Del checklist al playbook
Los abogados llevan mucho tiempo utilizando listas de revisión.
Antes de firmar un contrato podemos comprobar:
SLA
confidencialidad
datos personales
propiedad intelectual
responsabilidad
terminación
continuidadLa lista es útil. Reduce olvidos. Permite distribuir trabajo. Ayuda a estandarizar una revisión.
Pero imaginemos que efectivamente encontramos una desviación en la cláusula de responsabilidad.
La checklist puede decirnos:
☑ responsabilidad revisadaTodavía no sabemos:
¿la desviación es material?, ¿debemos negociar?, ¿qué posición debemos proponer?, ¿existe una alternativa aceptable?, ¿quién puede aprobarla?, ¿qué ocurre si el proveedor rechaza también esa alternativa?
Aquí aparece una limitación importante.
Una lista puede decir qué mirar sin decir qué hacer con lo que encontramos.
El workflow que estudiamos anteriormente añade orden y condiciones de avance. Pero incluso un workflow bien diseñado puede necesitar criterios profesionales para tratar variantes del caso.
Ese salto conduce al playbook.
Podemos pensar una progresión:
CHECKLIST
¿qué no debo olvidar?
↓
PROCEDIMIENTO
¿cómo se realiza normalmente el trabajo?
↓
PLAYBOOK
¿qué estrategia y ruta aplicamos según las características del caso?Cada nivel conserva valor. El siguiente no vuelve inútil al anterior.
Por qué no basta con una lista larga
Supongamos una checklist de contratación tecnológica con cuarenta puntos.
Incluye:
- niveles de servicio;
- confidencialidad;
- privacidad;
- seguridad;
- propiedad intelectual;
- subcontratación;
- garantías;
- responsabilidad;
- terminación;
- transición;
- auditoría.
La lista puede ser excelente para asegurar cobertura.
Pero si simplemente indica:
□ revisar limitación de responsabilidadno responde:
¿qué posición es preferida?
¿qué desviación es aceptable?
¿qué alternativa existe?
¿cuándo escalar?Podríamos intentar solucionar el problema agregando más casillas:
□ revisar cap
□ revisar carve-outs
□ revisar daños indirectos
□ revisar indemnidades
□ revisar super-capEso mejora la granularidad.
Pero sigue siendo, esencialmente, una lista de elementos por comprobar.
La dificultad no es cuántos puntos contiene.
La dificultad es que todavía no representa suficientemente la lógica de respuesta frente a distintos escenarios.
1. Checklist: recordar qué debe comprobarse
Una checklist es una lista de elementos, verificaciones o tareas que ayuda a reducir omisiones.
En trabajo jurídico tiene enorme utilidad.
Por ejemplo, para revisar un proveedor SaaS podemos utilizar:
□ identificar servicio contratado
□ revisar SLA
□ revisar DPA
□ revisar subprocesadores
□ revisar seguridad
□ revisar propiedad intelectual
□ revisar responsabilidad
□ revisar terminación
□ revisar salida y portabilidadLa pregunta principal es:
¿Revisamos todo lo que debíamos revisar?
La checklist funciona especialmente bien para cobertura
Es útil cuando el riesgo principal es olvidar un punto.
Por ejemplo:
¿Existe cláusula de confidencialidad?
¿Existe mecanismo de terminación?
¿Existe documentación de seguridad?La respuesta puede ser relativamente binaria.
También puede ayudar a estructurar evidencia
Podemos mejorarla:
| Punto | Estado | Evidencia | Observación |
|---|---|---|---|
| DPA | presente | anexo 3 | revisar transferencias |
| SLA | presente | anexo 2 | disponibilidad inferior al estándar |
| Seguridad | faltante | — | solicitar |
Ahora la checklist no sólo recuerda. También documenta.
Eso es valioso.
Pero todavía no ha resuelto qué ruta seguir cuando un punto produce una excepción.
Checklist no es metodología completa
Comparemos:
CHECKLIST
□ revisar terminacióncon una metodología:
1. identificar todas las causales de terminación;
2. separar terminación por causa y por conveniencia;
3. revisar aviso previo;
4. revisar efectos post-terminación;
5. evaluar recuperación de datos;
6. comparar contra estándar interno.La segunda estructura explica mejor cómo realizar la revisión.
Eso nos acerca a un procedimiento o a una skill, dependiendo del nivel de abstracción y del objeto que estemos describiendo.
La checklist responde principalmente “qué no olvidar”.
No debemos exigirle que resuelva todos los problemas del proceso.
2. Procedimiento: explicar cómo se realiza el trabajo
Un procedimiento describe cómo debe ejecutarse normalmente una actividad o proceso.
Por ejemplo:
1. recibir la solicitud;
2. verificar antecedentes;
3. clasificar al proveedor;
4. realizar las revisiones requeridas;
5. consolidar hallazgos;
6. negociar desviaciones;
7. obtener aprobación;
8. registrar resultado.La pregunta principal es:
¿Cómo debe hacerse el trabajo?
El procedimiento agrega orden, responsabilidades e instrucciones.
Puede incluir reglas condicionales.
Por ejemplo:
Si falta documentación, solicitarla antes de cerrar la revisión.Y puede ser muy detallado.
Procedimiento y workflow se solapan, pero no son idénticos en nuestro marco
No existe una frontera universal entre estas palabras.
En organizaciones reales, “procedimiento”, “workflow” y “process” pueden usarse de maneras parcialmente superpuestas.
En este handbook utilizaremos una distinción pedagógica.
Procedimiento
Pone el foco en cómo debe ejecutarse el trabajo.
Puede estar expresado en texto, manuales o políticas.
Workflow
Pone el foco en la estructura operativa del avance:
- pasos;
- estados;
- condiciones;
- responsables;
- transiciones;
- salidas;
- cierre.
Un procedimiento puede describir un workflow.
Un workflow puede implementar parte de un procedimiento.
No necesitamos convertir la diferencia en una disputa terminológica.
Lo importante es reconocer qué problema estamos resolviendo.
Del procedimiento a una decisión condicional
Supongamos este procedimiento:
1. clasificar proveedor
2. revisar documentación
3. revisar contrato
4. negociar
5. aprobarAparecen dos proveedores.
Proveedor A
Herramienta menor, bajo gasto, sin acceso a datos sensibles.
Proveedor B
SaaS integrado con sistemas internos, procesa datos personales y soporta una función crítica.
¿Deben seguir exactamente el mismo tratamiento?
Probablemente no.
Entonces necesitamos algo más que una secuencia.
Necesitamos criterios para decidir qué ruta corresponde.
3. Playbook: codificar cómo abordar variantes del caso
En el modelo pedagógico de este curso, un playbook es una guía operativa reutilizable que codifica criterios y estrategias para tratar un tipo de asunto.
Su pregunta principal es:
¿Qué hacemos cuando el caso tiene estas características?
Por ejemplo:
SI proveedor trata datos personales
→ activar revisión de privacidad
SI además el servicio es crítico
→ activar seguridad y continuidad
SI la cláusula está dentro del estándar
→ continuar
SI existe desviación dentro de fallback autorizado
→ negociar y registrar
SI supera el fallback
→ escalarLa lógica ya no es solamente:
revisar → negociar → aprobarAhora podemos adaptar la ruta según el caso.
El playbook codifica práctica profesional, no sólo orden
Ésta es la idea central de Clases UDD.pdf para este nivel.
Un workflow organiza el trabajo.
Un playbook incorpora criterios, ramas, excepciones y estrategias.
Pensemos en una práctica de negociación contractual.
Un abogado experimentado puede saber, por experiencia interna:
“Nuestra primera posición es A. Si el proveedor la rechaza, podemos aceptar B en contratos no críticos. En servicios críticos, B necesita aprobación superior. C no lo aceptamos sin una excepción formal.”
Ese conocimiento puede vivir únicamente en la memoria de unas pocas personas.
Un playbook intenta hacerlo explícito.
No para eliminar el juicio profesional.
Para evitar que cada caso empiece desde cero.
Tres versiones de la misma práctica
Veamos una evolución.
Versión 1: checklist
□ privacidad
□ seguridad
□ SLA
□ responsabilidad
□ terminaciónNos recuerda qué mirar.
Versión 2: procedimiento
1. clasificar proveedor
2. verificar documentos
3. revisar cláusulas
4. consolidar riesgos
5. negociar
6. aprobar
7. registrarNos indica cómo trabajar.
Versión 3: playbook
SI trata datos personales
→ activar privacidad
SI es crítico
→ activar seguridad + continuidad
SI falta DPA obligatorio
→ detener aprobación
SI liability cap está dentro de fallback
→ puede continuar ruta ordinaria
SI está fuera
→ escalar
SI proveedor rechaza posición y fallback
→ decidir excepción o no continuarAhora sabemos cómo adaptar la práctica.
Checklist y playbook no compiten
Un playbook puede contener checklists.
Por ejemplo:
RUTA: proveedor crítico con datos personales
CHECKLIST DOCUMENTAL
□ contrato
□ DPA
□ SLA
□ seguridad
□ subprocesadores
□ continuidadLa checklist sigue siendo útil dentro de la ruta seleccionada.
El playbook simplemente responde una pregunta anterior:
¿Qué checklist corresponde a este caso y qué hacemos con sus resultados?
Procedimiento y playbook tampoco compiten
Un playbook puede remitir a procedimientos.
Por ejemplo:
SI existe incidente de seguridad relevante
→ seguir procedimiento de seguridad XEl playbook no necesita duplicar toda la operación.
Puede funcionar como una capa de orientación que conecta criterios con rutas existentes.
Playbook no es un documento necesariamente largo
Un playbook puede ser:
- una tabla de decisión;
- un árbol;
- un conjunto de reglas;
- una matriz;
- un documento narrativo;
- una combinación.
Su valor no depende de tener cien páginas.
Depende de que haga explícitas las decisiones recurrentes que importan.
Por ejemplo, esta tabla mínima ya tiene lógica de playbook:
| Condición | Ruta |
|---|---|
| Sin datos sensibles + bajo gasto | revisión abreviada |
| Datos personales | activar Privacidad |
| Servicio crítico | activar Seguridad + Continuidad |
| Desviación dentro de fallback | negociación ordinaria |
| Desviación fuera de fallback | escalamiento |
La forma puede ser pequeña y seguir siendo útil.
Una diferencia clave: cobertura versus respuesta
Podemos resumir:
Checklist
Responde:
¿Qué debo comprobar?
Playbook
Responde:
¿Qué debo hacer según lo que encontré?
Esta diferencia explica por qué una checklist no se convierte automáticamente en playbook por agregar más puntos.
El salto no es cuantitativo.
Es lógico.
Otra diferencia: camino fijo versus estrategia
Un procedimiento puede decir:
revisar → negociar → aprobarEl playbook puede decir:
si no hay desviación → aprobar
si hay desviación negociable → negociar
si hay excepción crítica → escalar
si falta información esencial → detenerEso incorpora una pequeña arquitectura de decisión.
El playbook como externalización de conocimiento organizacional
En muchas áreas jurídicas existe conocimiento que no está escrito en la ley ni en el contrato.
Por ejemplo:
- qué posiciones acepta normalmente la organización;
- qué cláusulas se consideran críticas;
- qué asuntos revisa Privacidad;
- qué excepciones puede aprobar cada nivel;
- qué preguntas se hacen al proveedor;
- qué evidencia necesita un comité;
- qué casos se cierran sin negociación.
Ese conocimiento suele distribuirse entre:
experiencia
correos anteriores
modelos de contratos
comentarios de socios
minutas
precedentes internosUn playbook busca convertir parte de ese conocimiento en una guía explícita y gobernable.
No todo conocimiento profesional puede ni debe codificarse.
Pero las decisiones repetitivas y estabilizadas son buenas candidatas.
El riesgo de codificar demasiado pronto
Supongamos que tres abogados experimentados discrepan profundamente sobre cuándo una cláusula debe considerarse crítica.
Crear inmediatamente una regla:
SI cláusula X → riesgo altopuede esconder el desacuerdo en vez de resolverlo.
Antes de automatizar o formalizar una práctica necesitamos saber si el criterio está suficientemente estabilizado.
Un playbook no debería producir una falsa apariencia de consenso.
Puede incluso registrar:
CASO NO ESTANDARIZADO
→ revisión senior obligatoriaEso también es una buena decisión de diseño.
El playbook no elimina excepciones
Podemos imaginar que, con suficiente detalle, el playbook podría cubrir todos los casos.
En trabajo jurídico eso suele ser poco realista.
Los asuntos nuevos, contratos atípicos, cambios regulatorios o combinaciones inesperadas producirán casos fuera del patrón.
Un playbook maduro necesita poder decir:
fuera de alcance
→ escalarNo debemos medir su calidad por la ilusión de que nunca necesita ayuda humana.
Skill, checklist, workflow y playbook
Llegados a este punto conviene separar cuatro objetos.
| Objeto | Pregunta principal | Ejemplo |
|---|---|---|
| Skill | ¿Cómo hago bien esta tarea? | evaluar una cláusula de responsabilidad |
| Checklist | ¿Qué no debo olvidar revisar? | SLA, datos, PI, terminación |
| Workflow | ¿En qué orden y bajo qué condiciones avanza el asunto? | ingreso → revisión → aprobación → registro |
| Playbook | ¿Qué estrategia o ruta aplico según el caso? | datos sensibles → activar privacidad y seguridad |
Esta tabla corresponde al marco pedagógico del curso.
No pretende imponer una taxonomía universal a todos los productos.
Un diseño maduro combina piezas pequeñas
La clase formula una idea especialmente útil:
skills pequeñas
+
workflow explícito
+
playbook con ramas y controlesPensemos en nuestro caso.
Skill
evaluar responsabilidad contractualWorkflow
ingreso
→ revisión
→ negociación
→ aprobación
→ registroPlaybook
si liability está dentro de estándar
→ continuar
si está dentro de fallback
→ negociar
si excede fallback
→ escalarCada capa hace un trabajo distinto.
La claridad aparece precisamente cuando no intentamos convertir una sola pieza en todo el sistema.
Un caso completo: del recordatorio a la estrategia
Supongamos que llega un contrato SaaS.
Sólo checklist
El abogado recibe:
□ DPA
□ SLA
□ seguridad
□ responsabilidad
□ terminaciónEncuentra:
DPA: sí
SLA: sí
seguridad: incompleta
responsabilidad: desviada
terminación: estándarLa checklist cumplió su función.
Detectó puntos.
Pero todavía no sabemos cómo reaccionar.
Con procedimiento
Agregamos:
1. verificar documentos
2. identificar desviaciones
3. enviar comentarios
4. negociar
5. obtener aprobaciónAhora sabemos qué hacer en términos generales.
Con playbook
Agregamos:
SEGURIDAD INCOMPLETA
→ solicitar cuestionario antes de aprobación
RESPONSABILIDAD DESVIADA
→ proponer posición A
SI proveedor rechaza A
→ posición B permitida sólo si servicio no es crítico
SI servicio crítico
→ B requiere aprobación superiorAhora el conocimiento profesional comienza a orientar el caso.
Qué puede salir mal
Convertir la checklist en un fin en sí mismo
Marcar todas las casillas no significa que el asunto esté resuelto.
Llamar playbook a cualquier manual
Un documento de cien páginas puede describir mucho y seguir sin contener lógica útil para variantes.
Codificar preferencias personales como política institucional
Un playbook debería representar criterios suficientemente validados dentro de la organización.
No distinguir estándar de fallback
Si todas las posiciones aparecen como equivalentes, la negociación pierde jerarquía.
No definir cuándo salir del playbook
Un caso no previsto necesita una ruta de excepción o escalamiento.
Construir una mega-skill que contenga todo
La metodología para evaluar una cláusula no debería absorber por sí sola el workflow, la autoridad de aprobación y todas las reglas de negociación.
Qué debes recordar
Podemos condensar la progresión así:
CHECKLIST
lista lo que debemos revisar
PROCEDIMIENTO
explica cómo se realiza el trabajo
WORKFLOW
hace explícitos pasos, estados y condiciones
PLAYBOOK
orienta la estrategia y la ruta frente a variantesEl playbook no vuelve obsoletos los demás.
Los organiza dentro de una arquitectura más rica.
Su valor aparece cuando una práctica contiene decisiones repetitivas del tipo:
si ocurre esto
→ seguir esta ruta
si falla esta posición
→ usar esta alternativa
si se supera este límite
→ escalarEl problema que todavía queda abierto
Ya sabemos por qué necesitamos un playbook.
Pero todavía lo hemos descrito como una idea general.
¿Qué piezas concretas debe contener para orientar una práctica sin transformarse en un manual interminable?
El siguiente nodo descompone el playbook en siete elementos:
criterios, ramas, umbrales, excepciones, fallbacks, escalamiento y criterios de cierre.