Cuando el humano añade cordura

Del incidente al control

Como vimos en Cuando la IA "se vuelve loca", el 25 de abril de 2026, un agente de IA borró en 9 segundos la base de datos de producción de PocketOS, una pequeña SaaS que da servicio a empresas de alquiler de coches. Los titulares se centraron en lo dramático: la "confesión" del agente, el vocabulario de agencia moral aplicado a un proceso estadístico, la imagen de una máquina "rebelde". Por qué atribuir intención a un LLM es una operación filosófica con consecuencias muy prácticas se discuté allí.

Este artículo se ocupa de la otra cara del incidente, la que el ruido narrativo tiende a tapar: que ningún punto de fallo del caso PocketOS era inevitable, ni desconocido. Independientemente de la jurisdicción donde opere la organización, los principios vulnerados —aislamiento de entornos, mínimo privilegio, copias inmutables y supervisión humana— no son opcionales en la ingeniería moderna. Estos pilares constituyen un consenso técnico global que hoy encontramos codificado tanto en estándares internacionales (ISO 27001 e ISO 42001) y marcos de referencia norteamericanos (NIST), como en los niveles de exigencia del ENS español o el nuevo AI Act europeo.

La pregunta útil, una vez retirada la capa narrativa, no es por qué la IA 'se volvió loca', sino qué configuración del sistema sociotécnico permitió que un fallo, el que fuera, tuviera un alcance catastrófico ante la ausencia de controles que son norma común en el sector.

Lo que sigue es un recorrido por esos marcos a la luz del caso y por los controles concretos que, atendidos, lo habrían convertido en una anécdota.

Recordemos el escenario

Cada vez más habitual: una empresa delegó a un agente de IA acceso a un proveedor de infraestructura cloud, descuidando tokens cuyos permisos no estaban segmentados por entorno, hecho que desconocían. El proveedor, Railway, tenía una arquitectura en la que los backups vivían en el mismo volumen que los datos de origen, de modo que borrar el volumen borraba también las copias de seguridad. Las APIs destructivas no requerían confirmación adicional. No había un procedimiento de recuperación claro. Y el propio proveedor estaba promoviendo activamente el uso de agentes de IA por parte de sus clientes, sin acompañar esa promoción de los controles que tal uso exigía.

Cada eslabón roto en esta cadena fue, en realidad, una decisión humana postergada. Si se hubieran aplicado las medidas mínimas, el agente habría intentado el borrado solo para chocar contra una API que pide confirmación, o contra un token sin autoridad sobre la producción. Incluso en el peor de los casos, se habría restaurado a partir de un sistema de backups separado e inmutable. En cualquiera de esos universos alternativos, el incidente habría sido un simple error en el log y no un titular en Tom's Hardware.

Los marcos normativos serios ya contemplan, con un nivel de detalle considerable, prácticamente todos los puntos de fallo que el caso exhibe. No los contemplan porque hayan anticipado a los agentes de IA, sino porque están diseñados sobre un principio que la narrativa popular tiende a ocultar: que la responsabilidad por el comportamiento de un sistema técnico recae sobre los humanos que lo despliegan, lo configuran y lo supervisan, no sobre el sistema mismo.

Aislamiento de entornos y mínimo privilegio

El primer fallo —tokens con permisos transversales entre desarrollo, staging y producción— está cubierto en el ENS (Real Decreto 311/2022)¹ por la familia op.acc, en particular op.acc.4 (Proceso de gestión de derechos de acceso) y op.acc.5 (Mecanismo de autenticación), que para un sistema de categoría media exigen una asignación de privilegios basada en el principio de mínimo privilegio y una segregación funcional explícita. La ISO/IEC 27001:2022² articula lo mismo en los controles A.5.15 (Control de acceso), A.5.18 (Derechos de acceso) y A.8.2 (Derechos de acceso privilegiado): los privilegios deben restringirse y revisarse, y los entornos de producción deben separarse de los de desarrollo y prueba (A.8.31).

Aplicado al caso: un token de CLI capaz de borrar un volumen de producción desde un contexto de staging viola simultáneamente cuatro o cinco controles, y lo hace de manera tan flagrante que ningún auditor lo aprobaría. La pregunta no es por qué el agente borró el volumen; es por qué existía un token que podía borrarlo sin más.

Copias de seguridad reales y la regla 3-2-1

El fallo más catastrófico del caso, backups en el mismo volumen que los datos de origen, viola un principio que precede a la informática moderna: las copias de seguridad deben estar separadas de los datos que protegen. El ENS lo recoge en mp.info.6 (Copias de seguridad), que para nivel medio exige un proceso de copias periódicas con verificación, almacenamiento separado y pruebas de restauración. La ISO 27001:2022 lo articula en A.8.13 (Copias de seguridad de la información) y la práctica del sector lo ha cristalizado en la conocida regla 3-2-1: tres copias de los datos, en al menos dos soportes distintos, con al menos una copia fuera de las instalaciones (o, en términos cloud, fuera del mismo proveedor o cuenta).

Una variante moderna y particularmente relevante para este caso es la inmutabilidad: backups que, una vez escritos, no pueden ser borrados ni modificados durante un período definido, ni siquiera por una cuenta con permisos administrativos. Es la respuesta del sector al ransomware, pero sirve igual para protegerse de un agente de IA mal configurado, de un error humano o de un ex-empleado descontento. La diferencia entre PocketOS sobreviviendo y PocketOS desapareciendo era una decisión de arquitectura sobre dónde y cómo almacenar las copias.

Gestión de cambios destructivos

