F15 - 15.0 INTRODUCCIÓN: PRIVACIDAD E IA — UNA CONFLUENCIA INEVITABLE

§15.0 Introducción — La tensión estructural entre IA y privacidad: tabla comparativa de 6 dimensiones mostrando los riesgos sin privacy engineering vs. los controles técnicos que lo mitigan (training, contexto LLM, corpus RAG, fine-tuning, outputs, logs). El marco regulatorio que lo obliga: GDPR Art. 25, EU AI Act Art. 10, Reforma 25.326 Argentina.

§15.1 Privacy-by-Design para IA — Adaptación de los 7 principios de Cavoukian (1996, elevados a ley en GDPR) al contexto específico de LLMs, RAG y agentes. El principio proactivo aplicado al DPIA de IA antes del deployment; el de configuración predeterminada aplicado a Zero Data Retention y contexto mínimo en Copilot; el de funcionalidad total respondiendo al mito de que privacidad = peor modelo.

§15.2 Técnicas de Privacy Preservation — Differential Privacy con detail: el parámetro epsilon y sus valores en producción enterprise (ε=8.65 alineado con ISO/IEC 27559 y NIST SP 800-226), DP-SGD, las librerías Opacus y TF Privacy, el trade-off privacidad-utilidad con datos cuantitativos. Federated Learning: los 4 tipos (horizontal, vertical, cross-device, FL+DP combinado) con casos reales 2025 incluyendo Zurich+Orange (30% mejora) y KAIST. Homomorphic Encryption y SMPC: estado 2025, overhead, Azure Confidential Computing como alternativa práctica.

§15.3 Anonimización, Pseudonimización y Synthetic Data — El continuo legal-técnico entre las tres técnicas con sus implicaciones bajo GDPR/Ley 25.326. El problema de los quasi-identifiers (Sweeney 1997: código postal + género + fecha de nacimiento re-identifica al 87%). Machine Unlearning como respuesta técnica al derecho al olvido: reentrenamiento exacto (viable para modelos propios pequeños), approximate unlearning (investigación activa), y la postura práctica de compliance cuando el unlearning exacto no es técnicamente posible. Microsoft Presidio como herramienta operacional para anonimización de PII en corpus.

§15.4 Data Minimization en LLM y RAG — Las 5 dimensiones de minimización técnica: contexto del LLM (purging automático, filtros de PII, separación por clasificación), corpus RAG (políticas de retención, exclusión de categorías, auditoría de permisos SharePoint), logs de interacciones (máximo 90 días para contenido completo), outputs del LLM (Purview DLP, sensitivity labels en respuestas), y embeddings en vector database (access control, no indexar datos ultra-sensibles, encriptación at-rest).

§15.5 Microsoft Purview para Privacidad de IA — Mapa completo de 8 capacidades Purview con descripción, relevancia para privacidad de IA, y estado de disponibilidad: DSPM for AI, Sensitivity Labels (MIP), DLP para Copilot, Audit Log, Insider Risk Management for AI, Compliance Manager (con templates EU AI Act y GDPR), Data Lifecycle Management, y Data Risk Assessments. El Copilot Oversharing Problem: el 8.5% de prompts enterprise expone datos sensibles, y el límite de Purview (controla acceso, no inferencia semántica).

§15.6 DPIA para Sistemas de IA — Cuándo es obligatorio (6 criterios GDPR con ejemplos en contexto M365). El proceso completo de 8 pasos adaptado a sistemas de IA con outputs y evidencias para cada paso: descripción, necesidad/proporcionalidad, riesgos específicos de IA (memorización, inferencias indeseadas, sesgo, reidentificación, derecho al olvido inviable), controles existentes, plan de mitigación, consulta con DPO, revisión continua, documentación.

§15.7 Plan para CISO — Seis acciones concretas para los primeros 90 días: activar DSPM for AI, completar etiquetado MIP, implementar DLP en Copilot, ejecutar DPIAs para casos de alto riesgo, configurar retención de logs, e inventariar todos los sistemas de IA. Programa maduro para año 1 y 2027: privacy review como gate de deployment, auditoría anual, capacitación de 20,000 usuarios Copilot, Presidio para corpus RAG, proceso de ejercicio de derechos GDPR, y PETs para modelos propios.

15.0 INTRODUCCIÓN: PRIVACIDAD E IA — UNA CONFLUENCIA INEVITABLE

La privacidad y la inteligencia artificial comparten una tensión estructural: la IA se nutre de datos, y los datos de mayor valor son a menudo los más sensibles desde una perspectiva de privacidad. Un LLM entrenado con millones de documentos puede haber memorizado fragmentos de información personal. Un sistema RAG que indexa el corpus documental corporativo puede exponer datos que el usuario tiene permiso de acceder en contexto pero no de ver directamente. Un agente de Copilot Studio con acceso al calendario ejecutivo puede inferir información sensible de patrones de reuniones.

El privacy engineering es la disciplina que responde a esta tensión: no prohibir el uso de datos — que haría la IA inútil — sino diseñar sistemas de IA que maximizan la utilidad preservando la privacidad como propiedad técnica, no como declaración de intenciones. Para el CISO de 2026, el privacy engineering de IA es el complemento técnico de los marcos regulatorios analizados en la Fase 11 (LATAM) y del stack de gobernanza de la Fase 7.

DIMENSIÓN	SIN PRIVACY ENGINEERING	CON PRIVACY ENGINEERING
Datos de entrenamiento	El modelo puede memorizar y reproducir datos personales del corpus de entrenamiento (membership inference attack exitoso).	Differential Privacy en training: garantía matemática de que la contribución de ningún individuo es identificable en el modelo final.
Contexto del LLM en sesión	El LLM tiene acceso a todo el contexto de la sesión: emails anteriores, documentos abiertos, historial de conversación — puede combinarlos de formas no intuitivas.	Data Minimization: el contexto se construye solo con los datos estrictamente necesarios para la tarea. Purging automático del contexto entre sesiones.
Corpus RAG	El knowledge base RAG puede contener documentos de distintas clasificaciones. Una consulta puede recuperar documentos que el usuario puede acceder individualmente pero no debería ver combinados.	Segmentación de RAG por clasificación. Access control en vector database. Sensitivity labels que fluyen desde SharePoint/Purview al contexto del LLM.
Datos de entrenamiento fine-tuning	Si la empresa fine-tunea un modelo con datos propios (conversaciones de clientes, contratos), esos datos pueden ser extraíbles del modelo resultante.	Federated Learning y Differential Privacy para fine-tuning. AIBOM que documenta qué datos se usaron. Derecho al olvido: cómo eliminar un individuo del modelo.
Outputs del sistema	El LLM puede generar outputs que revelan PII de terceros, especialmente si procesó documentos con datos de múltiples personas.	PII detection en outputs (Microsoft Purview DLP en prompts y respuestas). Guardrails de output que sanitizan información personal antes de mostrarla al usuario.
Logs y auditoría	Los logs de interacciones con el LLM contienen el contenido completo de prompts y respuestas — fuente de PII que muchas organizaciones retienen indefinidamente.	Política de retención de logs de IA (Purview Data Lifecycle Management). Anonimización de logs para analytics. Solo retener metadatos (no contenido) para análisis de uso.

📋 Marco regulatorio que obliga el privacy engineering: EU AI Act Art. 10 (Datos de entrenamiento): sistemas de alto riesgo deben garantizar que los datos tienen la calidad y representatividad adecuada, y que se aplican medidas de privacidad apropiadas. GDPR Art. 25 (Privacy-by-Design): la privacidad debe incorporarse en el diseño del sistema desde el inicio, no añadirse después. Argentina Ley 25.326 Reforma 2025: tratamiento automatizado de datos personales requiere evaluaciones de impacto. El penalty máximo bajo GDPR: 4% revenue global o EUR 20M. El costo de privacidad-por-diseño es sistemáticamente menor que el costo de privacidad-por-remediación.

