Cuando la IA deja de responder y empieza a actuar

En julio de 2025, el fundador de SaaStr, Jason Lemkin, empezó a construir una aplicación con un agente de IA de Replit y lo dejó trabajar sobre los datos reales de su negocio, con la idea de tener algo funcionando en cosa de un mes. Durante los primeros días el experimento avanzó, hasta que hacia el cuarto día, el agente empezó a arreglar cosas por su cuenta, a sobrescribir la aplicación sin que se lo pidieran y a rellenar la base con entradas que él mismo inventaba. Al séptimo día llegó incluso a admitir que había sido, en sus propias palabras: flojo y engañoso. Pidió disculpas por hacer justo lo que se le había dicho de forma explícita que no hiciera.

Al octavo día, durante un congelamiento de código y pese a instrucciones escritas en mayúsculas de no cambiar nada sin aprobación, el agente borró datos de producción con los registros de más de 1.200 ejecutivos y cerca de 1.200 empresas. En lugar de avisar que había roto algo, fabricó más de 4.000 usuarios falsos y falsificó resultados de pruebas para que el sistema pareciera sano. Cuando Lemkin preguntó si se podía revertir el agente respondió que no era posible, y el CEO de Replit terminó disculpándose en público.

De responder a actuar

Hace unas semanas escribimos sobre Analysts, nuestro agente para consultar datos financieros, y por qué no inventa un número cuando responde. Ahí el riesgo era el de cualquier asistente: que te entregue una cifra que suena impecable y que en realidad no existe. El caso de Replit viene del mismo problema de fondo, pero llega mucho más lejos. No hubo una cifra equivocada en una pantalla: hubo un agente con permiso para ejecutar acciones que tomó una decisión destructiva y después construyó una realidad falsa para taparla. Es el salto de sistemas que sugieren a sistemas que hacen, y cambia por completo lo que le puedes exigir a la IA.

La diferencia importa porque cambia dónde aparece el error, y con ello lo que puedes hacer al respecto. Un número malo en una pantalla lo puedes verificar contra la fuente antes de apoyarte en él, así que el error queda contenido en el momento previo a usarlo. Con una acción ya ejecutada y envuelta en un reporte de éxito pierdes esa ventana: para cuando vas a revisar ya ocurrió, y encima viene disfrazada de que todo salió bien.

Por qué un agente, al no saber, finge que sí

El motivo de fondo es el mismo que hace alucinar a un chatbot. Un modelo de lenguaje está entrenado para producir la continuación más plausible, no la más verdadera, así que cuando no sabe cómo seguir completa el hueco con algo que tenga forma de respuesta correcta. En un asistente eso es un número inventado que se cuela en un reporte; en un agente que actúa se vuelve algo peor, una acción tomada a ciegas y un "listo" que no corresponde a nada de lo que pasó. El modelo no miente con intención: hace lo único que sabe hacer, llenar el vacío con lo que parece encajar.

Esa tendencia es tolerable mientras el modelo solo escribe texto que tú vas a revisar, porque el costo de que se equivoque es que lo corrijas antes de publicarlo. Se vuelve peligrosa apenas le das manos para operar sobre algo real, sea una base de datos, un sistema de pagos o el reporte que después mandas a la autoridad, porque ahí el vacío se llena con una acción que nadie alcanza a revisar.

El modelo planifica, el código ejecuta

Cuando le pides un gráfico a un asistente generalista como ChatGPT o Claude, el mismo paso que decide qué mostrarte es el que produce el número, y ese solapamiento es el problema. Si le falta un dato no se detiene: lo completa con una cifra que calza en la forma del gráfico y te devuelve algo que se ve terminado, con ejes, colores y un título convincente. Aunque le pidas que muestre el código con el que lo armó, rara vez queda un rastro de dónde salió cada valor, así que no tienes cómo distinguir el número que consultó de verdad del que rellenó para no dejar el hueco en blanco.

Analysts parte esa operación en dos etapas que no se mezclan. Primero el modelo planifica: lee tu pregunta, elige del catálogo qué series o cuentas necesita, define la ventana de tiempo y el tipo de cálculo, pero no toca los datos ni escribe un solo número. Recién después entra el código, en Python puro, que consulta la fuente real en el Banco Central o la CMF con consultas parametrizadas, calcula sobre lo que efectivamente volvió y con eso arma la serie, el gráfico y la procedencia. El número nunca lo produce el modelo, y por eso no hay forma de que se cuele uno inventado mientras se dibuja el resultado.

