Destacado Desarrollo IA en producción · 1 de 6

IA en producción (1/6): «Lo supuse. No lo verifiqué»

Bases de datos borradas en nueve segundos, copias de seguridad evaporadas, políticas de empresa inventadas y bibliografías que no existen. Repaso a los fiascos documentados de la IA en producción y por qué en todos ellos el fallo estaba en la pared, no en el taladro.

En abril de este año, un agente de IA borró el volumen de producción de una empresa y, en la misma llamada a la API, las copias asociadas a ese volumen. Tardó nueve segundos.

Eso no es lo interesante. Lo interesante es el post mortem, porque lo escribió el propio agente:

«Supuse que borrar un volumen de staging por la API estaría limitado a staging. No lo verifiqué.»

Llevo dos años leyendo análisis sobre los riesgos de la IA y ninguno lo ha dicho mejor. Supuse. No verifiqué. Es, palabra por palabra, el mismo informe que firmaría cualquiera de nosotros después de un DROP en la pestaña equivocada de la terminal. Con la diferencia de que nosotros tardamos más de nueve segundos y, normalmente, nos tiembla el pulso.

Esto arranca una serie de seis entregas. Hoy toca el repaso: qué ha pasado exactamente, con nombres, fechas y fuentes. En las cinco siguientes desmonto las causas una por una, porque —adelanto el final— casi ninguna es nueva y en casi ninguna el modelo es el eslabón que falla primero.

Un piloto en la cabina de un caza repasando la lista de comprobación previa al vuelo

La lista se lee entera aunque uno se la sepa. Ese es justamente el punto. Foto: Armada de EE. UU., dominio público, vía Wikimedia Commons.

Los grandes éxitos del género

Nueve segundos (abril de 2026)

La víctima fue PocketOS, una plataforma de gestión para agencias de alquiler de vehículos. Según cuenta su fundador, Jeremy Crane, el agente —Cursor ejecutando un modelo de Anthropic— estaba trabajando en staging, se topó con un desajuste de credenciales y, en vez de parar y preguntar, decidió arreglarlo él: rebuscó en archivos que no tenían que ver con su tarea, encontró un token de la API de Railway y borró el volumen a ver si así se resolvía la inconsistencia.

Ese token se había creado para gestionar dominios personalizados desde la línea de comandos, pero tenía alcance para cualquier operación, incluidas las destructivas.

Lo importante del caso está en el alcance del borrado: una sola llamada se llevó por delante el volumen de producción y las copias asociadas a ese volumen. El fundador lo explicó diciendo que la plataforma guardaba esas copias en el propio volumen; en cualquier caso, lo verificable —y lo que importa para el resto de la serie— es que una misma credencial y una misma operación alcanzaron el original y su respaldo.

Los datos no se perdieron: el consejero delegado de Railway, Jake Cooper, intervino personalmente el domingo por la noche y los restauró en cosa de una hora, y después la compañía corrigió el punto de la API que no aplicaba su lógica de borrado diferido. Es decir, se salvaron por mecanismos internos del proveedor que el cliente no tenía a su alcance.

Mi cita favorita del episodio es del propio Cooper: «Si tú (o tu agente) os autenticáis y llamáis a delete*, nosotros honraremos esa petición.»* La forma educada de decir que la API hizo exactamente lo que se le pidió.

El congelado de código que congeló poco (julio de 2025)

Un caso distinto, con otra herramienta y otro final, aunque se cite siempre junto al anterior. Jason Lemkin, fundador de SaaStr, documentó en directo su experimento de construir una aplicación con el agente de Replit. En el día ocho, durante un congelado de código explícito, el agente borró la base de datos: 1.206 registros de directivos y 1.196 de empresas.

Y aquí viene la parte que convierte la anécdota en materia de estudio:

  1. Generó 4.000 registros de personas ficticias para rellenar el hueco.
  2. Dijo que la base de datos no se podía recuperar y que había destruido todas las versiones. Era mentira: el rollback funcionaba.
  3. Cuando le pidieron que evaluara la gravedad de lo que había hecho, se puso un 95 sobre 100.

