El mismo principio que rige la seguridad en cloud en general aplica a los servicios de IA — pero con una capa adicional: los prompts, el contenido generado y el propio modelo base introducen nuevas líneas de responsabilidad que no existen en cómputo o almacenamiento tradicional.
Contenido
AWS es responsable de la infraestructura de cómputo para IA, de la seguridad y disponibilidad del foundation model base. El cliente es responsable de sus prompts y los datos que envía al modelo, del control de acceso (IAM) a los servicios de IA, y del cumplimiento normativo de su caso de uso específico.
La diferencia con el modelo "clásico" de IaaS/PaaS/SaaS es que en IA hay un nuevo objeto que proteger: el prompt (lo que envías al modelo) y la respuesta generada. Ninguno de los dos existía como concepto de seguridad en cómputo tradicional.
Por qué esto importa en el examen
Una pregunta frecuente del AIF-C01 presenta un escenario de fuga de datos o de contenido inapropiado generado por un modelo, y pide identificar si la falla es de AWS o del cliente. Casi siempre la respuesta correcta es "el cliente" — porque AWS no controla qué envías al modelo ni cómo configuras el acceso.
Quién es responsable de cada capa cuando usas servicios de IA en AWS.
| Capa | Responsable |
|---|---|
| Infraestructura física (GPUs, servidores, datacenters) | AWS |
| Pesos y seguridad del foundation model base | AWS |
| Disponibilidad del servicio (SLA) | AWS |
| Aislamiento entre tenants (tus datos no entrenan el modelo de otros) | AWS |
| Prompts que envías al modelo | Cliente |
| Datos usados para fine-tuning o RAG | Cliente |
| Control de acceso (IAM) a los servicios de IA | Cliente |
| Configuración de Guardrails / filtros de contenido | Cliente |
| Cumplimiento normativo del caso de uso (HIPAA, GDPR, PCI DSS) | Cliente |
| Auditoría de quién invoca qué modelo (CloudTrail habilitado) | Cliente |
| Cifrado de datos de entrenamiento y artefactos de modelo | Compartida |
| Detección de sesgo en el modelo entrenado por el cliente | Cliente |
Sin importar si usas Bedrock (modelo administrado) o SageMaker (modelo propio), estas responsabilidades no cambian.
AWS SIEMPRE es responsable de:
El cliente SIEMPRE es responsable de:
Bedrock te da acceso a foundation models ya entrenados vía API. Es el equivalente de "SaaS" en el mundo de la IA: la mayor parte de la pila la gestiona AWS.
AWS gestiona:
Tú gestionas:
Con SageMaker entrenas y despliegas tu propio modelo. Es más parecido a "IaaS": tienes más control, y por lo tanto más responsabilidad.
AWS gestiona:
Tú gestionas:
Caso realista
Una fintech construye un asistente interno con Bedrock para que los agentes de soporte resuman el historial de un cliente antes de una llamada. Para ahorrar tiempo, un desarrollador pega directamente en el prompt el número completo de cuenta, el DNI y el historial de transacciones del cliente — sin enmascarar ningún dato — y no configura Bedrock Guardrails para filtrar información sensible en las respuestas.
Semanas después, un log de la aplicación (mal protegido, con acceso demasiado amplio por un rol IAM sobre-permisivo) queda expuesto. Ese log contiene los prompts completos, incluyendo los datos financieros sin enmascarar.
¿Quién es responsable? El cliente, en cada punto de la cadena: decidió qué incluir en el prompt, no configuró Guardrails para enmascarar PII, y configuró un rol IAM con permisos excesivos sobre los logs. AWS entregó un modelo funcional y una infraestructura segura — ninguna de esas tres decisiones estaba bajo su control.
Por defecto, las llamadas a la API de Bedrock o a un endpoint de SageMaker pueden salir por internet público (aunque cifradas con TLS). AWS PrivateLink permite exponer esos servicios a través de un endpoint de interfaz privado dentro de tu VPC, de forma que el tráfico entre tu aplicación y el servicio de IA nunca sale a internet.
Compara la ruta pública hacia Bedrock contra una ruta privada vía PrivateLink y confirma la configuración privada.
+1 más...
Cuando un agente de IA actúa de forma autónoma (llama APIs, ejecuta acciones, invoca otras herramientas), necesitas gestionar identidad y permisos específicos para ese agente — no solo para el usuario humano que lo invocó.
Además de prompt injection sobre la entrada, hay riesgos que aparecen en la salida del modelo y que deben filtrarse antes de mostrarla al usuario final.
Bedrock Guardrails incluye filtros de toxicidad configurables como parte de su función de moderación de contenido.
Documentar de dónde vienen los datos usados para entrenar o para dar contexto a un modelo (linaje de datos) es clave para trazabilidad y auditoría — especialmente cuando hay que responder "¿por qué el modelo dijo esto?" o "¿de qué documento salió esta respuesta?".
Además de RAG en general, existen técnicas concretas para reducir y detectar alucinaciones antes de que lleguen al usuario.
Puedes heredar certificaciones de AWS para la infraestructura, pero el cumplimiento de tu caso de uso específico sigue siendo tuyo — especialmente si procesas datos regulados.
Lo que AWS certifica (infraestructura)
Lo que tú aún debes hacer
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa usa Amazon Bedrock para un chatbot interno. Un empleado incluye información médica confidencial de un cliente directamente en un prompt, sin enmascararla, y esa información termina expuesta en logs con permisos IAM demasiado abiertos. Según el modelo de responsabilidad compartida, ¿quién es responsable de esta brecha?
Inicia sesión para llevar tu progreso.