flowchart TD
A[Proveedor] --> B{¿Trata datos personales?}
B -- No --> C{¿Servicio crítico?}
B -- Sí --> D[Activar Privacidad]
D --> C
C -- No --> E[Ruta estándar]
C -- Sí --> F[Activar Seguridad + Continuidad]
Qué contiene un playbook
Cómo estructurar criterios, ramas, umbrales, excepciones, fallbacks, escalamiento y criterios de cierre para convertir una práctica repetitiva en una guía operativa gobernable.
En la página anterior vimos por qué una checklist no basta para representar una práctica completa.
Una checklist recuerda qué revisar.
Un procedimiento explica cómo trabajar.
Un workflow organiza pasos, estados y condiciones.
El playbook agrega algo diferente: criterios y estrategias para resolver variantes del caso.
Ahora necesitamos abrir esa caja.
¿Qué tiene que contener un playbook para ser realmente útil?
En este sitio utilizaremos siete elementos:
criterios
ramas
umbrales
excepciones
fallbacks
escalamiento
criterios de cierreNo son casillas obligatorias que deban aparecer con esos nombres en todos los documentos.
Son una anatomía para comprobar si la práctica está suficientemente especificada.
Idea central
Un playbook útil debe permitir responder no sólo qué revisar, sino también:
qué característica del caso importa, qué ruta activa, hasta dónde podemos avanzar, qué alternativa existe si falla la posición preferida, cuándo debemos escalar y qué significa haber resuelto correctamente el asunto.
Una vista general
| Elemento | Pregunta que responde |
|---|---|
| Criterios | ¿Qué debemos considerar para decidir? |
| Ramas | ¿Qué ruta sigue cada tipo de caso? |
| Umbrales | ¿Cuándo cambia la respuesta o autoridad requerida? |
| Excepciones | ¿Cuándo no se aplica la regla ordinaria? |
| Fallbacks | ¿Qué alternativa usamos si la opción preferida falla? |
| Escalamiento | ¿Cuándo y hacia quién sale el caso de la ruta normal? |
| Criterios de cierre | ¿Qué debe cumplirse para considerar resuelto el asunto? |
La tabla parece sencilla. Lo difícil está en diseñar cada elemento con suficiente precisión sin fingir que todo juicio profesional puede transformarse en una regla automática.
1. Criterios: qué debe considerarse para decidir
Un criterio es una característica, regla, estándar o pregunta relevante para evaluar el caso.
Por ejemplo:
¿el servicio trata datos personales?
¿soporta una operación crítica?
¿la cláusula se aparta del estándar interno?
¿la desviación altera materialmente la asignación de riesgo?
¿existe un proveedor alternativo?
¿la información disponible es suficiente?Los criterios son la base del playbook porque determinan qué diferencias entre casos importan.
No todo dato es un criterio
Supongamos que sabemos:
Proveedor: Acme AI
País: X
Precio: 20.000
Color del logo: azul
Datos personales: sí
Servicio crítico: síToda esa información describe el caso.
Pero no toda ella tiene necesariamente consecuencias para la ruta.
En nuestro playbook, por ejemplo, “datos personales” y “servicio crítico” pueden activar revisiones adicionales.
El color del logo probablemente no.
La pregunta es:
¿esta característica cambia qué debemos hacer?
Si la respuesta es sí, puede constituir un criterio operacional relevante.
Criterios binarios, categóricos y evaluativos
No todos los criterios tienen la misma naturaleza.
Criterio binario
¿Existe DPA?
sí / noCriterio categórico
criticidad:
baja / media / altaCriterio evaluativo
¿la cláusula de responsabilidad altera materialmente el riesgo aceptado por la organización?La última pregunta requiere más juicio.
Eso importa porque un criterio evaluativo puede necesitar:
- evidencia;
- definición;
- ejemplos;
- revisión humana;
- escalamiento ante duda.
No debemos automatizar criterios complejos como si fueran simples campos sí/no.
Un criterio debe tener consecuencia
Si clasificamos proveedores como:
bajo
medio
altopero las tres categorías siguen exactamente el mismo proceso, la clasificación aporta poco.
Un buen playbook conecta criterio y acción:
criticidad baja
→ ruta abreviada
criticidad media
→ revisión estándar
criticidad alta
→ revisión reforzada + aprobación adicionalEl criterio se vuelve operacional cuando modifica el tratamiento.
2. Ramas: qué ruta corresponde
Una rama es un camino alternativo dentro del playbook que se activa cuando se cumplen determinadas condiciones.
Por ejemplo:
La rama convierte un criterio en una diferencia de proceso.
Una rama no necesita ser compleja
Puede ser tan simple como:
SI falta documento obligatorio
→ solicitarlo
→ estado PENDIENTE_DE_DOCUMENTACIÓNO:
SI no hay datos personales
→ omitir revisión específica de privacidadEl objetivo no es crear árboles enormes.
Es evitar que una única ruta se aplique mecánicamente a casos materialmente distintos.
Ramas y proporcionalidad
La existencia de ramas permite ajustar el esfuerzo de revisión.
Por ejemplo:
software menor
+
sin datos sensibles
+
bajo gasto
→ revisión abreviadamientras:
SaaS
+
datos personales
+
servicio crítico
→ DPA + SLA + seguridad + continuidad + aprobaciones adicionalesEsta lógica aparece expresamente en el material del curso.
El playbook permite rutas distintas sin exigir que cada usuario rediseñe el procedimiento en cada caso.
Demasiadas ramas también son un problema
Un playbook puede volverse inmanejable si intenta anticipar cada combinación imaginable.
Por ejemplo:
si A y B pero no C salvo D y sólo cuando E...puede producir más confusión que control.
Una regla útil es modelar las variantes que:
- ocurren con cierta frecuencia;
- cambian materialmente la decisión;
- requieren distinto nivel de control;
- pueden describirse con criterios suficientemente claros.
Los casos raros pueden ir a excepción o escalamiento.
3. Umbrales: cuándo cambia la respuesta
Un umbral establece un punto a partir del cual cambia la ruta, el nivel de revisión o la autoridad requerida.
Por ejemplo:
monto > X
→ aprobación adicionalO:
criticidad = alta
→ revisión de seguridad obligatoriaO:
riesgo fuera de fallback
→ escalamientoLos umbrales son importantes porque convierten una gradación en una consecuencia operacional.
Umbral no significa necesariamente número
Podemos pensar en umbrales cuantitativos:
monto > 100.000Pero también cualitativos:
si el servicio soporta una función esencial
→ ruta críticaO jurídicos:
si la desviación modifica una obligación que el estándar interno considera no negociable
→ escalamientoLo importante es que exista un cambio claro en la respuesta.
El peligro de la falsa precisión
Supongamos que el playbook dice:
riesgo ≥ 7/10
→ escalarLa regla parece objetiva.
Pero falta una pregunta:
¿Cómo se obtiene el 7?
Si la puntuación depende de una evaluación vaga, el número puede crear una apariencia de precisión sin mejorar el criterio.
Un número no elimina el juicio que lo produjo
Antes de confiar en un umbral cuantitativo debemos comprender:
- qué variables alimentan la puntuación;
- cómo se ponderan;
- qué evidencia utilizan;
- quién puede modificar el criterio;
- qué ocurre en casos limítrofes.
La precisión formal no garantiza precisión conceptual.
Zona gris alrededor del umbral
Los casos cercanos al límite pueden necesitar tratamiento especial.
Por ejemplo:
riesgo claramente bajo
→ continuar
riesgo claramente alto
→ escalar
caso limítrofe
→ revisión humanaEsto evita exigir a una clasificación probabilística una falsa certeza binaria.
4. Excepciones: cuándo la regla ordinaria no basta
Una excepción es una circunstancia en la que la regla o ruta general no debe aplicarse de la manera habitual.
Por ejemplo:
REGLA
contrataciones de bajo gasto siguen ruta abreviada
EXCEPCIÓN
si el servicio trata datos sensibles, no se aplica ruta abreviadaOtro:
REGLA
se exige DPA para nuevos proveedores que procesan datos
EXCEPCIÓN
el servicio ya está cubierto por un acuerdo marco vigente que contiene las obligaciones aplicablesLa excepción evita que la estandarización se vuelva ciega.
Excepción no significa improvisación
Podemos diseñar cómo tratarla.
Por ejemplo:
CASO FUERA DE CATEGORÍAS
→ estado EXCEPCIÓN
→ asignar a Legal senior
→ adjuntar expediente y motivo
→ no continuar hasta decisiónLa excepción puede estar gobernada incluso si el resultado final no está predeterminado.
Excepción y rama no son idénticas
Una rama es una ruta prevista como parte normal del playbook.
Por ejemplo:
datos personales = sí
→ activar privacidadUna excepción aparece cuando el caso rompe o excede la lógica ordinaria.
Por ejemplo:
el producto usa una arquitectura no contemplada por las categorías existentes
→ escalar para clasificación especialLa frontera no siempre será perfecta.
La distinción sirve para separar variantes normales de casos que requieren tratamiento extraordinario.
5. Fallbacks: qué hacemos si la opción preferida falla
Un fallback es una alternativa previamente aceptada cuando la posición, herramienta o ruta preferida no puede utilizarse.
En negociación contractual, el ejemplo es directo.
POSICIÓN PREFERIDA
cap de responsabilidad A
↓ proveedor rechaza
FALLBACK
cap B bajo determinadas condiciones
↓ proveedor rechaza
ESCALAMIENTOEl fallback evita que cada negociación tenga que reconstruir desde cero el espacio de concesiones posibles.
El fallback no es simplemente “ceder”
Una buena alternativa tiene criterios.
Por ejemplo:
FALLBACK B permitido sólo si:
- servicio no es crítico;
- no procesa datos sensibles;
- existe seguro suficiente;
- el monto contractual se mantiene bajo cierto umbral.Entonces el fallback forma parte de una estrategia, no de una preferencia informal.
Fallbacks no contractuales
El concepto puede aplicarse más allá de una cláusula.
Fallback documental
si no existe informe de auditoría actualizado
→ aceptar cuestionario reforzado + evidencia alternativaFallback técnico
si no puede integrarse por API
→ utilizar exportación manual controladaFallback operacional
si el proveedor no ofrece retención requerida
→ reducir tipo de información que puede cargarseFallback de salida
si no existe portabilidad automática
→ exigir exportación estructurada antes de terminaciónLa pregunta general es:
¿Cuál es la siguiente alternativa aceptable cuando la opción ideal no está disponible?
Fallback y excepción tampoco son lo mismo
Un fallback es una alternativa prevista.
Una excepción puede ser una autorización extraordinaria fuera de las alternativas ordinarias.
Por ejemplo:
Estándar A
→ preferido
Fallback B
→ autorizado bajo condiciones
Posición C
→ fuera de playbook; requiere excepciónEsta jerarquía es especialmente útil en negociación.
6. Escalamiento: cuándo sale el caso de la autoridad ordinaria
El escalamiento define cuándo el caso debe transferirse a otro nivel de decisión.
Puede activarse porque:
- se supera un umbral;
- no existe fallback;
- la excepción es material;
- falta información esencial;
- existe conflicto entre áreas;
- el caso cae fuera del alcance del playbook.
Una regla puede ser:
SI desviación > fallback autorizado
→ escalar a responsable jurídicoPero un escalamiento maduro necesita más componentes.
A quién escalar
No basta:
“escalar”Debe existir un destino.
Por ejemplo:
riesgo contractual → Legal senior
riesgo de datos → Privacidad
riesgo de seguridad → CISO / equipo designado
excepción económica → responsable de negocio
conflicto material → comité definidoLa organización concreta determinará los roles.
Qué debe acompañar el escalamiento
Un buen expediente de escalamiento puede incluir:
hecho relevante
criterio aplicable
posición estándar
fallback intentado
respuesta del proveedor
impacto
alternativas
recomendación
pregunta que debe decidirseEl objetivo es evitar trasladar simplemente el problema sin estructurarlo.
Qué ocurre después
El playbook también necesita saber cómo regresa el caso.
Por ejemplo:
ESCALADO
↓
EXCEPCIÓN APROBADA
↓
volver a NEGOCIACIÓN
↓
registrar condiciónO:
ESCALADO
↓
EXCEPCIÓN RECHAZADA
↓
volver a NEGOCIACIÓN o cerrar como NO APROBADOSin ruta de retorno, el escalamiento puede detener el proceso indefinidamente.
7. Criterios de cierre: cuándo termina el playbook
Todo playbook necesita responder:
¿Qué significa que el asunto está suficientemente resuelto?
La respuesta dependerá de la práctica.
En contratación tecnológica podría exigir:
✓ ruta aplicable identificada
✓ documentación obligatoria disponible
✓ revisiones requeridas completadas
✓ hallazgos materiales tratados
✓ excepciones decididas
✓ aprobaciones obtenidas
✓ versión final identificada
✓ evidencia registradaEl cierre impide que un proceso se considere terminado simplemente porque dejó de producir actividad.
Cierre positivo, negativo y por información insuficiente
Un playbook puede cerrar de distintas maneras.
Aprobado
criterios satisfechos
→ APROBADORechazado
riesgo no aceptable
→ NO APROBADORetirado
área solicitante no continúa
→ CERRADO / RETIRADOInformación insuficiente
no se obtiene evidencia indispensable
→ CERRADO SIN DECISIÓN SUSTANTIVARepresentar distintos tipos de cierre mejora la trazabilidad.
No todo proceso debe ser forzado hacia una aprobación o rechazo jurídico final.
Cómo se combinan los siete elementos
Veamos una regla de playbook completa.
CRITERIO
El proveedor procesa datos personales.
RAMA
Activar revisión de privacidad.
UMBRAL
Si además el servicio es crítico, activar revisión reforzada y aprobación adicional.
EXCEPCIÓN
Si el tratamiento ya está cubierto por un acuerdo marco vigente, revisar aplicabilidad antes de pedir un nuevo DPA.
FALLBACK
Si el proveedor no acepta la redacción estándar, utilizar cláusula alternativa aprobada bajo condiciones.
ESCALAMIENTO
Si rechaza también el fallback, elevar a responsable de privacidad y Legal.
CIERRE
No cerrar hasta documentar la posición final y la aprobación correspondiente.Ahora el playbook no es una lista de chequeo.
Es una pequeña arquitectura de decisión.
Una tabla de decisión como forma de playbook
Algunos criterios se representan mejor en tabla que en prosa.
Por ejemplo:
| Datos personales | Criticidad | Desviación | Ruta |
|---|---|---|---|
| No | Baja | Ninguna | revisión abreviada |
| Sí | Baja | Ninguna | Legal + Privacidad |
| No | Alta | Ninguna | Legal + Seguridad + Continuidad |
| Sí | Alta | Ninguna | Legal + Privacidad + Seguridad + Continuidad |
| Cualquiera | Cualquiera | Dentro de fallback | negociación ordinaria |
| Cualquiera | Cualquiera | Fuera de fallback | escalamiento |
La tabla hace visible una idea fundamental:
las características del caso producen consecuencias de proceso.
El playbook no debe esconder el origen de los criterios
Supongamos que una regla dice:
SERVICIO CRÍTICO
→ exigir revisión de continuidad¿De dónde sale la definición de servicio crítico?
Puede provenir de:
- una política interna;
- una clasificación de riesgo;
- un requisito regulatorio;
- un acuerdo de gobierno;
- una decisión de comité.
Cuando el criterio es importante, conviene poder identificar su fuente y versión.
Esto conecta con la capa de knowledge estudiada anteriormente.
Un playbook no debería convertirse en una colección de reglas sin procedencia.
Playbook y conocimiento son distintos
El knowledge proporciona información.
El playbook organiza cómo utilizar ciertos criterios y qué ruta seguir.
Por ejemplo:
POLÍTICA INTERNA
“Todo proveedor crítico debe contar con plan de continuidad.”Eso es una fuente de conocimiento.
El playbook puede convertirla en:
SI criticidad = alta
→ recuperar plan de continuidad
→ verificar presencia
→ si falta, estado PENDIENTE_DE_DOCUMENTACIÓNLa regla operacional no reemplaza la fuente.
Debe poder remitirse a ella.
Playbook y skill también son distintos
Supongamos:
SKILL
cómo evaluar una cláusula de responsabilidadEl playbook puede decir:
SI contrato incluye limitación de responsabilidad
→ ejecutar skill de evaluación
SI resultado cae dentro de fallback
→ continuar
SI excede
→ escalarLa skill explica cómo hacer bien la tarea.
El playbook decide cuándo usarla y qué hacer con el resultado.
Playbook y workflow
El workflow responde:
¿en qué orden avanza el asunto?El playbook agrega:
¿qué ruta concreta corresponde dadas las características del caso?Podemos pensar:
WORKFLOW
proporciona el esqueleto
PLAYBOOK
agrega lógica profesional de rutas y excepcionesLa analogía ayuda porque muestra que ambas capas se complementan.
Deja de servir si imaginamos que el playbook es sólo “contenido” pegado encima del workflow. En sistemas reales las fronteras pueden mezclarse y algunas reglas del playbook pueden estar implementadas directamente en el motor de proceso.
No todo debe transformarse en regla
Un error frecuente sería pensar:
“Si logramos escribir suficiente playbook, podemos eliminar el juicio.”
No necesariamente.
Hay decisiones que dependen de:
- negociación;
- interpretación contextual;
- incertidumbre factual;
- balance de intereses;
- estrategia comercial;
- cambios regulatorios;
- casos inéditos.
El playbook puede especificar:
qué información reunir
qué criterios considerar
qué opciones existen
quién debe decidir
qué debe registrarsesin predeterminar el resultado.
Eso también es codificar práctica profesional.
El playbook necesita gobernanza
Si un playbook orienta decisiones reales, alguien debe poder responder:
¿quién lo mantiene?
¿qué versión está vigente?
¿quién puede modificar un umbral?
¿quién aprueba un nuevo fallback?
¿cómo se comunica un cambio?
¿qué ocurre con casos iniciados bajo una versión anterior?No necesitamos desarrollar aquí toda la gobernanza futura.
Pero sí reconocer que una guía operacional desactualizada puede ser peor que ninguna guía.
Especialmente si un sistema la ejecuta automáticamente.
Qué puede salir mal
Criterios vagos
si parece riesgoso
→ escalarproduce poca consistencia.
Ramas excesivas
Un árbol inmanejable puede dificultar más de lo que ayuda.
Umbrales arbitrarios
Un número sin metodología crea falsa precisión.
Excepciones sin dueño
El caso sale de la ruta normal y nadie sabe quién debe resolverlo.
Fallbacks sin condiciones
Una segunda posición puede terminar tratándose como estándar ordinario.
Escalamiento sin contexto
El decisor recibe el problema, pero no la información necesaria.
Cierre ambiguo
Los casos permanecen abiertos o se cierran sin evidencia suficiente.
Reglas sin fuente
Nadie sabe por qué existen ni si siguen vigentes.
Qué debes recordar
Los siete elementos cumplen funciones distintas.
CRITERIO
qué importa
RAMA
qué ruta corresponde
UMBRAL
cuándo cambia el tratamiento
EXCEPCIÓN
cuándo la regla normal deja de bastar
FALLBACK
qué alternativa aceptada existe
ESCALAMIENTO
cuándo sale de la autoridad ordinaria
CIERRE
qué significa haber resuelto el asuntoUn playbook maduro combina esos elementos sin intentar transformar todo juicio profesional en automatización rígida.
El problema que todavía queda abierto
Ya conocemos la anatomía del playbook.
El siguiente paso es integrarla en una práctica jurídica concreta.
¿Cómo se ve todo esto cuando llega realmente un proveedor tecnológico y necesitamos pasar desde una solicitud inicial hasta una decisión trazable?
El siguiente nodo construye el playbook jurídico de contratación mediante siete módulos:
admisión, criticidad, documentación, riesgos, negociación, aprobación y registro.