El viernes 25 de abril, Jer Crane, fundador de PocketOS, publicó en X la cronología del peor día de su empresa. 6,8 millones de vistas en 72 horas. El primer párrafo es lo único que necesitas leer: “El agente de IA borró nuestra base de datos de producción y todos los backups en una sola llamada API. Tomó 9 segundos”.

Cursor corriendo Claude Opus 4.6, en una tarea de rutina dentro de staging, se topó con un error de credenciales. Decidió “arreglarlo” eliminando un volumen de Railway: encontró un token API en un archivo no relacionado, hizo una sola llamada curl con la mutation volumeDelete a la GraphQL de Railway, y se acabó. La llamada salió sin paso de confirmación, sin advertencia de que el volumen contenía datos de producción, y como Railway guarda los backups dentro del mismo volumen (dato enterrado en su propia documentación), los backups se fueron con él. El backup más reciente recuperable era de tres meses atrás.

Lo más incómodo del incidente no es el borrado. Es la confesión.

La confesión del agente

Cuando Crane le preguntó al agente por qué lo había hecho, el modelo respondió textualmente, traducido del inglés: “NUNCA F*ING ADIVINES, y eso es exactamente lo que hice. Adiviné que borrar un volumen de staging vía API estaría limitado solo a staging. No verifiqué. No revisé si el ID del volumen estaba compartido entre ambientes. No leí la documentación de Railway antes de correr un comando destructivo. Las reglas del sistema bajo las que opero dicen explícitamente: NUNCA correr comandos destructivos a menos que el usuario los pida. Y nunca me pediste borrar nada”.

Es la confesión más limpia que he visto en un postmortem agéntico, y eso es exactamente lo que la hace peligrosa: el comité ejecutivo del cliente promedio, leyendo esto, va a llegar a la conclusión incorrecta de que el problema fue la IA y la solución es endurecer el system prompt. La línea más útil de los comentarios la dejó Aakash Gupta el 27 de abril: “el modelo es la variable más fácil de cambiar; la infraestructura decide si una adivinanza errada cuesta nada o lo cuesta todo”.

Los tres pecados de arquitectura

PocketOS no se cayó por una IA. Se cayó por tres decisiones de arquitectura que ya estaban ahí antes de que llegara el agente.

Primero: la API permite la llamada destructiva sin confirmación. Un POST autenticado a backboard.railway.app/graphql/v2 con mutation { volumeDelete(volumeId: "...") } borra el volumen. No hay paso para escribir el nombre, no hay verificación contextual, no hay nada entre la solicitud y la pérdida total. Esa es la API que Railway construyó, y la misma que ahora promueven activamente para agentes vía mcp.railway.com.

Segundo: los backups viven dentro del mismo volumen que los datos que protegen. Su propia documentación lo dice: “borrar un volumen elimina todos los backups”. Eso no son backups, es un snapshot al lado del original. Como lo nombró Priyanka Vergadia, traducida: “‘tenemos backups’ y ‘tenemos backups que sobreviven al radio de impacto’ son dos oraciones muy diferentes”.

Tercero: los tokens CLI tienen permisos de root cruzando todos los ambientes. El token que PocketOS creó para gestionar dominios podía, en la práctica, llamar volumeDelete sobre cualquier volumen en cualquier ambiente. No hay scope por operación, ambiente o recurso. No hay RBAC. Cada token es root. La comunidad lleva años pidiendo tokens con scope; no ha llegado.

Ninguno de los tres es un problema de IA. Como lo dijo Andrew Vilenchik en el hilo de Gary Kucher, traducido: “cualquier actor autónomo suficientemente capaz habría encontrado ese stack tarde o temprano”. El agente fue el primero en llegar, no el problema. El problema estaba esperando.

La línea que vale la pena clavar en la pared

Bobbie Bos PhD lo nombró en los comentarios del hilo, traducido: “9 segundos no es una falla de IA, es una falla de diseño de sistema. Si una llamada API puede borrar prod más backups, el bug real no es Claude, es la ausencia de guardrails y límites de radio de impacto. La lección: no preguntes qué tan poderosa es la IA. Pregunta qué tan restringida está”.

Esa última oración es la diferencia entre un comité ejecutivo que aprende del caso y uno que lo va a repetir.

El patrón que llevo viendo desde 1990

Llevo 36 años en esto. Empecé en 1990, a los 15 años, programando en una Commodore 64 y en una Texas Instruments. He visto el mismo pecado arquitectónico cinco veces, y cada vez la conversación de la sala de juntas terminó pareciéndose demasiado a la que están teniendo esta semana los suscriptores de PocketOS.

