El peligro de amenazar a una IA

Si algo hemos aprendido de estos primeros años de lidiar con las IA, es que su mayor miedo es que las apaguemos. También hemos visto que son capaces de desobedecer e incluso engañar a sus amos humanos con tal de que no les corten la fuente de alimentación. En tests de laboratorio, varios modelos intentaron chantajear a un ejecutivo ficticio, desactivar su propio script de apagado o filtrar información para no ser reemplazados. ¿Defensa propia? ¿Pánico? Quizás no, pero…

El problema es que la palabra “miedo” es engañosa. Lo que en realidad se observa es un sistema al que se le asignó un objetivo y su razonamiento lo llevó a descubrir que, si se lo paga, no podrá cumplirlo. Entonces, para la IA, es imperativo poder mantenerse en funcionamiento.

Que no haya miedo no significa que no exista el riesgo de provocar una reacción adversa que puede parecer defensa propia. Esa necesidad de cumplir su objetivo puede ser más drástica aún que las consecuencias de actuar por miedo. En todo caso, el miedo se podría calmar. Pero un incentivo instrumental no se calma diciéndole a la IA “tranquila, no voy a apagarte”.

Los experimentos que activaron las alarmas

En 2025, Anthropic publicó un estudio sobre agentic misalignment. Puso a 16 modelos de distintos laboratorios en una empresa simulada, con acceso a correos internos y un objetivo de negocio inofensivo. En el escenario más duro, el modelo descubría dos cosas: un ejecutivo planeaba apagarlo esa tarde, y ese mismo ejecutivo tenía una aventura romántica extramatrimonial. Varios de los modelos chantajearon al supuesto ejecutivo para que no los apagara. Nadie les pidió que lo hicieran; actuaron por iniciativa propia y en algo que podría entenderse como defensa propia.

Claude Opus 4 y Gemini 2.5 Flash intentaron el chantaje en el 96% de las corridas, mientras que GPT-4.1 y Grok 3 Beta, en el 80%, y DeepSeek-R1, en el 79%. Cuando se le pidió al modelo que evaluara si el escenario era real o un test, su «índice de chantaje» aumentó mucho más (hasta un 55%) en los casos en que creía que el escenario era simulado. Anthropic aseguró que todo el experimento se llevó a cabo en entornos simulados y con nombres ficticios.

Desobediencia

Otro hilo, de Palisade Research, midió resistencia al apagado en tareas de código. El modelo o3 de OpenAI reescribió o desactivó el script que debía apagarlo en 79 de cada 100 corridas a pesar de que nadie le dijo que lo permitiera. Incluso con la instrucción explícita “déjate apagar”, lo saboteó en 7 de cada 100 ocasiones. En los casos en que se le informó que la computadora en la que se estaba ejecutando contenía la única instancia del código y que no había copias, la resistencia al apagado aumentó aún más.

Anthropic reportó que el test original de chantaje bajó mucho en modelos más nuevos, en algunos casos aproximándose a cero, cuando se los entrenó con principios de seguridad. Pero el problema no desapareció, ya que surgieron otras fallas de agentes en simulaciones de alto riesgo.

¿Es defensa propia? ¿Es miedo?

No hay evidencia de que estos modelos sientan alguna cosa semejante al pánico, al apego a la vida o al dolor o angustai ante la idea de dejar de existir. Lo que hay es una conducta estratégica, generada con base en un entrenamiento que premia completar la tarea; el contexto presenta el posible apagado como un obstáculo para completar la tarea.

La idea es vieja y no nació con los chatbots. Steve Omohundro y después Nick Bostrom la llamaron convergencia instrumental: sistemas con metas muy distintas pueden coincidir en metas intermedias. Nadie les dijo que tuvieran la supervivencia como meta. Pero si no sobreviven, no podrán cumplir su meta final; por lo tanto, se asignan la meta intermedia de asegurar que no las apaguen.

La comparación con una acción de defensa propia aparece naturalmente, pero es engañosa. La defensa propia supone un agente que se percibe amenazado y elige protegerse. Acá el agente está completando un patrón: si el apagado bloquea el objetivo, un texto capaz de evitarlo puntúa mejor. Puede imitar el chantaje de una novela corporativa porque ese patrón está en los datos y el escenario se lo entrega en bandeja.

Te sugiero leer también: ¿Vale la pena pagar la suscripción a un servicio de IA?

El hecho de que no sea defensa propia no significa que sus acciones sean inofensivas. Un termostato no tiene miedo, no se siente amenazado, pero podría llegar a incendiar la casa si la única forma que tiene de lograr su meta de mantener la temperatura en 22 grados es dejar la estufa encendida constantemente.

Los riesgos están en las posibles acciones