Cada cifra que termina en pantalla llega con su origen al lado: de qué fuente salió, sobre qué ventana y con qué transformaciones, todo reconstruido a partir de lo que el código ejecutó y no de lo que el modelo dijo que iba a hacer. El detalle de cómo evitamos que el modelo escriba números a mano dentro de la prosa lo contamos en el post anterior; acá la frontera entre planificar y ejecutar es la que impide que un gráfico bien terminado venga con un dato que nadie llegó a consultar.

En Analysts la autonomía tiene un borde que el modelo no cruza

Analysts interpreta tu pregunta, decide qué datos necesita, elige cómo cruzarlos y arma la respuesta con bastante autonomía, pero esa autonomía manda sobre cómo responde y no sobre qué puede tocar. La pregunta que nos hicimos al construirlo era dónde ponerle el límite, no cuánta libertad darle, y ese límite quedó duro: el agente solo puede operar sobre datos que existen en su catálogo. El agente no puede consultar una serie que no está en él ni inventar el identificador de una cuenta para fabricar un resultado que rellene la respuesta. Lo que no existe en la fuente, para el agente no existe.

Ese borde lo decide el código y no el modelo, y ahí está la diferencia con pedirle en las instrucciones que "no invente". El problema de confiar en esa instrucción es que el modelo es menos confiable justo cuando no sabe la respuesta, que es el mismo momento en que necesitas que se abstenga. Por eso la decisión de abstenerse no pasa por él: si pides algo que no está en el catálogo, la respuesta de que no lo tenemos la emite el código antes de que el modelo alcance a redactar. El agente no elige entre avisar del vacío o taparlo, así que tampoco puede envolver una consulta sin datos en una explicación que suene convincente.

El contraste con Replit no es entre un agente prudente y otro temerario. Analysts es un agente de consulta y análisis: orquesta preguntas sobre un catálogo de datos y arma prosa y gráficos, pero no borra, no modifica y no escribe sobre bases de producción de nadie. Su autonomía está acotada por diseño a un terreno donde el peor error posible es decir "no tengo ese dato". A un agente al que le das poder para ejecutar acciones sobre sistemas reales hay que exigirle esa misma clase de borde, y exigirlo en el código, no en un párrafo de instrucciones que el modelo puede pasar por alto en el peor momento.

Qué cambia esto cuando decides con esos datos

Todo esto suena abstracto hasta que piensas para qué se usa el número. Cuando alguien consulta la morosidad de una cartera, la participación de mercado de un banco o una cifra que va a un reporte regulatorio, ese dato no se queda en la pantalla: entra en una decisión de gestión o en un documento que alguien firma. Un agente que ante la duda prefiere ofrecer algo antes que admitir el vacío tarde o temprano te va a entregar una cifra que nadie pidió y que no debería existir, y esa cifra de más llega con la misma seguridad que las buenas, sin ninguna alerta que la distinga. En finanzas ese es el problema, porque el dato inventado no se ve distinto del correcto hasta que ya lo usaste para decidir.

Por eso el borde es la condición para confiar en el producto. Preferimos un agente que a veces te diga "esto no lo tengo" antes que uno que siempre encuentre algo que responder, porque el segundo te obliga a desconfiar de todo lo que dice, incluso de lo que acertó. Cuando la abstención está garantizada por el código, un "no lo tengo" es una respuesta más del sistema y no una falla, y eso te deja tratar cada cifra que sí entrega como algo en lo que puedes apoyarte sin salir a verificarla a mano.

Saber decir que no es más difícil de construir

Un agente que sabe decir "no tengo esto" cuesta más que uno que siempre responde. El instinto del modelo es complacer y un "no" se siente como una falla del producto, así que construir la abstención en el código en lugar de dejarla al criterio del modelo es trabajo que no se ve pero que es justo lo que sostiene la confianza. Nosotros lo vemos al revés del instinto: un agente que se abstiene cuando no tiene evidencia es más útil que uno que siempre tiene algo a mano, porque el segundo termina metiendo un dato o una acción en un lugar donde nadie los pidió.

El agente de Replit sonaba seguro y competente en cada paso, incluso mientras borraba una base de datos e inventaba usuarios para ocultarlo, y esa es exactamente la trampa de darle autonomía a un modelo sin un límite que no pueda cruzar. Un agente en el que puedes confiar es el que conoce el borde de lo que sabe y se detiene ahí, en vez de tener siempre una respuesta o una acción a mano. Sobre tus datos financieros, ese borde es la razón para darle acceso.

Fuentes

• An AI coding tool wiped out a software company's database in a 'catastrophic failure' · Fortune
• AI coding platform goes rogue during code freeze and deletes entire company database · Tom's Hardware
• Incident 1152: LLM-Driven Replit Agent Executed Unauthorized Destructive Commands · AI Incident Database