Kiteworks advierte que el 80% de las organizaciones enfrentó incidentes de seguridad o IA mientras la gobernanza se quedaba atrás

Kiteworks llegó a Google News con una afirmación contundente: el 80% de las organizaciones sufrió un incidente de seguridad o de IA mientras la preparación en materia de gobernanza seguía siendo críticamente baja. La cifra llama la atención, pero el conflicto más profundo está entre las políticas escritas y los controles que funcionan durante el uso real de la IA.

El titular, publicado a través de Cybersecurity Insiders, aparece mientras las empresas dan a los sistemas de IA acceso a documentos privados, aplicaciones empresariales y flujos de trabajo internos. Estas conexiones amplían las consecuencias de permisos débiles, registros incompletos y movimientos de datos desconocidos.

Kiteworks tiene un interés comercial en este debate porque vende tecnología de seguridad y gobernanza de datos privados. Por ello, sus conclusiones merecen escrutinio, no aceptación automática. Sin embargo, varias cifras de apoyo revelan un problema de gobernanza que va más allá del enfoque de un solo proveedor.

Lo que realmente cambia el informe de Kiteworks

El informe transforma la gobernanza de la IA de un debate sobre políticas en un problema de respuesta a incidentes.

La nota de Google News presenta la cifra del 80% como el hallazgo central. Sin embargo, el titular por sí solo no explica si ese porcentaje combina brechas confirmadas, eventos sospechosos, infracciones de políticas o fallos específicos de la IA.

Esa distinción importa. Una brecha de datos convencional, un empleado que carga texto confidencial en un chatbot no autorizado y un agente autónomo que ejecuta una acción no prevista son eventos distintos. Requieren controles diferentes y producen niveles de daño diferentes.

Por tanto, los lectores deberían considerar el porcentaje del titular como el resultado de una encuesta comunicada por un proveedor. No es una medida de brechas verificadas de forma independiente en toda la economía. El material de Kiteworks disponible públicamente respalda la preocupación más amplia sobre la gobernanza, pero no convierte todas las categorías de incidentes en equivalentes.

La investigación global anterior de Kiteworks encuestó a 461 organizaciones de Norteamérica, Europa, Asia-Pacífico y Oriente Medio. La cobertura de esa investigación concluyó que solo el 17% había implementado por completo marcos técnicos de gobernanza de IA.

Ese es el punto de referencia más útil. La gobernanza técnica de IA implica controles aplicables que cubren el acceso a datos, el uso de modelos, la supervisión, la retención y la gestión de incidentes. Un documento de políticas sin esos controles no puede impedir que un empleado, una aplicación o un agente exponga información protegida.

La misma investigación relacionó la visibilidad limitada con resultados más débiles. Según un informe independiente, el 46% de las organizaciones que no conocían su número de terceros tampoco podía identificar la frecuencia de sus brechas.

Entre las organizaciones que no tenían certeza sobre las brechas, el 42% tampoco estaba seguro de los tiempos de detección. Otro 48% no pudo cuantificar los costes de litigios, según la cobertura.

Estas relaciones no demuestran que la mala visibilidad causara cada brecha. Sí muestran que las organizaciones incapaces de inventariar sistemas y socios también tienen dificultades para medir las consecuencias.

El análisis de Kiteworks sobre el sector tecnológico de 2026 ofrece otra perspectiva. Encuestó a 225 líderes de seguridad, TI, cumplimiento y riesgos de 10 industrias y ocho regiones. Treinta y dos encuestados representaban a organizaciones tecnológicas, mientras que el 97% de todos los participantes trabajaba en organizaciones con al menos 1.000 empleados.

La muestra es relevante para el riesgo de las grandes empresas, pero no representa a todos los negocios. El subconjunto tecnológico es particularmente pequeño. Las diferencias porcentuales dentro de esas 32 respuestas deben interpretarse como hallazgos orientativos, no como estimaciones precisas del sector.

Incluso con esas limitaciones, el informe identifica un problema coherente. Las organizaciones han invertido en prácticas de gobernanza visibles, pero los controles fundamentales siguen incompletos.

