AI on AWS and compliance — where your data actually lives

AI compliance doesn’t start with policy — it starts with architecture. When AI runs in your own AWS account, the data stays in the region you choose (e.g. the EU), inside an isolated network (VPC), encrypted with your key (KMS), with a full access trail (IAM, CloudTrail). An auditor doesn’t ask “do you have a policy” — they ask “where is the data and who has seen it”. An architecture that answers that by default does half of the compliance work for you.

A public chatbot sends your data “somewhere”. That is the first thing that breaks a GDPR or AI Act audit. Building AI on AWS, in your own account, flips the question: the data doesn’t leave, and you have proof of where it is.

Your data stays with you

In Amazon Bedrock, inputs and outputs are not used to train the base models and are not shared with model providers, and processing stays in the region where the API is called. For a business that is the difference between “we trust the vendor not to use our data” and “our data never leaves our account” — and it’s the first thing worth being able to demonstrate to a regulator.

Four pillars an auditor asks about

• Data residency. An EU region (e.g. eu-central-1) — you know and can show where the data physically sits. GDPR and sector rules expect this.
• Network isolation (VPC). AI runs in a private network, not exposed to the public internet — traffic through your VPC, not an open endpoint.
• Encryption and key control (KMS). Data encrypted at rest and in transit, with a key you manage — not “somewhere in the vendor’s cloud”.
• Identity and audit trail (IAM, CloudTrail). Who accessed what, and when — recorded. That is exactly what the AI Act expects of high-risk systems: logs and accountability.

”AWS-native is lock-in”? It’s an architecture choice, not a religion

A “vendor-agnostic” approach buys flexibility, but you pay for it in surface area: more providers means more places your data lives, more audit trails to stitch together, and more contracts to check. AWS-native gives deeper integration and a single, coherent audit trail — easier to demonstrate to a regulator. Neither approach is inherently better; we choose AWS-native because, for compliance, one auditable perimeter beats fragmentation. Lock-in is a myth: the data and the logic stay yours, and export is possible.

What this gives you under the AI Act

A high-risk system requires event logging, human oversight and technical documentation. An architecture that logs by default (CloudTrail), isolates (VPC) and encrypts under your key (KMS) does not satisfy the AI Act on its own — but it gives you a foundation on which those obligations can be demonstrated, instead of bolted on after the fact.

In short

AI compliance is architecture first, policy second. AI in your own AWS account = data in the region you choose, VPC isolation, KMS-key encryption, IAM/CloudTrail audit, data kept out of model training. You show the auditor proof, not a declaration.

What next

How we build RAG on AWS, with the data in your own account, is on the RAG / knowledge bases page. Architecture, risk classification and keeping compliance over time are closed out in our audit and ongoing care. If you want to know whether your current system can carry this, start with an AI Act compliance audit.