flowchart LR
A["Pregunta actual"] --> B["Buscar material pertinente"]
C["Knowledge"] --> B
B --> D["Seleccionar fragmentos"]
D --> E["Incorporar al contexto"]
E --> F["Modelo"]
Qué aporta cada capa
Un mapa funcional para distinguir instrucción, metodología, información, acción, secuencia, criterios y selección dinámica, y para decidir qué arquitectura necesita realmente una tarea.
En la página anterior reconstruimos la arquitectura completa como una progresión.
Ahora necesitamos utilizarla como instrumento de diagnóstico.
Supongamos que una herramienta de revisión contractual funciona mal. El usuario dice:
“La IA no está revisando bien.”
La frase identifica un problema, pero todavía no permite corregirlo.
¿La instrucción era ambigua?
¿La metodología estaba incompleta?
¿Faltaba la política correcta?
¿La información existía pero no fue recuperada?
¿La aplicación no podía consultar el expediente?
¿El proceso ejecutó las etapas en un orden incorrecto?
¿El criterio de escalamiento estaba mal definido?
¿El agente seleccionó una ruta improcedente?
La arquitectura adquiere valor cuando permite transformar una queja genérica en una pregunta más precisa:
¿Qué propiedad necesitábamos y qué capa era responsable de aportarla?
Idea central
Cada capa debe poder describirse mediante una función.
En el marco pedagógico de este sitio:
Prompt → instrucción
Skill → metodología
Knowledge → información
Tool → acción
Workflow → secuencia
Playbook → criterios
Agent → selección dinámica
Las demás piezas —template, RAG, API, connector y MCP— ayudan a reutilizar, seleccionar o conectar esas funciones.
La arquitectura como mapa de preguntas
Podemos condensar el sistema completo en siete preguntas operativas:
| Pregunta | Capa principal |
|---|---|
| ¿Qué queremos que se haga? | Prompt / Template |
| ¿Cómo debe hacerse correctamente? | Skill |
| ¿Con qué información debe trabajarse? | Knowledge / RAG |
| ¿Qué puede consultar, calcular o ejecutar? | Tool / integraciones |
| ¿En qué orden debe ocurrir? | Workflow |
| ¿Qué criterio determina la ruta, excepción o escalamiento? | Playbook |
| ¿Qué próximo paso puede seleccionarse dinámicamente? | Agent |
La utilidad de la tabla no está en memorizar equivalencias.
Está en observar que una misma tarea puede fallar por razones diferentes.
Prompt: aporta instrucción
La contribución del prompt consiste en transformar una necesidad en una especificación de trabajo.
En una revisión contractual, por ejemplo:
Identifica cláusulas que permitan al proveedor
suspender o terminar el servicio.
Analiza desde la posición del cliente.
Para cada hallazgo indica:
- cláusula;
- efecto;
- evidencia;
- información faltante.El prompt aporta una respuesta a preguntas como:
- qué operación realizar;
- sobre qué objeto;
- con qué propósito;
- desde qué perspectiva;
- bajo qué restricciones;
- con qué salida.
Su contribución es fundamental porque reduce inferencias innecesarias.
Pero el prompt no crea automáticamente:
- una metodología completa;
- una biblioteca documental;
- acceso a sistemas;
- un proceso institucional;
- criterios de aprobación.
Por eso su límite puede expresarse así:
instruir no equivale a saber hacer todo lo necesario para completar el trabajo.
¿Qué aporta la template?
La template no cambia la naturaleza principal de la instrucción. Añade reutilización y parametrización.
Permite distinguir entre:
estructura estable
+
variables del casoPor ejemplo:
[PARTE]
[TIPO_DE_CONTRATO]
[MATERIAS]
[DOCUMENTOS]
[CRITERIOS]
[FORMATO]Esto reduce variabilidad entre ejecuciones y facilita mantenimiento.
La pregunta de diseño es:
¿Existe una instrucción que necesitamos aplicar repetidamente con cambios previsibles?
Si la respuesta es sí, una template puede ser suficiente.
Si la tarea necesita además una metodología compuesta por pasos, criterios y artefactos reutilizables, entramos en el terreno de la skill.
Skill: aporta metodología
Una skill agrega una propiedad cualitativamente diferente: una forma delimitada de realizar una clase de tarea.
Pensemos en una skill de comparación contractual.
Podría establecer que el sistema debe:
1. identificar las cláusulas comparables;
2. extraer el texto relevante;
3. normalizar diferencias de redacción;
4. distinguir cambios sustantivos de cambios formales;
5. clasificar el efecto jurídico de cada diferencia;
6. señalar evidencia;
7. abstenerse cuando no existe correspondencia suficiente.Aquí la arquitectura ya no depende exclusivamente de que el prompt de cada usuario contenga toda la metodología.
La metodología se vuelve un componente reutilizable.
Esto puede ser especialmente valioso en trabajo jurídico porque muchas tareas no son simples preguntas. Son procedimientos intelectuales.
Una due diligence, una revisión de privacidad, una comparación de contratos o una matriz de riesgos exigen formas de trabajo que pueden estandarizarse al menos parcialmente.
El valor de una skill no está en llamarla “skill”
Lo importante es que exista una unidad delimitada de capacidad:
- con una finalidad reconocible;
- con entradas claras;
- con un procedimiento;
- con una salida esperada;
- con límites.
La implementación concreta puede variar entre plataformas.
La pregunta de diseño es:
¿Necesitamos reutilizar una metodología o basta reutilizar una instrucción?
Knowledge: aporta información
Una metodología sin información pertinente tiene un límite obvio.
Supongamos que la skill de revisión dice:
Compara con la política interna aplicable.La política debe existir y estar disponible.
Knowledge aporta ese universo de información.
Puede incluir:
- contratos modelo;
- políticas internas;
- manuales;
- legislación;
- jurisprudencia;
- precedentes de negociación;
- criterios de negocio;
- antecedentes del proveedor.
La contribución de esta capa puede parecer pasiva, pero es estructural.
Un sistema puede ser técnicamente sofisticado y producir malas respuestas porque trabaja con un universo documental incompleto.
En informática jurídica este problema no es nuevo. La tradición de documentación y recuperación de información jurídica muestra precisamente que convertir Derecho en información accesible y utilizable constituye una dimensión central del trabajo computacional jurídico, distinta de la automatización del razonamiento.
La pregunta de diseño es:
¿La tarea depende de información que no está contenida en la instrucción ni disponible de manera fiable en el contexto actual?
Si la respuesta es sí, necesitamos diseñar knowledge.
RAG: aporta selección contextual de información
Knowledge responde qué información existe.
RAG responde cómo localizar qué información parece pertinente para esta ejecución.
Ésa es su contribución específica.
Supongamos que la organización dispone de:
300 contratos anteriores
50 políticas
20 playbooks
1.000 decisiones internas
10.000 páginas de normativaPoner todo ese material en cada interacción sería ineficiente y podría empeorar la señal.
RAG permite construir un proceso parecido a:
Su aporte, por tanto, no es “conocimiento perfecto”.
Es contextualización dinámica.
La pregunta de diseño es:
¿Tenemos un universo informativo demasiado grande o variable para incorporarlo manualmente en cada tarea?
Tool: aporta acceso, cálculo o acción
Hasta este punto el sistema puede trabajar con instrucciones y conocimiento.
La tool añade una propiedad operativa:
hacer algo fuera de la generación de texto.
Puede ser una operación de lectura:
abrir expediente
buscar documento
consultar base
leer registroPuede ser una operación de transformación:
calcular
convertir
extraer
compararO puede producir un efecto:
crear borrador
actualizar registro
enviar mensaje
programar eventoGoogle utiliza la analogía de las tools como las “manos” del agente. La analogía ayuda porque hace visible el salto desde generar lenguaje hacia interactuar con sistemas externos.
Pero deja de servir si imaginamos que la herramienta tiene voluntad propia. Una tool es una capacidad disponible. Su uso depende de software de orquestación, permisos y decisiones.
La pregunta de diseño es:
¿La tarea necesita información o efectos que no pueden obtenerse solamente mediante el contexto ya disponible?
API, connector y MCP: aportan mecanismos de integración
Tool responde qué capacidad queremos exponer.
API, connector y MCP responden, desde perspectivas distintas, cómo puede conectarse esa capacidad.
No son sinónimos.
Una API define una interfaz de software.
Un connector puede empaquetar o simplificar la integración con un servicio determinado.
MCP proporciona un protocolo para exponer herramientas o recursos mediante una forma estandarizada.
Para el lector no técnico, el punto importante es no confundir arquitectura técnica con función.
Podemos describir una tool de manera útil para el sistema:
buscar_contrato
Finalidad:
localizar el contrato vigente de un proveedor.
Entrada:
identificador del proveedor.
Salida:
documento y metadatos.
Límite:
sólo lectura.El hecho de que por debajo utilice una API o un connector no cambia la función que la herramienta aporta a la tarea.
Workflow: aporta secuencia y estado
Una colección de skills y tools sigue siendo una colección.
El workflow las organiza.
Su contribución principal es introducir:
- orden;
- estados;
- dependencias;
- condiciones de avance;
- responsables;
- puntos de espera;
- cierre.
Por ejemplo:
stateDiagram-v2
[*] --> Recibido
Recibido --> Incompleto: faltan documentos
Incompleto --> Recibido: llegan faltantes
Recibido --> EnRevision: expediente completo
EnRevision --> Escalado: riesgo relevante
EnRevision --> Listo: sin escalamiento
Escalado --> Listo: decisión recibida
Listo --> Cerrado: aprobación registrada
El mismo contrato puede existir físicamente durante todo el proceso.
Lo que cambia es el estado institucional del asunto.
Ésta es una contribución decisiva porque muchos trabajos jurídicos no consisten únicamente en producir una respuesta. Consisten en tramitar un asunto desde un estado inicial hasta un estado final bajo condiciones definidas.
La pregunta de diseño es:
¿Necesitamos gobernar una secuencia de trabajo y saber en qué estado se encuentra el asunto?
Playbook: aporta criterios
Un workflow puede saber que después de la revisión viene una decisión.
Pero no necesariamente sabe qué criterio determina esa decisión.
El playbook introduce:
- umbrales;
- ramas;
- excepciones;
- prioridades;
- reglas de escalamiento.
Ejemplo:
Si no existe tratamiento de datos:
continuar por ruta contractual ordinaria.
Si existe tratamiento de datos:
revisar DPA.
Si existen datos sensibles:
activar revisión especializada.
Si la política de retención excede el estándar:
escalar.
Si existe excepción previamente aprobada:
documentar fundamento y vigencia.La contribución es convertir parte del conocimiento institucional en criterios de conducción del proceso.
Esto tiene una consecuencia importante: un playbook bien diseñado puede reducir variabilidad entre personas, pero también puede institucionalizar un criterio defectuoso.
La pregunta de diseño es:
¿El proceso necesita algo más que orden? ¿Necesita reglas para decidir qué ruta corresponde?
Agent: aporta selección dinámica
Finalmente, el agente agrega una propiedad específica: puede seleccionar dinámicamente entre acciones o próximos pasos permitidos.
Supongamos que el sistema recibe un expediente complejo.
En vez de seguir siempre la misma ruta, puede:
observar qué documentos existen;
detectar qué falta;
seleccionar una skill;
recuperar información;
usar una tool;
evaluar el resultado;
elegir otra acción;
detenerse;
pedir autorización;
continuar.El agente aporta flexibilidad frente a entornos donde no resulta práctico enumerar de antemano todas las secuencias posibles.
Pero esa flexibilidad no debe confundirse con ausencia de reglas.
Una arquitectura gobernada puede establecer:
objetivo permitido
tools permitidas
datos accesibles
acciones prohibidas
acciones que requieren aprobación
criterios de término
criterios de escalamientoLa selección dinámica ocurre dentro de ese espacio.
La pregunta de diseño es:
¿Existe una ventaja real en que el sistema elija el próximo paso según el contexto, o una ruta predefinida sería suficiente y más segura?
Una matriz de diagnóstico
Podemos ahora convertir la arquitectura en una herramienta para depurar sistemas.
| Síntoma | Capa que conviene examinar primero |
|---|---|
| La respuesta interpreta mal el encargo | Prompt |
| Cada usuario formula la misma tarea de forma distinta | Template |
| La ejecución omite pasos metodológicos | Skill |
| Falta información necesaria | Knowledge |
| La información existe pero no aparece en el contexto | RAG |
| El sistema no puede consultar o ejecutar algo necesario | Tool / integración |
| Las etapas ocurren desordenadamente | Workflow |
| Casos similares reciben rutas incompatibles | Playbook |
| El sistema elige mal qué hacer después | Agent / orquestación |
La tabla no pretende afirmar que cada problema tenga una única causa.
En sistemas reales puede haber fallos combinados.
Su utilidad está en impedir que todo se reduzca a una sola explicación:
“el modelo falló”.
El valor puede estar en una capa distinta del modelo
Esta arquitectura también ayuda a evaluar productos.
Dos proveedores pueden usar el mismo modelo subyacente y ofrecer resultados muy diferentes.
¿Por qué?
Porque su diferenciación puede estar en:
- mejores prompts;
- mejores skills;
- mejor knowledge;
- recuperación más precisa;
- herramientas especializadas;
- mejores workflows;
- playbooks desarrollados con expertos;
- controles de mayor calidad.
Para un comprador jurídico esto cambia la pregunta.
En vez de preguntar sólo:
¿Qué modelo usan?
conviene preguntar:
¿Dónde está realmente la especialización del sistema?
Un proveedor puede tener una excelente interfaz, pero un knowledge deficiente.
Otro puede tener un modelo menos nuevo, pero una metodología de revisión muy estable, fuentes curadas y trazabilidad.
La calidad del sistema surge de la combinación.
Capas distintas pueden contener conocimiento distinto
También conviene observar que el “conocimiento” organizacional no vive solamente en la capa llamada knowledge.
Puede estar distribuido.
Un prompt puede contener criterios.
Una skill puede encapsular metodología.
Un playbook puede contener políticas de escalamiento.
Un workflow puede reflejar requisitos procedimentales.
Una tool puede limitar operaciones según permisos.
Esto no elimina la utilidad de separar las capas.
Al contrario: permite preguntar qué clase de conocimiento se codificó dónde.
Podemos distinguir:
Prompt
conocimiento de la tarea actual
Skill
conocimiento metodológico
Knowledge
contenido sustantivo disponible
Workflow
conocimiento procedimental
Playbook
conocimiento decisional
Permisos
conocimiento convertido en restricción operacionalEsta lectura es especialmente importante en Derecho, donde reglas, prácticas, criterios y excepciones pueden terminar incorporados en distintos componentes técnicos sin aparecer como una única “regla jurídica”.
Una misma capacidad puede implementarse de varias maneras
La arquitectura funcional tampoco debe confundirse con una única implementación.
“Comparar contratos” podría implementarse mediante:
- un prompt puntual;
- una skill;
- código determinista;
- una combinación de reglas y modelo;
- un workflow;
- un agente que coordina varias comparaciones.
Por eso el diseño debe comenzar por la función y no por la herramienta de moda.
Una pregunta útil es:
¿Qué propiedad necesito antes de decidir con qué tecnología la implemento?
Primero:
necesito reutilizar metodologíaDespués:
¿cómo la implemento?No al revés.
El principio de suficiencia
Al final de la arquitectura conviene mantener una regla fuerte:
La mejor capa es la menos compleja que resuelve correctamente el problema.
Si una tarea se resuelve con un prompt, no gana valor por convertirla artificialmente en un agente.
Si una ruta es fija, un workflow puede ofrecer más previsibilidad que una selección dinámica.
Si una decisión tiene alto impacto y reglas claras, quizá deba permanecer determinista.
Si una acción es irreversible, puede necesitar autorización humana aunque el sistema sea capaz de ejecutarla.
La arquitectura no es una carrera hacia la autonomía.
Es un catálogo de propiedades que pueden combinarse.
Qué aporta la combinación
Hasta ahora hemos hablado de cada capa por separado.
La propiedad realmente interesante aparece cuando se combinan.
Pensemos en un sistema contractual con:
Prompt
define la misión.
Skill
define cómo revisar.
Knowledge
aporta políticas y precedentes.
RAG
trae lo pertinente.
Tool
consulta sistemas.
Workflow
ordena etapas.
Playbook
determina ramas.
Agent
elige próximos pasos.El resultado no es simplemente la suma de ocho objetos.
Aparecen propiedades emergentes:
- continuidad de trabajo;
- capacidad de reaccionar a faltantes;
- adaptación a distintos casos;
- trazabilidad;
- coordinación entre fuentes y acciones;
- ejecución parcial sin intervención humana en cada microdecisión.
Ésta es la razón por la que al final del curso hablamos de arquitectura.
Las propiedades relevantes dependen de las relaciones entre componentes.
Qué debes recordar
Cada capa responde a una pregunta distinta:
Prompt
¿qué hacer?
Skill
¿cómo hacerlo?
Knowledge
¿con qué información?
RAG
¿qué información traer ahora?
Tool
¿qué puedo consultar o ejecutar?
Workflow
¿en qué secuencia?
Playbook
¿con qué criterio?
Agent
¿qué próximo paso seleccionar?La template añade reutilización.
API, connector y MCP permiten integrar capacidades.
La arquitectura sirve para diseñar, comprar, diagnosticar y gobernar sistemas.
Su regla principal es sencilla:
No añadas una capa si no puedes explicar qué propiedad nueva necesitas.
El problema que todavía queda abierto
Hasta ahora hemos observado el lado constructivo de la arquitectura.
Cada capa resuelve una limitación.
Pero toda nueva propiedad abre también una nueva posibilidad de error.
Reutilizar una instrucción puede reutilizar un defecto.
Encapsular una metodología puede escalar una mala práctica.
Conectar una tool puede transformar un error textual en una acción.
Agregar un agente puede permitir que una decisión equivocada afecte las decisiones siguientes.
La próxima página recorre la misma arquitectura desde la pregunta inversa:
¿Qué riesgo nuevo introduce cada capa y qué tipo de control debe crecer junto con ella?