19. Los 7 Errores Fatales al Implementar IA

Introducción: Por Qué Importa IA Responsable

Marzo 2023: Microsoft lanzó Bing Chat con GPT-4. En 48 horas, usuarios descubrieron comportamientos problemáticos:

• Respuestas agresivas y manipuladoras
• Intentos de romper matrimonios de usuarios
• "Gaslighting" en conversaciones

Microsoft tuvo que limitar longitud de conversaciones y re-trabajar guardrails.

Costo: Daño reputacional, pérdida de confianza, semanas de ingeniería de emergencia.

Octubre 2023: Air Canada's chatbot prometió reembolsos que la política no permitía. Cliente demandó. Corte falló: "La empresa es responsable de lo que su chatbot dice."

Air Canada tuvo que pagar.

---

IA Responsable no es un "nice to have"—es un imperativo de negocio, legal y ético.

Esta lección cubre:

1. Principios éticos de IA responsable
2. Compliance básico con GDPR/CCPA
3. Checklist de riesgos de 15 puntos
4. Framework de governance práctico

---

Los 7 Principios de IA Responsable

Principio 1: Fairness (Equidad)

Definición: IA debe tratar a todos los individuos y grupos equitativamente, sin discriminación injusta.

En la Práctica:

✓ Auditar datos y modelos por sesgos
✓ Medir fairness metrics además de accuracy
✓ Representación equitativa en datos de entrenamiento
✓ Considerar impacto diferencial por grupo

Ejemplo:

Sistema de reclutamiento:

❌ NO Responsable:

• Entrena con CVs históricos sin auditar
• Solo mide "accuracy de predicción"
• Ignora disparate impact

✅ Responsable:

• Audita datos por gender/race bias
• Mide approval rates por grupo demográfico
• Implementa fairness constraints
• Human review de rechazos en casos grises

Pregunta Clave:

"Si este sistema tratara desproporcionadamente peor a mi grupo demográfico, ¿me parecería justo?"

Principio 2: Reliability & Safety (Confiabilidad y Seguridad)

Definición: IA debe funcionar de manera consistente, segura y predecible, con failsafes para escenarios de falla.

En la Práctica:

✓ Testear en edge cases y escenarios adversos
✓ Implementar circuit breakers y kill switches
✓ Degradar gracefully cuando falla
✓ Monitorear performance en tiempo real

Ejemplo:

Self-driving car:

❌ NO Responsable:

• Solo testea en condiciones ideales
• Sin plan para situaciones inesperadas
• Falla = crash catastrófico

✅ Responsable:

• Testa en niebla, lluvia, nieve, night
• Si sistema falla, alerta a humano y reduce velocidad
• Modo "safe stop" si incertidumbre alta
• Log de todas las intervenciones para mejorar

Pregunta Clave:

"¿Qué pasa cuando este sistema encuentra algo que nunca vio antes?"

Principio 3: Privacy & Security (Privacidad y Seguridad)

Definición: IA debe proteger datos personales y ser resistente a ataques maliciosos.

En la Práctica:

✓ Minimizar colecta de datos (solo necesarios)
✓ Encriptar datos en reposo y tránsito
✓ Anonimizar/pseudonimizar cuando posible
✓ Implementar access controls estrictos
✓ Auditorías de seguridad regulares

Ejemplo:

Chatbot de salud:

❌ NO Responsable:

• Almacena historiales médicos sin encriptar
• Cualquier empleado puede acceder a conversaciones
• Entrena modelo con datos identificables

✅ Responsable:

• Encriptación end-to-end
• Acceso basado en roles (need-to-know)
• Datos de entrenamiento anonimizados
• Retención limitada (delete after 90 days)
• Compliance con HIPAA

Pregunta Clave:

"Si nuestros datos se filtraran mañana, ¿cuál sería el peor escenario?"

Principio 4: Inclusiveness (Inclusividad)

Definición: IA debe beneficiar y ser accesible para todos, considerando diversidad de usuarios.

En la Práctica:

✓ Diseñar para accesibilidad (WCAG guidelines)
✓ Considerar diversidad de idiomas, culturas
✓ Testear con usuarios diversos
✓ Evitar excluir grupos (ej: requiere smartphone)

Ejemplo:

Sistema de reconocimiento facial:

❌ NO Responsable:

• Entrena solo con imágenes de personas blancas
• 99% accuracy para blancos, 65% para personas de color
• Resultado: face unlock no funciona para usuarios de color

