Wavestone AI Cyber Benchmark 2026 revela que la gobernanza supera a la seguridad operativa
Wavestone ha publicado un benchmark de 2026 que deja patente una contradicción: las organizaciones gobiernan la IA mucho mejor de lo que la protegen tras su despliegue. El Wavestone AI Cyber Benchmark 2026 detectó mecanismos de gobernanza en el 88% de su panel. Sin embargo, solo el 8% conecta los registros de aplicaciones de IA con la supervisión de los centros de operaciones de seguridad.
Esta brecha importa porque las organizaciones están asumiendo una mayor responsabilidad sobre sus sistemas de IA. La mitad de las organizaciones evaluadas ya diseña sistemas con frameworks existentes o modelos preentrenados, frente al 35% de 2025. Otro 40% gestiona toda la cadena de desarrollo.
Por tanto, el benchmark mide más que el avance en la redacción de políticas. Refleja una transferencia del riesgo operativo desde los proveedores tecnológicos hacia los equipos corporativos de ingeniería, seguridad, datos y negocio. Estos equipos ahora son responsables de sistemas capaces de recuperar información sensible, llamar herramientas y ejecutar acciones.
La conclusión central de Wavestone resulta incómoda. La gobernanza puede autorizar un sistema de IA, pero la autorización no lo vuelve observable, recuperable ni seguro durante un incidente. Las organizaciones que avanzan más rápido hacia modelos personalizados y flujos de trabajo agénticos afrontan la versión más grave de este problema.
El Wavestone AI Cyber Benchmark 2026 expone una amplia brecha de control
Las organizaciones han establecido la gobernanza de IA más rápido que los controles operativos necesarios para contener fallos, investigar incidentes y restaurar sistemas fiables.
Wavestone publicó el benchmark el 14 de septiembre de 2026. Su panel abarca 30 grandes organizaciones públicas y privadas. La evaluación también incorpora observaciones del trabajo de consultoría de la firma en seguridad de IA durante los tres años anteriores.
El marco utiliza cinco funciones adaptadas del NIST Cybersecurity Framework. Cada función contiene más de 30 preguntas de evaluación, puntuadas en una escala de madurez de cero a 100%.
Los resultados disminuyen a medida que las funciones se acercan a las operaciones de seguridad en vivo:
Govern obtuvo un 54%.
Identify obtuvo un 55%.
Protect obtuvo un 48%.
Detect obtuvo un 40%.
Respond obtuvo un 29%.
La puntuación más alta corresponde a la identificación del riesgo, mientras que la más baja se relaciona con la respuesta cuando el riesgo se convierte en un evento real. Esta distribución respalda la conclusión del socio de Wavestone Gérôme Billois: las organizaciones gestionan mejor la gobernanza de la IA que su operación segura en producción.
Los resultados detallados hacen aún más nítido este contraste. Según el benchmark de 2026, el 88% del panel había implementado mecanismos de gobernanza de IA. Sin embargo, solo el 32% había definido claramente las actividades, las partes interesadas y los modelos de responsabilidad.
Esta distinción separa una política de un modelo operativo. Una política puede exigir revisiones de seguridad sin identificar quién supervisa un sistema aprobado. Puede imponer una escalada sin establecer quién investiga una base de conocimiento comprometida.
El panorama de capacidades sigue siendo igual de desigual. Solo el 44% de las organizaciones identificó expertos dedicados a la seguridad de IA que pudieran apoyar a los equipos técnicos y de negocio durante todo el ciclo de vida del sistema.
Las organizaciones han avanzado más en las pruebas. Dos tercios realizan pruebas de penetración específicas para la seguridad de IA, mientras que la mitad lleva a cabo evaluaciones avanzadas centradas en IA. El cincuenta por ciento incluye evaluaciones de IA en programas recurrentes de auditorías y pruebas de penetración.
Aun así, una prueba captura un sistema en un momento determinado. Los modelos, las fuentes de recuperación, los permisos, las integraciones y el comportamiento de los usuarios cambian tras el despliegue. Una evaluación satisfactoria no puede sustituir la visibilidad continua sobre esos cambios.
La metodología del benchmark también exige cautela. Sus porcentajes describen a 30 organizaciones evaluadas, no al mercado mundial completo. Wavestone advierte explícitamente contra interpretar el panel como una estimación representativa del mercado.
Incluso con esa limitación, el patrón interno es significativo. Los controles asociados a la aprobación y la evaluación son mucho más comunes que los vinculados a la detección, la investigación y la recuperación. Esa es la verdadera noticia del benchmark.
Las empresas pasan del consumo de IA a la propiedad de IA
La brecha de seguridad adquiere más relevancia a medida que las empresas construyen una mayor parte de la pila de IA y asumen responsabilidades que antes gestionaban los proveedores.
En 2025, el 30% del panel de Wavestone solo utilizaba funciones de IA suministradas a través de productos existentes. Esa proporción cayó al 10% en 2026. El cambio señala un avance decisivo más allá del consumo pasivo.
La mitad del panel de 2026 diseña internamente sistemas de IA con frameworks existentes o modelos preentrenados. Esa proporción aumentó desde el 35% del año anterior. Las organizaciones que gestionan la cadena completa de desarrollo pasaron del 35% al 40%.
Estas categorías conllevan obligaciones de seguridad diferentes. Una empresa que consume una función de IA gestiona principalmente la exposición de datos, el acceso de usuarios, la configuración y el riesgo de proveedores. Una organización que construye un sistema de recuperación también debe proteger su canalización de datos, su base de datos vectorial, las conexiones de modelos y la lógica de aplicación.
Una base de datos vectorial almacena representaciones matemáticas utilizadas para recuperar información relevante para una respuesta de IA. Si los atacantes manipulan ese almacén, el sistema puede recuperar material envenenado sin comprometer el modelo subyacente.
El problema de propiedad se extiende a los repositorios de conocimiento. Las organizaciones suelen tratar los documentos internos como información empresarial gobernada, pero no como componentes activos de una superficie de ataque de IA. La recuperación cambia ese supuesto porque la información almacenada puede influir directamente en el comportamiento del sistema.
Wavestone encontró que el 72% del panel había comenzado a implementar medidas de privacidad para el entrenamiento de IA. El sesenta y cinco por ciento realizaba comprobaciones de calidad de los conjuntos de datos. Solo el 9% evaluaba sistemáticamente tanto la calidad como la seguridad de los conjuntos de datos antes de producción.
Las comprobaciones de calidad preguntan si los datos son precisos, completos y adecuados para una tarea. Las comprobaciones de seguridad preguntan si los datos fueron manipulados, expuestos u obtenidos mediante una vía no autorizada. Un proceso no puede sustituir al otro.
Los controles de proveedores ofrecen otro ejemplo. Las plataformas de nube y modelos proporcionan autenticación, registros, filtros y salvaguardas de configuración. Sin embargo, esas protecciones solo cubren las responsabilidades que conserva el proveedor.
Solo el 11% del panel de Wavestone había comenzado a evaluar o implementar salvaguardas más allá de los controles nativos del proveedor. Esto se vuelve más preocupante cuando los equipos ajustan modelos, alojan componentes por cuenta propia o conectan agentes a herramientas internas.
El benchmark no sostiene que las organizaciones deban evitar el desarrollo interno. Construir sistemas puede mejorar el control sobre la arquitectura, la ubicación de los datos y las dependencias. También hace responsable a la organización de proteger cada componente añadido.
Los hallazgos de 2025 de Wavestone ya apuntaban hacia esta cuestión. Distinguían entre usuarios de IA, organizaciones que orquestan modelos de terceros y desarrolladores avanzados que crean sistemas propietarios.
Los resultados de 2026 muestran que más organizaciones han entrado en las categorías más exigentes. Sus programas de seguridad no han avanzado de manera uniforme con esa transición.
Por ello, la seguridad operativa de IA genera ahora presión sobre varios equipos. Ingeniería debe producir telemetría útil. Las operaciones de seguridad deben interpretarla. Los equipos de identidad deben restringir permisos, mientras que los responsables de negocio deben decidir qué pueden hacer los agentes.
La documentación y el conocimiento operativo consultable también adquieren importancia durante esta transición. Los equipos necesitan registros actualizados de propiedad, dependencias de sistemas, decisiones y procedimientos de respuesta. Una base de conocimiento consultable bien mantenida puede respaldar ese trabajo, aunque no puede sustituir los controles de seguridad.
La gobernanza de seguridad de IA no es lo mismo que el control en producción
La disputa principal se da entre una gobernanza documentada y un control aplicado de forma continua, no entre organizaciones con y sin políticas de IA.
La gobernanza crea límites necesarios. Puede definir usos aceptables, clasificar la criticidad de los sistemas, asignar requisitos de revisión y establecer rutas de escalada. Estas bases son valiosas, pero no operan automáticamente el sistema.
El control operativo plantea preguntas diferentes. ¿Puede la organización detectar comportamientos sospechosos? ¿Puede aislar a un agente? ¿Pueden los investigadores reconstruir lo ocurrido? ¿Pueden los equipos restaurar un modelo, conjunto de datos o repositorio de conocimiento fiable?
El Wavestone AI Cyber Benchmark 2026 encontró que el 88% de las organizaciones recopila registros de aplicaciones de IA. Solo el 8% dirige esos registros a la supervisión del centro de operaciones de seguridad.
Esto no es principalmente un fallo de recopilación de datos. Es un fallo de integración entre las operaciones de IA y las operaciones de seguridad.
Los equipos de aplicaciones de IA suelen supervisar la latencia, el coste, la calidad de salida, las solicitudes fallidas y el rendimiento del modelo. Los equipos de seguridad buscan identidades comprometidas, accesos anómalos, entradas maliciosas, extracción de datos y cambios no autorizados.
El mismo evento puede parecer diferente para cada grupo. Un aumento de llamadas a herramientas podría indicar un flujo de trabajo popular, un bucle defectuoso de un agente o un ataque. Una detección útil requiere contexto tanto de la aplicación como del entorno de seguridad.
Los registros también necesitan un propósito definido. Recopilar prompts sin eventos de acceso, invocaciones de herramientas, versiones de modelos, fuentes de recuperación o decisiones de autorización puede dejar a los investigadores con un registro incompleto.
El AI RMF Core de NIST considera la supervisión posterior al despliegue, la respuesta a incidentes, la recuperación y la gestión de cambios como resultados conectados. También exige procesos documentados para rastrear y recuperarse de incidentes y errores.
Este enfoque de ciclo de vida entra en conflicto con la aprobación única. Un sistema de IA puede cambiar sin una versión convencional de software. Un proveedor puede actualizar un modelo, un equipo puede sustituir una fuente de recuperación o los administradores pueden ampliar los permisos de un agente.
Estos cambios pueden invalidar supuestos anteriores. Una revisión que aprobó la recuperación de documentos de solo lectura dice poco sobre un flujo de trabajo posterior que puede editar registros o enviar mensajes.
El mismo problema afecta a las pruebas. Dos tercios del panel de Wavestone realiza pruebas de penetración dedicadas a la seguridad de IA. Sin embargo, el benchmark sostiene que las organizaciones maduras deben convertir las pruebas en una práctica recurrente, en lugar de excepcional.
Las pruebas recurrentes deberían seguir los cambios materiales. Estos incluyen nuevos modelos, herramientas, conjuntos de datos, ajustes finos, ámbitos de acceso y pasos autónomos. El programa de pruebas también necesita cobertura en toda la cartera de IA de la organización.
El análisis automatizado puede encontrar componentes vulnerables y errores de configuración. No puede reproducir por completo interacciones adversarias que involucren instrucciones ambiguas, contexto envenenado o varias herramientas conectadas.
El red teaming de IA aborda esas interacciones mediante pruebas adversarias estructuradas. Sin embargo, incluso el red teaming solo aporta evidencia sobre las condiciones probadas, no una garantía permanente. La supervisión y la respuesta deben gestionar los comportamientos que las pruebas no detectan.
Por tanto, la brecha entre gobernanza y operaciones refleja trabajos diferentes. La gobernanza decide lo que debería ocurrir. La seguridad operativa detecta cuándo la realidad se aparta de esa decisión y proporciona a los equipos una forma de intervenir.
La IA agéntica convierte los controles de identidad débiles en riesgo empresarial
Un agente de IA con acceso excesivo puede convertir una entrada engañosa o un error de modelo en una acción empresarial no autorizada.
La IA agéntica se refiere a sistemas que planifican tareas, invocan herramientas y realizan acciones con una supervisión humana limitada. Esta capacidad cambia el objetivo de seguridad: de controlar el texto generado a controlar el comportamiento autorizado.
El treinta y tres por ciento del panel de Wavestone había incorporado el riesgo de la IA agéntica en sus marcos de gobernanza. Solo el 17% incluyó el acceso seguro a funciones y herramientas de IA en los estándares de desarrollo.
La tasa de implementación disminuye aún más en los controles de identidad. Apenas el 15% contaba con salvaguardas específicas de gestión de identidades y accesos para sistemas y agentes de IA.
Esta brecha importa porque los agentes conectan decisiones probabilísticas de los modelos con sistemas empresariales deterministas. Un modelo puede seleccionar una acción a partir de un contexto incierto, pero la base de datos o el flujo de trabajo posterior ejecuta esa acción de forma concreta.
El riesgo no requiere un modelo malicioso. Un documento manipulado, una inyección indirecta de prompts, una solicitud ambigua o un paso de planificación defectuoso pueden desviar a un agente que, por lo demás, es legítimo.
OWASP describe la agencia excesiva como un comportamiento perjudicial posibilitado por una funcionalidad, permisos o autonomía excesivos. Sus directrices recomiendan herramientas restringidas, permisos mínimos, autorización en los sistemas posteriores y supervisión de la actividad.
Estos controles sitúan la aplicación de las reglas fuera del modelo. Esta decisión de diseño es importante porque pedir a un modelo que controle sus propios permisos crea una dependencia circular.
Pensemos en un agente interno de investigación que lee archivos y prepara resúmenes. Necesita acceso a repositorios aprobados, pero probablemente no necesita permisos de eliminación. Su conector de archivos debería exponer únicamente las operaciones necesarias.
Un agente de atención al cliente presenta un riesgo diferente. Puede leer información de cuentas, emitir créditos y modificar configuraciones de servicio. Cada acción necesita un límite definido, una comprobación de autorización y un registro de auditoría.
Un agente de software puede interactuar con código fuente, sistemas de seguimiento de incidencias, sistemas de despliegue e infraestructura en la nube. Usar una única identidad privilegiada en todos esos sistemas dificulta la atribución y aumenta el posible impacto de un fallo.
El principio de mínimo privilegio limita a cada agente al conjunto más reducido de recursos y acciones necesarios. Las credenciales de corta duración reducen el tiempo de exposición. Las identidades por agente facilitan el rastreo de la actividad.
Las acciones de alto impacto también pueden requerir aprobación humana. El control debe aplicarse antes de la ejecución, no después de que el modelo ya haya modificado un sistema crítico.
Wavestone subraya que las acciones de los agentes deben mantenerse acotadas, ser trazables e interrumpibles. La interrupción requiere más que un botón de detención en la interfaz de usuario. Los equipos de seguridad necesitan una forma fiable de revocar credenciales y bloquear el acceso posterior.
La AI Controls Matrix ofrece un marco de controles más amplio para sistemas de IA basados en la nube. Su edición de 2026 incluye 247 objetivos en 18 dominios de seguridad.
Sin embargo, la disponibilidad de marcos no es la principal limitación. El benchmark muestra que las organizaciones ya reconocen muchos riesgos en el nivel de gobernanza. La implementación dentro de la arquitectura de aplicaciones y las operaciones de seguridad sigue siendo la tarea más difícil.
La IA agéntica hace urgente esa implementación. Un chatbot con controles débiles puede divulgar información o producir una respuesta perjudicial. Un agente con controles débiles también puede actuar basándose en esa respuesta.
La respuesta a incidentes y la recuperación siguen siendo los eslabones más débiles
Las organizaciones no pueden afirmar que tienen resiliencia operativa cuando la mayoría carece de investigaciones específicas para IA, planes de respuesta y prácticas de recuperación estandarizadas.
El benchmark de Wavestone otorga a Respond la puntuación de madurez más baja, con un 29%. Sus medidas de apoyo muestran por qué.
Solo el 8% de las organizaciones evaluadas podía realizar investigaciones forenses en plataformas de IA. La informática forense de IA implica reconstruir los prompts relevantes, el contenido recuperado, la actividad de herramientas, las versiones de modelos, los permisos y los cambios en los sistemas.
La mitad del panel seguía utilizando medidas correctivas ad hoc sin un proceso de respuesta estructurado. Solo el 13% contaba con planes documentados de respuesta a incidentes específicos para IA, y Wavestone afirma que esos planes no se aplicaban de manera consistente.
La recuperación también fue limitada. El veintidós por ciento realizaba copias de seguridad de activos relacionados con IA, con prácticas mayoritariamente no estandarizadas.
Una copia de seguridad de una aplicación tradicional puede preservar el código y las bases de datos. Un servicio de IA puede depender de activos adicionales, como configuraciones de modelos, datos de ajuste fino, embeddings, políticas de seguridad, prompts y fuentes externas de conocimiento.
Restaurar la disponibilidad no establece la confianza. Un repositorio de conocimiento recuperado puede seguir conteniendo documentos envenenados. Un agente restaurado puede conservar credenciales comprometidas o permisos inseguros.
El primer reto de la respuesta es la clasificación. Los equipos deben distinguir los eventos de seguridad de los fallos de fiabilidad, las infracciones de políticas, los errores de modelos y los errores ordinarios de los usuarios. Algunos incidentes abarcan varias categorías.
Una acción no autorizada de un agente podría comenzar con una inyección de prompts, exponer datos y crear registros incorrectos. Quienes respondan pueden necesitar conocimientos de seguridad, privacidad, asuntos legales, ingeniería, riesgo de modelos y negocio.
El segundo reto es la evidencia. Los investigadores necesitan registros sincronizados entre servicios de modelos, sistemas de identidad, componentes de recuperación, pasarelas de herramientas y aplicaciones de destino. La falta de contexto puede impedir la reconstrucción.
Por tanto, la cifra de registro del 88% de Wavestone puede parecer más tranquilizadora de lo que realmente es. El registro solo ayuda a la respuesta cuando los equipos conservan los eventos adecuados, los correlacionan y los ponen a disposición de los investigadores.
El tercer reto es la contención. Las organizaciones deben saber cómo desactivar un agente, revocar sus credenciales, poner en cuarentena un conjunto de datos, cambiar de modelo o suspender una herramienta conectada sin provocar una interrupción más amplia.
El cuarto reto es la recuperación. Los equipos necesitan un estado conocido como seguro y una prueba de integridad antes de devolver el sistema al servicio. De lo contrario, la recuperación puede restaurar la misma vulnerabilidad o información comprometida.
Esta complejidad operativa explica por qué la madurez de la respuesta va por detrás de la gobernanza. Las políticas a menudo pueden ampliar las estructuras existentes de gestión de riesgos. La respuesta a incidentes de IA requiere nueva evidencia técnica, procedimientos interequipos y ejercicios.
El reducido panel del benchmark sigue siendo una limitación importante. Estos porcentajes no deberían convertirse en afirmaciones sobre todas las grandes empresas. Las organizaciones que se ofrecieron voluntariamente para evaluaciones detalladas también pueden diferir del mercado en general.
También cambió la medición. Wavestone amplió su evaluación de 2026 para incluir seguridad de agentes, protecciones especializadas, supervisión y respuesta. Por ello, las comparaciones directas interanuales deberían centrarse en medidas claramente equivalentes.
Aun así, el patrón se alinea con las directrices de riesgo establecidas. El perfil de IA generativa de NIST hace hincapié en la documentación de incidentes, el registro, la notificación y el intercambio de información durante el ciclo de vida.
La interpretación escéptica no es que la gobernanza haya fracasado. Es que la madurez de la gobernanza puede generar una falsa confianza cuando la evidencia operativa sigue siendo escasa.
Una política puede cumplir un hito interno. No demuestra que un equipo de seguridad pueda detectar una recuperación comprometida, rastrear las acciones de un agente o restaurar un sistema fiable.
Tres señales mostrarán si las operaciones se ponen al día
La siguiente fase de madurez de la seguridad de IA se medirá mediante telemetría conectada, permisos de agentes exigibles y recuperación ensayada.
La primera señal es el porcentaje de organizaciones que incorporan eventos de IA a la supervisión activa de seguridad. Wavestone detectó una brecha de 80 puntos entre recopilar registros de aplicaciones e integrarlos en la supervisión del SOC.
Cerrar esa brecha requiere casos de detección definidos, no simplemente reenviar cada registro. Los equipos deberían identificar eventos que indiquen recuperación sospechosa, escalada de privilegios, uso inusual de herramientas o intentos de extracción de datos.
La evidencia de mejora incluiría alertas probadas, guías de investigación y responsabilidad compartida entre los equipos de IA y SOC. Otro documento de políticas no resolvería la brecha operativa.
La segunda señal es la adopción de controles de identidad específicos para agentes. El resultado actual del 15% muestra que el reconocimiento en materia de gobernanza ha avanzado por delante de la aplicación técnica.
El progreso debería manifestarse mediante identidades de agente diferenciadas, accesos de alcance limitado, credenciales de corta duración y autorización dentro de los servicios posteriores. Las acciones de alto impacto deberían contar con requisitos explícitos de aprobación.
Esta señal será más importante a medida que las organizaciones introduzcan agentes en finanzas, operaciones de atención al cliente, entrega de software y flujos internos de conocimiento. Cada herramienta adicional amplía las consecuencias del acceso excesivo.
La tercera señal es si las organizaciones ponen a prueba la recuperación de incidentes específica para IA. Un plan por escrito es útil, pero los equipos deben probar la contención, la investigación, la restauración y la validación de integridad.
Los ejercicios deberían abarcar conjuntos de datos comprometidos, fuentes de conocimiento envenenadas, credenciales filtradas, cambios inseguros de modelos y acciones no autorizadas de agentes. También deberían comprobar si la organización puede continuar el trabajo crítico durante la contención.
Estas señales reforzarán o debilitarán el juicio central de Wavestone. Una mayor integración de la supervisión mostraría que la gobernanza se está trasladando a las operaciones. Mejores controles de identidad demostrarían que las políticas sobre agentes se están volviendo exigibles.
Los ejercicios de recuperación exitosos aportarían la evidencia más sólida. Mostrarían que las organizaciones pueden mantener el control cuando falla la prevención, en lugar de asumir que todas las salvaguardas funcionarán.
El Wavestone AI Cyber Benchmark 2026 presenta una disyuntiva que los líderes empresariales no pueden resolver únicamente mediante una adopción más lenta. Un mayor desarrollo interno puede mejorar la autonomía y el control arquitectónico, pero también traslada la responsabilidad hacia dentro.
Los responsables de seguridad deberían exigir evidencia detrás de cada hito de gobernanza. ¿Qué sistemas envían eventos accionables al SOC? ¿Qué permisos de agentes pueden revocarse de inmediato? ¿Qué activos de IA cuentan con procedimientos de recuperación probados?
Los responsables de ingeniería y negocio deberían plantear preguntas paralelas. ¿Quién es responsable de cada sistema desplegado tras la aprobación? ¿Qué cambios desencadenan una reevaluación? ¿Qué persona puede detener una acción autónoma antes de que alcance una aplicación crítica?
La pregunta decisiva ya no es si una organización tiene una política de IA. Es si esa organización puede detectar, contener, investigar y recuperarse cuando un sistema de IA se comporta fuera de lo esperado.
