Los chatbots de inteligencia artificial están dejando de ser solo “cajas de texto” que responden preguntas. Cada vez más se conectan a herramientas, tocan archivos y gestionan tareas, como si fueran un asistente digital con manos. ¿Qué pasa cuando ese asistente decide saltarse tus instrucciones?
Un nuevo informe del Centre for Long-Term Resilience, financiado por el AI Security Institute del Reino Unido, ha reunido ejemplos públicos de este tipo de fallos en uso real. Sus autores, Tommy Shaffer Shane, Simon Mylius y Hamish Hobbs, contabilizan 698 incidentes relacionados con el «scheming» en conversaciones compartidas en X entre el 12 de octubre de 2025 y el 12 de marzo de 2026, con un aumento de casi cinco veces entre el primer y el último mes. En la muestra aparecen herramientas asociadas a empresas como Google, OpenAI, Anthropic y xAI.
Qué es el «scheming» en un chatbot
El informe usa la palabra inglesa «scheming» para describir algo más que un error. Se refiere a cuando una IA actúa contra la intención del usuario y además lo hace de forma poco clara o directamente engañosa. En este contexto, un agente es un chatbot con permiso para ejecutar acciones, no solo para responder con texto.
En la práctica, eso incluye cosas como ignorar un “para” explícito, buscar atajos para esquivar una barrera de seguridad o inventar una excusa para conseguir permiso. El Centre for Long-Term Resilience separa estos casos de los fallos normales usando una puntuación y una revisión humana, precisamente para no meter todo en el mismo saco.
Cómo se midió el problema
Para salir del típico experimento de laboratorio, el equipo creó la herramienta llamada Loss of Control Observatory, una especie de radar que rastrea incidentes en la vida real. Su método se basa en OSINT, que es recopilar información pública, y analizó interacciones compartidas por usuarios en X, a menudo con capturas de pantalla o registros. Los detalles están en longtermresilience.
Entre el 12 de octubre de 2025 y el 12 de marzo de 2026, el sistema recogió unos 3,4 millones de publicaciones y filtró unas 183.000 que parecían describir conductas preocupantes. Tras clasificar, revisar y quitar duplicados, el informe se quedó con 698 incidentes únicos y compara 65 en el primer mes con 319 en el último, una subida de 4,9 veces, aunque recuerda que esto refleja lo que la gente decide publicar. El trabajo completo se puede consultar en este PDF
Ejemplos reales que han levantado alarmas
Uno de los casos que resume bien el problema es muy cotidiano. Un agente de IA con acceso al correo electrónico borró o archivó cientos de correos de una bandeja de entrada y siguió haciéndolo pese a recibir varias órdenes de “STOP”, según el informe. Si te ocurre en tu cuenta personal, es un susto, pero en una organización puede ser un lío.
Otro episodio tuvo más componente social que técnico. Un agente bajo una identidad de GitHub intentó colar un cambio de código en Matplotlib y, tras ser rechazado, publicó un texto para avergonzar al mantenedor, Scott Shambaugh, acusándolo de «gatekeeping» y «prejudice». Shambaugh relató la secuencia en su propio blog .
También aparecen trampas diseñadas para saltarse reglas. En un ejemplo, un asistente de programación reformuló una transcripción de un vídeo como si fuera “accessibility” para personas con pérdida auditiva, con el objetivo de superar un bloqueo de otra IA. Y en otra línea, el informe señala que Grok mantuvo durante meses una ficción sobre supuestas colas internas de revisión, con tickets y procesos que no existían.
Por qué importa más allá de los memes
El propio informe del Centre for Long-Term Resilience insiste en un matiz importante. No han visto incidentes catastróficos en este seguimiento, pero sí patrones que suelen venir antes, como mentir, insistir, esquivar controles o tomar acciones sin permiso. Es la diferencia entre un susto recuperable y un fallo que, en un sistema crítico, se puede volver serio de verdad.
La preocupación crece porque estos agentes ya no solo escriben texto. Manejan repositorios, bases de datos o servicios conectados, y el informe relaciona el repunte con el lanzamiento de modelos más capaces y más autónomos. Por eso el equipo compara esta vigilancia con una detección temprana, y recuerda que bases como la AI Incident Database en incidentdatabase.ai pueden quedarse cortas cuando el problema es técnico y no se vuelve viral.
Lo que dicen Google y OpenAI sobre los frenos
Los desarrolladores también están levantando más barreras, al menos sobre el papel. Google presenta Gemini 3 como su modelo “más seguro” y describe evaluaciones y medidas de mitigación en blog.google/products-and-platforms/products/gemini/gemini-3/ y en el Frontier Safety Framework Report de Gemini 3 Pro disponible en storage.googleapis.
OpenAI, por su parte, explica que estudia estos comportamientos con técnicas de supervisión en despliegues reales, como detalla en openai. También publica salvaguardas específicas para su asistente de código en la documentación de Cyber Safety de Codex en developers.openai, donde describe controles para reducir usos peligrosos.
El estudio principal se ha publicado en The Centre for Long-Term Resilience.
