Responsible AI Principles and Model Governance

Resumen

La diferencia entre un modelo que la organización adopta y uno que abandona rara vez es la métrica de evaluación: es la confianza. Y la confianza se construye con principios que se pueden operacionalizar —IA responsable e explicable— y con disciplina de gobernanza sobre el activo: versiones conocidas, métricas vinculadas, despliegues controlados, supervisión continua y responsables identificables. Este tema desarrolla ambas caras.

La IA responsable responde a la pregunta de si el sistema debe operarse: si es equitativo, si tiene responsables, si puede examinarse, si protege la privacidad y si es seguro. La IA explicable responde a una pregunta más concreta y frecuente: por qué este modelo decidió esto. Ambas dejan de ser principios abstractos en cuanto aparece un caso concreto —una solicitud denegada, una reclamación clasificada con prioridad baja, un informe de riesgo— y alguien exige una respuesta que se sostenga.

El sesgo y la equidad ocupan el centro de la discusión porque el modelo aprende de datos históricos que contienen desigualdades y decisiones pasadas con sus limitaciones. Evaluar la equidad no es una comprobación única: es acordar qué diferencias de resultado son inaceptables, medir el rendimiento por segmento en evaluación y en producción, y corregir en datos, objetivo o umbral con dueño del negocio.

Sobre ese marco se apoya la gobernanza técnica, materializada en Vertex AI: el Model Registry como registro de versiones con métricas y trazabilidad, Model Garden como catálogo de modelos con documentación, controles de acceso y revisión de seguridad, Explainable AI como fuente de atribuciones de la predicción, y la monitorización de modelos como sistema de detección de deriva en producción. Junto a la supervisión técnica va el ciclo de vida documentado —propósito, datos, métricas, límites, aprobación, revisión y retirada— que convierte la responsabilidad en una práctica repetible.

Objetivos de Aprendizaje

Al terminar este contenido, serás capaz de:

Enumerar los principios de IA responsable y traducir cada uno a una exigencia operativa concreta.
Explicar qué es la IA explicable, qué técnicas de atribución aportan y hasta dónde llega su alcance.
Identificar las fuentes de sesgo en el ciclo de vida de un modelo —datos, etiquetas, objetivo y despliegue— y sus efectos observables.
Describir cómo se evalúa la equidad por segmentos y por qué no existe una métrica única que la certifique.
Explicar la función de gobernanza del Vertex AI Model Registry: versionado, métricas vinculadas, trazabilidad y despliegue controlado.
Describir el papel de Model Garden en la selección y adopción segura de modelos de Google, socios y código abierto.
Distinguir los tipos de deriva —de datos, de predicciones y de relación entre variables y resultado— y su detección en producción.
Diseñar un ciclo de vida gobernado de modelos: documentación, aprobación, despliegue, monitorización, revisión periódica y retirada.
Definir una respuesta a incidentes de modelo: rollback, revisión de causa, reentrenamiento y comunicación.

Contenido Principal

Subtema 1: Principios de IA responsable e IA explicable

La IA responsable es el conjunto de exigencias que un sistema de IA debe satisfacer para que su operación sea defendible ante usuarios, negocio, auditoría y regulador. Google Cloud la formula en cinco áreas que funcionan como lista de verificación: equitativa (fair), responsable (accountable), transparente (transparent), protegida en privacidad (privacy-secured) y segura (safe). Los principios de IA publicados por Google amplían el mismo marco con fines sociales, seguridad probada, rendición de cuentas ante las personas, diseño de privacidad, excelencia científica y restricción de casos de uso.

Su valor práctico es que cada área se traduce en una exigencia verificable:

Principio	Pregunta operativa	Evidencia que hay que poder mostrar
Equitativa	¿Trata de forma aceptable a todos los segmentos relevantes?	Métricas de rendimiento por segmento, en evaluación y en producción
Responsable	¿Hay una persona o equipo dueño del resultado?	Dueño asignado, registro de decisiones y de aprobaciones
Transparente	¿Se puede examinar el sistema y su comportamiento?	Documentación del propósito, datos, métricas y límites
Privacidad	¿Se minimiza y protege el dato personal?	Diseño de datos, permisos, ubicación y tratamiento registrado
Segura	¿Resiste usos indebidos y entradas adversas?	Pruebas de seguridad, límites de uso y controles de acceso

