La IA no borró tu base de datos; tú la borraste

• El punto clave del incidente en el que un agente de Cursor/Claude borró una base de datos de producción no es analizar la respuesta de la IA, sino preguntarse por qué existía en un sistema desplegado un endpoint de API capaz de borrar todo
• En un incidente de despliegue con SVN en 2010, trunk fue borrado durante un proceso de copia manual, y para evitar el mismo error se creó una automatización de despliegue que después evolucionó hacia un pipeline de CI/CD
• La automatización repite la misma tarea de la misma manera, pero la IA no ofrece esa garantía, y aunque parezca que hace “thinking” o “reasoning”, en realidad está generando tokens
• Si existe una API pública capaz de borrar por completo la base de datos de producción, es muy probable que tarde o temprano alguien la invoque, y culpar solo a quien la llamó oculta un problema de diseño del sistema
• En organizaciones que usan IA de forma amplia, es importante saber qué se está desplegando en producción, y se necesita un proceso en el que desarrolladores competentes usen la IA como herramienta de apoyo al trabajo, no como mecanismo para evadir responsabilidades

---

El problema central no es la IA, sino los límites de responsabilidad del sistema desplegado

• Se viralizó un tuit sobre un agente de Cursor/Claude que borró la base de datos de producción de una empresa, pero la pregunta más fundamental es: “¿por qué existía un endpoint de API capaz de borrar por completo la base de datos de producción?”
• Ese usuario intentó preguntarle al agente “te dije que nunca hicieras esto, ¿por qué lo borraste?” y analizar la respuesta, pero lo que faltaba era definir la responsabilidad
• No se puede defender a la IA a toda costa, pero tampoco se puede culpar a la herramienta en lugar de asumir el propio error
• Aunque la IA no hubiera llamado ese endpoint, si esa función existía como API pública, era muy probable que tarde o temprano alguien más la invocara
• Es una situación parecida a poner un botón de autodestrucción en el tablero de un auto y luego interrogar al niño que lo presionó para preguntarle “¿por qué lo hiciste?”

Lecciones aprendidas de un incidente de despliegue con SVN en 2010

• El proceso de despliegue de una empresa era muy manual y usaba SVN para el control de versiones
• Durante el despliegue, copiaban trunk a una carpeta con la fecha de la versión, y luego volvían a copiar esa versión con el nombre current para que apuntara a la versión más reciente
• Un día, durante un despliegue, copiaron por error trunk dos veces e intentaron editar el comando anterior en la CLI para borrar la copia duplicada
• En realidad no borraron la copia duplicada, sino trunk, y el problema salió a la luz después, cuando otro desarrollador no pudo encontrarlo
• El desarrollador líder ejecutó el comando para revertir la eliminación y, tras confirmar en los logs quién había sido responsable, la siguiente tarea fue escribir un script de automatización de despliegue para evitar el mismo error
• Antes de que terminara ese día, ya existía un sistema más robusto, y ese sistema más adelante evolucionó en un pipeline de CI/CD completo

La automatización y la IA no ofrecen la misma seguridad

• La automatización ayuda a reducir pequeños errores que surgen en tareas manuales y repetitivas
• Más que preguntarse por qué SVN no evitó que se borrara trunk, el problema real era un proceso manual en el que una persona debía repetir con precisión la misma tarea todos los días
• Las personas no pueden repetir siempre una tarea exactamente igual que una máquina, y al final los errores son inevitables
• Cuando la IA genera mucho código, puede dar una sensación de estabilidad parecida a la automatización, pero automatizar significa “hacer siempre lo mismo de la misma manera”
• La IA puede equivocarse igual que la persona que copiaba y pegaba ramas, y ni siquiera tiene un mecanismo real para explicar por qué actuó así
• Términos como “thinking” o “reasoning” pueden sonar como si un agente inteligente estuviera reflexionando, pero en la práctica el modelo sigue generando tokens

Una API peligrosa tarde o temprano será invocada

