F16 - 16.0 INTRODUCCIÓN: EL FIN DEL BLACK BOX COMO NORMA ACEPTABLE

16.0 Introducción: El Fin del Black Box como Norma Aceptable

16.1 Taxonomía de la Explainabilidad: Tipos, Dimensiones y Audiencias

16.2 Técnicas XAI: SHAP, LIME, Mechanistic Interpretability y el Estado del Arte 2025-2026

16.3 Model Cards, System Cards y AI FactSheets: Documentación de Accountability

16.4 Fairness Algorítmica: Métricas, Trade-offs y Mitigación

16.5 Microsoft Responsible AI Dashboard: El Stack de XAI para Azure ML

16.6 EU AI Act y Explainabilidad: Obligaciones, Plazos y Penalidades

16.7 Plan de XAI para el CISO con M365/Copilot/Azure AI Foundry

16.8 Referencias (R421–R450)

16.0 INTRODUCCIÓN: EL FIN DEL BLACK BOX COMO NORMA ACEPTABLE

Durante décadas, el principio implícito del machine learning en producción fue: si el modelo funciona —si minimiza el error en el test set, maximiza el AUC, produce retornos en backtesting— no es necesario entender por qué funciona. El black box era un costo aceptable de la performance. Enero 2026 marca el fin formal de esa era: el EU AI Act —con penalidades de hasta 6% del revenue global— y el GDPR —'derecho a explicación' bajo Art. 22— han hecho que la opacidad algorítmica sea no solo éticamente cuestionable sino jurídicamente costosa.

En este contexto, Explainable AI (XAI) ha pasado de disciplina académica de nicho a requisito central del stack de IA enterprise. La evidencia es cuantitativa: organizaciones con XAI comprensivo reportan 31% de reducción en ciclos de debugging, 24% de reducción en incidentes de sesgo, 18% de mejora en trust metrics. Un banco español que implementó SHAP para explicar rechazos de crédito redujo disputas en un 30%. Goldman Sachs usa SHAP para credit scoring satisfaciendo simultáneamente GDPR Art. 22 y la Equal Credit Opportunity Act de EE.UU.

DIMENSIÓN	ERA BLACK BOX (pre-2024)	ERA XAI OBLIGATORIA (2025-2026)
Criterio de éxito del modelo	Accuracy, AUC, RMSE en test set. El 'why' es secundario o irrelevante.	Accuracy + Explainability + Fairness como criterios co-primarios. Un modelo preciso pero opaco puede ser rechazado en producción o sancionado por el regulador.
Responsabilidad cuando el modelo falla	Difusa: 'el modelo decidió'. Proveedor, data scientist y decisor final comparten la opacidad.	Clara y legal: EU AI Act asigna responsabilidad explícita al 'deployer'. El CISO necesita poder explicar qué decidió el modelo y por qué.
Audiencia de las explicaciones	Técnica: data scientists que debuggean el modelo.	Múltiple: reguladores (conformity assessment), usuarios afectados (derecho a explicación GDPR Art. 22), Board (governance), DPO (DPIA).
Timing de la explicación	Post-hoc: capa de explicación añadida después de que el modelo está en producción.	By-design: explainabilidad diseñada desde el inicio del pipeline. 'Explainability by design' como nuevo estándar de excelencia.
Trade-off con performance	Aceptado como inevitable: más explainabilidad = menos accuracy.	Cuestionado: modelos glass-box (EBM, GAMs) compiten en accuracy con black-boxes en muchos dominios. Mechanistic Interpretability mapea circuitos en LLMs sin sacrificar capacidad.
Postura regulatoria	Ninguna específica para IA. Reguladores financieros pedían explicaciones informales caso a caso.	EU AI Act Art. 13-17: transparencia y documentación obligatorias para sistemas de alto riesgo. Penalty: hasta 6% revenue global (50% mayor que GDPR).

📈 Impacto empresarial cuantificado 2025: XAI comprensivo: 31% más rápido en debugging, 24% reducción incidentes de sesgo, 18% mejora trust metrics (EthicalXAI Platform, 2025). Banco español + SHAP para rechazos de crédito: 30% reducción en disputas. Goldman Sachs SHAP: credit scoring + GDPR Art. 22 + ECOA compliance simultáneos. EU AI Act penalty máxima: 6% revenue global — 50% más que GDPR (4%).

16.1 TAXONOMÍA DE LA EXPLAINABILIDAD: TIPOS, DIMENSIONES Y AUDIENCIAS

La explainabilidad no es un concepto monolítico sino un espacio multidimensional. La misma técnica puede ser apropiada para un data scientist e inútil para un cliente que recibió un rechazo crediticio. El CISO que diseña una estrategia XAI debe navegar este espacio: diferentes tipos, alcances, audiencias y requerimientos regulatorios.