15.1 PRIVACY-BY-DESIGN APLICADO A SISTEMAS DE IA

Privacy-by-Design (PbD), formulado por Ann Cavoukian en los años 90 y elevado a estándar en GDPR Art. 25, establece 7 principios fundacionales. Su aplicación a sistemas de IA requiere una reinterpretación: los principios fueron diseñados para sistemas de información convencionales. La naturaleza no determinística, la capacidad de inferencia y la memorización de los LLMs crean desafíos que Cavoukian no anticipó. Esta sección adapta los 7 principios al contexto específico de LLMs, RAG, agentes y modelos de ML empresariales.

#	PRINCIPIO PbD	APLICACIÓN CLÁSICA	ADAPTACIÓN ESPECÍFICA PARA IA
1	Proactivo, no Reactivo — Preventivo, no Correctivo	Identificar y abordar riesgos de privacidad antes de que ocurran, no responder a violaciones después.	Para IA: el DPIA (Data Protection Impact Assessment) de IA debe realizarse antes de entrenar el modelo o indexar el corpus RAG, no tras el deployment. Threat model de privacidad: ¿qué inferencias indeseadas puede hacer el modelo? ¿qué datos puede memorizar? La brecha entre 'diseñado para' y 'puede hacer' es el espacio de riesgo no anticipado.
2	Privacidad como Configuración Predeterminada	El sistema más restrictivo de privacidad debe ser el comportamiento por defecto. Los usuarios deben optar por compartir más, no menos.	Para IA: Copilot con Zero Data Retention por defecto, no como opción opt-in. El contexto del LLM debe incluir el mínimo de datos por defecto — el usuario puede ampliar el contexto explícitamente. Los agentes de Copilot Studio deben tener herramientas deshabilitadas por defecto y habilitarse solo cuando el usuario las solicita explícitamente.
3	Privacidad Incorporada al Diseño	La privacidad no es un complemento sino un componente central de la arquitectura del sistema.	Para IA: la separación entre el corpus RAG y las interacciones de usuario no es una feature sino un requisito de diseño. La arquitectura de segmentación por clasificación de datos no se agrega después del deployment — se diseña en el pipeline de indexación. Differential Privacy en entrenamiento es una decisión de arquitectura, no un parche.
4	Funcionalidad Total — Suma Positiva, no Suma Cero	La privacidad y la funcionalidad no son mutuamente excluyentes. Es posible maximizar ambas.	Para IA: Federated Learning como caso emblemático — modelo entrenado sobre datos de múltiples organizaciones sin que ninguna comparta sus datos con las otras. Synthetic Data que preserva las propiedades estadísticas del dataset real sin exponer individuos reales. El mito de que privacidad = menor calidad del modelo es rebatido por la investigación: los modelos con DP muestran degradación modest cuando epsilon es calibrado correctamente.
5	Seguridad de Extremo a Extremo — Protección Durante Todo el Ciclo de Vida	Los datos deben estar protegidos desde su recolección hasta su eliminación.	Para IA: el ciclo de vida del dato en IA incluye etapas inexistentes en sistemas tradicionales: preprocesamiento para training, representación como embedding, almacenamiento en vector database, uso como contexto en inferencia, aparición en outputs. Privacy engineering debe cubrir cada etapa. Cuando un individuo ejerce su derecho al olvido bajo GDPR, ¿cómo se elimina su dato de un modelo ya entrenado? (Machine Unlearning — ver 15.3)
6	Visibilidad y Transparencia	El sistema debe ser transparente sobre cómo procesa datos. Los usuarios deben poder verificar que la privacidad es real, no declarativa.	Para IA: el AI Transparency Report (Fase 3 del proyecto) es la expresión institucional de este principio. A nivel técnico: model cards que documentan qué datos se usaron en entrenamiento, qué medidas de privacidad se aplicaron, qué evaluaciones de bias se realizaron. Para Copilot: el Audit Log de Microsoft Purview que permite verificar qué datos procesó el LLM en cada interacción.
7	Respeto por la Privacidad del Usuario — Centrado en el Usuario	El sistema debe respetar los intereses del usuario y ofrecer herramientas de control efectivo.	Para IA: el derecho de acceso bajo GDPR debe incluir la capacidad de saber qué datos propios procesó el LLM. El derecho de rectificación debe incluir la corrección de datos en el corpus RAG. El derecho al olvido debe incluir un mecanismo técnico de eliminación del modelo (Machine Unlearning). Ninguno de estos derechos tiene una implementación trivial en sistemas de IA — son el estado del arte de la investigación en 2025-2026.

15.2 TÉCNICAS DE PRIVACY PRESERVATION: DP, FEDERATED LEARNING, HE, SMPC

El privacy engineering de IA opera con un conjunto de técnicas que tienen fundamento matemático — no son políticas o declaraciones de intención, sino mecanismos técnicos que proveen garantías formales y cuantificables de privacidad. Esta sección documenta las cuatro técnicas fundamentales con su aplicabilidad concreta para el CISO con ecosistema Microsoft.

15.2.1 Differential Privacy (DP) — La Técnica con Mayor Adopción Enterprise

Differential Privacy es una definición matemática de privacidad propuesta por Cynthia Dwork (Microsoft Research) en 2006. Su garantía fundamental: el output de un algoritmo DP es prácticamente indistinguible independientemente de si un individuo específico estuvo o no en el dataset de entrenamiento. La privacidad está garantizada para cualquier atacante, con cualquier información auxiliar, incluso en el futuro.

COMPONENTE DP	DESCRIPCIÓN APLICADA A IA ENTERPRISE
Parámetro Epsilon (ε) — El presupuesto de privacidad	El parámetro epsilon cuantifica la privacidad: epsilon=0 es privacidad perfecta (modelo que no aprende nada). Epsilon grande significa menos privacidad. Valores típicos en producción enterprise: ε=1 (alta privacidad, degradación de utilidad del 5-10%), ε=8 (privacidad razonable, degradación menor al 2%), ε=14 (compliance con ISO/IEC 27559 y NIST SP 800-226, degradación mínima). Un estudio de 2026 en credit risk models mostró que ε entre 5.74 y 14.13 es compatible con GDPR Privacy-by-Design, ISO/IEC 27559, y NIST SP 800-226.
Implementación en Training (DP-SGD)	El algoritmo DP-SGD (Differentially Private Stochastic Gradient Descent) aplica DP durante el training: en cada paso de gradient descent, el gradiente de cada ejemplo se recorta a un norm máximo (clipping) y luego se añade ruido gaussiano calibrado para garantizar el presupuesto epsilon. TensorFlow Privacy (Google) y Opacus (PyTorch/Meta) son las librerías open-source estándar. Para modelos fine-tuned sobre Azure: el entrenamiento puede ejecutarse con Opacus integrado en el pipeline de Azure ML.
Implementación en Queries e Inferencia (Local DP)	En sistemas que no pueden aplicar DP en entrenamiento (modelos base propietarios), se aplica DP a nivel de queries y outputs: antes de reportar estadísticas agregadas de uso del sistema, se añade ruido calibrado. Los query results de analytics sobre logs del LLM se suministran con DP: el CISO puede saber el % de usuarios que usan Copilot para documentos financieros sin poder identificar a ningún usuario específico.
Trade-off Privacidad-Utilidad	DP introduce degradación en la calidad del modelo. El costo depende del tamaño del dataset (más datos = menor degradación por DP), del valor de epsilon elegido, y de la tarea. Regla práctica: para datasets enterprise con >100,000 ejemplos, ε=8 introduce degradación en accuracy de <2%. Para datasets pequeños (<10,000 ejemplos), la degradación puede ser significativa y requiere compensación con técnicas como transfer learning desde modelos pre-entrenados con DP.
Adopción en Ecosistema Microsoft	Microsoft fue el inventor de la teoría de Differential Privacy (Cynthia Dwork, MSR). Microsoft implementa DP en Windows Telemetry y en Azure Synapse Analytics para exportación de estadísticas. TensorFlow Privacy (desarrollado parcialmente en colaboración con Microsoft) soporta Azure ML. Azure Data Factory tiene capacidades de data masking basadas en principios de DP para pipelines de datos. Microsoft Presidio: herramienta open-source de anonimización PII que combina detection (NLP) con técnicas de sustitución configurables.

