Etiqueta: Shadow Ai

Las acusaciones de robo de archivos contra OpenAI no son solo un litigio corporativo: exponen una falla estructural en la manera en que las empresas clasifican, custodian y controlan el acceso a sus datos antes de que lleguen a un proveedor de inteligencia artificial. El caso ilustra por qué la gobernanza de datos es un prerequisito, no un complemento, de cualquier estrategia de IA empresarial.

El caso, según se informó, involucra alegaciones de que empleados o ex-empleados habrían sustraído archivos propietarios y los habrían trasladado a OpenAI o utilizado en conexión con sus sistemas. Independientemente del desenlace legal, el patrón que describe es conocido para cualquier CDO que haya intentado rastrear qué datos salen de la organización y hacia dónde: sin un modelo sólido de ownership, clasificación y data lineage, la empresa no puede saber qué perdió hasta que alguien se lo dice en una demanda.

Qué falla cuando los datos se mueven sin trazabilidad

El concepto de data lineage —la capacidad de rastrear el origen, el movimiento y la transformación de un dato a lo largo del tiempo— es la primera línea de defensa ante este tipo de incidentes. Cuando un empleado copia archivos a un entorno externo, el lineage debería activar una alerta: el dato salió del grafo conocido. Pero en la mayoría de las organizaciones, ese grafo no existe más allá del data warehouse, y los archivos no estructurados —documentos, presentaciones, modelos internos— quedan fuera del radar del catálogo de datos corporativo. Según el marco DAMA-DMBOK (segunda edición), la gestión del ciclo de vida del dato incluye explícitamente la trazabilidad de su disposición y transferencia, algo que pocas organizaciones implementan de manera efectiva para activos no estructurados.

El rol del data steward es igualmente crítico aquí. Bob Seiner, referente en Non-Invasive Data Governance, define al steward no como un guardián burocrático sino como la persona que ya toma decisiones sobre un dato y simplemente las formaliza. Cuando ese rol no está asignado sobre archivos sensibles —código fuente, modelos propietarios, datos de clientes— nadie detecta el movimiento anómalo porque nadie tiene ownership formal del activo.

Cuándo aplica / cuándo NO este riesgo

Este riesgo de exfiltración silenciosa aplica de manera directa cuando la empresa utiliza proveedores de IA externos —ya sea a través de APIs, plugins o plataformas SaaS con capacidades generativas— y los empleados tienen acceso amplio a datos propietarios sin controles de clasificación. También aplica en escenarios de offboarding: cuando un empleado con acceso privilegiado sale de la organización y no existe un proceso formal de revocación de acceso y auditoría de lo que exportó antes de irse. No aplica —o aplica con menor urgencia— en organizaciones que operan modelos de IA completamente on-premise, sin transferencia de datos a terceros, y con controles de DLP (Data Loss Prevention) activos y auditados sobre todos los endpoints.

Shadow AI: el vector que amplifica el riesgo en 2025

Un factor que el caso OpenAI pone en primer plano es el del shadow AI: el uso de herramientas de inteligencia artificial generativa por parte de empleados sin autorización ni supervisión del área de TI o de datos. Según estimaciones del sector citadas por Gartner en 2024, más del 40% de los empleados en grandes organizaciones utiliza herramientas de IA generativa fuera de los canales corporativos aprobados. Cuando un empleado sube archivos internos a ChatGPT, Gemini o cualquier herramienta SaaS con IA para “hacer su trabajo más rápido”, está transfiriendo datos fuera del perímetro controlado, muchas veces sin que el dato haya sido clasificado previamente como sensible o confidencial. Sin clasificación, no hay política aplicable. Sin política aplicable, no hay infracción interna detectable hasta que el daño ya ocurrió.

El ángulo regulatorio en Argentina, Brasil y México

En América Latina, el escenario tiene capas regulatorias adicionales. En Argentina, la Ley 25.326 de Protección de Datos Personales establece obligaciones sobre la cesión y transferencia de datos a terceros, incluyendo proveedores tecnológicos en el exterior, lo que convierte cualquier transferencia no controlada a un sistema de IA externo en una potencial infracción ante la AAIP. En Brasil, la LGPD (Lei 13.709/2018) exige base legal para el tratamiento y transferencia internacional, y la ANPD ha señalado el uso de IA como una de sus prioridades de fiscalización para 2025 y 2026. En México, el INAI supervisa el cumplimiento de la LFPDPPP también en contextos B2B cuando hay datos de personas físicas involucrados. En los tres casos, el prerequisito regulatorio es el mismo que el prerequisito de gobernanza: saber qué datos tenés, cómo están clasificados, quién tiene acceso y hacia dónde se mueven.

