flowchart TB
R[Resources] --> RET[Retrieval]
RET --> C[Context]
S[Skill] --> C
C --> H[Hallazgos]
H --> COMP[Comparación]
COMP --> E[Evaluación]
E --> V[Verificación]
V --> O[Output]
Caso: skill + estándar interno + precedentes
Aplicación integrada de skills, knowledge, resources, recuperación y RAG a la revisión de una cláusula de limitación de responsabilidad.
Durante las páginas anteriores hemos separado deliberadamente conceptos que en una aplicación real aparecen juntos.
Aprendimos que:
Skill
= cómo realizar la tarea
Knowledge
= qué información puede utilizarse
Resources
= dónde existe esa información
Retrieval
= qué seleccionamos para esta consulta
Context
= qué recibe el modelo ahora
RAG
= recuperar y luego generarAhora podemos reunirlos.
El objetivo no es introducir un concepto nuevo.
Es comprobar si el modelo mental construido permite reconstruir una tarea profesional de principio a fin.
Utilizaremos el caso conductor del handbook:
Llegó un contrato de proveedor de IA. ¿Puede aprobarse?
No intentaremos revisar todo el contrato.
Trabajaremos sobre una única cuestión: limitación de responsabilidad.
Idea central
Una respuesta jurídica útil no debería aparecer como una conclusión aislada.
Queremos poder reconstruir:
metodología
→ información
→ fuentes
→ recuperación
→ evidencia
→ comparación
→ evaluación
→ incertidumbreEl caso muestra cómo cada capa cumple una función distinta.
El contrato nuevo
La empresa está evaluando un servicio SaaS que utilizará modelos de IA para procesar documentos internos.
El contrato contiene:
14.2 Limitación de responsabilidad
Salvo respecto de las obligaciones de pago del Cliente
y de fraude, la responsabilidad total y agregada de cada
Parte relacionada con este Contrato no excederá los montos
efectivamente pagados al Proveedor durante los tres meses
anteriores al evento que origine la reclamación.El abogado recibe una pregunta sencilla:
¿Podemos aceptar esta cláusula?
Podríamos enviar solamente el texto a un modelo y pedir una opinión.
En esta sección haremos algo distinto.
Paso 1. Seleccionar una skill
La primera pregunta no es qué estándar aplicar.
Es:
¿qué capacidad necesitamos?
Utilizamos una skill:
NOMBRE
Evaluar limitación de responsabilidad en contratación tecnológicaCapacidad
Comparar el régimen contractual de responsabilidad
con el estándar aplicable e identificar desviaciones
respaldadas por evidencia.Metodología
1. identificar cap general;
2. identificar base de cálculo;
3. identificar carve-outs;
4. identificar límites especiales;
5. revisar referencias cruzadas;
6. recuperar estándar vigente;
7. comparar cada elemento;
8. recuperar precedentes cuando exista desviación;
9. distinguir estándar de excepción;
10. identificar información faltante;
11. verificar evidencia;
12. producir matriz.Controles
No inventar políticas.
No tratar un precedente como estándar general.
No declarar ausente una excepción si no se ha revisado
el universo contractual necesario.
No emitir aprobación automática cuando exista una regla
de escalamiento.La skill contiene el método.
Todavía no contiene necesariamente los valores concretos de la política.
Paso 2. Determinar qué knowledge necesitamos
La skill obliga a buscar varias piezas.
| Pregunta | Knowledge |
|---|---|
| ¿Cuál es el cap mínimo? | estándar contractual |
| ¿Qué excepciones exige la organización? | estándar / política |
| ¿Quién aprueba desviaciones? | matriz de aprobación |
| ¿Existen antecedentes comparables? | precedentes |
| ¿Fueron excepciones o regla? | historial de aprobación |
Observe lo que ocurre.
La metodología genera necesidades de información.
Eso permite pasar de una pregunta general:
¿podemos aprobar?a consultas concretas.
Paso 3. Identificar resources
Supongamos que el sistema dispone de:
Estándar_Contratación_TI_v3.pdf
Estándar_Contratación_TI_v4.pdf
Matriz_Aprobaciones_v3.pdf
Contrato_ACME_2025.pdf
Acta_Aprobacion_ACME_2025.pdf
Contrato_DELTA_2026.pdf
DPA_Proveedor_Nuevo.pdf
SLA_Proveedor_Nuevo.pdfEstos son resources.
No todos serán pertinentes.
Paso 4. Gobernar las versiones
Los metadatos indican:
Estándar v3
estado = derogado
vigente hasta = 2026-03-31Estándar v4
estado = vigente
vigente desde = 2026-04-01Y contienen reglas diferentes.
Versión 3
Cap mínimo general:
6 meses.Versión 4
Proveedores SaaS críticos:
cap mínimo = 12 meses.Si el retriever encuentra la versión 3 y no conserva vigencia, el análisis puede ser coherente y estar equivocado.
El primer control no ocurre en el modelo.
Ocurre en la gobernanza del knowledge.
Paso 5. Formular necesidades de recuperación
La skill puede transformar el asunto en consultas:
estándar vigente limitación responsabilidad SaaS críticocarve-outs responsabilidad confidencialidad datosprecedentes SaaS crítico cap inferior estándaraprobación desviación cap contractualTambién puede utilizar metadatos:
estado = vigente
tipo = estándar
materia = responsabilidadpara reducir candidatos.
Paso 6. Recuperar el estándar
La búsqueda encuentra varios resultados.
Seleccionamos:
FUENTE
Estándar de Contratación Tecnológica v4
SECCIÓN
8.4
ESTADO
vigente
CONTENIDO
Para servicios SaaS clasificados como críticos,
el límite agregado general de responsabilidad
no deberá ser inferior al equivalente a doce meses
de cargos contractuales.También recuperamos:
FUENTE
Estándar de Contratación Tecnológica v4
SECCIÓN
8.4.2
CONTENIDO
Fraude queda fuera del cap general.
Confidencialidad y determinadas obligaciones
relativas a datos requieren tratamiento específico.Ya tenemos parte del conocimiento necesario.
El ejemplo es ilustrativo
Los nombres de documentos, versiones y umbrales utilizados en este caso son ficticios y sirven únicamente para mostrar la arquitectura de trabajo. No representan políticas reales de una organización concreta.
Paso 7. Recuperar la regla de aprobación
La matriz contiene:
FUENTE
Matriz de Aprobaciones v3
SECCIÓN
3.2
CONTENIDO
Toda desviación material respecto del cap mínimo
debe ser escalada al área Legal y al responsable
de riesgo correspondiente.Ahora sabemos algo distinto.
No solamente existe una desviación potencial.
Existe una regla sobre quién puede aprobarla.
Esto anticipa una distinción que será central más adelante:
capacidad para detectar
≠
autoridad para aprobarPaso 8. Recuperar precedentes
La búsqueda encuentra:
Contrato ACME 2025
cap = 6 mesesUna lectura superficial podría decir:
“Ya existe un precedente de seis meses, por tanto la empresa acepta caps inferiores a doce.”
Pero la skill obliga a comprobar el estatus del precedente.
Recuperamos además:
Acta de aprobación ACME 2025
La desviación a seis meses se aprueba excepcionalmente
atendida la criticidad reducida del componente y las medidas
compensatorias documentadas en el expediente.Ahora la interpretación cambia.
El contrato ACME demuestra:
existió una excepciónNo demuestra:
seis meses = estándarMucho menos:
tres meses = aceptableEste paso muestra por qué recuperar más evidencia puede cambiar el significado de una fuente ya encontrada.
Paso 9. Construir el contexto
Ahora la aplicación puede crear un paquete compacto.
[SKILL]
Metodología de evaluación de responsabilidad.
[TAREA]
Evaluar cláusula 14.2.
[CONTRATO NUEVO]
Cap = 3 meses.
Base = montos efectivamente pagados.
Fraude = fuera del cap.
[ESTÁNDAR VIGENTE]
SaaS crítico = mínimo 12 meses.
[REGLA ESPECIAL]
Confidencialidad y ciertas obligaciones de datos
requieren tratamiento específico.
[APROBACIÓN]
Desviaciones materiales requieren escalamiento.
[PRECEDENTE]
ACME = 6 meses.
[ESTATUS DEL PRECEDENTE]
ACME fue excepción.El modelo no necesita recibir toda la base documental.
Recibe la selección relevante.
Eso es construcción de contexto.
Paso 10. Extraer antes de evaluar
Aplicamos una skill pequeña de extracción.
Resultado:
| Elemento | Contrato nuevo |
|---|---|
| Cap general | 3 meses |
| Base | pagos efectuados |
| Fraude | fuera del cap |
| Confidencialidad | no aparece como carve-out en §14.2 |
| Datos | no aparecen expresamente en §14.2 |
La última columna debe leerse con cuidado.
No hemos demostrado:
“el contrato completo no contiene tratamiento de confidencialidad.”
Sólo sabemos:
“la cláusula 14.2 no lo contiene expresamente.”
Esa diferencia evita una inferencia excesiva.
Paso 11. Comparar
Ahora aplicamos la skill de comparación.
| Dimensión | Contrato | Estándar | Estado |
|---|---|---|---|
| Cap | 3 meses | mínimo 12 meses | desviación |
| Base | pagos efectuados | cargos contractuales | diferencia a revisar |
| Fraude | fuera del cap | fuera del cap | compatible |
| Confidencialidad | no identificada en 14.2 | tratamiento específico | requiere revisión adicional |
| Datos | no identificado en 14.2 | tratamiento específico cuando corresponda | información insuficiente |
La comparación produce un delta.
Todavía no hemos tomado la decisión final.
Paso 12. Evaluar
Ahora podemos aplicar criterios.
Hallazgo 1
Contrato:
3 meses.
Estándar:
12 meses.
Resultado:
desviación material.Hallazgo 2
Fraude:
fuera del cap en ambos.
Resultado:
compatible respecto de este punto.Hallazgo 3
Confidencialidad:
no aparece en la cláusula revisada.
Resultado:
no concluir todavía incumplimiento del estándar.
Acción:
revisar disposiciones relacionadas y anexos.Observe la tercera evaluación.
Una buena arquitectura no sólo produce conclusiones.
También produce estados de insuficiencia.
Paso 13. Interpretar el precedente
La skill debe separar:
POLÍTICA
regla general
PRECEDENTE
lo ocurrido antes
EXCEPCIÓN
desviación autorizadaAplicamos:
ACME 2025
cap = 6 meses
estado = excepciónConclusión:
El precedente muestra que la organización ha aprobado anteriormente una desviación, pero no modifica el estándar general de doce meses.
No podemos inferir:
“Tres meses también son aceptables.”
El precedente aporta contexto negociador.
No reemplaza el criterio vigente.
Paso 14. Verificar
La skill de verificación puede revisar cada afirmación.
| Afirmación | Evidencia | Estado |
|---|---|---|
| El contrato propone 3 meses | §14.2 | verificado |
| El estándar exige 12 meses | estándar v4 §8.4 | verificado |
| ACME fue excepción | acta ACME §4 | verificado |
| El contrato completo no protege confidencialidad | sólo §14.2 revisado | no verificado |
La última fila es especialmente valiosa.
Evita que una ausencia local se transforme en una afirmación global.
Paso 15. Construir el output
Podemos producir una salida de este tipo.
Hallazgo principal
La cláusula 14.2 limita la responsabilidad agregada a los montos pagados durante los tres meses anteriores al evento que origine la reclamación.
Criterio
El estándar vigente recuperado para servicios SaaS críticos establece un cap mínimo equivalente a doce meses de cargos contractuales.
Evaluación
Existe una desviación material respecto del estándar.
Fraude
El contrato excluye fraude del cap general, compatible en este punto con la fuente interna recuperada.
Confidencialidad y datos
La cláusula 14.2 no contiene un carve-out específico. La evidencia revisada no permite todavía concluir que el contrato completo carezca de tratamiento especial. Deben revisarse disposiciones relacionadas y anexos.
Precedentes
Se recuperó un contrato anterior con un cap de seis meses. El acta correspondiente lo identifica como excepción aprobada. Por tanto, no debe tratarse como sustituto del estándar vigente.
Acción procedimental
La desviación requiere el mecanismo de escalamiento indicado en la matriz aplicable.
Información faltante
Debe comprobarse:
- clasificación definitiva de criticidad;
- disposiciones de confidencialidad;
- tratamiento de datos;
- indemnidades;
- anexos que modifiquen responsabilidad.
El resultado es más útil que:
“La cláusula es riesgosa.”
No solamente por su extensión.
Porque permite reconstruir de dónde viene cada parte.
La cadena de evidencia
Podemos representar:
Cada transformación puede ser revisada.
Eso mejora observabilidad.
Qué podría salir mal
Aunque la arquitectura sea mejor, sigue teniendo riesgos.
Falla de resource
El DPA correcto no fue incorporado.
Falla de metadata
El estándar v3 aparece como vigente.
Falla de retrieval
No se recupera el acta de ACME.
Falla de fragmentación
El fragmento contiene el cap pero no la excepción.
Falla de interpretación
El modelo confunde “pagado” con “facturado”.
Falla de evaluación
Una desviación menor se clasifica como material.
Falla de redacción
El output transforma “requiere revisión” en “incumple”.
La arquitectura permite localizar el problema con más precisión.
No elimina los errores.
La responsabilidad profesional sigue fuera del modelo
La ABA, en Formal Opinion 512, destaca que abogados que utilizan IA generativa deben comprender razonablemente capacidades y limitaciones y aplicar un grado apropiado de revisión.
La guía del CCBE desarrolla preocupaciones semejantes respecto de competencia, confidencialidad y confiabilidad.
Para nuestro caso la consecuencia es sencilla:
una arquitectura con evidencia y trazabilidad facilita revisión profesional, pero no sustituye la responsabilidad de quien adopta la decisión.
El sistema puede detectar una desviación.
La organización decide quién está autorizado a aprobarla.
Qué hemos aprendido en toda la sección
Partimos con:
templatey descubrimos su límite.
Construimos:
skillpara estabilizar metodología.
Después separamos:
skill ≠ knowledgeDistinguimos:
context
knowledge
resourcesAprendimos recuperación:
buscar
seleccionar
incorporar
citarY finalmente RAG:
retrieval
+
generationEl caso muestra cómo todas las piezas se integran sin convertirse en sinónimos.
La frontera con la siguiente sección
Todavía hemos supuesto algo importante.
Hemos dicho:
recupera el estándar
recupera el precedente
obtén la matrizPero ¿cómo accede realmente el sistema a esos resources?
Si el estándar está en un DMS:
¿qué mecanismo lo abre?
Si el precedente está en una base:
¿cómo consulta la base?
Si el análisis debe registrarse en un sistema:
¿cómo escribe?
Si debe enviar una notificación:
¿cómo ejecuta esa acción?
La skill sabe qué debería hacerse.
RAG explica cómo información recuperada puede llegar al contexto.
Pero todavía necesitamos medios para interactuar operacionalmente con sistemas externos.
Ahora sabemos hacer; todavía necesitamos poder actuar
Esta sección construyó capacidad metodológica e informacional.
La siguiente añadirá capacidad operacional.
Aparecen entonces:
tools → APIs → connectors → MCP.
Qué debes recordar
Una arquitectura profesional puede separar:
SKILL
cómo hacer
KNOWLEDGE
qué información existe
RESOURCES
dónde está
RETRIEVAL
qué recuperar
CONTEXT
qué recibe el modelo
RAG
cómo generar con lo recuperado
VERIFICACIÓN
qué está realmente respaldadoEl valor de la separación no es terminológico.
Es operacional.
Permite saber qué componente produjo una conclusión, qué información utilizó y qué problema debemos corregir cuando algo falla.