Inteligencia simbiótica · Parte VI · Capítulo 26
Contratos, cumplimiento y Legal Operations
El contrato es un corte.
El contrato es un corte.
Una relación que podía adoptar varias formas queda organizada en derechos, obligaciones, riesgos, procedimientos y salidas. El texto no agota la relación, pero crea una estructura que orienta su futuro.
Por eso la IA contractual no debería medirse únicamente por la velocidad con la que revisa o redacta documentos.
La pregunta es si ayuda a construir y sostener relaciones más inteligibles desde la negociación hasta el cierre.
Del documento al ciclo de vida
La práctica contractual suele fragmentarse:
- una solicitud entra por correo;
- alguien elige una plantilla;
- varias personas negocian versiones;
- la firma se almacena;
- las obligaciones se trasladan parcialmente a calendarios o a memoria personal;
- los cambios operativos no siempre vuelven al texto;
- y el contrato reaparece cuando hay una renovación, una auditoría o un conflicto.
El documento está gestionado.
La relación no.
Un sistema de capacidad ampliada conecta al menos:
- necesidad empresarial;
- clasificación y riesgo;
- autoridad para negociar;
- posiciones y desviaciones;
- versión y aprobación;
- firma y eficacia;
- obligaciones y dependencias;
- eventos de cambio;
- rendimiento;
- renovación, terminación o transición.
La unidad contractual no termina cuando se guarda el PDF.
La cláusula dentro del sistema
Una cláusula puede ser estándar y producir un riesgo extraordinario por su combinación con otras.
La limitación de responsabilidad depende de garantías, indemnidades, seguros, exclusiones, niveles de servicio, datos y régimen de terminación. La propiedad intelectual depende de materiales previos, desarrollos, configuraciones, datos, artefactos y posibilidades de reutilización. La confidencialidad depende de flujos técnicos y permisos reales.
La revisión por comparación de cláusulas es útil.
Debe completarse con una lectura de dependencias.
La pregunta no es solo «¿se desvía del playbook?», sino «¿qué trayectoria crea esta combinación?».
Servicio, sistema y capacidad
Cuando se contrata una arquitectura humano–IA, tres objetos suelen quedar confundidos:
El servicio
El trabajo de analizar, diseñar, implementar, operar o mantener.
El sistema
La configuración concreta de componentes, integraciones, reglas, datos, memoria y flujos.
La capacidad
Lo que la organización puede sostener gracias a ese sistema: resolver solicitudes, mantener expedientes, producir análisis, operar una función o responder a un campo.
El contrato describe con facilidad entregables y horas. La dependencia real puede recaer sobre la capacidad continuada.
Si el sistema sigue encendido pero pierde consistencia, ¿qué se ha incumplido? Si una herramienta cambia y el equipo reconstruye la función, ¿se ha sustituido el objeto o se ha conservado? Si el criterio reside en el proveedor, ¿qué recibe el cliente al terminar?
Estas preguntas no requieren inventar una nueva categoría jurídica para cada tecnología.
Requieren describir correctamente el objeto, los estados y la continuidad esperada.
Contratar comportamiento en el tiempo
Los sistemas generativos no producen siempre la misma salida ante entradas aparentemente iguales. Sus proveedores actualizan modelos, filtros, límites, precios e interfaces. Los datos y el contexto también cambian.
No basta prometer que «funciona».
El contrato puede necesitar definir:
- funciones críticas;
- métricas y tolerancias;
- conjuntos de prueba;
- frecuencia de evaluación;
- cambios que requieren aviso o aprobación;
- degradación aceptable;
- gestión de incidencias;
- conservación de evidencia;
- y remedios cuando la capacidad cae sin interrupción total.
Se contrata una función dentro de un rango, no una identidad eterna del componente.
Capas de propiedad y control
Hablar de «la propiedad del sistema» suele ocultar objetos distintos:
- datos aportados;
- documentos de cliente;
- modelos de terceros;
- prompts e instrucciones;
- taxonomías;
- reglas de negocio;
- código e integraciones;
- configuraciones;
- evaluaciones;
- memorias y estados;
- outputs;
- correcciones humanas;
- artefactos metodológicos;
- y conocimiento general obtenido durante la prestación.
Cada capa puede tener un régimen diferente de titularidad, licencia, secreto, acceso, portabilidad y reutilización.
Una cláusula total —«todo pertenece al cliente» o «la plataforma conserva toda la tecnología»— puede ser sencilla y operativamente falsa.
La distribución coherente protege la continuidad del cliente y la capacidad legítima del proveedor para seguir trabajando, sin apropiarse de datos, criterio situado o ventajas que no le corresponden.
Dependencia y salida
La dependencia no es necesariamente abusiva. Toda capacidad compleja depende de personas, infraestructuras y conocimiento.
El problema aparece cuando no es visible ni gobernable.
Antes de contratar debe identificarse:
- qué componentes pueden sustituirse;
- qué conocimiento es transferible;
- qué formato permite exportar memoria;
- qué credenciales y dominios controla cada parte;
- qué operación manual de contingencia existe;
- cuánto tiempo requiere migrar;
- quién coopera;
- y qué ocurre con datos, logs, copias y artefactos al salir.
Una relación puede ser estable precisamente porque la salida está diseñada.
La libertad de retirada reduce la necesidad de defensa.
Cumplimiento como estado vivo
El cumplimiento suele representarse mediante políticas, controles y evidencias periódicas. Un sistema conectado permite además mantener una relación continua entre:
- obligación aplicable;
- proceso afectado;
- responsable;
- control;
- evidencia;
- excepción;
- incidente;
- acción correctiva;
- y cambio normativo o técnico.
La IA puede leer nuevas fuentes, detectar diferencias y proponer impactos. No debe decidir por similitud semántica que una norma aplica ni que un control satisface la obligación.
El estado de cumplimiento requiere cortes autorizados:
- aplicable;
- no aplicable con fundamento;
- pendiente de análisis;
- implementado;
- parcialmente implementado;
- no conforme;
- riesgo aceptado por autoridad competente;
- o cerrado con evidencia.
La casilla verde no es cumplimiento.
Es una afirmación que debe poder sostenerse.
Legal Operations como arquitectura de capacidad
Legal Operations no es la administración exterior del trabajo jurídico.
Es la disciplina que hace visible cómo entra una demanda, cómo se prioriza, quién decide, qué recursos consume, qué conocimiento deja y qué resultado produce.
La IA generativa amplía esa función porque puede operar sobre lenguaje no estructurado: correos, contratos, informes, solicitudes y conversaciones. Pero si solo se añade a la entrada, multiplica volumen.
La arquitectura debe conectar:
- intake;
- identificación del expediente o unidad;
- prioridad y riesgo;
- asignación;
- fuentes y contexto;
- producción;
- revisión y aprobación;
- entrega o ejecución;
- estado;
- aprendizaje.
El objetivo no es convertir todo trabajo en ticket.
Es evitar que lo repetible consuma el criterio y que lo singular se pierda dentro del flujo.
Playbooks que aprenden sin deformarse
Un playbook captura posiciones preferidas, alternativas, umbrales y autoridades. La IA permite aplicarlo y detectar desviaciones a gran escala.
También puede degradarlo si incorpora cada acuerdo como nueva regla.
Una concesión aceptada por urgencia no se convierte en estándar. Una cláusula que funcionó en un sector no se exporta sin contexto. Una corrección del profesional puede responder a estilo y no a riesgo.
El aprendizaje requiere clasificar el feedback:
- error del sistema;
- excepción del caso;
- cambio de política;
- mejora generalizable;
- preferencia situada;
- o decisión no transferible.
Solo algunas diferencias deben modificar la memoria estable.
Cumplir no es inmovilizar
El gobierno contractual y regulatorio puede convertirse en fricción defensiva. Se multiplican aprobaciones para que nadie pueda ser acusado, no para mejorar el acto. El sistema conserva formularios y pierde función.
Una forma coherente concentra control donde el efecto lo exige y libera variación donde es reversible.
El Derecho no entra al final para prohibir.
Diseña la trayectoria en la que la capacidad puede existir sin destruir sus condiciones.
Un contrato orientado a capacidad
Cuando el objeto es un sistema en funcionamiento, el contrato puede estructurarse alrededor de doce preguntas.
1. ¿Qué función debe continuar?
Definir la necesidad con resultados, destinatarios y límites; no mediante una lista cerrada de tecnologías.
2. ¿Qué unidad se entrega?
Servicio profesional, licencia, integración, operación gestionada, sistema configurado, capacidad disponible o combinación.
3. ¿Qué permanece bajo control de cada parte?
Datos, identidades, claves, infraestructura, modelos, dominios, criterios, relaciones con terceros y decisiones.
4. ¿Qué comportamiento se espera?
Calidad, disponibilidad, cobertura, latencia, tolerancia, abstención, escalada y recuperación.
5. ¿Cómo se demuestra?
Conjuntos de prueba, muestreo, logs, auditoría, aceptación, indicadores y derecho a impugnar.
6. ¿Quién decide y actúa?
Matriz de autoridad para cambios, excepciones, comunicaciones, compromisos, suspensión y retirada.
7. ¿Cómo cambia?
Versiones, actualizaciones, sustitución de componentes, cambio material, aviso, prueba y derecho de rechazo.
8. ¿Cómo se mantiene?
Monitorización, soporte, corrección, aprendizaje, seguridad y responsabilidades de cada parte.
9. ¿Qué ocurre ante desviación?
Clasificación de incidentes, contención, evidencia, comunicación, remedio, crédito, indemnización o terminación.
10. ¿Qué puede reutilizarse?
Capas de propiedad, licencias, conocimiento general, datos, correcciones y límites de confidencialidad.
11. ¿Cómo se sale?
Transición, exportación, cooperación, formato, plazos, eliminación, continuidad y costes.
12. ¿Quién soporta el residuo?
Riesgos que ninguna parte controla enteramente, límites, seguros y mecanismos de revisión.
Estas preguntas no exigen un contrato gigantesco. Exigen que el texto represente la forma real.
Niveles de servicio y objetivos de sistema
Los SLA clásicos miden disponibilidad o tiempo de respuesta. Un sistema generativo puede estar disponible y producir capacidad degradada.
Conviene distinguir:
- nivel de infraestructura: acceso, latencia, disponibilidad;
- nivel de flujo: ciclos completados, errores de transición, recuperación;
- nivel de calidad: exactitud, cobertura, procedencia, consistencia;
- nivel de gobierno: incidencias, cambios, revisión y evidencia;
- nivel de capacidad: función que la organización puede sostener y coste completo.
No todos los niveles deben contractualizarse como garantía rígida. Algunos pueden funcionar como objetivos de servicio, indicadores, pruebas de aceptación o causas de revisión.
Prometer exactitud absoluta es falso. No definir ningún umbral deja toda desviación dentro de lo esperable.
El contrato necesita un lenguaje para la degradación.
El registro de obligaciones
Tras la firma, cada obligación material puede representarse con:
- sujeto obligado;
- contenido;
- condición de activación;
- plazo o periodicidad;
- dependencia;
- evidencia de cumplimiento;
- consecuencia;
- y autoridad para interpretar o modificar.
La IA puede extraer una primera versión. El equipo confirma qué merece seguimiento. No toda frase contractual se convierte en tarea recurrente; algunas son reglas, facultades, declaraciones, condiciones o remedios.
El registro debe vincularse al documento y a sus modificaciones. Una obligación sin versión puede sobrevivir a una novación que la eliminó.
Cumplimiento continuo y cambio
El motor de obligaciones puede recibir eventos:
- vencimiento;
- cambio normativo;
- modificación de proveedor;
- incidente;
- nueva categoría de datos;
- entrada en otro territorio;
- o superación de umbral.
El evento no decide automáticamente incumplimiento. Abre revisión, solicita evidencia o activa una actuación definida.
La automatización correcta no sentencia antes de interpretar.
Hace comparecer la diferencia ante la función competente.
Cuatro economías ocultas
Al contratar capacidad conviene medir:
Economía de construcción
Diseño, integración, limpieza, pruebas y puesta en marcha.
Economía de operación
Licencias, inferencia, revisión, incidencias, coordinación y mantenimiento.
Economía de cambio
Revalidación, migración, actualización de memoria, formación y adaptación contractual.
Economía de salida
Exportación, transición, duplicidad temporal, pérdida de aprendizaje y reconstrucción.
Una oferta barata puede desplazar coste a las tres últimas. Una solución interna puede ocultar horas y dependencia personal.
La comparación debe imputar recursos que no se facturan.
El contrato como memoria de la relación
Un contrato vivo no es un texto que la IA reescribe continuamente.
Es una relación en la que el texto rector, las decisiones posteriores, los cambios, las evidencias y las obligaciones conservan correspondencia.
La modificación debe cortar. La conversación no debe cambiar el contrato por osmosis salvo que el propio régimen jurídico lo permita y las partes lo pretendan.
La flexibilidad operativa necesita saber qué permanece fijo.
De otro modo, el sistema aprende una práctica y la confunde con el derecho de exigirla.