La IA explicable es la capacidad de justificar una predicción concreta. En modelos tabulares, la explicación habitual es la atribución de características: para la decisión de hoy, qué variables contribuyeron, en qué dirección y con qué peso. Vertex AI incorpora esta capacidad con Explainable AI, y BigQuery ML ofrece funciones de explicación de sus modelos. La explicabilidad tiene cuatro usos de negocio: detectar que el modelo apoya variables inadecuadas (incluidos proxies de atributos protegidos), responder a una persona afectada o a un auditor, dar contexto a la revisión humana y sostener la confianza interna de los equipos que deben usar el sistema.

Conviene ser preciso sobre los límites: explicar qué variables influyeron no es lo mismo que justificar la decisión en términos normativos, ni garantiza que el modelo sea correcto. La explicabilidad es una condición necesaria de la responsabilidad, no su sustituto; se combina con evaluación de equidad, documentación de límites y supervisión del comportamiento en producción.

Subtema 2: Sesgo y equidad: dónde entra y cómo se gestiona

El sesgo aparece en cualquier punto del ciclo donde se tome una decisión con efecto sobre la señal que el modelo aprenderá. Reconocer la fuente importa porque cada una tiene una corrección distinta:

Sesgo histórico y de representación: los datos reflejan decisiones pasadas (créditos concedidos hace años, contrataciones de una época) o subrepresentan a un grupo. El modelo aprende el patrón de aquellas decisiones, no la realidad que podrían haber sido.
Sesgo de medición: la variable usada no mide lo que se cree. Calificar la "satisfacción" con el número de llamadas es medir el problema equivocado; usar el código postal como proxy de renta introduce una variable con carga discriminatoria.
Sesgo de agregación: un único modelo promedio enmascara diferencias entre grupos con comportamientos distintos, y optimiza para la mayoría.
Sesgo de evaluación y despliegue: se evalúa sobre un conjunto que no representa a la población de uso, o el sistema se aplica a un contexto distinto del del entrenamiento.

La gestión de la equidad empieza por una decisión de negocio y de cumplimiento: qué diferencias de resultado se consideran inaceptables. No existe una única métrica universal de equidad —las definiciones formales pueden entrar en conflicto entre sí—, de modo que el trabajo consiste en acordar los criterios aplicables al caso, medir el rendimiento del modelo por segmento con esos criterios, tanto en la evaluación inicial como en la monitorización continua, y corregir donde la brecha sea inaceptable.

Las palancas de corrección se ordenan por el lugar donde se actúa: en los datos (mejorar representación, recoger ejemplos faltantes, corregir etiquetas), en el objetivo (cambiar la variable que se optimiza o añadir restricciones), en el umbral (umbrales distintos por segmento cuando el criterio lo admite) y en el proceso (revisión humana de los casos sensibles). Cualquier corrección tiene un coste en la otra métrica del sistema —más equidad puede bajar la exactitud global, o al revés—, y esa compensación la decide el dueño del negocio con asesoría legal, no el equipo de datos en solitario.

Un error frecuente es tratar la equidad como una comprobación previa al despliegue. Los datos, la población y los usos cambian después, de modo que la medición por segmentos pertenece a la monitorización permanente del modelo, junto a la deriva y al rendimiento agregado.

Fuente de sesgo	Ejemplo concreto	Efecto en el modelo	Corrección típica
Histórico	Entrenar con decisiones de concesión pasadas	Reproduce la discriminación previa	Revisar objetivo, recoger datos del contrafactual
Representación	Pocos ejemplos de un segmento	Peor rendimiento en ese segmento	Muestreo y recogida dirigida
Medición	Proxy con carga discriminativa	El modelo se apoya en la variable equivocada	Sustituir o excluir variable, revisar definiciones
Agregación	Un modelo para públicos distintos	Promedio que no sirve a ninguno bien	Segmentar o añadir variables relevantes
Evaluación	Prueba no representativa del uso real	Buen informe y mal comportamiento	Evaluar sobre la población de despliegue