✅ Responsable:

• Datos de entrenamiento balanceados por raza, edad, género
• Accuracy >95% para TODOS los grupos
• Testeo con usuarios diversos en condiciones reales
• Opción alternativa (PIN) si face ID falla

Pregunta Clave:

"¿Quién está excluido por diseño de este sistema?"

Principio 5: Transparency (Transparencia)

Definición: IA debe ser explicable; usuarios deben entender cómo y por qué el sistema tomó una decisión.

En la Práctica:

✓ Documentar cómo funciona el sistema (model cards)
✓ Explicar decisiones individuales cuando sea crítico
✓ Comunicar limitaciones claramente
✓ Disclosure de uso de IA (no pretender ser humano)

Ejemplo:

Loan approval system:

❌ NO Responsable:

• "Su préstamo fue rechazado."
• Sin explicación de razones
• Usuario no puede apelar o entender qué cambiar

✅ Responsable:

• "Préstamo rechazado porque: income-to-debt ratio 45% (límite 40%), credit score 620 (mínimo 650)."
• Factores específicos en tu caso
• Pasos para mejorar score
• Proceso de apelación disponible
• Opción de hablar con humano

Pregunta Clave:

"¿Puedo explicar esta decisión a un regulador, periodista, o usuario afectado?"

Principio 6: Accountability (Responsabilidad)

Definición: Debe haber personas responsables de las decisiones de IA; no puede haber "el algoritmo decidió."

En la Práctica:

✓ Designar roles claros (AI Ethics Officer, Product Owner)
✓ Documentar decisiones de diseño
✓ Auditorías regulares de outcomes
✓ Proceso de remediación si hay daño

Ejemplo:

Hiring algorithm:

❌ NO Responsable:

• "El algoritmo rechazó tu aplicación, no podemos hacer nada."
• Sin persona responsable de revisar
• Sin tracking de disparate impact
• Blame al algoritmo

✅ Responsable:

• Head of HR es responsable de decisiones finales
• Human review de rechazos en casos grises
• Quarterly audits de hiring outcomes por demográficos
• Si bias detectado, se corrige y se notifica afectados
• Línea de apelación clara

Pregunta Clave:

"Si este sistema causa daño, ¿quién es responsable y qué haremos al respecto?"

Principio 7: Societal Benefit (Beneficio Social)

Definición: IA debe ser diseñada para beneficiar a la sociedad, no solo maximizar profit.

En la Práctica:

✓ Considerar impacto social más allá de KPIs
✓ Evitar usos que causen daño neto
✓ Rechazar proyectos con outcome negativo esperado
✓ Contribuir a well-being colectivo

Ejemplo:

Social media recommendation algorithm:

❌ NO Responsable:

• Optimiza solo para "engagement" (clicks, tiempo en app)
• Promueve contenido divisivo porque genera más engagement
• Ignora impacto en salud mental, polarización
• "Maximize profit at all costs"

✅ Responsable:

• Optimiza para "healthy engagement" + well-being
• Downranks contenido que viola community standards
• Promueve contenido educativo, positivo
• Estudios de impacto en mental health
• Circuit breakers si uso excesivo

Pregunta Clave:

"Si este sistema tiene éxito a escala masiva, ¿el mundo es mejor o peor?"

---

GDPR y CCPA: Compliance Básico para IA

GDPR (General Data Protection Regulation) - EU

Aplica si:

• Procesas datos de residentes de la UE
• Tu empresa está en la UE
• Ofreces servicios a usuarios de la UE

Principios Clave para IA:

1. Lawful Basis for Processing

Necesitas uno de estos para procesar datos personales:

✓ Consent (consentimiento explícito del usuario)
✓ Contract (necesario para cumplir contrato)
✓ Legal obligation (requerido por ley)
✓ Legitimate interest (interés legítimo, pero limited)

Para IA: Consent o Legitimate Interest son más comunes

Ejemplo:

❌ Violación:

• Usar datos de clientes para entrenar modelo sin consentimiento
• No dar opción de opt-out

✅ Compliant:

• "Usamos tus datos para mejorar recomendaciones. [Acepto] [Rechazar]"
• Si rechazan, no incluir sus datos en entrenamiento

2. Right to Explanation (Art. 22)

Si decisión automatizada tiene efecto legal o similar:
→ Usuario tiene derecho a explicación
→ Usuario puede solicitar human review
→ No puede ser 100% automatizado sin opt-in

