La confianza en la IA cayó 17 puntos. La gobernanza de identidades no humanas es la razón.
Una caída de 17 puntos en la autoevaluación de madurez en IA puede sonar alarmante. No lo es. Es lo que sucede cuando los líderes de TI dejan de calificar sus programas de IA según sus aspiraciones y empiezan a evaluarlos con base en evidencias reales.
La encuesta de tendencias de VentureBeat del Q3 2026, realizada a 800 líderes de TI en Estados Unidos y Reino Unido, reveló que el porcentaje de encuestados que consideraba a su organización «madura» en la implementación de IA cayó del 40% hace seis meses al 23% actualmente. Esto no significa que los programas de IA hayan empeorado. Significa que quienes los gestionan por fin miraron lo suficiente para ver la realidad: agentes implementados sin responsables, permisos nunca revisados y una fuerza laboral no humana que creció más rápido de lo que nadie pudo seguirle el ritmo.
La cifra que impulsa esa reevaluación es contundente. Las identidades no humanas —cuentas de servicio, claves API y agentes de IA que actúan en nombre de empleados y sistemas— ya superan en número a los usuarios humanos en el 83% de las organizaciones encuestadas por VentureBeat. Y el control menos implementado para gestionarlas, la gobernanza de identidades no humanas, apenas alcanza un 21% de adopción, la cifra más baja entre todas las prácticas de seguridad de IA evaluadas. Juntando ambos datos, el panorama es claro: la mayoría de las empresas tiene más identidades de máquina que personas, y menos de una de cada cuatro cuenta con un programa real de gobernanza para ellas.
Por eso esta encuesta también es relevante para Kiteworks. El intercambio seguro de datos de Kiteworks ofrece a las organizaciones un punto de control gobernado para el movimiento de datos sensibles entre personas, sistemas y agentes de IA, en vez de dejar ese tráfico disperso entre credenciales compartidas y conexiones sin control. La caída en la confianza no es un retroceso. Es la señal de que el trabajo real —cerrar la brecha de identidades no humanas— apenas está comenzando.
Conclusiones clave
1. Las autoevaluaciones de madurez en IA se desplomaron en seis meses.
La encuesta de tendencias de VentureBeat del Q3 2026 a 800 líderes de TI en EE. UU. y Reino Unido mostró que el porcentaje que describía a su organización como «madura» en la implementación de IA cayó del 40% al 23%, una disminución de 17 puntos que indica que los líderes por fin están evaluando sus programas con base en la realidad y no en aspiraciones.
2. Las identidades no humanas ya superan a los usuarios humanos.
En el 83% de las organizaciones encuestadas, las identidades de máquinas y agentes ya superan en número a los humanos en plantilla, pero los controles diseñados para gestionar cuentas humanas nunca se pensaron para una fuerza laboral que genera nuevas identidades cada hora.
3. La gobernanza de esas identidades es el control menos maduro evaluado.
Solo el 21% de las organizaciones cuenta con gobernanza de identidades no humanas, lo que la convierte en la mayor brecha individual en el modelo de madurez de seguridad de IA de VentureBeat, y en la que la mayoría de las empresas ni siquiera ha empezado a trabajar.
4. La madurez se correlaciona directamente con la capacidad de escalar.
Las organizaciones en el nivel más alto de madurez de la encuesta tenían cinco veces más probabilidades de reportar que no enfrentan barreras para expandir la implementación de agentes de IA, convirtiendo la gobernanza en un motor de crecimiento y no solo en un requisito de cumplimiento.
5. El uso compartido de credenciales es la norma, no la excepción.
Sin controles de identidad y acceso por agente, la mayoría de las organizaciones sigue canalizando agentes de IA a través de cuentas de servicio compartidas o credenciales humanas, un patrón que borra la trazabilidad en cuanto ocurre un problema.
Confías en que tu organización es segura. Pero ¿puedes comprobarlo?
Léelo ahora
La caída de 17 puntos: ¿Qué cambió entre dos encuestas separadas por seis meses?
Hace seis meses, el 40% de los líderes de TI encuestados por VentureBeat describían la implementación de IA de su organización como madura. En la encuesta del Q3 2026, esa cifra es del 23%. Si se mira solo ese dato, una caída de 17 puntos parece indicar un retroceso en los programas de IA. Pero considerando todo lo que cambió en esos seis meses, la historia es diferente.
La mayoría de las empresas no frenó sus implementaciones de IA en ese periodo. Las aceleraron. Los departamentos siguieron creando agentes para atención al cliente, ayuda en programación, procesamiento de documentos, investigación interna, prácticamente cualquier caso de uso justificable. Los proveedores siguieron lanzando funciones de agentes activadas por defecto. Y con cada nueva implementación, otra identidad no humana entraba al entorno, casi siempre sin que nadie presentara una solicitud formal, obtuviera aprobación o fuera nombrado responsable. La confianza debía caer en ese entorno, porque quienes estaban más cerca de estas implementaciones podían ver que la gobernanza no avanzaba al ritmo de la proliferación de identidades.
Esa es la lectura más saludable de los datos. Un puntaje de madurez que siguiera subiendo mientras la gobernanza de identidades no humanas se mantiene en solo 21% de adopción sería en realidad una señal peor, porque significaría que los líderes de TI están evaluando sus programas con criterios que ignoran la categoría de riesgo de mayor crecimiento. Un puntaje que cae a medida que los líderes descubren cuánto terreno les falta por cubrir indica que la evaluación se volvió más rigurosa. VentureBeat lo resume bien: la caída muestra que las organizaciones se están auditando con honestidad y no solo con confianza, algo que debe suceder antes de cerrar la brecha que revela la encuesta.
Esta distinción es importante para cómo los equipos de seguridad y cumplimiento deben presentar estos hallazgos internamente. Un miembro del consejo o un CFO que vea «la madurez en IA cayó 17 puntos» sin contexto podría interpretarlo como prueba de que la inversión en IA no está dando frutos. El enfoque más preciso, y el que vale la pena llevar a las conversaciones presupuestarias, es que el programa de gobernanza de datos de IA de la organización ahora se mide frente al verdadero alcance del crecimiento de identidades no humanas, y no frente al alcance mucho menor que existía cuando se hizo la evaluación anterior. Una evaluación formal de riesgos que mapea cada agente en funcionamiento con sus permisos actuales y su justificación de negocio real da a los equipos de cumplimiento la base probatoria que necesitan para cerrar brechas de manera estratégica y no solo reactiva.
Las identidades no humanas se han convertido silenciosamente en la mayoría
La estadística que debería reordenar toda hoja de ruta de seguridad de IA para 2026 es esta: las identidades no humanas ya superan en número a los usuarios humanos en el 83% de las organizaciones encuestadas. No es un hallazgo de nicho sobre unas pocas empresas pioneras en IA. Es la norma.
Cada agente de IA que una organización implementa normalmente necesita su propia identidad, o más a menudo, hereda la de otra persona. Cada integración de API entre un modelo de lenguaje grande y un sistema interno requiere credenciales. Cada flujo de trabajo automatizado que extrae un documento, resume un contrato o redacta un correo en nombre de una persona opera bajo alguna identidad, ya sea que esa identidad se haya aprovisionado deliberadamente o se haya tomado prestada de cualquier cuenta de servicio disponible. Multiplica eso por bots de atención al cliente, copilotos de programación, agentes de resumen de documentos, asistentes de investigación interna y la creciente lista de herramientas de proveedores que incluyen funciones de agentes activadas por defecto, y se entiende por qué el número de identidades no humanas en una empresa que adopta IA de agentes a escala puede superar ampliamente al de personas en cuestión de meses.
La mayoría de los programas de gestión de identidades y acceso nunca se diseñaron para esto. Los sistemas de IAM, controles de acceso y flujos de aprovisionamiento se crearon bajo un ritmo predecible: un empleado se incorpora, obtiene una cuenta, se le asignan accesos según su rol y, cuando se va, se da de baja la cuenta. Las identidades no humanas no siguen ese ciclo. Un agente puede crearse en una tarde por un desarrollador probando una integración, recibir permisos amplios para avanzar rápido y luego quedar funcionando indefinidamente porque nadie tiene la tarea de retirarlo. No hay un sistema de RRHH que registre cuándo empezó un agente, y normalmente nadie puede decir con certeza cuántos están activos ni qué pueden hacer. El CISO Dashboard proporciona la visibilidad unificada y en tiempo real de todos los eventos de acceso a datos mediados por IA, haciendo visible este inventario de agentes para la dirección de seguridad —el requisito previo para cualquier programa de gobernanza que pretenda gestionar lo que ahora no puede ver.
Esa es la razón estructural por la que la gobernanza de identidades no humanas va a la zaga de cualquier otra práctica de seguridad de IA en la encuesta de VentureBeat. No es que los equipos de seguridad no se preocupen por ello. Es que las herramientas y procesos en los que la mayoría de las organizaciones confía para la gobernanza de identidades se crearon pensando en una plantilla humana relativamente estable y predecible, y el crecimiento de identidades no humanas rompe todos los supuestos de ese modelo.
Por qué la gobernanza de identidades no humanas es la práctica de seguridad de IA menos adoptada
De todas las prácticas de seguridad de IA que VentureBeat midió, la gobernanza de identidades no humanas quedó en último lugar, con solo el 21% de las organizaciones reportando que la tienen implementada. Ese ranking merece atención, porque significa que el control más directamente vinculado a la categoría de identidades de mayor crecimiento en la empresa es también el que las organizaciones han tardado más en construir.
Varios factores se combinan para producir esa brecha. La gobernanza de identidades no humanas requiere un enfoque mental distinto al de las humanas: el acceso de un empleado puede limitarse a un rol que rara vez cambia, mientras que las necesidades de un agente de IA pueden variar tarea a tarea, y un agente con permisos excesivos «por si acaso» genera un riesgo que se multiplica cada vez que opera, no solo cuando alguien lo aprovisiona. Además, la mayoría de las organizaciones no mantiene un sistema de registro para agentes como lo hace para empleados, así que la gobernanza ni siquiera puede empezar; no puedes gobernar lo que no ves. Y la responsabilidad sobre los agentes de IA se reparte entre equipos que normalmente no colaboran de cerca —seguridad, gobernanza de datos, desarrollo de aplicaciones y la unidad de negocio que solicitó el agente—, por lo que cada uno suele asumir que otro es el responsable.
La consecuencia de dejar esa brecha del 79% sin atender no es teórica. Un agente sin gobernanza con acceso permanente a un repositorio de archivos, un CRM o un sistema de gestión documental es una exposición, aunque nadie lo use indebidamente. Sus credenciales pueden ser exfiltradas. Sus permisos suelen sobrevivir mucho más allá de la tarea para la que se le concedieron. Y cuando actúa sin una trazabilidad clara, el equipo de cumplimiento no tiene forma de reconstruir lo que pasó después. La arquitectura de confianza cero —verificar explícitamente, conceder el menor privilegio posible, asumir la existencia de brechas— aplica igual a una identidad no humana que a una humana. La mayoría de las organizaciones aún no ha extendido ese modelo a los agentes. La minimización de datos aplicada a los permisos de los agentes —provisionando a cada uno solo con acceso a las fuentes de datos específicas que requiere su tarea— es la implementación operativa del menor privilegio para identidades no humanas, y reduce directamente el alcance de daño si una credencial de agente es exfiltrada o usada indebidamente.
La trampa del uso compartido de credenciales: cómo el acceso compartido multiplica el riesgo
Cuando una organización no ha construido una gobernanza de identidades dedicada para sus agentes de IA, el recurso por defecto casi siempre es el mismo: los agentes heredan credenciales de otro lugar. Imagina un patrón común que ocurre en la mayoría de las empresas ahora mismo: un desarrollador reutiliza una cuenta de servicio que ya tiene acceso amplio a la base de datos porque crear una con alcance limitado lleva demasiado tiempo, un agente recibe una copia del token API de un empleado para extraer datos en su nombre, o una función de agente de un proveedor viene con una credencial de integración por defecto que tiene más alcance del necesario para la tarea específica.
Cada uno de esos atajos resuelve un problema inmediato y crea uno duradero. Las credenciales compartidas significan un alcance de daño compartido: si una sola cuenta de servicio se ve comprometida, todos los agentes que la usan también lo están, y todos los sistemas a los que esa cuenta puede acceder quedan expuestos, no solo el que el agente debía tocar. Además, borran la responsabilidad. Cuando tres agentes diferentes y dos flujos de trabajo automatizados se autentican como la misma cuenta de servicio, un registro de auditoría que muestra que esa cuenta accedió a un archivo sensible no dice nada sobre qué agente lo hizo, qué tarea ejecutaba o si el acceso tenía sentido. Es lo opuesto a lo que reguladores y equipos internos de riesgo esperan de una trazabilidad, y es precisamente el fallo que la gobernanza de identidades no humanas debe evitar. Una filtración de datos confirmada a través de una cuenta de servicio compartida por varios agentes crea un alcance de exfiltración que ninguna organización puede delimitar con certeza —las obligaciones de notificación bajo HIPAA, GDPR o marcos similares aplican al alcance máximo posible salvo que exista evidencia concreta para acotarlo.
La IA en la sombra agrava el problema. Empleados que adoptan herramientas de IA por su cuenta, fuera de cualquier implementación autorizada, suelen pegar datos sensibles en interfaces de IA de consumo o conectar herramientas personales de IA a sistemas corporativos usando sus propias credenciales. Cada una de esas conexiones no autorizadas es, en la práctica, otra identidad no humana que la organización desconoce y no puede gobernar. Los programas de prevención de pérdida de datos basados en monitorear aplicaciones y puntos de salida conocidos tienen visibilidad limitada sobre lo que hace un agente sin gobernanza con los datos una vez que los tiene, por eso la gobernanza a nivel de identidad debe ser parte de la solución, no solo el monitoreo a nivel de contenido. Una plataforma SIEM que reciba en tiempo real la telemetría de acceso de agentes desde puntos de conexión gobernados proporciona la línea base de comportamiento que permite detectar actividad anómala de agentes antes de que escale a un incidente de filtración.
Qué distingue a los líderes: la gobernanza como motor de crecimiento
El hallazgo más útil de la encuesta de VentureBeat no es la caída en la confianza en sí. Es lo que muestran los datos sobre las organizaciones en la cima de la curva de madurez. Esas organizaciones tenían cinco veces más probabilidades que el promedio de reportar que no enfrentan barreras para expandir la implementación de agentes de IA.
Esa correlación replantea toda la conversación sobre gobernanza. La suposición intuitiva es que la gobernanza ralentiza la adopción de IA, que cada control añadido entre un agente y los datos que necesita es una fricción que separa al negocio del valor que promete la IA. Los datos de la encuesta muestran que ocurre lo contrario a escala. Las organizaciones que construyeron una gobernanza real sobre sus identidades no humanas —es decir, que pueden ver cada agente, limitar su acceso a lo que realmente requiere y auditar lo que hizo— son las que mejor pueden añadir más agentes sin toparse con un límite. La gobernanza no las frena. Es lo que les permitió seguir escalando, porque ya resolvieron el problema que el resto aún enfrenta: saber qué tienen y controlar a qué puede acceder cada agente.
Las organizaciones sin esa base se topan con otro tipo de techo. Pueden implementar sus primeros agentes con relativa facilidad, a menudo reutilizando credenciales y accesos existentes, porque el riesgo de hacerlo aún no se ha materializado. Pero cada agente adicional sobre esa base sin gobernanza suma riesgo más rápido que valor, hasta que los equipos de seguridad, legales o de cumplimiento intervienen y frenan todo el programa precisamente porque nadie puede responder preguntas básicas sobre lo que ya está en funcionamiento. Esa es la barrera que las organizaciones líderes en la encuesta de VentureBeat ya superaron, y es un argumento directo para construir la gobernanza de identidades no humanas desde el principio, en vez de intentar adaptarla después de que un incidente obligue a hacerlo. Kiteworks proporciona el entorno de gobernanza unificado —un solo motor de políticas, una sola trazabilidad para todos los flujos de contenido mediados por IA y humanos— que hace posible escalar agentes sin chocar con una pared de cumplimiento, convirtiendo esa aspiración en una realidad operativa.
Cerrando la brecha: lo que realmente requiere la gobernanza de acceso por agente
Llevar la gobernanza de identidades no humanas del 21% de adopción a algo cercano a lo universal requiere un punto de partida distinto al que ofrecen la mayoría de las inversiones actuales en IAM: tratar a cada agente de IA como una identidad gobernada propia, no como una extensión de la cuenta humana o de servicio que le dio acceso.
Eso empieza por la visibilidad. Una organización no puede gobernar agentes que no sabe que existen, así que el primer paso es establecer un inventario real de cada agente con acceso a datos o sistemas sensibles, quién lo solicitó, a qué puede acceder y por qué. A partir de ahí, el acceso debe limitarse por agente y por tarea, en vez de heredarse de forma generalizada. Un agente que resume contratos no necesita permisos de escritura en los sistemas que los almacenan. Un agente que responde preguntas de clientes no requiere el mismo alcance que el equipo completo de soporte en el CRM. Los modelos de control de acceso basado en atributos y control de acceso basado en roles ofrecen un camino para ese alcance, pero solo si se aplican deliberadamente a los agentes y no por defecto. Aplicar etiquetas de clasificación de datos al contenido al que pueden acceder los agentes —para que los motores de políticas apliquen restricciones basadas en sensibilidad en cada solicitud— es el requisito previo que hace que la gobernanza ABAC sea precisa y no solo aproximada.
Cada interacción también debe registrarse a nivel de agente, no a nivel de credencial compartida, para que cuando un equipo de cumplimiento o auditor necesite reconstruir lo sucedido, la respuesta sea la acción específica de un agente concreto y no una incógnita con una cuenta de servicio compartida. Este es el principio de diseño detrás del Secure MCP Server, que ofrece a los agentes de IA un punto de conexión gobernado y auditado al contenido sensible de la organización, en vez de una credencial permanente y sin alcance definido. En lugar de que un agente herede el acceso de un humano o de una cuenta de servicio amplia, se autentica mediante OAuth 2.0 con tokens almacenados en el sistema operativo y no expuestos al modelo de IA, evaluando cada solicitud en tiempo real contra políticas RBAC y ABAC, con limitación de tasa para contener lo que cualquier agente puede extraer.
El mismo principio se aplica a cómo las organizaciones gobiernan los datos que un modelo o agente de IA puede ver y usar desde el inicio. Kiteworks Compliant AI aplica políticas en el punto donde el contenido sensible se encuentra con un sistema de IA, usando clasificación de datos y un motor de políticas de datos para que las decisiones de acceso se tomen por solicitud y no por concesiones amplias y permanentes. Esa combinación —un punto de acceso gobernado para agentes más la aplicación de políticas en la capa de datos— convierte la «gobernanza de identidades no humanas» de una categoría de encuesta en una realidad operativa: cada agente tiene su propia identidad, permisos limitados y trazabilidad, y ninguno toma prestadas credenciales humanas para hacer su trabajo.
Nada de esto exige que las organizaciones ralenticen la adopción de IA para lograrlo. Requiere construir la capa de gobernanza junto a los agentes, no después, que es exactamente lo que distingue a las organizaciones líderes en la encuesta de VentureBeat del promedio que aún espera que un programa de gobernanza alcance a una población de agentes que ya la superó.
Para saber más sobre cómo cerrar la brecha de gobernanza de identidades no humanas con controles de acceso por agente y conexiones de IA auditadas, solicita una demo personalizada hoy mismo.
Preguntas frecuentes
La caída refleja una autoevaluación más honesta, no un retroceso en la adopción de IA. A medida que las identidades no humanas y los agentes de IA proliferaron en las organizaciones, los líderes de TI obtuvieron una visión más clara de cuánto trabajo de gobernanza de datos de IA quedaba pendiente, y los puntajes de madurez bajaron para reflejar esa realidad en vez de la estimación anterior, más optimista. La adopción de herramientas de IA siguió creciendo en el mismo periodo; lo que cambió fue la rigurosidad con la que los líderes evaluaron su propia gobernanza. Las organizaciones sujetas a obligaciones de cumplimiento normativo —HIPAA, GDPR, CMMC— deben usar esta encuesta como un llamado externo para realizar una evaluación formal de riesgos sobre su postura de identidades no humanas, ya que los reguladores eventualmente evaluarán la gobernanza de acceso a datos de IA bajo los mismos marcos que rigen el acceso de usuarios humanos.
La gobernanza de identidades no humanas se refiere a las políticas, herramientas y procesos usados para inventariar, limitar, monitorear y retirar las identidades asignadas a agentes de IA, cuentas de servicio e integraciones API, diferenciándolas de las asignadas a empleados humanos. Incluye preguntas como quién es responsable de un agente, a qué datos y sistemas puede acceder, si ese acceso corresponde a su tarea real y si su actividad se registra de forma que permita una auditoría. Kiteworks aborda esto mediante controles de acceso y puntos de conexión gobernados que limitan el acceso de los agentes por tarea en vez de otorgar permisos amplios y permanentes. Los programas de gestión de riesgos de la cadena de suministro deben extender esta gobernanza a los agentes de IA implementados por proveedores externos —un agente implementado por un proveedor y operando en tu entorno con credenciales amplias es un riesgo de cadena de suministro que la mayoría de los marcos actuales de gobernanza de proveedores no abordan explícitamente.
Cada agente de IA, flujo de trabajo automatizado e integración entre sistemas normalmente requiere su propia identidad para autenticarse y operar, y las organizaciones los han implementado a un ritmo mucho mayor que el de contratación de empleados. Una sola unidad de negocio que adopte IA de agentes para atención al cliente, procesamiento de documentos o asistencia en programación puede sumar decenas de identidades no humanas en el tiempo que lleva incorporar a un nuevo empleado, por eso VentureBeat encontró esta mayoría ya presente en el 83% de las organizaciones encuestadas. La mayoría de los programas de gestión de identidades y acceso no se diseñaron para ese ritmo de crecimiento. Los marcos de gobernanza de datos que incluyen explícitamente identidades no humanas —con responsables definidos, revisiones de alcance de acceso y procedimientos de retiro— son el mecanismo organizacional para extender las disciplinas de IAM a una población de identidades que crece más rápido de lo que los procesos de aprovisionamiento gestionados por RRHH pueden seguir.
Los datos de la encuesta sugieren lo contrario. Las organizaciones en el nivel más alto de madurez, con la gobernanza más desarrollada, tenían cinco veces más probabilidades de reportar que no enfrentan barreras para expandir la implementación de agentes de IA, porque ya cuentan con la visibilidad y los controles de acceso necesarios para añadir agentes sin introducir riesgos no gestionados. Las organizaciones sin esa base suelen toparse con un límite más adelante, cuando los equipos de seguridad o cumplimiento deben intervenir precisamente porque nadie puede dar cuenta de lo que ya está en funcionamiento, lo que resulta en una desaceleración mucho más disruptiva que construir la gobernanza desde el inicio. Construir esa base temprano, en vez de intentar adaptarla después de que los agentes ya operan sin control, es la diferencia entre gestionar el riesgo de IA de forma proactiva o reaccionar bajo presión. Un plan de respuesta a incidentes que cubra explícitamente escenarios de mal funcionamiento de agentes y exfiltración de credenciales —con procedimientos de reversión definidos y umbrales de notificación regulatoria— es el complemento operativo de la arquitectura de gobernanza: define qué hacer después de la detección, no solo cómo detectar.
Empieza con un inventario: identifica cada agente de IA, cuenta de servicio e integración que actualmente tiene acceso a sistemas o datos sensibles, y confirma quién es responsable de cada uno y por qué tiene el acceso que tiene. A partir de ahí, limita los permisos de cada agente a su tarea específica en vez de heredar credenciales compartidas, y canaliza el acceso de los agentes a contenido sensible a través de un punto de conexión gobernado como el Secure MCP Server para que cada acción quede registrada bajo una identidad específica y responsable, y no una compartida. La clasificación de datos a los que pueden acceder los agentes es el requisito previo que hace posible la limitación de acceso basada en ABAC; sin ella, un motor de políticas no puede aplicar restricciones basadas en sensibilidad a las solicitudes de los agentes. Enviar los registros de acceso de agentes en tiempo real a una plataforma SIEM da a los equipos de seguridad la línea base de comportamiento necesaria para detectar actividad anómala de agentes antes de que escale a una filtración reportable.
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 está fallando 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.