Seguridad, IAM y cumplimiento para cargas de trabajo de IA

Seguridad es el segundo dominio con más peso en el examen AIF-C01: el Dominio 2 «Security, Compliance, and Governance» supone el 24 % de la puntuación, dentro de un examen de 65 preguntas (50 puntuadas + 15 sin puntuar) sin penalización por responder a ciegas. Lo que lo dificulta no es el vocabulario: es que AWS enuncia el mismo requisito en cuatro sitios distintos, y el examen te recompensa por saber cuál de esos sitios es el autoritativo. «¿Es Bedrock compatible con HIPAA?» tiene una respuesta correcta diferente según leas una página de marketing, la documentación propia del servicio o la tabla AWS Services in Scope.

Al terminar esta lección podrás:

• nombrar cada tipo de rol de IAM que una carga de trabajo de IA puede usar y decir quién lo asume;
• escribir una execution role de SageMaker con mínimo privilegio y explicar por qué AmazonSageMakerFullAccess todavía necesita una segunda declaración de S3;
• aplicar bien la regla de cuentas cruzadas: se requiere un Allow tanto en la política de identidad como en la política de recurso;
• elegir entre SSE-S3 y SSE-KMS (y saber cuándo solo una de las dos es posible);
• diseñar una VPC privada de ML: endpoint de gateway frente a endpoint de interfaz frente a NAT, y por qué los endpoints de SageMaker necesitan dos subredes en dos Zonas de Disponibilidad;
• separar los eventos de gestión de CloudTrail de los eventos de datos para bedrock-runtime, bedrock-mantle y SageMaker;
• demostrar una afirmación de cumplimiento a la manera de AWS: Services in Scope → AWS Artifact → BAA para servicios elegibles para HIPAA;
• defender el Veredicto comparativo: roles de IAM frente a claves compartidas, endpoint de VPC frente a NAT, SSE-KMS frente a SSE-S3.

---

1. Responsabilidad compartida, y qué añade la seguridad de IA

1.1 La frase que AWS publica de verdad

La documentación de seguridad de Amazon Bedrock no te entrega una lista de verificación. Dice que la responsabilidad "está determinada por la sensibilidad de tus datos, los objetivos de cumplimiento de tu empresa y las leyes y regulaciones aplicables". Esa frase es toda la filosofía: AWS asegura la infraestructura y el servicio, tú aseguras lo que metes en él y a quién permites tocarlo, y la sensibilidad de una carga de trabajo de IA (prompts, embeddings, datos de fine-tuning, salidas del modelo) es la variable que el examen no deja de evaluar.

1.2 La división, capa por capa

• 📚 ¿Sabías que…? AWS publica 143 ofertas de cumplimiento en sus servicios. La cifra es una distracción deliberada: el examen nunca pregunta el total, pregunta si este servicio en concreto está en el alcance de este programa en concreto, y la única respuesta autoritativa es la tabla AWS Services in Scope by Compliance Program, no la página de marketing de un servicio.

1.3 La primera trampa: «HIPAA certified» no existe

No existe una certificación HIPAA para AWS, para Amazon Bedrock, para SageMaker ni para ningún proveedor de servicios en la nube. La redacción correcta, y la que usa el examen, es:

1. firmar un Business Associate Agreement (BAA) con AWS, y
2. usar solo servicios elegibles para HIPAA para almacenar o procesar información de salud protegida (PHI).

AWS además mapea la HIPAA Security Rule a FedRAMP y NIST SP 800-53 (cuya guía es SP 800-66), y por eso esos dos nombres aparecen juntos en cada opción correcta sobre HIPAA.

---

2. Identidad: los roles detrás de cada trabajo de IA

2.1 Los tipos de role, en una tabla

SageMaker por sí solo documenta cuatro tipos de role, y Bedrock añade dos más. Aprende quién asume cada uno: eso es lo que la pregunta evalúa siempre.

Dos detalles que vale la pena memorizar:

• ExecutionRoleSessionNameMode = USER_IDENTITY mete en CloudTrail al usuario final (no un nombre de job compartido): el ajuste que convierte «lo hizo el job» en «lo hizo la credencial de Priya».
• Las personas del Role Manager son Data scientist, MLOps y SageMaker AI compute: tres roles, no una lista de texto libre.