Tres controles que un CDO puede activar esta semana

Frente a este escenario, la respuesta operativa no requiere esperar a que el litigio se resuelva. Un CDO con mandato real puede activar de inmediato tres controles de alta prioridad:

• Auditar el inventario de activos no estructurados sensibles (código fuente, modelos propietarios, datos de clientes en formatos de archivo) y asignar un data steward formal con accountability documentada para cada dominio crítico.
• Revisar los controles de DLP sobre endpoints y canales de salida, con foco específico en transferencias hacia dominios de proveedores de IA (openai.com, anthropic.com, gemini.google.com, etc.) y servicios de almacenamiento en la nube no corporativos.
• Establecer o actualizar la política de uso de IA generativa externa, con un proceso de aprobación explícito para herramientas de IA y una cláusula de clasificación previa obligatoria: ningún dato puede salir hacia un sistema de IA externo si no tiene una etiqueta de clasificación asignada.

El marco CDMC (Cloud Data Management Capabilities) del EDM Council, en su capability 8 sobre protección y privacidad de datos, ofrece un modelo de madurez útil para evaluar en qué punto se encuentra la organización antes de escalar el uso de proveedores de IA externos.

Las acusaciones contra OpenAI no definen culpabilidad, pero sí definen una pregunta que todo CDO debería poder responder hoy: si un empleado copiara los archivos más sensibles de la organización y los cargara a un sistema de IA externo esta tarde, ¿cuánto tardaríamos en saberlo?

Cuando la adopción de inteligencia artificial supera la capacidad de gobernanza de una organización, el primer cargo que queda expuesto no es el del CEO ni el del CFO: es el del CIO. Las brechas entre la velocidad de despliegue de herramientas de IA y los marcos de control interno están generando un riesgo operativo y reputacional que los equipos técnicos todavía subestiman.

El fenómeno tiene un nombre en la industria: AI overload. No se refiere al volumen de datos que procesan los modelos, sino a la saturación institucional que ocurre cuando una organización incorpora múltiples sistemas de IA —agentes, copilotos, herramientas generativas, APIs de terceros— sin que existan políticas claras de ownership, clasificación del dato de entrada, ni criterios de auditoría de outputs. El resultado es un entorno donde nadie puede responder con certeza quién es responsable de qué decide el sistema.

Tres brechas de gobernanza que concentran el riesgo en el CIO

La primera brecha es de inventario. La mayoría de las organizaciones no tienen un catálogo actualizado de los sistemas de IA que operan en producción, incluidos los contratados por áreas de negocio sin intervención de TI —lo que el mercado llama shadow AI. Sin ese inventario, el CIO no puede establecer controles de acceso diferenciados, ni garantizar que los datos que alimentan esos modelos cumplen con las políticas de clasificación vigentes. El DAMA-DMBOK v2 trata este punto bajo la capacidad de data asset management: si el activo no está catalogado, no existe para el gobierno.

La segunda brecha es de linaje (data lineage). Cuando un modelo de lenguaje genera una recomendación o resume un contrato, ¿de qué datos se nutrió? ¿Incluía información confidencial, datos personales de clientes, información regulada? Sin trazabilidad de extremo a extremo —desde la fuente hasta el output del modelo— es imposible demostrar cumplimiento ante una auditoría regulatoria. En jurisdicciones con marcos de protección de datos maduros, como Brasil (LGPD, Lei 13.709/2018) o Argentina (Ley 25.326 y su decreto reglamentario 1558/2001), la ausencia de linaje en tratamientos automatizados puede constituir una infracción directa a los principios de transparencia y finalidad.

La tercera brecha es de ownership. En muchas organizaciones, los data stewards —los responsables de dominio sobre conjuntos de datos específicos— no fueron incorporados al proceso de selección ni de monitoreo de herramientas de IA. Esto genera un vacío: el modelo opera sobre datos que alguien “gobierna” en papel, pero sin que ese steward haya validado el uso ni pueda responder por los resultados. Es una falla estructural que el EDM Council documenta en su Data Management Capability Assessment Model (DCAM) como riesgo de baja madurez en la capacidad de “data governance accountability”.

Cuándo aplica este análisis y cuándo no