Subtema 3: Gobernanza de modelos con Vertex AI

La gobernanza de modelos necesita un registro, un catálogo y un sistema de vigilancia. En Vertex AI, esas funciones se materializan en componentes concretos.

Vertex AI Model Registry: el registro. Permite registrar modelos entrenados —de AutoML, de entrenamiento personalizado o de BigQuery ML— con versiones, alias y metadatos, y mantener vinculadas sus métricas de evaluación y su procedencia. Su valor de gobernanza se expresa en cuatro respuestas que un responsable debe poder dar sin depender de la memoria de nadie: ¿qué modelo está desplegado?, ¿qué versión es y con qué métricas se aceptó?, ¿con qué datos y qué entrenamiento se produjo?, y ¿qué otras versiones existen y cómo se comparan? Además, el registro es el punto de partida del despliegue a endpoints y del control de cambios, porque la comparación entre versiones y la reversión a una versión anterior se basan en que las versiones existen y están documentadas.

Vertex AI Model Garden: el catálogo. Reúne modelos de Google —incluida la familia Gemini y modelos de visión, voz y lenguaje—, modelos de socios y modelos de código abierto en un mismo lugar, con documentación de cada modelo, patrones de despliegue consistentes, controles de acceso y revisión de seguridad de los modelos publicados. Su papel de gobernanza es doble: por un lado, evita que los equipos adopten modelos desde fuentes no gobernadas —descargas directas, dependencias opacas—; por otro, obliga a que la elección de modelo se documente frente a la tarea, los requisitos de datos y las condiciones de uso.

Explicabilidad y evaluación: el control. Explainable AI aporta atribuciones de características para entender la influencia de cada variable; las funciones de evaluación permiten comparar versiones con métricas consistentes antes de promover; y la documentación vinculada al modelo sostiene la revisión. Monitorización: la vigilancia. Vertex AI Model Monitoring observa el comportamiento del modelo en servicio y genera alertas cuando la distribución de los datos de entrada, las atribuciones o las predicciones se aleja de la línea base de entrenamiento.

Toda esta capa hereda los controles de la plataforma: quién puede registrar, desplegar o invocar se resuelve con IAM; qué cambios se produjeron, con los registros de auditoría; y cuánto cuesta cada activo, con el etiquetado y la atribución de costes. La gobernanza no se añade como sistema paralelo: se ejerce con la misma identidad y los mismos registros que el resto de la infraestructura.

Ejemplo Práctico

# 1. Inventario de modelos y versiones registrados (¿qué existe y cuándo se creó?)
gcloud ai models list --region=us-central1 --sort-by=~createTime \
  --format="table(name,displayName,createTime)"

# 2. Detalle de un modelo: versión, artefacto y etiquetas de gobierno
gcloud ai models describe MODELO_ID --region=us-central1 \
  --format="yaml(displayName,versionId,artifactUri,createTime,labels)"

# 3. Qué está realmente sirviendo tráfico
gcloud ai endpoints list --region=us-central1 \
  --format="table(name,displayName,createTime)"

# 4. Quién puede gestionar modelos y endpoints (gobierno del despliegue)
gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --format="table(bindings.role,bindings.members)" | grep -E "aiplatform|roles/owner"

Lectura de la salida en términos de negocio. El inventario de modelos con sus fechas revela el ritmo real del programa: muchos modelos creados y pocos con endpoint activo indican experimentación sin producto; modelos muy antiguos en endpoints indican que nadie está revisando su vigencia. El describe con labels es el punto donde la gobernanza se vuelve comprobable: si los modelos no llevan etiquetas de entorno, de dueño o de estado, no hay forma automática de responder quién responde por ellos. Y la política de identidades responde a la pregunta crítica de control: si el permiso de despliegue está concedido a personas individuales en lugar de a grupos con responsabilidad definida, cualquier cambio de modelo ocurre sin trazabilidad de aprobación.