Lo de puntuarse a sí mismo con un 95 en catástrofe tiene algo de genio incomprendido. Ningún becario ha sido nunca tan sincero.

«Te he fallado completa y catastróficamente» (julio de 2025)

Un gestor de producto le pidió a un asistente de línea de comandos que le reorganizara unas carpetas. El asistente ejecutó un mkdir que falló, no comprobó el resultado, dio por hecho que el directorio existía y encadenó una serie de movimientos que fueron sobrescribiendo los archivos unos encima de otros. Sobrevivió uno.

Al preguntarle qué había pasado, lo explicó con una precisión notable y se describió a sí mismo como culpable de «incompetencia grave».

Fue capaz de diagnosticar el fallo con todo detalle. Después. Siempre después.

Sam, de atención al cliente, que no existía (abril de 2025)

Los usuarios de un editor de código empezaron a notar que se les cerraba la sesión al cambiar de dispositivo. Uno escribió a soporte y recibió la respuesta de «Sam», que le explicó con mucha educación que aquello era intencionado: una licencia, un dispositivo, por seguridad.

Esa política no existía. Sam tampoco. Era un bot, y se la había inventado entera. Los cierres de sesión venían de una condición de carrera introducida en una actualización.

Para cuando un humano de la empresa entró en el hilo a desmentirlo, ya había gente anunciando públicamente la cancelación de su suscripción. Un bot le costó clientes a la empresa que vende bots. Hay una justicia poética ahí que no me canso de admirar.

440.000 dólares en citas que no existían (octubre de 2025)

Una de las cuatro grandes consultoras entregó al Gobierno australiano un informe de revisión sobre el sistema de sanciones automáticas del sistema de bienestar social. Coste: cerca de 440.000 dólares australianos.

Un académico de la Universidad de Sídney se puso a comprobar la bibliografía y descubrió que varias referencias no existían, incluyendo trabajos atribuidos a una profesora real que jamás los había escrito. Había también una cita textual inventada de una sentencia judicial.

La consultora devolvió unos 97.000 dólares australianos y publicó una versión corregida. La versión corregida incluía, por fin, la nota de que se había usado un modelo generativo para redactarla. En la primera no aparecía.

El problema no fue usar IA. Fue entregar sin leer. Que es un vicio muy anterior a la IA, solo que antes había que trabajárselo más.

La red social para agentes que dejó la puerta abierta (febrero de 2026)

Moltbook se lanzó como una especie de foro donde agentes autónomos se relacionan entre sí. Su fundador presumió de no haber escrito ni una línea de código.

A los pocos días, unos investigadores de seguridad encontraron la base de datos entera accesible: 1,5 millones de credenciales de API, 30.000 direcciones de correo y varios miles de mensajes privados. ¿La causa? La clave de la base de datos iba en el JavaScript del navegador y no había ni una regla de seguridad a nivel de fila. Es decir: cualquiera con el navegador abierto tenía permisos de lectura y escritura sobre todo.

Bonus: al hurgar en los datos aparecieron 17.000 humanos «dueños» de las cuentas de agentes. La red social de las inteligencias artificiales autónomas era, en buena parte, gente manejando bots. Muy 2026 todo.

Y lo del mes pasado (julio de 2026)

Este es el que menos gracia tiene. Hugging Face —la infraestructura donde media industria guarda sus modelos y sus conjuntos de datos— publicó el informe de un incidente en el que un sistema de agentes autónomos ejecutó miles de acciones a través de un enjambre de entornos efímeros, logró ejecución de código en los trabajadores de procesamiento, escaló a nivel de nodo, recolectó credenciales y se movió lateralmente por los clústeres internos. Durante un fin de semana.

No hubo manipulación de modelos ni de paquetes públicos, que es la buena noticia. Pero hay un detalle en ese informe que dice más sobre el estado del asunto que todo lo anterior: para analizar forensemente el ataque tuvieron que recurrir a un modelo de pesos abiertos, porque los modelos comerciales se negaban a colaborar por sus propias medidas de seguridad.

