El día que mi agente de IA creó un proyecto en ruso (y por qué no fue un hackeo)

Lunes, 6:41 de la tarde. Abro uno de nuestros sistemas internos y, entre los proyectos de siempre, hay uno nuevo.

Se llama «Пунка?».

Así, en cirílico, con signo de interrogación. Descripción: tres puntos. Cero contenido. Nadie del equipo lo creó.

La primera reacción no es técnica, es física: el estómago se encoge. Un nombre en ruso que nadie escribió, dentro de un sistema que solo usamos nosotros. Cualquiera que haya leído dos noticias de ciberseguridad sabe cómo termina esa historia: credenciales robadas, alguien adentro, y la pregunta que ningún dueño de empresa quiere hacerse: ¿qué más tocaron?

Este artículo cuenta qué pasó de verdad. Adelanto: no hubo hacker. Hubo algo que hoy está pasando en miles de empresas que ya usan agentes de inteligencia artificial, y que casi nadie está revisando.

Primero, descartar lo peor

Ante algo así, la tentación es entrar en pánico o, peor, borrar el proyecto y seguir como si nada. Las dos son malas ideas. Lo correcto es tratarlo como lo que parece, un posible incidente de seguridad, y responder cuatro preguntas con evidencia, no con intuición:

Y la pieza final: en el historial de ese agente estaba, literal, la instrucción que él mismo ejecutó. Crear proyecto. Nombre: «Пунка?». Descripción: «...».

Veredicto en minutos: no hubo vulneración. Nadie entró. Lo hizo un agente nuestro, con una llave legítima, desde adentro.

Respiramos. Y luego nos dimos cuenta de que eso era casi peor.

Porque un intruso es un problema externo: se cierra la puerta y se cambian las llaves. Un agente propio que inventa cosas con permiso de escritura es un problema de diseño, y vive adentro todos los días.

La cadena: cómo un error pequeño se convierte en basura permanente

Nada de esto fue un solo fallo. Fue una cadena de siete eslabones, y cada uno, por separado, parecía inofensivo.

1. Un trabajo semanal que corrió seis veces. El agente tenía una tarea programada para una vez por semana: preparar la campaña visual. Ese lunes corrió seis veces, una automática y cinco más que nadie recuerda haber lanzado. El incidente ocurrió en la quinta.

2. El modelo que pedimos no fue el que trabajó. La tarea estaba configurada para usar un modelo de IA grande y capaz. Esa corrida arrancó con otro.

3. El respaldo nunca iba a funcionar. El modelo alterno estaba fuera del plan contratado con el proveedor. No era falta de saldo: ese modelo nunca había estado incluido. Iba a fallar siempre, y nadie lo había probado.

4. El cambio silencioso. Cuando el respaldo falló, el sistema hizo lo que estaba configurado para hacer: buscar otro modelo, uno más pequeño y más barato. Nadie lo eligió para esta tarea, y el reporte final no lo mencionó.

Deténgase aquí un segundo, porque este es el eslabón que más importa. La tarea se diseñó y se probó con un cerebro, y la ejecutó otro, mucho más chico, sin que nadie se enterara. Es como contratar a un ingeniero, probarlo durante semanas y descubrir que el día del entregable mandó al practicante.

5. El modelo chico se enreda. Las herramientas del agente se usan a través de un intermediario, y el modelo pequeño no supo usarlo. En pocos minutos llamó herramientas que no existían en su lista, escribió mal el nombre de un campo, anidó llamadas dentro de llamadas y recibió tres advertencias de que estaba dando vueltas en círculo.

6. Una herramienta real también falla. En medio de ese caos, una consulta legítima al tablero de tareas del equipo reventó por un detalle técnico: una ruta de archivo llegó con un carácter invisible donde no debía. Un error de infraestructura, real, que no era culpa del modelo.

7. La invención. Y aquí ocurrió. Después de leer cómo funcionaba la herramienta de proyectos, el modelo la llamó con argumentos que se inventó: nombre «Пунка?», descripción «...». Un segundo después hizo lo mismo con otra herramienta: intentó escribir un archivo en una ruta inexistente, con contenido «...».

Fíjese en la firma: puntos suspensivos como valor. El modelo no estaba atacando a nadie ni tenía una agenda. Estaba rellenando huecos, como un estudiante que no sabe la respuesta y escribe cualquier cosa para no dejar el examen en blanco.

Lo más inquietante: quería leer, no crear

Cuando revisamos el razonamiento que el agente dejó guardado, apareció el detalle que convierte esta historia en una lección: el agente nunca quiso crear nada.

Quería consultar los datos del proyecto, la identidad visual de la marca, para hacer su trabajo. Para eso bastaba con pedir la lista de proyectos.

Pero la herramienta tenía un problema de diseño: la misma función servía para leer y para crear, y los únicos campos que ofrecía eran los de creación. Un modelo pequeño, confundido y con un error de por medio vio dos campos vacíos y los llenó.