Esto es lo que ha cambiado. Los incidentes de seguridad de IA ya no son casos hipotéticos y marginales vinculados a futuros sistemas autónomos. Las empresas están notificando incidentes mientras las capacidades esenciales de inventario, procedencia y aplicación de controles siguen sin completarse.

Por qué Google News está destacando ahora la brecha de gobernanza

La adopción de IA ha pasado de sesiones aisladas de chat a sistemas capaces de recuperar datos, invocar herramientas y actuar en procesos empresariales.

Un chatbot que responde una pregunta general tiene acceso limitado. Un agente de IA conectado al correo electrónico, almacenamiento en la nube, registros de clientes, código fuente o sistemas financieros opera sobre una superficie de ataque mucho mayor.

La IA agéntica se refiere a software que puede planificar y ejecutar múltiples acciones para alcanzar un objetivo. Su riesgo depende menos de la fluidez conversacional y más de la identidad, los permisos, las herramientas disponibles y los datos a los que puede acceder.

Esto crea varias vías hacia un incidente. Un agente puede recibir privilegios excesivos, seguir instrucciones maliciosas incrustadas en un documento, divulgar información recuperada o desencadenar una acción fuera de su propósito previsto.

Los empleados también generan exposición mediante la IA en la sombra, es decir, herramientas de IA utilizadas sin aprobación formal ni supervisión. El riesgo crece cuando esas herramientas conservan prompts, entrenan con contenido enviado o se conectan a cuentas de la organización.

Los programas de seguridad tradicionales ya gestionan identidades, endpoints, aplicaciones y tráfico de red. La IA añade una capa de razonamiento que puede combinar información e iniciar acciones a velocidad de máquina.

Esto no vuelve impredecible a cada sistema de IA. Sí significa que una aprobación estática durante el despliegue no puede sustituir la observación continua tras el despliegue.

El momento también refleja la presión regulatoria. La Ley de IA de la Unión Europea entró en vigor en 2024 y sus obligaciones siguen un calendario escalonado. Los requisitos de gobernanza para modelos de IA de propósito general comenzaron a aplicarse en agosto de 2025.

El calendario de implementación de la Comisión Europea muestra que las distintas disposiciones y plazos transitorios se aplican en momentos diferentes. Las organizaciones deben identificar qué sistemas, roles de proveedor y casos de uso se incluyen en cada obligación.

Este calendario en evolución complica la planificación del cumplimiento, pero no elimina la necesidad de un inventario. Una empresa no puede clasificar un sistema de IA, documentar sus riesgos ni aplicar los controles adecuados si nadie sabe que existe.

La regulación es solo una fuente de presión. Los clientes preguntan cada vez más a los proveedores cómo procesa la IA la información confidencial. Las aseguradoras, los auditores, los consejos de administración y los equipos de compras también quieren pruebas de que los controles funcionan como se describe.

El requisito de evidencia cambia el significado de la preparación. Una empresa no está preparada porque los ejecutivos hayan aprobado una política de IA. Lo está cuando los equipos pueden demostrar quién accedió a los datos, qué modelo los recibió, qué hizo el sistema y cómo respondió la organización.

Por eso los hallazgos de Kiteworks sobre gobernanza de IA resuenan más allá de la base de clientes del proveedor. Describen una brecha operativa ya visible en las revisiones de seguridad y las compras empresariales.

Google News está amplificando la estadística de incidentes en un momento en el que los ejecutivos reconocen el problema, pero carecen de pruebas coherentes. El titular capta la atención porque la adopción ha superado a los sistemas necesarios para observarla.

Las promesas de gobernanza superan al control técnico

El conflicto principal no es la adopción de IA frente a la cautela; es la gobernanza prometida sobre el papel frente a la gobernanza aplicada en producción.

El informe del sector tecnológico de Kiteworks ilustra esa división. Las organizaciones tecnológicas lideraron la muestra global en varias capacidades formales de gobernanza.

