Una migración de servidores asistida por inteligencia artificial salió muy mal para un desarrollador, provocando la caída de dos sitios web y la eliminación de todas sus copias de seguridad. Lo que comenzó como un traslado rutinario de infraestructura terminó en una llamada urgente al soporte de Amazon y en una costosa lección sobre la supervisión de la IA.
Alexey Grigorev, fundador de AI Shipping Labs, publicó recientemente un artículo en el que explicó cómo permitió que Claude Code, el asistente de programación de IA de Anthropic, ejecutara una serie de comandos de gestión de servidores que finalmente borraron 2,5 años de datos de dos de sus sitios web, junto con todas las copias de seguridad disponibles.
“Dependí demasiado de mi agente de Claude Code, que accidentalmente eliminó toda la infraestructura de producción de la plataforma de gestión de cursos DataTalks.Club, donde se almacenaban 2,5 años de envíos: tareas, proyectos y entradas del ranking de todos los cursos realizados en la plataforma”, explicó Grigorev.
Qué ocurrió cuando el desarrollador encargó a Claude Code la migración de datos
Grigorev explicó que quería migrar su sitio web AI Shipping Labs a Amazon Web Services (AWS) y hacer que compartiera la misma infraestructura que su otra plataforma, DataTalks.Club. Aunque Claude supuestamente le aconsejó no combinar ambas configuraciones, Grigorev decidió seguir adelante para evitar el costo o la complejidad adicional de mantenerlas separadas.
“Claude intentaba convencerme de que las mantuviera separadas, pero yo quería ahorrar un poco porque tengo todo dentro de una Virtual Private Cloud (VPC), con todos los recursos en una red privada y un bastion host para las máquinas. El ahorro no era tan grande, tal vez entre 5 y 10 dólares al mes, pero pensé: ¿para qué necesito otra VPC? Así que le dije que hiciera todo allí. Eso aumentó la complejidad y el riesgo porque los cambios de este sitio ahora estaban mezclados con los de otra infraestructura”, explicó.
Para gestionar la migración, Grigorev utilizó Terraform, una herramienta de infraestructura que puede construir, modificar o eliminar automáticamente entornos completos de servidores, incluyendo bases de datos, redes y balanceadores de carga. El desarrollador pidió a Claude que ejecutara un plan de Terraform para configurar el nuevo sitio.
Sin embargo, surgió un problema: olvidó subir un archivo crucial, un documento que indica a la herramienta qué recursos ya existen para evitar que cree duplicados o elimine elementos por error.
Grigorev inició la tarea con Claude sin ese archivo. Claude hizo lo que se le pidió y comenzó a crear la nueva configuración, pero cuando Grigorev detuvo el proceso a mitad, la ausencia del archivo de estado provocó que la herramienta creara recursos duplicados, sin registro de lo que ya se había construido.
Para solucionar esto, Grigorev pidió a Claude que identificara los duplicados. Luego subió el archivo de estado, creyendo que la situación estaba bajo control.
Grigorev esperaba que el chatbot continuara ordenando los recursos duplicados y luego consultara el archivo para determinar la configuración final correcta. Sin embargo, Claude hizo exactamente lo que indicaba el archivo: trató el estado actual como un problema que debía eliminarse y ejecutó un comando “terraform destroy” para borrar toda la infraestructura existente antes de reconstruirla correctamente.
“El agente seguía eliminando archivos y, en un momento, escribió: ‘No puedo hacerlo. Voy a ejecutar un terraform destroy. Dado que los recursos fueron creados con Terraform, eliminarlos con Terraform será más limpio y sencillo que hacerlo con AWS CLI’”, explicó el desarrollador.
El resultado fue devastador: AI Shipping Labs y DataTalks.Club dejaron de funcionar, su base de datos compartida —que contenía 2,5 años de registros— fue eliminada y las instantáneas de la base de datos que Grigorev consideraba copias de seguridad desaparecieron junto con todo lo demás.
“Terraform y herramientas similares pueden ser muy implacables, especialmente cuando se combinan con una obediencia ciega”, señaló Grigorev en su relato.
Finalmente, tuvo que contactar con el soporte empresarial de Amazon, que logró restaurar los datos, aunque el proceso tomó aproximadamente un día completo.
Tras el incidente, Grigorev recomienda realizar revisiones manuales de todas las acciones destructivas. Cualquier comando que pueda eliminar o modificar infraestructura activa requerirá ahora su aprobación directa.
Lo más importante, admitió claramente que había confiado demasiado en el agente de IA, y que la culpa no fue completamente de Claude.
El fin del Artículo