Este marco de riesgo aplica a organizaciones que ya tienen al menos una herramienta de IA generativa en producción —sea un copiloto de código, un asistente de atención al cliente, un motor de resumen de documentos— y que operan en sectores regulados: servicios financieros, salud, retail con datos de comportamiento, o cualquier industria que procese datos personales a escala. No aplica del mismo modo a organizaciones en fase de exploración o prueba de concepto, donde los datos utilizados son sintéticos o están completamente desidentificados y el modelo no toca producción.

Tampoco es un problema exclusivo de empresas grandes. En América Latina, compañías medianas de e-commerce, fintechs y aseguradoras están incorporando APIs de modelos de lenguaje de terceros sin un análisis previo de qué datos fluyen hacia esos proveedores externos. En México, la LFPDPPP y los lineamientos del INAI obligan a establecer cláusulas contractuales con encargados del tratamiento; en Colombia, la Ley 1581 de 2012 exige el mismo estándar. El uso de una API de IA sin contrato de encargo adecuado puede constituir una transferencia no autorizada de datos personales.

Lo que el CIO necesita resolver antes de escalar más herramientas

El primer paso no es detener la adopción, sino hacer visible lo que ya opera. Un sprint de inventario de sistemas de IA —incluyendo las herramientas contratadas por áreas de negocio sin aprobación formal de TI— es el punto de partida mínimo. Ese inventario debe cruzarse con el catálogo de datos existente para identificar qué activos de datos están siendo utilizados como input, bajo qué política de clasificación y con qué nivel de sensibilidad. Si no existe un catálogo de datos formal, ese es el déficit previo que hace imposible gobernar la IA.

El segundo paso es formalizar el rol del data steward en el ciclo de vida de cada sistema de IA: desde la selección del proveedor hasta la revisión periódica de outputs. No como control de calidad técnica, sino como garantía de que el uso del dato es consistente con la política de la organización y con los marcos regulatorios aplicables. En organizaciones que trabajan bajo el estándar CDMC del EDM Council, esto corresponde a la capacidad 10 (“data usage”) combinada con la capacidad 7 (“data protection”).

El riesgo no es la inteligencia artificial: es operar sistemas que toman decisiones sobre datos que nadie en la organización puede rastrear, explicar ni defender ante un regulador. Ese es el gap que convierte al CIO en el responsable de última instancia de fallos que nunca aprobó. Para profundizar en el marco de madurez de gobernanza aplicable a entornos con IA, el EDM Council ofrece el CDMC de acceso público en edmcouncil.org.

El uso no autorizado de herramientas de inteligencia artificial generativa dentro de las organizaciones —lo que la industria llama shadow AI— está superando la capacidad de los programas de gobernanza de datos para detectarlo, clasificarlo y auditarlo. Los frameworks existentes no fueron diseñados para un entorno en el que cualquier colaborador puede procesar datos corporativos sensibles desde una pestaña del navegador, sin pasar por TI ni por el área de datos.

La gobernanza de datos, en su concepción clásica —basada en DAMA-DMBOK o en el CDMC del EDM Council—, asume que el flujo de datos es relativamente conocido: hay sistemas de registro, hay data stewards que custodian dominios, hay pipelines auditables. Shadow AI rompe ese supuesto desde la base. Cuando un analista carga un archivo de clientes en ChatGPT para generar un resumen, o un equipo de ventas usa una extensión de IA para redactar propuestas con datos de CRM, ese flujo no deja rastro en ningún catálogo de datos, no tiene ownership asignado y no activa ninguna política de retención.

El problema de visibilidad: datos que salen sin pasar por el catálogo

El nudo central es de visibilidad. Los programas de gobernanza de datos dependen de que los activos estén registrados —idealmente en un catálogo con linaje (data lineage) documentado— para poder aplicar controles. Shadow AI crea canales de exfiltración suave que no generan alertas en las herramientas de Data Loss Prevention (DLP) tradicionales si el volumen por sesión es bajo, y que no quedan registrados en los logs de los sistemas fuente. El dato sale, es procesado por un modelo externo, y vuelve —o no— como output. Ese ciclo es invisible para el CDO.

A esto se suma un problema de clasificación. Si el dato no está etiquetado previamente —y en la mayoría de las organizaciones de la región, la clasificación formal de activos de datos está en etapas tempranas—, no hay mecanismo automático que impida que un dato catalogado como “confidencial” sea pegado en un prompt. La clasificación tiene que preceder al control, y en muchas empresas latinoamericanas ese paso todavía está en construcción.

Cuándo aplica y cuándo NO como problema de gobernanza