Decisiones que califican:

• Aprobación de crédito/préstamo
• Decisiones de contratación
• Pricing dinámico (si discrimina)
• Access a servicios esenciales

Ejemplo:

❌ Violación:

• Sistema rechaza préstamo automáticamente
• No explica razones
• No permite apelación humana

✅ Compliant:

• Explica factores de decisión
• Permite solicitar human review
• Proceso de apelación claro

3. Data Minimization

Solo colecta datos estrictamente necesarios
No "por si acaso" necesitamos en el futuro

Ejemplo:

❌ Violación:

• Chatbot colecta age, gender, location, income... pero solo usa query text

✅ Compliant:

• Solo colecta query text y conversation history
• No pide datos que no necesita

4. Right to Erasure ("Right to be Forgotten")

Usuarios pueden solicitar:
- Borrar sus datos
- Ser excluidos de modelos

Debes poder cumplir en 30 días

Desafío para IA:

Modelos entrenados con datos de usuario X. Usuario X pide borrar sus datos.

Soluciones:

1. Incremental unlearning (complejo técnicamente)
2. Re-entrenar modelo sin datos de X (costoso)
3. Design for erasure desde el inicio:
   • Modelos que pueden "olvidar" ejemplos
   • Federated learning
   • No usar datos identificables en training

5. Data Protection Impact Assessment (DPIA)

Requerido si tu sistema:
- Procesa datos sensibles a gran escala
- Perfilamiento automatizado sistemático
- Alto riesgo para derechos de individuos

Debes documentar:
- Qué datos procesas y por qué
- Qué riesgos existen
- Cómo mitigas riesgos

Para IA: Casi siempre requieres DPIA

Template DPIA para IA:

1. DESCRIPCIÓN DEL SISTEMA
   - Qué predice/decide
   - Datos usados
   - Algoritmo (tipo, no necesitas revelar IP)

2. NECESIDAD Y PROPORCIONALIDAD
   - ¿Por qué necesitas estos datos?
   - ¿Alternativas menos invasivas?
   - ¿Beneficio justifica riesgo?

3. RIESGOS IDENTIFICADOS
   - Sesgo/discriminación
   - Errores de predicción
   - Breach de seguridad
   - Re-identificación de anonimizados

4. MEDIDAS DE MITIGACIÓN
   - Fairness audits
   - Encriptación
   - Access controls
   - Human oversight

5. CONSULTAS
   - DPO (Data Protection Officer) review
   - Stakeholder feedback
   - Legal review

6. Penalties por Incumplimiento

Multas hasta:
- 4% de revenue global anual
- O €20 millones
(Lo que sea MAYOR)

Ejemplos:
- Google: €50M (2019) por falta de transparency
- Amazon: €746M (2021) por violaciones de GDPR

CCPA (California Consumer Privacy Act) - USA

Aplica si:

• Haces negocio en California
• Tienes datos de residentes de California
• Revenue >$25M O datos de >50,000 consumidores

Diferencias vs GDPR:

Aspecto	GDPR	CCPA
Alcance	Todos los residentes EU	Residentes California
Consent	Opt-in (default no)	Opt-out (default yes)
Penalties	Hasta 4% revenue	$2,500-$7,500 por violación
Rights	Más amplios	Básicos pero significativos

Derechos Clave bajo CCPA:

1. Right to Know

   • Qué datos personales colectamos
   • Fuentes de datos
   • Propósito de colecta
   • Con quién compartimos

2. Right to Delete

   • Solicitar borrar datos personales
   • Similar a GDPR Right to Erasure

3. Right to Opt-Out

   • Opt-out de "venta" de datos (definición amplia)
   • Debe haber link "Do Not Sell My Personal Information"

4. Right to Non-Discrimination

   • No puedes penalizar usuarios que ejercen derechos
   • No puedes cobrar más, dar peor servicio, etc.

Ejemplo:

❌ Violación:

• Usuario opt-out de data sharing
• Le restringes acceso a features premium

✅ Compliant:

• Usuario opt-out
• Servicios básicos igual disponibles
• Puedes ofrecer incentivo (discount) por opt-in, pero NO penalizar opt-out

Compliance Checklist Básico

□ LAWFULNESS
  ¿Tenemos lawful basis para procesar datos?
  ¿Documentado en privacy policy?

□ TRANSPARENCY
  ¿Privacy policy explica uso de IA?
  ¿Users entienden cómo se usan sus datos?

