MICKAI®ArticlesAWS Bedrock versus sovereign on-p…
Article · 18 August 2026

AWS Bedrock versus sovereign on-premise AI: is 'we do not train on your data' enough for regulated workloads?

A no-training promise addresses one reuse path but leaves CLOUD Act reach and verifiable audit unsolved, which is why regulated workloads need sovereign control.

Author
Micky Irons
Published
18 August 2026
Follow Micky Irons
LinkedInX
aws bedrocksovereign aicloud actdata sovereigntyregulated workloads
AWS Bedrock versus sovereign on-premise AI: is 'we do not train on your data' enough for regulated workloads?

No. A promise not to train on your data is a narrow assurance about one reuse path, not a guarantee of jurisdictional control or verifiable audit. AWS Bedrock can keep your prompts out of model training and still remain reachable under the United States CLOUD Act, because a provider headquartered in the United States can be compelled to produce data it holds regardless of region. For a regulated workload the two unsolved questions are where the data can be reached and whether every access leaves a tamper-evident record. A no-training clause answers neither.

This matters in 2026 because the compliance floor has risen. DORA has applied to financial entities across the European Union since January 2025, NIS2 now reaches essential and important entities across critical sectors, and GDPR still governs personal data leaving its protections. The high-risk obligations under Annex III of the EU AI Act, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded high-risk systems under Annex I moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. The workloads under scrutiny, credit decisions, clinical triage, fraud analysis and case handling, cannot run on infrastructure a buyer cannot audit.

What does "we do not train on your data" actually cover?

It covers one thing: the provider will not fold your inputs and outputs back into its foundation models. That is a real commitment, and also the easiest to make: it costs the provider little and is nearly impossible to independently disprove. It says nothing about who else can compel access while the data sits in the provider's custody, nothing about the completeness of the logs recording that access, and nothing about what happens under a lawful production order. A regulated buyer needs assurances that survive a subpoena, not just assurances about a training pipeline.

Can AWS Bedrock be reached under the US CLOUD Act?

Yes. The CLOUD Act, enacted in 2018, lets United States authorities compel a US-based provider to disclose data in its possession, custody or control, whether that data sits in Frankfurt, Dublin or London. Choosing an EU region reduces latency and helps with data-residency paperwork, but it does not remove the provider from US jurisdiction. This is a matter of corporate domicile, not encryption strength or regional configuration, which is why a technical control alone cannot close it.

What can an auditor actually check?

With a managed cloud service, an auditor checks the logs the provider chooses to expose, such as CloudTrail entries and access records. Those logs are generated, held and rotated by the same party being audited. The auditor cannot prove they are complete and cannot verify them without trusting the provider's own systems. That is a trust-me model dressed as evidence. A defensible position needs a record the operator holds, that no one can alter after the fact, and that a third party can verify independently.

A privacy promise you cannot verify and a jurisdiction you cannot control are assurances about intent, not guarantees about outcome.

How does sovereign on-premise AI close the gap?

Mickai is a Sovereign Intelligence Operating System, a SIOS that runs offline on operator-owned hardware inside the buyer's own perimeter. It changes the question from whether you trust the provider to whether you can verify the outcome yourself. The mechanisms are concrete:

  • Zero-egress inbound perimeter: the system accepts work but sends nothing out, so there is no external endpoint to compel and no data leaves the estate.
  • Hardware-attested identity: every action is bound to an attested device and operator, so the record shows who did what on which machine.
  • Post-quantum signed audit ledger: each action is sealed into a tamper-evident ledger signed with FIPS 204 (ML-DSA), with FIPS 205 (SLH-DSA) as a stateless-hash alternative, so the record stays verifiable against quantum attack.
  • Offline verifiability: a third party can check those signatures without network access, so trust does not depend on the operator's cooperation.
  • Cross-model consensus: high-stakes outputs are cross-checked across sovereign models before action, reducing single-model error.

The architecture behind this sits within 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD. They are patent pending, never granted or patented.

Which rules make an operator-held ledger necessary?

DORA requires financial entities to evidence operational resilience and control over third-party ICT risk. NIS2 pushes essential and important entities toward demonstrable security governance. ISO/IEC 42001 sets out an AI management system standard that expects traceability of AI decisions. GDPR demands accountability for personal data throughout its handling. None is satisfied by a promise; each is satisfied by evidence, and the strongest evidence is a record the regulated entity controls and can prove was not altered. A sealed, operator-held ledger turns compliance from an assertion into a demonstration.