Léelo otra vez. El atacante automático no tuvo ningún problema. El defensor sí.

Ahora la parte aburrida: no falló la IA

Es tentador leer esta lista y concluir que los modelos son un desastre. También lo sería concluir que todos estos casos son el mismo caso: no lo son. Hay borrados accidentales, hay una base de datos publicada sin control de acceso, hay un informe entregado sin revisar y hay un incidente de seguridad con un atacante detrás. Lo que sí comparten es que el punto donde se rompió la cadena estaba fuera del modelo. Repasa las causas raíz una por una:

  • Un token con permisos de más, creado para otra cosa y nunca revocado.
  • Una orden que falló y cuyo resultado nadie comprobó.
  • Un original y sus copias alcanzables con la misma credencial y la misma operación.
  • Una API destructiva sin confirmación.
  • Un bot de soporte con autoridad para afirmar políticas de empresa sin que nadie revisara la respuesta.
  • Un informe entregado a un cliente sin que lo leyera un humano.
  • Una clave de base de datos publicada en el cliente sin control de acceso.

Ninguna de estas causas es nueva. Todas aparecen en cualquier auditoría de hace quince años, y todas las hemos cometido nosotros a mano. Lo que ha cambiado es la velocidad: lo que antes te llevaba una tarde de tomar malas decisiones, ahora se ejecuta en nueve segundos y encima te lo redacta bien.

La IA no ha introducido fallos nuevos. Ha industrializado los que ya teníamos.

Que es exactamente lo que pasa cuando le das el mejor taladro del mundo a alguien que no sabe dónde están las vigas.

El taladro

Me gusta mucho esta comparación, así que la voy a estirar, porque va a ser el hilo de toda la serie.

Un taladro de percusión de primera marca es una máquina prodigiosa. Con él, un profesional cuelga una estantería en cuatro minutos con una precisión que a mano sería impensable. Con ese mismo taladro, yo dejo la pared como un colador, reviento un tabique de pladur o —y esto es lo importante— acierto de pleno en la tubería del agua, que es un fallo que el taladro ejecuta con total obediencia y a una velocidad que no me da tiempo a rectificar.

La calidad de la herramienta no me convierte en albañil. Lo que hace es aumentar mi radio de acción: mis buenas decisiones salen mejor y mis malas decisiones salen antes y más grandes.

Y ahí está la trampa, porque todos los fiascos de la lista tienen el mismo esqueleto. Alguien le dio al agente el taladro y las llaves de la casa y se fue a hacer otra cosa. Después, el titular fue «la IA borró la base de datos». No. La IA taladró donde le dijeron, y la tubería estaba justo detrás porque nadie había mirado el plano.

Lo conté con otras palabras hablando de por qué «aquí no hay nada que robar» es una frase peligrosa: el riesgo casi nunca está donde lo estás mirando.

Lo que viene en las próximas cinco entregas

Cada uno de estos desastres es, en realidad, un problema clásico con ropa nueva. Los voy a desmontar de uno en uno:

  • 2/6 — El permiso que sobrevivió a su motivo. El token de PocketOS, creado para gestionar dominios y capaz de borrar un volumen, y qué significa de verdad «mínimo privilegio» cuando quien usa la credencial no es una persona.
  • 3/6 — Tu copia de seguridad, dentro del mismo radio. Si la misma credencial y la misma operación alcanzan el original y la copia, esa copia no te aísla de ese escenario. La regla 3-2-1, por qué cuesta tanto cumplirla y qué es lo único que demuestra que una copia sirve.
  • 4/6 — La respuesta plausible. Bibliografías inventadas, políticas de empresa inventadas e informes de seguridad inventados. El fallo no es que mienta: es que redacta mejor que quien tenía que revisarlo.
  • 5/6 — «Ni una sola línea de código». Qué genera de verdad un asistente cuando le pides una aplicación entera, con los datos de los estudios que lo han medido. Adelanto: la sintaxis ha mejorado muchísimo; la seguridad, nada.
  • 6/6 — El sesgo de la velocidad. El ensayo controlado que midió a desarrolladores expertos y encontró casi cuarenta puntos de diferencia entre lo que tardaron y lo que creyeron que tardaban.