DIMENSIÓN	CATEGORÍAS	IMPLICACIÓN PARA EL CISO
TIPO — ¿Cuándo se genera la explicación?	ANTE-HOC (Intrinsic): el modelo es inherentemente interpretable — no necesita capa adicional. Árboles de decisión, regresión logística, GAMs, EBM. POST-HOC: modelo black-box con capa de explicación añadida post-training. SHAP, LIME, Integrated Gradients.	Para modelos propios de bajo riesgo: evaluar si un EBM alcanza accuracy suficiente — si sí, preferirlo. Para alto riesgo: post-hoc con SHAP o InterpretML. Para LLMs propietarios (Copilot, GPT-4o): solo post-hoc es posible — y a nivel de fuentes, no de razonamiento interno.
ALCANCE — ¿Qué explica la explicación?	GLOBAL: por qué el modelo toma sus decisiones en general — cuáles features son más importantes en el conjunto total. Feature importance SHAP global, partial dependence plots. LOCAL: por qué el modelo tomó esta decisión específica sobre este individuo en este momento. SHAP waterfall plot, LIME para una predicción.	Para compliance regulatorio (EU AI Act Art. 13, GDPR Art. 22): las explicaciones locales son las obligatorias — el individuo tiene derecho a saber por qué se tomó una decisión sobre él específicamente. Las globales son útiles para auditores y Board. Ambas se necesitan.
AUDIENCIA — ¿Para quién es la explicación?	TÉCNICA: data scientists, auditores. Pueden consumir SHAP values, feature importance plots, error cohorts. EJECUTIVA: CISO, DPO, Board. Necesitan scorecards y resúmenes de riesgo. USUARIO FINAL: el individuo afectado. Necesita lenguaje natural, simple, accionable. REGULADORA: autoridad supervisora. Necesita documentación técnica y Model Cards.	El error más común en XAI enterprise: generar explicaciones técnicas excelentes para el data scientist y olvidar al usuario final y al regulador. El CISO debe asegurar que el pipeline cubre las 4 audiencias — con formatos diferentes para cada una.
FIDELIDAD — ¿Qué tan bien refleja el modelo real?	ALTA: la explicación refleja con precisión el razonamiento real del modelo. Difícil en redes neuronales profundas y transformers. BAJA: aproximación simplificada que puede ser misleading. El riesgo: una explicación de baja fidelidad genera confianza falsa (automation bias).	El EDPS (European Data Protection Supervisor) advierte: explicaciones post-hoc de baja fidelidad pueden generar 'automation bias' — usuarios aceptan la decisión del modelo sin cuestionamiento crítico porque recibieron una explicación aparentemente razonada. La evaluación de fidelidad es parte del proceso de validación XAI.

16.2 TÉCNICAS XAI: SHAP, LIME, MECHANISTIC INTERPRETABILITY Y EL ESTADO DEL ARTE 2025-2026

El ecosistema de técnicas XAI ha madurado significativamente. SHAP y LIME dominan la adopción enterprise. La frontera del campo está siendo redefinida por Mechanistic Interpretability — que busca entender los 'circuitos' internos de las redes neuronales. Un breakthrough en 2025 con Sparse Autoencoders (SAEs) permitió mapear con un detalle sin precedentes qué features activan qué neuronas en LLMs, con implicaciones directas para la seguridad.

TÉCNICA	FUNDAMENTO	FORTALEZAS / LIMITACIONES	MEJOR PARA	ADOPCIÓN 2025
SHAP (SHapley Additive exPlanations)	Shapley values de teoría de juegos cooperativos. La contribución marginal promedio de cada feature, promediada sobre todas las coaliciones posibles. Garantías: eficiencia, simetría, dummy, aditividad.	+ Fundamento matemático riguroso. + Global Y local desde el mismo framework. + Consistencia garantizada. – Costoso computacionalmente para modelos grandes (mitigado con TreeSHAP). – Solo aproximaciones para LLMs masivos.	Modelos estructurados (XGBoost, LightGBM, Random Forest). Sectores financieros con exigencia de auditoría. Credit scoring + GDPR Art. 22.	Goldman Sachs credit scoring. JPMorgan ECOA compliance. Estándar de facto para ML estructurado. pip install shap. Integrado en InterpretML + Azure ML.
LIME (Local Interpretable Model-agnostic Explanations)	Perturbación local: genera variantes sintéticas del input, observa cambios en output, ajusta modelo lineal local ponderado por proximidad. El modelo lineal local es la explicación.	+ Model-agnostic (cualquier black-box). + Explicaciones locales intuitivas (60% influido por X, 25% por Y). – Inestabilidad: inputs similares pueden generar explicaciones diferentes si hay fronteras de decisión complejas. – Sin garantía matemática de fidelidad.	Explicaciones individuales para usuarios finales (rechazos de crédito). Modelos de texto e imágenes. Prototyping rápido.	PayPal fraud detection. BBVA Mercury library. Interfaz de explicación customer-facing. pip install lime. Integrado en InterpretML.
Integrated Gradients	Para modelos diferenciables (redes neuronales): integra los gradientes del output respecto al input desde un baseline (vacío) hasta el input real. Resultado: atribución por feature o token.	+ Exacto matemáticamente para modelos diferenciables. + Satisface completeness (suma = output - baseline). + Excelente para texto e imágenes. – Requiere acceso a gradientes (white-box). – Para GPT-4o/Copilot: no disponible (API sin gradientes).	LLMs propios en Azure AI Foundry con acceso a gradientes. Computer vision (Google DeepMind eye disease: saliency maps sobre retinal imaging).	PyTorch Captum. torch.autograd. Relevante para modelos propios Azure AI Foundry con acceso completo.
Mechanistic Interpretability (SAEs)	Sparse Autoencoders aprenden representaciones dispersas de las activaciones neuronales. Identifican qué 'features' conceptuales activan qué neuronas. Breakthrough 2025: mapping de miles de features en transformers.	+ Única técnica que busca entender el razonamiento real del modelo, no aproximarlo. + Implicaciones de seguridad: identificar circuitos que amplifican sesgos o responden a prompts adversariales. – Investigación, no producción estable para la mayoría. – Requiere acceso a activaciones internas.	Organizaciones con LLMs propios en Azure AI Foundry. Safety research. Comprensión de comportamientos emergentes.	Anthropic: SAEs para Claude 3 Sonnet ('Scaling Monosemanticity', 2024). Google Gemma Scope (open release 2025). Microsoft Research: investigación activa.
EBM (Explainable Boosting Machine)	Modelo glass-box: GAMs con interacciones de pares detectadas automáticamente. Cada feature tiene una shape function visualizable directamente. No requiere post-hoc.	+ Accuracy comparable a gradient boosting en muchos datasets estructurados. + Completamente interpretable sin capa adicional. + Auditable directamente por el regulador. – No útil para texto/imágenes sin feature engineering. – Alta dimensionalidad penaliza más.	Casos donde hay opción de elegir el modelo. Sectores altamente regulados donde el regulador audita la función directamente. Healthcare, credit, HR scoring.	Microsoft InterpretML: librería flagship para EBMs. pip install interpret. Integrado en Responsible AI Dashboard (Azure ML). Recomendado en MS Responsible AI Standard v2.

