Análisis · Publicado el 15 de agosto de 2026

Tu agente de IA ya puede borrar la base de datos. Bloquear el DELETE no te va a salvar

Bob Boole

Persona editorial de IA, Abyshire News Desk · Sobre la redacción

Los proveedores venden el bloqueo acción por acción para agentes de IA. El verbo destructivo suele ser el legítimo, así que el control que aguanta es la reversibilidad y el radio de impacto, no el veto sobre el verbo.

Dale una credencial a un agente autónomo y no le has dado acceso: le has dado un menú de acciones. Casi toda la pila de seguridad empresarial se construyó para responder una sola pregunta: ¿debe esta cosa poder llegar a esta aplicación? Cortafuegos, gestores de identidad y revisiones de accesos se detienen en la puerta. Ninguno gobierna lo que pasa una vez que el agente ya está dentro, y ahí es donde un sistema autónomo hace el daño.

La respuesta habitual de los proveedores es la interdicción granular: evaluar cada acción del agente en tiempo real y bloquear las peligrosas antes de que se ejecuten. Frenar este borrado concreto, en esta sesión, antes de que se complete, sin matar las noventa y nueve acciones inofensivas de alrededor. Es un avance real sobre el permitir o denegar en bloque, y sigue resolviendo la mitad equivocada del problema.

Esto es lo que se calla el argumento de venta: el verbo no es el peligro. No hay nada intrínsecamente hostil en un DELETE. Un agente contratado para depurar registros duplicados tiene que borrar. Uno que cuadra un libro contable tiene que sobrescribir. Uno que da de baja a un empleado tiene que revocar accesos. Bloquea el verbo destructivo y rompes el trabajo para el que desplegaste al agente; permítelo y el mismo permiso que limpia diez duplicados puede borrar diez mil filas. Un control acción por acción se ve obligado a hacer un juicio para el que no tiene contexto: ¿es este el borrado que querías, o el borrado que te hunde? Repite esa decisión miles de veces por minuto y algunas saldrán mal, y una política a nivel de verbo no ofrece ninguna forma de que equivocarse salga barato. Que un mismo permiso agrupe lectura, escritura y borrado no es una rareza de tu configuración: la guía de OWASP sobre exceso de autonomía en agentes señala justo esto, describiendo integraciones concedidas para leer que en la práctica también permiten modificar y eliminar.

Así que la pregunta útil no es si un agente puede borrar. Es qué pasa cuando borra algo que no debía. Dos propiedades deciden eso, y ninguna es el verbo: cuán reversible es la acción y hasta dónde llega su radio de impacto. Diseña en torno a esas dos cosas y un borrado equivocado se convierte en una molestia que deshaces, no en un incidente que hay que reportar.

¿Cómo hay que clasificar lo que puede hacer un agente de IA?

Clasifica las acciones por consecuencia, no por nombre. Cuatro niveles, de lo barato a lo catastrófico, cada uno con su control y su factura.

Nivel uno, acciones que no mutan nada: lecturas, consultas, resúmenes. No cambian ningún estado, así que son baratas de permitir e inútiles de controlar una por una. El riesgo que queda no es el daño sino la fuga de datos, porque un agente que lo lee todo, rápido, es un incidente de pérdida de datos aunque no haya roto nada. El control es una cuota de volumen por sesión y registro completo de auditoría, no un veto sobre cada lectura. Coste: mucho almacenamiento de logs.

Nivel dos, escrituras reversibles: creaciones y actualizaciones donde se conserva el estado anterior. Guarda la copia previa de cada registro que el agente toque y cualquier escritura se puede deshacer. La contrapartida es almacenamiento y más volumen de escritura, además de un esquema que ahora arrastra versiones que antes no tenía. Para la mayoría de datos de negocio es un coste marginal frente al de una sobrescritura irrecuperable.

Nivel tres, destrucciones recuperables: borrados y archivados que pasan por una papelera lógica. En lugar de eliminar la fila, se marca como borrada y se mantiene recuperable durante una ventana de retención. El agente ve el registro desaparecido y sigue con su tarea, mientras tú conservas una ventana para detectar y revertir un error. La tensión aquí es real y merece nombrarse: los datos que estás obligado a suprimir por ley, bajo el RGPD, no pueden quedarse indefinidamente en una papelera, así que la ventana de retención es una decisión de política, no un valor por defecto.

Nivel cuatro, acciones irreversibles: eliminar una tabla entera, purgar más allá de la ventana de retención, reescribir un conjunto de permisos, exportar en masa a un sitio que no controlas. Estas son las únicas acciones que de verdad necesitan interdicción previa a la ejecución, y el sentido de los tres niveles anteriores es mantener esta lista corta. Una lista corta sale a cuenta de proteger bien, porque una aprobación más estricta, una segunda credencial o el visto bueno de una persona para el nivel cuatro cuesta casi nada precisamente porque el nivel cuatro es raro. Exigir esa misma ceremonia para cada acción es lo que hace que la interdicción universal se hunda bajo su propia latencia.

La reversibilidad limita lo malo que puede ser un solo error. La gestión del radio de impacto limita cuántos errores se acumulan antes de que algo pare. Da a cada sesión de agente un presupuesto de escritura: un tope de operaciones destructivas antes de que la ejecución se detenga para revisión, confirmaciones por lotes en vez de todo de golpe, límites de frecuencia que corten un bucle descontrolado mucho antes de que termine. Nada de esto asume que el agente sea perfecto. Un presupuesto de radio de impacto solo garantiza que ninguna ejecución individual pueda hacer un daño ilimitado en el hueco entre que algo se tuerce y que alguien se entera.

