Can you use AWS Bedrock for regulated financial and health data?

Yes, AWS Bedrock can process regulated financial and health data in many cases: it is HIPAA eligible under a signed Business Associate Addendum, keeps prompts and inference inside your own AWS account, and does not use your data to train the foundation models. The limit is architectural, not contractual: your data still runs on a control plane the vendor operates, on hardware the vendor owns, reachable by vendor personnel and by the US CLOUD Act. For most enterprise workloads that is acceptable, but for the hardest regulated tiers it is not. The honest test is whether your obligation is met by a contract or by physics.

This question matters more in 2026 than it did two years ago. DORA has been in force across EU financial services since January 2025, NIS2 has widened the scope of essential and important entities, and supervisors now ask where a model runs and who can reach it. The EU AI Act adds pressure on a longer clock: the high-risk Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and Article 50 transparency duties largely unchanged. We read that deferral as a build window, not a reprieve.

What does AWS Bedrock actually guarantee for regulated data?

Bedrock gives you a strong contractual perimeter. Under the AWS BAA it is HIPAA eligible, so covered entities and business associates can process protected health information within scope. Foundation model providers do not receive your inputs, and your data is not used to improve the base models. You can encrypt with your own KMS keys, keep traffic on private VPC endpoints, and record calls in CloudTrail. For a bank or hospital moving from a public consumer service, this is a real improvement in control.

Where does the residual risk actually sit?

The residual risk sits below the account boundary. Bedrock runs on infrastructure the vendor owns and operates. The control plane, hypervisor, physical hosts and privileged staff are all the provider's. Your key policies and network rules constrain access, but they are enforced by the same operator you are trying to isolate from. This is the difference between governance that is contractual and governance that is architectural. Regulators increasingly want the second kind of assurance for the most sensitive tiers.

Which rule makes an operator-owned option necessary?

Several, and each targets a different gap. The US CLOUD Act lets US authorities compel a US-headquartered provider to produce data it holds or controls, wherever it physically sits, a jurisdictional exposure a European or Gulf regulator may not accept for the most sensitive records. For UK financial services, the FCA and PRA expect firms to retain accountability and to avoid the concentration and lock-in that would stop them exiting or auditing a critical third party. HIPAA requires a covered entity to control and evidence access to protected health information, GDPR restricts cross-border transfer, and DORA adds resilience and oversight duties over ICT third parties. For classified or national-security workloads, no commercial cloud is in scope at all. None of these rules forbids Bedrock outright; they raise the evidentiary bar until, at the top tier, only operator-owned and offline infrastructure clears it.

What can an auditor actually check?

An auditor can verify Bedrock's certifications, your BAA, your KMS key policies, your VPC configuration and your CloudTrail history. What an auditor cannot independently verify is the vendor's own privileged access at the layers beneath your account, because that evidence is attested by the vendor rather than reproducible by you. The stronger test is offline verifiability: can the auditor confirm, from a sealed record you hold, exactly which model ran, on which data, under whose identity, without asking the operator to vouch for it. That is the assurance a purely contractual model cannot give.

“The real question is not whether regulated data can enter a vendor cloud, but whether your compliance rests on a promise you cannot inspect or on an architecture you can prove.”

How does a sovereign alternative close the gap?

Mickai is a Sovereign Intelligence Operating System, a SIOS, built for the tier where a contract is not enough. It runs offline on operator-owned hardware, so there is no vendor control plane and no third-party personnel beneath the account boundary. A zero-egress inbound perimeter keeps regulated data on the estate. Identity is hardware-attested and bound to the audit chain, so every action is tied to a verified operator, not a shared credential. Every action is written to a post-quantum signed audit ledger, sealed with FIPS 204 (ML-DSA) as the primary standard and FIPS 205 (SLH-DSA) available, so the record stays verifiable even against a future quantum adversary. Sovereign models run locally, and cross-model consensus lets several models check one another before an answer is trusted. The design intent, expressed across 104 filed UK patent applications with approximately 2,340 claims owned by Mickai LTD and never granted or patented, is to make governance a property of the system rather than a clause in a contract.

When is Bedrock the right choice and when is it not?

Bedrock is the right choice when your regulator accepts vendor-attested controls, when the data tier tolerates US jurisdictional reach, and when speed on managed infrastructure outweighs the need for physical isolation. It is the wrong choice when your obligation demands that the operator, and no one else, can reach the data, when CLOUD Act exposure is disqualifying, when you need offline verifiability an auditor can reproduce, or when the workload is classified. The decision is not vendor loyalty. It is matching the assurance model to the sensitivity of the data.

Frequently asked questions

Is AWS Bedrock HIPAA compliant for health data?

Bedrock is HIPAA eligible when you sign the AWS Business Associate Addendum and keep the workload within documented scope. Eligibility is not compliance: you remain the covered entity or business associate and must configure encryption, access control and logging correctly and evidence that you did. The accountability for the data stays with you.

Does AWS see or train on data sent to Bedrock?

AWS states that Bedrock does not use your prompts or outputs to train the foundation models, and the model providers do not receive your data. Inference runs inside your account and region. The residual point is that the service runs on infrastructure AWS operates, so privileged vendor access at the platform layer rests on contract and certification, not on an architecture you can inspect.

Can UK FCA or PRA regulated firms use AWS Bedrock?

Yes, many do, provided they meet the outsourcing and operational resilience expectations. The FCA and PRA expect the firm to retain accountability, to assess concentration and lock-in risk with a critical third party, and to keep a workable exit and audit path. For the most sensitive workloads, some firms conclude only operator-owned infrastructure gives the control and exit assurance supervisors want.

Does the US CLOUD Act affect data in AWS Bedrock?

Yes, in principle. The CLOUD Act allows US authorities to compel a US-headquartered provider to produce data it holds or controls, wherever it is stored. For many workloads that is manageable. For records a European or Gulf regulator, or a national-security mandate, requires to stay beyond foreign legal reach, it can be disqualifying, which is why operator-owned, offline processing exists for that tier.