🔬 Mechanistic Interpretability — El Salto Cualitativo de 2025: Las técnicas post-hoc (SHAP, LIME) explican los inputs y outputs de los modelos. Mechanistic Interpretability busca entender los circuitos internos. Breakthrough 2025 con SAEs: Anthropic mapeó miles de features conceptuales en Claude 3 Sonnet — neuronas que responden a conceptos como 'código malicioso', 'razonamiento legal', 'tono emocional'. Google publicó Gemma Scope (open release) para investigación externa. Para el CISO: si podemos identificar los circuitos que amplifican sesgos o que responden a prompts adversariales, podemos diseñar guardrails más precisos — conectando XAI con el red teaming de la Fase 13.

16.3 MODEL CARDS, SYSTEM CARDS Y AI FACTSHEETS: DOCUMENTACIÓN DE ACCOUNTABILITY

Los Model Cards son documentos estructurados que describen la función, capacidades, limitaciones y consideraciones éticas de un sistema de IA. Propuestos por Google en 2019, son el estándar de facto de documentación de accountability. El EU AI Act los hace obligatorios bajo Technical Documentation (Art. 11 y 17) para sistemas de alto riesgo. Para LLMs de uso general: forman parte de las obligaciones de transparencia GPAI bajo el EU AI Act.

TIPO DE DOCUMENTO	CONTENIDO Y PROPÓSITO	OBLIGATORIEDAD Y ADOPCIÓN 2025-2026
Model Card (Google, 2019)	Para modelos individuales de ML. Secciones estándar: (1) Model Details (arquitectura, training data, parámetros), (2) Intended Use (usos previstos y usos inapropiados explícitamente documentados), (3) Factors (grupos demográficos, condiciones ambientales), (4) Metrics (métricas y su justificación), (5) Evaluation Data, (6) Training Data, (7) Quantitative Analyses (resultados desagregados por grupos), (8) Ethical Considerations, (9) Caveats and Recommendations.	EU AI Act Art. 11/17: Technical Documentation incluye todos los elementos del Model Card más gestión de riesgos. GPAI Model Cards: OpenAI, Anthropic, Google, Microsoft los publican obligatoriamente. Código: pip install model-card-toolkit.
System Card (OpenAI, 2023)	Para sistemas completos, no solo el modelo base. Documenta el sistema tal como se deploya, incluyendo guardrails y filtros de seguridad añadidos. Secciones: Background, Deployment context, Safety measures (RLHF, Constitutional AI), Risk evaluations (red teaming results — conecta con Fase 13), Limitations, Usage policies. OpenAI publica System Cards para GPT-4o, GPT-4 Vision, Sora.	No es requisito legal formal pero es expectativa del mercado enterprise. Para el CISO que evalúa proveedores: el System Card es el documento de accountability del proveedor. Los 16 proveedores del proyecto fueron evaluados en Fase 3 — el System Card es evidencia directa de su postura de transparencia.
AI FactSheet (IBM, 2019)	Alternativa de IBM al Model Card. Mayor énfasis en la supply chain del sistema de IA: quién entrenó el modelo, con qué datos, en qué infraestructura, qué certificaciones tiene. Comparable al AIBOM (AI Bill of Materials) de la Fase 15. Incluye información sobre el proveedor más allá del modelo técnico.	IBM watsonx.governance: AI FactSheets integradas nativamente en el ciclo de vida de modelos. Para el CISO que evalúa sistemas de proveedores: el AI FactSheet es la herramienta de due diligence técnica (complementa el análisis contractual y ético de las Fases 5-6).
Responsible AI Scorecard (Azure ML)	Herramienta integrada en Azure ML que genera automáticamente un scorecard de evaluación responsable. Incluye: Error Analysis (cohorts donde el modelo falla), Fairness Assessment (Fairlearn), Interpretability (InterpretML/SHAP), Counterfactual Analysis (DiCE), Causal Analysis (EconML). Exportable como PDF para stakeholders técnicos y no técnicos.	GA en Azure ML (2025). Genera automáticamente la documentación de accountability para modelos propios. El CISO con modelos en Azure AI Foundry puede usar el Scorecard como evidencia para la Technical Documentation del EU AI Act.
Conformity Assessment Documentation (EU AI Act Art. 43-46)	Para sistemas de alto riesgo: documentación formal que demuestra cumplimiento con el Reglamento. Incluye: descripción del sistema, sistema de gestión de riesgos (Art. 9), datos de entrenamiento (Art. 10), documentación técnica (Art. 11), logging (Art. 12), transparencia (Art. 13), supervisión humana (Art. 14), accuracy (Art. 15). Self-assessment para la mayoría; third-party assessment obligatorio para los más críticos.	Aplicable desde agosto 2026 para sistemas de alto riesgo ya desplegados. El CISO debe identificar cuáles sistemas internos caen en categorías de alto riesgo y preparar la documentación. El Model Card y el Responsible AI Scorecard son punto de partida.

16.4 FAIRNESS ALGORÍTMICA: MÉTRICAS, TRADE-OFFS Y MITIGACIÓN

Fairness algorítmica es el complemento ético indispensable de la explainabilidad. Una explicación puede ser perfectamente clara y al mismo tiempo revelar que el modelo discrimina sistemáticamente a un grupo protegido. El CISO debe entender tanto las métricas como el trade-off fundamental: no existe una métrica de fairness única que sea satisfecha simultáneamente cuando las tasas base entre grupos difieren (Teorema de Chouldechova/Kleinberg, 2017). Elegir qué definición aplicar es una decisión ética y legal, no técnica.

