Producto de IA — Módulo 10: riesgo, cumplimiento e IA responsable

En el módulo 9 armamos el equipo y el modelo operativo: quién construye, quién opera y qué roles de riesgo y cumplimiento hacen falta desde el día uno. Ese módulo respondió quién se ocupa del riesgo. Este responde de qué se ocupa, y por qué. Porque el riesgo de un producto de IA tiene una trampa temporal: no aparece en el roadmap. Un modelo que discrimina, uno que filtra datos personales, uno que toma una decisión de alto impacto sin que un humano la pueda revisar — nada de eso rompe una demo ni falla un test. Funciona perfecto hasta el día que le llega el caso equivocado, y para entonces ya no es un ajuste de producto: es un titular, una multa o una demanda. Este módulo es sobre ver ese riesgo cuando todavía es una decisión de diseño y no un incidente.

La tesis del módulo

El riesgo de un producto de IA no es un trámite legal al final, es una dimensión de diseño desde el principio. Un modelo que discrimina, filtra datos o toma una decisión de alto impacto sin supervisión no es un bug tardío: es una decisión de producto que alguien no tomó a tiempo. La IA responsable no se parcha en la fase de auditoría — se diseña en la fase de definición, o no existe.

Por qué el cumplimiento llega tarde y por qué eso es caro

En el software tradicional, el compliance suele ser un checklist al final: se construye, se audita, se corrige, se lanza. Con un producto de IA ese orden se rompe por una razón concreta: muchas de las decisiones que crean riesgo se toman en la definición del caso de uso y en la elección de los datos, no en el código. Cuando decides que tu modelo aprenda del historial de aprobaciones de crédito de la empresa, ya heredaste el sesgo de ese historial — no hay refactor que lo saque después sin rehacer el dataset. Cuando decides que el agente ejecute la acción sin confirmación humana, ya definiste el perfil de riesgo — auditar eso al final solo confirma lo que se decidió mal al principio.

De ahí la regla operativa del módulo, hermana de la del equipo: la evaluación de riesgo no es una etapa, es una columna que acompaña cada caso de uso desde que entra al roadmap. El rol que la sostiene lo definimos en el módulo anterior; el mapa de amenazas técnicas que la alimenta vive en el Curso de Seguridad. Aquí conectamos las dos cosas: qué gestiona ese equipo, con qué marco, y en qué momento.

Clasificar el riesgo del caso de uso

El primer error de gestión es tratar todos los productos de IA como si tuvieran el mismo riesgo. No lo tienen. Un asistente de escritura que sugiere una frase y un sistema de scoring crediticio (puntaje que decide si a una persona se le da un préstamo) son universos distintos, aunque ambos sean “IA”. El primero, si se equivoca, molesta; el segundo, si se equivoca, le niega la casa a alguien. Clasificar el riesgo antes de construir es lo que evita gastar controles de aeropuerto en un caso de uso de juguete — y, peor, lo que evita tratar un caso de alto impacto con la ligereza de un juguete.

Tres preguntas ordenan la clasificación:

1. ¿A quién afecta la decisión? No es lo mismo un sistema interno que solo ven empleados que uno que toca a clientes, a solicitantes de un beneficio o al público general. Cuantas más personas y más vulnerables, más alto el riesgo.
2. ¿Qué decisión toma? ¿Sugiere, prioriza, o decide? Un sistema que recomienda a un humano que decide es distinto de uno que ejecuta la decisión solo. La frontera del riesgo es la autonomía: cuánta acción irreversible ocurre sin un humano en el medio.
3. ¿Qué tan reversible es? Un texto sugerido se borra. Un préstamo negado, un diagnóstico errado o un contrato cancelado dejan huella. La reversibilidad barata baja el riesgo; la irreversibilidad lo dispara.

De estas tres sale una idea que atraviesa todo el módulo: la supervisión humana (human oversight, un humano que puede revisar, corregir o vetar la decisión de la IA) debe ser proporcional al riesgo. A más impacto, menos automatización ciega. No se trata de meter un humano en todo — eso mata el producto — sino de meterlo exactamente donde la decisión es alta y difícil de deshacer.

Ojo: el riesgo no lo define la tecnología, lo define el uso. El mismo modelo de lenguaje puede ser riesgo mínimo (redactar un correo) o alto riesgo (filtrar currículums para una contratación). La regulación moderna clasifica por caso de uso, no por modelo — y tu gestión también debería.

El mapa regulatorio (estado 2025–2026)

No necesitas ser abogado, pero sí necesitas saber qué te exige cada marco, a quién aplica y cuál es voluntario y cuál obligatorio. Cuatro piezas cubren casi todo el terreno para un producto que opera en Europa, Estados Unidos o Chile.

