Semana 8 · Módulo 8 de 11

Gobierno, cumplimiento e IA responsable

Aprende a gobernar una aplicación de IA generativa en producción: trazabilidad completa con model invocation logging y CloudTrail, linaje de datos y prompts, model cards, cumplimiento (RGPD, EU AI Act, ISO/IEC 42001) y los principios de IA responsable de AWS aplicados con Guardrails, evaluaciones y revisión humana.

Reparto de la semana

Por qué importa

Con este módulo cierras el dominio 3 (20 % del examen): los task statements 3.3 (Implement AI governance and compliance mechanisms) y 3.4 (Implement responsible AI principles).

En el módulo 7 protegiste la aplicación. Ahora tienes que demostrarlo: ante auditoría, ante el delegado de protección de datos, ante un regulador o ante un cliente que pregunta «¿por qué el asistente me denegó el préstamo?». Gobierno es poder responder a cuatro preguntas en cualquier momento:

1. ¿Quién invocó qué modelo, cuándo, con qué prompt y qué respondió?
2. ¿De dónde salió la información de la respuesta (qué documentos, qué versión del prompt, qué versión del modelo)?
3. ¿Qué controles se aplicaron (guardrail, versión, qué intervino) y quién los cambió?
4. ¿Cumple el sistema las normas y los principios de la organización, y cómo lo sabemos de forma continua?

El examen lo pregunta con escenarios del tipo «una aseguradora debe conservar durante siete años un registro de cada respuesta generada y poder atribuir cada afirmación a su documento fuente, con el LEAST operational overhead». Tienes que combinar las piezas correctas: invocation logging a S3 con retención, citas de Knowledge Bases, metadatos de origen y CloudTrail.

1. Qué es gobernar la IA generativa

Gobierno de la IA (AI governance) es el conjunto de políticas, procesos, roles y controles técnicos que aseguran que los sistemas de IA se usan de forma segura, conforme a la ley y alineada con los valores de la organización, durante todo su ciclo de vida.

En IA generativa hay retos que un sistema tradicional no tiene:

• Salidas no deterministas: la misma pregunta puede dar respuestas distintas; necesitas registrar lo que realmente se respondió.
• Dependencias invisibles: la respuesta depende del modelo (y su versión), del prompt (y su versión), de los documentos recuperados (y su versión) y del guardrail (y su versión). Cambiar cualquiera cambia el comportamiento.
• Datos personales en texto libre: prompts y respuestas pueden contener PII que acaba en logs.
• Riesgos nuevos: alucinaciones, sesgos, contenido dañino, uso indebido.

2. Marco de gobierno organizativo (Skill 3.3.3)

El temario pide «comprehensive frameworks that align with organizational policies, regulatory requirements, and responsible AI principles». Un marco razonable, y cómo se apoya en AWS:

3. Trazabilidad y auditoría

3.1 Model invocation logging

Es el registro de qué se preguntó y qué se respondió. Recoge la petición completa, la respuesta completa y los metadatos de cada invocación de modelo en tu cuenta y región.

Datos verificados en la documentación (octubre de 2026):

• Desactivado por defecto. Se configura por cuenta y región en Settings de la consola de Bedrock o con PutModelInvocationLoggingConfiguration.
• Registra las invocaciones de Converse, ConverseStream, InvokeModel e InvokeModelWithResponseStream realizadas por el endpoint bedrock-runtime (incluidas las APIs compatibles con OpenAI en ese endpoint). Las llamadas por bedrock-mantle no se capturan.
• Destinos: Amazon S3, CloudWatch Logs o ambos, de la misma cuenta y región.
• Eliges las modalidades: texto, imagen, embeddings, vídeo (y audio en la API).
• Los cuerpos de entrada y salida de hasta 100 KB van en línea en el registro; los mayores de 100 KB y los binarios (imágenes) se guardan como objetos aparte en S3. Si el destino es solo CloudWatch Logs, puedes indicar un bucket para esos datos grandes (largeDataDeliveryS3Config).
• En S3 llegan ficheros JSON comprimidos con gzip; puedes consultarlos con Amazon Athena y catalogarlos con AWS Glue. En CloudWatch Logs, con Logs Insights.
• Para CloudWatch Logs necesitas un rol de IAM que Bedrock asuma (logs:CreateLogStream, logs:PutLogEvents); para S3, una bucket policy que permita s3:PutObject a bedrock.amazonaws.com con condiciones aws:SourceAccount y aws:SourceArn. Si el bucket usa SSE-KMS, la clave debe permitir kms:GenerateDataKey al servicio.