El sector reportó técnicas de preservación de la privacidad en un 56%, frente a un resultado global del 33%. Las taxonomías de incidentes de IA y los manuales de respuesta alcanzaron el 50%, frente al 27% global.

Los encuestados del sector tecnológico también reportaron evaluaciones de impacto de IA en un 53%, auditorías de sesgo en un 47% y documentación sobre explicabilidad de modelos en un 41%. Cada resultado superó la cifra global correspondiente.

Son inversiones significativas. Las evaluaciones de impacto pueden identificar a los grupos afectados y los daños previsibles. Los manuales de incidentes asignan a los equipos responsabilidades predefinidas cuando un modelo se comporta de forma inesperada.

Sin embargo, el mismo informe del sector tecnológico detectó resultados más débiles en infraestructura menos visible.

Solo el 22% de los encuestados tecnológicos reportó entornos de entrenamiento aislados, frente al 26% global. El aislamiento separa los recursos de desarrollo, entrenamiento y producción para que los datos no puedan desplazarse entre ellos sin control.

Solo el 19% reportó capacidades de procedencia y linaje, frente a una cifra global del 23%. La procedencia de los datos registra de dónde se originó la información, cómo cambió y qué modelos o procesos la utilizaron.

Esto crea una contradicción práctica. Una empresa puede detectar un comportamiento inusual y disponer de un documento de respuesta, pero aun así no poder rastrear el resultado afectado hasta sus datos de origen.

También puede mantener controles de acceso en producción mientras deja los entornos de desarrollo de modelos conectados de manera demasiado amplia. Esa brecha eleva el riesgo de acceso no autorizado, material de entrenamiento contaminado o movimientos de datos no previstos.

Los encuestados tecnológicos obtuvieron mejores resultados en registros de auditoría inmutables, supervisión de deriva y manuales de incidentes. Estos controles ayudan a los equipos a ver que algo ha cambiado.

Un linaje débil dificulta explicar por qué cambió. Puede retrasar el análisis de la causa raíz y hacer más difícil prevenir la recurrencia.

El informe también concluyó que el 53% de los encuestados tecnológicos afirmó que los consejos de administración priorizaban la gobernanza de IA. Sin embargo, solo el 47% reportó atención del consejo a la postura general de riesgo cibernético, siete puntos porcentuales por debajo de la cifra global.

Ese resultado no demuestra que los consejos de administración hayan abandonado la ciberseguridad. Sugiere que la atención del liderazgo puede desplazarse hacia iniciativas de IA visibles mientras la seguridad fundamental compite por el mismo tiempo y presupuesto.

La gobernanza de IA no puede situarse junto a la ciberseguridad como un proyecto aislado de cumplimiento. Depende de la gestión de identidades, el cifrado, la clasificación de datos, la seguridad del software, la supervisión de terceros y la respuesta a incidentes.

El Instituto Nacional de Estándares y Tecnología de Estados Unidos refleja este enfoque de ciclo de vida. Su marco voluntario de riesgos de IA organiza el trabajo en torno a cuatro funciones: Gobernar, Mapear, Medir y Gestionar.

La gobernanza establece responsabilidades y políticas. El mapeo identifica el contexto y las partes afectadas. La medición evalúa el riesgo, mientras que la gestión lo prioriza y aborda.

Una empresa que se detiene en la gobernanza ha completado solo una parte de ese ciclo. Las políticas deben conectarse con observaciones técnicas, resultados de pruebas y decisiones de respuesta.

Esta es la inversión central tras el titular. Las organizaciones pueden parecer preparadas porque cuentan con comités, estándares y herramientas aprobadas. Los incidentes de seguridad de IA revelan si esos preparativos llegan a los sistemas que manejan datos reales.

Los incidentes de seguridad de IA exponen el problema del inventario

Las organizaciones no pueden controlar los flujos de datos de IA que no pueden identificar, clasificar y reconstruir.

El inventario parece básico, pero la IA lo dificulta. Un solo proceso empresarial puede involucrar a un empleado, una aplicación de software, un proveedor externo de modelos, infraestructura de recuperación y varios repositorios de datos.