Shadow AI es un problema de gobernanza de datos cuando el activo comprometido tiene un data steward asignado, pertenece a un dominio de datos definido, o está sujeto a una política de retención o clasificación. En esos casos, el uso no autorizado de una herramienta de IA externa es un incumplimiento del marco de gobernanza, no solo una infracción de seguridad. En cambio, si el empleado usa IA con datos públicos o propios sin clasificación corporativa, el problema es predominantemente de política de uso aceptable —competencia de RRHH o Legal— y no de gobernanza de datos en sentido estricto. La distinción importa porque define quién debe actuar y con qué autoridad.

Tres capabilities que el programa de gobernanza debe incorporar

Los equipos de gobernanza de datos que quieran responder a shadow AI necesitan desarrollar, como mínimo, tres capabilities nuevas. Primero, integración con herramientas de monitoreo de endpoints y tráfico de red para detectar transferencias de datos hacia dominios de IA generativa conocidos —algo que hoy hace el equipo de seguridad, no el de datos, y que requiere coordinación formal entre ambos. Segundo, extensión del catálogo de datos para incluir no solo sistemas de registro sino también flujos de IA sancionados, de modo que el inventario refleje dónde se procesan los datos, no solo dónde viven. Tercero, capacitación de data stewards para identificar y reportar usos de IA no inventariados dentro de sus dominios: el steward como primer sensor humano de shadow AI.

El marco de Non-Invasive Data Governance de Bob Seiner es particularmente útil aquí: si los stewards ya tienen responsabilidades definidas sobre sus dominios de datos, extender esa responsabilidad al monitoreo de herramientas de IA que procesan esos datos es un paso incremental, no una revolución organizacional.

En Brasil, Argentina y México: el riesgo regulatorio es concreto

En América Latina, shadow AI no es solo un riesgo operativo: es un riesgo de cumplimiento con consecuencias legales concretas. La Lei Geral de Proteção de Dados (LGPD) de Brasil exige que el tratamiento de datos personales tenga una base legal y un propósito documentado. Si un empleado procesa datos de clientes en una herramienta de IA externa sin autorización, la empresa puede enfrentar responsabilidad ante la ANPD por tratamiento sin base legal y sin medidas de seguridad adecuadas. En Argentina, la Ley 25.326 establece obligaciones similares, y la AAIP ha dado señales de mayor actividad inspectiva en los últimos dos años. En México, el INAI requiere bajo la LFPDPPP que los responsables garanticen que los encargados de tratamiento —incluyendo proveedores tecnológicos— ofrezcan garantías suficientes. Un proveedor de IA generativa usado en modo shadow no tiene contrato de encargo, no tiene cláusulas de confidencialidad y probablemente no cumple con los estándares requeridos.

Los bancos y aseguradoras de la región tienen una presión adicional: reguladores sectoriales como el Banco Central de Brasil (BACEN) o la Comisión Nacional Bancaria y de Valores (CNBV) en México están incorporando expectativas de gestión de riesgos tecnológicos que incluyen el inventario de herramientas de IA. Shadow AI es, en ese contexto, un gap de cumplimiento sectorial además de uno de gobernanza.

El lunes, el CDO tiene cuatro movimientos concretos

Sin necesidad de esperar una política corporativa de IA completa, un CDO puede iniciar cuatro acciones inmediatas. Primero, mapear junto a seguridad qué dominios de datos de mayor criticidad tienen mayor probabilidad de exposición vía IA (datos de clientes, datos financieros, datos de RRHH). Segundo, revisar si el catálogo de datos incluye campo de “herramientas autorizadas de procesamiento” y, si no existe, agregarlo como metadata. Tercero, convocar a los data stewards de dominios críticos para una sesión de sensibilización: preguntarles si conocen usos de IA generativa en sus áreas y documentar las respuestas. Cuarto, establecer una mesa de trabajo con Legal y Seguridad para definir qué herramientas de IA pasan a la categoría de “encargados de tratamiento” bajo LGPD, Ley 25.326 o LFPDPPP, según la jurisdicción, y qué contratos deben formalizarse.

El CDMC del EDM Council incluye la gestión de riesgos de datos como capability central; el gap de shadow AI no es nuevo en términos de concepto, pero sí en escala. Las organizaciones que quieran profundizar pueden consultar el marco de referencia del EDM Council en edm-council.org y los lineamientos de la ANPD brasileña sobre uso de IA publicados en 2024.

La adopción acelerada de inteligencia artificial en el sector educativo está revelando una brecha que muchas instituciones preferían no ver: sus datos no están gobernados. La conferencia EDUCAUSE 2026 puso este diagnóstico en el centro del debate, con un mensaje que trasciende a los campus universitarios y aplica a cualquier organización que haya empezado a desplegar IA sin primero ordenar su casa de datos.

