EU AI Act Art.43 Conformity Assessment + CLOUD Act: What Notified Body Auditors Will Find (2026)

Post #1590 in the sota.io EU Cyber Compliance Series — EU AI Act CLOUD Act Compliance Gap #4/5

In this series we have been building a case, piece by piece. The first post showed how the US CLOUD Act undermines EU AI Act Art.9 risk management and Art.10 data governance when your AI system runs on US-controlled cloud. The second post examined how CLOUD Act exposure breaks the record-keeping integrity required by Art.12 and the transparency obligations of Art.13. The third post traced how these gaps reach deployers through Art.26 and the Fundamental Rights Impact Assessment under Art.27.

This post reaches the endgame: the conformity assessment. This is the formal gate every provider of a high-risk AI system must pass before placing that system on the EU market. The August 2026 deadline is 55 days away. After that date, selling or deploying a non-compliant high-risk AI system in the EU exposes you to fines of up to €30 million or 6% of global annual turnover.

The conformity assessment is conducted either by the provider's own internal control team or, for the highest-stakes categories, by an accredited notified body (NB). Notified body auditors are forensic. They follow documentation trails. They check chain of custody. And when your technical documentation, model training records, logs, and incident history live on infrastructure that a US government subpoena can reach without your knowledge, they will find the gap.

What Art.43 Requires: Two Pathways to Conformity

Article 43 of the EU AI Act establishes the conformity assessment procedures that high-risk AI system providers must follow. The article creates two distinct pathways based on the nature of the system.

Pathway One — Annex I systems (product safety components): High-risk AI systems that are safety components of products regulated by the sectoral Union harmonization legislation listed in Annex I — medical devices, machinery, aviation, automotive — must follow the specific conformity assessment procedure set out in that sectoral legislation, supplemented by Annex VII (third-party NB assessment) or Annex VI (internal control), as determined by the sectoral rules. The NB conducting the sectoral assessment also checks the AI-specific requirements.

Pathway Two — Annex III systems (standalone high-risk AI): High-risk AI systems falling under Annex III — biometric identification, critical infrastructure AI, educational and vocational training AI, employment AI, access to public and private services, law enforcement AI, migration and border management AI, and administration of justice AI — generally use Annex VI: internal control. The provider's internal team reviews the technical documentation and confirms compliance. No external NB involvement is required under this pathway.

The critical exception: Under Art.43(3), providers of real-time remote biometric identification systems in publicly accessible spaces must have the conformity assessment conducted by a notified body under Annex VII, regardless of whether the system falls under Annex I or III. This is the only Annex III category for which NB involvement is mandatory under Art.43.

In practice, however, many providers of Annex III high-risk AI systems are voluntarily commissioning NB assessments for commercial reasons: enterprise buyers, public-sector procurement rules, and insurance underwriters increasingly require third-party certification as a condition of purchase. If you are building a high-risk AI system for B2B or public-sector markets, NB involvement is commercially inevitable even if it is not legally required for your specific category.

What Notified Body Auditors Actually Examine Under Annex VII

When a notified body conducts a conformity assessment under Annex VII, it does not merely review a PDF summary. It conducts a structured audit of the provider's quality management system (QMS) and the technical documentation for the specific AI system in scope.

The QMS audit under Art.17 examines: the documented procedures for design, development, and testing; the risk management process and its records; the data governance practices; the post-market monitoring plan; the incident response procedures; and the organisational structure and responsibilities.

The technical documentation review covers the elements required by Annex IV, which includes:

General system description: A description of the AI system, its intended purpose, the AI techniques used, the software components and their interdependencies.

Training, validation, and testing data: Documentation of the datasets used, their sources, preprocessing steps, selection criteria, and measures taken to examine for potential biases. For systems trained on personal data, this includes the legal basis and data governance records under Art.10.

Monitoring, functioning, and control: Logs automatically generated by the system under Art.12 and Art.19. Audit trail records of all key events. Evidence that the logging infrastructure was configured and maintained correctly throughout the system's operational history.

Algorithmic transparency: Technical descriptions sufficient to enable the competent authority to verify the provider's conformity claims. Not a black box. Not a summary. The actual technical record.

Risk management records: Documentation of the Art.9 risk management process, including all identified risks, the mitigation measures adopted, and the residual risk assessment. This must be a living document, updated through the system's lifecycle.

