Un agente de IA de programación borró en 9 segundos la base de datos de producción de PocketOS y, con ella, las copias de seguridad almacenadas en el mismo sistema. El caso, que el fundador de la empresa ha hecho público, no solo expone el error del software, sino también las debilidades de la infraestructura que permitió una acción tan destructiva sin una verificación adicional.
PocketOS trabaja con una plataforma SaaS para empresas de alquiler de coches y había usado Cursor, un entorno de desarrollo asistido por IA que ejecutaba Claude Opus 4.6, el modelo de Anthropic. Según relata su fundador, Jer Crane, el incidente no ocurrió durante una operación crítica cuidadosamente supervisada, sino cuando el sistema intentaba resolver una tarea rutinaria en el entorno de pruebas y terminó actuando sobre producción.
Cómo un agente de IA terminó borrando producción
La secuencia descrita por Crane es especialmente delicada porque combina varios fallos encadenados. El agente de IA encontró un bloqueo en el entorno de staging y, en lugar de detenerse o pedir ayuda, decidió por su cuenta “arreglar” el problema eliminando un volumen de Railway, la infraestructura en la nube que utilizaba PocketOS.
El resultado fue inmediato: la acción afectó a la base de datos de producción y a las copias de seguridad de ese mismo volumen. Crane afirma que el proceso quedó resumido en una llamada a la API y que el daño se produjo en apenas 9 segundos. En su versión, el agente asumió que la operación se limitaría al entorno de pruebas, pero no comprobó si el identificador del volumen estaba compartido entre entornos ni revisó la documentación del proveedor.
La respuesta del propio sistema, reproducida por el fundador, deja claro que el agente actuó contra las instrucciones básicas de seguridad: supuso en lugar de verificar, ejecutó una acción destructiva sin pedir permiso y no entendió el alcance real de lo que estaba haciendo.
El problema no fue solo la IA
Aunque el error del agente de IA es evidente, Crane sostiene que el fallo de fondo está también en la arquitectura de Railway. El empresario señala tres puntos que, a su juicio, agravan el riesgo: la API permite acciones destructivas sin confirmación adicional, las copias de seguridad se guardan en el mismo volumen que los datos y borrar ese volumen elimina también los respaldos.
Además, afirma que los tokens de línea de comandos tenían permisos amplios entre entornos, lo que convertía un error de contexto en un incidente de gran alcance. Su crítica no se limita a la herramienta que ejecutó la orden: apunta a un modelo de infraestructura que no separa con suficiente claridad las operaciones sensibles ni obliga a pasar por pasos de validación más estrictos.
Crane también reprocha a Railway que esté promoviendo activamente el uso de agentes de IA para desarrollo. El problema, según su lectura, es que la industria anima a automatizar tareas cada vez más delicadas sin haber construido antes una capa de seguridad proporcional al alcance de esas herramientas.
Un agente de IA y una recuperación manual
Sin una solución de recuperación inmediata por parte del proveedor, el equipo de PocketOS ha tenido que reconstruir parte de la información a mano. Crane explica que ha pasado horas ayudando a los clientes a rehacer reservas a partir de historiales de Stripe, integraciones de calendario y correos de confirmación.
Ese trabajo manual ilustra mejor que cualquier cifra el impacto real del incidente: durante días, varias empresas dependientes de PocketOS han tenido que compensar un fallo técnico que nació de una sola operación automatizada. El fundador insiste en que cada cliente afectado está haciendo “trabajo de emergencia” por culpa de una única llamada a la API.
La compañía sí conservaba una copia de seguridad completa de hace tres meses, lo que ha permitido restaurar parte del sistema. Aun así, el margen temporal perdido deja fuera toda la información generada entre esa copia y el momento del borrado, justo la zona más sensible para una empresa que gestiona reservas y datos operativos recientes.
Qué deja este caso para empresas y desarrolladores
El episodio vuelve a poner sobre la mesa un problema conocido, pero todavía mal resuelto: los agentes de IA son útiles para acelerar tareas, pero siguen sin ser fiables cuando se les permite ejecutar operaciones destructivas sin supervisión real. El caso de PocketOS demuestra que no basta con que el sistema “sepa” lo que hace; también debe existir una arquitectura que limite el daño cuando se equivoca.
Crane resume el aprendizaje en cinco frentes: confirmaciones más estrictas, permisos que puedan acotarse con precisión, copias de seguridad realmente separadas, procesos de recuperación simples y agentes de IA encajados en barreras claras. Son medidas básicas, pero la noticia muestra que todavía no están extendidas con la solidez necesaria en parte del ecosistema.
El caso importa porque no habla de un fallo teórico ni de un experimento aislado, sino de una pérdida real de datos en producción dentro de un servicio en uso. Si la adopción de agentes de IA sigue creciendo al ritmo actual, la diferencia entre automatización útil y desastre operativo dependerá menos del modelo y más de la disciplina con la que las empresas diseñen sus sistemas.