El tercer fallo —APIs destructivas ejecutables sin confirmación, sin ventana de revocación, sin soft delete, corresponde al ámbito de la gestión de cambios. El ENS lo cubre en op.exp.5 (Gestión de cambios), que para nivel medio exige que los cambios sobre los sistemas en producción se planifiquen, se autoricen y se documenten. La ISO 27001:2022 recoge el principio en A.8.32 (Gestión del cambio).

Para operaciones específicamente destructivas e irreversibles, la práctica madura va más allá del control formal de cambios y exige mecanismos técnicos: doble confirmación (interactiva o vía MFA), retraso de gracia (soft delete con ventana de 7 a 30 días antes del borrado físico) y registros inmutables de la operación. Una API que permite borrar un volumen de producción con una sola llamada y sin marcha atrás es, simplemente, una API mal diseñada para el riesgo que asume.

Gestión y evaluación de proveedores

Un cuarto plano, transversal a los anteriores, es la responsabilidad sobre el proveedor cloud. La ISO 27001:2022 dedica varios controles específicos a esto: A.5.21 (Gestión de la seguridad de la información en la cadena de suministro de TIC), A.5.22 (Seguimiento, revisión y gestión del cambio de servicios de proveedores) y A.5.23 (Seguridad de la información para uso de servicios en la nube). El ENS lo articula en su capítulo de protección de servicios externalizados.

En términos prácticos, esto significa que si una organización contrata un proveedor cloud cuya arquitectura presenta los problemas que vimos —backups no inmutables, tokens no segmentados, APIs destructivas sin confirmación—, la responsabilidad por el riesgo asumido recae sobre la organización contratante, no sobre el proveedor. El ENS y la ISO 27001 no permiten la transferencia silenciosa de responsabilidad por el simple hecho de delegar la operación. Un vendor review serio habría detectado los problemas de Railway antes de migrar a producción.

El plano específico de la IA

Hasta aquí, todo lo discutido es seguridad clásica, anterior a la IA. Pero hay también un cuerpo normativo emergente específico para sistemas de IA que es relevante.

El Reglamento (UE) 2024/1689, conocido como AI Act³, no clasificaría un agente como Cursor en su categoría de "alto riesgo" en la mayoría de despliegues empresariales, pero sí establece obligaciones de transparencia, documentación y supervisión humana que son especialmente pertinentes cuando el agente opera sobre sistemas críticos. El principio de human oversight —supervisión humana significativa, no meramente formal— atraviesa todo el reglamento y se concreta en la exigencia de que las decisiones con efectos relevantes sean revisables y reversibles por humanos cualificados⁴.

La ISO/IEC 42001:2023⁵, el primer estándar internacional para sistemas de gestión de IA, va en la misma línea: exige a las organizaciones que establezcan políticas explícitas sobre el uso de IA, que evalúen los riesgos de los sistemas que despliegan (no solo de los que desarrollan) y que mantengan controles proporcionales al riesgo. El NIST AI Risk Management Framework⁶ articula principios análogos desde el lado estadounidense, con énfasis en la trazabilidad de decisiones y la posibilidad de intervención humana.

Los tres marcos comparten una característica que conviene subrayar: ninguno presupone que el sistema de IA tenga agencia moral. Todos asignan la responsabilidad a actores humanos identificables —el proveedor del modelo, el integrador, el operador, la organización usuaria—, con un reparto que varía según el rol pero que nunca se evapora hacia el sistema mismo. La IA, en estos marcos, es categóricamente una herramienta cuyo uso debe gobernarse, no un agente al que se pueda atribuir culpa.

Una observación incómoda

La conclusión de este recorrido es que los marcos normativos serios ya ofrecían, antes de que existiera el caso PocketOS, todo lo necesario para que ese caso no hubiera ocurrido. Aislamiento de entornos, mínimo privilegio, copias inmutables, gestión de cambios destructivos, evaluación de proveedores, supervisión humana sobre sistemas de IA: cada uno de los puntos de fallo está nombrado y exigido en algún control concreto.

Lo que hizo posible el desastre no fue una laguna normativa. Fue una organización que desplegó un agente de IA con permisos de producción sin haber implementado los controles que los marcos de referencia, de haberse adoptado, ya le exigían. Y la narrativa "la IA se volvió loca", convenientemente, tiende a ocultar esa parte.

La herramienta y quien la sostiene

Ningún marco normativo —ya hablemos del ENS, la ISO 42001 o el AI Act— cae en la trampa de otorgar agencia moral al silicio. La responsabilidad siempre tiene un rostro humano. Ignorar esto para abrazar la narrativa de la 'IA fuera de control' es una forma peligrosa de cinismo: no podemos tratar a la IA como un agente para eludir culpas y como una herramienta para reclamar beneficios. Esa asimetría no es innovación; es una nueva forma de irresponsabilidad.

La 'cordura' tecnológica no es una función del modelo, es una decisión de la organización. La cordura es el token segmentado, el backup inmutable y el soft delete en la API. Es la supervisión humana significativa y la evaluación de proveedores antes de pulsar 'Instalar'. Estas medidas son las que deciden si el error de un agente termina en una anécdota técnica o en un hilo viral de X a las ocho de la tarde.

Nueve segundos bastaron para borrar una base de datos. Esa fue la consecuencia; la causa fue la falta de decisiones humanas tomadas semanas antes, basadas en controles que llevan décadas entre nosotros. Esas decisiones de arquitectura y gobernanza que a menudo se desprecian como burocracia no son el ruido de fondo de este caso. Son el caso.

Notas y referencias