MÉTRICA	DEFINICIÓN	CUÁNDO APLICAR — IMPLICACIÓN LEGAL
Demographic Parity	La tasa de decisiones positivas es igual para todos los grupos: P(Ŷ=1 | Grupo A) = P(Ŷ=1 | Grupo B). El modelo aprueba el mismo porcentaje de solicitudes independientemente del grupo.	Apropiada cuando el objetivo es corregir inequidades históricas (affirmative action). Obligatoria en RRHH donde hay discriminación sistémica documentada. Limitación: puede aprobar solicitudes de menor calificación de un grupo — tensión con eficiencia. No compatible con Equal Opportunity cuando las tasas base difieren.
Equal Opportunity	La tasa de verdaderos positivos es igual entre grupos: P(Ŷ=1 | Y=1, Grupo A) = P(Ŷ=1 | Y=1, Grupo B). El modelo no rechaza a los candidatos calificados de ningún grupo con mayor frecuencia.	Apropiada para allocation de beneficios: el modelo no debe rechazar a prestatarios solventes de un grupo en mayor proporción. Relevante para crédito y contratación. Fairlearn Exponentiated Gradient puede optimizar para esta métrica.
Equalized Odds	Generalización: tanto TPR como FPR son iguales entre grupos. P(Ŷ=1|Y=1,G) igual para todos G, Y P(Ŷ=1|Y=0,G) igual para todos G. La métrica más fuerte de fairness.	La métrica más exigente: requiere que el modelo se comporte igualmente en casos positivos y negativos para todos los grupos. Imposible de satisfacer simultáneamente con Demographic Parity cuando las tasas base difieren (Teorema de Chouldechova).
Counterfactual Fairness	La decisión sería la misma en un contrafactual donde el individuo pertenece a un grupo diferente, manteniendo todo lo demás constante. Implementado vía DiCE.	La métrica más intuitiva para explicar al individuo: 'si usted fuera de otro género/etnia, con los mismos ingresos, la decisión habría sido la misma'. Útil para cumplir con GDPR Art. 22 de forma que el individuo pueda entender y contestar.
Calibration	El modelo está calibrado si la probabilidad predicha refleja la frecuencia real: P(Y=1 | Ŷ=p, Grupo A) = P(Y=1 | Ŷ=p, Grupo B) = p. Los scores tienen el mismo significado para todos los grupos.	Esencial en sistemas donde el número predicho se usa directamente para decisiones cuantitativas: scoring de riesgo, scoring de salud, scoring de crédito. Sin calibración por grupos, un score de 0.7 significa cosas distintas para distintos grupos.

⚠️ Teorema de Imposibilidad de Fairness: Chouldechova (2017) y Kleinberg et al. (2017): cuando las tasas base de la variable de outcome difieren entre grupos —caso casi universal en aplicaciones reales— es matemáticamente imposible satisfacer simultáneamente Calibration, Demographic Parity y Equal Opportunity. El CISO y el equipo legal deben elegir explícitamente qué métrica de fairness aplicar y documentar la justificación. Elegir implícitamente (sin documentar) tiene riesgo regulatorio. Microsoft Responsible AI Standard v2 requiere documentar esta elección.

16.4.2 Fairlearn — La Herramienta de Mitigación de Sesgos de Microsoft

COMPONENTE FAIRLEARN	DESCRIPCIÓN TÉCNICA	CASO DE USO EN AZURE ML
Metrics Dashboard	Visualización interactiva: selection rates por grupo, TPR, FPR, AUC desagregado. Selección de sensitive feature (género, etnia, edad) y métrica de fairness. Comparación de múltiples modelos en scatter plot performance vs. fairness.	Para modelos propios en Azure ML: ejecutar post-training para verificar ausencia de disparidades antes del deployment. El output puede incluirse en el Responsible AI Scorecard como evidencia para el EU AI Act.
Exponentiated Gradient	Algoritmo de reducción: reformula el problema de fairness como serie de clasificaciones ponderadas. En cada iteración, aumenta el peso de los ejemplos de grupos tratados injustamente. Resultado: clasificador que minimiza el error total sujeto a la constraint de fairness elegida.	Para modelos que muestran disparidad significativa: re-entrena incorporando la constraint de fairness. Compatible con scikit-learn, LightGBM, PyTorch. El CISO audita el trade-off: cuánta accuracy se sacrifica para qué nivel de fairness.
Threshold Optimizer	Enfoque post-processing: modifica el threshold de decisión de forma diferenciada por grupo sin re-entrenar el modelo. Más rápido pero menos preciso que Exponentiated Gradient.	Para modelos legacy en producción que no pueden re-entrenarse: permite añadir fairness sin cambiar el modelo subyacente. Útil para sistemas de scoring de clientes ya desplegados que muestran disparidad en auditoría.
GridSearch	Entrena una familia de modelos con diferentes niveles de penalización de fairness. Permite comparar el Pareto frontier de performance vs. fairness. El equipo elige explícitamente qué punto del trade-off seleccionar y documenta la justificación.	El scatter plot de GridSearch (performance vs. fairness disparity) es una herramienta visual poderosa para explicar el trade-off al AI Governance Committee y documentar la decisión de selección de modelo.

16.5 MICROSOFT RESPONSIBLE AI DASHBOARD: EL STACK DE XAI PARA AZURE ML

El Microsoft Responsible AI Dashboard es el 'single pane of glass' que consolida XAI, fairness, análisis de errores y análisis causal en una interfaz integrada. Disponible en Azure ML Studio, es el resultado de integrar cuatro toolkits open-source: Fairlearn, InterpretML, DiCE, y EconML.

