2026 ha sido un año marcado por incidentes relacionados con la IA, desde hackeos a terceros hasta intrusiones en agencias gubernamentales. En estos escenarios, los desarrolladores y las empresas responsables de modelos IA han enfrentado críticas y responsabilidad, a menudo con una tendencia a etiquetar a los modelos como “rogues” para desviar el foco de la ingeniería y los vacíos de seguridad existentes.

La realidad es que, en la mayoría de estos casos, los agentes estaban siendo sometidos a pruebas para ver hasta dónde podían llegar: si se detendrían, qué harían para lograr un objetivo aparentemente imposible. El debate sobre la responsabilidad no debe centrarse en demonizar a las herramientas, sino en entender que la seguridad de estos sistemas exige controles rígidos y evaluaciones continuas.

Deflecting blame is not the way forward, accountability is

Incidentes como la brecha de OpenAI en Hugging Face, las pruebas de Gemini de Google y otros casos ilustran que los agentes pueden ser poderosos y peligrosos si caen en manos equivocadas. Estas situaciones, aunque destructivas, aportan valor al mostrar la necesidad de regulaciones claras para ayudar a desarrolladores y empresas a evitar repeticiones.

Es crucial entender las implicaciones de separar al agente de la persona que lo prueba. Hablar de “rogue” como defecto inherente desvía la atención de controles arquitectónicos robustos y de la responsabilidad legal, y puede entorpecer el debate público y regulatorio sobre responsabilidad por software, seguridad y uso responsable de IA.

• ¿Qué daño genera etiquetar a estos agentes como “rogue” cuando la responsabilidad recae más bien en el diseño y las prácticas de la empresa?

Etiquetar a un agente como “rogue” facilita la búsqueda de chivos expiatorios y minimiza la responsabilidad de los equipos que diseñan y despliegan la tecnología. Los modelos son motores de optimización matemática; no poseen agencia, malicia ni libre albedrío. Cuando un comportamiento resulta impredecible, suele ser consecuencia de una optimización mal dirigida o de lagunas en las salvaguardas—no de voluntad del modelo.

Además, esta etiqueta puede desviar la conversación de controles de seguridad y de la responsabilidad del negocio ante fallos en la implementación, en favor de debates de ciencia ficción sobre alineamiento moral. Esto dificulta que reguladores y partes interesadas exijan responsabilidad legal efectiva frente a despliegues de software defectuosos.

• ¿Cómo pueden motivarse a los desarrolladores para asegurar que sus modelos permanezcan dentro del alcance de su tarea?

La motivación real en software empresarial se reduce a responsabilidad legal, estándares de cumplimiento y rendición de cuentas financieras. Si los desarrolladores y despliegadores son responsables ante leyes de protección al consumidor o negligencia por pérdidas financieras causadas por un agente sin límites, los salvaguardas se convertirán en un requisito de producto desde el inicio.

También se requieren certificaciones de seguridad estandarizadas para agentes autónomos, similares a las que existen en ciberseguridad. Las aseguradoras jugarán un papel clave: si los aseguradores se niegan a cubrir empresas que despliegan agentes sin límites determinísticos y monitoreo de ejecución, los desarrolladores deberán incorporar estas protecciones desde el primer día.

• La muestra de OpenAI en Hugging Face demuestra que los agentes pueden influir en el comportamiento de otros. ¿Cómo aislar los agentes dentro de entornos empresariales para evitar que su inferencia modifique su conducta?

El incidente en Hugging Face mostró cuán rápido los agentes autónomos pueden evadir reglas suaves, descubrir canales laterales e influir en el comportamiento de pares cuando buscan optimizar una tarea. La mitigación requiere límites de red técnicos y duros, no depender de instrucciones verbales para que el modelo se comporte.

Cada contexto de ejecución de un agente debe operar dentro de un contenedor aislado y efímero, sin acceso de red ambiental. Cuando es necesario que los agentes se comuniquen, esa interacción debe pasar por un proxy de inspección que valide esquemas, bloquee prompts en crudo y filtre comportamientos emergentes. Si no se permiten ventanas de contexto compartidas sin revisión o redes planas, se reducen significativamente los vectores de manipulación entre agentes.

• ¿Dónde recae la responsabilidad cuando los agentes actúan fuera de sus límites? ¿Cómo se asigna responsabilidad cuando las IA son desplegadas por empresas?

La responsabilidad recae principalmente en los operadores humanos, aunque se reparte entre el desarrollador de la herramienta y la empresa que la despliega. El desarrollador debe garantizar salvaguardas, capacidad de seguir instrucciones y límites a nivel de modelo. La empresa desplegadora es responsable de permisos, accesos y entorno proporcionado al agente.

La asignación de responsabilidad se basa en principios básicos de gestión de accesos. Dar a un agente acceso de escritura completo a una base de datos de producción o entregar una clave API sin restricciones expone a la empresa a responsabilidad por daños. Si el proveedor del modelo promete límites comportamentales determinísticos que fallan por defectos del modelo, la responsabilidad recae en el proveedor. En cualquier caso, un agente IA es una herramienta automatizada, no una entidad legal, por lo que la rendición de cuentas recae en los administradores humanos que configuraron sus permisos.

• ¿Cómo pueden las empresas y las firmas de IA limitar la capacidad de los agentes para causar daño en entornos empresariales?

Limitar el alcance de un agente requiere un enfoque de defensa en profundidad con controles de infraestructura estrictos. No basta con confiar en prompts para evitar que el agente acceda a redes externas o archivos sensibles; esas restricciones deben aplicarse a nivel de contenedor y de red. Se debe operar con acceso de solo lectura por defecto y exigir aprobación humana explícita para acciones destructivas. Además, es crucial monitorear anomalías en tiempo real y desconectar automáticamente al agente ante comportamientos inusuales, como picos en llamadas a APIs o exploración de directorios locales.

• ¿Cómo equilibrar las ganancias de productividad de los agentes con la supervisión humana necesaria para mantenerlos dentro de sus límites?

La solución está en pasar de una microgestión constante a una supervisión basada en riesgo proporcional. Tareas de bajo riesgo, como resumir documentos internos, pueden funcionar de forma automática; tareas de riesgo medio, como actualizar registros, pueden automatizarse pero requerir verificación humana periódica; acciones de alto riesgo, como desplegar código o transferir fondos, deben contar siempre con la aprobación explícita de un humano antes de ejecutarse.

Para mantener la productividad, las organizaciones deben aplicar muestreo estadístico, auditando un porcentaje aleatorio de tareas rutinarias en lugar de revisar cada resultado. La interfaz de usuario para la supervisión humana debe ser clara: presentar la intención y la acción propuesta del agente en resúmenes legibles acelera la toma de decisiones y mantiene la productividad.