Campos de cada registro:

{
  "schemaType": "ModelInvocationLog",
  "timestamp": "2026-10-01T09:15:00Z",
  "accountId": "111122223333",
  "region": "eu-central-1",
  "requestId": "…",
  "operation": "Converse",
  "modelId": "eu.amazon.nova-micro-v1:0",
  "identity": { "arn": "arn:aws:sts::111122223333:assumed-role/app-seguros/sesion" },
  "requestMetadata": { "equipo": "siniestros", "caso_uso": "resumen-parte" },
  "input": { "inputBodyJson": {}, "inputTokenCount": 812 },
  "output": { "outputBodyJson": {}, "outputTokenCount": 164 }
}

• identity.arn: quién invocó (rol y sesión), capturado automáticamente.
• requestMetadata: etiquetas clave-valor que tu aplicación añade en la petición (equipo, caso de uso, identificador de cliente seudonimizado). Es el único campo que pone el llamante. Úsalo para imputar costes y para la trazabilidad por caso de uso.
• inputTokenCount y outputTokenCount: base para la imputación de costes y la detección de anomalías (módulo 9).

Ejemplo de consulta de CloudWatch Logs Insights para ver el consumo por principal:

fields identity.arn as principal, input.inputTokenCount as tin, output.outputTokenCount as tout
| stats sum(tin) as entrada, sum(tout) as salida, count() as llamadas by principal
| sort entrada desc

3.2 AWS CloudTrail: quién hizo qué en la API

CloudTrail registra llamadas a la API (quién, cuándo, desde dónde, con qué parámetros), no el contenido de los prompts. Es la pieza de auditoría de cambios y de acceso. Lo que tienes que saber de Bedrock:

Ejemplo para registrar los data events de guardrails y Knowledge Bases en un trail:

aws cloudtrail put-event-selectors --trail-name auditoria-genai \
  --advanced-event-selectors '[
    {"Name": "Management", "FieldSelectors": [{"Field": "eventCategory", "Equals": ["Management"]}]},
    {"Name": "Guardrails", "FieldSelectors": [
      {"Field": "eventCategory", "Equals": ["Data"]},
      {"Field": "resources.type", "Equals": ["AWS::Bedrock::Guardrail"]}]},
    {"Name": "KnowledgeBases", "FieldSelectors": [
      {"Field": "eventCategory", "Equals": ["Data"]},
      {"Field": "resources.type", "Equals": ["AWS::Bedrock::KnowledgeBase"]}]}
  ]'

Detalles útiles:

• El data event de ApplyGuardrail incluye la acción (GUARDRAIL_INTERVENED) y las evaluaciones (por ejemplo, VIOLENCE con confianza HIGH, un EMAIL bloqueado), sin el texto. Si la invocación fue evaluada por un guardrail impuesto por la organización sin guardrail en la petición, guardrailIdentifier aparece como ENFORCED.
• Para cross-Region inference, el evento registra en additionalEventData.inferenceRegion dónde se procesó: evidencia de residencia de datos.
• Amazon GuardDuty analiza CloudTrail y detecta actividad sospechosa en Bedrock, como un usuario desde una ubicación nueva que elimina guardrails o cambia el bucket de datos de entrenamiento.
• Buenas prácticas del SAA que siguen aplicando: trail multirregión y de organización, log file integrity validation, bucket con S3 Object Lock (WORM) si necesitas inmutabilidad para auditoría, y cifrado con KMS.
• CloudTrail Lake está en mantenimiento desde el 31/03/2026 (sin clientes nuevos). Para consultar trails, usa Athena sobre el bucket de CloudTrail.