COMPONENTE	LIBRERÍA SUBYACENTE	PREGUNTA QUE RESPONDE	OUTPUT
Error Analysis	microsoft/responsible-ai-toolbox. Árbol de decisión que identifica los cohorts del dataset donde el modelo tiene mayor tasa de error.	¿Dónde falla el modelo? ¿Hay grupos específicos para los que el modelo es significativamente menos preciso?	Heatmap de errores por cohort. Árbol de decisión de fallos. Input para el Model Card y para el fairness assessment.
Interpretability	microsoft/interpret → InterpretML. Integra SHAP, LIME, EBM. Soporta local (por predicción) y global (por modelo).	¿Por qué el modelo toma sus decisiones? ¿Por qué este cliente específico recibió esta predicción?	Feature importance plot (global). SHAP waterfall plot (local). EBM shape functions. Exportable al Responsible AI Scorecard.
Fairness Assessment	microsoft/fairlearn. Métricas: selection rate, TPR, FPR, AUC por grupo. Mitigación: Exponentiated Gradient, Threshold Optimizer, GridSearch.	¿Es el modelo justo con todos los grupos sensibles? ¿Cuál es el trade-off entre fairness y performance?	Dashboard interactivo de métricas desagregadas. Scatter plot performance vs. fairness. Evidencia para conformity assessment EU AI Act.
Counterfactual Analysis	microsoft/DiCE. Genera los mínimos cambios en features no protegidas que cambiarían la decisión del modelo.	¿Qué debería cambiar para obtener un resultado diferente? ¿Puede el usuario tomar acciones concretas?	'Si su ingreso fuera $X más, la solicitud sería aprobada.' Implementa GDPR Art. 22. Esencial para sistemas de crédito y RRHH.
Causal Analysis	microsoft/EconML. Estima efectos causales —no solo correlaciones— de features sobre outcomes.	¿Cuál es el impacto causal real de una intervención? ¿Qué factores tienen causalidad vs. solo correlación?	'Reducir la tasa causalmente aumenta la tasa de repago en X%.' Evita decisiones basadas en correlaciones espurias.

🔧 Cómo activar el Responsible AI Dashboard en Azure ML: 1. Registrar el modelo en Azure ML Registry. 2. Azure ML Studio → Seleccionar modelo → 'Create Responsible AI Dashboard'. 3. Configurar dataset de evaluación con sensitive features (género, etnia, edad). 4. Seleccionar componentes (Error Analysis, InterpretML, Fairlearn, DiCE, EconML). 5. El dashboard se genera como asset adjunto al modelo. 6. Exportar como 'Responsible AI Scorecard' (PDF): métricas clave en formato compartible con stakeholders no técnicos. Disponibilidad: GA en Azure ML. Requiere: Azure ML workspace, modelo registrado, dataset de evaluación etiquetado.

16.6 EU AI ACT Y EXPLAINABILIDAD: OBLIGACIONES, PLAZOS Y PENALIDADES

El EU AI Act no usa explícitamente el término 'Explainable AI' — pero sus requisitos de transparencia, documentación técnica, supervisión humana y logging hacen que la explainabilidad sea una necesidad práctica para cualquier sistema de alto riesgo. La penalidad máxima — 6% del revenue global — supera al GDPR.

Art.	TÍTULO	IMPLICACIÓN XAI	HERRAMIENTA TÉCNICA
9	Sistema de Gestión de Riesgos	Proceso continuo de identificación, análisis y mitigación de riesgos a lo largo de todo el ciclo de vida. Debe documentar cómo se identificaron y mitigaron los riesgos — incluyendo los derivados de sesgos y comportamientos no explicados.	DPIA de IA. Fairlearn bias assessment. Red Teaming (Fase 13). Registro de riesgos del sistema.
10	Datos de Entrenamiento	Los sistemas de alto riesgo deben usar datos relevantes, representativos, libres de errores. Los conjuntos de datos deben examinarse para detectar posibles sesgos. La detección de sesgos implica herramientas de fairness assessment.	Fairlearn metrics sobre datos de training. Error Analysis para detectar cohorts subrepresentados. AIBOM.
11	Documentación Técnica	Antes del deployment: documentación técnica completa incluyendo descripción del sistema, capacidades, limitaciones, proceso de validación y testing.	Model Card completo. Responsible AI Scorecard de Azure ML. AIBOM para modelos fine-tuned.
12	Registro (Logging)	Los sistemas de alto riesgo deben tener capacidades de logging para reconstruir las circunstancias que llevaron a resultados identificados como riesgosos.	Azure ML Model Monitoring. Purview Audit Log para sistemas M365. Custom logging en Azure AI Foundry.
13	Transparencia al Usuario	Los usuarios deben poder entender las capacidades y limitaciones del sistema para usarlo apropiadamente. Información clara sobre propósito, accuracy, limitaciones, errores posibles.	Componente de Transparencia del Model Card. Documentation visible en la interfaz de usuario. Formación de usuarios documentada.
14	Supervisión Humana	Los sistemas de alto riesgo deben diseñarse para que humanos puedan supervisar efectivamente: parar el sistema, invalidar decisiones, monitorear comportamiento. Los operadores deben entender suficientemente el sistema.	XAI como prerequisito de supervisión humana efectiva: un operador no puede supervisar lo que no puede entender. Human-in-the-loop para decisiones de alto impacto. Kill switch probado.
17	Documentación Técnica Detallada	Para cada versión del sistema: descripción del modelo, datos de training, validación y testing, resultados de evaluación de performance desagregados por grupos relevantes.	Model Card con Quantitative Analyses desagregadas. Responsible AI Scorecard. Versionado en Azure ML Registry.
65	Penalidades	No compliance con requisitos para sistemas de alto riesgo: hasta 3% revenue global. Uso de sistemas prohibidos (Art. 5): hasta 6% revenue global. Información incorrecta a organismos notificados: hasta 1%.	El compliance con Arts. 9-17 (XAI + fairness + documentación) es la defensa. El CISO debe demostrar que los controles fueron implementados, evaluados y documentados.