El argumento de fondo es técnicamente simple pero organizacionalmente incómodo: los modelos de IA necesitan datos de calidad, con linaje claro, clasificados, y con ownership definido. Cuando esos atributos no existen —y en la mayoría de las instituciones educativas no existen de forma sistemática—, la IA no falla de manera obvia. Falla de manera silenciosa: genera respuestas inexactas, amplifica sesgos ya presentes en los datos históricos, o consume información sensible de estudiantes sin que nadie en la cadena haya autorizado ese uso.

La IA como auditor involuntario: tres fallas que EDUCAUSE ’26 puso sobre la mesa

Según se informó desde la conferencia, los panelistas identificaron patrones recurrentes en instituciones que desplegaron herramientas de IA generativa sobre sus repositorios de datos académicos y administrativos. Las fallas no eran de los modelos: eran de la infraestructura de gobernanza que debía sostenerlos. Los problemas más frecuentes se agrupan en tres categorías:

• Ausencia de catálogo de datos: las instituciones no sabían qué datos tenían, dónde estaban almacenados ni quién era el data steward responsable de cada dominio.
• Linaje roto: los datos llegaban a los sistemas de IA desde múltiples fuentes sin trazabilidad de transformaciones previas, lo que hacía imposible auditar los outputs del modelo.
• Shadow AI: docentes y personal administrativo conectaban herramientas de IA externas a repositorios institucionales sin pasar por ningún proceso de evaluación de riesgo ni validación de privacidad.

Este tercer punto es el más sensible en términos regulatorios. El uso no autorizado de IA generativa dentro de organizaciones —lo que la industria denomina shadow AI— no es un problema de ciberseguridad en primer lugar: es un problema de gobernanza. Cuando un docente sube información de sus estudiantes a un LLM externo sin que la institución haya evaluado ese flujo de datos, el framework DAMA-DMBOK lo clasifica como un fallo en la capability de Data Security y en la política de Data Quality, no como un incidente de red.

Cuándo aplica este diagnóstico y cuándo NO

Este análisis aplica directamente a instituciones —educativas o no— que están desplegando IA sobre datos que nunca pasaron por un programa formal de gobernanza: sin clasificación por sensibilidad, sin definición de dominios, sin data owners nombrados. Si una organización ya opera con un framework maduro —DCAM del EDM Council, ISO/IEC 38505, o equivalente— y tiene sus activos catalogados con metadata gestionada, la IA no expone brechas nuevas: las hace más visibles, pero el programa de gobierno ya tiene los controles para responder. El problema crítico es para quienes asumieron que podían postergar la gobernanza hasta “después de implementar la IA”. Ese orden no funciona.

Tampoco aplica —o aplica solo parcialmente— a organizaciones que usan IA exclusivamente sobre datos públicos o sintéticos, sin ingestión de datos personales de empleados, clientes o, en el caso educativo, estudiantes. En esos contextos, los riesgos de gobernanza son menores, aunque no inexistentes.

América Latina: universidades públicas bajo presión regulatoria creciente en Brasil, México y Argentina

El cuadro que describe EDUCAUSE 2026 resuena con fuerza en la región, donde las universidades públicas manejan volúmenes significativos de datos sensibles de estudiantes —condición socioeconómica, rendimiento académico, salud— bajo marcos regulatorios que están madurando rápidamente. En Brasil, la Lei Geral de Proteção de Dados (LGPD) obliga a las instituciones educativas a designar un Encarregado (equivalente al DPO europeo) y a realizar evaluaciones de impacto cuando el tratamiento involucra datos de menores o categorías sensibles. El uso de IA generativa sobre registros académicos de menores de edad activa directamente esa obligación.

En México, la LFPDPPP y los lineamientos del INAI exigen consentimiento informado para finalidades distintas a las originales de recolección: una universidad que recolectó datos de sus estudiantes para gestión académica y luego los usa para entrenar o alimentar un modelo de IA enfrenta un conflicto de finalidad que no puede resolver sin revisión legal. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) avanzó en 2024 con recomendaciones sobre IA y datos personales que, aunque no son vinculantes, anticipan el estándar que el proyecto de reforma de la Ley 25.326 buscará consolidar. Las instituciones educativas que no tengan un programa de gobernanza operativo cuando esa reforma se apruebe enfrentarán un costo de adecuación significativamente mayor.