EU AI Act — el reglamento europeo basado en riesgo

Es el marco obligatorio de referencia mundial y organiza los sistemas de IA en cuatro niveles de riesgo, con obligaciones proporcionales a cada uno:

• Riesgo inaceptable (prohibido). Prácticas vetadas de plano — como el social scoring estatal o la manipulación subliminal. Las prohibiciones aplican desde el 2 de febrero de 2025.
• Alto riesgo. Sistemas que tocan decisiones sensibles (crédito, empleo, educación, salud, justicia, infraestructura crítica). Cargan las obligaciones más pesadas: gestión de riesgo, calidad de datos, documentación técnica, registro, transparencia y supervisión humana. Según el texto del Reglamento, las obligaciones del Anexo III aplican desde el 2 de agosto de 2026; el calendario ha sido objeto de discusión, así que verifica la fecha vigente antes de planificar.
• Riesgo limitado. Obligaciones de transparencia: avisar que se interactúa con una IA, etiquetar contenido generado. Aplica desde el 2 de agosto de 2026.
• Riesgo mínimo. Sin obligaciones específicas (la mayoría de las aplicaciones).

Aparte, los modelos de propósito general — GPAI (General-Purpose AI, modelos base como los que dan vida a los asistentes) — tienen obligaciones propias de transparencia y documentación del entrenamiento, vigentes desde el 2 de agosto de 2025. El Reglamento aplica de forma extraterritorial: si tu producto llega a personas en la UE, te alcanza aunque tu empresa esté en otro continente.

NIST AI RMF — el marco estadounidense voluntario

El NIST AI Risk Management Framework (marco de gestión de riesgo de IA del instituto de estándares de EE. UU., publicado en enero de 2023) es voluntario: no es una ley, es una guía para organizar el trabajo. Su núcleo son cuatro funciones que se ejecutan de forma iterativa, no en fila:

• Govern (gobernar): políticas, responsabilidades y cultura; es la base que sostiene a las otras tres.
• Map (mapear): entender el contexto del sistema y sus posibles impactos.
• Measure (medir): evaluar el riesgo con métricas cuantitativas y cualitativas.
• Manage (gestionar): priorizar y tratar los riesgos según lo que definió Govern.

No te obliga a nada, pero es el vocabulario común con el que se conversa el riesgo de IA en el mundo anglosajón — y una excelente estructura para tu propio programa interno.

ISO/IEC 42001 — el sistema de gestión certificable

La ISO/IEC 42001 (publicada en diciembre de 2023) es el primer estándar internacional para un sistema de gestión de IA (AIMS, el conjunto de políticas y procesos con que una organización gestiona su IA de forma responsable). Su gran diferencia con el NIST: es certificable. Un organismo externo audita tu sistema de gestión y, si cumple, emite un certificado válido por tres años con auditorías anuales. Usa la misma arquitectura que otras normas ISO (contexto, liderazgo, planificación, soporte, operación, evaluación, mejora), así que si ya tienes ISO 27001 de seguridad, buena parte del camino está andado. Es la pieza que le da a un cliente o a un regulador una prueba verificable por un tercero de que tu gobernanza no es solo un PDF.

Protección de datos — GDPR y la Ley 21.719 chilena

Toda IA que procesa datos de personas cae bajo las leyes de datos personales. En Europa, el GDPR. En Chile, la Ley 21.719, publicada el 13 de diciembre de 2024, que entra en plena vigencia el 1 de diciembre de 2026. Esta ley crea una Agencia de Protección de Datos Personales con potestad para investigar, multar y ordenar suspensiones de tratamiento; establece la obligación de notificar brechas de seguridad a la Agencia y multas de hasta 20.000 UTM (o 4% de los ingresos en caso de reincidencia). Aplica a toda organización que trate datos personales en Chile, sin importar su tamaño. Para un producto de IA esto significa: base legal para usar los datos, minimización, y — crítico — respetar los derechos de las personas sobre decisiones automatizadas.

Marco	Tipo	A quién aplica	Qué le exige a tu producto
EU AI Act	Obligatorio	Quien ofrece IA en la UE (extraterritorial)	Clasificar por riesgo; alto riesgo: gestión de riesgo, datos, docs, supervisión humana; transparencia
NIST AI RMF	Voluntario	Cualquiera (referencia EE. UU.)	Estructura de gobernanza: Govern, Map, Measure, Manage
ISO/IEC 42001	Voluntario, certificable	Cualquiera que quiera prueba de un tercero	Sistema de gestión de IA auditable y certificado
GDPR / Ley 21.719	Obligatorio	Quien trata datos personales (UE / Chile)	Base legal, minimización, derechos, notificación de brechas