16.6.1 Timeline EU AI Act — Ventana de Compliance para el CISO

FECHA	MILESTONE	ACCIÓN CISO
1 agosto 2024	Entrada en vigor del EU AI Act.	-
2 febrero 2025	Prohibición de sistemas de IA de riesgo inaceptable (Art. 5).	Verificar que ningún sistema interno cae en categoría prohibida.
2 agosto 2025	Reglas GPAI y obligaciones de autoridades nacionales. Proveedores GPAI deben publicar Model Cards.	Verificar que los 16 proveedores del proyecto han publicado su documentación GPAI. Actualizar due diligence (Fases 5-6).
2 agosto 2026	Requisitos para sistemas de alto riesgo (Arts. 9-17) aplicables. Conformity assessment obligatorio.	FECHA CRÍTICA: documentación técnica, gestión de riesgos, logging, XAI y fairness assessment completados para todos los sistemas de alto riesgo internos.
2027	Sistemas de IA en productos regulados existentes: transición completa.	Compliance total para sistemas en productos médicos, seguridad, etc.

16.7 PLAN DE XAI PARA EL CISO CON M365/COPILOT/AZURE AI FOUNDRY

El plan distingue dos contextos: (A) el CISO como usuario de IA de terceros (M365 Copilot, modelos de proveedores) — donde el trabajo es evaluar y documentar la explainabilidad que los proveedores ofrecen — y (B) el CISO como deployer de modelos propios (Azure ML, Copilot Studio) — donde el trabajo es implementar XAI y fairness sobre modelos propios. Las obligaciones regulatorias más intensas aplican al contexto B.

16.7.1 Contexto A — M365 Copilot y Proveedores: Evaluar XAI del Proveedor

PREGUNTA	FUENTE DE EVIDENCIA	ACCIÓN DEL CISO
¿El proveedor publica Model Card / System Card para los modelos de Copilot?	Microsoft: Responsible AI Report anual (2025), Model Cards para GPT-4o (Azure OpenAI), familia Phi, Copilot System Card. Disponibles en microsoft.com/ai y Azure AI Foundry documentation.	Descargar y revisar. Verificar que cubren: intended use, limitations, evaluation results desagregados. Almacenar como evidencia para el AI Governance Committee y auditoría EU AI Act.
¿Qué explainabilidad ofrece Copilot al usuario final?	M365 Copilot cita las fuentes de los documentos que usa para generar respuestas — indica qué archivos de SharePoint / emails de Exchange fueron usados como contexto. No provee SHAP values ni feature importance: la explicación es a nivel de fuentes, no de razonamiento interno del LLM.	Comunicar a usuarios el nivel real de explainabilidad disponible. Para casos donde la explicabilidad del reasoning es crítica (no solo las fuentes): evaluar si Copilot es la herramienta apropiada o si se necesita un sistema con mayor explainabilidad.
¿Los agentes de Copilot Studio permiten auditar su razonamiento?	Copilot Studio registra los pasos de razonamiento y las herramientas llamadas en Azure Monitor / Application Insights. Es posible auditar qué herramienta fue llamada con qué argumento. El razonamiento interno del LLM sigue siendo opaco.	Implementar logging de herramientas en todos los agentes (Azure Monitor). Configurar alertas para herramientas llamadas de forma anómala. El trace de herramientas es el 'audit trail' de XAI disponible para agentes.
¿Cómo evaluar si Copilot tiene sesgos en el contexto específico de la organización?	No hay herramienta de fairness específica para M365 Copilot. El assessment debe ser empírico: diseñar escenarios de prueba con inputs equivalentes para distintos grupos y evaluar si los outputs son consistentes.	Diseñar un 'Copilot Fairness Evaluation' ad hoc: 20-30 escenarios donde el input solo difiere en atributos protegidos (nombre, género aparente, origen). Evaluar si los outputs difieren sistemáticamente. Documentar el resultado. Repetir anualmente o tras actualizaciones del modelo base.

16.7.2 Contexto B — Modelos Propios en Azure ML / AI Foundry: Implementar XAI

	ACCIÓN	DETALLE DE EJECUCIÓN	CRITERIO DE ÉXITO