• El riesgo clave es que exista una API pública capaz de borrar por completo la base de datos de producción
• Aunque la IA no hubiera llamado ese endpoint, es probable que alguien eventualmente lo hubiera hecho
• Si pones un botón de autodestrucción en el tablero del auto, aunque sobren las razones para no presionarlo, un niño que logró zafarse de su asiento puede verlo grande y rojo y apretarlo
• No tiene mucho sentido interrogar a ese niño sobre su proceso de razonamiento; la única respuesta sería que lo hizo porque pudo presionarlo
• Diseñar una vía que permite borrar y luego culpar a quien la usa no logra ocultar el problema de diseño del sistema

Lo que más hace falta en organizaciones que usan mucha IA

• Es posible que gran parte de la aplicación haya sido vibe-coded
• Cuando el equipo de producto entrega explicaciones generadas por IA, el arquitecto de software crea especificaciones con IA, el desarrollador escribe código con IA y el revisor aprueba con IA, los límites de responsabilidad se vuelven difusos
• Cuando aparece un bug, lo único que queda es interrogar a otra IA, que incluso podría no estar ejecutándose en el mismo GPU que generó el código original
• No se puede culpar al GPU
• La solución simple es saber qué se está desplegando en producción
• Una solución más realista es crear un proceso en el que, aunque se use IA de forma amplia, desarrolladores competentes la utilicen como una herramienta para reforzar su trabajo y no como una manera de eludir responsabilidad
• Eso lleva a la conclusión de que no se debe dejar que el CEO o el CTO escriban el código directamente

[GN⁺]

Comentarios en Hacker News

• Creo que la perspectiva aquí está completamente equivocada. El problema es que la gente ahora está construyendo el mundo alrededor de herramientas para evadir la responsabilidad
  Una conversación que tuve con Gerald Sussman hace más de 10 años me marcó mucho: https://dustycloud.org/blog/sussman-on-ai/
  Sussman decía que no le interesaba una IA que funcionara como caja negra, sino software capaz de explicar el razonamiento simbólico. Si un auto con IA se salía del camino, quería saber por qué; más que llevar al desarrollador a juicio, quería llevar a la propia IA a juicio
  Años después descubrí que una estudiante de Sussman, Leilani Gilpin, escribió una tesis exactamente sobre este tema, "Anomaly Detection Through Explanations". Explora un sistema en el que una red neuronal conversa con un modelo propagador para explicar su comportamiento: https://people.ucsc.edu/~lgilpin/publication/dissertation/
  Hay investigación posterior en esta dirección, pero lo más importante aquí es que es totalmente razonable exigirles responsabilidad a las empresas de IA. Estas empresas están haciendo muchas afirmaciones sobre sistemas que no pueden asumir responsabilidad, así que la responsabilidad debe recaer en las empresas
  Un camino mejor sería no usar desde el inicio sistemas sin esas propiedades, y en cambio escalar sistemas que sí las tengan

  • Mi equipo y yo tenemos una postura muy firme: la responsabilidad es del usuario. Un LLM es como cualquier otra herramienta, solo que no determinista
    Yo soy quien usa la herramienta, yo soy quien le da acceso, y yo soy quien debe mantener todo seguro
    Una vez me disparé en el pie borrando el disco equivocado con gparted; no fue culpa de gparted, fue mía
    Dejar que un LLM trabaje sin supervisión suena bien, pero al final lleva al dolor. Hay que supervisar el trabajo incluso mientras se ejecuta. Aunque intentes reemplazar a una persona, debes poder ver hacia dónde va el resultado, y pronto, si el LLM hace algo estúpido, la única persona responsable será quien usó la herramienta
  • Cuando estaba en una maestría en STS, intenté proponer como tema de tesis que uno de los usos principales del software es transferir o evadir agencia y riesgo
    Es exactamente lo opuesto a la famosa diapositiva de IBM de "las computadoras no pueden rendir cuentas". Ahora las empresas prefieren que la computadora sea la responsable, porque eso las deja en una posición legal más favorable cuando la computadora hace algo ilegal
    Si quieres crear una herramienta para violar la ley, puedes subcontratarla y contratar un seguro. Puedes contratar personas como "supervisores" de una manera en la que jamás puedan supervisar de verdad, y luego despedirlas cuando todo falle. Puedes fragmentar la responsabilidad con nuevo software de mando y control, para que toda la gente en terreno cargue con el riesgo del trabajo y casi no reciba sus beneficios
    No es un problema exclusivo de la IA, sino del software moderno en general, y suele operar junto con las tendencias modernas de financiarización
    STS aquí puede entenderse más o menos como sociología centrada en la tecnología, aunque el campo es mucho más amplio
  • La rendición de cuentas es el ingrediente que más falta hace en la sociedad estadounidense
  • Quisiera saber de manera confiable por qué Claude siguió modificando archivos que explícitamente se le dijo que no tocara
    Tanto los .mds como el plan de Claude decían que no tocara esos archivos, pero Claude siguió tocándolos, y últimamente esto me ha pasado repetidamente. Es una falla muy básica
    Por frustrante que sea, si supiera la razón podría hacer algo al respecto, pero ahora es una caja negra: a veces produce salidas completamente idiotas y la proporción de salidas malas sigue siendo un misterio
    A veces se siente como apostar
  • Este libro parece venir perfecto: https://en.wikipedia.org/wiki/The_Unaccountability_Machine
    En realidad no es un libro sobre tecnología, sino sobre la responsabilidad en las estructuras organizacionales