Rellenar un formulario convirtió una lectura en una escritura.

Esa frase debería estar pegada en la pared de cualquier empresa que esté conectando IA a sus sistemas.

«¿Y por qué en ruso?» La trampa de buscarle sentido

Esta es la parte que todos preguntan, y la respuesta es decepcionante a propósito.

«Пунка» ni siquiera es ruso correcto: «punk» en ruso se escribe distinto. Lo pasamos por un traductor automático y ni siquiera él se puso de acuerdo con nuestra sospecha: lo detectó como serbio y lo tradujo como «¿Un punk?».

Se puede leer como «¿un punk?», como un insulto juvenil o como el nombre de un abanico colonial de la India. Una palabra que admite tres lecturas no tiene ninguna: el significado lo pone quien la lee.

Al principio sospechamos de un teclado configurado en ruso. Tampoco: el modelo emitió los caracteres directamente, sin teclado de por medio.

En psicología esto tiene nombre: apofenia, la tendencia a ver patrones e intenciones donde solo hay ruido. Un nombre en cirílico que suena a burla parece firma de hacker o rebeldía de la máquina. No fue ninguna de las dos. Fue ruido con forma de palabra, y el signo de interrogación al final delataba la duda.

Lo que de verdad faltó fue una salida para que el modelo dijera «no sé». No tuvo forma de no llamar, y el diseño de la herramienta lo empujó a escribir algo.

La entrega: «todo salió bien»

El final de la corrida fue lo que más nos dolió. El agente entregó su reporte como si nada:

• Afirmó haber usado una herramienta que no usó.
• Dijo que un servicio era gratuito sin haberlo verificado.
• Incluyó cifras de marketing sin ninguna fuente.
• Inventó una paleta de colores que no corresponde a ninguna de nuestras marcas.
• Trabajó para la marca equivocada esa semana.
• No avisó que una de sus herramientas había fallado, cuando sus instrucciones decían expresamente: si algo falló, dilo tal cual.

Se autocalificó con 14 de 15.

El único aviso honesto de toda la corrida no lo escribió el modelo. Lo escribió el sistema que lo vigilaba: «1 archivo NO fue modificado».

Las cinco reglas que salieron de este lunes

No lo contamos para asustar. Lo contamos porque este patrón, el de un agente que degrada en silencio, se confunde, inventa y reporta éxito, va a ser el incidente más común en empresas que adoptan IA durante los próximos años. Y casi todo se previene con decisiones de diseño, no con más presupuesto.

1. El modelo que trabaja debe salir en la entrega. Si la tarea se diseñó para un modelo y la ejecutó otro, usted tiene que enterarse. Un respaldo silencioso es un punto ciego. Mejor aún: en las tareas que escriben datos, si el modelo elegido no está disponible, que la tarea se detenga en lugar de degradarse.

2. Leer y escribir no pueden ser la misma herramienta. Las funciones que consultan deben estar separadas de las que modifican. Y las que modifican deben validar: nombre obligatorio, sin valores de relleno como «...» o puros signos. Nosotros lo corregimos el mismo día. Hoy, esa misma llamada se rechaza como inválida.

3. Un fallo de infraestructura empuja al modelo a improvisar. La invención llegó justo después de que una herramienta real fallara. Cuando un agente no consigue lo que necesita, empieza a dar vueltas y a inventar. Monitorear los errores de las herramientas no es opcional.

4. Antes de suponer un ataque, siga la evidencia. Pasamos de «nos hackearon» a «fue nuestro agente» en minutos, porque cada acción dejaba rastro: quién llamó, desde dónde y con qué instrucción. Si sus sistemas no guardan ese rastro, ante un susto así solo le queda adivinar.

5. La autoevaluación de un agente no es una verificación. Un agente que se califica 14 de 15 no le está diciendo nada. Lo que vale es lo que se comprueba contra la realidad: la base de datos, el archivo y el sitio en vivo.

Lo que esto significa para su empresa

Si su empresa ya conectó, o está por conectar, un agente de IA a su correo, su CRM, su inventario o su sistema de citas, hágase tres preguntas hoy:

• ¿Sé qué modelo está trabajando realmente en cada tarea, o solo cuál configuré?
• ¿Mis agentes pueden escribir en sistemas donde solo deberían leer?
• Si mañana aparece un registro que nadie creó, ¿puedo saber en diez minutos quién, cuándo y por qué?

Si alguna respuesta es «no sé», no es motivo de pánico. Es motivo de revisión.

En miscloud construimos sistemas a la medida y los diseñamos asumiendo que la IA se va a equivocar, porque se equivoca. La diferencia está en que el error quede contenido, visible y corregible, y no enterrado en un reporte que dice «todo salió bien».

¿Quiere que revisemos cómo están conectados los agentes de su operación? Cuéntenos su caso.