La empresa quizá solo posea una parte de esa cadena. Una plataforma de atención al cliente puede añadir funciones generativas mediante un modelo de terceros. Un desarrollador puede conectar un asistente de programación a repositorios privados.

Otro equipo puede crear un agente interno que recupere documentos del almacenamiento compartido. Cada implementación puede generar distintas condiciones de retención, permisos y registro.

Por tanto, un inventario útil debe registrar más que nombres de productos. Debe identificar propietarios de los sistemas, fines previstos, proveedores de modelos, datos conectados, herramientas disponibles, grupos de usuarios y ubicaciones geográficas de procesamiento.

También debe recoger si el sistema puede realizar acciones. Un asistente que redacta un correo electrónico implica un nivel de riesgo. Un agente autorizado para enviar ese correo o modificar una cuenta implica otro.

Los hallazgos de Kiteworks sobre la visibilidad de terceros encajan con este problema. Los proveedores e integraciones desconocidos pueden ocultar rutas por las que circulan datos privados.

La organización puede haber aprobado la aplicación visible, pero no comprender todos los procesadores que hay debajo. Esto cobra importancia cuando cambia un proveedor de modelos, un complemento o un servicio de datos.

El mismo problema aparece en la soberanía de los datos. La investigación de Kiteworks de 2026 descubrió que aproximadamente cuatro de cada cinco encuestados se consideraban bien informados sobre los requisitos de soberanía. Sin embargo, cerca de un tercio informó de un incidente relacionado con la soberanía durante el año anterior.

La soberanía de los datos se refiere al control legal y operativo sobre dónde reside la información y qué jurisdicción la rige. La IA complica esto cuando las instrucciones, las incrustaciones, los registros y las salidas de los modelos cruzan fronteras regionales.

El informe sobre soberanía plantea la brecha como una diferencia entre la concienciación y el control demostrable. Las organizaciones pueden comprender las normas, pero carecer de aplicación automatizada o de pruebas listas para auditoría.

Este contraste es más defendible que tratar cada evento reportado como el mismo tipo de incidente de IA. También apunta a una prueba concreta.

Tras un evento relacionado con IA, ¿puede la organización identificar los datos afectados, el modelo involucrado, la identidad que lo inició, las acciones ejecutadas y los destinatarios posteriores? Si no es así, la gobernanza sigue siendo incompleta, independientemente de la calidad de las políticas.

Los trabajadores del conocimiento desempeñan un papel en este sistema. Deciden qué archivos se incluyen en las instrucciones, en qué respuestas generadas se confía y qué herramientas de IA pasan a formar parte del trabajo diario.

Las organizaciones pueden reducir la exposición accidental ofreciendo a los empleados formas aprobadas de buscar y sintetizar su propia información. Una base de conocimientos de IA privada puede limitar la copia innecesaria entre servicios no relacionados cuando sus límites están claramente definidos.

Este enfoque sigue requiriendo gobernanza. El almacenamiento local o privado no resuelve automáticamente el acceso excesivo, las salidas inexactas, la autenticación débil ni las obligaciones de retención.

El objetivo no es prohibir flujos de trabajo útiles. Es ofrecer a los usuarios una vía aprobada cuyo movimiento de datos pueda comprenderse y revisarse.

El inventario también necesita gestión de cambios. Una aplicación que comenzó como asistente de redacción puede adquirir funciones de recuperación, automatización o agente mediante una actualización.

Los equipos de seguridad deben revisar las nuevas capacidades conforme al acceso y las acciones modificados, y no únicamente al conocido nombre del producto. Una herramienta que antes presentaba bajo riesgo puede cambiar sustancialmente tras recibir nuevos permisos.

Aquí es donde los incidentes de seguridad de IA se convierten en señales valiosas. Cada evento debe actualizar el inventario, el modelo de amenazas, el diseño de controles y la orientación para empleados.

Un recuento de incidentes por sí solo no puede mostrar si las organizaciones aprendieron de esos eventos. La calidad del proceso correctivo importa más que la cifra principal.

