Security, Compliance, and Governance for AI Solutions
Shared responsibility and access control
AWS operates on a shared responsibility model: AWS secures the cloud, customers secure what they put in it, including data, prompts, and model configuration. Use IAM for least-privilege access, roles rather than long-lived keys, and separate permissions for training, deployment, and data access. Encrypt data at rest with AWS KMS and in transit with TLS. Amazon VPC, PrivateLink, and VPC endpoints keep traffic private. AWS CloudTrail logs API activity; Amazon CloudWatch monitors metrics and alarms; AWS Config tracks resource compliance.
Data protection and governance
Know that Amazon Bedrock does not use customer prompts or outputs to train base models, and that data can be kept private within your account. SageMaker supports network isolation and private endpoints for training and inference. For governance, define data classification, retention, and lineage; use AWS Audit Manager and Security Hub for evidence and posture; apply Bedrock Guardrails to block sensitive data such as personally identifiable information from leaving the application.
Traps to expect
Questions misstate the shared responsibility boundary, assuming AWS secures customer data or prompts. Another trap is treating encryption alone as full compliance, or confusing CloudTrail (API audit) with CloudWatch (performance monitoring). Watch for answers that grant broad permissions or store secrets in code.
Rule of thumb
Apply least privilege, encrypt everywhere, log everything, and keep data private to your account. If a question asks who secures the model inputs, the answer is the customer.
Worked example
A regulated team deploys a Bedrock chatbot. They scope IAM roles per function, enable CloudTrail, encrypt with KMS, add Guardrails to block PII, and confirm prompts are not used for model training.