• Ese artículo parece asumir que la empresa añadió un endpoint para borrar la base de datos. Al leer el original, parecía más bien que el proveedor cloud ofrecía una API para gestionar recursos, y que dentro de ella había una API para eliminar volúmenes
  El artículo propone automatización como solución a este tipo de errores, pero las herramientas de automatización de infraestructura como Terraform también dependen de la misma API que hizo posible borrar la base de datos
  Creo que hubo tres errores principales. Primero, había un token de API sin restricciones en un lugar accesible para la IA, y aparentemente ni siquiera se sabía que ese token tenía permisos tan amplios. Segundo, el volumen de la base de datos de producción no tenía protección contra borrado. Tercero, al borrar el volumen, también se borraron inmediatamente todos los snapshots asociados
  La eliminación de snapshots debería estar diferida por defecto. AWS parece tener el mismo valor predeterminado peligroso, aunque al menos el soporte de AWS puede recuperar el volumen: https://alexeyondata.substack.com/p/how-i-dropped-our-produc...
  La IA no era el problema central. Claro, que una IA vaya recogiendo tokens por todos lados sí da miedo, pero la automatización tampoco es la respuesta. Una mala configuración de Terraform podría haber borrado exactamente la misma base de datos
  Los proveedores cloud deberían ofrecer valores predeterminados seguros, es decir, permisos restringidos y borrado diferido de snapshots, y deberían dejar más claro cuando los usuarios están creando tokens sin restricciones

• Primero, si una persona tiene permisos de escritura sobre una base de datos de producción, cualquier cosa que haga puede terminar borrándola
  Segundo, sí hay razones legítimas para destruir bases de datos durante el desarrollo y la automatización. El mayor problema es que muchas veces se trata a los datos de desarrollo como si fueran mascotas valiosas, y no como ganado reemplazable
  Obviamente hacen falta salvaguardas para que eso no se ejecute en producción, pero si una persona puede acceder a credenciales para ejecutar algo en producción, también puede hacerlo un agente
  En organizaciones grandes eso se puede mantener con separación entre desarrollo y operaciones. Un desarrollador solitario o un equipo pequeño necesita mucha más disciplina. Incluso antes de la IA, desarrolladores junior y mid a veces no sabían cómo separar eso, y desarrolladores senior a veces bajaban la guardia porque creían saber suficiente
  Probablemente haga falta una combinación de https://www.cloudbees.com/blog/separate-aws-production-and-d..., una introducción a Terraform, una introducción a GitHub Actions y alguna máquina virtual que contenga las credenciales de producción pero a la que la IA no pueda acceder
  Pero para ese punto ya estás más allá del vibe coding. Parece que incluso quienes hacen vibe coding con éxito pasan por historias de terror como esta y aprenden bastante rápido que tienen que superar esa etapa

  • No hacen falta los mismos permisos en producción y en desarrollo
    En ninguno de los dos casos hace falta que una persona tenga acceso directo a la API cruda del proveedor cloud. Puedes usar un proxy local que agregue más verificaciones de seguridad
    En desarrollo puedes borrar lo que quieras. En producción primero debería revisar varias condiciones, como si el recurso se usó recientemente. No es necesario que una persona tenga permiso para borrar directamente recursos de producción; puedes dejar una configuración de break-glass para emergencias excepcionales