Cuidado: no confundas voluntario con opcional para tu negocio. El NIST y la ISO 42001 no te multan, pero tus clientes empresariales cada vez más los exigen en la evaluación de proveedores. Un marco voluntario ignorado hoy es un contrato perdido mañana.

Sesgo y equidad: un riesgo de negocio, no solo ético

El sesgo (bias, cuando el modelo trata sistemáticamente peor a un grupo de personas) no es un defecto moral abstracto: es un riesgo medible con consecuencias de negocio directas — multas regulatorias, demandas, fuga de clientes y daño de marca. Y casi nunca nace de una mala intención; nace de tres fuentes técnicas:

• Los datos. Si el histórico refleja una realidad desigual (menos mujeres contratadas en cierto rol, menos crédito aprobado en cierta zona), el modelo aprende a reproducir esa desigualdad y la presenta como objetividad.
• Las etiquetas. Si quienes etiquetaron los datos de entrenamiento traían un sesgo, el modelo lo hereda. La etiqueta “buen candidato” está tan sesgada como quien la puso.
• El objetivo. Optimizar “maximizar aprobaciones que se pagan a tiempo” puede, sin decirlo, penalizar a grupos con historiales crediticios más cortos por razones estructurales, no de riesgo real.

La trampa clásica es el modelo que funciona en promedio pero falla para un grupo: 94% de acierto global suena bien, hasta que se desagrega y resulta que el 94% es 97% para el grupo mayoritario y 71% para una minoría. El promedio escondió a las personas para quienes el producto no funciona — exactamente la misma lógica de “el promedio esconde el caso grave” que vimos en red teaming. Por eso la equidad se mide desagregando por grupo con métricas de fairness (a alto nivel: comparar tasas de acierto, de falsos positivos o de aprobación entre grupos y exigir que la brecha esté bajo un umbral). No hay una única métrica correcta — hay que elegir cuál importa para tu caso — pero la regla de gestión es simple: un modelo que no se evaluó por grupo no se evaluó.

Supervisión humana como control de producto

La supervisión humana (human-in-the-loop, un humano dentro del ciclo de decisión) no es un consuelo ético: es el control de riesgo más potente que tiene un producto de IA, porque corta la irreversibilidad. La pregunta de diseño no es “¿ponemos un humano?”, sino “¿qué decisiones de este producto no se automatizan del todo, nunca?”.

La respuesta la da la clasificación de riesgo de arriba: donde el impacto es alto y la acción es irreversible, un humano confirma antes de ejecutar. Es la misma lógica de la gobernanza de agentes del Curso de Seguridad — allí, tools destructivas con confirmación explícita; aquí, decisiones de alto impacto con revisión humana. En ambos casos el principio es idéntico: la autonomía se otorga en proporción inversa al daño que puede causar un error. Un buscador puede ser 100% autónomo; un sistema que despide, deniega crédito o diagnostica, no.

IA responsable operacionalizada

“IA responsable” suena a diapositiva de relaciones públicas. Deja de sonar a eso cuando se convierte en cuatro prácticas concretas que dejan rastro:

• Transparencia. Avisar que quien atiende es una IA, y etiquetar el contenido que genera. No es cortesía: en riesgo limitado del EU AI Act es obligación.
• Explicabilidad proporcional. Dar una razón entendible de la decisión, con detalle proporcional al impacto. A un usuario al que se le negó un crédito no le sirve “el modelo dijo que no”; le corresponde saber por qué y cómo apelar.
• Privacidad por diseño. Minimizar los datos que se recogen y procesan desde el diseño, no como añadido. La ley de datos lo exige; la buena ingeniería lo agradece.
• Registro de decisiones. Guardar qué decidió el sistema, con qué entrada y — cuando hubo — qué humano lo revisó. Sin ese registro no puedes auditar, no puedes apelar y no puedes demostrarle nada a un regulador.

Ninguna de las cuatro es PR. Las cuatro son diseño, y las cuatro se decidieron — bien o mal — mucho antes de la auditoría.

Artefacto: plantilla de evaluación de riesgo del caso de uso

Esta es la columna que acompaña cada caso de uso en el roadmap. Se llena antes de construir, en una página. Ejemplo ilustrativo (cifras y niveles inventados para mostrar el formato, no datos reales):

# Evaluación de riesgo — Caso de uso: "Pre-filtro de currículums"

Impacto de la decisión ...... ALTO
  A quién afecta ............ Candidatos externos a un empleo
  Qué decisión toma ......... Descarta CVs antes de que un humano los vea
  Reversibilidad ............ Baja (un CV descartado no se revisa)

Nivel regulatorio
  EU AI Act ................. ALTO RIESGO (empleo, Anexo III)
  Datos personales .......... Sí (GDPR / Ley 21.719 aplican)