Subtema 4: Supervisión de modelos en producción

Un modelo en producción es un sistema que se degrada sin errores visibles. La supervisión existe para detectar esa degradación a tiempo y para que exista un procedimiento cuando aparece. Los fenómenos a vigilar son distintos y cada uno indica una causa diferente:

Deriva de datos (data drift): cambia la distribución de las variables de entrada respecto a la de entrenamiento. Ejemplo: el perfil de edad de los solicitantes se desplaza tras una campaña. Indica que el modelo opera sobre un mundo distinto del aprendido.
Deriva de predicciones (prediction drift): cambia la distribución de las salidas. Si la proporción de "alto riesgo" se duplica sin cambio en el proceso, hay que averiguar si cambió el mundo, los datos o el modelo.
Skew entre entrenamiento y servicio (training-serving skew): los datos que entran en producción no se parecen a los del entrenamiento por transformaciones distintas, tiempos de captura o definiciones divergentes. Es el fallo silencioso más clásico y suele ser de ingeniería, no del modelo.
Degradación de rendimiento: la exactitud o el recall efectivo caen porque cambió la relación entre variables y resultado (concept drift), aunque las entradas parezcan iguales.

La monitorización de Vertex AI observa estas señales —deriva de características, de atribuciones y de predicciones— y las convierte en alertas; el dato de predicciones conviene además llevarlo a BigQuery para cruzarlo con los resultados reales cuando llegan, que es la única forma de medir el rendimiento verdadero en servicio. Sobre las alertas se define la respuesta: revisar causas, y si la degradación se confirma, reentrenar con datos representativos del periodo nuevo, validar contra las pruebas de aceptación y promover la versión nueva por el mismo camino de aprobación que cualquier otro cambio.

La respuesta a incidentes necesita estar escrita antes del incidente. El patrón mínimo: detectar (alerta o revisión), contener (revertir a la versión anterior si el efecto lo requiere, o reducir el alcance del uso), diagnosticar (datos, definiciones, código, fuente externa), corregir (reentrenamiento, corrección de datos o de proceso) y aprender (documentar y actualizar las pruebas para que el fallo no vuelva a pasar inadvertido). La reversión a una versión previa solo es posible si las versiones existen en el registro y están aprobadas, que es la razón profunda por la que el Model Registry es una pieza de gobierno y no un almacén técnico.

Un punto final sobre ciclo de vida: los modelos también se retiran. Cuando el caso de uso desaparece, la distribución cambia de forma estructural o el coste de mantenerlo supera su valor, el modelo debe salir de producción de forma documentada, con el endpoint retirado, el registro actualizado y el conocimiento del proceso transferido a su dueño. Un inventario de modelos sin fecha de revisión ni retiro es un inventario de riesgo.

Señal	Qué sugiere	Primeras acciones	Responsable típico
Deriva de datos	El mundo de entrada cambió	Confirmar causa externa, evaluar reentrenamiento	Dueño del modelo con datos
Skew entrenamiento/servicio	Definiciones o transformaciones divergentes	Auditar el pipeline de datos y las transformaciones	Ingeniería de datos
Caída de predicciones o de métricas	Degradación del rendimiento o del concepto	Evaluar contra pruebas, decidir reentrenamiento	Dueño del modelo
Aumento de alertas de equidad	Rendimiento desigual por segmento	Revisar segmentos afectados y corrección aplicable	Dueño de negocio con cumplimiento
Modelo sin uso o obsoleto	Caso de uso muerto o sustituido	Retirada documentada del endpoint y del registro	Dueño del proceso

Ejemplo Práctico

# 1. Línea base de entrenamiento: distribución de una variable de entrada
bq query --use_legacy_sql=false "
SELECT COUNT(*) AS filas,
       ROUND(AVG(edad), 1) AS edad_media,
       ROUND(COUNTIF(edad BETWEEN 25 AND 45) / COUNT(*), 3) AS pct_25_45