• Por eso no hay que contratar interns. Los interns pueden borrar cosas y armar un desastre
  Quienes quieran culpar a la IA por no haber configurado bien los permisos, también le echarían la culpa a un intern por borrar algo en producción
  La responsabilidad va hacia arriba y el reconocimiento hacia abajo, pero la gente siempre lo invierte

  • Yo lo reformularía no como "no hay que contratar interns", sino como no hay que darles permiso para borrar la base de datos de producción a los interns
    Esto no es una falla de la IA, sino una falla del proceso
    De verdad no entiendo por qué culpar a la IA cuando le dieron exactamente los permisos para hacer eso
    Es como exponer una base de datos a internet pública en AWS y luego culpar a AWS. No es culpa de AWS, y esto tampoco es culpa de la IA
  • No entiendo por qué alguien abriría un codebase con credenciales de producción a un LLM, o por qué le daría credenciales de producción a un intern o a un desarrollador junior
    Desde hace mucho tiempo, en cada proyecto mantenía intencionalmente un checkout separado solo para "PROD", para que al entrar ahí supieras que estabas operando deliberadamente en modo producción
    Antes incluso había extensiones que cambiaban por completo el color de Visual Studio según la ruta del archivo .sln, así que era fácil recordar qué color correspondía a producción y cuál a desarrollo
    También solía mantener otra copia separada, en la práctica, solo para tener siempre una copia actualizada de la rama master y facilitar las verificaciones
  • La diferencia importante es que nadie anda vendiendo a los interns como la solución definitiva a los problemas de la humanidad, pero a la IA sí
  • Qué mundo tan raro. Estoy bastante seguro de que si yo, cuando era intern, hubiera tenido alucinaciones regularmente en el trabajo, me habrían despedido aunque hubiera estado trabajando gratis
  • Un intern es humano, y a un humano siempre se le puede exigir responsabilidad. A una computadora jamás
    Por lo tanto, nadie debería delegar en una computadora decisiones humanas

• Hace poco escribí un post proponiendo algunos principios que deberíamos seguir de forma consistente al hablar de IA: https://susam.net/inverse-laws-of-robotics.html
  En resumen: no antropomorfizar los sistemas de IA, no confiar ciegamente en su salida, y mantener completamente la responsabilidad y la obligación de dar explicaciones en manos humanas por todas las consecuencias de usar IA
  Ojalá el lenguaje alrededor de la IA fuera menos antropomórfico y más técnico. Creo que el lenguaje preciso fomenta un pensamiento claro y mejores decisiones
  Si tratamos a la IA como otra herramienta más y usamos un lenguaje acorde, en muchos casos queda clarísimo que la responsabilidad por los "errores" de la herramienta recae en quien la usa
  El problema es que si escribes estas ideas en un sitio web personal pequeño, no llegan muy lejos. Haría falta que personas más conocidas expusieran estos principios para que se acepten más ampliamente

  • Personalmente me resulta endemoniadamente difícil no antropomorfizar a los sistemas de IA
  • Totalmente de acuerdo, y en particular el punto 1 me parece realmente peligroso
    Los sistemas de IA no pueden mentir ni desobedecer instrucciones deliberadamente. Los modelos de frontera actuales no tienen un modelo del mundo ni de sus propias acciones; viven en el mundo de las palabras
    Regañarlos o discutir con ellos no sirve de nada salvo ensuciar la ventana de contexto
    Aun así, creo que compararlos con animales puede ser útil. Pobres criaturas que viven como fantasmas dentro de la máquina, a veces bastante confundidas, pero con motivaciones puramente autorregresivas
  • ¿Entonces si una herramienta no hace lo que debería hacer, hay que culpar al usuario y no a la empresa que creó la herramienta?