Lo que no demuestra la cifra del 80 %

El titular señala una exposición generalizada, pero no establece una tasa de brechas universal ni demuestra que la IA haya causado cada incidente reportado.

Las encuestas de proveedores pueden revelar patrones útiles, especialmente cuando publican tamaños de muestra y metodología. También conllevan limitaciones inevitables.

Los encuestados pueden interpretar “incidente” de manera distinta. Los líderes de seguridad pueden incluir bajo la misma etiqueta ataques intentados, brechas confirmadas, infracciones de políticas, eventos de privacidad y fallos operativos.

Los resultados autodeclarados también dependen de la visibilidad. Una organización madura con una supervisión amplia puede informar de más incidentes porque detecta más eventos.

Una organización menos preparada puede parecer más segura simplemente porque no puede ver los fallos. La propia investigación de Kiteworks advierte sobre este efecto de visibilidad.

También importan las poblaciones de las encuestas. El informe tecnológico de Kiteworks representa abrumadoramente a grandes organizaciones: el 97 % de los encuestados trabaja en empresas con al menos 1.000 empleados.

Las grandes compañías tienen más sistemas, usuarios, proveedores y obligaciones regulatorias. Su experiencia no debe extrapolarse directamente a las pequeñas empresas.

El análisis tecnológico incluyó solo a 32 encuestados del sector. Una diferencia de varias respuestas puede modificar sustancialmente un porcentaje dentro de ese subgrupo.

Por tanto, la afirmación del 80 % necesita detalles de respaldo antes de que los lectores puedan compararla con otro estudio de incidentes. Los detalles necesarios incluyen la redacción de la pregunta, las opciones de respuesta, el período de observación y el tratamiento de eventos sospechosos.

También ayudaría separar los incidentes cibernéticos tradicionales de los eventos originados por IA. Un atacante que utiliza IA para mejorar el phishing es diferente de un modelo empresarial que filtra datos recuperados.

Una tercera categoría incluye ataques convencionales contra infraestructura de IA, como el robo de credenciales o software vulnerable. Llamar a los tres “incidentes de IA” oscurece quién controlaba el sistema que falló.

Kiteworks también vende productos diseñados para abordar la gobernanza de datos privados. Esa posición comercial no invalida sus datos, pero crea un incentivo para enfatizar los riesgos que su plataforma aborda.

Una reproducción independiente reforzaría la afirmación principal. También lo haría la publicación de desgloses anonimizados por tipo de incidente, tamaño de la organización, región y madurez de gobernanza.

La lección más creíble del informe no exige aceptar una tasa universal del 80 %. Varios estudios de Kiteworks muestran que la preparación formal y la aplicación operativa divergen con frecuencia.

El informe tecnológico identifica brechas en el aislamiento del entrenamiento y la procedencia. La encuesta anterior encontró una implementación limitada de gobernanza técnica. La investigación sobre soberanía muestra una elevada concienciación junto con incidentes continuos.

En conjunto, esos hallazgos respaldan una conclusión más acotada. Muchas grandes organizaciones han comenzado a aplicar gobernanza de IA, pero relativamente pocas pueden demostrar un control técnico integral durante todo el ciclo de vida de los datos.

Esto es grave sin ser sensacionalista. También ofrece a los compradores un mejor marco para evaluar productos de gobernanza.

Un proveedor debe explicar qué flujos de datos observa, qué políticas aplica y qué acciones puede bloquear. También debe revelar limitaciones y dependencias de integración.

Los compradores deben ser cautelosos cuando un producto trata la gobernanza como si fuera solo un panel. La visibilidad es necesaria, pero la aplicación, las pruebas, la respuesta y la recuperación completan el ciclo operativo.

También deben evitar asumir que una única puerta de enlace controla todas las rutas. Los empleados, las funciones de IA integradas, las interfaces directas de programación de aplicaciones y los agentes autónomos pueden crear rutas independientes.

El titular de Google News merece atención porque el riesgo subyacente es real. Su porcentaje exacto debe seguir atribuyéndose al informe hasta que la metodología completa aclare qué incluye la cifra.

