flowchart LR
A[Capacidad del modelo] --> B[Generar o analizar una salida]
B --> C[Resultado útil posible]
D[Sistema profesional] --> E[Entrada correcta]
E --> F[Información pertinente]
F --> G[Modelo]
G --> H[Controles y revisión]
H --> I[Resultado utilizable]
Inteligencia artificial: antes de usarla
Qué hace un modelo, qué no hace y por qué una capacidad técnica aislada todavía no constituye un sistema profesional de trabajo.
Inteligencia artificial: antes de usarla
La primera dificultad para trabajar seriamente con inteligencia artificial no suele ser aprender una técnica. Es aprender a mirar correctamente el objeto que tenemos delante.
La experiencia de uso de una aplicación generativa produce una ilusión muy poderosa. Escribimos una instrucción en lenguaje natural, esperamos unos segundos y recibimos una respuesta que parece haber leído, comprendido y resuelto el problema. Si la respuesta está bien redactada, cita conceptos jurídicos pertinentes y adopta una estructura profesional, resulta fácil saltar desde una observación relativamente modesta —“el sistema produjo un buen texto”— hacia afirmaciones mucho más amplias —“la IA sabe Derecho”, “la IA entendió el contrato”, “la IA encontró la respuesta” o “la IA decidió correctamente”.
Ese salto es precisamente lo que debemos evitar.
Antes de aprender prompts, recuperación de información, herramientas, workflows o agentes, necesitamos una idea más básica: qué clase de capacidad aporta un modelo y qué parte del trabajo profesional queda todavía fuera de esa capacidad.
Idea central
Un modelo puede poseer capacidades extraordinarias para generar, clasificar, extraer o transformar información y, al mismo tiempo, ser insuficiente como explicación del sistema que realmente utilizamos.
La primera operación mental del curso es pasar de:
“¿Qué tan bueno es el modelo?”
a:
“¿Qué sistema está produciendo el trabajo que observo?”
Empezar por una distinción sencilla: capacidad no es sistema
Pensemos en una tarea jurídica cotidiana: llega un contrato de un proveedor tecnológico y queremos identificar sus principales riesgos.
Podemos entregar el documento a un modelo y pedir:
Revisa este contrato e identifica los principales riesgos para el cliente.El resultado puede ser útil. El modelo puede encontrar cláusulas de responsabilidad, confidencialidad, datos personales, propiedad intelectual o término. Incluso puede explicar por qué ciertas redacciones resultan problemáticas.
Eso demuestra una capacidad.
No demuestra todavía que exista un proceso profesional completo para revisar contratos.
Para eso tendríamos que responder preguntas adicionales. ¿Recibió el contrato completo o faltó un anexo? ¿Conocía la política interna de negociación de la organización? ¿La información estaba actualizada? ¿Separó texto contractual de inferencia? ¿Existía una regla para escalar riesgos altos? ¿Alguien verificó el resultado? ¿Quedó un registro suficiente para reconstruir posteriormente qué se revisó y bajo qué criterios?
La diferencia entre esas dos situaciones puede representarse así:
El primer flujo pregunta si una capacidad existe.
El segundo pregunta si esa capacidad puede operar de manera suficientemente controlada dentro de una práctica real.
Qué hace un modelo
En este handbook usaremos modelo como una categoría general para referirnos a un componente computacional que transforma entradas en salidas a partir de regularidades aprendidas durante su desarrollo o entrenamiento.
No todos los modelos de inteligencia artificial hacen lo mismo. Unos clasifican. Otros predicen valores. Otros reconocen imágenes. Otros generan contenido. El término “inteligencia artificial” agrupa, por tanto, técnicas y sistemas muy distintos.
Para el recorrido que sigue nos interesan especialmente los modelos fundacionales y, dentro de ellos, los modelos de lenguaje de gran escala o large language models —LLM— porque son la base de muchas aplicaciones generativas contemporáneas.
Un modelo puede realizar operaciones como:
- generar un borrador de texto;
- resumir un documento;
- extraer determinada información;
- clasificar un fragmento en una categoría;
- comparar dos textos;
- transformar una salida de un formato a otro;
- responder una pregunta a partir del contexto que recibe;
- producir una representación útil para otras operaciones del sistema.
El punto importante es que estas operaciones son transformaciones computacionales. No necesitamos describirlas mediante categorías psicológicas humanas para reconocer su utilidad.
Un modelo puede producir una clasificación jurídicamente útil sin “tener una opinión” sobre el contrato. Puede generar una explicación convincente sin poseer responsabilidad profesional. Puede encontrar una regularidad en el lenguaje sin realizar el mismo proceso cognitivo que un abogado.
En el caso de los LLM: generar una continuación plausible
Para comprender los LLM conviene partir de una intuición simple.
Supongamos que el sistema recibe:
“La presente obligación de confidencialidad permanecerá vigente por…”
El modelo procesa la secuencia recibida y genera una continuación a partir de las relaciones estadísticas y representaciones aprendidas durante su entrenamiento, condicionadas por el contexto que tiene disponible en esa ejecución.
No produce necesariamente todo el párrafo de una sola vez. En una explicación simplificada, genera progresivamente unidades llamadas tokens. Cada nueva unidad se incorpora al contexto desde el cual continúa la generación.
No necesitamos conocer todavía la arquitectura Transformer ni las matemáticas de la inferencia. Sí necesitamos comprender tres consecuencias prácticas.
Primera: el modelo puede producir lenguaje extremadamente coherente porque fue construido precisamente para explotar patrones de lenguaje a gran escala.
Segunda: una respuesta lingüísticamente convincente no contiene, por ese solo hecho, una garantía de verdad.
Tercera: el contexto entregado al modelo durante la ejecución condiciona fuertemente lo que puede producir.
Esta tercera consecuencia será decisiva durante todo el curso. Un modelo no trabaja en abstracto: siempre recibe una determinada entrada, dentro de una determinada aplicación, con una determinada cantidad de contexto y bajo determinadas instrucciones.
Probabilidad no significa azar sin estructura
Una característica importante de los modelos generativos es su naturaleza probabilística.
Esto no significa que el modelo responda “al azar” en el sentido cotidiano. Significa que, frente a una determinada secuencia, existen diferentes continuaciones posibles con distintas probabilidades y que el mecanismo de generación selecciona entre ellas de acuerdo con su configuración.
Por eso dos ejecuciones del mismo encargo pueden producir formulaciones diferentes.
En software determinista solemos esperar una relación cercana a:
misma entrada
↓
misma regla
↓
misma salidaEn un modelo generativo puede ocurrir:
misma entrada
↓
modelo probabilístico
↓
varias salidas posiblesChip Huyen destaca esta naturaleza probabilística como uno de los factores que hacen especialmente desafiante construir aplicaciones confiables con modelos fundacionales. La variabilidad no elimina la utilidad del modelo; obliga a diseñar evaluación y controles adecuados alrededor de ella.
Para un abogado existe una consecuencia inmediata: una demostración exitosa prueba posibilidad, no estabilidad.
Si una herramienta revisa correctamente un contrato durante una demo, sabemos que pudo hacerlo en ese caso. Todavía no sabemos cómo se comportará frente a cincuenta contratos diferentes, anexos mal escaneados, cláusulas atípicas, documentos en otro idioma o situaciones donde la información relevante aparezca distribuida en varias fuentes.
Qué no hace un modelo
Comprender los límites no significa disminuir la importancia de la tecnología. Significa impedir que la utilidad observada sea interpretada como una propiedad más amplia que la efectivamente demostrada.
No transforma automáticamente fluidez en verdad
Un LLM puede producir una afirmación falsa en un texto formalmente impecable.
Éste es uno de los problemas habitualmente descritos como alucinación: el sistema genera contenido que no está suficientemente fundamentado en hechos o fuentes pertinentes para la tarea.
En el trabajo jurídico el problema es especialmente serio porque una cita falsa puede tener exactamente la apariencia superficial de una cita correcta.
Comparemos:
La Corte Suprema sostuvo en sentencia de 14 de mayo de 2025 que...La estructura sintáctica no nos dice si esa sentencia existe.
La conclusión general es sencilla:
La forma correcta no prueba el contenido
Debemos separar siempre tres cuestiones:
FORMA CORRECTA
¿La salida tiene la estructura solicitada?
CONTENIDO CORRECTO
¿Lo que afirma es verdadero o jurídicamente defendible?
EVIDENCIA SUFICIENTE
¿Podemos comprobar de dónde proviene y por qué debemos aceptarlo?
Esta separación será importante más adelante cuando trabajemos con salidas estructuradas. Un JSON perfectamente válido puede contener una cita inventada. Una tabla impecable puede clasificar mal una cláusula. La estructura mejora la capacidad de procesar y revisar la salida; no convierte la salida en verdadera.
No conoce necesariamente el presente
Los modelos se desarrollan a partir de información disponible durante determinadas etapas de entrenamiento y pueden incorporar mecanismos adicionales de actualización o acceso a información externa. Pero no debemos asumir que un modelo aislado posee conocimiento actualizado sobre cualquier hecho contemporáneo.
Precios, versiones de software, estados procesales, normas recientemente publicadas, cambios societarios o políticas internas pueden haber cambiado.
Cuando la tarea depende de información actual, necesitamos saber de dónde proviene esa actualidad.
Decir “el sistema sabe la normativa vigente” es menos preciso que preguntar:
¿Qué fuente consulta y cuál es su fecha de actualización?
No conoce necesariamente la información privada de una organización
La organización puede disponer de miles de documentos que nunca formaron parte del entrenamiento del modelo y que tampoco se encuentran presentes en la interacción actual.
Por ejemplo:
- contratos anteriores;
- políticas internas;
- matrices de riesgo;
- correos;
- informes de auditoría;
- playbooks de negociación;
- bases documentales licenciadas.
La existencia de información en la organización no equivale a disponibilidad para el modelo.
Ésta parece una diferencia obvia, pero en la práctica es una de las fuentes más frecuentes de expectativas equivocadas.
El abogado puede saber que “nuestra política exige responsabilidad ilimitada por cierto tipo de incidente”. Si esa política no fue incorporada de alguna forma a la ejecución, no existe una razón para asumir que el modelo aplicará ese criterio.
No conoce automáticamente la fuente de cada afirmación
Un modelo puede producir una respuesta que coincide con información real sin ser capaz, por sí solo, de identificar con confiabilidad el documento exacto del que deriva cada proposición.
Eso es distinto de un sistema diseñado para recuperar fuentes, adjuntar fragmentos y mantener procedencia.
La diferencia importa porque el trabajo jurídico no consiste solamente en producir proposiciones plausibles. Muchas veces necesitamos poder responder:
¿Dónde está eso?
¿Cuál es la norma?
¿Qué cláusula lo dice?
¿Qué documento respalda esta inferencia?
No puede actuar sobre sistemas externos por el solo hecho de generar lenguaje
Un modelo puede producir la frase:
“He enviado el informe al equipo de privacidad.”
Eso no significa que haya ocurrido una acción externa.
Para que el sistema efectivamente envíe un mensaje, modifique un registro, guarde un archivo o cree una tarea, debe existir una arquitectura que conecte el modelo con capacidades externas y que autorice esa operación.
Esta frontera será desarrollada mucho más adelante, en la sección Poder actuar. Por ahora basta una regla:
generar una descripción de una acción no es ejecutar la acción.
No posee permiso porque posea capacidad
Incluso cuando una aplicación dispone técnicamente de una función, sigue existiendo una pregunta distinta:
¿Está autorizada a utilizarla en esta situación?
Ésta es una distinción transversal del curso:
| Nivel | Pregunta |
|---|---|
| Capacidad | ¿Puede hacerlo técnicamente? |
| Permiso | ¿Está autorizado a hacerlo? |
| Decisión | ¿Puede seleccionar esa acción? |
| Responsabilidad | ¿Quién responde por el resultado? |
Que un sistema pueda eliminar un archivo no significa que deba recibir permiso para hacerlo autónomamente.
Que un modelo pueda recomendar aprobar un contrato no significa que tenga autoridad institucional para aprobarlo.
“Entender” no significa atribuir pensamiento humano
Los sistemas generativos han hecho necesario utilizar vocabulario que a veces se aproxima al lenguaje psicológico: “razona”, “decide”, “recuerda”, “sabe”. Estas expresiones pueden ser pedagógicamente útiles, pero deben manejarse con precisión.
Cuando decimos que un modelo “elige” una salida, estamos describiendo de manera simplificada un proceso computacional de selección.
Cuando decimos que una aplicación “recuerda”, puede ser que exista software que conserva estado y vuelve a incorporar información en una interacción posterior.
Cuando decimos que un agente “decide el siguiente paso”, puede significar que el sistema utiliza un modelo para seleccionar entre acciones permitidas.
Nada de ello implica necesariamente conciencia, intención moral o comprensión jurídica humana.
Esta precisión no es filosófica solamente. Tiene consecuencias prácticas. Si tratamos al sistema como un profesional autónomo, podemos terminar atribuyéndole capacidades, deberes o autoridad que en realidad pertenecen a personas y organizaciones.
Del output impresionante al trabajo operativo
La pregunta más importante de esta página aparece cuando pasamos de una respuesta aislada a un proceso profesional.
Imaginemos nuevamente el contrato del proveedor de IA.
Un modelo recibe el archivo y produce esta salida:
1. Riesgo alto: uso amplio de Customer Data.
2. Riesgo medio: SLA insuficiente.
3. Riesgo alto: limitación de responsabilidad demasiado baja.
4. Recomendación: no aprobar sin modificaciones.Podría ser correcto.
Pero un proceso operacional necesita algo más.
Tal vez debería poder reconstruir:
contrato recibido
↓
secciones efectivamente procesadas
↓
criterios de revisión aplicados
↓
fuentes adicionales utilizadas
↓
hallazgos
↓
evidencia de cada hallazgo
↓
revisión humana
↓
decisión
↓
registroLa diferencia no está en que el modelo “se vuelva más inteligente”. Está en que la capacidad se inserta dentro de una arquitectura de trabajo.
El caso conductor: “¿Puede aprobarse?”
Durante el handbook utilizaremos un caso recurrente:
Llegó un contrato de proveedor de IA. ¿Puede aprobarse?
En esta primera página no intentaremos resolverlo.
Lo utilizaremos para descubrir la diferencia entre capacidad y sistema.
Situación 1: uso directo de un modelo
El abogado entrega el contrato y solicita una revisión.
El modelo produce un análisis.
Tenemos una salida.
Situación 2: proceso profesional
La organización exige, por ejemplo:
- identificar el tipo de servicio contratado;
- separar obligaciones del proveedor y del cliente;
- verificar tratamiento de datos;
- revisar SLA y continuidad;
- comparar posiciones contra estándares internos;
- distinguir texto contractual, inferencia y evaluación;
- escalar determinados riesgos;
- registrar la decisión final.
Ahora el problema ya no es solamente “generar un análisis”.
Es organizar capacidades, información, personas y controles para producir una decisión defendible.
Una matriz para leer cualquier promesa de IA
Cuando una herramienta exhiba una capacidad, conviene separar cuatro niveles de observación:
| Nivel | Pregunta | Ejemplo |
|---|---|---|
| Capacidad | ¿Puede producir la operación? | ¿Puede extraer cláusulas? |
| Condición | ¿Bajo qué entradas y contexto? | ¿Necesita el contrato completo? |
| Fiabilidad | ¿Con qué tasa y tipo de error? | ¿Qué omisiones produce? |
| Operación | ¿Cómo se inserta en el trabajo? | ¿Quién revisa y qué queda registrado? |
Esta matriz evita dos posiciones igualmente pobres.
La primera es el entusiasmo acrítico:
“Lo hizo una vez, por tanto funciona.”
La segunda es el rechazo abstracto:
“Puede equivocarse, por tanto no sirve.”
La evaluación profesional necesita una pregunta más exigente:
¿Para qué tarea concreta, bajo qué condiciones, con qué controles y con qué nivel de riesgo resulta suficientemente útil?
Por qué esto importa para profesionales del Derecho
La ABA, al abordar el uso de IA generativa por abogados, no exige que el profesional se convierta en ingeniero de modelos. Sí exige una comprensión razonable de las capacidades y limitaciones de la tecnología utilizada. Las orientaciones del CCBE avanzan en una dirección compatible: la adopción profesional debe considerar confidencialidad, competencia, exactitud, transparencia y otros riesgos vinculados a la forma concreta en que se utiliza el sistema.
Esta exigencia de comprensión razonable tiene una consecuencia pedagógica importante.
Un abogado no necesita saber entrenar un Transformer.
Sí debería poder distinguir entre preguntas como:
¿El modelo puede resumir?
¿La aplicación tiene acceso al documento correcto?
¿El sistema conserva información?
¿Quién verifica el resultado?
¿La salida es trazable?
¿Quién está autorizado para actuar sobre ella?
La competencia tecnológica útil para el trabajo jurídico empieza por formular preguntas causalmente correctas.
Qué debemos retener
Un modelo puede generar, clasificar, extraer, comparar, transformar y apoyar formas de razonamiento sobre información que recibe.
Eso no significa que:
- toda afirmación generada sea verdadera;
- disponga automáticamente de información actual;
- pueda acceder a documentos privados no incorporados a la ejecución;
- identifique siempre de manera confiable la procedencia de lo que afirma;
- pueda actuar sobre sistemas externos por el solo hecho de describir una acción;
- posea permiso, autoridad o responsabilidad profesional.
La idea que necesitamos conservar es más general:
El modelo es una fuente de capacidad. El trabajo profesional emerge cuando esa capacidad se integra dentro de un sistema.
El problema que todavía queda abierto
Ahora podemos ver por qué la expresión “usar IA” resulta demasiado imprecisa.
Pero todavía no hemos separado con suficiente claridad los objetos que suelen quedar mezclados bajo esa etiqueta.
¿Es lo mismo el modelo que produce una salida que el sistema que organiza la ejecución?
¿Es lo mismo ese sistema que la aplicación que ve el usuario?
No.
La siguiente página introduce la distinción fundamental entre modelo, sistema de IA y aplicación.