2.2 Ejemplo 1: una execution role de SageMaker con mínimo privilegio

Cuatro declaraciones, una cuenta (111122223333), un bucket (acme-ml-artifacts), una Región (us-east-1). Compara esto con la política gestionada de la siguiente subsección: la diferencia es la respuesta del examen.

2.3 La advertencia de S3 de AmazonSageMakerFullAccess

AWS documenta una restricción concreta dentro de AmazonSageMakerFullAccess: ciertas acciones de S3 se conceden solo en buckets y objetos cuyos nombres contengan SageMaker, Sagemaker, sagemaker o aws-glue, más una lista corta de acciones que aplican a cualquier recurso de S3. Consecuencias:

• un bucket llamado acme-ml-artifacts no está cubierto: debes adjuntar una segunda política, exactamente como en el Ejemplo 1;
• una opción que afirma «FullAccess concede s3:* en cada bucket de la cuenta» es falsa;
• una opción que afirma «FullAccess no concede permisos de S3» es igualmente falsa.

La lección práctica va más allá de S3: una política gestionada es un punto de partida, no un diseño. El examen recompensa una y otra vez al candidato que dice «política gestionada por el cliente limitada al ARN del recurso».

2.4 Ejemplo 2: permitir una familia de modelos y denegar otra

Observa el acoplamiento: denegar InvokeModel más InvokeModelWithResponseStream también deniega Converse/ConverseStream, porque estos últimos se construyen sobre los primeros. Para imponerlo en toda la organización sales del límite de la cuenta y escribes un SCP sobre bedrock:Invoke*, bedrock:Converse* y sagemaker:InvokeEndpoint*.

2.5 Ejemplo 3: una Bedrock service role de customization que resiste al confused deputy

Esta política empaqueta tres hábitos:

1. aws:SourceAccount en la política de confianza: la protección contra confused deputy que AWS recomienda para todo Bedrock service role (customization, import, batch, agents, knowledge bases, Flows, evaluations);
2. aws:SourceArn encima, para acotar al nivel del job;
3. para Bedrock en concreto, iam:PassedToService = bedrock.amazonaws.com cuando quien llama pasa un role, y una declaración de política de clave a juego para que KMS realmente permita el job.

2.6 Cómo se evalúa una petición: todo acota, nada concede

La regla que el examen no deja de reformular: un límite de permisos (permissions boundary), una service control policy (SCP) y una resource control policy (RCP) acotan todas los permisos máximos posibles: ninguna de las tres concede nada. Un límite sin política de identidad adjunta da a un usuario cero permisos efectivos, no los permisos del límite.

2.7 Ejemplo 4: un límite de permisos acotando a un desarrollador de ML

Permiso efectivo = política de identidad ∩ límite. El desarrollador conserva lo que su política de identidad permite, pero nunca puede superar esos cuatro servicios, y nunca puede borrar un modelo o un endpoint aunque su política de identidad diga sagemaker:*.

Ordena los pasos para construir ese role:

---

3. Identidad en Bedrock: políticas gestionadas, políticas de recurso y cuentas cruzadas

3.1 Siete políticas gestionadas, y sus fechas

Amazon Bedrock incluye 7 políticas gestionadas de AWS, y al examen le gusta la cronología:

3.2 Basadas en identidad y basadas en recurso, y por qué los guardrails necesitan ambas

Bedrock acepta políticas basadas en identidad (quién eres) y políticas basadas en recurso (qué objeto se toca). Los guardrails y los perfiles de inferencia usan políticas de recurso, y AWS declara que una política de recurso es obligatoria para el cumplimiento a nivel de organización: para impedir que toda una organización invoque un modelo sin un guardrail adjunto, adjuntas una política de recurso evaluada con bedrock:GuardrailIdentifier y la respaldas con un SCP. Una política de identidad por sí sola no puede expresar «este guardrail debe estar presente».

3.3 Cuentas cruzadas: el Allow debe existir en los dos lados

En concreto, para un bucket de S3 compartido y un guardrail compartido:

1. La cuenta B (444455556666) crea role/CrossAccountBedrock que confía en {"AWS":"arn:aws:iam::111122223333:root"} y pone una política de recurso en el bucket/guardrail que permite a la cuenta A;
2. La cuenta A adjunta una política de identidad con {"Action":"sts:AssumeRole","Resource":"arn:aws:iam::444455556666:role/CrossAccountBedrock"};
3. los dos Allows son obligatorios: para KMS debes usar tu propia CMK, porque la política de clave de un S3 gestionado por AWS no se puede compartir de esa manera.

Ejemplo 5: la mitad que falta: la política de recurso sobre el bucket de la cuenta B.

La cuenta 111122223333 (identidad) más esta declaración en 444455556666 (recurso) = los dos Allows que exige la regla; la segunda declaración además impone TLS en tránsito en el bucket.

3.4 Límites de permisos, SCP y RCP comparados

• 📚 ¿Sabías que…? La función Role Manager y la vía de la service-linked role están ambas ligadas a Studio Classic. En Studio (la experiencia actual) asignas roles de domain, space y user por persona, y por eso una opción que describe «dejar que SageMaker cree el rol automáticamente» es una respuesta de Studio Classic, y una opción que describe tres personas es una respuesta de Role Manager.

---

4. Cifrado: en reposo y en tránsito

4.1 En tránsito: TLS 1.2 es el número

AWS declara TLS 1.2 como mínimo en tránsito para estos servicios. En CloudTrail puedes verificar la versión negociada mediante tlsDetails.tlsVersion. Cualquier opción que ofrezca «TLS 1.0 o superior», «SSL» o «solo TLS 1.3» es errónea en direcciones opuestas.

4.2 En reposo: valores por defecto, opciones y las dos excepciones

Dos excepciones concentran una ponderación desproporcionada en el examen:

1. Un volumen de SageMaker sin clave recibe una clave transitoria que se descarta tras cifrar: así que «los volúmenes de SageMaker no están cifrados» es falso, y «debes proporcionar una clave KMS» también es falso.
2. El acceso a S3 entre cuentas necesita tu CMK. Si la cuenta A lee el bucket de la cuenta B, la política de clave gestionada por AWS por defecto de la cuenta B no cooperará; la cuenta A debe proporcionar y controlar una clave gestionada por el cliente.

4.3 Elegir entre SSE-KMS y SSE-S3 en una frase

SSE-S3 es el valor por defecto, no tiene sobrecarga de gestión de claves ni cargos por peticiones a KMS; SSE-KMS te da una clave gestionada por el cliente con rastro de auditoría en CloudTrail, políticas de clave y grants, y rotación por clave, y es la única forma de satisfacer un requisito entre cuentas o una política que exige CMK. Reglas de AWS Config como sagemaker-endpoint-config-kms-key-required y sagemaker-featuregroup-encryption-at-rest existen precisamente para detectar cuándo te quedaste con el valor por defecto.

---

5. Aislamiento de red: VPC, endpoints de gateway y PrivateLink

5.1 El contrato de VpcConfig

El VpcConfig de SageMaker acepta 1 to 16 subredes y 1 to 5 grupos de seguridad, y SageMaker crea interfaces de red elásticas (ENI) en cada subred. La regla dura que los candidatos se saltan:

Un endpoint de SageMaker necesita al menos 2 subredes en al menos 2 Zonas de Disponibilidad, aunque lances una sola instancia.

Los jobs de entrenamiento necesitan al menos 2 IP privadas por instancia (al menos 5 con EFA), y el grupo de seguridad debe permitir TCP 443 de entrada en la ruta de la ENI.

5.2 Los siete servicios Bedrock PrivateLink

Con PrivateLink obtienes: sin internet gateway, sin NAT, sin requisito de VPN o Direct Connect y sin IP públicas. DNS privado habilitado significa que tu código no cambia; DNS privado deshabilitado significa que reescribes las llamadas a {vpce-id}.bedrock-runtime.{region}.vpce.amazonaws.com. El grupo de seguridad del endpoint debe permitir 443 de entrada, y puedes adjuntar una política de endpoint personalizada para acotar qué acciones o ARN de modelo son alcanzables.

5.3 Cuatro patrones de VPC y lo que cuestan

5.4 Ejemplo 6: un diseño privado que funciona de Bedrock + SageMaker (Patrón B)