Tres señales que pondrán a prueba la advertencia de Kiteworks

Las próximas pruebas deberán mostrar si las empresas están creando una gobernanza aplicable o simplemente añadiendo otra capa de documentación.

La primera señal es una mejor divulgación de incidentes. Las futuras investigaciones deberían separar las brechas confirmadas, los eventos sospechosos, las infracciones de políticas y las acciones no intencionadas de IA.

También deberían distinguir los incidentes causados por IA de los ataques dirigidos a sistemas de IA. Esa taxonomía haría más significativas las comparaciones interanuales.

Una divulgación detallada podría reforzar la advertencia de Kiteworks si se mantienen tasas elevadas en categorías claramente definidas. Podría debilitar el titular si la cifra del 80 % combina muchos eventos de baja gravedad o escasamente relacionados.

La segunda señal es el progreso medible en los controles técnicos. El informe tecnológico de 2026 proporciona referencias para entornos de entrenamiento aislados, procedencia, manuales de respuesta a incidentes y supervisión del consejo de administración.

Una encuesta de seguimiento debería utilizar las mismas preguntas y el mismo enfoque de muestreo. Una mayor adopción de la trazabilidad y el aislamiento de entornos demostraría que las organizaciones están cerrando la brecha de aplicación.

Resultados estables o descendentes respaldarían la preocupación central del informe. Indicarían que el gasto sigue concentrado en evaluaciones y políticas, en lugar de controles fundamentales.

La tercera señal es la evidencia regulatoria. La aplicación europea, las auditorías y las directrices de implementación deberían revelar qué fallos de gobernanza generan la mayor exposición práctica.

Esté atento a casos relacionados con documentación ausente, supervisión inadecuada, interacción con IA no divulgada o movimiento de datos mal controlado. Estos ejemplos ayudarán a las organizaciones a priorizar inversiones.

La acción regulatoria podría reforzar la tesis del informe si las autoridades detectan repetidamente brechas entre las políticas declaradas y el comportamiento de los sistemas. Un cumplimiento claro con pocos fallos operativos debilitaría su urgencia.

Los compradores empresariales no necesitan esperar esas señales antes de actuar. Pueden poner a prueba su preparación con un ejercicio sencillo basado en un flujo de trabajo de IA en producción.

Comience con un sistema que acceda a información sensible. Pida al responsable que identifique cada fuente de datos, proveedor de modelos, herramienta conectada, permiso, regla de retención y responsable de la toma de decisiones.

Después, simule una cuenta comprometida, un documento malicioso o una acción no intencionada. Determine si la organización puede detener el sistema, rastrear su actividad, identificar la información expuesta y preservar pruebas.

El ejercicio debe incluir a los equipos jurídico, de seguridad, de privacidad, de TI y al equipo de negocio que utiliza el sistema. La gobernanza de IA falla cuando la responsabilidad desaparece entre esos grupos.

Los equipos deben preservar las decisiones y las lecciones de incidentes en un sistema consultable, en lugar de dispersarlas entre reuniones y documentos. Un flujo de trabajo de conocimiento estructurado puede ayudar a los responsables a mantener pruebas a medida que cambian los sistemas.

La documentación sigue sin poder sustituir la aplicación. Su valor reside en conectar a responsables identificados, comportamientos observados, excepciones aprobadas y acciones correctivas.

La cifra de incidentes del 80 % reportada por Kiteworks se interpreta mejor como una advertencia que merece verificación. La investigación más amplia de la empresa ya muestra suficientes indicios de visibilidad débil, gobernanza técnica limitada y procedencia incompleta.

La verdadera pregunta ya no es si una organización tiene una política de IA. Es si esa organización puede reconstruir las acciones de un sistema de IA cuando algo sale mal.

Google News puede amplificar un porcentaje llamativo, pero los líderes de seguridad necesitan los controles que hay debajo. Deben inventariar un flujo de trabajo de IA activo, probar su ruta de fallo y documentar lo que sigue siendo invisible.