15.2.2 Federated Learning — Entrenar Modelos Sin Mover Datos

Federated Learning (FL) invierte el paradigma del machine learning tradicional: en lugar de traer los datos al modelo, lleva el modelo a los datos. Solo los updates del modelo — nunca los datos crudos — viajan a un servidor central. Propuesto por Google en 2017, es hoy la técnica de privacy preservation con mayor adopción enterprise, especialmente en sectores con restricciones regulatorias estrictas sobre movimiento de datos.

TIPO FL	ARQUITECTURA	CASO DE USO ENTERPRISE	EJEMPLO REAL 2025
Horizontal FL(Cross-Silo)	Múltiples organizaciones con mismas features pero distintos usuarios. Cada organización entrena localmente, comparte solo gradientes.	Bancos colaborando en modelo de detección de fraude sin compartir transacciones de clientes. Hospitales entrenando modelo diagnóstico sin compartir historias clínicas.	Zurich Insurance + Orange Telecom: modelo de predicción FL sobre datos de Orange sin acceso a ellos. Resultado: 30% mejora en predicciones vs. modelo individual.
Vertical FL	Organizaciones con distintas features pero los mismos usuarios. Combina features de distintas fuentes sin revelar cada fuente al otro.	Banco + retailer + telco sobre mismos clientes: el banco tiene historial crediticio, el retailer tiene patrones de compra, la telco tiene uso de datos. FL vertical sin que ninguno vea los datos del otro.	Credit scoring con datos alternativos: banco + empresa de telecomunicaciones entrenan modelo conjunto. El banco mejora predicción de default sin acceder a datos de telco.
Cross-Device FL	Modelo entrenado en miles/millones de dispositivos edge. Solo los updates del modelo suben al servidor.	Mejora de teclado predictivo (Google GBoard), personalización de modelos de voz, detección de intrusiones en endpoints.	Google Keyboard usa FL para personalización de predicción sin enviar texto del usuario a Google. Apple usa FL para Siri improvements. Relevante para modelos de endpoint security de M365.
FL + DP Combinado(Recomendado)	FL protege contra el servidor central que ve datos crudos. DP añadida sobre los gradientes de FL protege contra membership inference attacks sobre los gradients compartidos.	El estándar de facto para deployments enterprise con requisitos de compliance: FL + DP garantiza privacidad incluso si el servidor es comprometido o el atacante tiene acceso a los gradientes.	Estudio Nature Scientific Reports 2026: FL+DP para credit risk en escenario bancario real. DP-FL con ε=8.65 alineado con GDPR, ISO/IEC 27559, NIST SP 800-226. Degradación de accuracy: <3% vs. FL sin DP.

15.2.3 Homomorphic Encryption y SMPC — Computación sobre Datos Cifrados

TÉCNICA	CÓMO FUNCIONA Y GARANTÍA	ESTADO 2025-2026 Y APLICABILIDAD ENTERPRISE
Homomorphic Encryption (HE)	Permite realizar operaciones matemáticas sobre datos cifrados sin necesidad de descifrarlos. El resultado cifrado, al descifrarse, es igual al resultado que se habría obtenido sobre los datos en plaintext. Garantía: el servidor de ML nunca ve los datos en plaintext — ni durante la inferencia ni durante el entrenamiento. Esquemas: CKKS (para operaciones de punto flotante, más relevante para ML), BFV, BGWE.	2025: operacionalmente viable para inferencia sobre modelos pequeños. Para training, el overhead computacional es aún 10x-1000x mayor que sin HE. Microsoft SEAL (librería open-source de HE) es el estándar. Azure Confidential Computing integra enclaves hardware (Intel TDX) como alternativa más práctica a HE pura para cargas de trabajo enterprise. Aplicación más real 2025: inferencia sobre modelos de clasificación en contextos regulados (HIPAA) donde el servidor cloud no debe ver los datos del paciente.
Secure Multi-Party Computation (SMPC)	Permite que múltiples partes computen una función conjunta sobre sus inputs combinados sin revelar sus inputs individuales a ninguna otra parte. Ejemplo clásico: tres bancos computan el promedio de sus tasas de default sin que ninguno sepa las tasas individuales de los otros. PySyft (OpenMined) es la librería open-source de referencia para SMPC en ML.	2025: madurez creciente pero overhead significativo para modelos grandes. Viable para agregaciones estadísticas entre organizaciones (variante: Privacy Set Intersection para encontrar usuarios comunes entre dos bases de datos sin revelar cuáles son). Microsoft Research activo en esta área. Aplicación enterprise 2025: combinación de signals de threat intelligence entre organizaciones del mismo sector sin revelar sus incidentes individuales (fraud networks collaboration).
Confidential Computing (SGX/TDX)	No es privacy preservation en el sentido del ML sino un control complementario: el código y los datos que procesa se ejecutan en un enclave hardware verificable — ni el cloud provider ni el administrador del sistema pueden ver el contenido del enclave. Intel TDX (Trust Domain Extensions), AMD SEV-SNP.	Disponible en Azure hoy: Azure Confidential VMs con Intel TDX, Azure Confidential Containers. El 'attestation report' permite al tenant verificar que su modelo y sus datos se ejecutan en un enclave genuino sin backdoors del cloud provider. Para el CISO que no confía completamente en el cloud provider para datos ultra-sensibles: Confidential Computing es la opción más práctica y madura hoy (vs. HE que aún tiene overhead prohibitivo para LLMs).

15.3 ANONIMIZACIÓN, PSEUDONIMIZACIÓN Y SYNTHETIC DATA PARA IA

Las tres técnicas de esta sección abordan el mismo problema desde distintos ángulos: cómo usar datos que contienen información personal para entrenar modelos de IA sin comprometer la privacidad de los individuos en esos datos. La distinción entre ellas tiene implicaciones legales directas bajo GDPR y la Ley 25.326: solo la anonimización exitosa saca los datos del scope del derecho de privacidad — la pseudonimización y los datos sintéticos mal generados siguen siendo datos personales.

15.3.1 El Continuo Anonimización-Pseudonimización-Sintético