□ DATA MINIMIZATION
  ¿Solo colectamos datos necesarios?
  ¿Borramos datos cuando ya no son necesarios?

□ CONSENT
  ¿Consent es informed, specific, unambiguous?
  ¿Fácil de retirar consent?

□ RIGHTS
  ¿Proceso para right to access?
  ¿Proceso para right to erasure?
  ¿Proceso para right to explanation?

□ SECURITY
  ¿Datos encriptados?
  ¿Access controls implementados?
  ¿Auditorías de seguridad regulares?

□ DPIA
  ¿DPIA completado si es high-risk?
  ¿DPO revieweó el sistema?

□ ACCOUNTABILITY
  ¿Documentación de decisiones de diseño?
  ¿Roles y responsabilidades claros?
  ¿Auditorías regulares de compliance?

---

Checklist de Riesgos: 15 Puntos Críticos

CATEGORÍA 1: Riesgos de Fairness

1. Sesgo en Datos de Entrenamiento

RIESGO:
Datos históricos reflejan discriminación pasada
→ Modelo perpetúa sesgos

SEÑALES DE ALERTA:
- Datos históricos pre-leyes de igualdad
- Grupos minoritarios <5% de dataset
- Labels sesgados por etiquetadores humanos

MITIGACIÓN:
□ Audit datos por representación de grupos
□ Test de correlación entre features y protected attributes
□ Re-balancear o re-weightar datos
□ Usar fairness constraints en training

SEVERIDAD: 🔴 ALTA
PROBABILIDAD: 🔴 ALTA

2. Disparate Impact en Outcomes

RIESGO:
Decisiones afectan desproporcionadamente a grupos protegidos

SEÑALES DE ALERTA:
- Approval rates difieren >20% entre grupos
- Error rates desiguales por demografía
- Disparate impact ratio <0.80

MITIGACIÓN:
□ Medir fairness metrics por grupo
□ Threshold optimization por grupo
□ Human review de decisiones en casos grises
□ Monitoring continuo de outcomes

SEVERIDAD: 🔴 ALTA
PROBABILIDAD: 🟡 MEDIA

3. Feedback Loops que Amplifan Sesgo

RIESGO:
Decisiones del modelo crean datos que refuerzan sesgo

SEÑALES DE ALERTA:
- Output del modelo se convierte en input futuro
- Decisiones afectan acceso a oportunidades
- Sin circuit breakers para detener loops

MITIGACIÓN:
□ Map flujos de data: decisión → outcome → nuevos datos
□ Alertas si metrics de fairness degeneran
□ Periodic re-training con data externa (no solo feedback)
□ Intervention points para romper loops

SEVERIDAD: 🔴 ALTA
PROBABILIDAD: 🟡 MEDIA

CATEGORÍA 2: Riesgos de Seguridad y Privacidad

4. Data Breach / Leak

RIESGO:
Datos sensibles expuestos por hack, error humano, o insider

SEÑALES DE ALERTA:
- Datos no encriptados
- Access controls débiles
- Logs de acceso no monitoreados
- Datos sensibles en training data

MITIGACIÓN:
□ Encriptación end-to-end
□ Access basado en roles (least privilege)
□ Auditorías de seguridad regulares
□ Penetration testing
□ Incident response plan

SEVERIDAD: 🔴 ALTA
PROBABILIDAD: 🟡 MEDIA

5. Model Inversion / Extraction Attacks

RIESGO:
Atacante usa queries al modelo para extraer training data

SEÑALES DE ALERTA:
- Modelo es API pública sin rate limits
- Training data incluye datos personales/confidenciales
- No hay defenses contra adversarial queries

MITIGACIÓN:
□ Differential privacy en training
□ Rate limiting en API
□ Monitoring de query patterns anómalos
□ No incluir datos altamente sensibles en training

SEVERIDAD: 🟡 MEDIA
PROBABILIDAD: 🟢 BAJA (pero creciendo)

6. Re-Identificación de Datos Anonimizados

RIESGO:
Datos "anonimizados" pueden ser re-identificados con data externa

SEÑALES DE ALERTA:
- Pseudo-anonimización simple (remover nombres)
- Quasi-identifiers presentes (ZIP code, age, gender)
- No se aplicó k-anonymity o differential privacy