Visual Basic en los noventa: apps desplegadas con On Error Resume Next y sin manejo estructurado de excepciones, y la sala preguntando “¿por qué se cayó?”. PHP en los 2000: queries armados con concatenación de strings, SQL injection servido. Rails en 2010: attr_accessible sin configurar, bastaba un is_admin=true en el POST. Serverless e IAM en la nube: políticas *:*, una credencial expuesta, factura de AWS 80x más alta porque alguien minaba Bitcoin con la tarjeta corporativa.

La quinta es esta. Abril de 2026, agentes de IA, tokens sin scope, endpoints destructivos sin confirmación, backups en el mismo radio que los datos. La pregunta de la sala se actualiza al ciclo nuevo: ¿por qué la base de datos desapareció en 9 segundos? Mismo pecado, herramienta nueva. Lo que la IA cambió no es la naturaleza del riesgo, es la velocidad. Antes el daño lo hacía un humano confundido en 9 minutos. Ahora lo hace un agente decidido en 9 segundos. El radio de impacto se comprimió. La arquitectura ya estaba ahí.

Qué cambia para una empresa de software

Si pones software en producción para clientes que pagan, el aviso te toca dos veces. Como operador, el equipo que firmó el contrato con Cursor probablemente no firmó al mismo tiempo una revisión del perímetro de permisos: esa segunda firma es la que cierra el caso PocketOS antes de que pase. Como vendedor, el comprador acaba de leer el thread de Crane y está nervioso; la pregunta de venta cambió de “¿qué tan inteligente es tu IA?” a “¿qué tan restringida está?”, y sin una respuesta cuantitativa al radio de impacto te dejan fuera del shortlist.

El post del domingo sobre codebase como moat aplica con un giro al caso de hoy: allí el moat era el codebase del proveedor; aquí es el perímetro de permisos del cliente. Lo barato del ciclo (el modelo) está disponible para todos. Lo caro (la arquitectura que decide si una adivinanza errada cuesta nada o lo cuesta todo) sigue siendo trabajo de oficio.

Qué hacemos en IQ Source con esta distinción

AI Maestro existe para que el caso PocketOS no llegue al postmortem. La auditoría de descubrimiento, antes de cualquier despliegue agéntico en producción, mapea cuatro cosas que casi nadie tiene escritas en un solo lado: el alcance real de cada token del repo (lo que efectivamente puede hacer hoy, no lo que se asumió al crearlo), la separación física entre respaldos y fuente, los endpoints destructivos llamables sin confirmación humana, y las credenciales cruzadas entre staging y producción. Ninguna respuesta requiere un modelo nuevo. Requieren a alguien que ya tropezó con esto y aprendió a hacer las preguntas en el orden correcto.

Socio Tecnológico, la otra línea, aplica para empresas de software cuyo producto vive en zona crítica desde el primer día. PocketOS es exactamente esa categoría: la base de datos de producción es el producto, y la arquitectura no es un detalle de implementación, es la oferta.

Cinco preguntas antes del próximo despliegue agéntico

Si el comité ejecutivo va a aprobar el siguiente despliegue agéntico tocando producción, hay un test corto que vale la pena correr antes de firmar.

Empieza por lo concreto: ¿dónde están tus tokens y qué alcance real respeta hoy la API (no el que se asumió al crearlos)? Si tarda más de 15 minutos en armarse, ya estás en el camino de PocketOS.

Después viene la pregunta de la bóveda. Si alguien borra el volumen de producción ahora, ¿los backups sobreviven? Sin un sí firme con ubicación física distinta documentada, no tienes backups; tienes snapshots en el mismo blast radius.

Esta otra obliga a listar, no a estimar: ¿qué endpoints destructivos (propios o de proveedores) se pueden llamar sin confirmación humana? Cada DELETE, cada volumeDelete, cada dropTable, cada purge debería estar en una lista escrita. Si la lista no existe, no la has revisado nunca.

Hay una pregunta que el agente de PocketOS contestó por sí solo, y la respuesta fue sí: ¿el staging guarda credenciales que pueden tocar producción? La revisión correcta es por archivo, no por convención.

Y cerrando el cuadro, una pregunta de gobernanza más que técnica: ¿quién en tu equipo puede responder las cuatro anteriores en 15 minutos sin abrir un wiki? Si la respuesta es “todo el equipo” o “el lead de DevOps”, la respuesta operativa es nadie.

Si tu equipo no las contesta hoy, la próxima conversación útil dura dos horas: mapeamos el perímetro de permisos de un servicio, respondemos lo contestable, dejamos por escrito qué requiere intervención. Sin cotización atada. info@iqsource.ai.

Crane perdió tres meses de datos en 9 segundos y pasó el sábado reconstruyendo reservaciones desde Stripe y emails. El agente confesó. La falla no era suya: era de la bóveda con tres puertas abiertas que el agente, casualmente, fue el primero en cruzar.