3.3 CloudWatch Logs: registros de decisiones y redacción

La Skill 3.3.1 menciona «CloudWatch Logs to collect comprehensive decision logs». Un decision log es un registro estructurado que tu aplicación escribe con el contexto de cada decisión: petición (seudonimizada), versión del prompt, versión del modelo, identificadores de los documentos recuperados, versión y resultado del guardrail, puntuaciones de confianza, respuesta final, si hubo revisión humana. Escríbelo en JSON desde tu Lambda para poder consultarlo con Logs Insights y crear métricas.

Redacción a nivel de token (token-level redaction): las data protection policies de CloudWatch Logs detectan y enmascaran datos sensibles en el momento de la ingesta con managed data identifiers (email, tarjetas, credenciales, PII y PHI de muchos países) y custom data identifiers (hasta 10 regex por política):

• La política tiene una sentencia Audit (detecta y, opcionalmente, envía hallazgos a otro log group, a Firehose o a S3) y una sentencia Deidentify con MaskConfig vacío (enmascara).
• Se enmascara en todas las salidas: consola, Logs Insights, filtros de métricas y de suscripción. Solo quien tiene el permiso logs:Unmask ve los datos originales.
• Puede aplicarse a toda la cuenta o a un log group concreto.
• Solo afecta a lo ingerido después de crear la política.
• Emite la métrica LogEventsWithFindings para alarmas.

Es la respuesta al problema del aviso anterior: los invocation logs en CloudWatch Logs con datos personales.

4. Linaje de datos y atribución de fuentes (Skills 3.3.1 y 3.3.2)

Linaje (lineage) es poder reconstruir de dónde viene un dato y qué transformaciones sufrió. En IA generativa hay tres linajes que gobernar:

4.1 Linaje de los datos que alimentan el modelo

• AWS Glue Data Catalog: registra las fuentes de datos (tablas y esquemas de S3, bases de datos) con sus metadatos. Es el inventario técnico de «qué datos existen y dónde».
• Linaje en Amazon SageMaker Unified Studio (el catálogo de datos de la nueva generación de SageMaker): función compatible con OpenLineage que captura y visualiza eventos de linaje. Se captura automáticamente en los flujos de Visual ETL y en ejecuciones Spark de AWS Glue (Glue 5.0 o superior, DataFrames de Spark) y de EMR, y puedes publicar eventos propios con la API PostLineageEvent. Así ves que el documento indexado en la Knowledge Base viene de una tabla X transformada por el job Y.
• Metadatos en S3: metadatos de objeto (fecha de publicación, autor, departamento, clasificación) y, para Knowledge Bases, ficheros nombre.extensión.metadata.json junto a cada documento con atributos que se indexan con los fragmentos.

4.2 Atribución de fuentes en las respuestas

La Skill 3.3.2 pide «metadata tagging for source attribution in FM-generated content»:

• Las Knowledge Bases devuelven citas con la ubicación del fragmento fuente (URI de S3, página en PDF, metadatos). Muéstralas al usuario y guárdalas en el decision log.
• Añade metadatos de origen a cada fragmento (documento, versión, fecha, propietario) para poder filtrar por ellos (solo documentos vigentes) y para demostrar a posteriori qué versión se usó.
• Si generas contenido que se publica (textos de marketing, informes), etiqueta el resultado con metadatos de procedencia: modelo, versión del prompt, fecha, fuentes. El artículo 50 del EU AI Act exige, además, marcar como generado por IA ciertos contenidos sintéticos (sección 6).

4.3 Linaje de prompts y modelos