When is AWS Bedrock still the right choice?

For workloads that carry no regulated or sensitive data, Bedrock is a capable route to production, and its no-training terms are a reasonable safeguard. The calculus changes when the data falls under DORA, NIS2, GDPR or sector rules, when the workload feeds a decision a regulator can later question, or when the buyer must prove control to an auditor rather than assert it. Sovereign on-premise AI is not a rejection of cloud AI; it is the fit for workloads where jurisdiction and verifiable audit are non-negotiable.

How should a regulated buyer decide?

Before trusting any AI service with regulated data, ask three questions. Can a foreign authority compel access through the provider's corporate domicile? Can you produce a complete access record that a third party verifies without the provider's help? Can you run the workload with the network cable pulled? If any answer is no, that workload does not belong on the service, and a no-training promise changes none of those answers.

Frequently asked questions

Does AWS Bedrock train its models on your prompts?

No. AWS states that Bedrock does not use your inputs or outputs to train its foundation models, and that is a genuine safeguard. It does not address whether your data can be compelled through AWS's US domicile under the CLOUD Act, nor give you an independently verifiable audit record. For regulated workloads those two gaps matter more than the training question.

Does keeping data in an EU region put it outside US reach?

No. Data residency in Frankfurt, Dublin or another EU region controls where data is stored, not who can compel it. Because AWS is headquartered in the United States, the CLOUD Act can reach data in its custody regardless of region. Jurisdiction follows the provider's corporate domicile, so a regional control cannot remove it.

What is the difference between data residency and data sovereignty?

Data residency is about the physical location where data is stored. Data sovereignty is about who holds legal and practical control over it. You can have EU residency and still lack sovereignty if a foreign provider can be compelled to disclose the data. Sovereignty is achieved when the operator holds the data, the keys and the audit record inside its own perimeter.

Why does a post-quantum signed audit ledger matter?

An audit record is only useful if no one can forge or alter it, today or years later. Signing the ledger with FIPS 204, the primary post-quantum signature standard, and optionally FIPS 205, keeps those signatures valid even once quantum computers can break older schemes. That protects the long retention periods regulated records demand.

Is sovereign on-premise AI only for governments?

No. Any organisation running regulated or sensitive workloads faces the same jurisdiction and audit questions, including banks, insurers, healthcare providers and critical-infrastructure operators. The driver is the sensitivity of the workload and the applicable rules, not the sector label. Wherever a buyer must prove control rather than assert it, an offline, operator-owned system with a verifiable ledger fits.

Subscribe
Get every new Mickai article by email.

Long-form essays on sovereign AI from Micky Irons. One email per article. No tracking, no marketing, no third parties. Every email includes a one-click unsubscribe link.

Prefer RSS? Subscribe at /articles/feed.xml.

Originally published at https://mickai.co.uk/articles/aws-bedrock-vs-sovereign-on-premise-ai. If you operate in a regulated sector or want sovereign AI on your own hardware, the audit form on mickai.co.uk is the entry point.
More articles
18 Aug 2026
How Telecoms Operators Meet the Telecommunications Security Act With AI That Never Leaves the Network
Telecoms operators meet the Telecommunications Security Act code of practice with AI that runs inside the security-critical boundary on operator-owned hardware. A zero-egress perimeter keeps network configuration and signalling data within operator control, so nothing sensitive crosses out to a public cloud service.
18 Aug 2026
Can energy operators run AI on grid and OT data on-premise to satisfy the Cyber Assessment Framework?
Yes. Energy operators can run forecasting and anomaly detection on grid and OT data entirely on their own hardware, and this satisfies the Cyber Assessment Framework more cleanly than cloud analytics, because telemetry never leaves the audited perimeter and no third-party processor exists to assess.
18 Aug 2026
How Airports Meet EASA Part-IS from February 2026 with On-Site AI
Part-IS applies to aerodrome operators from 22 February 2026 and makes the airport, not its vendor, accountable for information-security risk. Running AI on operator-owned hardware behind a zero-egress perimeter keeps passenger and operational data inside that boundary, so a supplier's SOC 2 cannot discharge it.
18 Aug 2026
Can Automotive Suppliers Use AI on OEM Design Data While Keeping TISAX Prototype Protection?
Automotive suppliers can run AI on OEM design and prototype data and keep TISAX prototype protection, but only when the model runs on their own hardware inside the protected zone. Public cloud AI transmits the data outward, which prototype protection forbids.