Agentes de IA: solo 14% de empresas los revoca en minutos

Solo el 14% de las empresas que respondieron sobre revocación en el sondeo de septiembre de VB Pulse afirma que un responsable designado puede cortar el acceso de un agente de IA en minutos. El sondeo previo, de agosto, ya había mostrado que la mitad de los encuestados tenía agentes en producción y que, dentro de ese grupo, el 61% compartía credenciales entre agentes. Para un founder el problema no es de cumplimiento normativo: es de continuidad de negocio. Ya delegaste autoridad en software que actúa solo, pero no puedes retirársela rápido ni de forma selectiva.

El dato viene del análisis publicado por VB Intelligence, la unidad de investigación de VentureBeat, el 19 de octubre, construido sobre una conversación con Nir Chervoni, responsable de productos de seguridad de Nebius, un cloud especializado en IA. Vale una aclaración de transparencia que el propio medio hace: VentureBeat declara a Nebius como sponsor pagado de su cobertura de eventos. Los números de encuesta y el marco de evaluación sirven; conviene leerlo sabiendo que el proveedor tiene interés en el resultado.

¿Por qué compartir credenciales rompe la continuidad del negocio?

Una credencial compartida crea una dependencia entre cargas de trabajo. Si la revocas para frenar a un agente comprometido, también interrumpes a todos los demás agentes que usan el mismo acceso. Lo que debería ser una respuesta de seguridad se convierte en una caída de servicio no planificada.

La propuesta de Chervoni vuelve a fundamentos conocidos, pero los aplica al nivel de cada agente:

• Identidad separada para cada agente, no una cuenta de servicio compartida.
• Credenciales de vida corta y acotadas a la tarea específica que el agente debe cumplir.
• Gestión de secretos centralizada, en lugar de claves en variables de entorno o en el código.
• Claves controladas por el cliente, incluida la opción de conectar su propio sistema de gestión de claves (KMS).
• Logs de auditoría que alimenten el sistema de monitoreo de seguridad que ya usa la empresa.

Según el análisis, Nebius dice haber invertido en gestión de identidades y accesos, gestión de claves, gestión de secretos y registro de auditoría, y trabaja con clientes que prefieren traer sus propios componentes de seguridad.

¿Las guardrails del modelo alcanzan como control de acceso?

No, y la cita de Chervoni lo resume mejor que cualquier explicación: «Nunca confíes en una guardrail para imponer algo que una política de acceso puede imponer de forma determinista».

La distinción es práctica. Desviar a un agente de una acción inapropiada no le quita el permiso subyacente para ejecutarla. Si el prompt es manipulado, si el modelo se equivoca o si alguien encuentra un camino alternativo, el permiso sigue vigente y la acción es posible. La autorización tiene que estar en la infraestructura y en la aplicación, aplicándose por separado de lo que el modelo decida responder.

Para un equipo chico esto significa una regla simple: el guardrail es una capa de experiencia de usuario, la política de acceso es el control real.

¿Qué protege realmente el confidential computing en GPU?

El confidential computing extiende la protección al momento en que los datos se procesan, que es justo cuando el cifrado tradicional ya no cubre nada: los pesos del modelo y los datos sensibles deben descifrarse en memoria de CPU y GPU, donde un administrador privilegiado o un operador del cloud podrían alcanzarlos.

La pieza clave es la attestation: la verificación criptográfica de que el entorno donde va a correr tu carga es el que dice ser. Las claves se liberan solo si esa verificación pasa. La arquitectura de referencia de NVIDIA lo deja claro al listar los componentes requeridos: una imagen de máquina virtual confidencial medida, confidential computing tanto en CPU como en GPU, un verificador de attestation, gestión de claves con liberación segura y registros que no expongan el contenido procesado.

Los límites también importan para no comprar humo. Según el análisis, la tecnología no corrige vulnerabilidades de la aplicación, no detiene un ataque de prompt injection ni gobierna lo que el modelo produce. Una identidad comprometida puede seguir ejerciendo sus permisos legítimos aunque el entorno sea confidencial.

Aislamiento entre clientes y soberanía: pedir evidencia, no folletos

Chervoni propone cinco preguntas concretas para evaluar el aislamiento de un proveedor de nube de IA:

• Hardware: ¿cómo se prepara el equipamiento entre un cliente y otro?
• Sanitización: ¿cómo se gestionan la integridad del firmware y el borrado de la memoria de la GPU?
• Aislamiento de máquina: ¿puede una carga de un cliente alcanzar interfaces de administración?
• Componentes compartidos: ¿qué partes del plano de control son compartidas entre clientes?
• Red: ¿cómo se particionan las redes de alta velocidad y el aislamiento se probó de forma independiente?

El segundo punto es la confusión más caras que arrastran muchas empresas: residencia de datos no es soberanía. La residencia dice dónde están los datos; la soberanía también pregunta quién puede acceder a ellos, cómo se procesan y quién controla esas protecciones. Un despliegue regulado en Europa puede tener capacidad dedicada, claves bajo control del cliente, liberación de claves por attestation, acceso de personal aprobado y registrado, y retención cero en inferencia. Ese ejemplo que describe el análisis es una arquitectura ilustrativa, no la confirmación de que todo servicio del proveedor la entregue.

El mercado se está moviendo en esta dirección

La discusión no es teórica. El mismo 19 de octubre, Fortanix anunció soporte para el proyecto Confidential Containers (CoCo) de la CNCF, que según SiliconANGLE alcanzó estado de incubación en la fundación en julio. La compañía publica además una encuesta de Atomik Research entre 300 líderes de IA de grandes empresas estadounidenses: el 93% reconoce que el cifrado tradicional no protege los datos mientras la IA los procesa y el 41% dijo que sus dudas de seguridad llevaron a bloquear un despliegue por completo.

El tamaño del mercado lo confirma. Según el informe Confidential Computing Market Report 2026 de ResearchAndMarkets, difundido por Yahoo Finance, el segmento pasa de US$12.280 millones en 2025 a US$16.690 millones en 2026 (36% de crecimiento anual) y se proyecta en US$54.920 millones para 2030, con una tasa anual compuesta del 34,7%.

También hay movimiento en el frente del software. VAST Data presentó el 24 de septiembre de 2026 su capacidad DataEnclave, construida sobre NVIDIA Confidential Computing —que la compañía describe como su tercera generación, sobre plataformas Hopper, Blackwell y Rubin—, con envío previsto para el primer trimestre de 2027. El patrón es el mismo en todos los casos: la protección se verifica antes de liberar las claves.

¿Qué significa esto para tu startup?

Aunque no tengas un banco como cliente, si ya pusiste un agente a operar sobre sistemas reales, aplica lo mismo a otra escala.

• Dale identidad propia y dueño con nombre. Cada agente con su propia credencial y una persona responsable de poder cortarla. Si la credencial es compartida por tres agentes, el dueño no existe en la práctica.
• Cronometra una revocación de prueba. Corta el acceso de un agente y mide dos cosas: cuánto tardas y qué otros servicios se caen. Va a doler descubrir que el agente de reportes comparte cuenta con el que cobra.
• Acota permisos y acorta la vida de las credenciales. Credenciales de horas, no de años, y limitadas a lo que la tarea necesita. Es la forma más barata de que una filtración tenga un radio de daño pequeño.
• Suma attestation y liberación de claves al checklist de proveedor. Pregunta qué componentes quedan protegidos en el despliegue que vas a comprar, qué pasa si la verificación falla y si existe una forma de saltarse la política de liberación de claves. Una etiqueta de confidential computing no responde eso.
• Mide el costo real de las protecciones. Latencia, rendimiento y precio cambian cuando activas estas capas. Prueba con tu carga de trabajo, no con el benchmark del folleto.

Conclusión

La lección del análisis es que el control de un agente en producción es una capacidad operativa, no una casilla de seguridad. Puedes tener el mejor modelo y la mejor infraestructura, pero si no puedes demostrar que revocas un acceso en minutos y que el resto de tu operación sigue funcionando, ese agente es un riesgo concentrado.

El confidential computing amplía lo que puedes proteger mientras los datos se procesan, y eso es valioso para cualquier startup que toque datos sensibles de clientes o modelos propios. Pero no reemplaza la identidad, la autorización, el aislamiento ni el plan de recuperación. La pregunta que ordena todo es simple: cuando el agente deja de ser confiable, ¿puedes apagarlo sin apagar el negocio?

Fuentes

• VentureBeat: AI cloud security needs to prove control before agents reach production
• SiliconANGLE: Fortanix extends Confidential AI to Kubernetes workloads through Confidential Containers
• Yahoo Finance: Global Confidential Computing Market Report 2026
• Business Insider Markets: VAST Data Introduces DataEnclave