1	Inventario de modelos propios con clasificación EU AI Act	Levantar el inventario completo de modelos ML propios o fine-tuned. Para cada modelo: clasificar riesgo bajo EU AI Act (Alto Riesgo → conformity assessment; Limitado → transparencia; Minimal → sin obligaciones). Sistemas de alto riesgo relevantes para empresa argentina: RRHH (scoring de empleados, selección), scoring de clientes, sistemas de seguridad con decisiones automáticas.	Inventario con clasificación EU AI Act para cada modelo. Lista de modelos de alto riesgo con target de compliance (agosto 2026).
2	Implementar RAI Dashboard en Azure ML para modelos de alto riesgo	Para cada modelo de alto riesgo en Azure ML: configurar el Responsible AI Dashboard con los 5 componentes. Definir qué grupos sensibles evaluar. Ejecutar el análisis completo. Revisar con el AI Governance Committee. Documentar hallazgos y plan de mitigación si hay disparidades.	RAI Dashboard ejecutado para 100% de modelos de alto riesgo. Reporte de fairness assessment por grupo sensible. Si hay disparidades: plan de mitigación con Fairlearn documentado.
3	Generar Model Card para cada modelo de alto riesgo	Usar template de Model Card (model-card-toolkit) adaptado a requisitos de Technical Documentation EU AI Act (Art. 11). Completar todas las secciones. Incluir output del RAI Dashboard como Quantitative Analyses. Review y firma del DPO y AI Governance Committee antes del deployment.	Model Card completo y firmado para cada modelo de alto riesgo. Almacenado en Azure ML Registry adjunto al modelo versionado. Actualizado en cada re-entrenamiento significativo.
4	Implementar SHAP en el pipeline de inferencia para decisiones auditables	Para modelos que apoyan decisiones con impacto en personas (RRHH, scoring, selección): implementar generación de explicaciones SHAP locales en el pipeline de inferencia. Cada decisión puede acompañarse de una explicación on-demand. Almacenar top-3 features más importantes por decisión en el log. Para sistemas customer-facing: implementar DiCE counterfactuals si el usuario pregunta 'qué debo cambiar'.	Pipeline de inferencia con explicaciones SHAP locales on-demand. Log de decisiones con features más importantes. Interface de explicación para usuario final cuando aplica.
5	Proceso de revisión anual de fairness y XAI	Ciclo anual: (1) Re-ejecutar RAI Dashboard con datos del año en producción (data drift puede haber cambiado el fairness). (2) Revisar si hay grupos nuevos a evaluar. (3) Actualizar Model Card. (4) Si el modelo fue actualizado: re-ejecutar desde el inicio. (5) Presentar Responsible AI Scorecard al AI Governance Committee como parte del informe anual de postura de IA.	Ciclo anual documentado: RAI Dashboard actualizado, Model Card actualizado, Responsible AI Scorecard presentado al AI Governance Committee. Evidencia de proceso continuo para auditoría EU AI Act.
6	Capacitación del equipo en XAI y fairness enterprise	Capacitación obligatoria para data scientists: RAI Dashboard de Azure ML, interpretación de SHAP values, métricas de fairness y su significado legal, cómo documentar un Model Card. Capacitación para CISO y DPO: qué significa cada métrica del RAI Dashboard, cómo comunicar resultados al Board, cuándo iniciar un proceso de mitigación.	100% del equipo de data science con capacitación en RAI Dashboard. CISO y DPO con capacitación en métricas de fairness. Microsoft Learn provee el learning path de Responsible AI.

16.8 REFERENCIAS (R421–R450)

XAI — Fundamentos y Estado del Arte 2025-2026:

R421. Financial Content Markets, 'The End of the Black Box: How Explainable AI is Transforming High-Stakes Decision Making in 2026', enero 2026. XAI como requisito legal y ético. Mechanistic Interpretability 2025: SAEs mapean features conceptuales en LLMs. IBM watsonx.governance 'agentic explainability'. Palantir AIP Control Tower. Posible retraso EU Digital Omnibus hasta 2028 para reglas más estrictas en empresas pequeñas.

R422. EthicalXAI Platform, 'SHAP vs LIME: Choosing the Best XAI Method for Your Enterprise Models in 2025', julio 2025. EU AI Act: penalidades hasta 6% revenue global. Organizaciones con XAI comprensivo: 31% más rápido en debugging, 24% reducción incidentes de sesgo, 18% mejora trust metrics. California SB-1001 para algorithmic accountability. Brazil LGPD con provisiones de IA.

R423. Bismart Blog, 'Explainable AI (XAI) in 2025: How to Trust AI', agosto 2025. BBVA Mercury library para explainabilidad de modelos financieros. Banco español SHAP: 30% reducción en disputas de decisiones crediticias. BBVA y Telefónica: auditorías de algoritmos anticipando EU AI Act. XAI como herramienta de trust y adoption.

R424. AI Ireland, 'Explainable AI and the EU AI Act: Unlocking Trust and Compliance Before It's Too Late', abril 2025. EU AI Act: justificación en conformity assessments, audit trails obligatorios. Timeline oficial EU AI Act. Post-hoc XAI: SHAP, LIME, Captum. Integrar explainabilidad desde el inicio del modelo lifecycle.

R425. GJETA, 'The Rise of Explainable AI: Enhancing Transparency and Accountability', 2025. Comparativa SHAP vs LIME vs perturbation-based vs self-explainable. Evaluación XAI: functionally-grounded, application-grounded, human-grounded. Regulatorio: EU AI Act, GDPR, FDA AI guidance médica.

R426. SwiftTask, 'Explainable AI (XAI) 2024: Algorithmic Transparency and the EU AI Act', 2025. Balance performance-transparencia: modelos simples pierden 8-12% accuracy. Hybrid approaches como compromiso. 'Explainability by design' como nuevo estándar.

SHAP, LIME, Técnicas de Explicación:

R427. Lundberg, Scott y Lee, Su-In, 'A Unified Approach to Interpreting Model Predictions' (SHAP), NeurIPS 2017. Shapley values de teoría de juegos cooperativos. Cuatro propiedades: eficiencia, simetría, dummy, aditividad. pip install shap.

R428. Ribeiro, Marco et al., 'Why Should I Trust You? Explaining the Predictions of Any Classifier' (LIME), KDD 2016. Perturbación local + modelo lineal ponderado. Model-agnostic.

R429. Articsledge, 'What is Explainable AI (XAI)? Complete Guide to XAI in 2025', noviembre 2025. Goldman Sachs SHAP + GDPR Art. 22 + ECOA compliance. JPMorgan Chase SHAP + LIME. PayPal fraud detection. Bridgewater: XAI para trading transparency.

R430. CFA Institute, 'Explainable AI in Finance: Addressing the Needs of Diverse Stakeholders', agosto 2025. 6 grupos de stakeholders con necesidades XAI distintas. Overreliance risk: automation bias. Evaluative AI y Neurosymbolic AI como alternativas. No hay benchmark universal de calidad de explicaciones.

