La deuda de datos se está convirtiendo en un riesgo de seguridad de IA empresarial
Google News puso de relieve una advertencia de IT Brew que cuestiona una suposición común sobre la IA empresarial: los modelos más nuevos no pueden compensar años de controles de datos descuidados.
El problema inmediato es la deuda de datos, el coste acumulado de información incompleta, incoherente, inaccesible o mal gobernada. Esa deuda es anterior a la IA generativa. Sin embargo, los sistemas de IA pueden dejarla al descubierto más rápido y ampliar el alcance de sus consecuencias.
El conflicto ya no se limita a si los datos deficientes generan respuestas débiles. Los agentes de IA pueden recuperar registros, invocar software y hacer recomendaciones en distintos sistemas empresariales. Cuando sus datos subyacentes carecen de una propiedad clara o de reglas de acceso, un problema de precisión se convierte en un problema de seguridad.
Esto coloca a los líderes empresariales en una posición incómoda. Se enfrentan a presión para ampliar la IA mientras los equipos de seguridad aún carecen de inventarios fiables, clasificaciones, políticas de retención y mapas de permisos. La velocidad de despliegue y una gobernanza de datos responsable avanzan ahora a ritmos distintos.
Un estudio de junio de 2026 de Genpact y HFS Research da un marco financiero a esa tensión. Sus autores encuestaron a 2.002 directivos de 16 sectores e identificaron la deuda de datos, tecnología, procesos y talento como barreras para obtener valor de la IA.
El informe estima que estas obligaciones acumuladas mantienen atrapados unos 18 billones de dólares en valor potencial entre las empresas del Global 2000. Esa estimación merece cautela, pero el problema subyacente es concreto. La IA no puede utilizar de forma segura información que una organización no comprende.
La advertencia de Google News trata sobre infraestructura, no solo sobre modelos
El cambio importante es que la deuda de datos ahora determina a qué pueden acceder los sistemas de IA, qué pueden exponer y sobre qué pueden actuar.
La cobertura de IT Brew se apoya en una reevaluación más amplia de la preparación empresarial para la IA. Durante años, las empresas trataron los registros dispersos, las bases de datos duplicadas, los campos sin documentar y los permisos amplios como una fricción operativa manejable. La IA convierte esas concesiones en entradas.
Una aplicación convencional suele acceder a la información mediante consultas predefinidas y flujos de trabajo predecibles. Un asistente de IA generativa puede recuperar material relacionado semánticamente de varios repositorios. Un agente puede ir más allá al elegir herramientas y ejecutar acciones.
Ese alcance ampliado cambia el cálculo de seguridad. Un documento olvidado en una antigua unidad compartida podría no llamar la atención durante el trabajo habitual. Un sistema de recuperación puede mostrarlo porque su contenido se parece a la pregunta de un usuario, incluso cuando su ubicación de almacenamiento parece poco visible.
Un permiso obsoleto crea un problema similar. Un empleado que conserva acceso tras cambiar de puesto puede visitar rara vez el sistema anterior. Un asistente de IA conectado a ese sistema puede llevar su contenido a conversaciones rutinarias. En la práctica, un vendedor que se trasladó a otra región podría pedir el historial de una cuenta y recibir concesiones de precios o notas de clientes de un territorio que ya no gestiona.
El fallo de acceso original sigue siendo de origen humano. La IA aumenta la frecuencia y la escala con que ese fallo puede importar.
Por eso, la distinción entre calidad de datos y seguridad de datos se está volviendo menos útil. Una clasificación incorrecta de un cliente puede distorsionar una recomendación de IA. Una etiqueta de sensibilidad ausente puede exponer la información privada de ese mismo cliente.
Ambos fallos se originan en la gestión de datos. Sus consecuencias recaen en distintas partes de la empresa.
El estudio sobre deuda empresarial define la deuda de datos como la carga creada por información fragmentada, inaccesible, de baja calidad o insuficientemente gobernada. Sitúa esa carga junto a la deuda de procesos, tecnología y talento.
Estas categorías interactúan. Las aplicaciones heredadas crean datos fragmentados. Los datos fragmentados obligan a los empleados a construir soluciones manuales. Las soluciones manuales dependen de conocimiento no documentado que poseen unas pocas personas.
Añadir IA a ese entorno no elimina las dependencias. Puede ocultarlas tras una interfaz conversacional.
El estudio determinó que la baja calidad de las decisiones y los conocimientos poco fiables fueron el principal efecto empresarial de la deuda de datos seleccionado con mayor frecuencia, con un 18%. Le siguieron los costes más elevados y el esfuerzo desperdiciado, con un 15%.
La seguridad no queda fuera de esa cadena. Una empresa no puede proteger los datos de forma constante si no puede identificar las copias autorizadas, los propietarios responsables o los usuarios legítimos. Tampoco puede explicar una decisión de IA cuando los registros que la respaldan carecen de procedencia.
La procedencia describe de dónde vino la información y cómo cambió. Se vuelve esencial cuando un modelo combina resultados de búsqueda, documentos internos, instrucciones de usuarios y herramientas externas. En una guía conjunta, la NSA, CISA, FBI y socios internacionales recomiendan específicamente rastrear la procedencia de los datos y autenticar las revisiones de confianza durante todo el ciclo de vida de la IA.
Sin procedencia, los investigadores podrían observar una salida insegura pero tener dificultades para reconstruir su causa. ¿La fuente era inexacta, estaba manipulada, desactualizada, tenía permisos inadecuados o simplemente fue malinterpretada por el modelo?
Google News resulta útil aquí como señal de una atención creciente, no como la evidencia en sí misma. La evidencia subyacente procede de encuestas empresariales, telemetría de seguridad, estándares y experiencias organizativas documentadas.
La propia investigación sobre automatización de IT Brew concluyó que solo el 12% de los profesionales de TI encuestados se sentía muy seguro de que los empleados comprendieran las políticas relevantes de seguridad de datos. Esa cifra refleja concienciación, no aplicación técnica, pero pone de relieve la débil capa humana que rodea a una adopción rápida.
La misma investigación concluyó que el 29% de los encuestados experimentó un ligero aumento de la complejidad tras los despliegues de IA. La complejidad importa porque los equipos de seguridad deben comprender un sistema antes de poder supervisarlo de manera fiable.
Una pila de IA compleja puede abarcar almacenes de datos, bases de datos vectoriales, proveedores de modelos, sistemas de identidad, plugins y dispositivos de empleados. Cada conexión crea otro punto donde los permisos, el registro o las normas de retención pueden divergir.
Por tanto, el titular no es que los datos empresariales necesiten otra campaña de limpieza. La IA ha cambiado las consecuencias de posponer ese trabajo.
La deuda de datos amplía la superficie de ataque de la IA
Los datos mal gobernados brindan a los sistemas de IA más oportunidades de revelar información sensible o seguir un contexto comprometido.
Una superficie de ataque incluye cada vía por la que se puede manipular o alcanzar un sistema. La IA amplía esa superficie porque el lenguaje natural se convierte en una interfaz para los datos y el software.
El riesgo comienza antes de que un atacante entre en escena. Los empleados pueden pegar material propietario en servicios no aprobados. Los equipos pueden conectar asistentes a repositorios sin revisar los permisos heredados. Los desarrolladores pueden recopilar registros operativos que contienen secretos o datos personales.
Estas acciones crean IA en la sombra, es decir, usos de IA que operan fuera de los controles aprobados de seguridad y gobernanza. Las herramientas pueden ser legítimas, pero la organización no puede observar de forma fiable cómo se mueve la información a través de ellas.
La investigación sobre riesgos de IA de Cyberhaven analizó miles de millones de movimientos de datos relacionados con servicios de IA generativa, aplicaciones de endpoints y agentes. La empresa afirma que el comportamiento de la IA empresarial está creando riesgos que los controles más antiguos a menudo no pueden detectar.
La investigación de proveedores debe leerse teniendo presentes sus incentivos comerciales. Aun así, la brecha de visibilidad descrita coincide con un principio básico de seguridad: los controles no pueden proteger información que no pueden localizar ni clasificar.
La deuda de datos debilita esa visibilidad de varias maneras.
En primer lugar, los registros duplicados dificultan identificar la versión autorizada. Los equipos de seguridad podrían proteger una base de datos actual mientras una exportación más antigua sigue disponible mediante una carpeta compartida.
En segundo lugar, una clasificación incompleta deja a los modelos sin reglas fiables para tratar contenido sensible. Un documento puede contener información confidencial aunque su etiqueta de archivo no indique nada.
En tercer lugar, las identidades incoherentes oscurecen quién debería tener acceso. Las adquisiciones, las cuentas de contratistas, las credenciales compartidas y los cambios de puesto pueden dejar permisos que sobreviven a su propósito empresarial.
En cuarto lugar, unas prácticas de retención deficientes mantienen disponible información después de que haya caducado su valor. La recuperación mediante IA hace que esa información inactiva sea más fácil de redescubrir.
En quinto lugar, la falta de linaje impide que los equipos rastreen una salida hasta su origen. Esto complica la respuesta a incidentes y dificulta contener errores perjudiciales.
Estas debilidades se vuelven más graves cuando los agentes de IA reciben acceso permanente. El acceso permanente sigue disponible de forma continua, en lugar de concederse brevemente para una tarea específica.
Un asistente que solo redacta texto a partir de documentos aprobados tiene un alcance operativo limitado. Un agente que puede leer facturas, actualizar registros de clientes y enviar mensajes combina varios límites de confianza.
Si un repositorio conectado contiene instrucciones engañosas, el agente puede encontrarse con una inyección indirecta de prompts. En ese ataque, texto malicioso dentro de contenido externo o recuperado intenta redirigir el comportamiento del modelo.
El modelo podría tratar el texto hostil como una instrucción en lugar de datos ordinarios. Las defensas eficaces requieren más que filtrar frases sospechosas. Los sistemas deben separar las instrucciones de confianza del contenido no confiable y restringir lo que pueden hacer las herramientas.
La deuda de datos complica esa separación. Cuando las organizaciones carecen de inventarios fiables de fuentes, no pueden decidir fácilmente qué repositorios merecen confianza. Cuando la propiedad de los documentos no está clara, nadie tiene el deber claro de revisar contenido riesgoso.
El control de acceso también se comporta de forma distinta en los sistemas de recuperación. Un índice de búsqueda puede conservar información después de que el documento original se elimine o restrinja. Los embeddings en caché, que son representaciones numéricas utilizadas para la búsqueda semántica, pueden generar cuestiones adicionales sobre el ciclo de vida.
El embedding podría no reproducir por sí solo un documento fuente. Sin embargo, el texto indexado, los metadatos, la caché de recuperación y los registros del modelo pueden conservar detalles sensibles.
Los equipos de seguridad deben saber qué componentes almacenan contenido sin procesar y cuáles almacenan representaciones derivadas. También deben comprender el comportamiento de eliminación en toda la canalización. Por ejemplo, cuando un contratista que deja la empresa pierde acceso a una carpeta de proyecto, la misma restricción debería llegar con rapidez al índice de búsqueda; de lo contrario, antiguos compañeros de equipo podrían seguir viendo extractos de documentos que el sistema fuente ya no devuelve.
Cloud Security Alliance informó de que la información no estructurada representa entre el 70% y el 90% estimado de los datos empresariales. Su estudio sobre datos no estructurados sostiene que las prácticas tradicionales de gobernanza tienen dificultades para gestionar este volumen.
Los datos no estructurados incluyen correos electrónicos, mensajes de chat, documentos, grabaciones y presentaciones. También son el material al que los sistemas de generación aumentada por recuperación suelen dirigirse primero.
Esto crea una inversión central. La información que las empresas antes consideraban demasiado dispersa para gestionar se ha convertido en un contexto valioso para la IA. Su utilidad atrae la integración antes de que el trabajo de gobernanza esté completo.
Un despliegue más rápido de la IA choca con una gobernanza responsable
La competencia principal es entre la velocidad de implementación y la capacidad de explicar cada acceso importante a datos o acción de IA.
Los programas de IA suelen comenzar con un objetivo empresarial visible. Un equipo de soporte quiere respuestas más rápidas. Un grupo financiero quiere automatizar la revisión de facturas. Una organización de ingeniería quiere asistentes que busquen en la documentación técnica.
La remediación de datos ofrece un beneficio menos inmediato. Catalogar registros, revisar permisos, eliminar duplicados y definir reglas de retención puede parecer ajeno a la demostración que esperan los ejecutivos.
Esa diferencia de visibilidad anima a los equipos a construir primero la capa de IA. Conectan un modelo a los sistemas existentes, prueban un flujo de trabajo prometedor y posponen el trabajo fundamental hasta que la escala se vuelve necesaria.
Este enfoque funciona mientras el piloto sigue siendo limitado. Falla cuando la organización añade usuarios, repositorios, herramientas o acciones autónomas.
Los equipos de seguridad heredan entonces un sistema cuyo valor depende de un acceso amplio. Restringir ese acceso puede reducir la calidad de las respuestas. Mantenerlo amplio puede vulnerar los principios de mínimo privilegio.
El mínimo privilegio consiste en otorgar a cada usuario o servicio solo el acceso necesario para su tarea actual. Se vuelve más difícil de aplicar cuando un agente realiza muchas tareas para muchos usuarios.
Los derechos de acceso de un empleado no deberían convertirse automáticamente en los permisos permanentes de un agente. El agente puede operar más rápido, combinar información entre sistemas y actuar cuando el empleado no está supervisando cada paso.
La telemetría de Teleport ilustra esta preocupación. Su encuesta de 2026 abarcó a 205 CISOs, arquitectos de seguridad y líderes de plataformas. La empresa informó que las organizaciones con sistemas de IA con privilegios excesivos experimentaron 4,5 veces más incidentes de seguridad que aquellas que aplicaban el mínimo privilegio.
Los hallazgos sobre seguridad de identidad proceden de un proveedor y no establecen causalidad. Aun así, apuntan a un mecanismo creíble: el acceso innecesario aumenta la cantidad de acciones perjudiciales que puede realizar un sistema comprometido.
Una buena gobernanza debe operar en varios niveles.
A nivel de datos, los equipos necesitan responsables, clasificaciones, reglas de calidad, períodos de retención y usos aprobados. A nivel de identidad, necesitan asignaciones claras entre usuarios, servicios, agentes y recursos.
A nivel de modelo, necesitan pruebas de filtraciones, selección insegura de herramientas, resultados poco fiables y manipulación. A nivel operativo, necesitan registros que vinculen una acción de IA con su usuario, fuentes de datos, modelo, instrucciones y herramientas.
Ninguno de estos controles funciona bien de forma aislada.
Un registro de acceso perfecto no puede explicar si una fuente era precisa. Un catálogo de datos limpio no puede impedir que un agente realice una acción innecesaria. Unas pruebas sólidas del modelo no pueden compensar credenciales que permiten cambios ilimitados en producción.
Por eso, comprar un producto de seguridad para IA no elimina la deuda de datos. Los productos pueden mejorar el descubrimiento, la supervisión, la aplicación de políticas o las pruebas. No pueden decidir las reglas legítimas de propiedad y uso de cada organización.
Estas decisiones requieren participación empresarial. Los equipos jurídicos comprenden las obligaciones contractuales. Los equipos de privacidad comprenden los requisitos relativos a los datos personales. Los líderes de departamento comprenden qué registros siguen siendo necesarios para las operaciones.
Los equipos de seguridad traducen esas responsabilidades en controles, pero no pueden inventar el contexto empresarial subyacente. Las directrices conjuntas para una IA segura de CISA y el Centro Nacional de Ciberseguridad del Reino Unido, respaldadas por 23 organizaciones de ciberseguridad, también sitúan la responsabilidad en el diseño seguro, la transparencia y la propiedad organizativa durante el desarrollo y la operación.
La presión se extiende a los trabajadores del conocimiento. Los empleados suelen crear archivos locales, duplicar notas o exportaciones privadas porque los sistemas oficiales son difíciles de buscar. Estas copias pueden conservar un contexto valioso mientras escapan de la gobernanza centralizada.
Un sistema de gestión del conocimiento bien diseñado puede reducir la fragmentación innecesaria cuando sus reglas de acceso y retención se mantienen claras. También puede crear nuevos riesgos cuando los equipos incorporan material sin revisar los permisos.
El objetivo no es la centralización máxima. Es un control predecible sobre dónde vive la información, quién puede acceder a ella y cómo puede usarla la IA.
Ese objetivo entra en conflicto con la creencia de que un modelo de IA debería buscar en todo. La recuperación amplia puede mejorar la comodidad, pero también aumenta la exposición y hace más difícil detectar un contexto incorrecto.
La alternativa segura es la recuperación selectiva. Los sistemas deberían filtrar las fuentes según el usuario, la tarea, la sensibilidad y el estado actual de autorización antes de que el contenido llegue al modelo.
Ese filtrado debe producirse en el momento de la solicitud. Copiar documentos a un índice central bajo una cuenta de servicio puede diluir las distinciones que existían en los sistemas de origen.
Los equipos también necesitan límites explícitos para las herramientas. Un agente que analiza una factura no necesita automáticamente permiso para aprobar un pago. Un asistente que recomienda una respuesta para un cliente no necesita autoridad para enviarla. En la práctica, el revisor financiero debería ver el pago propuesto, la factura de origen y los indicadores de excepción, mientras que el agente sigue sin poder liberar fondos sin una aprobación autorizada por separado.
Estas distinciones ralentizan la implementación inicial. También hacen que la implementación a escala sea más defendible.
Lo que las cifras sobre deuda de datos no demuestran
La investigación sobre deuda empresarial identifica una limitación generalizada, pero no demuestra que todo fallo de IA comience con datos deficientes.
La estimación de 18 billones de dólares de Genpact y HFS Research es la cifra más llamativa asociada con la cobertura reciente. Representa valor potencial modelado, no dinero registrado en las cuentas corporativas.
La estimación combina posibles aumentos de ingresos y reducciones de costes si las empresas Global 2000 resuelven cuatro tipos de deuda empresarial. No debería interpretarse como un retorno garantizado de la modernización de datos.
Solo una de las cuatro categorías es la deuda de datos. Las limitaciones de procesos, tecnología y talento pueden bloquear un proyecto incluso cuando su información es precisa y está bien gobernada.
Un modelo también puede fallar debido a limitaciones no relacionadas con la higiene de datos. Puede alucinar, malinterpretar una solicitud, seleccionar la herramienta equivocada o responder de forma inconsistente a indicaciones similares.
Los fallos de seguridad tienen muchas fuentes. Una dependencia comprometida, una credencial robada, una API vulnerable, un plugin inseguro o un diseño de aplicación defectuoso pueden eludir una gobernanza de datos que, por lo demás, sea adecuada.
Tratar la deuda de datos como la única causa repetiría la misma simplificación que creó el problema. Los sistemas empresariales de IA son sistemas sociotécnicos, lo que significa que su comportamiento depende conjuntamente del software, la información, los procesos y las personas.
El diseño de la encuesta del informe también importa. Las respuestas de los ejecutivos revelan limitaciones organizativas percibidas. No ofrecen una auditoría independiente del entorno de datos de cada empresa participante.
Los encuestados pueden usar “deuda de datos” para describir condiciones diferentes. Un ejecutivo puede referirse a registros de clientes duplicados. Otro puede referirse a una mala calidad de analítica, acceso limitado o falta de gobernanza.
La categoría sigue siendo útil porque estas condiciones comparten un patrón de coste diferido. Las organizaciones ganaron velocidad a corto plazo al posponer trabajo y luego afrontaron costes más altos cuando la IA requirió información coherente.
Sin embargo, la etiqueta puede volverse demasiado amplia. Los proveedores pueden asociar la “deuda” a cualquier problema heredado y presentar la modernización como la solución evidente.
Ese encuadre corre el riesgo de fomentar otro costoso programa de transformación sin prioridades claras. Una empresa podría sustituir plataformas mientras mantiene una propiedad poco clara y accesos excesivos.
La mejor prueba es operativa. ¿Puede la organización responder preguntas específicas sobre un flujo de trabajo de IA de alto valor?
Los equipos deberían saber qué fuentes utiliza el sistema, quién es responsable de ellas y cuándo se revisaron por última vez. Deberían saber si los permisos siguen alineados con las funciones actuales.
Deberían saber qué puede hacer el agente después de recuperar información. También deberían saber si los investigadores pueden reconstruir una decisión importante sin depender de la narrativa del modelo.
El Instituto Nacional de Estándares y Tecnología organiza el trabajo sobre riesgos de IA en torno a gobernar, mapear, medir y gestionar el riesgo. Su Marco de Gestión de Riesgos de IA y Perfil de IA Generativa exige propósitos de sistema documentados, supervisión continua, responsabilidades definidas para la respuesta a incidentes y revisión periódica de sistemas de IA de terceros, en lugar de depender de un único control o producto.
Esa visión de ciclo de vida encaja con la deuda de datos porque las debilidades antiguas rara vez desaparecen con una sola migración. Los equipos deben seguir verificando la calidad, los permisos, la procedencia y el uso a medida que evolucionan los sistemas.
Otra incertidumbre se refiere a los resultados de seguridad medibles. Los encuestados pueden informar de una preparación deficiente, pero las empresas rara vez divulgan incidentes detallados de IA. Por lo tanto, los datos públicos ofrecen una visión incompleta de la frecuencia y la gravedad.
Algunos incidentes pueden clasificarse como pérdida de datos ordinaria, abuso de acceso o compromiso de aplicaciones, incluso cuando la IA influyó en el camino. Otros pueden implicar resultados inseguros sin provocar una brecha notificable.
Esto dificulta la comparación. Las organizaciones necesitan definiciones internas para los incidentes relacionados con IA antes de poder evaluar si los controles los reducen.
Una definición útil debería incluir manipulación del modelo, divulgación no autorizada de datos, acciones inseguras de agentes e infraestructura de IA comprometida. También debería distinguir entre daños confirmados, infracciones de políticas y cuasi incidentes.
Sin esa disciplina, los líderes pueden afirmar que hay mejoras porque los incidentes notificados siguen siendo bajos. La cifra podría reflejar en cambio una detección limitada.
La conclusión escéptica es directa. La deuda de datos es un multiplicador de riesgo creíble, no una explicación completa de la inseguridad de la IA.
Las empresas que limpien sus registros pero ignoren la identidad de los agentes, el comportamiento del modelo y las dependencias de software seguirán expuestas. Las empresas que compren herramientas de supervisión pero dejen sin resolver la propiedad se enfrentarán a la misma ambigüedad con mejores paneles de control.
Tres señales mostrarán si la seguridad de la IA se está poniendo al día
La próxima prueba es si las empresas convierten la preocupación por la deuda de datos en permisos más limitados, recuperación trazable y una reducción medible de incidentes.
La primera señal es la adopción de controles de identidad específicos por tarea para los agentes de IA. Las organizaciones deberían alejarse de las cuentas de servicio compartidas y las credenciales permanentes.
Cada agente debería tener una identidad distinta, permisos limitados y un responsable humano o empresarial. El acceso debería limitarse según la tarea y caducar cuando ya no sea necesario. El documento conceptual de NIST de 2026 sobre la identidad y autoridad de los agentes de software identifica la autorización, la auditoría, el no repudio y los controles contra la inyección de prompts como áreas específicas que requieren estándares y orientación de implementación más sólidos.
Si esto se convierte en una práctica estándar, la brecha entre la implementación de IA y la preparación en seguridad comenzará a cerrarse. Si el acceso permanente sigue siendo habitual, la deuda de datos continuará traduciéndose en un radio de impacto mayor.
La segunda señal es la evidencia de que los sistemas de recuperación preservan los permisos de origen y las reglas de eliminación. Los proveedores empresariales de IA prometen cada vez más conectores seguros, pero los compradores necesitan pruebas técnicas.
Los equipos de seguridad deberían comprobar si el acceso revocado desaparece rápidamente de los resultados de búsqueda. Deberían verificar cómo los índices, las cachés, los registros y las copias de seguridad gestionan el material eliminado.
También deberían comprobar si las citas identifican de forma fiable la fuente exacta utilizada para una respuesta. Un enlace genérico a un repositorio no basta cuando los investigadores necesitan procedencia a nivel de documento.
El progreso en este ámbito reforzaría el argumento de que las organizaciones pueden utilizar información dispersa sin diluir sus controles. La persistencia de la deriva de permisos demostraría que la conveniencia sigue prevaleciendo sobre una recuperación responsable.
La tercera señal es una mejor divulgación de los incidentes de seguridad relacionados con la IA. Las empresas y los proveedores necesitan categorías coherentes que distingan entre filtración de datos, inyección de prompts, autonomía excesiva, abuso de identidad y compromiso de la infraestructura.
Un mayor número de informes no significa necesariamente que la seguridad esté empeorando. Los aumentos iniciales pueden indicar que la detección y la clasificación están mejorando.
La medida importante es si las organizaciones reducen los resultados graves y acortan el tiempo necesario para contenerlos. Eso requiere métricas comparables, no afirmaciones de marketing aisladas.
Estas tres señales deberían aparecer en las revisiones de compras y en los paneles operativos. Son más informativas que el número de proyectos piloto lanzados o de empleados a los que se ha dado acceso a un asistente.
La atención de Google News seguirá desplazándose hacia los agentes de IA, los nuevos productos de seguridad y los incidentes importantes. Los lectores deberían mirar más allá de esos titulares y examinar el estado de la capa de datos.
Pregúntese si un sistema destacado sabe qué información es autorizada. Pregúntese si su acceso sigue al usuario y a la tarea. Pregúntese si sus acciones pueden reconstruirse después de que algo salga mal.
Los líderes empresariales deberían comenzar con un flujo de trabajo valioso en lugar de prometer una limpieza de toda la organización. Deben trazar sus fuentes, propietarios, permisos, requisitos de retención, herramientas de agentes y rutas de fallo.
Después, deben poner a prueba los controles con cuentas revocadas, documentos manipulados, registros desactualizados y solicitudes que crucen los límites de autorización. Deben registrar qué recuperó el sistema, qué ignoró y qué intentó hacer.
Ese ejercicio no eliminará todos los riesgos de la IA. Revelará si la organización comprende el sistema que ya ha desplegado.
La cuestión ya no es si la deuda de datos reduce la calidad de los modelos. Es si las empresas retirarán esa deuda antes de que la IA convierta cada permiso olvidado y cada registro no gestionado en una decisión activa de seguridad.
