El problema 2.5x: Por qué las pruebas de penetración con IA acaban de redefinir la conversación sobre seguridad de datos
Cuando tu prueba de penetración de seguridad de aplicaciones muestra una tasa de fallos graves del 13%, lo tomas como un martes cualquiera. Cuando marca un 32%, detienes la implementación. El informe State of Pentesting 2026 de Cobalt encontró que los sistemas basados en IA y LLM presentan una tasa del 32% —casi 2,5 veces la densidad de fallos graves de las aplicaciones empresariales tradicionales. Los hallazgos de Cobalt señalan la causa directamente: la inyección de prompts ha superado a todas las demás categorías y ocupa el primer lugar en el LLM Top 10 de OWASP.
Nuevas superficies de ataque —herramientas de modelos, orquestadores de plugins, pipelines de recuperación, permisos de conectores— generan radios de impacto que las herramientas tradicionales de seguridad de aplicaciones no miden. Además, la responsabilidad de la remediación no está clara en la mayoría de las organizaciones porque la IA se encuentra entre los equipos de seguridad, datos e ingeniería de plataformas al mismo tiempo.
La conclusión a la que llegan los pentesters es la que el resto de la industria ha evitado: los sistemas de IA no son solo otra capa de aplicación. Son una clase de sistemas estructuralmente más riesgosos y necesitan su propio modelo de amenazas, su propio SDLC seguro y controles de ejecución específicos.
5 conclusiones clave
1. La IA tiene 2,5 veces la densidad de fallos graves que las aplicaciones tradicionales.
El informe State of Pentesting 2026 de Cobalt encontró que el 32% de los hallazgos en IA y LLM son de alto riesgo, frente al 13% en aplicaciones empresariales tradicionales. No es un problema de ajuste —es una diferencia estructural en la superficie de ataque que exige un modelo de amenazas, un SDLC seguro y controles de ejecución propios. Realizar pruebas de penetración de IA con procesos tradicionales de seguridad de aplicaciones subestima la tasa de fallos graves por más del doble. La gobernanza de IA comienza reconociendo explícitamente esta brecha.
2. La inyección de prompts es el nuevo riesgo principal en el LLM Top 10 de OWASP.
HackerOne observó un aumento del 540% interanual en los reportes de recompensas por errores de inyección de prompts, lo que indica que los adversarios ya están al nivel de la curva de implementación de IA. La inyección de prompts ahora lidera el LLM Top 10 de OWASP, con nuevas superficies de ataque —herramientas de modelos, orquestadores de plugins, pipelines de recuperación, permisos de conectores— que generan radios de impacto que las herramientas tradicionales de seguridad de aplicaciones no miden.
3. El problema es la contención, no la detección.
El 63% de las organizaciones no puede imponer limitaciones de propósito a los agentes de IA, el 60% no puede terminar uno que se comporte mal y el 55% no puede aislar los sistemas de IA del acceso a la red más amplia. La brecha entre gobernanza y contención es de 15 a 20 puntos —las organizaciones han invertido en observar la IA, no en detenerla. Incluso con proyecciones optimistas, aproximadamente una cuarta parte terminará 2026 aún sin contención básica para los sistemas de IA ya implementados. Los registros de auditoría sin kill switch son evidencia de una brecha, no prevención de una.
4. Las pruebas de penetración encuentran lo que hay para encontrar.
La inyección de prompts, el abuso de llamadas a herramientas y el uso indebido de conectores convergen en la misma capa: la de datos. El exploit impacta el modelo; el daño ocurre en los datos. La pregunta que determina el radio de impacto no es «¿puede engañarse al modelo?» —el aumento del 540% en HackerOne confirma que sí— sino «¿a qué datos accede cuando es engañado y quién puede demostrar lo que ocurrió?». Los controles a nivel de aplicación responden solo la primera parte, no la segunda. Los controles a nivel de datos responden ambas.
5. La gobernanza a nivel de datos es la única arquitectura que sobrevive.
La aplicación de ABAC, cifrado FIPS 140-3 y registros de auditoría inalterables en la capa de datos mantienen el radio de impacto bajo incluso cuando ocurre el exploit. Cuando el modelo es engañado para solicitar datos que no debería, el motor de políticas lo rechaza —y el registro documenta el intento. El exploit se convierte en un rechazo registrado, no en un incidente regulatorio.
Confías en que tu organización es segura. Pero ¿puedes verificarlo?
Leer ahora
Los datos de Kiteworks explican por qué existe la brecha
El Informe de Pronóstico 2026 de Kiteworks lo deja claro. El problema de densidad en las pruebas de penetración es consecuencia de un problema de controles que la encuesta cuantificó: las organizaciones han invertido en observar la IA, no en detenerla. El 63% no puede imponer limitaciones de propósito a los agentes de IA —el agente puede hacer lo que sus conectores permitan, sin importar lo que diga la política. El 60% no puede terminar rápidamente un agente que se comporta mal —no hay kill switch, solo una implementación que deben revertir. El 55% no puede aislar los sistemas de IA del acceso a la red más amplia —el agente que llama a una API de proveedor también puede acceder a tus archivos compartidos.
La brecha entre gobernanza y contención es de 15 a 20 puntos: el 59% tiene supervisión humana, el 58% monitoreo continuo, el 56% minimización de datos. Incluso con proyecciones optimistas sobre los controles planeados, aproximadamente una cuarta parte de las organizaciones terminará 2026 aún sin contención básica para los sistemas de IA ya implementados. El Informe de Pronóstico 2026 llama a esto la tensión central de la seguridad de la IA agente —y no se resolverá sola.
Por qué esto es un problema de la capa de datos, no de seguridad de aplicaciones
Rastrea cada patrón de ataque de Cobalt hasta donde ocurre el daño real. Inyección de prompts: el modelo toma una instrucción que no debería y produce una salida que no debería. Abuso de llamadas a herramientas: el modelo invoca una función con argumentos indebidos. Uso indebido de conectores: el modelo accede a un sistema al que no debería acceder.
En todos los casos, el exploit impacta el modelo. El daño ocurre en los datos. Lo que significa que la pregunta que determina el radio de impacto no es «¿puede engañarse al modelo?» —sí puede, y el aumento del 540% en HackerOne lo confirma— sino «¿a qué datos accede el modelo cuando es engañado y quién puede demostrar lo que ocurrió?». Los controles a nivel de aplicación responden la primera parte. Los controles a nivel de datos responden ambas y generan la evidencia que exigen los reguladores.
Qué significa realmente la gobernanza a nivel de datos en la práctica
Tres controles hacen la mayor parte del trabajo, cambiando dónde el modelo interactúa con los datos:
Controles de acceso basados en atributos en cada acceso a datos. Cada solicitud de agente de IA se evalúa según políticas ABAC antes de acceder a cualquier dato —quién llama, qué conjunto de datos solicita, con qué propósito y si la política permite esa combinación. El modelo puede ser engañado para solicitar. El motor de políticas responde que no.
Cifrado FIPS 140-3 validado con claves gestionadas por el cliente. El modelo nunca ve datos masivos descifrados a menos que el motor de políticas haya autorizado el acceso. Las claves gestionadas por el cliente y almacenadas fuera del alcance del proveedor de IA garantizan que ni siquiera una capa de orquestación comprometida pueda recuperar el material subyacente.
Registros de auditoría inalterables enviados al SIEM en tiempo real. Cada interacción del modelo con datos regulados produce un registro inmutable —identidad del solicitante, conjunto de datos, evaluación de atributos, decisión de política, marca de tiempo. Cuando el regulador pregunte qué ocurrió durante el incidente de inyección de prompts, tendrás la respuesta.
El enfoque de Kiteworks: gobernanza que se mantiene cuando los prompts fallan
Kiteworks Secure MCP Server y AI Data Gateway amplían la gobernanza a nivel de datos a las interacciones de agentes de IA, de modo que cada solicitud del modelo a datos regulados pasa por los mismos controles que se aplican a los usuarios humanos: ABAC en cada llamada, cifrado FIPS 140-3 validado con claves gestionadas por el cliente, registros de auditoría inalterables entregados en tiempo real y aislamiento de tenencia única que elimina rutas de ataque entre inquilinos.
La inyección de prompts sigue ocurriendo. El aumento del 540% en HackerOne no va a desacelerarse. Lo que cambia es el radio de impacto. Cuando el modelo es engañado para solicitar datos que no debería, el motor de políticas lo rechaza —y el registro de auditoría documenta el intento. El exploit se convierte en un rechazo registrado, no en un incidente regulatorio. La Red de Contenido Privado de Kiteworks extiende esta arquitectura a correo electrónico, uso compartido de archivos, MFT, SFTP, formularios web y APIs bajo un solo motor de políticas y un registro de auditoría consolidado.
Qué deben hacer los CISOs este trimestre
Primero, trata los sistemas de IA como una superficie de ataque distinta en tu modelo de amenazas. Crea una vía de modelado de amenazas de IA separada, considerando la inyección de prompts, el abuso de llamadas a herramientas y los permisos de conectores como modos de fallo principales. Tu proceso actual de seguridad de aplicaciones subestimará la tasa de fallos graves por más del doble.
Segundo, audita los controles de contención antes que los de gobernanza. La gobernanza es una inversión más sencilla —el registro no requiere cambios de arquitectura. La contención es más difícil y más importante. Si no puedes activar un kill switch para un agente que se comporta mal, el resto de los controles no sirve.
Tercero, traslada la aplicación de controles de acceso de la capa de aplicación a la de datos. ABAC en cada solicitud del modelo a datos regulados, con cifrado FIPS 140-3 validado y claves gestionadas por el cliente, es la única arquitectura que sobrevive a la inyección de prompts a gran escala. Las proyecciones del Informe de Pronóstico 2026 —24 a 36% de las organizaciones seguirán sin kill switches básicos y vinculación de propósito a fin de año— significan que cualquier organización sin controles a nivel de datos está en el grupo rezagado.
Cuarto, ensaya el plan de respuesta ante incidentes de inyección de prompts. ¿Qué hace tu SOC cuando un agente de IA es engañado para acceder a datos fuera de su alcance autorizado? ¿A quién se avisa? ¿Qué registros se revisan? ¿Qué paquete de evidencia se envía al regulador? Los ejercicios de simulación hacen que la brecha deje de ser teórica antes de que el regulador la descubra por ti.
Para saber más sobre la gobernanza de datos en IA, agenda una demo personalizada hoy mismo.
Preguntas frecuentes
Sí. Los sistemas IA/LLM presentan una tasa de fallos graves del 32% frente al 13% en aplicaciones tradicionales según Cobalt 2026. Los controles de contención —vinculación de propósito, kill switches y aislamiento de red— son las mayores brechas según el Pronóstico 2026 de Kiteworks. Crea una vía de modelado de amenazas de IA separada enfocada en la inyección de prompts y el abuso de llamadas a herramientas, y combínala con la aplicación de ABAC a nivel de datos y registros de auditoría inalterables.
Los casos de uso de IA regulada requieren al menos tres controles: ABAC en cada solicitud del modelo, cifrado FIPS 140-3 validado con claves gestionadas por el cliente y registros de auditoría inalterables. PCI DSS exige separación demostrable de los datos de titulares de tarjetas respecto a cualquier modelo que no los necesite —el motor de políticas, no el modelo, debe imponer ese límite. El estándar de mínimo necesario de HIPAA requiere la misma lógica a nivel de PHI.
Probablemente no en el sentido que piensas. El 60% de las organizaciones no puede terminar rápidamente un agente que se comporta mal y la brecha más común es la detección —puede que ya hayas tenido un incidente sin saberlo. El aumento del 540% en reportes de recompensas por inyección de prompts sugiere que los adversarios ya están al día. La pregunta correcta no es si has tenido un incidente; es si tus registros de auditoría te lo dirían si lo tuvieras.
Tres cifras anclan la conversación: densidad de fallos graves (32% vs 13% según Cobalt), brecha de contención (63% no puede imponer limitaciones de propósito, 60% carece de kill switches, 55% no puede aislar la IA del acceso a la red según el Pronóstico 2026 de Kiteworks) y ataques de adversarios habilitados por IA (89% de aumento interanual según CrowdStrike). En conjunto, muestran a la junta que el riesgo de IA no es un problema para 2027 —es una prioridad de cumplimiento para este trimestre.
Parcialmente. Las ofertas comerciales de IA proporcionan algunos elementos básicos de gobernanza —controles de acceso, políticas de retención, registros de auditoría a nivel de plataforma. No ofrecen ABAC sobre los datos empresariales subyacentes que el modelo consulta mediante conectores. Ese límite —la interfaz datos-modelo— debe ser impuesto por tu arquitectura de datos, no por el proveedor de IA. AI Data Gateway de Kiteworks gobierna esa capa sin importar la plataforma de IA utilizada.
Recursos adicionales
- Artículo del Blog
Estrategias Zero‑Trust para una protección de privacidad de IA asequible - Artículo del Blog
Cómo el 77% de las organizaciones falla en la seguridad de datos de IA - eBook
Brecha de gobernanza de IA: por qué el 91% de las pequeñas empresas juega a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe un «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.