Post-market monitoring data: Records from the Art.72 post-market monitoring plan, including any incidents reported under Art.73, serious malfunction records, and corrective action documentation.

The notified body auditor's job is to verify that these records are complete, consistent, and trustworthy. They check for gaps. They check for unexplained deletions. They check for documentation that was created retroactively to fill holes. They have seen every evasion technique in the book.

Art.44: The Certificate and Its Conditions

When a notified body completes a conformity assessment and determines the system is compliant, it issues a certificate under Article 44. Certificates issued by notified bodies have a maximum validity of four years and are renewable subject to a new assessment. They must be submitted to the EU database on AI required by Art.49.

Art.44 is not the end of the story. The certificate is conditional on the system remaining as documented. If the provider makes a substantial modification to the system — new training data, new model version, changed intended purpose, new deployment context — the certificate may be invalidated. Art.45 governs substantial modifications: if a modification substantially modifies the design or performance of the system, a new conformity assessment is required.

The practical implication: a notified body certificate is a liability as well as an asset. The certificate creates a documented baseline. Any deviation from that baseline that is not properly documented and assessed is an evidential gap — and if that gap can be attributed to third-party cloud infrastructure over which you did not have full control, the gap is yours to own.

The CLOUD Act Evidence Integrity Problem

Here is where the series comes full circle. Everything the notified body auditor examines — the QMS records, the training data documentation, the logs under Art.12/19, the risk management records under Art.9, the incident reports under Art.73, the post-market monitoring data under Art.72 — exists somewhere on a physical server. The question of where is not a technical curiosity. It is a legal fact with evidentiary consequences.

If any of this documentation infrastructure lives on Amazon Web Services, Microsoft Azure, or Google Cloud Platform, it is subject to the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. §2523).

The CLOUD Act permits the US government to compel these cloud providers to produce data held anywhere in the world, including EU servers, without notifying the data subject or the foreign government. The provider — AWS, Microsoft, Google — receives the production order and complies. The EU-based customer may not be notified, and under some gag orders, is legally prohibited from being notified.

For a conformity assessment, this creates three categories of evidence integrity problem:

The silent access problem: If a US government production order accessed your system's training data records, incident logs, or QMS documentation between two points in time that the NB auditor is examining, the NB cannot determine whether those records are complete as originally generated, or whether they reflect the state after disclosure. The chain of custody is broken.

The undocumented deletion problem: Production orders sometimes require the cloud provider to copy data to a US government system. They do not require notification of the data subject. If any record in your technical documentation was copied as part of a disclosure, you have no knowledge of it, and therefore you cannot represent to the NB that your documentation is complete and unaltered. This is not a theoretical risk — it is the operational design of the CLOUD Act.

The post-certification modification problem: Even after a notified body has issued a certificate under Art.44, subsequent CLOUD Act disclosures affecting the AI system's operational logs or monitoring records could create gaps that invalidate the technical basis of the certificate. A certificate issued on the basis of complete records is not valid against a post-issuance audit that reveals records were incomplete.

What Sophisticated NB Auditors Are Already Asking

Notified body accreditation is governed by Regulation (EC) No 765/2008 and the competence standards of ISO/IEC 17065 for product certification. As NB auditors have become familiar with the EU AI Act requirements, several leading NBs have begun incorporating infrastructure provenance questions into their pre-audit questionnaires.

The questions take forms like:

• "Where is the technical documentation required by Annex IV stored? On what cloud infrastructure?"
• "Who has administrative access to the systems storing the Art.12 automatically generated logs?"
• "Is the documentation infrastructure subject to any foreign surveillance or compelled production legislation?"
• "Can you provide a chain-of-custody record for the technical documentation from development to this assessment?"

These are not hostile questions. They are the logical consequence of what Art.43 requires: an auditor must be able to form a reliable opinion on the completeness and integrity of the documentation presented. If the documentation is hosted on infrastructure over which a foreign government has compelled-access rights, the auditor cannot form that opinion without qualification.

The qualification matters. A certificate issued with a scope limitation — "on the basis of documentation provided, which the provider attests was complete at the time of submission" — is a weaker commercial and legal instrument than an unqualified certificate. In regulated industries (financial services, healthcare, critical infrastructure) where NB assessment is being used in procurement, buyers and regulators will notice the difference.