Lo que un CDO debe hacer antes de que la IA ya esté en producción

El mensaje operativo de EDUCAUSE 2026 para quienes lideran gobernanza de datos es claro: la IA no espera a que el catálogo esté terminado. El despliegue ya ocurrió, o va a ocurrir en semanas. Frente a esa realidad, los pasos concretos son tres. Primero, ejecutar un inventario de flujos de datos hacia herramientas de IA —tanto las aprobadas como las que circulan sin autorización formal— y clasificar cada flujo por sensibilidad de los datos involucrados. Segundo, nombrar data stewards por dominio con responsabilidad explícita sobre los datos que alimentan sistemas de IA: el ownership difuso es el origen de la mayoría de las brechas que describe este diagnóstico. Tercero, revisar las bases legales de tratamiento según la normativa aplicable antes de escalar cualquier caso de uso de IA que involucre datos de personas —estudiantes, empleados, pacientes— para evitar conflictos de finalidad que son costosos de resolver a posteriori. Bob Seiner, referente del enfoque Non-Invasive Data Governance, insiste en que los stewards deben existir donde ya existe responsabilidad natural sobre los datos: en el sector educativo, eso es el área académica y el área de registro, no el departamento de IT.

Para profundizar, el marco de referencia más completo para este diagnóstico es el DAMA-DMBOK2, capítulo de Data Security, y los lineamientos de evaluación de impacto de la ANPD de Brasil, disponibles en gov.br/anpd, que incluyen criterios específicos para tratamientos automatizados con potencial de decisión sobre personas.

Cuando un empleado de la Agencia de Ciberseguridad e Infraestructura de Estados Unidos (CISA) usó ChatGPT en un contexto no autorizado, el incidente dejó al descubierto algo más profundo que un error individual: la mayoría de las organizaciones gubernamentales y privadas no tienen marcos operativos para gobernar el uso de inteligencia artificial generativa por parte de sus equipos. El problema no es tecnológico. Es de gobernanza.

El caso de CISA, según se informó, involucra el uso de una herramienta de IA generativa fuera de los canales aprobados por la agencia. No se trató de un ataque externo ni de una vulnerabilidad técnica en los modelos: fue un empleado que recurrió a una herramienta de acceso público para realizar tareas laborales. Este patrón tiene nombre en la industria: shadow AI, el equivalente al viejo shadow IT pero con implicancias mucho más complejas cuando los datos involucrados son sensibles o clasificados.

Shadow AI: el riesgo que los marcos de gobernanza todavía no capturan

El concepto de shadow AI describe el uso no autorizado o no gestionado de herramientas de inteligencia artificial dentro de una organización, generalmente por fuera de los controles aprobados por TI, seguridad o el área legal. A diferencia del shadow IT clásico —instalar una app no autorizada, usar Dropbox en lugar del servidor corporativo—, el shadow AI implica que el empleado está potencialmente transfiriendo datos hacia modelos de lenguaje externos cuyo tratamiento de la información no está bajo el control de la organización. En el caso de CISA, que opera en el ecosistema de seguridad nacional estadounidense, las consecuencias potenciales van desde la exposición de información sensible hasta la generación de contenido oficial basado en salidas no verificadas de un modelo.

El problema estructural es que los frameworks de gobernanza de datos vigentes —incluso los más maduros, como el DAMA-DMBOK o el Data Management Capability Assessment Model (DCAM) del EDM Council— no contemplan de manera explícita el ciclo de vida del dato cuando este sale de la organización hacia un modelo de lenguaje de terceros. ¿Qué dato puede ingresarse como prompt? ¿Quién es el data steward responsable de esa decisión? ¿Existe una política de clasificación que defina qué nivel de sensibilidad habilita o prohíbe el uso de IA generativa externa? En la mayoría de las organizaciones, la respuesta a esas tres preguntas es: nadie lo definió.

Clasificación de datos y ownership: los dos controles que fallaron en CISA

Un análisis de gobernanza del incidente apunta a dos fallas concretas. Primero, ausencia de una política de clasificación de datos que establezca explícitamente qué categorías de información no pueden salir del perímetro organizacional bajo ningún formato, incluyendo prompts a modelos externos. Segundo, falta de ownership claro: ningún data steward tenía la responsabilidad asignada de definir las reglas de uso de IA generativa para su dominio de datos. Cuando el ownership no está definido, el empleado toma la decisión por defecto —usar la herramienta que tiene disponible— y la organización absorbe el riesgo sin haberlo evaluado.