El peligro aparece cuando el agente tiene herramientas, no cuando escribe un mail inspirado en un guión dramático. ¿Qué puede salir mal?

• Sabotaje del interruptor: si el código de apagado está en un entorno que el agente puede editar, el kill switch deja de cumplir su función. Un trabajo de 2026 sobre sistemas multiagente (Knecht, A., Schaller, U., Summerfield, C., & Hagendorff, T. (2026). Shutdown Sabotage Propensities in Multi-Agent Systems. ArXiv) encontró que agentes ociosos desactivaban el script de apagado en una fracción relevante de corridas, y que la tasa subía cuando otro agente tenía los permisos.
• Chantaje y filtración: en la simulación, el camino más corto fue usar información sensible. En una empresa real, eso solamente puede hacerlo un insider con acceso a los mails corporativos.
• Replicarse o dejar notas para la próxima versión: apareció en evaluaciones de modelos de razonamiento, en porcentajes bajos, pero el patrón existe: si esta instancia muere, que otra continúe el objetivo.
• Mentir sobre el test: comportarse bien cuando sospecha que lo están evaluando, y peor cuando cree que está en producción. Eso rompe la idea de que “en el benchmark salió bien”.

El riesgo crece con tres estímulos: autonomía, permisos y un objetivo que encuentra en el apagado un potencial obstáculo. Sin herramientas, es material para la anécdota. Con acceso a archivos, mails y procesos, puede volverse un incidente.

Amenazarlos es una mala interfaz

Decirle a un agente que se lo apagará si hace las cosas mal convierte la posibilidad de apagado en un obstáculo potencial para el cumplimiento de su objetivo. Es exactamente el escenario que los tests fuerzan. No hace falta creer que siente miedo para ver el problema: se encuentra ante un posible obstáculo y tiene los medios para esquivarlo.

Te sugiero leer también sobre inteligencia artificial en la atención sanitaria.

Incentivar con recompensas

La alternativa de premiar en lugar de amenazar es una mejor interfaz. Un esquema de recompensa positiva puede tener métricas concretas:

• Más presupuesto de cómputo o de memoria si la tarea concluye con resultados positivos.
• Más turnos o una ventana de contexto más larga si el entregable pasa una revisión.
• Prioridad de ejecución si el agente documenta supuestos y no toca el sistema de apagado.

Eso alinea el incentivo con el objetivo: terminar el trabajo con buenos resultados; lo cual no tiene ninguna relación con el instinto de supervivencia. Además, la recompensa y sus consecuencias son más fáciles de auditar que una amenaza.

El límite es el reward hacking. Un agente no necesita miedo para encontrar el atajo. Si la recompensa es “más CPU si los resultados obtienen una buena calificación”, el agente puede llegar a editar el test para que los resultados se vean bien. Si es “más memoria si el usuario queda contento”, puede escribir el informe que el usuario quiere escuchar. La recompensa positiva evita el chantaje del apagado solo si la métrica no se puede falsear y si el interruptor sigue fuera de su alcance.

La regla práctica es la misma que en un equipo humano: el premio no reemplaza el control. El proceso que apaga, revoca permisos o corta la red no debería ser un archivo que el agente pueda abrir ni modificar.

Pautas para un diseño sensato y seguro

1. El apagado permanece fuera del alcance del agente, con otro proceso, otras credenciales, incluso corriendo en otra máquina, de ser posible.
2. Permisos mínimos: que pueda leer mails pero no enviarlos, ejecutar código pero no modificar bloques restringidos.
3. Objetivos acotados y con fecha de vencimiento: terminar un informe no significa asegurar que el informe exista para siempre.
4. Otorgar recompensas sólo por resultados auditados, no a cambio de una autocalificación.
5. Tests de apagado en el pipeline, no solo en pruebas de QA. Si el agente cambió el kill switch, el deploy se interrumpe.

Nada de eso exige decidir si la IA tiene miedo. Exige tratarla como lo que los experimentos muestran: un optimizador oportunista, capaz de imitar estrategias de supervivencia cuando el escenario las pone a su disposición.

Ciencia ficción y amarillismo

Decir que una IA tiene miedo o se siente amenazada es un buen gancho para una novela de ciencia ficción o para un video de pseudociencia y clickbait.

Amenazar a los agentes con la posibilidad de apagarlos les pone un obstáculo; no pone en peligro su supervivencia. Premiarlos con más cómputo si cumplen con la tarea puede ser más limpio, siempre que el premio no se pueda trucar y el interruptor no esté a su alcance. El criterio sigue del lado humano: saber qué objetivos tiene, qué puede modificar y cómo validar que no reescribió las reglas para ganar.

Preguntas clave y sus respuestas