The Registration Gap

Art.49 requires providers of high-risk AI systems to register their systems in the EU database on AI before placing them on the market. The registration record must reference the conformity assessment procedure used and, for Annex VII systems, the notified body certificate number.

If a provider registers a system, obtains NB certification, and then modifies the system's infrastructure — migrating from one cloud provider to another, adding a new data processing region, changing the logging architecture — the registration is technically outdated. Under Art.49, the provider should update the registration to reflect the current state.

Cloud migrations happen continuously in production AI systems. Teams add AWS regions, change Azure tenants, add GCP processing pipelines. Each change is a potential registration discrepancy. If the NB's certificate was based on infrastructure documentation that no longer reflects the actual deployment, the certificate's scope may not cover the current system state.

The CLOUD Act implication is direct: a provider that migrates AI system infrastructure from an EU-controlled cloud to a US-controlled cloud after obtaining NB certification has potentially changed the evidence integrity posture of the system in ways that the certificate does not reflect. The certificate covers the system as it existed at assessment time.

The Market Surveillance Authority Scenario

Beyond notified bodies, providers of high-risk AI systems must cooperate with market surveillance authorities (MSAs) under Art.21. MSAs are national enforcement bodies — the CNIL in France, the BNetzA in Germany, the ICO in the UK — that have powers to request documentation, conduct on-site inspections, and require access to technical systems.

An MSA exercising powers under Art.21 can request the provider's technical documentation. If that documentation is stored on US-controlled cloud infrastructure, the provider faces a practical dilemma: the MSA has a legal right to access under EU law, and the US government may have a concurrent claim to the same data under CLOUD Act. The provider is caught between two legal regimes, with conflicting requirements on what to disclose, to whom, and whether to notify the other party.

This is not a hypothetical. It is the structural conflict that the EU's international data transfer rules have been grappling with since Schrems I (2015) and Schrems II (2020). The EU AI Act adds a new dimension: it is not just personal data at stake, but the technical documentation of AI systems that affect fundamental rights.

Building a CLOUD Act-Resistant Conformity Assessment Record

For providers approaching the August 2026 deadline, the conformity assessment is the last gate before market entry. The documentation you present to your NB or to an MSA must be complete, consistent, and — if you want an unqualified certificate — provably intact.

The simplest way to achieve this is to host your AI system's compliance documentation infrastructure on cloud infrastructure that is not subject to CLOUD Act. This means:

Provenance-aware technical documentation: Your Annex IV documentation, training data records, risk management records, and QMS documentation should be stored on infrastructure where you can credibly represent to an NB that the documentation has not been subject to compelled foreign-government access. EU-native cloud providers — hosted in Germany, the Netherlands, France, or elsewhere in the EU, with no US parent — provide this assurance. AWS Frankfurt, Azure Netherlands, and GCP Belgium do not, because the parent companies are US persons subject to CLOUD Act.

Logging infrastructure sovereignty: Your Art.12 and Art.19 logs are particularly sensitive from an evidence integrity perspective, because they are the continuous operational record of the AI system's behaviour. Logs stored on EU-native infrastructure are not subject to CLOUD Act reach. Logs stored on AWS/Azure/GCP are, regardless of the server's geographic location.

QMS system sovereignty: Your quality management system — the procedures, review records, risk assessments, corrective action logs — should be stored where you control access and where foreign compelled access is not legally possible. This is what an NB auditor is examining when they review your QMS under Art.17.

Incident reporting chain: Your Art.73 serious incident reports and the underlying incident documentation should be maintained on infrastructure that preserves chain of custody. If an incident occurs, the sequence of events, the decision records, the notification timeline must be complete and unalterable by third-party access.

Practical Architecture for NB-Ready AI Compliance Infrastructure

A developer building an EU-native AI compliance infrastructure for conformity assessment purposes would typically structure it as follows:

Compliance documentation tier: A version-controlled repository for Annex IV documentation, hosted on EU-native infrastructure (Hetzner, OVHcloud, Scaleway, or equivalents). Git provides inherent integrity evidence — cryptographic commit hashes that verify the documentation state at any point in time. Hosted on EU infrastructure with no US parent, this record is not subject to CLOUD Act.