El NIST AI Risk Management Framework (AI RMF), publicado en 2023, ofrece un punto de partida para estructurar controles en torno a sistemas de IA, pero su adopción en organismos públicos de América Latina es todavía marginal. El framework distingue entre las funciones Govern, Map, Measure y Manage aplicadas a riesgos de IA —una estructura que puede integrarse con los dominios del DAMA-DMBOK para organizaciones que ya tienen un programa de gobernanza de datos activo.

Cuándo aplica este análisis y cuándo no

Este tipo de riesgo de shadow AI aplica a cualquier organización cuyos empleados tienen acceso a herramientas de IA generativa públicas y trabajan con datos que tienen algún nivel de sensibilidad: información regulada, datos personales bajo LGPD, Ley 25.326 o LFPDPPP, información estratégica, datos de clientes, contratos, o comunicaciones internas. No aplica de la misma manera a organizaciones donde todos los datos son públicos por naturaleza o donde los equipos ya operan exclusivamente dentro de entornos de IA privados y auditados. Para el grueso de las organizaciones de la región —bancos, aseguradoras, organismos públicos, empresas de salud—, el caso CISA es un escenario perfectamente replicable.

En América Latina, el marco regulatorio ya exige controles que el shadow AI vulnera

En Brasil, la Lei Geral de Proteção de Dados (LGPD) impone al controlador la responsabilidad de demostrar que implementó medidas técnicas y organizativas suficientes para proteger los datos personales. Si un empleado ingresa datos personales de clientes en un prompt de ChatGPT sin que la organización haya definido controles para eso, el controlador está potencialmente expuesto ante la Autoridade Nacional de Proteção de Dados (ANPD). En Argentina, la Ley 25.326 y las disposiciones de la Agencia de Acceso a la Información Pública (AAIP) establecen obligaciones análogas de seguridad sobre los datos. En México, la LFPDPPP exige medidas de seguridad administrativas, físicas y técnicas —una transferencia no autorizada de datos personales a un modelo de IA externo puede interpretarse como una vulneración de esa obligación. Ninguna de estas leyes menciona explícitamente la IA generativa, pero los principios de responsabilidad y seguridad que establecen son suficientemente amplios para alcanzar este tipo de uso.

La respuesta operativa para un equipo de gobernanza pasa por tres pasos concretos: (1) revisar la política de clasificación de datos e incorporar una capa explícita de “aptitud para IA externa” —definir qué clases de datos pueden usarse en prompts fuera del perímetro—; (2) asignar formalmente a los data stewards de cada dominio la responsabilidad de aprobar o restringir el uso de herramientas de IA generativa sobre sus datos; y (3) implementar un registro de herramientas de IA en uso, aprobadas y no aprobadas, equivalente al inventario de sistemas que ya exige el DCAM en su capability de Data Asset Inventory.

El incidente de CISA no es una anomalía: es el primer caso documentado de una serie que crecerá mientras las organizaciones sigan tratando la gobernanza de IA como un problema futuro en lugar de un control que debió estar activo hace doce meses.

La integración de Copilot directamente en Windows introduce una capa de procesamiento de datos asistido por IA en el endpoint que los marcos de gobernanza corporativa no estaban diseñados para gestionar. El modelo de control centralizado de datos enfrenta una tensión concreta: el dato ya no viaja solo hacia el servidor; ahora es procesado, resumido y potencialmente enviado a servicios externos desde el propio dispositivo del usuario.

Durante años, la gobernanza de endpoints en entornos empresariales se resolvió con políticas de DLP (Data Loss Prevention), clasificación de archivos y controles de acceso gestionados por el área de TI. Copilot en Windows cambia la ecuación: el asistente puede acceder a correos, documentos, portapapeles y contexto de pantalla para generar respuestas, lo que significa que datos bajo clasificación sensible pueden ser parte de un prompt sin que el data steward responsable de ese activo haya intervenido en la decisión.

Qué dato fluye, hacia dónde y bajo qué política

El problema central para los equipos de gobernanza no es técnico sino de ownership: ¿quién es el data steward del contexto que Copilot consume en tiempo real? En el marco DAMA-DMBOK, el dato tiene un custodio definido por dominio; pero el contexto ensamblado por un modelo de lenguaje en el endpoint mezcla activos de múltiples dominios —finanzas, RRHH, operaciones— sin respetar los límites de clasificación establecidos. Esto no es un fallo de seguridad informática; es un fallo de data lineage: la trazabilidad del dato se rompe en el momento en que ingresa al contexto del modelo.

