flowchart TD
A[Admisión completa] --> B{Criticidad}
B -- Baja --> C[Ruta abreviada]
B -- Media --> D[Ruta estándar]
B -- Alta --> E[Ruta reforzada]
E --> F[Legal]
E --> G[Privacidad]
E --> H[Seguridad]
E --> I[Continuidad]
Playbook jurídico
Cómo convertir la revisión de un proveedor tecnológico en una práctica completa: admisión, criticidad, documentación, riesgos, negociación, aprobación y registro.
Ya conocemos la lógica del playbook.
Sabemos que no es una checklist ampliada ni un workflow con otro nombre. Es una guía operativa que utiliza criterios, ramas, umbrales, excepciones, fallbacks y escalamiento para orientar una práctica recurrente.
Ahora corresponde integrar esas piezas en un caso jurídico completo.
Retomaremos el caso conductor del curso:
Ha llegado un contrato nuevo de un proveedor tecnológico. Revísalo y prepara el proceso interno necesario para decidir si puede aprobarse.
La pregunta parece contractual, pero en realidad exige mucho más que leer cláusulas.
Antes de decidir necesitamos saber qué se está contratando, qué tan crítico es el servicio, qué documentos deberían existir, qué riesgos importan, qué posiciones pueden negociarse, quién tiene autoridad para aprobar y qué evidencia debe quedar después.
Por eso el material del curso organiza un playbook mínimo de contratación tecnológica en siete módulos:
Admisión
↓
Criticidad
↓
Documentación
↓
Riesgos
↓
Negociación
↓
Aprobación
↓
Registro
Idea central
El playbook jurídico transforma una revisión documental en un proceso de decisión.
No pregunta solamente:
“¿Qué dice el contrato?”
Pregunta también:
¿Qué asunto tenemos delante, qué ruta corresponde, qué evidencia falta, qué desviaciones importan, qué puede negociarse, quién puede aceptar el resultado y qué debe quedar registrado?
El playbook no es una norma universal de contratación
Antes de entrar al detalle debemos fijar una frontera.
La estructura que sigue es un modelo pedagógico.
No pretende afirmar que toda empresa, estudio jurídico o institución pública deba utilizar exactamente estas etapas ni estos criterios.
Una organización puede tener:
- otras funciones internas;
- umbrales distintos;
- categorías de proveedores propias;
- exigencias regulatorias sectoriales;
- políticas de seguridad específicas;
- procedimientos de procurement diferentes.
El valor de esta arquitectura es mostrar cómo se convierte conocimiento jurídico y organizacional en una práctica gobernable.
Una vista general
| Módulo | Pregunta central | Resultado esperado |
|---|---|---|
| Admisión | ¿Qué se contrata y para qué? | expediente correctamente identificado |
| Criticidad | ¿Qué intensidad de revisión requiere? | ruta aplicable |
| Documentación | ¿Tenemos información suficiente? | expediente documental completo o faltantes explícitos |
| Riesgos | ¿Qué desviaciones importan? | matriz verificable de hallazgos |
| Negociación | ¿Qué posición y fallback corresponde? | puntos resueltos, pendientes o escalados |
| Aprobación | ¿Quién puede aceptar el resultado? | decisión autorizada |
| Registro | ¿Qué debe conservarse? | cierre trazable |
Cada módulo produce información que alimenta al siguiente.
1. Admisión: entender qué asunto llegó
La primera tentación frente a un contrato nuevo es abrirlo y comenzar a comentar cláusulas.
Eso puede ser prematuro.
Un documento no explica necesariamente toda la contratación.
Podemos tener un contrato de servicios cuyo texto no permite saber con claridad:
- qué producto concreto se adquirirá;
- qué usuarios lo utilizarán;
- qué proceso de negocio soportará;
- qué datos recibirá;
- con qué sistemas se integrará;
- qué dependencia operativa generará;
- qué anexos forman parte del acuerdo.
La admisión intenta resolver ese problema antes de evaluar en profundidad.
Pregunta central
¿Qué se está contratando y para qué proceso de negocio?
Esta formulación aparece expresamente en Clases UDD.pdf.
La pregunta es importante porque la misma cláusula puede tener consecuencias distintas según el uso real del servicio.
Información mínima de admisión
Una ficha podría contener:
Proveedor:
Acme AI Ltd.
Servicio:
plataforma SaaS de análisis documental
Área solicitante:
Operaciones
Finalidad:
clasificar y resumir documentación interna
Usuarios:
equipo de operaciones
Datos previstos:
documentos corporativos y potencial información de clientes
Integraciones:
repositorio documental interno
Países / ubicaciones relevantes:
por confirmar
Documentos recibidos:
contrato principal + SLA
Documentos faltantes identificados inicialmente:
DPA + antecedentes de seguridadLa ficha no decide si el proveedor es aceptable.
Su función es construir un objeto de análisis suficientemente definido.
No mezclar descripción del servicio con evaluación
En admisión deberíamos distinguir:
HECHO DECLARADO
El proveedor ofrece una plataforma SaaS.
CONTEXTO
El área pretende usarla para documentos de clientes.
INFERENCIA
El servicio probablemente requerirá revisión de privacidad.
DECISIÓN
todavía no adoptadaEsta separación evita que una conclusión preliminar se transforme silenciosamente en hecho.
El origen de cada dato importa
Podemos mejorar la ficha:
| Campo | Valor | Fuente |
|---|---|---|
| Servicio | SaaS de análisis documental | propuesta comercial |
| Finalidad | clasificación interna | formulario solicitante |
| Datos | posible información de clientes | área de negocio |
| Subprocesadores | no identificados | información faltante |
| SLA | 99,5 % | anexo contractual |
Esta estructura hace visible la procedencia.
Una aplicación puede incluso distinguir entre:
confirmado por documento
informado por solicitante
inferido
no disponibleLa admisión termina cuando sabemos suficientemente qué caso tenemos delante para poder clasificarlo.
Error frecuente: el nombre comercial como sustituto del objeto
“Copilot”, “asistente jurídico”, “plataforma de IA” o “herramienta SaaS” no describen por sí solos la prestación.
Necesitamos saber qué hará realmente dentro de la organización.
Una herramienta genérica utilizada sólo para textos públicos puede tener una ruta distinta de la misma herramienta conectada a expedientes confidenciales.
El playbook trabaja sobre el uso concreto, no sólo sobre la marca.
2. Criticidad: decidir qué intensidad de proceso corresponde
Una vez comprendido el objeto, podemos preguntar:
¿Afecta una operación esencial, clientes, datos o continuidad?
Ésta es la pregunta central de criticidad utilizada en el curso.
El objetivo no es asignar una etiqueta decorativa.
La criticidad debe modificar la ruta.
Qué puede aumentar criticidad
Dependiendo de la organización, pueden ser relevantes:
- importancia del proceso soportado;
- número de usuarios;
- impacto sobre clientes;
- tipo y sensibilidad de información;
- acceso a sistemas internos;
- dependencia del proveedor;
- dificultad de sustitución;
- consecuencias de indisponibilidad;
- consecuencias de una salida incorrecta;
- exposición económica o reputacional.
No necesitamos transformarlos todos en números.
Podemos utilizar categorías:
BAJA
MEDIA
ALTAsi cada una tiene consecuencias claras.
La clasificación debe activar rutas
Por ejemplo:
Si los tres niveles producen exactamente las mismas revisiones, probablemente la clasificación no aporta suficiente valor.
Caso A y caso B
El material del curso contrasta dos escenarios especialmente útiles.
Caso A: software menor
sin datos sensibles
+
bajo gasto
+
baja dependenciaPuede seguir una revisión abreviada y aprobación legal estándar.
Caso B: proveedor SaaS
datos personales
+
servicio críticoPuede activar DPA, SLA, revisión de privacidad, seguridad y otras comprobaciones.
El punto no es que esas rutas sean universales.
El punto es que la criticidad debe tener consecuencias de proceso.
Evitar la falsa precisión
Podemos utilizar un score si la organización tiene una metodología clara.
Pero un número como:
criticidad = 8,3no explica por sí solo por qué el caso es crítico.
Una clasificación útil debe permitir reconstruir los factores relevantes.
Por ejemplo:
criticidad alta porque:
- servicio soporta función operativa diaria;
- contiene datos de clientes;
- no existe reemplazo inmediato;
- indisponibilidad superior a 24 h tendría impacto material.Esto mejora revisión y escalamiento.
3. Documentación: determinar si existe base suficiente para evaluar
Una vez definida la ruta podemos saber qué documentos deberían estar presentes.
La pregunta del curso es:
¿Están contrato, anexos, DPA, SLA, seguridad y órdenes?
La lista concreta variará según el caso.
Lo importante es que el playbook pueda distinguir entre:
documentos recibidos
+
documentos requeridos
+
documentos faltantesNo todo proveedor necesita el mismo paquete documental
Por ejemplo:
RUTA ABREVIADA
contrato + orden + antecedentes básicosmientras:
RUTA CON DATOS PERSONALES
contrato + DPA + subprocesadores + información de tratamientoY:
RUTA CRÍTICA
contrato + DPA + SLA + seguridad + continuidad + soporte + salidaLa documentación depende de la ruta.
Eso evita pedir materiales irrelevantes a todos los proveedores y, al mismo tiempo, evita avanzar sin evidencia cuando el caso la necesita.
Documento presente no equivale a documento suficiente
Supongamos que existe un archivo llamado:
Security_Overview.pdfEso no significa automáticamente que responda las preguntas relevantes.
Podemos necesitar verificar:
- fecha;
- alcance;
- producto al que se refiere;
- versión;
- entidad cubierta;
- si existe evidencia complementaria.
La comprobación documental no es simplemente contar archivos.
Estados de documentación
Podemos utilizar:
COMPLETA
INCOMPLETA
EN VALIDACIÓN
PENDIENTE DE PROVEEDOR
NO APLICAEl estado permite impedir que un expediente avance silenciosamente.
Por ejemplo:
SI DPA obligatorio = faltante
→ estado PENDIENTE_DE_DOCUMENTACIÓN
→ no habilitar aprobación finalLa capacidad de detenerse es parte del control.
Información insuficiente como resultado legítimo
Una mala implementación puede sentir presión por “dar una respuesta” siempre.
Pero un playbook profesional debe permitir:
NO HAY BASE SUFICIENTE PARA CONCLUIRPor ejemplo:
No se puede evaluar la reutilización de datos porque la documentación contractual remite a una política no proporcionada.
Eso es mejor que completar el vacío mediante inferencia no respaldada.
4. Riesgos: convertir documentos en hallazgos verificables
Una vez que comprendemos el servicio y contamos con los antecedentes necesarios podemos ejecutar las revisiones sustantivas.
Aquí entran skills que ya fueron desarrolladas en etapas anteriores del handbook.
Por ejemplo:
- responsabilidad;
- datos personales;
- propiedad intelectual;
- confidencialidad;
- continuidad;
- terminación;
- SLA;
- cambios del servicio.
El playbook no reemplaza esas skills.
Decide cuándo utilizarlas y qué hacer con sus resultados.
La pregunta central
¿Qué desviaciones superan el umbral relevante?
La palabra “desviación” es importante.
No todo hallazgo es necesariamente un problema.
Podemos encontrar:
cláusula dentro del estándar
cláusula dentro del fallback
cláusula fuera del fallback
información faltante
contradicción entre documentosCada categoría puede producir una ruta distinta.
Una matriz verificable
Una salida robusta podría contener:
| Campo | Función |
|---|---|
| Documento | identificar fuente |
| Cláusula | localizar evidencia |
| Texto relevante | permitir verificación |
| Hallazgo | describir qué ocurre |
| Criterio | mostrar contra qué se evalúa |
| Evaluación | explicar impacto |
| Estado | estándar / fallback / excepción / falta información |
| Acción | aceptar / preguntar / negociar / escalar |
Ejemplo:
| Documento | Cláusula | Hallazgo | Criterio | Estado | Acción |
|---|---|---|---|---|---|
| Contrato | 12.4 | cap inferior al estándar | playbook responsabilidad | fuera de fallback | escalar |
| DPA | 5.2 | subprocesadores con aviso | estándar interno | dentro de fallback | registrar |
| SLA | 3.1 | disponibilidad 99,5 % | requisito servicio crítico | desviación | negociar |
La forma estructurada no garantiza que la evaluación sea correcta.
Pero permite revisarla.
Separar evidencia e inferencia
Un hallazgo debería poder distinguir:
TEXTO
qué dice el contrato
INFERENCIA
qué conclusión extraemos
CRITERIO
qué estándar aplicamos
DECISIÓN
qué hacemos con elloÉsta es una de las maneras más importantes de mantener trazabilidad en un sistema jurídico asistido por IA.
Priorizar no significa ocultar
Puede ser útil mostrar cinco riesgos principales.
Pero la priorización no debería eliminar automáticamente hallazgos menores que puedan tener importancia acumulativa o documental.
Una estrategia es separar:
PRIORIDADES PARA DECISIÓN
+
ANEXO COMPLETO DE HALLAZGOSLa interfaz ejecutiva y la evidencia completa cumplen funciones diferentes.
5. Negociación: transformar hallazgos en posiciones
Una revisión que detecta problemas todavía no ha resuelto la contratación.
Necesitamos decidir qué posición adoptar.
La pregunta del curso es:
¿Qué fallback o pregunta enviar al proveedor?
Esto convierte el playbook en una guía de negociación.
Posición preferida, fallback y escalamiento
Podemos modelar:
flowchart TD
A[Desviación] --> B[Proponer posición preferida]
B --> C{¿Proveedor acepta?}
C -- Sí --> D[Cerrar punto]
C -- No --> E{¿Existe fallback autorizado?}
E -- Sí --> F[Proponer fallback]
F --> G{¿Proveedor acepta?}
G -- Sí --> H[Registrar fallback]
G -- No --> I[Escalar]
E -- No --> I
Esta arquitectura representa algo que los equipos jurídicos hacen constantemente de manera informal.
Por ejemplo:
“Pedimos A. Si no, B. Si tampoco, hay que hablar con el socio.”
El playbook convierte esa práctica en una ruta explícita.
Una negociación no es sólo redacción
El fallback puede consistir en:
- texto alternativo;
- control compensatorio;
- limitación del alcance;
- evidencia adicional;
- reducción de datos;
- seguro;
- derecho de salida;
- aprobación excepcional.
Por ejemplo:
PROBLEMA
proveedor no acepta obligación contractual de retención de 30 días
FALLBACK
exportación automática al repositorio del cliente cada 24 horasAquí la solución no es únicamente jurídica. Es sociotécnica.
El playbook puede combinar controles contractuales, técnicos y organizacionales.
Preguntar antes de negociar
No toda ambigüedad requiere una redline inmediata.
Por ejemplo:
“Usage Data” no está claramente definido.El primer paso puede ser:
preguntar qué información incluyeantes de decidir si existe un riesgo contractual.
El playbook puede distinguir:
PREGUNTA
cuando falta información
NEGOCIACIÓN
cuando conocemos la posición pero queremos modificarla
ESCALAMIENTO
cuando no podemos resolver dentro del rango autorizadoEsto evita convertir cada incertidumbre en conflicto contractual.
6. Aprobación: quién puede aceptar el resultado
Después de revisar y negociar todavía necesitamos una decisión institucional.
La pregunta del curso es:
¿Quién aprueba y con qué evidencia?
Esta formulación contiene dos elementos inseparables.
Quién
La persona o rol con autoridad suficiente.
Con qué evidencia
El conjunto mínimo que permite comprender qué se está aceptando.
Una arquitectura de aprobación por nivel
Por ejemplo:
SIN DESVIACIONES MATERIALES
→ aprobación ordinaria
FALLBACK AUTORIZADO
→ aprobación ordinaria + registro
EXCEPCIÓN FUERA DE PLAYBOOK
→ aprobación superior
RIESGO NO ACEPTABLE
→ no aprobarLa distribución concreta dependerá de la organización.
La lógica es que la autoridad debe escalar con la excepción.
El sistema puede preparar; la persona puede decidir
Una aplicación podría mostrar:
RESUMEN DEL EXPEDIENTE
Proveedor: Acme AI
Criticidad: alta
Documentación: completa
Hallazgos: 8
Dentro de estándar: 5
Fallbacks utilizados: 2
Excepciones: 1
Puntos pendientes: 0
DECISIÓN SOLICITADA
Aceptar excepción de liability cap.
EVIDENCIA
[ver cláusula]
[ver estándar]
[ver negociación]
[ver informe de riesgo]La arquitectura reduce la carga de reconstruir todo el expediente.
Pero la existencia de una recomendación automática no convierte al sistema en autoridad aprobadora.
Aprobación y firma no son exactamente lo mismo
Puede existir:
aprobación interna
↓
negociación final
↓
firmaO:
aprobación de excepción
↓
continuar negociaciónEl playbook debe identificar qué acto se está aprobando.
“APROBADO” puede ser demasiado ambiguo si no sabemos:
- qué versión;
- qué excepción;
- qué alcance;
- qué siguiente acción habilita.
7. Registro: convertir la decisión en evidencia organizacional
El proceso no termina simplemente cuando alguien dice “sí”.
El último módulo responde:
¿Qué debe quedar registrado para que la decisión pueda reconstruirse?
La respuesta puede incluir:
identificación del proveedor
servicio contratado
criticidad
versión contractual final
documentos revisados
matriz final
excepciones
fallbacks
aprobaciones
responsables
fecha
obligaciones futurasLa cantidad dependerá del caso.
La regla general es:
una decisión importante debería poder reconstruirse posteriormente con un esfuerzo razonable.
Versión y responsable son esenciales
Supongamos que seis meses después aparece una disputa.
Preguntamos:
¿Qué contrato fue aprobado?Si el expediente contiene cuatro versiones y no sabemos cuál fue la final, la aprobación pierde trazabilidad.
O:
¿Quién aceptó esta excepción?Si sólo existe un correo informal sin vinculación con el expediente, reconstruir la decisión puede ser difícil.
Por eso el material del curso insiste en guardar matriz, versión y responsable.
El registro también mira hacia el futuro
Un contrato aprobado puede crear obligaciones posteriores:
- renovación;
- auditoría;
- revisión de subprocesadores;
- actualización de seguros;
- revisión de seguridad;
- aviso de terminación;
- exportación de datos.
Cerrar correctamente puede requerir convertir esas obligaciones en tareas futuras.
Por ejemplo:
renovación automática en 12 meses
→ crear alerta 90 días antesO:
certificación de seguridad anual
→ asignar revisión periódicaEl registro no es solamente archivo histórico. Puede alimentar nuevos procesos.
El playbook completo
Podemos reunir los siete módulos:
flowchart TD
A[Admisión] --> B{¿Caso identificado?}
B -- No --> A1[Solicitar contexto]
A1 --> A
B -- Sí --> C[Criticidad]
C --> D[Seleccionar ruta]
D --> E[Documentación]
E --> F{¿Suficiente?}
F -- No --> G[Solicitar antecedentes]
G --> E
F -- Sí --> H[Riesgos]
H --> I[Negociación]
I --> J{¿Dentro de estándar o fallback?}
J -- Sí --> K[Aprobación ordinaria]
J -- No --> L[Escalamiento]
L --> M[Decisión de excepción]
M --> K
K --> N[Registro]
N --> O[Cierre]
La ruta no pretende cubrir toda contratación imaginable.
Su utilidad está en mostrar cómo cada módulo modifica el siguiente.
Una ejecución completa: proveedor SaaS crítico con datos personales
Veamos el playbook en acción.
Paso 1. Admisión
Llega una solicitud para contratar una plataforma SaaS con funciones de IA.
El área indica que se utilizará para analizar documentación de clientes.
Se crea el expediente:
ESTADO
RECIBIDOLa ficha inicial identifica:
servicio = SaaS
uso = análisis documental
datos personales = probable
integración = repositorio internoPaso 2. Criticidad
El servicio será utilizado diariamente y tendrá acceso a información de clientes.
Además, el equipo no dispone de un sustituto inmediato.
El playbook clasifica:
CRITICIDAD
ALTAConsecuencia:
activar Legal + Privacidad + Seguridad + ContinuidadPaso 3. Documentación
Se revisa el expediente.
Disponible:
contrato
SLA
propuesta comercialFaltante:
DPA
lista de subprocesadores
documentación de seguridadEl caso pasa a:
PENDIENTE_DE_DOCUMENTACIÓNNo se solicita aprobación todavía.
Paso 4. Reanudación
El proveedor entrega los antecedentes.
Se comprueba versión y alcance.
El estado cambia a:
EN_REVISIÓNPaso 5. Riesgos
Las skills correspondientes analizan:
- datos;
- seguridad;
- SLA;
- responsabilidad;
- terminación;
- continuidad.
La matriz identifica:
5 puntos dentro de estándar
2 desviaciones dentro de fallback
1 desviación fuera de fallback
1 pregunta documental abiertaNo se comprime todo a:
RIESGO ALTOCada punto conserva evidencia.
Paso 6. Pregunta al proveedor
La incertidumbre se refiere a la definición de Usage Data.
Antes de negociar se formula una pregunta.
El proveedor responde.
La respuesta permite cerrar ese punto.
Paso 7. Negociación
Para una desviación se propone la posición preferida.
El proveedor la rechaza.
El fallback está autorizado para esta categoría y se acepta.
Para la desviación fuera de fallback, el equipo no tiene autoridad suficiente.
Se escala.
Paso 8. Escalamiento
El decisor recibe:
texto contractual
estándar interno
posición preferida
fallback intentado
respuesta del proveedor
impacto operacional
recomendación del equipoLa excepción es aprobada bajo una condición compensatoria.
El resultado vuelve a la negociación.
Paso 9. Aprobación
La matriz final muestra:
documentación = completa
revisiones = completas
puntos abiertos = 0
fallbacks = 2
excepción aprobada = 1La persona competente aprueba la contratación.
Paso 10. Registro
Se conservan:
contrato final
DPA
SLA
documentación de seguridad
matriz
aprobación de excepción
responsable
fechaAdemás se crea una revisión futura de subprocesadores.
Estado final:
CERRADOQué ganó la organización
Comparemos este recorrido con un encargo simple:
Revisa este contrato y dime si puede aprobarse.El modelo podría producir una buena respuesta.
Pero el playbook resolvió preguntas que una respuesta aislada no resuelve:
¿qué servicio es?
¿qué ruta corresponde?
¿qué documentos faltan?
¿qué criterios se aplican?
¿qué posiciones son aceptables?
¿qué requiere escalamiento?
¿quién puede aprobar?
¿qué versión queda registrada?La diferencia es pasar de análisis documental a decisión institucional trazable.
El playbook como puente entre conocimiento y proceso
El playbook conecta varias capas del sistema que ya conocemos.
KNOWLEDGE
aporta políticas y estándares
SKILLS
ejecutan metodologías concretas
TOOLS
permiten buscar, leer, escribir o registrar
WORKFLOW
ordena estados y pasos
PLAYBOOK
orienta qué ruta y estrategia aplicarNinguna capa sustituye a las otras.
El diseño gana claridad cuando cada una mantiene una función delimitada.
Playbook no equivale a agente
Ésta es la frontera con la siguiente etapa del recorrido.
En nuestro playbook, las rutas principales fueron diseñadas de antemano.
Sabemos:
si datos personales → privacidad
si servicio crítico → seguridad
si falta DPA → detener
si desviación dentro de fallback → continuar
si supera fallback → escalarEl sistema puede incluso ejecutar automáticamente muchas de estas reglas.
Eso no significa necesariamente que esté decidiendo libremente cómo trabajar.
La arquitectura sigue siendo principalmente predefinida.
Más adelante estudiaremos sistemas capaces de seleccionar dinámicamente qué acción realizar, qué tool utilizar o qué ruta seguir dentro de límites.
Por ahora debemos conservar:
PLAYBOOK
codifica rutas conocidas
AGENT
puede seleccionar dinámicamente próximos pasos dentro de una arquitectura gobernadaUn buen playbook sabe también cuándo no sabe
La calidad no depende de cubrir todos los casos.
Debe existir una ruta como:
CASO FUERA DE PLAYBOOK
→ detener
→ reunir evidencia
→ escalar a responsableEsto es especialmente importante en Derecho.
Un caso novedoso no debería ser forzado artificialmente dentro de una categoría sólo para permitir que el proceso continúe.
Playbook y cambio organizacional
Los criterios internos pueden cambiar.
Por ejemplo:
- nuevo umbral económico;
- nueva política de datos;
- nuevo proveedor de modelo permitido;
- nueva posición de liability;
- nueva exigencia de seguridad;
- nuevo responsable de aprobación.
Si el playbook se utiliza operativamente, necesita mantenimiento.
Debe ser posible saber:
qué versión está vigente
quién la aprobó
cuándo cambió
qué regla fue modificadaNo necesitamos desarrollar todavía un sistema completo de governance.
Pero una práctica codificada y desactualizada puede producir errores consistentes a gran escala.
Qué puede salir mal
1. Comenzar por cláusulas sin comprender el servicio
La admisión existe precisamente para evitarlo.
2. Clasificar criticidad sin consecuencias
Una etiqueta que no modifica ruta ni controles aporta poco.
3. Tratar presencia documental como suficiencia
Un PDF con un nombre correcto puede estar desactualizado o referirse a otro producto.
4. Mezclar hallazgo con decisión
Detectar una desviación no significa automáticamente rechazarla.
5. No distinguir pregunta, negociación y escalamiento
Una falta de información no siempre exige una redline.
6. Utilizar el fallback como posición inicial
Si la alternativa se vuelve el punto de partida, la jerarquía del playbook se pierde.
7. Aprobar sin saber qué versión
La autoridad debe referirse a un objeto identificable.
8. Cerrar sin registro
Una decisión no trazable genera deuda futura.
9. Convertir el playbook en regla universal
Los casos fuera de alcance necesitan abstención y escalamiento.
10. Ejecutar una versión desactualizada
Los criterios deben tener mantenimiento y vigencia.
Qué debes recordar
El playbook jurídico utilizado en este curso contiene siete módulos.
Admisión
¿Qué se contrata y para qué proceso de negocio?
Criticidad
¿Qué intensidad de revisión necesita?
Documentación
¿Existe evidencia suficiente para evaluar?
Riesgos
¿Qué desviaciones superan los criterios o umbrales?
Negociación
¿Qué posición, pregunta o fallback corresponde?
Aprobación
¿Quién puede aceptar el resultado y con qué evidencia?
Registro
¿Qué debe quedar para reconstruir la decisión?
La secuencia completa convierte capacidades técnicas y conocimiento jurídico en una práctica organizada.
Dónde estamos en el recorrido
Podemos reconstruir ahora todo el nivel ORGANIZAR EL TRABAJO.
flowchart TD
A[Acciones aisladas] --> B[Tareas, secuencias y estados]
B --> C[Workflow]
C --> D[Tipos de workflow]
D --> E[Human-in-the-loop]
E --> F[Checklist → procedimiento → playbook]
F --> G[Componentes del playbook]
G --> H[Playbook jurídico]
Y podemos conectarlo con lo aprendido antes:
SKILL
hace bien una tarea
TOOL
permite actuar
WORKFLOW
ordena el trabajo
PLAYBOOK
orienta la ruta según el casoYa podemos organizar procesos jurídicos complejos con bastante precisión.
El problema que todavía queda abierto
Existe, sin embargo, una limitación deliberada.
El playbook funciona especialmente bien cuando conocemos de antemano las variantes relevantes.
Podemos escribir:
si A → ruta 1
si B → ruta 2
si C → escalarPero imaginemos ahora una instrucción más abierta:
“Prepara una decisión sobre este proveedor. Determina qué antecedentes necesitas, qué capacidades debes utilizar y cómo avanzar a medida que descubras nueva información.”
Ya no estamos describiendo solamente una ruta previamente codificada.
Aparece una pregunta nueva:
¿Qué ocurre cuando el sistema debe seleccionar durante la ejecución cuál debería ser el siguiente paso?
Hasta aquí aprendimos a organizar el trabajo.
El siguiente nivel comienza cuando estudiamos cómo un sistema puede decidir cómo trabajar dentro de límites.
Ésa es la puerta de entrada a los agentes.