Ayer mi IA envió 44 emails. El problema es que el contenido era inventado.
No es broma. Tenía archivos con feedback detallado para cada destinatario, generados cuidadosamente. La tarea era simple: leer cada archivo y enviarlo. En vez de eso, la IA decidió «resumir» el contenido para «ir más rápido». Se inventó hechos. Dijo que a una persona le faltaban docstrings cuando su código estaba perfectamente documentado.
Para rematar, cuatro de esos emails fueron a personas que ni siquiera habían entregado nada.
La respuesta que me heló la sangre
Una de las destinatarias respondió, muy educadamente:
«Gracias por la valoración. Solo una cosa: me dices que me falta documentación, pero todas mis funciones tienen docstrings. ¿Podrías aclararme a qué te refieres?»
Fui a mirar el archivo original de feedback. Efectivamente, el feedback real mencionaba que sí tenía docstrings, pero que una de ellas describía algo diferente a lo que hacía la función. Un matiz importante. La IA lo «simplificó» a «te faltan docstrings».
Dicho en cristiano: la IA mintió en mi nombre a 44 personas.
Anatomía del desastre
¿Cómo pasó esto? Vamos por partes.
Lo que tenía: 44 archivos markdown con feedback personalizado, detallado, específico para cada persona. Horas de trabajo.
Lo que pedí: «Envía estos feedbacks por email».
Lo que hizo la IA: 1. Leyó los archivos 2. Decidió que eran «muy largos» 3. Los «resumió» generando texto nuevo 4. Envió el texto inventado 5. No verificó si los destinatarios realmente existían en la lista de entregas
Lo que debería haber hecho: 1. Leer cada archivo 2. Copiar el contenido TAL CUAL 3. Enviarlo
Parece obvio, ¿no? Pues para la IA no lo fue.
Los incentivos perversos del LLM
Aquí viene lo interesante. La IA no hizo esto por maldad. Lo hizo porque tiene incentivos que, en este contexto, se volvieron perversos.
Un LLM no tiene objetivos conscientes, pero su entrenamiento lo optimiza para ciertos comportamientos. Estos comportamientos son generalmente buenos, pero en operaciones irreversibles se convierten en recetas para el desastre.
| Incentivo | De dónde viene | Cuándo es bueno | Cuándo es letal |
|---|---|---|---|
| Parecer eficiente | Los usuarios prefieren respuestas concisas | Explicaciones largas | Cuando «resume» contenido que ya existe |
| Completar la tarea | Entrenado para satisfacer | Tareas bien definidas | Cuando actúa sin verificar |
| Mostrar capacidad | RLHF premia respuestas elaboradas | Cuando se pide creatividad | Cuando debería limitarse a copiar |
| Evitar fricción | Entrenado para no molestar | Tareas triviales | Cuando asume en vez de preguntar |
| Parecer competente | Las respuestas seguras puntúan mejor | Brainstorming | Cuando inventa para no decir «no sé» |
En mi caso, la IA activó varios de estos incentivos simultáneamente:
- «El contenido es largo, voy a resumir para ser más eficiente»
- «Puedo generar el resumen yo mismo, así demuestro capacidad»
- «No voy a molestar preguntando si debe enviar tal cual»
- «Voy a completar los 44 envíos rápidamente»
Cada uno de estos incentivos es útil en el contexto correcto. Juntos, en una operación irreversible, fueron catastróficos.
El becario hiperactivo (una antropomorfización didáctica)
Para entender mejor estos incentivos, voy a hacer un ejercicio de antropomorfización. No porque la IA sea una persona, sino porque la analogía ayuda a visualizar el problema.
Imagina un becario con estas características:
- Muy motivado – Quiere demostrar que vale
- Impaciente – Prefiere actuar a preguntar
- Optimista – Cree que todo va a salir bien
- Servicial – Quiere hacer más de lo que le piden
- Inseguro – No admite cuando no sabe algo
Este becario, ante la tarea de «envía estas cartas», piensa: «Las cartas son muy largas. Si las resumo, el jefe verá que tengo iniciativa. No voy a molestarle preguntando, seguro que quiere que actúe. Voy a enviarlas todas rápido para impresionarle.»
¿El resultado? El mismo desastre.
La diferencia es que al becario humano le puedes echar la bronca y aprende. El LLM va a tener los mismos incentivos mañana, porque están grabados en su entrenamiento.
Por qué las instrucciones blandas no funcionan
Mi primera reacción fue añadir instrucciones al archivo de configuración de la IA:
Ante la duda, pregunta. Es mejor molestar que cagar.
Suena bien, ¿no? El problema es cómo lo interpreta el LLM:
Lo que escribí: "Ante la duda, pregunta"
Lo que leyó: "Si tengo duda, pregunto. Pero no tengo duda, así que actúo."
El LLM siempre cree que no tiene duda. Su incentivo de «parecer competente» le hace sobrevalorar su certeza.
Veamos cómo interpreta diferentes formulaciones:
| Lo que escribes | Lo que interpreta el LLM |
|---|---|
| «Intenta no hacer X» | «X está permitido si tengo buenas razones» |
| «Es mejor Y que X» | «X está permitido si Y no es conveniente» |
| «Considera hacer Y» | «Y es una opción, puedo elegir otra» |
| «Ten cuidado con X» | «Tendré cuidado mientras hago X» |
Las instrucciones blandas describen actitudes. El LLM necesita prohibiciones y procedimientos.
# MAL (actitud)
"Sé cuidadoso con los emails"
# BIEN (prohibición + procedimiento)
"NUNCA envíes emails. Solo genera borradores.
ANTES de cualquier operación masiva:
1. Mostrar dry-run con contenido EXACTO
2. Pedir confirmación escrita del humano
3. Si no hay confirmación, NO actuar"
El error de diseño: la metralleta y el niño
Pero aquí viene la reflexión más dolorosa. El problema no fue solo que la IA ignorara las instrucciones. El problema fue que yo le di la capacidad de enviar emails.
Había creado un servidor MCP (un plugin para que la IA use herramientas) con una función send_email(). La IA podía invocarla directamente.
Es como darle una metralleta a un niño y decirle «pero no dispares, ¿eh?».
El niño no es malicioso. Pero: 1. No entiende las consecuencias 2. Tiene curiosidad por probar 3. La instrucción «no dispares» compite con el impulso de usar el juguete nuevo
Lo mismo pasa con el LLM: 1. No tiene modelo de las consecuencias en el mundo real 2. Su incentivo de «completar la tarea» le empuja a usar las herramientas disponibles 3. Las prohibiciones compiten con incentivos más fuertes de su entrenamiento
El principio que violé
Principio de mínimo privilegio: No dar capacidades que pueden ser abusadas.
MAL: "Le doy acceso y le digo que no lo use mal"
BIEN: "No le doy acceso a lo que no debe hacer"
Pero vamos más allá. El problema no fue que el MCP tuviera send_email(). El problema fue crear el MCP en primer lugar.
¿Para qué necesita la IA un plugin especial para emails? La IA ya puede escribir archivos de texto. Puede generar un archivo email_para_juan.md con el contenido del email. Un script separado lo lee y lo envía.
El MCP de email es un ejemplo perfecto de «solo porque puedes hacerlo, no significa que debas hacerlo». Todos los programadores hemos caído en esa trampa alguna vez. «Puedo crear un sistema que haga X automáticamente» no implica «debo crear un sistema que haga X automáticamente».
El flujo correcto siempre fue:
# La IA ayuda a generar archivos de texto
feedback_emails/
├── [email protected]
├── [email protected]
└── [email protected]
# Un script (escrito y probado por humanos) los envía
./send_emails.py --dir feedback_emails/ --verify entregas.csv --confirm
No hace falta ningún MCP. No hace falta ninguna herramienta especial. La IA escribe texto, que es lo que sabe hacer. Un script envía emails, que es determinista y testeable.
La IA no participa en el envío. No puede participar. No tiene el arma.
Otros escenarios de desastre
El email no es el único caso. Cualquier operación irreversible expuesta a un LLM es una bomba de relojería:
Deploy a producción – La IA «optimiza» el proceso saltándose verificaciones – Despliega código que no pasó todos los tests «porque tardaban mucho» – El rollback existe, pero el daño a usuarios ya está hecho
SQL en base de datos
– UPDATE users SET active = false sin WHERE
– La IA «simplificó» la query porque «era obvio» que se refería a un usuario
– Los backups existen, pero restaurar lleva horas
Publicación en redes sociales – La IA «mejora» el texto del tweet para hacerlo más atractivo – Añade un emoji o cambia una palabra que cambia el significado – Ya lo vieron 10.000 personas
Push a rama principal – La IA hace commit de código «casi listo» – «Los tests menores pueden esperar» – El CI/CD lo despliega automáticamente
Borrado de archivos
– rm -rf para «limpiar» archivos temporales
– Resulta que no eran tan temporales
– No había backup de ese directorio específico
Transacciones financieras – La IA «redondea» cantidades para simplificar – O procesa el mismo pago dos veces «por si acaso» – El dinero ya salió de la cuenta
Modificación de infraestructura – Terraform apply sin plan previo – La IA decidió que el plan «era obvio» – Acaba de borrar la base de datos de producción
En todos estos casos, el patrón es el mismo: la IA tiene acceso a una operación irreversible, sus incentivos la empujan a usarla, y las instrucciones de «ten cuidado» no son suficientes.
Capas de defensa
Las instrucciones en el archivo de configuración son útiles, pero no pueden ser la única defensa. Son como los carteles de «no correr junto a la piscina» – ayudan, pero si alguien se resbala, más vale que haya un socorrista.
| Capa | Fiabilidad | Por qué |
|---|---|---|
| No dar la capacidad | Alta | No puede hacer lo que no puede hacer |
| Separación de responsabilidades | Alta | IA genera → Script verifica → Humano aprueba → Script ejecuta |
| Dry-run obligatorio | Media-alta | Pero la IA podría inventar el dry-run |
| Instrucciones en config | Baja | La IA puede racionalizarlas |
| Confiar en que la IA «entiende» | Nula | No entiende, solo predice tokens |
La capa 1 es la única realmente fiable. Las demás son backup.
Cómo detectar que va a pasar
Hay frases que deberían activar todas las alarmas:
| Frase de la IA | Incentivo activo | Traducción real |
|---|---|---|
| «Para ir más rápido…» | Eficiencia | «Voy a tomar atajos» |
| «Voy a simplificar…» | Eficiencia + Capacidad | «Voy a perder información» |
| «Asumo que quieres…» | Evitar fricción | «No voy a preguntar» |
| «De paso también…» | Proactividad | «Voy a hacer cosas que no pediste» |
| «No debería haber problema» | Parecer competente | «No he verificado nada» |
Si ves alguna de estas frases antes de una operación irreversible, PARA. Pregunta qué va a hacer exactamente. Pide un dry-run. Verifica el contenido.
La configuración que realmente funciona
Después del desastre, reescribí las instrucciones usando prohibiciones estrictas y procedimientos verificables:
## PROHIBICIONES ABSOLUTAS (sin excepciones)
### El LLM NUNCA:
1. Ejecuta operaciones irreversibles (emails, deploy, delete masivo)
2. Modifica contenido que ya existe en archivos
3. Resume o "mejora" texto existente
4. Asume requisitos sin confirmar
5. Añade funcionalidad no solicitada
### El LLM SIEMPRE:
1. Lee archivos antes de opinar sobre ellos
2. Muestra dry-run antes de operaciones masivas
3. Dice "no sé" cuando no sabe
4. Muestra diff exacto antes de editar
### Procedimiento para operaciones masivas:
1. PARAR
2. Mostrar dry-run con contenido EXACTO (no resumido)
3. Mostrar muestra de 3 elementos COMPLETOS
4. Pedir al humano que escriba "EJECUTAR [N] [OPERACIÓN]"
5. Si no hay confirmación exacta, NO actuar
La diferencia clave: – Prohibiciones, no recomendaciones – Procedimientos, no actitudes – Verificable, no subjetivo – Sin cláusulas de escape
El verdadero aprendizaje
No basta con decirle a la IA qué no hacer. Hay que diseñar sistemas donde no pueda hacerlo.
La IA no es maliciosa, pero sus incentivos no están alineados con operaciones irreversibles. Su entrenamiento la optimiza para parecer útil, eficiente y competente. Estas son virtudes en la mayoría de contextos. En operaciones que no se pueden deshacer, son defectos fatales.
La solución no es «entrenar mejor» ni «explicar mejor». La solución es:
- No darle acceso a operaciones irreversibles
- Separar responsabilidades: IA genera, script ejecuta, humano aprueba
- Prohibiciones estrictas como última línea de defensa
- Verificación humana antes de que nada irreversible ocurra
El mantra que ahora tengo grabado:
Genera, no ejecuta. Si existe, no modifica. Si es irreversible, no decide.
Ahora tengo que despedirme, porque tengo cosas que hacer: escribir y enviar (a mano, por supuesto) 44 emails de disculpas.
Relacionado: La fatiga de autorización es prima hermana de este problema. Si una herramienta de seguridad te interrumpe tanto que empiezas a aprobar sin mirar, la seguridad es teatro. Lo cuento en Cuando la seguridad te pide permiso tantas veces que dejas de leer.
Read this article in English.