1. 10.20.0.0/16 con la privada 10.20.1.0/24 (AZ-a) y 10.20.2.0/24 (AZ-b); sin ruta a IGW, sin NAT;
2. endpoint de gateway de S3 adjunto a las dos tablas de rutas, con una política de endpoint limitada a arn:aws:s3:::acme-*;
3. endpoints de interfaz en las dos subredes para bedrock-runtime, bedrock, sagemaker, sagemaker.api, sagemaker.runtime, ecr.api, ecr.dkr, logs y kms; grupo de seguridad del endpoint con 443 de entrada desde 10.20.0.0/16;
4. VpcConfig = {Subnets:[a,b], SecurityGroupIds:[sg-ml]}; salida de sg-ml limitada a 443 hacia el grupo de seguridad del endpoint; notebook con DirectInternetAccess = Disabled;
5. flujo: usuario de Studio → ENI de SageMaker → ENI del endpoint → runtime de Bedrock sobre la red de AWS con TLS 1.2. CloudTrail registra la llamada como un evento de gestión en la Región de origen, y GuardDuty AI Protection lo lee a través de su canal vinculado al servicio. Respaldo (Patrón C) añade un IGW, subredes públicas y un NAT gateway solo cuando una dependencia no tiene endpoint de interfaz.

5.5 La arquitectura segura de VPC / ML

---

6. Auditoría: CloudTrail, registro de invocaciones, GuardDuty y Config

6.1 Eventos de gestión frente a datos: la línea de gratis/de pago

Los eventos de gestión son gratuitos y están activos por defecto; los eventos de datos son opt-in y de pago. El historial de eventos de CloudTrail conserva 90 días de eventos de gestión en la consola.

6.2 El registro de invocaciones de modelos es un interruptor aparte, y está apagado

El model invocation logging de Bedrock está apagado por defecto. Cuando lo activas:

• los destinos son CloudWatch Logs y/o S3, y deben estar en la misma cuenta y la misma Región;
• un cuerpo de prompt/completion en línea de ≤100 KB se guarda en línea: los cuerpos más grandes van a un prefijo de S3 bajo data/;
• el registro no es CloudTrail: CloudTrail te dice quién llamó a qué, el registro de invocaciones te dice qué se dijo.

6.3 GuardDuty AI Protection

El AI Protection de GuardDuty lee los eventos de datos de Bedrock, AgentCore y SageMaker además de los eventos de gestión, a través de un canal de CloudTrail vinculado al servicio que GuardDuty crea por ti. Hallazgos notables:

Esto son hallazgos y alertas, no bloqueos: GuardDuty te dice que un guardrail intervino; solo el propio guardrail bloquea el contenido.

6.4 AWS Config: reglas y packs para IA

Las reglas de Config con el prefijo sagemaker- incluyen:

• sagemaker-notebook-no-direct-internet-access
• sagemaker-notebook-instance-inside-vpc
• sagemaker-endpoint-config-kms-key-required
• sagemaker-featuregroup-encryption-at-rest

Y hay tres conformance packs orientados a la IA: Best Practices for Amazon Bedrock, Best Practices for Amazon SageMaker AI y Best Practices for AI/ML Supporting Infrastructure. El control 3.1.1 de NIST SP 800-171 se mapea a sagemaker-notebook-no-direct-internet-access, y AWS declara que las plantillas de ejemplo no garantizan superar una auditoría de cumplimiento.

• 📚 ¿Sabías que…? La eliminación de un Guardrail y el cambio del registro de invocaciones de modelos a desactivado se tratan ambos como eventos de seguridad por el plan Foundational de GuardDuty. Es inusual, la mayoría de la «deriva de configuración» solo es visible en Config, y es una pista fuerte de que el examen considera «apagar en silencio tu red de seguridad» un ataque, no una tarea de administración.

6.5 Panel de estado (octubre de 2026)

---

7. Cumplimiento: HIPAA, AWS Artifact y lo que Bedrock publica de verdad

7.1 La única cadena autoritativa

De ese diagrama salen tres reglas:

1. AWS Services in Scope es la única tabla autoritativa de «¿está cubierto»: ✓ significa en alcance en los informes actuales;
2. AWS Artifact es donde viven los informes reales de SOC / ISO / FedRAMP: nunca una página de servicio, nunca un enlace de consola etiquetado «Compliance»;
3. para HIPAA necesitas un BAA más servicios elegibles para HIPAA; AWS mapea la Security Rule a FedRAMP + NIST 800-53.

7.2 Lo que Amazon Bedrock publica

El conjunto de cumplimiento publicado de Amazon Bedrock es: ISO, SOC, CSA STAR Level 2, GDPR, HIPAA eligible y FedRAMP High en AWS GovCloud (US-West): más una matriz FedRAMP por modelo (publicada el 18 sep 2026) que cubre modelos Clase C/D e IL4/IL5.

7.3 Números que merece la pena llevarse al examen

• 📚 ¿Sabías que…? La frase «in scope» (en alcance) tiene un significado preciso: dice que el servicio fue incluido en el informe del auditor para ese periodo: no que tu carga de trabajo sea conforme. Por eso toda opción de cumplimiento que diga «activar GuardDuty logra el cumplimiento de HIPAA» es falsa: puedes estar en alcance y aun así incumplir tus propias obligaciones bajo el modelo de responsabilidad compartida.

---

8. Gobernanza de datos: retención, residencia y moderación de contenido

8.1 Modos de retención de Bedrock

Los modos de retención son none, default, aws_review, provider_data_share e inherit, con un alcance que fluye proyecto → cuenta → valor por defecto del modelo, por Región, sin propagación entre Regiones. Los hechos examinables:

• aws_review mantiene los datos dentro del límite de AWS durante ≤30 días y nunca se los da al proveedor del modelo;
• las claves de condición del plano de control son bedrock:DataRetentionMode / bedrock-mantle:DataRetentionMode, aplicables con SCP e IAM;
• los datos de fine-tuning se usan solo para fine-tuning, nunca para entrenar los modelos Titan base, y no se guarda nada después del job, pero el modelo ajustado aún puede hacer replay de ellos, así que filtra o borra las filas sensibles antes de empezar;
• en el lanzamiento no hay interfaz de consola para los modos de retención: solo API/SDK.

8.2 Ejemplo 7: imponer cero retención de datos en toda la organización (SCP)

Efecto: solo puede configurarse none; un modelo que requiera aws_review devuelve entonces ValidationException / status: unavailable. La variante del plano de control sustituye bedrock-mantle:PutAccountDataRetention por bedrock:PutAccountDataRetention y bedrock-mantle:DataRetentionMode por bedrock:DataRetentionMode.

8.3 Inferencia entre Regiones: Geographic frente a Global

CloudTrail registra la llamada en la Región de origen. Ninguno de los dos modos añade un recargo de enrutamiento, y ninguno admite Provisioned Throughput.

8.4 Moderación de contenido: la caja de herramientas completa

Detalles de Guardrails del resumen: 6 categorías de filtro, Hate, Insults, Sexual, Violence, Misconduct y Prompt Attack, más el nivel CLASSIC|STANDARD y mensajes de respuesta bloqueada de 1 to 500 caracteres. La detección de PII es ML probabilística, y exactamente por eso puedes elegir enmascarar en lugar de bloquear.

8.5 Límites de moderación de Rekognition

DetectModerationLabels acepta solo JPEG y PNG, usa una taxonomía de 3 niveles con MinConfidence por defecto en 50 %, y funciona con Amazon A2I para revisión humana. El límite duro que AWS declara por escrito: las APIs no detectan contenido ilegal como CSAM: ningún umbral de confianza lo arregla, y ninguna opción del examen debería afirmar lo contrario.

• 📚 ¿Sabías que…? La propia guía de guardrails de AWS dice: "Desactiva los Invocation Logs si no quieres que el contenido bloqueado aparezca como texto plano en los registros." En otras palabras, el registro que activas para auditar puede convertirse en el lugar donde se guarda literalmente el contenido que acabas de bloquear: un dilema de diseño genuino, y un caso raro en el que AWS recomienda explícitamente apagar una función de registro.

---

9. Veredicto comparativo

---

10. Trampas del examen y los números que merecen memorizarse

10.1 Los números que se evalúan

10.2 Marcado como no verificado en esta lección