Sesgo y equidad
  Fuente de sesgo probable .. Histórico de contrataciones desiguales
  Métrica a monitorear ...... Tasa de descarte desagregada por género/edad
  Umbral de brecha .......... < 5 puntos porcentuales entre grupos

Controles requeridos
  [x] Evaluación de fairness por grupo antes de lanzar
  [x] Registro de cada decisión con la entrada usada
  [x] Aviso de que interviene IA + vía de apelación
  [x] Revisión legal de base de datos

Supervisión humana .......... OBLIGATORIA
  Ningún CV se descarta solo: la IA prioriza, un reclutador decide

Decisión ..................... [ ] Aprobado  [x] Aprobado con condiciones
  Condición: no pasa a producción sin el reporte de fairness firmado
  Dueño del riesgo: Lead de Producto + Compliance
  Fecha de revisión: cada 3 meses

Lo que hace útil a la plantilla no es el formato, es la línea de decisión al final: obliga a alguien con nombre a firmar que aceptó el riesgo residual, con condición y fecha. Un riesgo aceptado por escrito es gobernanza; un riesgo aceptado en silencio es un incidente futuro con más pasos.

Diagrama: del nivel de riesgo a los controles proporcionales

La idea completa del módulo en una imagen — a más riesgo, más controles y menos autonomía:

  NIVEL DE RIESGO           CONTROLES PROPORCIONALES

 ┌──────────────┐
 │   MÍNIMO     │ ──► sin obligaciones; buenas
 │ (redactar,   │     prácticas internas
 │  resumir)    │
 └──────┬───────┘
        │
        ▼
 ┌──────────────┐
 │   LIMITADO   │ ──► transparencia: avisar
 │ (chatbot de  │     "esto es IA", etiquetar
 │  atención)   │     lo generado
 └──────┬───────┘
        │
        ▼
 ┌──────────────┐
 │    ALTO      │ ──► gestión de riesgo + datos
 │ (crédito,    │     + registro + fairness
 │  empleo,     │     + SUPERVISIÓN HUMANA
 │  salud)      │     obligatoria
 └──────┬───────┘
        │
        ▼
 ┌──────────────┐
 │ INACEPTABLE  │ ──► no se construye:
 │ (scoring     │     está prohibido
 │  social)     │
 └──────────────┘

Leído de abajo hacia arriba también funciona: la pregunta de gestión no es “¿cuánta IA le ponemos?”, sino “¿en qué nivel cae este caso y qué controles exige ese nivel?”. El nivel se decide primero; los controles se derivan.

Errores comunes

• Tratar el cumplimiento como una etapa final. Las decisiones que crean el riesgo (elegir los datos, definir la autonomía) se toman en la definición del caso de uso. Auditar al final solo confirma lo que se decidió mal al principio.
• Clasificar por tecnología en vez de por uso. “Es solo un LLM” no dice nada del riesgo. El mismo modelo es mínimo redactando y alto riesgo filtrando currículums. Clasifica el caso de uso, no el modelo.
• Confundir voluntario con opcional. El NIST y la ISO 42001 no multan, pero los clientes empresariales los exigen en su evaluación de proveedores. Ignorarlos hoy es perder contratos mañana.
• Medir la calidad solo en promedio. Un 94% global puede esconder un 71% para una minoría. La equidad se mide desagregando por grupo, o no se mide.
• Poner un humano “de adorno”. Supervisión humana no es un botón que nadie mira: es un humano con tiempo, contexto y poder real de vetar. Si no puede decir que no, no es supervisión.
• Aceptar riesgo sin dueño ni fecha. Un riesgo residual está bien — aceptarlo en silencio no. Sin firma, condición y revisión, no es gobernanza: es una omisión esperando su turno.

La frase para llevarse

“El cumplimiento de un producto de IA no se audita al final: se diseña al principio. Cuando el riesgo llega al roadmap, ya es tarde para que sea barato — el modelo que discrimina o filtra datos no falló, hizo exactamente lo que alguien decidió no impedir a tiempo.”

Qué viene

Módulo 11: lanzamiento y adopción. Ya sabes construir el caso, priorizar, medir, financiar, formar el equipo y gestionar el riesgo. Falta lo que decide si todo eso importó: que la gente use el producto. Vamos a ver por qué la adopción de IA falla distinto que la de un software normal — la desconfianza, la curva de aprendizaje, el rechazo del experto que siente que lo reemplazan — y cómo se diseña un lanzamiento que gana esa confianza en vez de asumirla.

Material relacionado

• Módulo 9: equipo y modelo operativo
• Módulo 11: lanzamiento y adopción
• Modelo de amenazas de la IA
• Incidentes y gobernanza
• Red teaming y seguridad
• Glosario de Producto de IA