TÉCNICA	DEFINICIÓN Y GARANTÍA	LIMITACIONES PARA IA	STATUS REGULATORIO GDPR / Ley 25.326
Anonimización	Proceso irreversible de transformación de datos personales tal que la re-identificación del individuo sea imposible para cualquier atacante con cualquier información auxiliar. Técnicas: k-anonymity (cada individuo es indistinguible de al menos k-1 otros), l-diversity, t-closeness.	Para IA: la anonimización agresiva destruye el valor estadístico del dataset — especialmente para variables correlacionadas. Los modelos entrenados con datos fuertemente anonimizados muestran degradación severa. El problema de quasi-identifiers: variables aparentemente inocuas (código postal + género + fecha de nacimiento) permiten re-identificar al 87% de la población de EE.UU. (Sweeney 1997). En el contexto de LLMs, los embeddings de texto pueden actuar como quasi-identifiers.	FUERA DEL SCOPE: datos genuinamente anónimos no son datos personales bajo GDPR ni Ley 25.326. El CISO no necesita base legal para procesarlos. El reto: probar que la anonimización es genuina — los supervisores de protección de datos exigen evidencia técnica, no solo declaración.
Pseudonimización	Sustitución de identificadores directos (nombre, DNI, email) por pseudónimos (tokens, IDs sintéticos) manteniendo el resto de los atributos. El proceso es reversible con la clave de pseudonimización.	Para IA: es útil para reducir el riesgo de re-identificación pero no lo elimina — los quasi-identifiers siguen presentes. Un LLM puede re-identificar a un individuo a partir de la combinación de atributos incluso sin los identificadores directos. El 2025 study on enterprise prompt data encontró que 8.5% de prompts en Copilot/ChatGPT exponían datos sensibles incluyendo employee PII (26.8% del total de exposiciones).	DENTRO DEL SCOPE: es un dato personal bajo GDPR y Ley 25.326. Reduce el riesgo (GDPR Art. 89 permite excepciones para investigación con datos pseudonimizados) pero no elimina las obligaciones. El CISO debe mantener la tabla de correspondencia pseudónimo-identidad con controles estrictos.
Datos Sintéticos	Datos artificialmente generados que replican las propiedades estadísticas del dataset real sin contener registros reales de individuos. Generados con GANs (Generative Adversarial Networks), VAEs, o LLMs. Los datos sintéticos preservan las distribuciones estadísticas, correlaciones y patrones del dataset original.	Para IA: calidad variable según el método de generación. El riesgo de memorización: un generativo (GAN, LLM) puede memorizar registros del training dataset y reproducirlos. KAIST 2025: método que usa representaciones sintéticas en lugar de datos reales para FL, permitiendo colaboración entre hospitales y bancos sin sharing de datos reales.	STATUS COMPLEJO: depende del método de generación. Si el generativo fue entrenado con DP, los datos sintéticos heredan la garantía DP. Si no: los datos sintéticos pueden ser datos personales (si permiten re-identificación o si el generativo memorizó datos reales). El artículo 29 Working Party (WP29) no ha dado una posición definitiva. Tratar como datos personales hasta que se demuestre lo contrario.

15.3.2 Machine Unlearning — El Derecho al Olvido en Modelos de IA

El derecho al olvido (GDPR Art. 17, Ley 25.326 Art. 16) establece que un individuo puede solicitar la eliminación de sus datos. En sistemas de información tradicionales, esto significa borrar el registro de una base de datos. En un modelo de ML ya entrenado, el equivalente es técnicamente difícil: el modelo 'recordó' el dato durante el entrenamiento y ese aprendizaje está distribuido en millones de parámetros. Machine Unlearning es la disciplina que busca eliminar la influencia de un dato específico de un modelo ya entrenado sin reentrenarlo desde cero.

ENFOQUE	DESCRIPCIÓN TÉCNICA	VIABILIDAD 2025-2026
Reentrenamiento Exacto(Exact Unlearning)	Reentrenar el modelo completo desde cero excluyendo los datos del individuo que solicita el olvido. Garantía perfecta: el nuevo modelo nunca vio esos datos.	Solo viable cuando el dataset de training está controlado, el modelo tiene un costo de training razonable, y las solicitudes de olvido son infrecuentes. Para modelos fine-tuned sobre Azure ML: viable si el dataset de fine-tuning está documentado (AIBOM). Para modelos base (GPT-4o, Claude): imposible — el CISO no tiene acceso al training del proveedor.
Approximate Unlearning(Newton Step)	Actualizar los parámetros del modelo con un gradiente diseñado para deshacer el aprendizaje de los datos específicos, sin reentrenar desde cero. Técnicas: gradient ascent sobre los datos a olvidar, influence function-based unlearning.	Estado del arte 2025: funciona razonablemente bien para modelos pequeños y datos claramente memoritzados. Para LLMs de escala masiva: la investigación está activa (Apple, Google, Microsoft Research) pero no hay producción estable aún. El CISO debe documentar que para modelos base de proveedores, el derecho al olvido técnico no es actualmente realizable — esto tiene implicaciones para la base legal del training.
Síntesis de Política(Practical Compliance)	En ausencia de unlearning técnico viable, política de compliance: (1) No usar datos personales identificables para training sin base legal sólida. (2) Usar datos anónimos o sintéticos para training. (3) Para fine-tuning con datos propios: mantener AIBOM, diseñar el pipeline para permitir reentrenamiento selectivo. (4) Transparencia con los titulares: si el unlearning exacto no es posible, informar y ofrecer alternativas.	Recomendado como postura práctica para el CISO hoy (2026). La política combina: base legal sólida para training (legítimo interés o consentimiento), minimización de datos personales en training (preferir datos sintéticos), AIBOM que documenta qué datos se usaron, y proceso de evaluación de solicitudes de olvido caso a caso.

🔑 Herramienta práctica: Microsoft Presidio: Microsoft Presidio es una herramienta open-source (Apache 2.0) para detección y anonimización de PII en texto e imágenes. Usa NLP (spaCy) para reconocimiento de entidades (nombres, DNI, emails, números de tarjeta, coordenadas GPS, etc.) y permite elegir el tipo de sustitución: redacción, tokenización, enmascaramiento, cifrado, o síntesis de valores plausibles. Integrable en pipelines de Azure ML para pre-procesar datos antes de indexación en RAG o antes de fine-tuning. Disponible en PyPI: pip install presidio-analyzer presidio-anonymizer. Soporta español, inglés, alemán, italiano, portugués — relevante para corpus en Argentina y LATAM.

15.4 DATA MINIMIZATION EN CONTEXTOS LLM Y RAG

Data Minimization (GDPR Art. 5(1)(c)) establece que los datos personales deben ser adecuados, pertinentes y limitados a lo necesario para los fines para los que son procesados. En el contexto de LLMs y sistemas RAG, este principio tiene implicaciones técnicas concretas que van más allá de las políticas: determinan qué entra en el contexto del modelo, cuánto tiempo se retiene, y qué se puede inferir.

DIMENSIÓN DE MINIMIZACIÓN	RIESGO SIN MINIMIZACIÓN	CONTROL TÉCNICO DE MINIMIZACIÓN
Contexto del LLM (Context Window)	El contexto del LLM incluye el historial completo de la conversación, documentos relevantes recuperados por RAG, información de perfil del usuario. Sin minimización: el contexto puede incluir emails de terceros, datos salariales de compañeros, conversaciones pasadas irrelevantes para la consulta actual. La combinación de datos en el contexto permite al LLM hacer inferencias que ninguna fuente individual permitiría.	(1) RAG con re-ranking semántico: incluir solo los chunks con similarity score mayor al threshold configurado. (2) Purging automático del historial de conversación tras un número configurable de turnos o tras el cierre de sesión. (3) Filtros de contexto que eliminen PII del historial antes de incluirlo en el prompt del LLM. (4) Separación por clasificación: el contexto de un usuario de Nivel de Acceso 3 no incluye automáticamente documentos de Nivel 4 aunque esté en el contexto de la sesión.
Corpus RAG — Indexación	El corpus RAG indexa todo lo que se le indica: si SharePoint tiene 10 años de emails corporativos, el RAG puede recuperar emails de una persona que ya salió de la empresa, datos de proyectos cancelados, información de clientes de contratos ya terminados.	(1) Políticas de retención para el corpus RAG que repliquen las políticas de retención del dato original (Purview Data Lifecycle Management). (2) Exclusión de categorías de datos del corpus: datos de RRHH, datos de clientes de contratos cerrados, información personal de emails personales. (3) Revisión de permisos de SharePoint antes de indexación: el RAG no debe indexar contenido al que el usuario no debería acceder directamente.
Logs de Interacciones con el LLM	Los logs de conversaciones con Copilot/LLM contienen el contenido completo de prompts y respuestas — incluida la PII que el usuario ingresó o recibió. Sin política de retención, se acumulan indefinidamente. El log es una fuente de PII con alto riesgo de re-identificación.	(1) Retención de logs de interacciones IA: máximo 90 días para logs completos (contenido), indefinido para metadatos (timestamp, user, tokens usados). (2) Anonimización de logs antes de transferir a analytics: sustitución de nombres y datos identificables con tokens. (3) Separación entre logs de seguridad (auditables, con contenido) y logs de uso/analytics (anonimizados). (4) Purview Data Lifecycle Management: políticas automáticas de borrado de logs de Copilot según configuración.
Respuestas del LLM — Output PII	El LLM puede incluir PII de terceros en sus respuestas: nombres de empleados en documentos que resume, datos salariales en tablas que analiza, información de clientes en emails que procesa.	(1) Purview DLP en outputs de Copilot: política que detecta PII en respuestas del LLM y la redacta antes de mostrar al usuario. (2) Sensitivity labels: si el documento fuente tiene label Confidential, la respuesta del LLM que incluye su contenido hereda la clasificación. (3) Guardrails de output específicos para PII: Microsoft Azure AI Content Safety con categorías de PII configuradas.
Embeddings en Vector Database	Los embeddings de texto preservan información semántica del texto original. Ataques de embedding inversion pueden reconstruir texto aproximado del original desde el embedding — especialmente para textos cortos como nombres, emails, o datos de tarjetas.	(1) Access control en la vector database (Azure AI Search): solo los roles con acceso al documento original pueden recuperar sus embeddings. (2) No indexar datos de alta sensibilidad (credenciales, datos médicos, datos financieros personales) directamente como texto en el RAG — usar referencias a sistemas seguros en su lugar. (3) Encriptación at-rest de los embeddings en Azure AI Search.