Para que una laguna de investigación no se convierta en una respuesta errónea: el alcance de PCI DSS para Amazon Bedrock (ausente de las propias páginas de Bedrock); la elegibilidad de HIPAA de SageMaker (no se recuperó la HIPAA Eligible Services Reference); la disponibilidad por Región de GuardDuty AI Protection; el contenido regla a regla de los tres conformance packs de IA; los precios exactos de NAT gateway, endpoints de interfaz, PrivateLink y GuardDuty AI Protection (las afirmaciones de coste aquí son direccionales); los pesos por tema de AIF-C01 (solo se publican los pesos por dominio 20/24/28/14/14); y la disponibilidad de Role Manager para clientes nuevos. Trata cada uno de ellos como «consulta la página de origen antes de afirmarlo».

---

Casos Reales

Cinco historias de clientes publicadas por AWS, recuperadas para este curso el 6 de octubre de 2026, ejercitan los controles del Dominio 2 en producción. Léelas como evidencia, no como marketing: cada porcentaje de abajo es una cifra afirmada por el cliente/AWS y no auditada, y solo Sun Finance (n = 585 imágenes) y Adobe (su propio conjunto de pruebas) revelan una base muestral. El examen no te pedirá que recuerdes estos números: te pide que reconozcas qué control demuestra cada uno.

Evidencia de los casos de estudio para el Dominio 2

Lo que demuestran realmente los casos

Los patrones de fracaso son tan examinables como los éxitos: inferencia DIY (Forethought abandonó su propia pila de Amazon EKS por los endpoints multimodelo de SageMaker con −66 % y la inferencia serverless con ≈−80 %), OCR solo con LLM (Sun Finance, arriba) y visión por computadora propia a medida (Chronomics, cuatro meses frente a tres o cuatro semanas). Cada uno es una pregunta sobre elegir el nivel adecuado, que eso es Dominio 1, pero cada uno también tiene una cola del Dominio 2: quién es el dueño de las credenciales, dónde se asientan los datos y qué evidencia puedes producir después.

• 📚 ¿Sabías que…? AWS publica exactamente una tasa de resultado de proyectos: el 65 % de los proyectos del Generative AI Innovation Center llegó a producción en 2025 (algunos en solo 45 días), a partir de más de 1.000 implementaciones y organizados en torno al marco de las Five V's: Value → Visualize → Validate → Verify → Venture. El otro 35 % no se lanzó. Cualquier opción que afirme «todos los pilotos de IA generativa de AWS tienen éxito» contradice el propio blog de AWS.

---

Regulación y cambios en los servicios de AWS

Actualizaciones de 2026 (en octubre de 2026)

Todo lo que sigue fue verificado para este curso el 6 de octubre de 2026 y procede de fuentes de primera persona: la página del marco regulatorio de la Comisión Europea, los propios avisos de certificación y disponibilidad de servicios de AWS, y las páginas de producto de AWS. Las fechas están escalonadas, y colapsarlas es la manera clásica de perder este punto.

Techos de multa bajo el EU AI Act:

Dos marcos de gobernanza están detrás de esas fechas y siguen siendo voluntarios: el NIST AI Risk Management Framework (AI 100-1, ene 2023: Govern, Map, Measure, Manage, 19 categorías / 72 subcategorías) con su Generative AI Profile NIST AI 600-1 (jul 2024, 12 riesgos), y ISO/IEC 42001:2023 (dic 2023), el primer Sistema de Gestión de IA certificable. La posición de AWS no cambia con nada de esto: la evidencia de cumplimiento procede de AWS Services in Scope y AWS Artifact, y HIPAA sigue significando BAA + servicios elegibles para HIPAA.

• 📚 ¿Sabías que…? AWS define un ciclo de vida de servicios de tres palabras que aparece en las opciones del examen: Maintenance (sin clientes nuevos, sin funciones nuevas, sigue soportado), Sunset (fin de operaciones planificado, normalmente 12 meses) y Full Shutdown (eliminado del portafolio). El 30 de julio de 2026 un bloque grande de funciones de SageMaker, incluido Role Manager, pasó a maintenance, y por eso las notas de estudio antiguas que lo describen como «la vía actual para una carga de trabajo nueva» ya están equivocadas.

---

Preguntas de Práctica (Practice Questions)

---