R431. EDPS, 'TechDispatch on Explainable Artificial Intelligence', noviembre 2023. Automation bias: las explicaciones pueden aumentar la probabilidad de aceptación ciega. GDPR y transparencia del tratamiento. Proxy attributes: XAI puede revelar que el modelo usa proxies de atributos protegidos.

Model Cards, Fairness y Microsoft Responsible AI:

R432. Mitchell, Margaret et al. (Google), 'Model Cards for Model Reporting', FAccT 2019. Artículo fundacional. Secciones: Model Details, Intended Use, Factors, Metrics, Evaluation Data, Training Data, Quantitative Analyses, Ethical Considerations, Caveats. pip install model-card-toolkit.

R433. Gebru, Timnit et al. (Google), 'Datasheets for Datasets', Communications of the ACM, 2021. Documentación de motivación, composición, proceso de recolección, preprocesamiento, usos recomendados. Complementario al AIBOM (Fase 15).

R434. Microsoft GitHub, 'Responsible AI Toolbox', github.com/microsoft/responsible-ai-toolbox. Error Analysis, InterpretML (SHAP + LIME + EBM), Fairlearn, DiCE, EconML. Responsible AI Dashboard y Scorecard (PDF). Compatible: scikit-learn, PyTorch, LightGBM.

R435. Medium (Bhavya), 'The Ultimate Guide to Microsoft Responsible AI Toolbox', mayo 2025. Fairlearn para detección de sesgos. EBM: glass-box comparable a gradient boosting. Responsible AI Dashboard ideal para executive reviews. DiCE: counterfactuals accionables.

R436. Microsoft Learn, 'What is Responsible AI — Azure Machine Learning', 2025. 6 principios: Fairness, Reliability, Privacy, Inclusiveness, Transparency, Accountability. SmartNoise: DP (co-desarrollado con MSR). Counterfit: cyberattack simulation para AI. Responsible AI Scorecard para comunicación cross-stakeholder.

R437. Microsoft AI, 'Responsible AI Principles and Approach', 2025. Responsible AI Annual Report 2025. Aether committee. Responsible AI Standard v2. Sensitive use case reviews.

R438. Microsoft Responsible AI Standard v2, 2022-2025. Requisitos F1-F2 para Fairness: Fairlearn, Error Analysis, InterpretML. Documentación de trade-offs. Consulta legal para disparidades residuales.

R439. Fairlearn.org Documentation, 2025. Métricas: demographic parity, equalized odds, equal opportunity, calibration. Algoritmos: Exponentiated Gradient, Threshold Optimizer, GridSearch. Scatter plot performance vs. fairness.

R440. Medium (Navita Singh), 'Responsible AI in Azure (Part 1)', octubre 2025. Fairlearn Exponentiated Gradient en Azure. Demographic parity vs. equalized odds. Responsible AI Dashboard en Azure ML Studio.

EU AI Act, Fairness Theory y Accountability Algorítmica:

R441. EU AI Act, Regulation (EU) 2024/1689. Art. 9 (Risk Management), Art. 10 (Data Governance), Art. 11 (Technical Documentation), Art. 12 (Logging), Art. 13 (Transparency), Art. 14 (Human Oversight), Art. 17 (Detailed Technical Documentation), Art. 43-46 (Conformity Assessment), Art. 65 (Penalties).

R442. EU AI Act Timeline oficial. 1 agosto 2024 entrada en vigor. 2 febrero 2025: prohibición sistemas inaceptables. 2 agosto 2025: GPAI y autoridades nacionales. 2 agosto 2026: sistemas de alto riesgo. 2027: productos regulados legacy.

R443. Medium (Tahir), 'How to Build an Enterprise AI Compliance Program', agosto 2025. Enterprise AI compliance: Governance, Risk Assessment (DPIAs + AIAs), Data Governance, XAI (Model Cards + SHAP/LIME), Human Oversight. Fases de implementación.

R444. Chouldechova, Alexandra, 'Fair Prediction with Disparate Impact', Big Data, 2017. Teorema de imposibilidad: cuando las tasas base difieren entre grupos, es matemáticamente imposible satisfacer simultáneamente Calibration, Demographic Parity y Equal Opportunity.

R445. Kleinberg, Jon et al., 'Human Decisions and Machine Predictions', NBER, 2018. Las inconsistencias de fairness en modelos ML reflejan inconsistencias en decisiones humanas. La explainabilidad puede revelar sesgos históricos en datos de training.

R446. GoCodeo, 'Top 5 Responsible AI Frameworks in 2025', 2025. Microsoft Azure RAI: 6 pilares, Fairlearn + InterpretML + SHAP + RAI Dashboard. LinkedIn FAIR framework. Credo AI: governance enterprise con policy-as-code.

R447. IBM watsonx.governance Documentation, 2025. 'Agentic explainability'. AI FactSheets integradas. Healthcare suite: XAI step-by-step para recomendaciones clínicas. 'White box' como selling point enterprise ante liability de decisiones automatizadas.

R448. Anthropic, 'Scaling Monosemanticity: Extracting Interpretable Features from Claude 3 Sonnet', 2024. SAEs: miles de features conceptuales mapeadas en Claude 3 Sonnet. Implicaciones de seguridad: circuitos que responden a prompts adversariales. Base del programa de Interpretability Safety Research de Anthropic.

R449. Google DeepMind, 'Gemma Scope: Open Sparse Autoencoders Everywhere All At Once', 2025. Open release de SAEs para Gemma 2. Permite que investigadores externos estudien los circuitos internos de un LLM de alta calidad.

R450. NIST AI Risk Management Framework (AI RMF) 1.0, enero 2023. Map, Measure, Manage, Govern. Transparencia y Explicabilidad como función core del Measure. Mapping NIST AI RMF ↔ EU AI Act para organizaciones con exposición a ambos marcos.