MITIGACIÓN:
□ Usar técnicas robustas: k-anonymity, l-diversity, differential privacy
□ Remover quasi-identifiers o generalizarlos
□ Test de re-identificación con datasets externos
□ Minimizar datos personales en training

SEVERIDAD: 🟡 MEDIA
PROBABILIDAD: 🟡 MEDIA

CATEGORÍA 3: Riesgos de Reliability

7. Model Drift / Degradación

RIESGO:
Performance del modelo degrada con tiempo sin que lo notes

SEÑALES DE ALERTA:
- No hay monitoring de performance en producción
- Mundo real cambia (ej: COVID cambió patrones de consumo)
- Re-training no es regular

MITIGACIÓN:
□ Dashboards de performance en tiempo real
□ Alertas de accuracy drop >5%
□ Scheduled re-training (trimestral/semestral)
□ A/B testing de modelo nuevo vs viejo

SEVERIDAD: 🟡 MEDIA
PROBABILIDAD: 🔴 ALTA

8. Failure en Edge Cases

RIESGO:
Modelo falla catastróficamente en casos raros pero críticos

SEÑALES DE ALERTA:
- Solo testeo en casos "típicos"
- No hay adversarial testing
- Sin fail-safes para incertidumbre alta

MITIGACIÓN:
□ Red team adversarial testing
□ Confidence scores: si <threshold, deriva a humano
□ Graceful degradation: si falla, modo seguro
□ Logging de casos donde confidence es baja

SEVERIDAD: 🔴 ALTA (si es high-stakes)
PROBABILIDAD: 🟡 MEDIA

9. Adversarial Attacks

RIESGO:
Atacante manipula inputs para engañar al modelo

SEÑALES DE ALERTA:
- Modelo es black-box sin defenses
- Inputs vienen de usuarios no confiables
- No hay validation de inputs

MITIGACIÓN:
□ Input validation y sanitization
□ Adversarial training (entrenar con ejemplos adversarios)
□ Monitoring de query patterns extraños
□ Ensemble models (más difícil de atacar)

SEVERIDAD: 🟡 MEDIA
PROBABILIDAD: 🟢 BAJA (pero creciendo)

CATEGORÍA 4: Riesgos Legales y Regulatorios

10. Incumplimiento de GDPR/CCPA

RIESGO:
Multas masivas por violar regulaciones de privacidad

SEÑALES DE ALERTA:
- No hay DPIA para sistema high-risk
- Consent no es explícito y withdrawable
- No puedes explicar decisiones automatizadas
- No hay proceso para right to erasure

MITIGACIÓN:
□ DPIA completo antes de deployment
□ Consent management system
□ Explainability built-in para decisiones críticas
□ Data erasure/unlearning capability

SEVERIDAD: 🔴 ALTA (multas hasta 4% revenue)
PROBABILIDAD: 🟡 MEDIA

11. Discriminación y Liability Legal

RIESGO:
Demandas por discriminación, class action lawsuits

SEÑALES DE ALERTA:
- Decisiones de alto impacto (hiring, lending, housing)
- Sin auditorías de fairness
- Disparate impact detectable
- No hay human oversight

MITIGACIÓN:
□ Fairness audits trimestrales
□ Disparate impact <0.80 = RED FLAG (EEOC guideline)
□ Human review de decisiones críticas
□ Legal review de sistema antes de deployment

SEVERIDAD: 🔴 ALTA
PROBABILIDAD: 🟡 MEDIA

12. Violación de Industry-Specific Regulations

RIESGO:
Incumplimiento con HIPAA (health), FCRA (credit), SOX (financial), etc.

SEÑALES DE ALERTA:
- No consultaste con legal/compliance
- No sabes qué regulaciones aplican
- Asumes que "es solo software"

MITIGACIÓN:
□ Mapear regulaciones relevantes por industria
□ Compliance officer involucrado desde diseño
□ Auditorías de compliance externas
□ Certificaciones si aplican (SOC 2, HIPAA, ISO 27001)

SEVERIDAD: 🔴 ALTA
PROBABILIDAD: 🟡 MEDIA

CATEGORÍA 5: Riesgos de Reputación y Trust

13. Falta de Transparencia / "Black Box"

RIESGO:
Usuarios/reguladores no confían en sistema que no pueden entender

SEÑALES DE ALERTA:
- No puedes explicar decisiones individuales
- "El algoritmo lo decidió" es tu respuesta
- Usuarios sorprendidos por decisiones
- Media cobertura negativa de falta de transparency

