Lo que AWS Reimagine revela sobre la brecha de gobernanza de IA en las empresas
Una empresa logró que el 88% de sus empleados adoptaran herramientas de IA y, aun así, solo consiguió mejoras reales en menos de una de cada 5,000 sesiones. Ese dato, oculto en el nuevo informe Reimagine 2026 de Amazon Web Services, dice más sobre el estado actual de la gobernanza de IA empresarial que cualquier encuesta de adopción publicada este año. El uso era generalizado. El valor verificable y gobernado, casi inexistente. Y la distancia entre ambos es exactamente donde hoy reside la mayor exposición a riesgos de seguridad y cumplimiento para la mayoría de las organizaciones.
AWS elaboró el informe Reimagine 2026 tras nueve meses de entrevistas confidenciales, de noviembre de 2025 a julio de 2026, con 154 líderes —en su mayoría ejecutivos C-level que dirigen programas de IA en 23 industrias y 27 países—, acompañados por investigadores sénior de Amazon que codificaron y verificaron los hallazgos. No es una encuesta de proveedores inflada con porcentajes de adopción. Es una lectura detallada de cómo la gobernanza se desmorona en la práctica cuando los agentes de IA empiezan a operar dentro de procesos empresariales reales, y aborda un tema que Kiteworks ha seguido de cerca en su propia investigación. La adopción avanza más rápido que los controles diseñados para gobernarla, y la brecha resultante es ahora tanto un problema de gobernanza de datos como de tecnología.
Ese enfoque es clave para quien asume las consecuencias cuando algo sale mal. Un CISO o responsable de cumplimiento no ve la IA en la sombra como una historia de productividad. La vive como una pregunta imposible de responder ante un regulador o un abogado contrario: ¿quién autorizó a este agente de IA a acceder a estos datos, y estaban cifrados, registrados y controlados en ese momento? Los hallazgos de AWS, vistos desde esa óptica, describen un vacío de responsabilidad que Kiteworks secure data exchange fue diseñado para cerrar, porque los reguladores regulan datos, no modelos, y una trazabilidad que no puede responder a esa pregunta no es evidencia.
Este artículo analiza lo que encontró AWS, separa las estadísticas verificadas de las cifras mal atribuidas a este informe en coberturas secundarias, y conecta la brecha de gobernanza con los controles específicos —aplicación de acceso por solicitud, aislamiento de credenciales y registros de auditoría unificados— que convierten la supervisión de riesgos de IA en algo que un auditor puede inspeccionar, más allá de un simple documento de políticas.
Principales conclusiones
1. La adopción no es evidencia de valor gobernado.
AWS encontró una organización con un 88% de adopción de herramientas de IA que solo logró mejoras reales en menos de una de cada 5,000 sesiones, demostrando que las métricas de uso dicen casi nada sobre si la salida de la IA es segura, precisa o autorizada.
2. La gobernanza de IA documentada sigue siendo la excepción, no la norma.
Una encuesta complementaria de Strand Partners a empresas europeas, encargada por AWS, reveló que más de la mitad de las pymes y grandes empresas, junto con tres cuartas partes de las startups, ya usan IA, pero solo el 24% tiene un enfoque documentado de IA responsable y apenas el 10% cuenta con una estrategia de gobernanza de datos.
3. Los ciclos de aprobación lentos empujan el uso de IA a la sombra.
Entrevistados por AWS describieron la aplicación de procesos de revisión de TI de seis meses a experimentos de IA que avanzan en días, y reportaron que cuando un experimento de dos semanas enfrenta una aprobación de un mes, los equipos dejan de pedir permiso y empiezan a pedir perdón, convirtiendo la política en un motor de IA en la sombra en vez de un control.
4. La gobernanza debe estar fuera del sistema de IA, no dentro de él.
La propia guía del informe para IA agentica exige controles de identidad, acceso y cifrado que operen independientemente del agente, además de una autonomía escalonada que solo se amplía tras demostrar fiabilidad, lenguaje que AWS compara con el periodo de prueba de una nueva contratación.
5. La solución es la aplicación codificada en la capa de datos, no otro documento de políticas.
Cerrar la brecha que describe AWS requiere controles que se apliquen automáticamente en el punto donde un agente de IA solicita datos, que es precisamente la función de Kiteworks Compliant AI y el Kiteworks Secure MCP Server.
Dentro de la investigación AWS Reimagine 2026
El equipo de Reimagine, un grupo de Ejecutivos en Residencia de AWS provenientes de ex líderes C-level de organizaciones como el Jet Propulsion Laboratory de la NASA, dedicó nueve meses a esta investigación en vez de limitarse a una encuesta. Entre noviembre de 2025 y julio de 2026, realizaron 154 entrevistas, 128 de ellas con ejecutivos de 23 industrias y 27 países, complementadas por líderes y expertos de AWS que aplicaron métodos computacionales de grounded theory para codificar las transcripciones de manera consistente. AWS también recurrió a un estudio interno sobre la dinámica de adopción de IA entre más de 35,000 profesionales en 27 países para contrastar los hallazgos de las entrevistas con un conjunto de datos mucho mayor.
Esa metodología importa porque produjo algo que las encuestas de adopción rara vez capturan: un relato coherente, contado desde dentro de docenas de organizaciones, que describe cómo se forma la brecha entre uso y gobernanza de IA. Los investigadores fueron explícitos: esto no es un modelo de madurez ni un discurso comercial disfrazado de investigación. Se presenta como un diagnóstico, y el diagnóstico es que la mayoría de las organizaciones construyeron su gobernanza de IA para un mundo donde los proyectos tecnológicos avanzaban al ritmo del ciclo presupuestario anual, y la IA no respeta ese ritmo.
Vale la pena aclarar una advertencia, ya que una estadística ampliamente difundida sobre este informe es incorrecta. Algunas coberturas secundarias atribuyen a AWS Reimagine 2026 la cifra «83% de adopción, 13% de visibilidad». Ese número no aparece en el informe de AWS ni en su propio anuncio. Proviene de una encuesta de otro proveedor sin relación. Las cifras verificadas de AWS y Strand Partners que se presentan a continuación son las que realmente sirven para fundamentar un argumento de gobernanza.
Confías en que tu organización es segura. Pero ¿puedes verificarlo?
Leer ahora
Cuando el 88% de adopción produce casi ningún valor gobernado
La evidencia más clara de que la adopción es una métrica equivocada de éxito proviene de un caso que AWS destaca en su investigación. Una empresa mostró un 88% de adopción de herramientas, es decir, casi todos los empleados usaron el sistema de IA al menos una vez, pero menos de una de cada 5,000 sesiones generó un trabajo realmente mejor que el anterior. La adopción fue universal. La mejora, estadísticamente casi invisible. AWS detectó el mismo patrón en el conjunto de datos más amplio, señalando que menos del 5% de los profesionales que se familiarizaron con la IA al inicio de su recorrido llegaron a un nivel sofisticado de uso que genera valor empresarial medible.
Esa brecha debería cambiar la forma en que los equipos de seguridad o cumplimiento leen su propio panel de adopción de IA. Un número alto de adopción indica alta exposición. No dice nada sobre si esa exposición está gobernada, si los datos a los que accedió un agente eran apropiados para que los viera, o si alguien podría reconstruir después lo que ocurrió en cualquiera de esas sesiones. Una métrica de adopción sin un registro de acceso correspondiente no es una métrica de gobernanza. Es una superficie de riesgo con un nombre amigable.
Este es precisamente el punto ciego que los programas de gobernanza de datos de IA deben cerrar primero, antes de invertir en expandir la capacidad de IA. La visibilidad sobre qué tocó un agente de IA, y la autoridad sobre lo que podía tocar, deben existir en el momento en que ocurre la solicitud, no como un informe retrospectivo generado semanas después cuando alguien finalmente pregunta.
Hallazgos de Strand Partners sobre adopción sin gobernanza
Las propias entrevistas de AWS se ven reforzadas por una encuesta complementaria encargada a Strand Partners, «Unlocking Europe’s AI Potential in the Digital Decade 2025», basada en datos de miles de empresas europeas. El patrón hallado coincide casi exactamente con los datos de las entrevistas. Más de la mitad de las pymes y grandes empresas, junto con tres cuartas partes de las startups, ya reportan usar IA. Sin embargo, solo el 24% tiene un enfoque documentado para el uso responsable de IA. Apenas el 10% cuenta con una estrategia de gobernanza de datos.
Sasha Rubel, responsable de Política de IA y Generative AI para AWS en EMEA, rechazó interpretar esas cifras como un simple fracaso. «Refleja la verdadera dificultad de gobernar una tecnología que se reinventa cada trimestre», dijo a los investigadores de Reimagine. Es un punto válido, pero no cambia la exposición que describen esos números. Una organización que usa IA sin una estrategia documentada de gobernanza de datos no tiene una base consistente para responder a la pregunta más básica de un regulador: qué datos accedió este sistema, bajo qué autoridad y a dónde fue el resultado. Explicar la dificultad de por qué la gobernanza va por detrás de la adopción no es lo mismo que demostrar que la brecha es segura de dejar abierta.
El argumento positivo también merece ser mencionado, porque refuerza el caso de negocio para cerrar la brecha, no solo el de cumplimiento. La investigación de Bain & Company sobre adopción responsable de IA, citada en el mismo informe de AWS, encontró que las organizaciones con un enfoque efectivo de IA responsable ven un impacto medio en sus beneficios del 6 al 10% gracias a sus casos de uso de IA, frente al 3 al 5% de las organizaciones sin ese enfoque. La gobernanza, bien hecha, no es un impuesto al valor de la IA. Es un multiplicador.
Por qué los ciclos de revisión de seis meses no pueden gobernar una IA que avanza en días
El hallazgo más concreto y útil para un líder de cumplimiento en el informe de AWS tiene que ver con el diseño de procesos más que con la tecnología. Muchas de las organizaciones entrevistadas por AWS siguen aplicando el mismo rigor de aprobación a los experimentos de IA que usaban para programas tradicionales de TI de seis meses, con comités que revisan propuestas de IA, documentos de políticas aprobados por legal y una firma humana obligatoria en los resultados. Esos procesos funcionaban cuando un proyecto tardaba seis meses en construirse. No funcionan cuando la misma idea puede prototiparse en días.
Tony Leopold, CTO de United Rentals, describió el cambio de forma directa en el informe. El trabajo que antes costaba cientos de miles de dólares y seis meses de ejecución ahora ocurre en días y por cientos de dólares. Un proceso de revisión calibrado para el antiguo cronograma se vuelve, en palabras de AWS, «insuficiente cuando lleva seis días», porque la gobernanza está fuera del sistema de IA, añadida después en vez de integrada, y tiende a tratar cada caso de uso como de alto riesgo por defecto.
La consecuencia es predecible y AWS la nombra directamente. Si un experimento de dos semanas enfrenta una revisión de un mes, los equipos dejan de pedir permiso y empiezan a pedir perdón tras seguir adelante. La política, en esa situación, no está minimizando el riesgo. Lo está empujando a la sombra, hacia herramientas no monitoreadas y flujos de trabajo sin registro que el equipo de seguridad solo descubre cuando ya ocurrió un problema. Chris Sedore, Vicepresidente de Servicios de Información y Tecnología y CIO de la Universidad de Boston, cuantificó hasta dónde ha llegado esto en su propia institución, estimando que entre el 40 y el 50% del personal usa IA al menos semanalmente, «parte en modelos y sistemas que ofrecemos, parte de forma no autorizada». Un entrevistado describió esta dinámica como familiar en forma pero no en escala, señalando que los CIOs que pasaron años gestionando TI en la sombra ahora enfrentan IA en la sombra a una escala diez veces mayor.
La IA en la sombra es un síntoma del diseño de gobernanza, no un problema de usuario
Sería fácil interpretar los hallazgos sobre IA en la sombra como un problema de disciplina, empleados que ignoran las reglas, y diseñar una respuesta basada en más formación y una aplicación más estricta del proceso de aprobación existente. El propio análisis de AWS rechaza esa lectura, y vale la pena tomarlo en serio. La existencia de IA en la sombra no es evidencia de que la gobernanza haya fracasado como concepto. Es evidencia de que la gobernanza se ha diseñado de forma que las personas la perciben como una barrera excesiva para hacer su trabajo, lo que significa que la solución es rediseñar, no reforzar el mismo diseño con más consecuencias.
Ese diagnóstico coincide con lo que otros investigadores están encontrando de forma independiente a AWS. El informe 2026 AI-Ready Governance Survey Report de OneTrust, realizado con Sapio Research entre 1,200 altos responsables de decisión en ocho mercados, halló que el 87% de las organizaciones fomenta activamente el uso de agentes de IA por parte de los empleados, mientras solo el 47% tiene una gobernanza clara sobre cómo pueden operar esos agentes. Dos investigaciones independientes, de organizaciones y metodologías distintas, coinciden en la misma brecha estructural. El liderazgo quiere la productividad, y la capa de control aún no se ha puesto al día.
Cerrar esa brecha no significa construir una versión más estricta del mismo proceso de gobierno, riesgo y cumplimiento y aplicarlo a la IA más lentamente. Significa sacar la gobernanza de un documento que aprueba un comité una vez y trasladarla a un sistema que aplica la regla cada vez que un agente de IA solicita acceso a datos, lo que es un control de naturaleza completamente diferente. Una política que dice que un agente de IA solo debe acceder a datos relevantes para su tarea es imposible de hacer cumplir si nada verifica esa afirmación en el momento de la solicitud. El control de acceso basado en atributos que evalúa cada solicitud según el rol del agente, la sensibilidad del contenido y el contexto de la tarea es lo que convierte esa política en realidad y no en aspiración.
Cuatro principios acertados del informe sobre la gobernanza de IA agentica
AWS resume su investigación en cuatro principios prácticos para gobernar la IA agentica, y cada uno corresponde directamente a una brecha de control que la mayoría de las organizaciones deja abierta. El primero es acertar con lo básico antes que nada. La identidad, el acceso y el cifrado siguen siendo los mecanismos de protección que evitan que los fallos de seguridad avancen a velocidad de máquina, y saltárselos porque un agente parece demasiado rápido para detenerse es justo lo contrario de lo correcto. El segundo es establecer límites de seguridad fuera del propio agente, ya que los agentes pueden malinterpretar o eludir reglas incrustadas en sus instrucciones, lo que significa que los límites reales deben estar en la infraestructura, fuera del alcance del agente.
El tercer principio trata la autonomía como algo que el agente debe ganarse y no como algo que se le concede por defecto. La propia formulación de AWS es directa: empezar con aprobación humana, ampliar la autonomía solo tras demostrar fiabilidad y mantener la capacidad de restringirla de nuevo. «Trátalo como el periodo de prueba de una nueva contratación», aconseja el informe, una comparación que resonará con cualquier responsable de cumplimiento que ya gestiona la incorporación, provisión de acceso y revisión periódica de accesos para empleados humanos y nunca ha extendido esa disciplina a una identidad no humana con alcance similar. El cuarto principio exige pruebas continuas en vez de una aprobación única, ya que los modelos se actualizan, los prompts evolucionan y cada cambio puede introducir un fallo que la revisión original nunca anticipó.
En conjunto, estos cuatro principios describen un enfoque que AWS denomina gobernanza como código: políticas traducidas en mecanismos de aplicación que operan a velocidad de máquina, de modo que el juicio humano se reserva para excepciones genuinas y no para volver a aprobar la misma decisión de bajo riesgo cada vez que se repite. Es una arquitectura muy diferente a la de una junta de revisión mensual, y es la arquitectura que Kiteworks Compliant AI y el Secure MCP Server están diseñados para ofrecer.
Cerrando la brecha de evidencia para CISOs y responsables de cumplimiento
Cada hallazgo del informe de AWS termina en la misma pregunta que un CISO o responsable de cumplimiento debe responder bajo presión: si la organización puede aportar evidencia, no una garantía ni un documento de políticas, sino un registro específico, con sello de tiempo y atribución, de lo que ocurrió cuando un agente de IA accedió a datos confidenciales. El Informe anual de riesgos de seguridad y cumplimiento de datos de Kiteworks 2026 encontró una brecha paralela en el lado de la aplicación, con el 79% de las organizaciones sin capacidad automatizada de kill switch para sus sistemas de IA, lo que significa que la mayoría no podría detener de forma fiable a un agente de IA a mitad de tarea si comenzara a acceder a datos indebidos. La adopción superando a la gobernanza y la aplicación superando a la respuesta a incidentes son el mismo problema de fondo visto desde dos ángulos distintos.
Un Panel de CISO que muestre la actividad de cada agente de IA en un solo lugar es un punto de partida, pero la visibilidad por sí sola no responde a la pregunta de responsabilidad que plantea AWS: ¿quién es el propietario designado cuando un agente de IA causa un daño? Esa pregunta no se responde solo con un organigrama. Se responde con un sistema que genera el registro automáticamente. El Control Plane de Kiteworks captura cada interacción IA-contenido en una trazabilidad de auditoría unificada, lo que significa que la evidencia que un regulador o abogado contrario pedirá ya existe, en vez de tener que reconstruirse bajo presión. La propia recomendación de AWS para el siguiente paso —crear un registro de agentes con un propietario designado para cada agente en producción— solo funciona si ese registro está respaldado por logs lo suficientemente precisos para demostrar lo que hizo cada agente, y eso es un requisito de la capa de datos, no un ejercicio de hoja de cálculo.
Cómo Kiteworks Compliant AI y Secure MCP Server cierran la brecha
Los controles específicos que señala la investigación de AWS —límites fuera del agente, acceso que escala con fiabilidad demostrada y aplicación continua en vez de una revisión única— describen casi exactamente lo que Kiteworks Compliant AI está diseñado para hacer. Cada solicitud de contenido por parte de un agente de IA o modelo de lenguaje grande se evalúa en tiempo real contra políticas basadas en roles y atributos, no después, lo que materializa el principio de «gobernanza fuera del agente» que recomienda AWS.
El Secure MCP Server extiende esa misma aplicación a la categoría de riesgo de IA de mayor crecimiento: agentes que se conectan a sistemas empresariales mediante el Model Context Protocol. Almacena los tokens de autenticación OAuth en el almacén seguro de credenciales del sistema operativo, en vez de exponerlos en prompts, de modo que un agente comprometido o mal configurado no pueda usar credenciales robadas para acceder a datos fuera de sus permisos, y registra cada interacción en la misma trazabilidad de auditoría unificada que cubre el correo electrónico seguro, la transferencia gestionada de archivos y el uso compartido de archivos de Kiteworks. Esa combinación —aplicación en el punto de solicitud más un registro completo y exportable de cada acceso— es lo que convierte la recomendación de AWS de «gobernanza como código» en algo verificable por un auditor durante una auditoría.
Las organizaciones no tienen que elegir entre la velocidad que promete la IA y la gobernanza que exigen los reguladores. El informe AWS Reimagine 2026 lo demuestra, respaldado por 154 entrevistas ejecutivas y una encuesta complementaria a miles de empresas europeas: intentar tener velocidad sin gobernanza produce adopción sin valor verificable y un problema de IA en la sombra que supera al anterior. Integrar la gobernanza en la propia capa de datos, en vez de añadirla a posteriori al sistema de IA, es lo que permite a la organización conservar ambas cosas.
Para saber más sobre cómo cerrar la brecha entre la adopción de agentes de IA y el acceso gobernado y auditable a los datos, solicita una demo personalizada hoy.
Preguntas frecuentes
No necesariamente, y AWS lo aclara directamente. El uso generalizado de IA en la sombra es evidencia de que los empleados consideran que el camino aprobado es demasiado lento o restrictivo en comparación con el valor que ofrece la IA, no de que la gobernanza sea una mala idea. La respuesta útil es tratar el volumen de IA en la sombra como una métrica honesta de dónde tu proceso de revisión genera fricción, y luego trasladar los controles importantes —control de acceso y visibilidad de datos, en particular— al propio sistema, para que el camino aprobado sea el rápido y no el lento.
Como mínimo, un registro con sello de tiempo que indique qué agente o modelo hizo la solicitud, a qué contenido accedió, qué política autorizó ese acceso y a dónde fue cualquier salida generada. Una declaración general como «el sistema de IA está monitoreado» no satisfará a un regulador ni a un auditor. Una trazabilidad de auditoría generada automáticamente en el momento de cada solicitud, en vez de reconstruida tras un incidente, marca la diferencia entre una respuesta defendible y una improvisación.
La mayoría de los sistemas de gestión de identidades y accesos controlan si un usuario o cuenta de servicio puede autenticarse en un sistema. Kiteworks Compliant AI controla una cuestión más específica y relevante: qué contenido concreto puede ver ese agente de IA o modelo de lenguaje grande para esa solicitud particular, evaluado en tiempo real según políticas basadas en roles y atributos. Esa aplicación por solicitud es lo que el informe de AWS describe como establecer límites de seguridad fuera del agente, en vez de confiar en que el propio agente siga las instrucciones.
La investigación de AWS encontró que esto sigue sin resolverse en las organizaciones analizadas, y considera que la propia ambigüedad es parte del problema a solucionar, en vez de asumir que ya existe una respuesta clara. Su recomendación es estructural y no organizativa: mantener un registro de agentes con un propietario humano designado para cada agente en producción, de modo que la responsabilidad no dependa de reconstruir intenciones después de un incidente. Una trazabilidad de auditoría unificada en todos los sistemas que toca un agente hace que esa titularidad sea exigible y no solo simbólica.
Sí, y este es el argumento central de la recomendación de gobernanza como código del informe de AWS. La lentitud proviene de canalizar cada decisión de IA a través de un comité humano sin importar el nivel de riesgo, no de tener gobernanza. Codificar la política en la capa de datos, para que las solicitudes de bajo riesgo se evalúen y aprueben automáticamente mientras las de alto riesgo o inusuales lleguen a un humano, preserva el control y elimina el cuello de botella humano en la mayoría de las decisiones rutinarias. El Secure MCP Server aplica exactamente este modelo a los agentes que se conectan mediante el Model Context Protocol.
Recursos adicionales
- Artículo del Blog
Estrategias Zero‑Trust para proteger la privacidad de IA de forma 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.