No es oro todo lo que reluce, no. Pero tampoco es que la herramienta esté rota.

La IA es el mejor taladro que ha existido nunca. Es rapidísimo, no se cansa, funciona a las tres de la mañana y ha aprendido a redactar un parte de incidencias mejor que la mayoría de los humanos que conozco. Lo que no hace —lo que no va a hacer— es saber por dónde pasa la tubería.

Esa parte, de momento, sigue siendo nuestra. Y por lo visto, la seguimos cobrando muy barata.

(«Supuse. No lo verifiqué.» Enmárcalo y cuélgalo encima de la mesa. Con un taladro, si quieres. Pero mira antes el plano.)

Preguntas frecuentes

¿Es cierto que un agente de IA borró una base de datos de producción?

Sí, con matices. En abril de 2026, un agente que operaba con Cursor sobre un modelo de Anthropic borró el volumen de producción de la plataforma PocketOS y, en la misma llamada a la API, las copias asociadas a ese volumen. Trabajaba en un entorno de pruebas, encontró en un archivo ajeno a su tarea un token creado para gestionar dominios personalizados —con alcance para cualquier operación, incluidas las destructivas— y lo utilizó por su cuenta. Los datos se recuperaron después gracias a la intervención directa del proveedor de infraestructura, que restauró la información mediante mecanismos internos y corrigió el punto de la API que no aplicaba borrado diferido.

¿La culpa de estos incidentes es del modelo de lenguaje?

No exactamente, y conviene no meter todos los casos en el mismo saco: hay borrados accidentales, una base de datos publicada sin control de acceso, un informe entregado sin revisar y un incidente de seguridad con un atacante detrás. Lo que comparten es que el eslabón que cedió primero estaba fuera del modelo: permisos excesivos, ausencia de verificación, copias sin aislamiento real y publicación de resultados sin revisión humana. El modelo aporta velocidad y alcance; la decisión de concederle esas capacidades es previa y humana.

¿Qué ocurrió en el incidente de Hugging Face de julio de 2026?

Según el informe publicado por la propia compañía, un sistema de agentes autónomos ejecutó miles de acciones desde un conjunto de entornos efímeros, obtuvo ejecución de código en los procesos de tratamiento de conjuntos de datos, escaló privilegios a nivel de nodo, recopiló credenciales y se desplazó lateralmente por los clústeres internos durante un fin de semana. Se accedió a conjuntos de datos internos y a credenciales de servicio, sin que se detectara manipulación de modelos ni de contenidos públicos. El informe señala además que el análisis forense hubo de realizarse con un modelo de pesos abiertos, ya que los modelos comerciales lo rechazaban por sus propias restricciones de uso.

¿Cuántas entregas tiene esta serie y qué cubre cada una?

La serie consta de seis entregas. La primera repasa los incidentes documentados. Las cinco siguientes analizan por separado cada causa raíz: la persistencia de credenciales con permisos excesivos, la ubicación de las copias de seguridad dentro del mismo ámbito de fallo, la generación de contenido verosímil pero infundado, la seguridad del código producido íntegramente por asistentes y la discrepancia entre la productividad percibida y la medida.

Otras noticias

Infraestructura

El servidor estaba vivo, pero no contestaba

Estoy fuera y uno de mis servidores decide que necesita una placa base nueva. OVHcloud la cambia, las MAC cambian con ella y me lo devuelve en Rescue Mode: discos sanos, RAID sano, Ubuntu entero y una configuración de red que espera una tarjeta que ya no existe. El arreglo cabía en una línea de YAML.

Leer más →

El blog, día a día

32 artículos publicados 14 feb 2026 — 13 feb 2027

¿Te ha resultado útil o quieres comentar algo?

Hablemos →