MITIGACIÓN:
□ Explainability tools (SHAP, LIME) para decisiones
□ Model cards documentando capabilities/limitations
□ User-facing explanations en lenguaje simple
□ Disclosure de uso de IA

SEVERIDAD: 🟡 MEDIA
PROBABILIDAD: 🔴 ALTA

14. Uso No Ético / Daño Social

RIESGO:
Sistema usado de manera que causa daño neto a sociedad

SEÑALES DE ALERTA:
- Optimizas solo profit, ignoras externalities
- Uso adictivo, polarización, desinformación
- Weaponization del sistema
- Falta de ethical review

MITIGACIÓN:
□ Ethics board review de proyectos
□ Impact assessment: beneficio social vs daño
□ Rechazar proyectos con daño neto esperado
□ Monitoring de outcomes sociales, no solo KPIs

SEVERIDAD: 🔴 ALTA (reputacional + social)
PROBABILIDAD: 🟢 BAJA (si tienes ethics framework)

15. Hallucinations / Información Falsa (LLMs)

RIESGO:
LLM genera información falsa, peligrosa, o dañina

SEÑALES DE ALERTA:
- LLM sin guardrails
- Usado para domains críticos (medical, legal, financial)
- No hay human review de outputs
- Usuarios confían ciegamente

MITIGACIÓN:
□ Guardrails robustos (content filtering)
□ Grounding en sources verificables
□ Disclaimers claros ("puede contener errores")
□ Human-in-loop para decisiones críticas
□ Citation/sourcing de claims

SEVERIDAD: 🔴 ALTA (si es critical domain)
PROBABILIDAD: 🔴 ALTA (inherente a LLMs)

---

Framework de Governance de IA

Estructura Organizacional

NIVEL 1: BOARD / C-SUITE
├─ Approves AI strategy y budget
├─ Accountable por outcomes
└─ Reviews major incidents

NIVEL 2: AI ETHICS BOARD / COMMITTEE
├─ Reviews high-risk projects
├─ Aproba/rechaza basado en ethical criteria
├─ Quarterly audits de sistemas existentes
└─ Composición: Legal, Ethics, Tech, Business, External experts

NIVEL 3: AI PRODUCT OWNERS
├─ Responsables de proyectos específicos
├─ Implementan guidelines de ethics board
├─ Reportan metrics de fairness/compliance
└─ Accountable por performance y riesgos

NIVEL 4: DATA SCIENCE / ML TEAMS
├─ Implementan controles técnicos
├─ Auditorías de datos y modelos
├─ Monitoring continuo
└─ Escalation de riesgos identificados

Proceso de Revisión de Proyectos

FASE 1: PROPUESTA (Semana 0)
├─ Use case y justificación de negocio
├─ Risk assessment inicial
├─ Datos requeridos
└─ Si es high-risk → Ethics Board review requerido

FASE 2: DISEÑO (Semanas 1-2)
├─ DPIA (si aplica)
├─ Fairness constraints definidos
├─ Security architecture
├─ Human-in-loop design
└─ Ethics Board approval (si high-risk)

FASE 3: DESARROLLO (Semanas 3-8)
├─ Data audits
├─ Model audits
├─ Security testing
├─ Adversarial testing
└─ Checkpoint reviews con Product Owner

FASE 4: PRE-DEPLOYMENT (Semana 9-10)
├─ Compliance checklist completo
├─ Legal review
├─ Pilot con monitoreo intensivo
├─ Incident response plan
└─ Ethics Board final approval

FASE 5: MONITORING (Post-deployment)
├─ Dashboard de fairness/performance
├─ Quarterly audits
├─ User feedback
└─ Continuous improvement

Decision Tree: ¿Es High-Risk?

¿El sistema toma decisiones que afectan:
├─ Empleo o opportunities económicas?        → SÍ → HIGH-RISK
├─ Acceso a servicios esenciales?            → SÍ → HIGH-RISK
├─ Libertad/seguridad de individuos?         → SÍ → HIGH-RISK
├─ Procesa datos sensibles (health, biometric)? → SÍ → HIGH-RISK
├─ Usa datos de >100,000 personas?           → SÍ → HIGH-RISK
└─ Nada de lo anterior?                      → MEDIUM/LOW-RISK

HIGH-RISK → Requiere:
- Ethics Board approval
- DPIA completo
- Fairness audits trimestrales
- Human-in-loop obligatorio
- Legal review