15.5 MICROSOFT PURVIEW: EL STACK DE PRIVACIDAD PARA IA EN M365

Microsoft Purview es la plataforma de seguridad, gobernanza y compliance de datos de Microsoft — y desde 2024-2025 se ha transformado en la herramienta central para gestionar la privacidad de datos en el contexto de Copilot, agentes y aplicaciones de IA enterprise. Para el CISO con 20,000+ licencias M365 E5, Purview no es una herramienta adicional: está incluida en la licencia y es el mecanismo primario de control de privacidad de IA disponible hoy.

15.5.1 Mapa de Capacidades Purview para Privacidad de IA

CAPACIDAD PURVIEW	QUÉ HACE	RELEVANCIA PARA PRIVACIDAD DE IA	DISPONIBILIDAD
Data Security Posture Management for AI (DSPM for AI)	Visibility central sobre qué aplicaciones de IA usa la organización (M365 Copilot, ChatGPT, Gemini, etc.), qué datos sensibles fluyen hacia ellas, y cuáles son los riesgos de oversharing. Dashboard con recomendaciones y políticas one-click.	El 'front door' de la privacidad de IA: sin visibilidad no hay gestión. Identifica sitios SharePoint con datos sobre-compartidos que el Copilot puede amplificar. Detecta prompts que incluyen PII siendo enviados a apps de IA no aprobadas.	GA. Disponible en Purview portal. Incluido con M365 E5.
Sensitivity Labels (Microsoft Information Protection)	Etiquetas de clasificación aplicadas a documentos, emails, y contenido M365 que controlan qué puede hacer el LLM con el contenido etiquetado. Permite configurar qué labels impiden que Copilot resuma o procese el contenido.	El mecanismo central de Data Minimization para RAG: documentos con labels de alta sensibilidad no son indexados por RAG o Copilot sin autorización explícita. Los labels fluyen con el dato: un documento Confidential mantiene ese label aunque Copilot lo procese.	GA. Requiere configuración de labels y políticas.
DLP para Copilot (Data Loss Prevention)	Políticas DLP aplicadas específicamente a prompts y respuestas de Copilot: detectan PII, credenciales, datos financieros en los prompts enviados por los usuarios y en las respuestas generadas por el LLM.	Protección del output del LLM: si el LLM genera una respuesta con PII de un empleado, la política DLP puede redactarla antes de mostrarla al usuario. Prevención de exfiltración: bloquea prompts que intentan sacar datos confidenciales vía Copilot.	GA para M365 Copilot. En preview para algunos AI apps de terceros.
Purview Audit (Audit Log de Interacciones IA)	Registro auditado de todas las interacciones de usuarios con Copilot: qué prompts enviaron, qué respuestas recibieron, qué documentos procesó el LLM. El audit log es inmutable y searchable.	Accountability y derecho de acceso GDPR: el titular puede preguntar qué datos suyos procesó el LLM. La organización puede auditar qué empleados están enviando PII a Copilot. Evidencia forense en caso de incidente de privacidad involucrando IA.	GA. Requiere habilitación del audit log de Copilot.
Insider Risk Management for AI	Detecta patrones de comportamiento de usuarios con Copilot que indican posible riesgo de insider threat: búsquedas masivas antes de salir de la empresa, consultas sobre documentos de proyectos no asignados, extracción de datos financieros.	Complementa la Data Minimization: identifica cuándo un usuario está usando Copilot para acceder a más datos de los que su función justifica. Genera alertas para investigación, no acciones automáticas.	GA. Requiere licencia M365 E5 Compliance.
Compliance Manager — Templates de Regulación IA	Templates pre-configurados para evaluar el estado de compliance con GDPR, EU AI Act, ISO 42001, NIST 2 AI, y otras regulaciones. Genera assessment automático y acciones recomendadas.	Para el CISO que necesita documentar compliance GDPR Art. 25 (PbD) y Art. 35 (DPIA) en relación a sistemas de IA: Compliance Manager provee el framework y evidencia de controles implementados.	GA. Templates de EU AI Act, GDPR disponibles.
Data Lifecycle Management	Políticas automáticas de retención y eliminación de contenido M365, incluyendo logs de Copilot y documentos del corpus RAG. Define cuánto tiempo se retienen los prompts y respuestas de Copilot.	Implementación técnica de la Data Minimization temporal: los logs de Copilot se eliminan automáticamente según la política configurada. Derecho al olvido: la eliminación de contenido en SharePoint propaga al corpus RAG en el siguiente ciclo de indexación.	GA. Requiere configuración de políticas de retención específicas para AI logs.
DSPM for AI — Data Risk Assessments	Escaneo semanal automático de los 100 SharePoint sites más usados para identificar datos sobre-compartidos que podrían ser amplificados por Copilot: documentos sin sensitivity label accesibles a toda la organización.	Prevención proactiva del Copilot Oversharing Problem: identifica antes de que el CISO lo descubra por un incidente cuáles son los documentos que Copilot está usando y que no deberían estar disponibles tan ampliamente.	GA. Escaneo automático + assessments manuales configurables.

⚠️ El Copilot Oversharing Problem: Un estudio 2025 de enterprise prompt data encontró que el 8.5% de los prompts enviados a Copilot y ChatGPT riesgaban exponer datos sensibles: customer info (45.8%), employee PII (26.8%), legal and financial data (14.9%), security details (6.9%). Microsoft Purview DSPM for AI detecta oversharing en SharePoint — pero no controla lo que el LLM infiere combinando datos de múltiples fuentes a las que el usuario tiene acceso legítimo individualmente. Esto es el límite de Purview: controla acceso, no inferencia semántica. Herramientas complementarias como Knostic o guardrails de output son necesarias para el gap de inferencia.

15.6 DPIA PARA SISTEMAS DE IA: METODOLOGÍA Y CASOS PRÁCTICOS

El DPIA (Data Protection Impact Assessment) o Evaluación de Impacto en la Protección de Datos es obligatorio bajo GDPR Art. 35 cuando el tratamiento de datos 'puede suponer un alto riesgo para los derechos y libertades de las personas físicas'. Los sistemas de IA son candidatos naturales al DPIA: combinan procesamiento automatizado de datos a escala, decisiones que afectan a las personas, y riesgos de sesgos y discriminación que no existen en sistemas convencionales. La Reforma 2025 de la Ley 25.326 argentina introduce un requisito equivalente para tratamientos automatizados.

15.6.1 Cuándo es Obligatorio el DPIA para Sistemas de IA