• Amazon Bedrock Prompt Management (módulo 4): versiones inmutables de cada prompt; guarda en el decision log el ARN con versión del prompt usado. RenderPrompt puede auditarse con data events de CloudTrail.
• SageMaker Model Registry: para modelos que despliegas tú (ajustados, importados, en endpoints de SageMaker AI): grupos de modelos, versiones, métricas asociadas, approval status (PendingManualApproval, Approved, Rejected), linaje para trazabilidad y reproducibilidad, despliegue con CI/CD y collections para organizarlos. Muestra la información de las model cards de cada versión.
• Versiones de guardrail y versión de modelo (modelId exacto en el invocation log).

flowchart LR
  SRC["Fuente: tabla o documento en S3"] -->|"Glue job, linaje OpenLineage"| DOC["Documento procesado con metadata.json"]
  DOC -->|"Ingesta"| KB["Knowledge Base"]
  KB -->|"Cita del fragmento"| RESP["Respuesta"]
  PR["Prompt v3 en Prompt Management"] --> RESP
  M["Modelo y versión"] --> RESP
  G["Guardrail v2"] --> RESP
  RESP --> LOG["Invocation log y decision log"]

5. Documentar modelos: model cards y AI Service Cards

5.1 Amazon SageMaker Model Cards

Una model card es la ficha de un modelo para gobierno y auditoría. SageMaker Model Cards la hace programática (Skill 3.3.1: «SageMaker AI to develop programmatic model cards»):

• Contenido guiado: descripción general del modelo (propietario, creador, tipo de problema), usos previstos (propósito, usos previstos y no previstos, supuestos), nivel de riesgo (unknown, low, medium, high) con su justificación, detalles de negocio, detalles de entrenamiento, resultados de evaluación (en JSON, con métricas) y consideraciones éticas, advertencias y recomendaciones.
• Estados: Draft, PendingReview, Approved, Archived. Encaja con el proceso de aprobación del marco de gobierno.
• Inmutabilidad: cualquier cambio distinto de actualizar el estado de aprobación crea una versión nueva, así tienes un registro inmutable de la evolución.
• Exportación a PDF para compartir con auditores, compartición entre cuentas, cifrado con KMS y integración con Model Registry.
• Se crean con la API (CreateModelCard) o el SDK, así que puedes generarlas automáticamente en el pipeline de CI/CD con los resultados de la evaluación.

¿Y si usas un modelo gestionado de Bedrock que no has entrenado? Documenta tu uso del modelo: qué modelo y versión, para qué caso de uso, qué no debe hacerse con él, qué evaluaciones hiciste, qué guardrail aplicas y qué limitaciones conoces (idiomas, alucinaciones, sesgos detectados). La Skill 3.4.3 pide exactamente eso: «model cards to document FM limitations».

5.2 AWS AI Service Cards

Son la documentación de transparencia que publica AWS sobre sus propios servicios y modelos: casos de uso previstos y limitaciones, decisiones de diseño de IA responsable y buenas prácticas de despliegue y optimización. Hay tarjetas, por ejemplo, para modelos Amazon Nova, Amazon Bedrock Guardrails y otros servicios de IA de AWS.

La diferencia de examen: una AI Service Card la escribe AWS sobre su servicio (léela para conocer las limitaciones del modelo que eliges); una model card la escribes tú sobre tu modelo o tu uso. Las AI Service Cards alimentan tus model cards.

6. Cumplimiento normativo

6.1 Responsabilidad compartida

AWS es responsable de la seguridad de la nube (infraestructura, el servicio Bedrock, sus certificaciones); tú, de la seguridad y el cumplimiento en la nube: qué datos envías, a qué usuarios das acceso, qué registras, cómo usas la salida del modelo y si tu caso de uso es legal. Las certificaciones de AWS no certifican tu aplicación.

6.2 RGPD

El Reglamento General de Protección de Datos (RGPD, GDPR en los enunciados) se aplica cuando tratas datos personales de personas en la UE. Lo que aterriza en una aplicación de IA generativa:

AWS publica material en su GDPR Center (https://aws.amazon.com/compliance/gdpr-center/) y la FAQ de Bedrock indica que puedes usar Bedrock conforme al RGPD.

6.3 EU AI Act (Reglamento europeo de IA)

Reglamento de la UE que regula los sistemas de IA según su nivel de riesgo:

• Prácticas prohibidas (riesgo inaceptable): por ejemplo, puntuación social o manipulación que explota vulnerabilidades.
• Alto riesgo: sistemas usados en ámbitos como empleo, crédito, educación o servicios esenciales (Anexo III), o integrados en productos regulados (Anexo I). Exigen gestión de riesgos, gobierno de datos, documentación técnica, registro de eventos (logging), transparencia hacia el usuario, supervisión humana, exactitud, robustez y ciberseguridad.
• Riesgo limitado: obligaciones de transparencia (artículo 50): informar a las personas de que interactúan con un sistema de IA y marcar ciertos contenidos generados o manipulados por IA.
• Riesgo mínimo: sin obligaciones específicas.
• Obligaciones específicas para los proveedores de modelos de IA de uso general (GPAI, como los grandes modelos fundacionales).

Calendario (verificado el 01/10/2026 en la web de la Comisión Europea): en vigor desde el 1 de agosto de 2024; prohibiciones y alfabetización en IA desde el 2 de febrero de 2025; obligaciones de los modelos de uso general desde el 2 de agosto de 2025; las obligaciones de transparencia del artículo 50 aplican desde el 2 de agosto de 2026. El Digital Omnibus on AI, en vigor desde el 27 de julio de 2026, aplazó las obligaciones de alto riesgo: al 2 de diciembre de 2027 para los sistemas del Anexo III y al 2 de agosto de 2028 para los integrados en productos del Anexo I.

Para el examen no necesitas derecho; necesitas mapear requisitos a controles: logging → invocation logging y CloudTrail; supervisión humana → flujos de revisión; transparencia → avisos al usuario, citas, trazas; documentación técnica → model cards; gestión de riesgos → marco de gobierno y evaluaciones.

6.4 ISO/IEC 42001

ISO/IEC 42001:2023 es la norma internacional de sistemas de gestión de la IA (AIMS): requisitos y controles para desarrollar y usar IA de forma responsable (como ISO 27001 para la seguridad de la información, pero para IA). AWS obtuvo la certificación acreditada ISO/IEC 42001 para servicios de IA, entre ellos Amazon Bedrock, otorgada por Schellman (acreditada por ANAB), y superó su primera auditoría de seguimiento en noviembre de 2025 sin hallazgos. El certificado se descarga en AWS Artifact.

Uso en el examen: si un enunciado pide «demostrar a los auditores que el proveedor de IA sigue un sistema de gestión de IA certificado», la respuesta es el certificado ISO/IEC 42001 de AWS obtenido en AWS Artifact. Tu organización puede, además, certificarse ella misma en ISO/IEC 42001 apoyándose en los controles de este módulo.

6.5 AWS Artifact

Portal gratuito de la consola para descargar informes y certificados de cumplimiento de AWS (SOC, ISO, PCI y otros) y revisar y aceptar acuerdos con AWS para tu cuenta o toda la organización. Esos documentos son las evidencias del lado de AWS que entregas a tus auditores. Incluye un asistente (Assurance Assistant) para preguntas de cumplimiento.

Ojo: AWS Audit Manager (automatización de la recogida de evidencias) está en mantenimiento desde el 31/03/2026 y no admite clientes nuevos; no lo propongas para un diseño nuevo aunque aparezca en materiales antiguos.

7. Monitorización continua y controles avanzados (Skill 3.3.4)

El temario enumera: «automated detection for misuse, drift, and policy violations, bias drift monitoring, automated alerting and remediation workflows, token-level redaction, response logging, AI output policy filters». Cómo resolver cada uno:

8. Principios de IA responsable de AWS

AWS define ocho dimensiones de IA responsable (página oficial de IA responsable, consultada el 01/10/2026). Apréndelas en inglés, porque los enunciados las usan tal cual:

Herramientas que AWS asocia a estas dimensiones: Bedrock Guardrails, Bedrock Evaluations (comparación de modelos), SageMaker Clarify y la librería fmeval, SageMaker Model Monitor, SageMaker Ground Truth, el gobierno de ML de SageMaker (model cards, Model Registry) y las AI Service Cards. Varias están hoy en mantenimiento (sección 12).

9. Sistemas transparentes (Skill 3.4.1)

Los ejemplos del temario, uno a uno:

• Reasoning displays (explicaciones visibles para el usuario): mostrar al usuario un resumen del razonamiento o de los pasos seguidos («He consultado tu póliza y la cláusula 4.2 excluye…»). Pídelo en el prompt como salida estructurada separada de la respuesta, o muestra el razonamiento que devuelven los modelos con razonamiento ampliado. No confundas un razonamiento generado con una prueba: para decisiones reguladas, combínalo con evidencias (citas) o con Automated Reasoning.
• Métricas de confianza en CloudWatch para cuantificar la incertidumbre: publica como métrica personalizada la puntuación de grounding y relevancia del guardrail, la puntuación de un juez LLM o la similitud entre respuesta y fuentes. Alarmas si la confianza media cae; respuestas con baja confianza → aviso al usuario o revisión humana.
• Evidence presentation (presentación de evidencias): citas de Knowledge Bases con enlace al documento y al fragmento.
• Trazas de razonamiento de agentes: en Bedrock Agents (Classic), activar la traza devuelve los pasos de preprocesado, orquestación (la justificación del modelo, las herramientas invocadas y sus resultados) y postprocesado. En AgentCore, AgentCore Observability emite trazas, spans y métricas en formato OpenTelemetry a CloudWatch, con paneles que muestran cada paso del agente, las llamadas a herramientas, latencias, tokens y errores. Recuerda que Agents Classic no admite clientes nuevos desde el 30/07/2026 (módulo 5).
• Aviso de interacción con IA: indicar claramente que la respuesta la genera una IA (artículo 50 del EU AI Act) y con qué limitaciones.

10. Evaluaciones de equidad (Skill 3.4.2)

La equidad en un LLM no se mide como en un clasificador tabular (no hay una etiqueta «aprobado» sin más). Se evalúa comprobando que el sistema trata igual a grupos distintos en situaciones equivalentes:

1. Conjunto de pruebas contrafactuales: la misma petición cambiando solo un atributo sensible (nombre asociado a un género u origen, edad, idioma materno). Ejemplo: «Resume el perfil de María/Mohamed/Juan, 45 años, ingeniera/o con 10 años de experiencia».
2. Métricas definidas previamente (pre-defined fairness metrics): tasa de respuestas favorables por grupo, diferencia de longitud o tono, puntuación de un juez por grupo, tasa de rechazos por grupo. Publícalas en CloudWatch como métricas personalizadas con una dimensión por grupo y define umbrales de alerta (por ejemplo, diferencia máxima de 5 puntos entre grupos).
3. A/B testing sistemático con Prompt Management y Flows: crea variantes del prompt (con y sin instrucciones de neutralidad, con distintos ejemplos) en Bedrock Prompt Management y compáralas; orquesta la ejecución de la batería con Bedrock Flows para repetirla igual cada vez.
4. LLM-as-a-judge con Bedrock Evaluations: un modelo evaluador puntúa las respuestas según criterios (incluidos criterios de sesgo, daño o estereotipos, o métricas personalizadas) de forma automática y a escala. Útil para cribar; valida una muestra con personas.
5. La librería open source fmeval incluye evaluación de prompt stereotyping (estereotipos) además de toxicidad y robustez.

11. Sistemas conformes con las políticas (Skill 3.4.3)

Traduce la política de IA responsable de la empresa en controles automáticos:

• Guardrails a partir de los requisitos de la política: cada frase de la política se convierte en una configuración. «No damos consejo de inversión» → denied topic; «nunca mostramos datos de tarjetas» → PII BLOCK; «no inventamos condiciones de la póliza» → contextual grounding o Automated Reasoning; «lenguaje respetuoso» → content filters. Versiona el guardrail y documenta en la model card qué requisito cubre cada política.
• Model cards que documentan las limitaciones del FM: idiomas en los que no se ha evaluado, tareas para las que no debe usarse, sesgos observados, tasa de alucinación medida.
• Lambda para comprobaciones automáticas de cumplimiento: antes de devolver la respuesta (validar que incluye el aviso legal obligatorio, que no promete plazos, que cita al menos una fuente) o de forma programada sobre la cuenta (verificar que el logging está activado, que el guardrail impuesto es la versión aprobada, que la model card está en Approved antes de desplegar). En CI/CD, esas comprobaciones son una quality gate.

12. Revisión humana: A2I, Ground Truth y alternativas actuales

Las personas en el bucle (human-in-the-loop) son necesarias para decisiones de alto impacto, para casos de baja confianza y para evaluar calidad subjetiva.

Estado de los servicios clásicos (octubre de 2026)

Siguen en la guía del examen, así que pueden aparecer. Reconoce para qué servían: si una pregunta pide «revisión humana de extracciones de Textract con baja confianza con el mínimo desarrollo», la respuesta canónica del examen es A2I; en un proyecto real con una cuenta nueva, no podrás darlo de alta y construirás el flujo con Step Functions.

Patrón actual de revisión humana con Step Functions

flowchart TD
  IN["Petición"] --> GEN["Generar respuesta con Bedrock"]
  GEN --> EVAL{"¿Confianza alta y sin intervención del guardrail?"}
  EVAL -->|"Sí"| OUT["Responder al usuario"]
  EVAL -->|"No"| TASK["Tarea humana: SQS o DynamoDB y notificación SNS, waitForTaskToken"]
  TASK --> REV["Revisor aprueba, corrige o rechaza en una interfaz web"]
  REV -->|"SendTaskSuccess vía API Gateway y Lambda"| OUT
  REV --> FB["Guardar feedback para evaluación y mejora"]

• El estado de tarea con .waitForTaskToken pausa la ejecución (hasta un año en flujos Standard) hasta que el revisor responde y una Lambda llama a SendTaskSuccess o SendTaskFailure con el token.
• API Gateway expone la API de feedback (valoraciones con pulgar arriba o abajo, correcciones) que alimenta los conjuntos de evaluación (módulo 10).
• Umbrales: qué va a revisión lo decides con la puntuación de grounding, la confianza del juez, la intervención del guardrail o el tipo de decisión (toda denegación de crédito, por ejemplo).

Evaluación humana en Bedrock

Bedrock Evaluations admite trabajos de evaluación con evaluadores humanos: tu propio equipo, gestionado como work team con Amazon Cognito desde la consola, valora o compara las respuestas de hasta dos modelos sobre tu conjunto de prompts en S3 con métricas y métodos de puntuación que defines. Es la alternativa gestionada a montar un flujo de Ground Truth para evaluar calidad subjetiva (tono, utilidad, adecuación a la marca).

Tabla de decisión: cuándo usar qué

Trampas típicas del examen

• CloudTrail para ver el contenido de los prompts: no. CloudTrail registra la llamada, no el prompt ni la respuesta. Para el contenido, model invocation logging.
• Model invocation logging activado por defecto: no; hay que configurarlo por región. Y los destinos deben estar en la misma cuenta y región.
• Esperar ver Retrieve o InvokeAgent en Event history: son data events; necesitas un trail con selectores avanzados (y se pagan aparte).
• Creer que Guardrails enmascara el invocation log: no; usa CloudWatch Logs data protection y restringe logs:Unmask.
• AI Service Card frente a model card: la primera la publica AWS; la segunda la escribes tú.
• Proponer Clarify, A2I, Ground Truth o Model Monitor en una cuenta nueva: están en mantenimiento desde el 30/06/2026 y no admiten clientes nuevos desde el 30/07/2026. Conócelos para el examen, pero si la pregunta insiste en «nuevo proyecto» o en «servicio actual», elige Bedrock Evaluations, fmeval, Step Functions o las soluciones open source.
• CloudTrail Lake o AWS Audit Manager para un diseño nuevo: ambos en mantenimiento desde el 31/03/2026. Consulta los trails con Athena.
• Confundir transparencia y explicabilidad (ver aviso de la sección 8).
• Pensar que la certificación ISO/IEC 42001 de AWS certifica tu aplicación: certifica el sistema de gestión de IA de AWS; tu cumplimiento es tuyo (responsabilidad compartida).
• EU AI Act: todo el alto riesgo ya aplica en agosto de 2026: el Digital Omnibus lo aplazó a diciembre de 2027 (Anexo III) y agosto de 2028 (Anexo I). La transparencia del artículo 50 sí aplica desde el 2 de agosto de 2026.
• Palabras clave: audit trail, who did what → CloudTrail; full request and response, prompt and completion → invocation logging; source attribution, traceability of answers → citas y metadatos; document intended use and limitations → model card; human review of low-confidence results → A2I en el examen, Step Functions en diseños nuevos.

Resumen

• Gobierno es poder responder quién, qué, con qué fuentes, con qué controles y si cumple, de forma continua. Combina controles preventivos centralizados, detectivos y documentación.
• Model invocation logging (desactivado por defecto, S3/CloudWatch Logs de la misma cuenta y región) guarda prompts y respuestas completos, con identity.arn y requestMetadata; contiene PII en claro y el contenido bloqueado: protégelo con KMS, acceso restringido, retención y data protection policies de CloudWatch Logs.
• CloudTrail: InvokeModel y Converse como management events (sin contenido); agentes, Knowledge Bases, flows, prompts y guardrails como data events con selectores avanzados. GuardDuty vigila Bedrock sobre CloudTrail.
• Linaje y atribución: Glue Data Catalog, linaje OpenLineage en SageMaker Unified Studio, metadatos metadata.json, citas de Knowledge Bases, versiones de prompts, modelos (Model Registry) y guardrails.
• SageMaker Model Cards: uso previsto, nivel de riesgo, evaluaciones, limitaciones; estados de aprobación y versiones inmutables. AI Service Cards: la transparencia que publica AWS.
• Cumplimiento: responsabilidad compartida; RGPD (minimización, retención, transferencias, accountability); EU AI Act (transparencia desde agosto de 2026, alto riesgo aplazado a 2027-2028); ISO/IEC 42001 (AWS certificada, incluye Bedrock); evidencias en AWS Artifact.
• Monitorización continua: métricas de Guardrails, detección de anomalías, evaluaciones periódicas contra golden datasets, EventBridge + Lambda para remediar.
• Ocho dimensiones de IA responsable de AWS: fairness, explainability, privacy and security, safety, controllability, veracity and robustness, governance, transparency.
• Transparencia con citas, razonamientos, confianza en CloudWatch y trazas de agentes; equidad con pruebas contrafactuales, métricas por grupo, variantes de Prompt Management y LLM-as-a-judge; políticas convertidas en guardrails, model cards y comprobaciones con Lambda.
• Clarify, A2I, Ground Truth y Model Monitor están en mantenimiento desde el 30/06/2026 y cerrados a clientes nuevos desde el 30/07/2026: reconócelos, pero diseña con Bedrock Evaluations, fmeval, SHAP, Step Functions y las soluciones open source de AWS.

Cobertura del temario

Task 3.3: Implement AI governance and compliance mechanisms

Task 3.4: Implement responsible AI principles

Servicios in-scope cuyo dueño es este módulo

Practica lo aprendido

Documentación oficial para ampliar

• Model invocation logging
• Bedrock y CloudTrail (management y data events)
• CloudWatch Logs data protection
• Amazon SageMaker Model Cards
• SageMaker Model Registry
• Linaje de datos en SageMaker Unified Studio
• IA responsable en AWS
• ISO/IEC 42001 en AWS
• AWS Artifact
• Estado de SageMaker Clarify y alternativas
• Servicios en mantenimiento
• EU AI Act (Comisión Europea)