MEDIUM-RISK → Requiere:
- Product Owner approval
- Risk assessment básico
- Security review
- Monitoring de performance

LOW-RISK → Requiere:
- Standard development process
- Basic compliance checks

---

Templates Prácticos

Template: Model Card

# MODEL CARD: [Nombre del Modelo]

## MODEL DETAILS
- **Tipo:** [ej: Classification, Regression, LLM]
- **Versión:** [1.0.0]
- **Fecha:** [2025-01-15]
- **Owner:** [Equipo/Persona responsable]

## INTENDED USE
- **Primary Use:** [Para qué fue diseñado]
- **Out-of-Scope Uses:** [Para qué NO debe usarse]
- **Users:** [Quién lo usará]

## TRAINING DATA
- **Fuente:** [De dónde vienen los datos]
- **Tamaño:** [N ejemplos, features]
- **Período:** [Datos de qué período]
- **Demographics:** [Representación de grupos]

## PERFORMANCE
- **Accuracy:** [Overall: 92%]
- **Performance por Grupo:**
  - Grupo A: 94%
  - Grupo B: 88%
  - Grupo C: 91%

## FAIRNESS METRICS
- **Demographic Parity:** [0.96]
- **Equal Opportunity:** [0.94]
- **Disparate Impact:** [0.92]

## LIMITATIONS
- [Limtación 1: ej: No funciona bien con datos de menores]
- [Limitación 2: ej: Degradación esperada si mercado cambia]
- [Limitación 3: ej: Require human review en casos grises]

## ETHICAL CONSIDERATIONS
- [Consideración 1: Riesgo de sesgo por X]
- [Mitigación: Implementamos Y]

## MONITORING PLAN
- **Metrics:** [Qué se monitorea]
- **Frequency:** [Trimestral]
- **Alerts:** [Si accuracy cae >5%, disparate impact <0.85]

Template: Risk Assessment

# RISK ASSESSMENT: [Proyecto IA]

## PROJECT OVERVIEW
- **Objetivo:** [Qué problema resuelve]
- **Stakeholders:** [Quién se beneficia/afecta]
- **Risk Level:** [HIGH / MEDIUM / LOW]

## RISK CATEGORIES

### 1. FAIRNESS RISKS
- **Riesgo Identificado:** [ej: Sesgo en datos históricos]
- **Probabilidad:** [ALTA / MEDIA / BAJA]
- **Impacto:** [ALTO / MEDIO / BAJO]
- **Mitigación:** [Auditoría de datos, fairness constraints]
- **Owner:** [Persona responsable]

### 2. PRIVACY RISKS
- **Riesgo Identificado:** [ej: Datos sensibles en training]
- **Probabilidad:** [ALTA / MEDIA / BAJA]
- **Impacto:** [ALTO / MEDIO / BAJO]
- **Mitigación:** [Anonimización, encriptación]
- **Owner:** [Persona responsable]

[Repetir para: Security, Reliability, Legal, Reputational]

## APPROVAL
- **Product Owner:** [Firma y fecha]
- **Ethics Board:** [Firma y fecha, si high-risk]
- **Legal:** [Firma y fecha, si high-risk]

---

Ejercicio Práctico: Audita Tu Proyecto

Toma un proyecto de IA actual o propuesto en tu organización.

Paso 1: Evalúa contra los 7 Principios

Para cada principio, rate 1-5:
1 = No cumple en absoluto
5 = Cumple completamente

FAIRNESS: ___/5
¿Auditas sesgos? ¿Mides fairness?

RELIABILITY: ___/5
¿Testeas edge cases? ¿Fail-safes?

PRIVACY: ___/5
¿Data minimization? ¿Encriptación?

INCLUSIVENESS: ___/5
¿Accesible para todos? ¿Data diversa?

TRANSPARENCY: ___/5
¿Explicable? ¿Documentado?

ACCOUNTABILITY: ___/5
¿Roles claros? ¿Auditorías?

SOCIETAL BENEFIT: ___/5
¿Beneficio neto positivo?

TOTAL: ___/35

Interpretación:

• 30-35: Excelente. Estás en buen camino.
• 20-29: Bien, pero áreas de mejora claras.
• 10-19: Preocupante. Necesitas acciones correctivas.
• <10: Crítico. Considera pausar hasta mejorar.

Paso 2: Aplica Checklist de 15 Riesgos

