flowchart LR
U[Usuario] --> A[Aplicación]
A --> M[Modelo]
M --> A
Modelo, sistema y aplicación
Tres objetos distintos que suelen confundirse cuando hablamos de IA y que deben separarse para entender, evaluar, contratar y gobernar una solución tecnológica.
Modelo, sistema y aplicación
En la página anterior vimos que un modelo puede producir resultados impresionantes sin que eso baste para describir un proceso profesional completo. Ahora necesitamos precisar qué objetos estamos observando.
En conversaciones cotidianas utilizamos frases como:
“La IA revisó el contrato.”
“Nuestra IA usa el modelo X.”
“Compramos una IA jurídica.”
“La IA tiene acceso a nuestros documentos.”
Todas pueden ser comprensibles en lenguaje informal. Pero si queremos analizar capacidad, riesgo, confidencialidad, disponibilidad, responsabilidad o cumplimiento contractual, resultan demasiado ambiguas.
La razón es que suelen comprimir en una misma palabra al menos tres niveles diferentes:
- el modelo que realiza determinadas transformaciones;
- el sistema de IA que organiza modelos, datos, infraestructura, controles y procesos;
- la aplicación que presenta determinadas funcionalidades al usuario o a otros sistemas.
Idea central
En el marco pedagógico de este sitio:
Modelo = componente que genera, clasifica, predice o transforma información.
Sistema de IA = conjunto operacional dentro del cual uno o más modelos funcionan junto con datos, infraestructura, interfaces, controles, condiciones de uso y procesos humanos.
Aplicación = producto o capa de software mediante la cual determinadas funcionalidades se ofrecen al usuario o a otros componentes.
No son sinónimos.
Esta distinción no pretende imponer una terminología universal a toda la industria ni sustituir las definiciones que pueda utilizar una norma jurídica específica. Su función es analítica: permitir que hagamos preguntas más precisas.
Por qué necesitamos tres niveles
Supongamos que dos empresas ofrecen un producto que, desde la perspectiva del usuario, hace exactamente lo mismo:
[ Subir contrato ]
[ Revisar ]
Resultado:
- riesgo de datos
- riesgo de responsabilidad
- riesgo de continuidadLa experiencia visible puede ser casi idéntica.
Sin embargo, detrás de esa interfaz podrían existir arquitecturas radicalmente distintas.
Producto A
Producto B
flowchart LR
U[Usuario] --> A[Aplicación]
A --> P[Procesamiento documental]
P --> K[Fuentes y criterios]
K --> M[Modelo]
M --> V[Validaciones]
V --> A
Desde el punto de vista comercial ambos pueden venderse como “AI Contract Review”.
Desde el punto de vista técnico y jurídico no son el mismo sistema.
La distinción entre modelo, sistema y aplicación nos permite empezar a explicar por qué.
El modelo
El modelo es el componente que aporta una determinada capacidad computacional.
En el caso de un LLM puede procesar texto y producir nuevas secuencias de texto. En otros sistemas un modelo puede clasificar imágenes, detectar anomalías, estimar valores o producir representaciones útiles para búsqueda y comparación.
Una representación mínima sería:
flowchart LR
A[Entrada] --> B[Modelo]
B --> C[Salida]
Por ejemplo:
Entrada:
“Clasifica esta cláusula de responsabilidad como
favorable, negociable o crítica desde la perspectiva del cliente.”
Modelo:
procesa la entrada y el contexto disponible.
Salida:
“Crítica”.Conocer el modelo importa porque puede afectar, entre otras cosas:
- tipos de entrada que admite;
- calidad de generación;
- desempeño en ciertas tareas;
- latencia;
- costo de uso;
- tamaño del contexto disponible;
- comportamiento frente a determinados idiomas o dominios;
- posibilidades de despliegue y adaptación.
Pero conocer el nombre del modelo no nos revela automáticamente cómo funciona la solución completa.
Un mismo modelo puede producir sistemas muy distintos
Imaginemos que dos firmas utilizan el mismo modelo fundacional.
La firma 1 lo usa mediante un chat general y entrega manualmente cada contrato.
La firma 2 construye una aplicación en la que el modelo recibe solamente determinadas cláusulas, junto con criterios internos, y donde los resultados de riesgo alto pasan obligatoriamente a revisión humana.
El modelo subyacente puede ser idéntico.
Sin embargo, cambian:
- la información disponible;
- la forma de preparar la entrada;
- la finalidad;
- los controles;
- los usuarios;
- las acciones posteriores;
- la evidencia conservada.
Por tanto, no podemos atribuir al modelo todas las propiedades del sistema.
Error típico
Preguntar únicamente “¿qué modelo usa?” y tratar la respuesta como descripción suficiente del producto.
El modelo importa, pero el riesgo real puede estar en la recuperación documental, la integración, los permisos, las actualizaciones, el workflow o la revisión humana.
El sistema de IA
El curso utiliza una noción operacional de sistema de IA.
El sistema es el conjunto dentro del cual la capacidad del modelo se vuelve utilizable para una finalidad concreta.
Podemos representarlo de manera inicial así:
MODELO
+
DATOS
+
INFRAESTRUCTURA
+
INTERFAZ
+
CONTROLES
+
CONDICIONES DE USO
+
PROCESOS HUMANOS
=
SISTEMA EN OPERACIÓNEsta fórmula no intenta enumerar todos los componentes que puede tener una arquitectura real. Cumple una función más importante: recordarnos que el output final depende de algo más que del modelo.
El sistema determina las condiciones de uso de la capacidad
Pensemos en una función simple: resumir un contrato.
Un modelo puede resumir texto.
Pero el sistema determina cuestiones como:
- cómo llega el documento;
- si se procesa completo;
- si se extrae correctamente el texto;
- qué instrucciones acompañan al documento;
- qué usuario está autorizado para cargarlo;
- dónde se almacena;
- cuánto tiempo se conserva;
- qué resultado se muestra;
- si existen advertencias;
- qué logs se generan.
El modelo aporta una capacidad de generación.
El sistema define las condiciones operacionales de esa capacidad.
El sistema puede incorporar varios modelos
Otra razón para no confundir ambos niveles es que una aplicación puede utilizar más de un modelo.
Por ejemplo:
flowchart LR
D[Documento] --> O[OCR o extracción]
O --> C[Modelo de clasificación]
C --> L[LLM de análisis]
L --> R[Resultado]
Incluso puede existir un modelo para clasificar, otro para generar y un tercero para evaluar una salida.
Hablar de “el modelo de la aplicación” puede ser entonces una simplificación excesiva.
La pregunta más útil pasa a ser:
¿Qué modelos intervienen, para qué función y bajo qué reglas?
La aplicación
La aplicación es la capa de software mediante la cual una capacidad se ofrece de manera utilizable.
Para un usuario final, suele ser el objeto más visible.
Puede adoptar muchas formas:
- un sitio web;
- una función dentro de un procesador de textos;
- una extensión de un gestor documental;
- un asistente conversacional;
- una herramienta de due diligence;
- una aplicación interna;
- un servicio que opera en segundo plano sin interfaz humana directa.
La aplicación puede encargarse de cuestiones que el modelo no resuelve por sí solo:
usuarios
permisos
carga de archivos
interfaz
historial
integraciones
configuración
notificaciones
presentación de evidencia
exportación de resultadosLa aplicación traduce una capacidad técnica a una tarea reconocible
Un modelo fundacional puede realizar muchas tareas posibles.
Una aplicación selecciona algunas y las convierte en una experiencia concreta.
Por ejemplo, una plataforma de revisión contractual puede ofrecer botones como:
[ Extraer cláusulas ]
[ Comparar con estándar ]
[ Identificar riesgos ]
[ Preparar preguntas ]Esas funciones no necesariamente existen “dentro del modelo” como módulos separados. Pueden ser construidas mediante software, instrucciones, fuentes, reglas y secuencias que organizan el uso del modelo.
La aplicación convierte una capacidad general en funcionalidades reconocibles para un usuario.
Un ejemplo completo: la misma marca, distintos niveles
Imaginemos un proveedor ficticio llamado LexReview AI.
El vendedor afirma:
“LexReview AI utiliza un modelo de última generación para revisar contratos y detectar automáticamente riesgos.”
La frase contiene varios niveles.
Nivel 1 — Modelo
El proveedor utiliza un LLM de un tercero.
El modelo puede:
- procesar lenguaje;
- generar texto;
- clasificar fragmentos;
- producir explicaciones.
Nivel 2 — Sistema
LexReview AI incorpora además:
- extracción de texto desde PDF;
- almacenamiento de documentos;
- criterios contractuales propios;
- fuentes internas del cliente;
- mecanismos de autenticación;
- controles de acceso;
- logs;
- reglas de escalamiento.
Nivel 3 — Aplicación
El usuario ve:
- una pantalla para cargar contratos;
- un panel de riesgos;
- enlaces a cláusulas;
- botones para exportar resultados;
- un historial de revisiones.
La experiencia puede ser una.
La arquitectura subyacente no lo es.
Qué cambia cuando distinguimos los niveles
Ahora podemos formular preguntas que antes quedaban mezcladas.
Sobre el modelo
¿Qué modelo utiliza el sistema?
¿Puede cambiar durante la vigencia del servicio?
¿Existen requisitos mínimos de desempeño?
Sobre el sistema
¿Qué datos intervienen?
¿Qué fuentes incorpora?
¿Qué terceros sostienen la operación?
¿Qué registros conserva?
Sobre la aplicación
¿Qué funcionalidad está incluida en la suscripción?
¿Qué permisos puede configurar el cliente?
¿Cómo se muestran las fuentes y advertencias?
¿Qué integraciones existen?
La distinción no es terminológica solamente. Reorganiza el análisis.
Por qué no deben confundirse
1. Porque la calidad pertenece al sistema completo
Supongamos que un modelo obtiene buenos resultados en una evaluación general.
Eso no garantiza que una aplicación concreta produzca resultados igualmente buenos.
La calidad puede verse afectada por:
- extracción defectuosa de documentos;
- contexto insuficiente;
- instrucciones pobres;
- fuentes desactualizadas;
- restricciones de longitud;
- postprocesamiento;
- diseño de interfaz;
- errores de integración.
Chip Huyen propone evaluar no solamente modelos aislados, sino también los componentes del sistema y el desempeño de la aplicación respecto de la tarea concreta. Esta diferencia es esencial para el curso: un benchmark de modelo es una señal de capacidad, no una decisión final sobre un sistema profesional.
2. Porque el riesgo puede estar fuera del modelo
Imaginemos que se produce una filtración de información confidencial.
El problema podría estar en:
- almacenamiento;
- permisos;
- logging;
- configuración;
- integración;
- aislamiento entre clientes;
- conducta del usuario.
Decir simplemente “falló el modelo” puede impedir una investigación causal correcta.
Del mismo modo, una cita jurídica falsa puede provenir de varios lugares:
fuente incorrecta
↓
recuperación incorrecta
↓
contexto incorrecto
↓
generación incorrecta
↓
presentación sin verificaciónLa salida final no identifica automáticamente dónde ocurrió el error.
3. Porque la relación comercial puede ocultar la arquitectura
El cliente puede contratar con una única empresa.
Esa empresa puede depender de:
proveedor de modelo
proveedor cloud
base documental
servicio de OCR
servicio de autenticación
servicio de analyticsEl contrato principal puede ser bilateral.
El sistema técnico puede ser distribuido.
Esta cuestión tendrá una página propia bajo Dependencias, pero la distinción modelo/sistema/aplicación es lo que permite verla.
4. Porque los cambios ocurren en niveles distintos
Una aplicación puede mantener su interfaz y cambiar el modelo.
Puede mantener el modelo y cambiar la fuente documental.
Puede mantener ambos y modificar la política de retención.
Puede agregar una funcionalidad nueva sin cambiar el modelo principal.
Por eso decir:
“el producto no cambió”
puede ser cierto comercialmente y falso desde el punto de vista del riesgo.
Necesitamos poder preguntar qué capa cambió.
5. Porque una promesa comercial puede referirse a un nivel y la obligación jurídica a otro
Supongamos que la página comercial dice:
“Detecta automáticamente cláusulas de alto riesgo.”
Para convertir esa frase en una obligación contractual verificable necesitamos saber al menos:
- qué significa “detectar”;
- qué universo de cláusulas;
- bajo qué documentos;
- con qué criterios;
- qué tasa de error es aceptable;
- qué parte del sistema produce la función.
Una promesa sobre “la IA” debe ser traducida a una prestación técnicamente identificable.
Una analogía útil: motor, vehículo y servicio
Podemos utilizar una analogía provisional.
Modelo = motor.
Aporta potencia o capacidad.
Sistema = vehículo completo.
Incluye motor, transmisión, frenos, sensores, dirección y otras piezas necesarias para operar.
Aplicación = forma concreta en que el usuario accede y utiliza la capacidad.
La analogía ayuda porque evita confundir el componente central con el conjunto operacional.
Pero deja de servir cuando imaginamos que siempre existe un único motor, una única frontera o una arquitectura lineal. Un sistema de IA puede utilizar varios modelos, servicios y reglas; además, la misma pieza puede ser “aplicación” para un actor y “componente” para otro.
Por eso la analogía debe abandonarse en cuanto haya cumplido su función introductoria.
Las fronteras dependen de la perspectiva
Las categorías son útiles, pero no siempre tienen bordes absolutos.
Consideremos una plataforma jurídica SaaS.
Desde el punto de vista del cliente:
la plataforma completa es la aplicación contratada.
Desde el punto de vista del proveedor:
esa aplicación puede ser sólo una capa que integra modelos, bases, servicios cloud e infraestructura interna.
Desde el punto de vista del proveedor del modelo:
la plataforma jurídica puede ser apenas uno entre miles de clientes que consumen su servicio.
No existe una contradicción.
Lo importante es especificar desde qué nivel estamos analizando el sistema.
Una regla práctica para documentos y contratos
Cuando un documento utilice la palabra “AI”, conviene preguntar inmediatamente:
¿Se refiere al modelo?
¿Se refiere al sistema completo?
¿Se refiere a una funcionalidad de la aplicación?
Por ejemplo:
“El proveedor podrá actualizar la AI periódicamente.”es una cláusula ambigua.
¿Puede cambiar el modelo?
¿Puede cambiar la lógica de aplicación?
¿Puede modificar fuentes?
¿Puede alterar funcionalidades?
¿Puede cambiar subprocesadores?
La precisión conceptual permite exigir precisión contractual.
Caso conductor: ¿qué estamos comprando?
Volvamos al contrato del proveedor de IA.
Antes de revisar limitaciones de responsabilidad o indemnidades, hacemos una pregunta más elemental:
¿Qué estamos comprando realmente?
La respuesta superficial podría ser:
“una plataforma de inteligencia artificial para revisar contratos”.
Una respuesta más útil debería separar:
APLICACIÓN
plataforma web de revisión contractual
MODELO
uno o más modelos que generan o clasifican resultados
SISTEMA
aplicación + modelos + documentos + infraestructura + controles + procesosEsta descripción permite que el análisis jurídico posterior se conecte con la arquitectura real.
Una obligación de disponibilidad puede relacionarse principalmente con el servicio de aplicación.
Una cláusula de versionado puede afectar al modelo.
Una obligación de retención puede corresponder a componentes del sistema de datos.
Una garantía de funcionalidad puede depender de varias capas simultáneamente.
La arquitectura no reemplaza al contrato. Permite redactarlo y leerlo mejor.
Qué debemos retener
Modelo, sistema y aplicación designan niveles distintos.
El modelo aporta capacidad computacional.
El sistema organiza esa capacidad junto con información, infraestructura, controles y procesos.
La aplicación ofrece una determinada experiencia o funcionalidad utilizable.
Confundir estos niveles produce errores recurrentes:
- atribuir al modelo fallas de integración;
- evaluar un producto sólo por el modelo que utiliza;
- negociar garantías sobre un componente equivocado;
- ignorar cambios que ocurren detrás de una interfaz estable;
- tratar una marca comercial como descripción técnica.
La regla práctica es:
cuando alguien diga “la IA hace X”, pregunte qué componente del sistema hace X y bajo qué condiciones.
El problema que todavía queda abierto
Ya podemos distinguir las piezas conceptualmente.
Pero todavía existe un error posible: imaginar que el sistema completo sigue siendo un objeto exclusivamente técnico.
No lo es.
En una organización, la herramienta funciona junto con personas, procedimientos, autorizaciones, interfaces y controles. Esas relaciones pueden modificar el comportamiento real incluso cuando el modelo y el software no cambian.
Por eso la siguiente página introduce una perspectiva más amplia:
la IA como sistema sociotécnico.