CRITERIO DE OBLIGATORIEDAD (GDPR Art. 35)	SISTEMA DE IA QUE LO ACTIVA	EJEMPLO EN CONTEXTO M365
Evaluación o puntuación sistemática de personas (profiling)	Cualquier sistema de IA que score, clasifique, o perfile individuos basándose en sus datos.	Un agente de Copilot Studio que analiza el rendimiento de empleados basándose en datos de Microsoft Viva Insights (reuniones, emails, actividad Teams) para apoyar decisiones de RRHH.
Decisiones automatizadas con efectos jurídicos o significativos	Sistemas donde la IA toma o apoya decisiones que afectan material o legalmente a personas.	Un sistema que usa ML para scoring crediticio de clientes (si la empresa es financiera), o para priorización de candidatos en procesos de selección.
Monitoreo sistemático	Sistemas de vigilancia o monitoreo sistemático de personas en áreas accesibles al público o en el workplace.	Microsoft Viva Insights con análisis de comportamiento de empleados. Insider Risk Management que monitorea actividad de usuarios en M365.
Datos sensibles a escala	Procesamiento a gran escala de categorías especiales de datos: salud, biometría, afiliación política, religión, orientación sexual.	Un LLM que procesa registros médicos de empleados (aseguradora de salud), o datos de afiliación sindical.
Datos de personas vulnerables	Tratamiento de datos de menores, pacientes, personas bajo custodia.	Cualquier sistema de IA que procesa datos de menores en contextos educativos o de salud.
Transferencias internacionales de datos de alto riesgo	Datos que se transfieren fuera del EEE (o Argentina) a países sin nivel adecuado de protección para training de modelos.	Uso de APIs de LLMs con servidores fuera de la UE/Argentina para procesar datos de empleados o clientes locales, sin Standard Contractual Clauses adecuadas.

15.6.2 El Proceso DPIA para Sistemas de IA — 8 Pasos

#	PASO	CONTENIDO ESPECÍFICO PARA IA	OUTPUT Y EVIDENCIA
1	Descripción del sistema de IA y del tratamiento	Describir: arquitectura del sistema (LLM base, RAG, agentes), fuentes de datos usadas (SharePoint, Exchange, Dataverse), capacidad de inferencia (qué puede deducir el sistema además de lo que se le da explícitamente), destinatarios de los outputs, retención de datos y logs.	Ficha técnica del sistema de IA. Flowchart de datos. Inventario de fuentes de datos y su clasificación.
2	Evaluación de necesidad y proporcionalidad	¿Es la IA necesaria para el fin declarado? ¿Podría el fin lograrse con menos datos o con técnicas menos intrusivas? ¿Los datos usados son los mínimos necesarios? Para sistemas de RRHH: ¿el análisis de comportamiento de empleados es proporcional a la necesidad de gestión de rendimiento?	Justificación documentada de la base legal (interés legítimo, consentimiento, contrato). Análisis de alternativas consideradas. Decisión de proporcionalidad firmada.
3	Identificación de riesgos de privacidad específicos de IA	Riesgos específicos de IA que no existen en sistemas convencionales: (1) Memorización de datos personales en el modelo, (2) Inferencias no intencionadas (el modelo deduce orientación sexual de patrones de comportamiento), (3) Sesgos algorítmicos que discriminan grupos protegidos, (4) Reidentificación de datos pseudonimizados, (5) Exfiltración de datos vía prompts adversariales, (6) Derecho al olvido técnicamente inviable en el modelo ya entrenado.	Risk register específico para IA. Probabilidad e impacto de cada riesgo. Riesgos residuales tras controles.
4	Evaluación de controles existentes	Documentar los controles implementados y su efectividad: Purview DLP en Copilot (¿bloquea efectivamente PII en outputs?), Sensitivity Labels (¿todos los documentos relevantes están etiquetados?), Audit Log (¿es completo y buscable?), Data Minimization en RAG (¿el corpus está limitado a datos necesarios?), controles de acceso.	Mapa de controles × riesgos. Gaps identificados entre riesgos y controles. Rating de efectividad de cada control.
5	Plan de mitigación de riesgos residuales	Para cada riesgo sin cobertura de control adecuada: diseñar e implementar controles adicionales. Para el riesgo de memorización en modelos propietarios: plan de uso de DP en fine-tuning. Para sesgo: auditoría con Azure Responsible AI Dashboard y Fairlearn antes del deployment. Para Machine Unlearning: proceso de evaluación caso a caso.	Plan de mitigación con acciones, responsables y fechas. Compromiso de implementación previo al deployment o en plazo definido.
6	Consulta con DPO (Data Protection Officer)	El DPO debe revisar el DPIA antes de que el sistema entre en producción. Si los riesgos residuales son altos, puede ser necesaria consulta previa con la autoridad supervisora (AEPD en España, AGPD en Argentina para Ley 25.326). El DPO tiene derecho a disentir y el responsable debe documentar por qué no siguió su consejo.	Opinion del DPO firmada. Si hay discrepancia: documentación de la justificación del responsable. Si aplica: evidencia de consulta previa con autoridad supervisora.
7	Revisión continua — El DPIA es un documento vivo	El DPIA debe revisarse cuando: el sistema cambia significativamente (nuevo modelo base, nuevas fuentes de datos, nuevas capacidades de agente), cuando ocurre un incidente de privacidad relacionado con el sistema, y periódicamente (recomendado: anualmente para sistemas de alto riesgo).	Calendario de revisión periódica. Log de cambios al sistema con indicación de si requieren revisión del DPIA. Proceso de re-DPIA para cambios significativos.
8	Documentación y registro	El DPIA debe estar documentado y disponible para la autoridad supervisora cuando lo requiera. No es obligatorio publicarlo, pero sí tenerlo disponible. Purview Compliance Manager provee templates de DPIA y gestión del ciclo de vida del documento.	DPIA firmado y versionado. Accesible en el registro de DPIAs de la organización. Historial de revisiones. Disponible para auditoría regulatoria.

15.7 PLAN DE PRIVACIDAD DE IA PARA CISO CON M365/COPILOT (2026-2027)

El plan que sigue traduce los conceptos de las secciones anteriores en acciones concretas, secuenciadas y con criterios de éxito medibles para el CISO que gestiona 20,000+ licencias M365 E5 con Copilot activo. Se estructura en tres horizontes: los primeros 90 días (baseline y controles urgentes), el primer año (programa maduro), y 2027 (madurez avanzada).

15.7.1 Los Primeros 90 Días — Baseline y Controles Urgentes

	ACCIÓN	DETALLE DE EJECUCIÓN	CRITERIO DE ÉXITO
