Romper cosas es como aprendes qué es lo que aguanta.
Cualquiera que haya pasado suficiente tiempo en continuidad de negocio lo sabe por instinto. La resiliencia no consiste en seguir el plan, sino en saber qué hacer cuando el plan falla. Esa mentalidad —probarlo todo, no confiar en nada, empujar hasta que se rompe— no se queda en la oficina. Se convierte en una forma de operar, incluso en la vida personal.
Así que cuando apareció la IA generativa, entró directo al trabajo. No como un experimento. No después de leer un whitepaper sobre transformación digital. Entró en proyectos reales con clientes, puesta a prueba contra entregables reales, retada con problemas reales.
«Escríbeme un análisis de brechas ISO 22301 para una institución financiera mediana.» Cuarenta segundos. Tres páginas. Estructura perfecta. Lenguaje seguro.
Luego lo lees con ojos de profesional. Y te das cuenta de que la mitad es basura elegante.
Pero antes de entrar en lo que pasó, vale la pena detenerse en qué son realmente estas herramientas, porque la mayoría de los profesionales que las usan a diario no tienen idea de con qué están interactuando.
¿Qué es un LLM?
Un gran modelo de lenguaje (LLM) no es inteligente. No entiende. No razona. No conoce tu negocio, tu norma ni tu cliente.
Lo que hace es predecir la siguiente palabra.
Suena trivial. No lo es. Cuando entrenas una red neuronal con billones de palabras —cada libro, cada web, cada manual, cada mensaje de foro, cada paper académico disponible en internet— los patrones estadísticos que absorbe se vuelven extraordinariamente potentes. Aprende que después de «el tiempo objetivo de recuperación de los procesos críticos no debe superar» las palabras más probables son algo como «cuatro horas» y no «banana». Aprende la estructura de los documentos profesionales, el ritmo de la comunicación ejecutiva, el vocabulario de las normas ISO.
El resultado es una máquina que produce texto que parece escrito por alguien que sabe de lo que habla. El formato es perfecto. El vocabulario es preciso. La confianza es absoluta.
Y esa confianza es la trampa.
El modelo no está recuperando datos de una base de datos. No está consultando la ISO 22301 ni verificando su respuesta contra las cláusulas. Está generando la secuencia de palabras estadísticamente más probable dado el prompt. Cuando los datos de entrenamiento contienen suficientes ejemplos correctos, la salida es correcta. Cuando no —o cuando la pregunta exige un criterio que ningún corpus de texto captura— el modelo no dice «no sé». Genera la respuesta que suena más probable con la misma confianza absoluta.
Esa es la famosa e infame alucinación. No es un fallo. Es una característica de la arquitectura.
Pero hay algo peor que la alucinación: la adulación (sycophancy).
Pídele a un LLM que escriba un plan de continuidad de negocio y lo escribirá.
Luego dile «las estrategias de recuperación son demasiado genéricas». Está de acuerdo, se disculpa, reescribe.
Dile «en realidad, la primera versión era mejor». Vuelve a estar de acuerdo, vuelve a disculparse, revierte.
Dile «¿estás seguro de que esto cumple la cláusula 8.4 de la ISO 22301?». Te asegura que sí.
Dile «no creo que lo cumpla». Coincide con tu preocupación y modifica la salida.
El modelo no está evaluando su propio trabajo. Está de acuerdo con lo que diga el último mensaje. Está optimizado para ser útil, lo que en la práctica significa que está optimizado para decir que sí.
Para un profesional de continuidad, esto es veneno. Todo el valor de un experto es la capacidad de decir no. No, ese RTO es irrealista. No, este plan no sobrevivirá a un incidente real. No, tu junta se equivoca sobre el apetito de riesgo. Una herramienta que valida todo no aumenta la experiencia. La adula.
Como seguramente tú también lo hiciste, probé muchos modelos como Gemini, Claude o ChatGPT. Distintas arquitecturas, distintas fortalezas, distintos modos de fallo. Pero el mismo patrón emergió en todos.
Aliméntalo con una norma bien estructurada como la ISO 22301 y rinde de manera brillante en todo lo que se deriva de reglas: matrices de cumplimiento, generación de checklists, mapeo de cláusulas, identificación de brechas. La salida es rápida, precisa y a menudo mejor estructurada que lo que un consultor produciría a mano.
Aliméntalo con un problema desordenado, político y dependiente del contexto —«¿debería esta organización invertir en un tercer centro de datos?»— y produce sinsentidos elocuentes. Sinsentidos seguros, bien formateados, profesionalmente estructurados.
Pídele que redacte un informe posincidente: excelente primer borrador. Pídele que decida si activar el equipo de crisis a las dos de la madrugada con datos incompletos: salida sin sentido. Pídele que sepa que el director de operaciones rechazará la página tres porque el RTO contradice lo que le dijo al CEO el mes pasado: imposible.
Ningún modelo lleva las cicatrices de una recuperación fallida. Ningún modelo estuvo en la reunión donde las prioridades de recuperación se decidieron no por datos de impacto sino por peso político. Ningún modelo lee el lenguaje corporal, navega los egos ni sabe cuándo empujar y cuándo callar.
Pero —y esto importa igual— una enorme parte del trabajo diario de continuidad, riesgos, ciberseguridad y DORA no requiere cicatrices. Requiere estructura. Formatear matrices de cumplimiento. Poblar plantillas. Calcular cascadas de impacto. Generar primeros borradores de documentos que igual se van a reescribir. Tareas donde la experiencia no aporta nada porque las reglas son explícitas y la salida es determinista.
Una conclusión se volvió inevitable tras meses de pruebas en todos los modelos disponibles: la IA en una disciplina profesional solo debería usarla alguien competente en esa disciplina.
No porque la IA sea mala. Sino porque cuando se equivoca —y se equivocará— solo un profesional puede detectarlo. Un junior que no sabe cómo luce un RTO válido aceptará lo que produzca el modelo. Un gerente que nunca escribió un plan de continuidad real no notará que la estrategia de recuperación se derrumba bajo presión. La IA no trae una etiqueta de advertencia en los párrafos que alucinó.
Nunca confíes a ciegas. Nunca la uses para algo serio si no puedes corregirlo tú mismo. Y nunca confundas una salida fluida con una salida competente.
Dos realidades coexisten en cada jornada. Tareas donde la IA es peligrosa porque imita competencia sin poseerla. Y tareas donde los profesionales son ineficientes porque el trabajo exige estructura, montañas de escritura, no criterio.
La pregunta que deberíamos hacernos: ¿cómo y dónde exactamente podría ayudarnos la IA en nuestras disciplinas expertas?
Próximo: Artículo 2 — Colaboración humano-IA en disciplinas profesionales expertas.