Log aggregation tier: Structured logs under Art.12/19, retained in an EU-hosted log aggregation system (Grafana Loki, Elasticsearch, or equivalent, self-hosted on EU servers or hosted by an EU-native provider). Logs should include timestamps, user and system actions, and model decision records sufficient to reconstruct the system's operational history.

Risk management record system: The Art.9 risk management documentation — risk register, mitigation records, residual risk assessments — maintained in a structured format on EU-native infrastructure, with audit log of all changes, including who made them and when.

Incident response system: The Art.73 incident pipeline — detection, triage, classification, notification, resolution — running on infrastructure where the chain of custody can be unambiguously documented. This is particularly important for the timing requirements under Art.73: 2 days for serious incidents to national authorities, 15 days for the detailed notification, and immediate safety measures where applicable.

NB access provisioning: A read-only access pathway for the notified body auditor, providing direct access to the documentation infrastructure under controlled conditions. This eliminates the intermediary step of exporting documentation and gives the NB direct evidence of the record's current state.

Developer Checklist: NB-Ready Conformity Assessment Preparation

Use this checklist to assess your current conformity assessment readiness in relation to CLOUD Act exposure:

Documentation infrastructure audit:

• Identify where all Annex IV technical documentation is currently stored
• Identify the cloud provider and legal entity for each storage location
• Determine whether each provider is a US person subject to CLOUD Act
• Document the result in your QMS as part of your Art.9 risk assessment

Log integrity assessment:

• Audit the location of all Art.12 and Art.19 log storage
• Verify that log retention meets the requirement to retain logs for the period the system is in service
• Assess whether log integrity can be cryptographically verified (hash chains, append-only log structures)
• Document any periods where logs may have been subject to CLOUD Act access

QMS sovereignty review:

• Identify the infrastructure on which your Art.17 QMS is maintained
• Assess whether the QMS documentation can be credibly represented as complete to an NB auditor
• Check whether your QMS review records include the infrastructure provenance of each document

Training data provenance:

• Map the storage locations of all training, validation, and testing data referenced in your Annex IV documentation
• Verify that data governance records under Art.10 include the jurisdictional status of storage infrastructure
• Assess the impact of CLOUD Act exposure on your ability to represent data completeness to an NB

NB audit preparation:

• Prepare to answer NB pre-audit questions about infrastructure provenance
• Draft a clear statement of which cloud providers host which parts of the system's documentation
• Where US-controlled cloud is used, prepare a risk assessment explaining how CLOUD Act exposure is managed
• Consider whether voluntary migration to EU-native infrastructure is warranted before the certification process

Registration currency:

• Verify that your Art.49 EU AI database registration reflects the current deployment infrastructure
• Review whether any infrastructure changes since initial registration require an update
• Confirm that your conformity assessment documentation reflects the current — not a prior — infrastructure state

The August 2026 Gate

The EU AI Act's August 2, 2026 deadline is not a reporting deadline. It is a market access gate. After that date, providers of high-risk AI systems that have not completed their conformity assessment and obtained the required declaration of conformity under Art.47 cannot legally sell or deploy those systems in the EU. For systems subject to NB assessment under Annex VII, the certificate must be in hand.

The notified body pipeline is already constrained. There are a limited number of accredited NBs for AI systems in the EU, and the queue for assessment slots has been growing since the Act entered force. Providers who approach the deadline without documentation infrastructure that supports an unqualified NB assessment will face a choice: delay market entry, obtain a qualified certificate that weakens their commercial position, or migrate infrastructure in a compressed timeline.

The CLOUD Act problem is solvable. Migration from US-controlled cloud to EU-native infrastructure is an engineering project, not a legal impossibility. What it requires is acknowledging the problem exists, understanding what an NB auditor will find, and making the architecture decision before the certification process begins — not during it.

Where This Series Goes Next

In the next and final post of this series, we will synthesise the full picture: a CLOUD Act-resistant EU AI Act compliance architecture, with a 30-step developer checklist covering everything from initial system design through conformity assessment, market surveillance readiness, and post-market monitoring. Every Art.9, Art.12, Art.26, Art.43, and Art.73 obligation, mapped to infrastructure decisions that eliminate the CLOUD Act exposure gap.

The August 2 deadline is not a future event. It is now.

sota.io is EU-native managed PaaS — Hetzner Germany, no US parent, not subject to CLOUD Act. If you need infrastructure for your AI compliance documentation that an NB auditor can rely on, see what we offer.