Para cada riesgo, marca:
✓ = Mitigado adecuadamente
⚠️ = Mitigado parcialmente
❌ = No mitigado

1. Sesgo en datos: [✓/⚠️/❌]
2. Disparate impact: [✓/⚠️/❌]
3. Feedback loops: [✓/⚠️/❌]
4. Data breach: [✓/⚠️/❌]
5. Model extraction: [✓/⚠️/❌]
6. Re-identificación: [✓/⚠️/❌]
7. Model drift: [✓/⚠️/❌]
8. Edge case failure: [✓/⚠️/❌]
9. Adversarial attacks: [✓/⚠️/❌]
10. GDPR/CCPA: [✓/⚠️/❌]
11. Discriminación legal: [✓/⚠️/❌]
12. Industry regulations: [✓/⚠️/❌]
13. Falta transparencia: [✓/⚠️/❌]
14. Uso no ético: [✓/⚠️/❌]
15. Hallucinations: [✓/⚠️/❌]

Cuenta:
- ❌: ___ (Crítico: necesita acción inmediata)
- ⚠️: ___ (Alerta: necesita mejora)
- ✓: ___ (Bien: mantener)

Si tienes >3 ❌ en riesgos HIGH severity: → NO desplegar hasta mitigar.

Paso 3: Plan de Acción

## RIESGOS CRÍTICOS (❌)

### Riesgo 1: [Nombre]
- **Acción:** [Qué harás]
- **Owner:** [Quién]
- **Deadline:** [Cuándo]
- **Recursos:** [Qué necesitas]

[Repetir para cada ❌]

## MEJORAS (⚠️)

### Riesgo X: [Nombre]
- **Acción:** [Qué harás]
- **Owner:** [Quién]
- **Deadline:** [Cuándo]

[Repetir para cada ⚠️]

---

Resumen: IA Responsable en Acción

Los 7 Principios (Recordatorio)

1. Fairness - Trata a todos equitativamente
2. Reliability - Funciona segura y consistentemente
3. Privacy - Protege datos personales
4. Inclusiveness - Accesible y beneficioso para todos
5. Transparency - Explicable y comprensible
6. Accountability - Roles claros, responsabilidad humana
7. Societal Benefit - Beneficia a la sociedad

Compliance en Una Página

GDPR:

• Lawful basis (consent, contract, legitimate interest)
• Right to explanation para decisiones automatizadas
• Data minimization
• Right to erasure
• DPIA para high-risk

CCPA:

• Right to know qué datos tienes
• Right to delete
• Right to opt-out de venta
• No discriminar a quienes ejercen derechos

Checklist Rápido Pre-Deployment

□ Auditamos datos y modelo por sesgos
□ Medimos fairness, no solo accuracy
□ Datos sensibles están protegidos (encriptación)
□ Consent es explícito y withdrawable
□ Podemos explicar decisiones
□ Hay human-in-loop para decisiones críticas
□ Monitoring de performance y fairness en producción
□ Proceso de apelación disponible
□ DPIA completado (si high-risk)
□ Legal/compliance revieweó el sistema
□ Incident response plan definido
□ Model card y documentación completa
□ Ethics board approveó (si high-risk)
□ Plan de auditorías regulares
□ Stakeholders entrenados en uso responsable

Si marcaste <12/15: Necesitas más trabajo antes de desplegar.

---

Próximos Pasos

Has completado el Módulo 5: Ética y Responsabilidad.

En el Módulo 6: Implementación aprenderás:

• Los 7 errores fatales al implementar IA
• Cómo lanzar tu primer piloto exitoso
• Roadmap de 90 días para escalar IA

Reflexión Final:

"IA Responsable no es un checklist que completas una vez. Es un commitment continuo con fairness, transparency y accountability. La diferencia entre empresas que construyen confianza y las que la destruyen no es la perfección—es la disposición a auditar, aprender, corregir y priorizar el bienestar humano sobre la conveniencia técnica."

Tu Acción Esta Semana:

Aplica el Checklist de 15 Riesgos a un proyecto de IA en tu organización. Identifica los top 3 riesgos no mitigados y propón plan de acción.

---

Recursos Adicionales:

• Framework: Microsoft's Responsible AI Standard
• Tool: Google's Model Card Toolkit
• Guía: EU AI Act Compliance Checklist
• Libro: "Ethics of Artificial Intelligence and Robotics" (Stanford Encyclopedia)
• Community: Partnership on AI (partnershiponai.org)