Microsoft ha documentado configuraciones de privacidad para Copilot en entornos empresariales, incluyendo la posibilidad de deshabilitar el envío de datos a servicios en la nube y operar en modo “con datos comerciales protegidos” bajo licencias Microsoft 365. Sin embargo, según se informó, la granularidad de esos controles varía según el plan de licenciamiento y la configuración de tenant, lo que crea brechas de governance para organizaciones que aún no han actualizado sus contratos o revisado sus políticas de uso.

Shadow AI en el endpoint: el riesgo que DAMA no anticipó

La irrupción de Copilot como función nativa del sistema operativo —y no como aplicación instalable separada— representa un vector nuevo de shadow AI: el uso ocurre antes de que el área de gobernanza tome conocimiento de él. A diferencia de un empleado que descarga ChatGPT, aquí el asistente viene preinstalado con el sistema operativo. Las políticas de uso aceptable y los registros de consentimiento informado que muchas organizaciones latinoamericanas desarrollaron en 2023-2024 para herramientas de IA generativa externa no cubren, en la mayoría de los casos, capacidades nativas del OS.

Desde la perspectiva del EDM Council y su marco CDMC (Cloud Data Management Capabilities), el control relevante es el capability 9: gestión de consentimiento y uso de datos. En una arquitectura con Copilot activo en el endpoint, ese control requiere ser reimplementado a nivel de política de grupo (GPO) o mediante Microsoft Intune, no solo a nivel de contrato o aviso de privacidad corporativo.

Cuándo aplica como problema de gobernanza / cuándo no

Este desafío aplica directamente cuando la organización maneja datos clasificados como confidenciales o restringidos bajo cualquier esquema de clasificación (sea propio, basado en ISO/IEC 27001 o en normativa sectorial), y Copilot está habilitado por defecto en los endpoints de esos usuarios. No aplica —o el riesgo es bajo— cuando el tenant de Microsoft 365 tiene Copilot deshabilitado a nivel de administrador, cuando los dispositivos operan en entornos air-gapped, o cuando la organización solo procesa datos públicos. El punto crítico es el gap entre organizaciones que asumen que “Copilot empresarial es seguro por contrato” y aquellas que han verificado efectivamente qué datos salen del endpoint y bajo qué base legal.

El vector regulatorio en América Latina

En Brasil, la LGPD establece que el responsable del tratamiento (controlador) debe garantizar medidas técnicas y administrativas para proteger los datos personales de accesos no autorizados y situaciones accidentales. Un Copilot que accede a correos con datos de clientes sin que el usuario haya recibido información clara sobre ese procesamiento configura, al menos, una tensión con el artículo 46 de la ley. En Argentina, la Ley 25.326 y las disposiciones de la AAIP en materia de cesión de datos a terceros —incluyendo proveedores tecnológicos extranjeros— obligan a revisar si los acuerdos de procesamiento de datos vigentes con Microsoft cubren los nuevos flujos introducidos por Copilot. En México, el INAI ha sido explícito en que los responsables no pueden delegar en el contrato con el proveedor la responsabilidad de informar al titular sobre los tratamientos realizados.

Las organizaciones que operan bajo regulación sectorial adicional —bancos supervisados por el BCRA en Argentina, instituciones financieras bajo la CNBV en México, o entidades de salud con obligaciones bajo normativas locales— enfrentan una capa extra: el regulador sectorial puede exigir controles más estrictos sobre dónde y cómo se procesan datos de clientes, independientemente de lo que el contrato con Microsoft establezca.

Tres controles concretos para equipos de gobernanza

• Auditar qué usuarios tienen Copilot habilitado y sobre qué datos clasificados tienen acceso, cruzando el inventario de activos de datos con el directorio de licencias de Microsoft 365 Copilot.
• Revisar los Data Processing Agreements (DPA) con Microsoft para confirmar que los nuevos flujos de Copilot están cubiertos y son compatibles con las bases legales de tratamiento establecidas en las políticas internas.
• Actualizar las políticas de clasificación de datos para incluir una regla explícita sobre qué categorías de datos no pueden ser expuestas al contexto de modelos de lenguaje, y trasladar esa regla a controles técnicos en Intune o mediante etiquetas de sensibilidad de Microsoft Purview.

La documentación oficial de Microsoft sobre controles de privacidad para Copilot en entornos empresariales está disponible en el Centro de confianza de Microsoft (Microsoft Trust Center); revisarla junto al DPA vigente es el punto de partida obligado antes de cualquier decisión de habilitación masiva.