1	Activar DSPM for AI y ejecutar Data Risk Assessment inicial	Habilitar Microsoft Purview DSPM for AI en el portal de Purview. Ejecutar el assessment de los 100 SharePoint sites más accedidos para identificar datos sobre-compartidos que Copilot puede amplificar. Revisar el AI Activity report: qué tipos de datos sensibles están fluyendo hacia Copilot y en qué volumen.	Mapa de riesgos de oversharing. Lista de sitios SharePoint con datos sobre-compartidos priorizados por volumen y sensibilidad. Baseline de PII en prompts de Copilot.
2	Completar el etiquetado MIP de documentos de alta sensibilidad	Auditar el estado de los Sensitivity Labels en M365: qué % de los documentos clasificados como Confidencial/Alta Confidencialidad tienen el label aplicado. Implementar auto-labeling para documentos sin label que contienen patrones de datos sensibles (Purview auto-classification). Los labels son el mecanismo central que impide que Copilot procese contenido que no debe.	Target: >90% de documentos con clasificación Confidential o superior tienen label aplicado. Cobertura de auto-labeling habilitada para patrones de PII principales (DNI, CUIL, datos financieros).
3	Implementar DLP en prompts y respuestas de Copilot	Configurar políticas DLP en Microsoft Purview para M365 Copilot: (1) Detectar y bloquear/alertar prompts que incluyen números de tarjeta, DNI, CUIL, contraseñas. (2) Detectar y redactar PII de empleados en respuestas de Copilot antes de mostrarlas. (3) Política para documentos con labels Highly Confidential: Copilot no puede resumirlos ni incluir su contenido en respuestas.	Políticas DLP activas para Copilot. Reporte mensual: N° de prompts bloqueados/alertados, tipos de PII detectados, N° de redacciones de output.
4	Ejecutar DPIA para los casos de uso Copilot de mayor riesgo	Identificar los 3-5 casos de uso de Copilot con mayor riesgo de privacidad: casos de RRHH (análisis de rendimiento, nómina), casos financieros (acceso a P&L, presupuesto), casos legales (contratos con PII de clientes). Ejecutar el proceso DPIA de 8 pasos para cada uno usando el template de Compliance Manager.	DPIAs completados para todos los casos de uso de alto riesgo. DPO ha revisado y firmado. Hallazgos documentados con plan de mitigación.
5	Configurar retención de logs de Copilot	Habilitar el Audit Log de Copilot en Purview (si no está habilitado). Configurar política de retención: logs completos (contenido de prompts/respuestas) retenidos máximo 90 días. Logs de metadatos (user, timestamp, tokens) retenidos hasta 1 año para analytics. Asegurarse de que la política de retención está documentada en el Registro de Actividades de Tratamiento (GDPR Art. 30).	Política de retención de logs de Copilot configurada y verificada. Documentación en el RAT (Registro de Actividades de Tratamiento). Comunicación al DPO de la política.
6	Inventario de sistemas de IA y evaluación de DPIA pendientes	Levantar el inventario completo de sistemas de IA en la organización: M365 Copilot, agentes de Copilot Studio, apps sobre Azure AI Foundry, herramientas de IA de terceros (ChatGPT Enterprise si existe, GitHub Copilot, etc.). Para cada sistema: ¿requiere DPIA? ¿fue realizado? ¿cuándo fue la última revisión?	Inventario de sistemas de IA con status de DPIA para cada uno. Backlog de DPIAs pendientes con priorización y fechas target.

15.7.2 Programa de Privacidad de IA Maduro — Año 1 y 2027

INICIATIVA	DESCRIPCIÓN Y ALCANCE	HERRAMIENTAS Y MÉTRICAS
Privacy-by-Design como gate de deployment de IA	Ningún sistema de IA (agente de Copilot Studio, app Azure AI Foundry, plugin Copilot) puede salir a producción sin un checklist de privacy review aprobado. El checklist incluye: DPIA completado si corresponde, Sensitivity Labels configurados, DLP policies configuradas, corpus RAG auditado, política de retención de logs definida.	Gate formal en el proceso de deployment de IA. Registro de aprobaciones. Responsable: DPO y CISO co-firman los deployments de alto riesgo. KPI: 100% de nuevos sistemas de IA con privacy review completado.
Auditoría anual de privacidad de IA	Revisión anual del estado del programa: re-ejecutar el Data Risk Assessment de DSPM for AI, revisar todos los DPIAs existentes, auditar el estado de los controles Purview, evaluar cambios regulatorios desde la última revisión (EU AI Act, reforma Ley 25.326, nuevas guías de autoridades supervisoras).	Purview DSPM for AI reports. Compliance Manager compliance score. Herramienta externa de auditoría si el volumen lo justifica. Output: Privacy Posture Report anual presentable al Board.
Capacitación en privacidad de IA para usuarios de Copilot	Los 20,000+ usuarios de Copilot no entienden instintivamente qué datos envían al LLM ni las implicaciones. Programa de capacitación: qué no poner en prompts de Copilot (PII de terceros, credenciales, datos de clientes), cómo usar la clasificación de documentos, qué hacer si Copilot genera output con datos de otra persona.	Microsoft Viva Learning para distribución de contenido. Módulo de 30 minutos con quiz. KPI: >80% de usuarios Copilot con capacitación completada en 12 meses. Reducción medible de prompts con PII detectados por DLP.
Implementación de Presidio para corpus RAG (2027)	Para organizaciones que desarrollan aplicaciones propias sobre Azure AI Foundry con corpus RAG propietario: implementar Microsoft Presidio en el pipeline de indexación para anonimizar PII antes de que el texto ingrese al vector database. Configurar para español y los tipos de PII relevantes: DNI, CUIL, CBU, nombres de personas identificables.	Azure ML pipeline con Presidio. KPI: 0% de PII identificable en embeddings del vector database. Auditoría trimestral de muestras del corpus RAG.
Proceso de ejercicio de derechos GDPR/25.326 para sistemas de IA	Definir cómo responde la organización cuando un individuo ejerce derechos sobre datos que pueden estar en sistemas de IA: derecho de acceso (qué datos del individuo están en el corpus RAG), derecho de rectificación (corregir un dato en el RAG), derecho al olvido (eliminar datos del corpus RAG y, donde sea posible, del modelo).	Proceso documentado con SLAs: acceso en 30 días, olvido en 30 días donde técnicamente posible (eliminación del corpus RAG es viable; Machine Unlearning del modelo base no lo es actualmente). Registro de solicitudes y respuestas. Escalar al DPO y asesoría legal los casos donde el Machine Unlearning exacto no es técnicamente posible.
Privacy Enhancing Technologies (PETs) para modelos propios (2027)	Para organizaciones que desarrollan o fine-tunean modelos propios: evaluar la implementación de Differential Privacy en el pipeline de fine-tuning usando Opacus (PyTorch) o TensorFlow Privacy. Target: epsilon calibrado a los requisitos de compliance (ε=8 para alineación con ISO/IEC 27559 y NIST SP 800-226). Evaluar Synthetic Data como alternativa para datasets que contienen PII de clientes.	Azure ML + Opacus/TF Privacy. Métricas: epsilon, degradación de accuracy vs. baseline, confirmación de compliance DP. KPI: fine-tuning de modelos propios con DP implementado. Synthetic dataset generator configurado para casos de uso identificados.

15.8 REFERENCIAS (R391–R420)

Privacidad de IA: Marcos Regulatorios y Principios:

R391. GDPR, Art. 25 (Privacy-by-Design y Privacy-by-Default), Art. 35 (Data Protection Impact Assessment), Art. 17 (Derecho al Olvido), Art. 5(1)(c) (Data Minimization). eur-lex.europa.eu. Marco legal primario que obliga el privacy engineering en sistemas de IA que procesan datos de ciudadanos de la UE.

R392. EU AI Act, Art. 10 (Data and Data Governance). Sistemas de IA de alto riesgo deben garantizar prácticas de gobernanza de datos adecuadas que incluyan medidas de privacidad apropiadas en los datos de entrenamiento, validación y testing.

R393. Cavoukian, Ann, 'Privacy by Design: The 7 Foundational Principles', Information & Privacy Commissioner of Ontario, 2009. Los 7 principios fundacionales que se convierten en requisito legal bajo GDPR Art. 25 y que esta Fase adapta al contexto de sistemas de IA.

R394. Secure Privacy, 'Compliance Challenges at the Intersection between AI & GDPR in 2025', 2025. GDPR penalties reaching 4% global revenue or EUR 20M. DPIA obligatorio para sistemas de IA de alto riesgo. Privacy Shield y EU-U.S. Data Privacy Framework para transferencias internacionales. Data minimization y purpose limitation aplicados a IA.

R395. NIST SP 800-226, 'Guidelines for Evaluating Differential Privacy Guarantees', 2023. Guía técnica para evaluación de implementaciones de Differential Privacy. Referencia para epsilon values en contextos de compliance regulatorio.

R396. ISO/IEC 27559:2022, 'Privacy Enhancing Data De-identification Framework'. Marco de referencia para técnicas de de-identificación y privacidad mejorada. Referencia para compliance de DP con ε en rango 5.74-14.13.

Differential Privacy — Teoría y Aplicación Enterprise:

R397. Dwork, Cynthia (Microsoft Research), 'Differential Privacy', ICALP 2006. El artículo fundacional que define Differential Privacy y la garantía matemática de privacidad. Creado por la investigadora que luego co-lideró el programa de privacidad de Microsoft.