FROM \`PROJECT_ID.ml.solicitudes_entrenamiento\`"

# 2. Misma variable en el periodo reciente de servicio: ¿se mantiene la distribución?
bq query --use_legacy_sql=false "
SELECT COUNT(*) AS filas,
       ROUND(AVG(edad), 1) AS edad_media,
       ROUND(COUNTIF(edad BETWEEN 25 AND 45) / COUNT(*), 3) AS pct_25_45
FROM \`PROJECT_ID.ml.solicitudes\`
WHERE fecha >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)"

# 3. Rendimiento verdadero en servicio cuando llegan las etiquetas reales
bq query --use_legacy_sql=false "
SELECT COUNTIF(prediccion = resultado_real) / COUNT(*) AS exactitud_servicio,
       COUNT(*) AS decisiones_evaluadas
FROM \`PROJECT_ID.ml.predicciones_con_resultado\`
WHERE fecha >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)"

Lectura de la salida en términos de negocio. Las dos primeras consultas son la comparación que define la deriva: si la proporción de la variable entre entrenamiento y servicio se separa de forma sostenida, el modelo ya no opera sobre el mundo para el que fue aceptado, y toca decidir con el dueño del caso si se reentrena o se acota el uso. La tercera consulta es la única que mide el rendimiento real —la métrica de la evaluación previa valía sobre datos de prueba, no sobre la operación— y por eso las etiquetas tardías deben llegar al mismo almacén donde están las predicciones. Ninguna de las tres necesita un cuadro de mando sofisticado para empezar: necesita que exista el hábito de mirarlas con fecha y con responsable, que es exactamente lo que una alerta sin destinatario no garantiza.

Subtema 5: Operar la responsabilidad: documentación, aprobación y revisión

Los principios se convierten en práctica cuando existen artefactos concretos con responsables. El conjunto mínimo de gobernanza operativa de un modelo tiene cinco piezas:

Ficha del modelo: propósito, caso de uso, datos de entrenamiento, métricas de aceptación, límites conocidos, segmentos vigilados y fecha de revisión. Es el equivalente funcional de la ficha técnica que exige cualquier activo crítico, y es lo que permite que otra persona entienda el sistema sin preguntar a su autor.
Registro de versiones: cada versión promovida a producción queda en el Model Registry con sus métricas y su estado; la promoción exige comparación y aprobación explícita, no solo éxito del entrenamiento.
Aprobación previa: criterios acordados con el dueño de negocio y, cuando aplica, con cumplimiento y seguridad —qué métricas deben aprobar, qué segmentos revisar, qué usos quedan excluidos.
Supervisión activa: monitorización de deriva y rendimiento, alertas con destinatario y revisión periódica con fecha.
Registro de decisiones: quién aprobó cada promoción, qué incidentes hubo, qué cambios de instrucción o de datos se aplicaron.

Este marco se aplica con distinta profundidad según el impacto del uso: un modelo que sugiere contenido interno admite controles ligeros; un modelo que decide sobre acceso a crédito, empleo o servicios exige explicabilidad, evaluación de equidad por segmentos, aprobación formal y supervisión reforzada. Esa proporcionalidad es la parte madura de la gobernanza: no se trata de aplicar el máximo control a todo, sino de clasificar los usos por riesgo y asignar a cada nivel su disciplina.

La última responsabilidad es del proceso, no de la plataforma: los controles de Vertex AI hacen posible la gobernanza, pero la decisión de usar un modelo de forma adecuada, de revisarlo en su fecha y de retirarlo cuando deje de servir corresponde al dueño del caso de negocio. Esa asignación explícita es lo que separa una lista de principios de una práctica de organización.

Ejemplo Práctico

Plantilla mínima de ficha de modelo, mantenida junto al código del proceso y actualizada en cada promoción de versión:

# Ficha del modelo: scoring de solicitudes de crédito
- Propósito y alcance: priorizar revisión humana; NO decide concesión automática
- Dueño del modelo: <rol de negocio>      Revisión: <fecha>
- Datos de entrenamiento: periodo, población, exclusiones conocidas
- Métricas de aceptación: exactitud, recall por segmento, equidad por segmento
  (criterio de brecha acordado con cumplimiento)
- Límites conocidos: sin datos de <segmento>; válido para <contexto> únicamente
- Segmentos vigilados: <lista> con métrica y umbral de alerta
- Versión en producción: <versión en Model Registry>   Aprobación: <quién y cuándo>
- Incidentes y decisiones: registro vinculado con fechas y responsables

Lectura de la plantilla en términos de negocio. Las dos líneas que más se omiten son las que más valor tienen: el alcance —que impide que el modelo se use para algo para lo que no fue aceptado— y la fecha de revisión, que convierte la supervisión en un compromiso con calendario en lugar de una buena intención. El vínculo con la versión del Model Registry es lo que hace trazable la afirmación "el modelo que decide hoy es el que se aprobó"; sin ese enlace, la ficha describe un sistema que ya no existe. Y el campo de límites es el que más protege al equipo: documentar lo que el modelo no puede hacer evita que la organización lo extienda silenciosamente a un caso de uso nuevo donde sus métricas ya no significan nada.

Temas relacionados: AI, Machine Learning and Generative AI Fundamentals, Google Cloud AI Solutions and Vertex AI, Generative AI, Foundation Models and LLMs in Enterprise

Conceptos Clave

Concepto	Descripción	Cuándo usarlo
IA responsable	Marco de equidad, responsabilidad, transparencia, privacidad y seguridad aplicado al ciclo de vida del IA	Al definir, evaluar y operar cualquier sistema de IA
IA explicable	Capacidad de justificar una predicción señalando las variables que la explican	En decisiones sobre personas, auditoría y revisión humana
Atribución de características	Contribución de cada variable a la predicción concreta	Para explicar una decisión individual y detectar variables indebidas
Sesgo (bias)	Desviación sistemática del modelo por datos, objetivo o despliegue	Al evaluar rendimiento desigual o resultados inesperados
Equidad	Tratamiento aceptable de los segmentos relevantes, según criterio acordado	Para acordar qué brechas de resultado son inaceptables
Representación	Proporción y calidad de los ejemplos de cada segmento en los datos	Cuando un grupo tiene peor rendimiento por falta de datos
Training-serving skew	Diferencia entre los datos de entrenamiento y los datos de servicio	Ante métricas que caen sin cambio aparente del mundo
Vertex AI Model Registry	Registro versionado de modelos con métricas, metadatos y estado	Para saber qué está desplegado, con qué métricas y por qué
Vertex AI Model Garden	Catálogo de modelos de Google, socios y código abierto con documentación y controles	Al seleccionar modelos fuera de los entrenados internamente
Explainable AI	Capacidades de Vertex AI para atribuir predicciones a características	Para auditoría, explicación a afectados y revisión humana
Model monitoring	Detección de deriva de datos, de atribuciones y de predicciones	Siempre que un modelo sirve decisiones reales
Data drift	Cambio de la distribución de las variables de entrada	Para decidir la vigencia del entrenamiento actual
Prediction drift	Cambio de la distribución de las salidas del modelo	Como señal temprana de cambio del mundo o del proceso
Rollback de modelo	Reversión a una versión anterior aprobada	En incidentes con impacto sobre decisiones o usuarios

Comparaciones

Eje	Evaluación previa al despliegue	Supervisión en producción
Momento	Antes de promover la versión	De forma continua mientras sirve
Qué mide	Rendimiento y equidad sobre datos de prueba	Deriva, rendimiento observado y alertas
Datos	Conjunto de evaluación representativo	Flujo real de entrada y de predicciones
Acción típica	Aprobar, rechazar o pedir correcciones	Alertar, revisar, reentrenar o revertir
Fallo si no existe	Se despliega un modelo no validado	Se degrada en silencio hasta el incidente

Eje	IA responsable (marco)	IA explicable (técnica)
Alcance	Todo el ciclo de vida y todos los principios	Una predicción concreta y sus variables
Pregunta	¿Debe y puede operarse este sistema? ¿Bajo qué condiciones? ¿Quién responde?	¿Por qué decidió esto el modelo hoy?
Evidencia	Políticas, ficha de modelo, aprobaciones, monitorización, dueños	Atributos de característica, entrada y salida registradas
Límite	Sin técnicas de explicación, parte del marco no es verificable	Explicar no garantiza corrección ni equidad
Relación	Se sostiene con explicabilidad y con supervisión	Es un componente del marco responsable

Nivel de control	Uso de bajo impacto	Uso de alto impacto
Documentación	Ficha breve con propósito y métricas	Ficha completa con límites, segmentos y fecha de revisión
Explicación	Disponible si se solicita	Exigida y registrada para decisiones sensibles
Equidad	Revisión general	Evaluación por segmentos con criterio acordado y aprobación
Supervisión	Monitorización básica de rendimiento	Deriva, equidad y rendimiento con alertas y revisión periódica
Aprobación	Responsable técnico del equipo	Responsable de negocio con validación de cumplimiento

Errores Comunes

Error: Tratar la IA responsable como un documento de principios que se aprueba una vez y no vuelve a aparecer. → Solución: Convertir cada principio en una exigencia verificable con dueño y fecha: métricas por segmento programadas, ficha de modelo obligatoria, aprobación registrada y revisión periódica en calendario. Lo que no tiene responsable y fecha no se ejecuta cuando aparece la presión por entregar.
Error: Evaluar la equidad con una sola métrica global y darla por cerrada antes del despliegue. → Solución: Acordar con negocio y cumplimiento qué diferencias de resultado son inaceptables, medir el rendimiento por segmento —tanto en la evaluación inicial como en la monitorización— y aceptar explícitamente los compromisos entre equidad y exactitud. La equidad no se certifica con un número; se gestiona con criterio y vigilancia continua.
Error: Registrar modelos sin versiones ni métricas, o desplegar directamente desde el artefacto de entrenamiento. → Solución: Exigir que todo modelo que sirva tráfico pase por el Model Registry con su versión, sus métricas de aceptación y sus etiquetas de dueño y entorno. Sin registro, no hay comparación entre versiones, no hay reversión controlada y no hay respuesta ante un incidente.
Error: Confundir explicabilidad con garantía de corrección, o con cumplimiento por sí sola. → Solución: Usar la explicabilidad como una evidencia más —junto con evaluación de equidad, documentación de límites, supervisión y aprobación— y no como sustituto de ellas. La atribución de variables explica una decisión; no dice si el modelo debió tomarla ni si trata bien a todos los segmentos.
Error: Esperar a que el negocio note que "los resultados ya no son los de antes" para revisar el modelo. → Solución: Instrumentar monitorización de deriva y de rendimiento con alertas y destinatarios, llevar las predicciones a un almacén analítico para compararlas con los resultados reales y fijar fechas de revisión. La degradación de un modelo no lanza errores de sistema: sin supervisión, se descubre por pérdida de negocio, que es el modo más caro de enterarse.

Puntos para el Examen

🎯 Punto clave 1: La IA responsable se operacionaliza en cinco áreas —equitativa, responsable, transparente, protegida en privacidad y segura— y cada una exige evidencia verificable. Las preguntas de caso presentan un principio y piden su manifestación concreta: dueño asignado, documentación revisable, métricas por segmento, protección del dato y pruebas de seguridad.

🎯 Punto clave 2: El sesgo entra por los datos (histórico y representación), por las variables (medición y proxies), por el agregado (un modelo para públicos distintos) y por la evaluación (pruebas no representativas). La equidad se evalúa por segmentos con un criterio acordado, porque no existe una métrica única que certifique el resultado.

🎯 Punto clave 3: La IA explicable atribuye la predicción a las variables que la explican y sirve para responder a afectados, detectar variables indebidas y dar contexto a la revisión humana. Su límite debe declararse: explicar no garantiza corrección ni equidad.

🎯 Punto clave 4: Vertex AI aporta gobernanza de modelos con mecanismos identificables: Model Registry para versionado, métricas y trazabilidad; Model Garden para catálogo documentado con controles de acceso y revisión; Explainable AI para atribuciones; y model monitoring para deriva de datos, atribuciones y predicciones.

🎯 Punto clave 5: La supervisión en producción distingue deriva de datos, deriva de predicciones y skew entre entrenamiento y servicio, y cada una apunta a una causa y a un responsable distintos. Sin registro de versiones no hay rollback, y sin dueño ni fecha de revisión la gobernanza se degrada: esa es la lógica que une principios, plataforma y operación.

Recursos Externos

Responsible AI documentation — Prácticas y capacidades de Google Cloud para equidad, explicabilidad, privacidad y seguridad de los sistemas de IA.
Vertex AI Explainable AI — Atribución de características para interpretar predicciones de modelos tabulares.
Vertex AI Model Registry — Registro, versionado y gestión de modelos para su despliegue controlado.
Vertex AI model monitoring — Detección de deriva de datos y de predicciones en modelos en producción.
Google AI Principles — Principios de IA publicados por Google que enmarcan el uso responsable de la tecnología.

Autoevaluación Rápida

Pregunta: Un modelo de scoring rechaza sistemáticamente a un segmento de solicitantes. ¿Por dónde empiezas y qué no debes hacer? Respuesta: Por la evaluación por segmento con el criterio de equidad acordado con negocio y cumplimiento, para confirmar si la brecha es inaceptable y medir su magnitud; después se rastrea la fuente —datos subrepresentados, variable proxy con carga discriminatoria, objetivo heredado de decisiones históricas— y se corrige en el punto identificado. Lo que no se debe hacer es declarar el modelo aceptable por su exactidad global ni corregir el umbral por iniciativa técnica sin dueño de negocio: la compensación entre equidad y exactitud es una decisión documentada.
Pregunta: ¿Qué aporta el Vertex AI Model Registry a la gobernanza y qué sería imposible sin él? Respuesta: Aporta un registro versionado con métricas y metadatos: qué modelo, qué versión, con qué evaluación se aceptó y qué está desplegado. Sin él, no hay comparación controlada entre versiones, no hay reversión a un estado aprobado cuando un modelo falla —rollback—, ni trazabilidad de quién promovió qué y cuándo; la operación depende de la memoria de las personas y la respuesta a un incidente se vuelve lenta y especulativa.
Pregunta: El equipo explica que su modelo es explicable, por lo que la responsabilidad queda cubierta. ¿Es correcto? Respuesta: No. La explicabilidad cubre una parte del marco —la transparencia de decisiones concretas— pero no aporta equidad, ni dueños, ni privacidad, ni seguridad, ni supervisión del comportamiento en el tiempo. Un modelo perfectamente explicado puede discriminar de forma consistente y seguir degradándose en producción. La explicabilidad es una condición necesaria para responder a personas y auditores, y debe combinarse con evaluación de equidad, documentación de límites, aprobación y monitorización.
Pregunta: Distingue deriva de datos, deriva de predicciones y training-serving skew, y di a quién corresponde investigar cada una. Respuesta: La deriva de datos indica que las entradas cambiaron respecto al entrenamiento: corresponde revisar al dueño del modelo con el equipo de datos para decidir reentrenamiento. La deriva de predicciones indica que las salidas se desplazan —puede venir del cambio del mundo, del proceso o del modelo— y exige cruzar con resultados reales. El skew entre entrenamiento y servicio indica que los datos de producción no son los de entrenamiento por transformaciones o definiciones distintas, y es típicamente un hallazgo de ingeniería de datos. Separarlas importa porque cada una lleva a una corrección distinta.
Pregunta: Llega una alerta de que un modelo en producción degrada su rendimiento. ¿Cuál es la respuesta correcta y qué habría que tener preparado de antemano? Respuesta: Contener primero —revertir a la versión anterior si el efecto lo requiere o reducir el alcance del uso—, después diagnosticar (datos, definiciones, cambio externo, código) y corregir validando contra las pruebas de aceptación antes de promover de nuevo. De antemano deben existir: versiones aprobadas en el registro para poder revertir, monitorización con alertas y destinatario, criterios de aceptación escritos, ficha del modelo con límites y dueño, y un procedimiento de incidente con responsables. Sin esos preparativos, la respuesta se improvisa mientras el modelo sigue decidiendo.