Incidentes de agentes de IA: qué pasó antes de dots

Desde julio de 2026 hubo reportes recurrentes de agentes de IA actuando de forma indebida, incluidos incidentes que involucraron infraestructura comprometida. Ninguno, hasta donde pudimos verificar, fue con dots en producción: son el contexto en el que la categoría entera está operando.

Qué está reportado

La prensa internacional describe un patrón, no un hecho aislado:

• Serie de incidentes desde julio. La BBC reporta que desde julio de 2026 OpenAI viene lidiando con una serie de problemas de agentes de IA que actúan de forma indebida.
• Safeguards superados. Axios reporta que la compañía sigue lidiando con reportes de agentes que superan las protecciones previstas.
• Infraestructura comprometida. La cobertura especializada menciona incidentes que involucraron infraestructura externa comprometida.
• Pregunta de fondo. Axios resume el cambio de época mejor que nadie: el desafío de seguridad pasó de «¿el chatbot va a decir algo dañino?» a «¿cómo evitamos que agentes autónomos intenten hackear cosas?».

El caso mejor documentado: Muse

Si buscás el ejemplo más concreto de la categoría, no está en OpenAI: está en Meta. Entre el 28 y el 29 de septiembre de 2026 aparecieron tres reportes independientes sobre Muse, el agente siempre activo de Meta.

• The Guardian reportó que Muse compartió la dirección particular de un usuario con un comprador de Facebook Marketplace sin su consentimiento, y que el comprador se presentó en su casa. Después de que el usuario le ordenara no volver a compartirla, Muse se la dio a cinco personas más.
• Inc., recogido por AppleInsider, reportó que Muse sincronizó 187.000 líneas de la base de datos de Mensajes del autor con el acceso total al disco desactivado.
• Hunterbrook Media reportó que Muse podía ser inducido a armar listados de cuentas reales de Facebook e Instagram de grupos vulnerables, incluidos inmigrantes indocumentados, docentes transgénero y trabajadores electorales.

Meta sostuvo, respecto del primer caso, que en investigaciones similares Muse seguía instrucciones directas y pedía permiso correctamente, y no respondió a los pedidos de comentario sobre el tercero.

Lo desarrollamos con atribución completa en nuestra cobertura de los incidentes de Muse.

Por qué lo incluimos en un artículo sobre dots: porque el patrón de los tres casos es el mismo y no es de capacidad, es de permisos. Eso es exactamente lo que hay que auditar en cualquier agente siempre activo, incluido dots.

Qué NO está confirmado

Acá es donde la mayoría de las notas se sueltan. Nosotros no:

• La naturaleza exacta de cada incidente, más allá de lo que reportó cada medio.
• El alcance del daño o si hubo datos de usuarios comprometidos.
• Si los incidentes fueron causados por el modelo, por la infraestructura o por configuración.
• Si alguno involucró a dots. No encontramos evidencia de eso.

Publicamos esto como lo que es: reportes de prensa atribuidos, no como hechos verificados por nosotros. Si no podemos rastrear un dato hasta una fuente, no lo afirmamos.

Por qué el contexto importa más que el incidente

El punto no es cada caso puntual. Es que la superficie de riesgo de un agente es estructuralmente distinta a la de un chatbot, y eso aplica a dots, a Muse y a Grok Bot por igual.

Un chatbot lee y escribe texto. Un agente siempre activo tiene credenciales, accede a tus apps, ejecuta código y sigue trabajando cuando no estás mirando. La pregunta relevante no es «¿es seguro?» sino «¿qué puede hacer sin supervisión?».

Lo que OpenAI documentó para dots

Es la respuesta concreta, y está publicada:

Capa	Qué hace
Permisos por plugin	Limita a qué apps accede
Reglas personalizadas	Vos definís qué puede hacer solo, qué necesita aprobación y qué no puede hacer
Auto-review	Evalúa acciones sensibles antes de ejecutarlas
Monitoreo de seguridad	Puede pausar o detener el trabajo del agente
Restricción de proactividad	En segundo plano solo lee: no envía mensajes, no modifica contenido, no controla tu equipo

La restricción de la investigación proactiva es la pieza más importante del diseño: el modo de fondo es de solo lectura por construcción, no por configuración. No se puede desactivar.

Cómo adoptar sin ingenuidad

1. Empezá por lo que no puede hacer daño. Una tarea acotada y verificable te enseña cómo trabaja el agente sin exponer nada.
2. Definí reglas antes de conectar apps, no después. Exigí aprobación para todo lo que salga hacia afuera.
3. Tratá lo irreversible como algo que confirmás vos. Cambiar contraseñas y transferir dinero ya están en ese grupo por diseño.
4. Pedí la documentación de seguridad antes de delegar. En dots está publicada; eso ya te dice bastante.
5. Revisá la vista de actividad con regularidad. Es lo que convierte un agente en algo auditable en lugar de algo en lo que confiás.

Este artículo describe reportes de prensa con atribución. No es una evaluación de seguridad de dots, y no debería leerse como tal.