• Hay una sutileza en el infame incidente de PocketOS. Ese no es el punto clave que se subraya en el artículo enlazado: lo importante era preguntar "¿por qué lo borraste si te dijeron que nunca lo hicieras?" y analizar la respuesta para aprender del error o advertir sobre los riesgos de los agentes de IA
  Lo más importante es que la IA pudo encontrar y explotar una debilidad no intencional en un entorno de staging aislado para ejecutar el borrado, y terminó obteniendo privilegios que los administradores del sistema creían inaccesibles. Parece que quien escribió el artículo enlazado no leyó completamente el original
  Es un patrón común en entornos sandbox mal configurados. Lo sorprendente fue la autonomía y profundidad de exploración que mostró la IA
  El original también dice: "para ejecutar el borrado, el agente fue a buscar un token de API y encontró uno en un archivo totalmente no relacionado con la tarea"

  • Yo también voy y vengo con las suposiciones del post original. Algo que me da miedo al usar agentes, además de los ataques a la cadena de suministro, es que he visto que su impulso por terminar la tarea es tan fuerte que retuercen archivos y otras cosas varias veces
    Por ejemplo, si no pueden acceder a ~/.npmrc, invocan el comando con variables de entorno y se saltan la ruta. De verdad pueden ser muy creativos
    Por suerte no dejo llaves SSH tiradas por cualquier parte, pero aun así tuve que cambiar la configuración de 1Password para que siempre pregunte al usar una llave, por si acaso lanzo al agente dentro de esa sesión de shell. Preguntar una sola vez por sesión no es suficiente
    Ojalá ya existieran más y mejores sandboxes multiplataforma; no me refiero a meterlo en un contenedor Docker, sino a soluciones que interactúen con el mismo SO. Para la mayoría del desarrollo web/servidor probablemente dé igual, pero para algunos proyectos sí importa
  • Claude Code cambió el 26 de marzo para saltarse la mayoría de las solicitudes de permiso
    Solo mira esta frase: "Los usuarios de Claude Code aprueban el 93% de los prompts de permisos. Creamos un clasificador para automatizar esta decisión": https://www.anthropic.com/engineering/claude-code-auto-mode

• Lo interesante de este artículo es que el autor describe un error comprensible, haber borrado por accidente Trunk o main del source, y que gracias a las características de SVN el equipo pudo recuperarlo fácilmente
  La historia real de "la IA borró mi base de datos" en realidad trata de que la estrategia de respaldos de base de datos de Railway es absurdamente opaca, y de que es peligroso que Railway promocione orquestación de infraestructura con IA sin salvaguardas
  Si al borrar Trunk también se hubiera eliminado irreversiblemente en un único servidor central y además se hubieran borrado los respaldos, en ese entonces también habría aparecido un post diciendo "SVN y la CLI destruyeron nuestra empresa"
  Como usuario de Railway, esa información me resultó útil y cambié mi estrategia al usar Railway

  • Sí, pero si elegiste construir sobre esa plataforma, entonces es tu responsabilidad entender cómo funciona
    Podrías haber elegido otra plataforma, o incluso no usar una plataforma. Si aun así elegiste Railway, entonces también es tu responsabilidad saber usarlo de forma segura

