flowchart TB
G[Gobernanza y observabilidad<br/>logs · auditoría · trazabilidad]
A[Aplicación<br/>interfaz · funcionalidades]
O[Orquestación<br/>routing · tools · secuencias]
AD[Adaptación<br/>prompts · contexto · RAG · reglas · fine-tuning]
M[Modelo<br/>modelo base · versión · proveedor]
D[Datos<br/>fuentes · repositorios · representaciones]
I[Infraestructura<br/>cloud · compute · storage]
I --> D
D --> M
M --> AD
AD --> O
O --> A
G -. supervisa .-> A
G -. supervisa .-> O
G -. supervisa .-> AD
G -. supervisa .-> M
El AI Stack
Una representación por capas para entender dónde se encuentran las capacidades, dependencias, costos, riesgos y controles de una aplicación de inteligencia artificial.
El AI Stack
En la página anterior ampliamos la mirada. Un sistema de IA no funciona solamente mediante un modelo: intervienen datos, infraestructura, interfaces, personas, procedimientos y controles.
Esa perspectiva es necesaria, pero produce un nuevo problema.
Si observamos todos los componentes de una aplicación moderna al mismo tiempo, la arquitectura puede volverse difícil de leer. Aparecen servicios cloud, documentos, modelos, prompts, reglas, mecanismos de recuperación, integraciones, interfaces, logs, controles, usuarios y procesos. Todo importa, pero no todo cumple la misma función.
Necesitamos entonces un mapa de capas.
En este handbook utilizaremos la expresión AI Stack para describir una representación analítica del conjunto de tecnologías y funciones que hacen posible una aplicación de inteligencia artificial.
La palabra stack proviene del vocabulario de ingeniería de software y suele utilizarse para describir una “pila” de componentes tecnológicos que trabajan juntos. No existe un único AI Stack universal. Diferentes autores y proveedores agrupan las capas de formas distintas.
Chip Huyen, por ejemplo, presenta una arquitectura de alto nivel para AI engineering organizada en grandes estratos. El material del curso adopta una descomposición más granular porque resulta especialmente útil para comprar, evaluar y gobernar soluciones profesionales.
El stack de este sitio
Utilizaremos siete capas:
Infraestructura → Datos → Modelo → Adaptación → Orquestación → Aplicación → Gobernanza y observabilidad
La función del esquema no es afirmar que todo sistema de IA deba dibujarse exactamente así.
Su función es ayudar a preguntar, para cada capa:
¿qué existe aquí, quién lo controla, qué puede cambiar y qué riesgo introduce?
Una primera lectura del mapa
El diagrama debe leerse como una abstracción, no como una secuencia física rígida.
En un sistema real, los datos pueden atravesar varias capas. La aplicación puede llamar directamente a servicios externos. La gobernanza no vive exclusivamente “arriba”: debe penetrar la arquitectura completa. La orquestación puede interactuar con herramientas y bases de datos en múltiples direcciones.
Aun así, el mapa es útil porque descompone una etiqueta comercial única —“IA”— en funciones distintas.
1. Infraestructura
La infraestructura contiene los recursos computacionales sobre los cuales funcionan los demás componentes.
Puede incluir:
cómputo
almacenamiento
redes
hosting
servicios cloud
entornos de ejecución
mecanismos de respaldoNo necesitamos dominar estos elementos como ingenieros. Necesitamos entender qué tipo de preguntas abren.
Qué problema resuelve
Los modelos y aplicaciones necesitan algún lugar donde ejecutarse y algún medio para almacenar o transmitir información.
La infraestructura responde, en términos simples:
¿sobre qué recursos materiales y servicios funciona el sistema?
Por qué importa
Puede afectar:
- disponibilidad;
- latencia;
- escalabilidad;
- continuidad;
- ubicación de datos;
- redundancia;
- seguridad;
- costos.
Un servicio que depende de una única región cloud y un servicio diseñado con redundancia geográfica pueden ofrecer la misma interfaz al usuario, pero no la misma resiliencia.
Pregunta jurídica inicial
¿Dónde corre el servicio y qué disponibilidad promete?
De esa pregunta pueden derivarse temas de SLA, continuidad, disaster recovery, ubicación y seguridad.
El material del curso insiste en una idea útil: la arquitectura es el índice oculto del contrato. La capa técnica indica qué tipo de obligaciones conviene buscar.
2. Datos
La capa de datos reúne las fuentes de información que alimentan, contextualizan o registran la operación.
En una aplicación jurídica puede incluir:
- documentos cargados por el usuario;
- legislación;
- jurisprudencia;
- contratos anteriores;
- políticas internas;
- bases documentales;
- metadatos;
- representaciones utilizadas para búsqueda;
- logs y resultados.
Qué problema resuelve
Un modelo general puede tener capacidad lingüística, pero una tarea profesional depende frecuentemente de información específica.
La capa de datos responde:
¿con qué información puede trabajar el sistema?
Pregunta jurídica inicial
El curso formula una pregunta especialmente útil:
¿Qué ingresa, qué persiste, qué se reutiliza y qué se borra?
Esta formulación obliga a separar varias operaciones que suelen mezclarse bajo la palabra “datos”.
Ingreso
¿Qué recibe el sistema?
Persistencia
¿Qué se almacena después de la ejecución?
Reutilización
¿Puede utilizarse posteriormente para otras finalidades?
Eliminación
¿Qué mecanismo existe para borrar o exportar información?
A partir de aquí aparecen temas de confidencialidad, DPA, retención, reutilización, exportación y seguridad.
3. Modelo
La capa de modelo contiene uno o más modelos que aportan capacidades de generación, clasificación, extracción, predicción u otras transformaciones.
Qué problema resuelve
El modelo proporciona una capacidad general o especializada que el resto del sistema puede utilizar.
La pregunta ya no es:
“¿usa IA?”
sino:
¿qué modelo o modelos intervienen y para qué función?
Variables relevantes
Dependiendo del caso puede importar:
proveedor
versión
modalidades
contexto soportado
desempeño
latencia
costo
posibilidad de sustitución
modo de desplieguePregunta jurídica inicial
¿Cuál es, de quién es y puede cambiar?
Esta pregunta parece sencilla, pero abre varios problemas.
Un proveedor puede mantener la misma aplicación y sustituir el modelo subyacente.
Puede utilizar un modelo de tercero sobre el cual no controla totalmente el ciclo de versión.
Puede enrutar distintas tareas hacia modelos diferentes.
Por eso una referencia contractual genérica a “AI technology” puede ser insuficiente cuando el modelo es material para la prestación.
4. Adaptación
Un modelo fundacional es una capacidad general. Una aplicación profesional necesita convertir esa capacidad en algo útil para una tarea determinada.
A ese conjunto de mecanismos lo agruparemos, pedagógicamente, bajo adaptación.
Puede incluir:
prompts
contexto
RAG
reglas
fine-tuning
configuración específicaNo desarrollaremos aquí estas técnicas porque tendrán páginas propias.
La intuición necesaria es sólo ésta:
la adaptación reduce la distancia entre lo que el modelo puede hacer en general y lo que necesitamos que haga en esta tarea concreta.
Un ejemplo
Un modelo general puede revisar texto.
Una aplicación contractual puede adaptarlo para:
- identificar cláusulas específicas;
- analizar desde la perspectiva del cliente;
- aplicar una taxonomía interna;
- comparar contra posiciones estándar;
- separar evidencia e inferencia.
La capacidad base puede ser compartida con miles de productos.
La diferenciación comercial puede encontrarse precisamente en cómo se construye esta capa superior.
Pregunta jurídica inicial
¿Dónde está la especialización por la que estoy pagando?
Si el proveedor responde “en nuestro modelo propietario”, el análisis será uno.
Si la especialización está principalmente en fuentes, prompts, reglas, playbooks o integración, pueden aparecer preguntas distintas sobre propiedad, documentación, cambios y aceptación.
El valor no siempre está en el foundation model
En muchos productos contemporáneos la diferenciación puede desplazarse hacia capas superiores: selección de contexto, fuentes, integración, workflow, experiencia de usuario, herramientas y controles.
Por eso un producto útil para Derecho no tiene que ser necesariamente el que utiliza el modelo mejor posicionado en un benchmark general.
5. Orquestación
Cuando una aplicación ejecuta más de una operación, alguien o algo debe coordinar el orden del trabajo.
A esta función la llamaremos orquestación.
La capa puede determinar, por ejemplo:
- qué componente se ejecuta primero;
- qué información recibe cada etapa;
- qué servicio se invoca;
- qué resultado vuelve al contexto;
- qué ruta se sigue ante una condición;
- cuándo termina la ejecución.
Qué problema resuelve
Un modelo puede producir una salida.
Un sistema complejo necesita coordinar varias operaciones.
Ejemplo simplificado:
flowchart LR
A[Recibir contrato] --> B[Extraer texto]
B --> C[Identificar cláusulas]
C --> D[Aplicar criterios]
D --> E[Preparar resultado]
No necesitamos decidir todavía si esta secuencia es un workflow, una cadena fija o parte de un sistema agente. Esas distinciones aparecerán después.
Aquí importa comprender que puede existir una capa de software que determina la organización de la ejecución.
Pregunta jurídica inicial
¿Qué operaciones puede coordinar o invocar el sistema?
Esta pregunta se volverá especialmente importante cuando la orquestación incluya herramientas capaces de leer, escribir o modificar sistemas externos.
6. Aplicación
La aplicación es la capa que convierte la arquitectura en una funcionalidad utilizable.
Puede incluir:
- interfaz;
- autenticación;
- usuarios;
- permisos;
- configuración;
- historial;
- integraciones;
- exportación;
- presentación de resultados;
- documentación funcional.
Qué problema resuelve
La aplicación traduce componentes técnicos a una experiencia operacional.
El usuario no “usa el modelo” en abstracto. Utiliza un producto que define qué puede cargar, qué función puede ejecutar, qué resultado puede ver y qué acciones puede realizar.
Pregunta jurídica inicial
¿Qué funcionalidad es realmente parte del producto contratado?
Esta pregunta obliga a distinguir entre:
DEMO
lo que el proveedor muestra
DOCUMENTACIÓN
lo que el proveedor describe
ESPECIFICACIÓN
lo que se define como prestación
ACEPTACIÓN
lo que se prueba que fue entregadoEs una diferencia especialmente importante en desarrollos y servicios complejos.
Una promesa comercial como “identificación automática de riesgos” puede ser demasiado abierta. Una especificación debería permitir saber qué cuenta como cumplimiento.
7. Gobernanza y observabilidad
La séptima capa tiene una particularidad: no debe entenderse como un componente aislado que simplemente “se pone arriba”.
La gobernanza y la observabilidad deberían atravesar el sistema.
Gobernanza
Pregunta:
¿Qué está permitido, quién puede hacerlo y bajo qué condiciones?
Puede comprender:
- roles;
- permisos;
- aprobación;
- políticas;
- restricciones;
- control de cambios;
- responsables.
Observabilidad
Pregunta:
¿Qué ocurrió realmente durante la ejecución?
Puede comprender:
- logs;
- métricas;
- trazas;
- eventos;
- registros de cambios;
- evidencia de acciones.
Por qué ambas se relacionan
Gobernar sin observar produce reglas difíciles de verificar.
Observar sin gobernar produce datos sin una estructura de responsabilidad.
Un sistema profesional necesita poder conectar:
qué podía hacer
+
qué hizo
+
quién lo autorizó
+
qué resultado produjoPregunta jurídica inicial
¿Qué queda registrado y auditable?
Esta pregunta se volverá central cuando lleguemos a agentes, pero conviene instalarla desde ahora.
El stack como traducción entre arquitectura y contrato
Una de las contribuciones más útiles del material del curso es convertir cada capa en una pregunta contractual.
| Capa | Pregunta inicial | Controles contractuales que pueden aparecer |
|---|---|---|
| Infraestructura | ¿Dónde corre y qué disponibilidad promete? | SLA, continuidad, disaster recovery, ubicación |
| Datos | ¿Qué ingresa, persiste, se reutiliza o se borra? | DPA, confidencialidad, retención, exportación |
| Modelo | ¿Cuál es, de quién es y puede cambiar? | versionado, sustitución, performance, subcontratación |
| Adaptación | ¿Dónde está la especialización que pago? | especificaciones, propiedad, cambios, aceptación |
| Orquestación | ¿Qué operaciones puede coordinar? | permisos, límites, aprobación humana |
| Aplicación | ¿Qué funcionalidad es parte del producto? | SOW, documentación, soporte, acceptance |
| Gobernanza y observabilidad | ¿Qué queda registrado y auditable? | logs, auditoría, incidentes, reportes, evidencia |
La tabla no significa que exista una cláusula independiente por cada capa.
Significa que una comprensión arquitectónica adecuada permite descubrir qué tipo de obligación necesita ser definida.
Regla práctica
Si no puede formular una pregunta concreta para cada capa relevante, probablemente todavía no entiende suficientemente qué está comprando o utilizando.
El stack también ayuda a localizar el error
Imaginemos que la aplicación entrega una recomendación incorrecta.
Podemos utilizar el stack como árbol de diagnóstico.
Infraestructura
¿Hubo una interrupción o pérdida de datos?
Datos
¿Faltaba un documento relevante?
Modelo
¿La generación fue incorrecta?
Adaptación
¿Los criterios o instrucciones estaban mal definidos?
Orquestación
¿Se omitió una etapa necesaria?
Aplicación
¿La interfaz presentó mal el resultado?
Gobernanza y observabilidad
¿Había revisión y registros suficientes para detectarlo?
La pregunta “¿por qué falló la IA?” se convierte en una investigación estructurada.
Un ejemplo completo: revisión de proveedor de IA
Volvamos al caso conductor.
Llegó un contrato de proveedor de IA. ¿Puede aprobarse?
Supongamos que el producto contratado permite revisar contratos y generar una matriz de riesgos.
Infraestructura
La aplicación corre sobre una nube de tercero.
Preguntas:
- ubicación;
- disponibilidad;
- resiliencia;
- recuperación.
Datos
La aplicación recibe contratos, anexos y políticas internas.
Preguntas:
- retención;
- reutilización;
- exportación;
- seguridad.
Modelo
La generación utiliza un modelo fundacional externo.
Preguntas:
- proveedor;
- versión;
- sustitución;
- desempeño.
Adaptación
El proveedor incorpora criterios propios y permite cargar playbooks del cliente.
Preguntas:
- propiedad;
- configuración;
- cambios;
- documentación.
Orquestación
El sistema ejecuta varias etapas antes de producir la matriz.
Preguntas:
- orden;
- fallbacks;
- operaciones externas;
- aprobaciones.
Aplicación
El usuario carga documentos, consulta resultados y exporta informes.
Preguntas:
- funcionalidad incluida;
- permisos;
- soporte;
- cambios de producto.
Gobernanza y observabilidad
La solución conserva logs y registra quién aprobó cada revisión.
Preguntas:
- contenido del log;
- acceso;
- conservación;
- auditabilidad.
Ahora podemos ver la contratación como una traducción entre dos estructuras:
ARQUITECTURA TÉCNICA
↓
PREGUNTAS DE RIESGO
↓
OBLIGACIONES CONTRACTUALES
↓
CONTROLES OPERACIONALESEl stack no es la cadena de proveedores
Debemos proteger una frontera conceptual importante.
Una capa describe una función arquitectónica.
Un proveedor describe un actor.
No son equivalentes.
Una misma empresa puede controlar varias capas.
Una capa puede depender de varios proveedores.
Por ejemplo:
Proveedor A
- aplicación
- orquestación
- adaptación
Proveedor B
- modelo
Proveedor C
- infraestructuraEl stack nos dice qué funciones existen.
La página siguiente preguntará quién sostiene esas funciones.
El stack tampoco asigna automáticamente responsabilidad
Identificar una capa no responde por sí solo quién responde jurídicamente por ella.
Supongamos que un cliente suministra una política interna desactualizada.
El sistema aplica correctamente esa política y produce una recomendación equivocada respecto de la política vigente.
La causa puede estar en la información suministrada por el cliente.
En otro caso, el proveedor podría sustituir unilateralmente el modelo y degradar una función prometida.
Aquí la atribución será distinta.
El stack ayuda a localizar dónde ocurrió algo.
El contrato, la regulación y los hechos permiten determinar quién tenía la obligación relevante.
Evitar tres errores al usar el stack
Error 1 — Convertirlo en dogma
No existe una única taxonomía universal.
El esquema del curso es una herramienta pedagógica.
Error 2 — Tratar las capas como compartimentos estancos
Los sistemas reales tienen dependencias cruzadas.
La capa de datos puede afectar al modelo y a la aplicación. La gobernanza atraviesa todas las demás.
Error 3 — Dibujar sin preguntar
Un diagrama sólo es útil si permite formular preguntas materiales.
No buscamos producir una arquitectura bonita.
Buscamos responder:
qué componente
qué función
qué control
qué dependencia
qué cambio
qué evidenciaQué debemos retener
El AI Stack es una forma de descomponer un sistema complejo en capas analíticamente manejables.
En este curso utilizamos:
Infraestructura
↓
Datos
↓
Modelo
↓
Adaptación
↓
Orquestación
↓
Aplicación
↓
Gobernanza y observabilidadCada capa abre una pregunta distinta.
El valor principal del mapa para profesionales del Derecho no es aprender arquitectura por sí misma. Es poder conectar:
componente → riesgo → obligación → control.
El problema que todavía queda abierto
Ya sabemos qué capas sostienen una aplicación.
Todavía no sabemos necesariamente quién las provee.
Una sola interfaz puede depender de un modelo externo, un cloud distinto, una base documental licenciada y varios servicios técnicos.
La siguiente página transforma el stack en un mapa de actores:
Dependencias.