R398. Alation, 'Privacy-Preserving Machine Learning: Minimizing PII and PHI', agosto 2025. Técnicas comparadas: Differential Privacy, Homomorphic Encryption, Federated Learning, SMPC. TensorFlow Privacy, PySyft, FATE como frameworks enterprise. Entity recognition y automated PII detection a escala.

R399. Nature Scientific Reports, 'Privacy-preserving federated credit risk models: evaluating differential privacy and homomorphic encryption techniques', enero 2026. DP-FL con ε=8.65: alineado con GDPR Privacy-by-Design, ISO/IEC 27559, NIST SP 800-226. Degradación de accuracy <3%. CKKS-based HE-FL: confidencialidad criptográfica pero overhead significativo.

R400. Opacus (Meta/PyTorch), 'Differential Privacy for Deep Learning', github.com/pytorch/opacus. Librería estándar para DP-SGD en PyTorch. Integrable en pipelines Azure ML. Soporte para epsilon accounting con Rényi Differential Privacy.

R401. TensorFlow Privacy (Google), 'TF Privacy: Machine Learning with Differential Privacy', 2025. Extensiones DP para TensorFlow. Desarrollado en colaboración parcial con Microsoft Research. Compatible con Azure ML.

Federated Learning — Arquitectura y Casos de Uso:

R402. Introl.io, 'Federated Learning Infrastructure: Privacy-Preserving Enterprise AI Guide 2025', diciembre 2025. Mercado FL: $0.1B en 2025 → $1.6B en 2035 (27.3% CAGR). Large enterprises: 63.7% del mercado. Solo 5.2% de investigación en producción real. NVIDIA FLARE (enterprise), Flower (investigación), PySyft (privacidad máxima). Healthcare: 34% cuota de mercado FL.

R403. Dialzara, 'Federated Edge AI: The Complete 2025 Guide to Privacy-Preserving Distributed Intelligence', 2025. Zurich Insurance + Orange Telecom: 30% mejora en predicciones con FL sin sharing de datos. Vertical FL para credit scoring con datos telco. FedBPT para adaptar LLMs grandes con FL.

R404. World Journal of Advanced Research and Reviews, 'Federated learning for privacy-preserving data analytics', 2025 (26(01), 1220-1232). FL en mobile environments: GDPR/CCPA compliance. Ataques contra FL: model inversion, membership inference, Byzantine attacks. Byzantine-robust FL frameworks, blockchain-based verification.

R405. KAIST Research, 'Federated Learning with Synthetic Data Representations', 2025. Método que usa synthetic data representations en lugar de datos reales para FL. Hospitales y bancos entrenan modelos colaborativos sin compartir datos personales. Referencia citada en contexto de privacy-preserving AI por múltiples fuentes 2025.

R406. Refontelearning, 'Federated Learning for Privacy-Preserving AI: Building Trust in a Decentralized World', 2025. Secure aggregation + DP como defensa combinada. Governance, scalability y compliance: marcos legales para FL multi-organización. Roles emergentes: federated learning engineer, privacy engineer para FL.

Anonimización, Synthetic Data y Machine Unlearning:

R407. Sweeney, Latanya, 'Simple Demographics Often Identify People Uniquely', Carnegie Mellon University, 1997. El artículo clásico: código postal + género + fecha de nacimiento identifica al 87% de población de EE.UU. La base empírica para el concepto de quasi-identifiers y la dificultad de la anonimización real.

R408. Microsoft Presidio, 'PII Anonymization Library', github.com/microsoft/presidio. Open source (Apache 2.0). Detección de PII con NLP (spaCy) + anonymization. Soporta español, inglés, alemán, portugués. Integrable en Azure ML pipelines para pre-procesamiento de datos para RAG o fine-tuning.

R409. Article 29 Working Party (WP29), 'Opinion 05/2014 on Anonymisation Techniques', 2014. La guía oficial de los supervisores de protección de datos de la UE sobre anonimización: qué cuenta como genuinamente anónimo, cuándo la pseudonimización es insuficiente. La referencia legal que el CISO debe conocer para declarar que un dataset está fuera del scope de GDPR.

R410. Cao, Yinzhi et al., 'Machine Unlearning', IEEE S&P 2015. El artículo fundacional de Machine Unlearning. El estado del arte 2025: unlearning exacto (reentrenamiento) viable solo para modelos pequeños y datasets controlados. Approximate unlearning para LLMs: investigación activa en Apple, Google, Microsoft Research — sin producción estable disponible.

Microsoft Purview — Documentación Oficial y Análisis:

R411. Microsoft Learn, 'Microsoft Purview data security and compliance protections for Microsoft 365 Copilot and other generative AI apps', 2025. DSPM for AI, Sensitivity Labels para Copilot, DLP en prompts y respuestas, Audit Log de interacciones Copilot, Compliance Manager con templates EU AI Act, GDPR.

R412. Microsoft Learn, 'Data Security Posture Management for AI (classic)', 2025. learn.microsoft.com/en-us/purview/dspm-for-ai. Dashboard central DSPM: insights AI activity, ready-to-use policies, data risk assessments, compliance controls. Escaneo semanal automático de top 100 SharePoint sites.

R413. Microsoft Security Blog, 'New Microsoft Purview features help protect and govern your data in the era of AI', diciembre 2025. DSPM for AI, Data Security Investigations (AI-powered para investigar riesgos), Adaptive Protection, templates Compliance Manager para EU AI Act, ISO 42001, NIST 2 AI.

R414. BizTech Magazine, 'Microsoft Ignite 2025: How Microsoft Purview Drives Data Security in the AI Era', noviembre 2025. Data Security Investigations: primera solución AI-powered para investigar riesgos de datos/IA. Microsoft Agent 365: governance para AI agents (1.3 billion proyectados para 2028). Three dimensions: información, DLP, Insider Risk Management.

R415. Knostic, 'Why Microsoft Purview Needs Help Preventing Oversharing', junio 2025. 8.5% de prompts enterprise exponen datos sensibles: customer info (45.8%), employee PII (26.8%), legal/financial (14.9%), security (6.9%). Purview limita acceso pero no inferencia semántica. El gap de inferencia: el LLM puede combinar fuentes individuales inofensivas en outputs sensibles.

Privacy Engineering Operacional:

R416. Microsoft Learn, 'Use Microsoft Purview to manage data security and compliance for Microsoft Agent 365', 2025. DSPM for AI preview con AI observability page para agentes. Audit de interacciones agent-to-human, human-to-agent, agent-to-tools, agent-to-agent. Sensitivity labels y DLP para Agent 365.

R417. Microsoft Learn, 'Learn about Microsoft Purview', 2025. Purview como plataforma unificada: data security + governance + compliance. Data Security Posture Management, Information Protection, DLP, Insider Risk Management, Compliance Manager, Data Lifecycle Management. Pricing: Purview Suite (E3+) y pay-as-you-go para data estate.

R418. Microsoft Security Blog, 'Unifying Data Security and Governance for the AI Era: Microsoft Purview Innovations for Fabric Data', septiembre 2025. Purview Information Protection policies para Fabric items (GA). DLP para OneLake estructurado (GA). Integrated Information Protection + DLP + Insider Risk Management + DSPM para AI.

R419. Microsoft SDK Developer Blog, 'Data Security and Compliance for GenAI — Purview Developer SDK', 2025. DSPM for AI components: insights analytics, ready-to-use policies, data risk assessments, compliance controls. Data Classification, DLP, Lifecycle Management integrados. APIs para desarrolladores que construyen apps compliance-aware sobre Azure AI Foundry.

R420. Gobierno de Argentina, 'Proyecto de Reforma de la Ley 25.326 de Protección de Datos Personales', 2025 (en proceso legislativo). Introduce evaluaciones de impacto equivalentes al DPIA para tratamientos automatizados de datos personales incluyendo sistemas de IA. Fortalece derechos de acceso, rectificación y eliminación. Referencia para el CISO con operaciones en Argentina.