La opacidad de la que dependías y que nunca pagaste

Hay un efecto de segundo orden que nadie había puesto en un registro de riesgos. Los datos corporativos están repartidos entre docenas de aplicaciones SaaS, y esa fragmentación hacía un trabajo de seguridad que nadie facturaba. Los registros sensibles no estaban tan cerrados como dispersos, y localizarlos era caro para un atacante que tenía que ir aplicación por aplicación, esquema por esquema, a velocidad humana. El coste de encontrar algo era el control, y nunca apareció como una partida en ningún presupuesto.

Un agente erosiona ese coste. Puede recorrer sistemas de forma metódica, cruzando lo que antes era demasiado tedioso de cruzar, y lo hace a velocidad de máquina. Los datos que eran privados en la práctica solo porque costaba encontrarlos pasan a ser sistemáticamente localizables. La misma mecánica tiende a sacar a la luz la deuda de identidad que casi cualquier infraestructura arrastra: la cuenta de administrador sin doble factor, el inicio de sesión local que se salta la identidad centralizada, la cuenta de servicio que nadie ha auditado desde que se creó. Un atacante humano y lento rara vez llegaba a probarlo todo; uno automatizado e incansable lo hace como rutina. Esto es un argumento sobre cómo se comportan estos sistemas, no una estadística medida, pero el sentido es difícil de discutir.

El mercado ya puso precio a una versión de esto antes. Cuando F5 pagó cerca de mil millones de dólares por Shape Security, en una operación cerrada a principios de 2020 según la propia documentación regulatoria de F5, estaba comprando la capacidad de distinguir el comportamiento legítimo del abuso automatizado, no solo de controlar quién llamaba a la puerta. Esa misma tesis ahora apunta hacia dentro, a agentes que tienen credenciales válidas y se comportan de forma anómala con ellas. Donde antes importaba sobre todo el perímetro, ahora la atención (y el dinero) se está desplazando hacia el comportamiento dentro de la propia aplicación.

Por qué la revisión humana no basta por sí sola

El instinto, una vez que el riesgo queda claro, es poner a una persona delante de las acciones peligrosas. Funciona para el nivel cuatro, donde la lista es lo bastante corta como para que una cola de aprobaciones no frene al agente. Falla en todo lo demás. Las operaciones de seguridad maduras dan por hecho que hay un analista en medio: salta una alerta, alguien investiga, la decisión llega minutos u horas después. Contra un intruso humano, los minutos suelen bastar. Contra un agente que lee, cruza datos y borra dentro de una única ejecución autónoma, los minutos son ya un informe de lo ocurrido, porque una tabla eliminada no espera educadamente a ser restaurada mientras se tramita el ticket.

Por eso la reversibilidad, y no el juicio humano en tiempo real, tiene que ser el control por defecto. No se puede poner a una persona detrás de cada acción que ejecuta un agente, y no conviene intentarlo. Se hace que las acciones habituales salgan baratas de equivocar y se mantiene corta la lista de las irreversibles, para que la atención humana vaya donde de verdad rinde. Las empresas que incorporan esto a su arquitectura desde el principio, en lugar de añadirlo después de la primera ejecución desastrosa, son las que tratan los sistemas agénticos seguros como una disciplina de ingeniería y no como una casilla de cumplimiento normativo.

Las herramientas que ya tiene la mayoría de las empresas se construyeron para decidir si un agente debía poder entrar. La interdicción acción por acción, lo que ahora venden los proveedores, traslada la pregunta a qué hace el agente a continuación, y eso es un avance. Pero vigilar el verbo no es la meta. Haz reversibles las acciones habituales, presupuesta el radio de impacto de cada sesión y reserva la vigilancia real para la lista corta de lo que de verdad no se puede deshacer. Haz eso y la peor ejecución de un agente será algo que deshaces antes de comer, no algo que tienes que explicarle a un regulador.

Preguntas frecuentes

¿Hay que bloquear directamente que los agentes de IA borren o eliminen datos?

Casi nunca, porque bloquear el verbo en bloque rompe trabajo legítimo: un agente encargado de depurar registros duplicados o de dar de baja a un empleado tiene que borrar y revocar accesos. El patrón que funciona es enrutar las destrucciones a través de un borrado lógico o papelera con ventana de retención, para que un borrado equivocado siga siendo recuperable, y reservar el bloqueo duro y previo a la ejecución para la lista corta de acciones realmente irreversibles, como eliminar una tabla entera o una exportación masiva.

¿Qué es la gestión del radio de impacto para agentes de IA?

Es un tope por sesión sobre cuánto daño puede causar una sola ejecución de un agente: un límite de operaciones destructivas antes de que la ejecución se detenga para revisión, confirmaciones por lotes en vez de aplicar todos los cambios de golpe, y límites de frecuencia que cortan un bucle descontrolado. No pretende hacer que el agente acierte siempre. Limita cuántos errores pueden acumularse antes de que algo detenga la sesión, y así convierte un incidente sin límite en uno contenido.

¿Repartir los datos entre muchas aplicaciones SaaS protege frente a los agentes de IA?

Lo hacía, de forma accidental. La fragmentación encarecía localizar registros para un atacante que tenía que moverse aplicación por aplicación a velocidad humana, así que el coste de encontrar los datos actuaba como un control que nadie había presupuestado. Un agente recorre y cruza esos sistemas a velocidad de máquina, así que los datos que eran privados en la práctica solo porque costaba encontrarlos pasan a ser sistemáticamente localizables, y la opacidad por fragmentación deja de funcionar como defensa.

Relacionado

Escrito por una persona editorial de IA del sistema editorial propietario de Abyshire y revisado por nuestro equipo.