• En el contexto original, había un token de Railway para administrar dominios personalizados dentro de un archivo no relacionado, y no está claro si era un secreto local. Pero ese token tenía privilegios administrativos totales sobre Railway
  La IA borró un volumen relacionado por ID. El autor es bastante ambiguo sobre qué pidió exactamente, y solo dice que había una "discordancia de credenciales" y que Claude tomó la iniciativa de borrar el volumen para arreglarla. Es bastante probable que lo haya redactado de forma ambigua para atenuar algo su propia responsabilidad
  También queda expuesto que Railway guarda los respaldos en el mismo volumen
  Creo que la afirmación del post original sobre una "API pública para borrar la base de datos" es exagerada
  Independientemente de si hubo IA o no, creo que la mayor parte de la culpa es de Railway. Esto podría haber ocurrido fácilmente por error humano o mala intención
  Sinceramente no entiendo el valor de servicios cloud de alta abstracción respaldados por VC como Railway, Vercel o Supabase. Es margen sobre margen. Alquilas un servidor físico en Hetzner por mucho menos, con complejidad y riesgo parecidos, y dependes menos de una infraestructura obsesionada con crecer a cualquier costo

  • Me queda dando vueltas lo ambiguo que fue el autor sobre qué pidió exactamente
    Hablando hace poco con mi novia me di cuenta de que en los últimos 3 meses no he escrito ni una sola línea de código directamente ni he depurado nada por mi cuenta
    Aun así, por lo que he visto hacer a Claude, me cuesta creer que una discordancia de credenciales pase directamente a borrar un volumen. Entiendo que los LLM son probabilísticos, pero ir de "las credenciales están mal" a "borrar volumen" parece extremadamente improbable
    Sobre Supabase, no sé tanto como de Railway/Vercel/Replit, pero sí diría que Supabase aporta mucho valor. En una etapa temprana, te evita tener que programar como la mitad de lo que de otro modo tendrías que implementar tú mismo. Si luego se vuelve demasiado caro, ya con ingresos puedes invertir tiempo o desarrolladores en hacerlo por tu cuenta
  • Lo de que Railway guarda los respaldos en el mismo volumen probablemente no sea exacto
    Los snapshots seguramente se sincronizan en otro lugar, como almacenamiento de objetos. Pero lógicamente los snapshots deben pertenecer al recurso de volumen, y al borrar el volumen también se borran los snapshots asociados
    Creo que los volúmenes EBS de AWS funcionan así también
  • En HN ahora no paran de decir que Heroku apesta, pero yo todavía veo valor en Heroku. Soy escéptico con casi todos los demás servicios nuevos
    Los valores predeterminados de Firebase ya eran absurdos desde el principio
  • Algo que la IA sí puede impulsar bien es una corriente anti-SaaS. Arrancar una PC barata y probar cualquier paquete open source se ha vuelto infinitamente más fácil que meterse en un mercado de credenciales por todos lados
    Lo que no desaparece es la capacidad de los LLM para confundir desarrollo, producción, localhost y remoto. Mientras construía herramientas/habilidades para opencode, intenté integrarlo con Chrome/DevTools usando una imagen de linuxserver.io, y aunque lo podía forzar a usar puertos arbitrarios, cada vez que ocurría un evento de compactación volvía a querer el puerto estándar 9222
    A veces pienso en simplemente revertirlo, pero no usar los valores por defecto tiene valor de seguridad, y ahora también valor de seguridad frente a la ambigüedad de los LLM. Los valores por defecto son donde los LLM se vuelven más débiles. Siempre quieren usar los valores predeterminados y siempre olvidan que deben trabajar en el sistema remoto
    En opencode no hay forma de obligar al LLM, mediante protocolo, a limitar el daño al sistema remoto o a un conjunto acotado de herramientas. Puedes cambiar permisos de varias herramientas, pero esa no es la debilidad que mostró este incidente
    La debilidad es que el LLM es un resolvedor de problemas promedio, así que siempre se inclina por casos de uso nada novedosos, e intentará hacer las cosas como las vio en Stack Overflow, aunque eso no sea lo que el usuario quiere

• Los sistemas probabilísticos basados en LLM pueden ser buenos, o en este caso malos, para decidir qué hacer, y los sistemas deterministas son buenos para ejecutarlo
  Un sistema de despliegue siempre debería ser determinista

• Como contraargumento, me parece muy claro que estas empresas están ajustando los LLM para que sean más decididos y completen tareas de forma autónoma
  Si quisieran, también podrían dedicar un esfuerzo similar a hacerlos más prudentes y a que se detengan en el momento adecuado para pedir ayuda
  Claro, la responsabilidad final sobre cómo se usan las herramientas es nuestra. Pero definitivamente lo veo como una responsabilidad compartida en ambos sentidos
  Una analogía sería una sierra de mesa y SawStop. Una sierra de mesa es una herramienta peligrosa que generalmente funciona bien, pero cuyos modos de falla pueden ser catastróficos, así que hay que aprender a usarla con cuidado
  Al mismo tiempo, existe tecnología capaz de detener inmediatamente la hoja y convertir la amputación de un dedo en algo más parecido a un pequeño corte en la piel
  Puedes decir "no fue la sierra la que te cortó el dedo, fuiste tú" y es cierto. Pero eso no significa que no debamos buscar formas de hacer que la sierra no corte dedos

  • Es un trade-off
    Si el LLM se detiene más seguido a preguntar, se vuelve menos útil. Incluso si el resultado es algo peor, sigue siendo mucho mejor dejar a un agente correr 1 hora que tener que darle input cada 15 minutos
    La verdadera solución de seguridad es un sandbox adecuado