EU AI Act Conformity Assessment: The Two Routes, Who Performs Each One, and What the Audit File Has to Contain

Article 43 of the EU AI Act prohibits placing a high-risk AI system on the Union market without a completed conformity assessment. The article specifies two routes. The first is an internal control procedure based on Annex VI, available for most high-risk systems where harmonized standards apply. The second is a third-party procedure based on Annex VII, required for biometric identification systems and any case where harmonized standards are absent or not applied in full. Both routes require the technical documentation set out in Annex IV to be assembled and kept current. The August 2, 2026 effective date for high-risk system requirements is the binding deadline.

I want to walk through what each conformity route actually requires, what the Annex IV file has to contain, and where the record-keeping infrastructure under Article 12 and Article 19 connects to the assessment.

Mandate

The conformity assessment is the procedural gate that demonstrates a high-risk AI system meets the substantive requirements in Articles 8 through 15. Those requirements cover the risk management system, the data governance approach, the technical documentation, the record-keeping mandate, the transparency obligation, the human oversight design, the accuracy and resilience criteria, and the cybersecurity properties.

Route 1: internal control procedure (Annex VI)

The internal control procedure is the lighter route. The provider, which is the developer or the entity placing the system on the market, performs the assessment internally. The provider must verify that the quality management system under Article 17 is in place, that the technical documentation under Article 11 and Annex IV is complete, that the conformity is established against the relevant harmonized standards or common specifications, and that the assessment is documented in writing. No notified body is involved. The provider signs the EU declaration of conformity and applies the CE marking.

The internal control route is available for most high-risk systems listed in Annex III, including AI used in critical infrastructure, education, employment, essential private and public services, law enforcement, migration and border control, and administration of justice. The route is conditional on the existence of harmonized standards or common specifications that cover the substantive requirements. Where the standards do not cover a requirement, the provider cannot rely on the internal route for that requirement.

Route 2: third-party assessment with notified body (Annex VII)

The third-party route is mandatory for biometric identification systems and for any case where the provider cannot rely fully on the internal route. A notified body, designated by a member state under Article 31, performs the assessment. The notified body reviews the technical documentation, audits the quality management system, and may inspect the AI system in operation. The notified body issues an EU technical documentation assessment certificate, valid for up to five years, that becomes part of the conformity file.

The third-party route is more expensive and slower, but the certificate provides a defensible record when a national competent authority later opens an investigation. The number of notified bodies designated for AI conformity assessment as of June 2026 remains limited, and the queue at most notified bodies has lengthened through the spring.

Annex IV: what the technical documentation must contain

Annex IV lists ten categories of documentation. The provider must include a general description of the AI system, the design specifications, the description of the system architecture, the data and data governance information, the human oversight design, the description of the system's life cycle and resource use, the risk management documentation, the change-management procedures, the standards applied, and the EU declaration of conformity.

The data governance category is where most providers struggle. Annex IV expects the documentation to describe how training, validation, and test data sets were selected, labeled, cleaned, and bias-checked, including the rationale for each choice. The record-keeping category expects the documentation to describe the Article 12 logging system, the Article 19 record retention, and the audit access procedure. Most enterprise deployers have not yet built the logging system that the record-keeping section presumes exists.

Compliance gap

The conformity assessment is a paper exercise unless the underlying architecture produces the artifacts the documentation describes.

The record-keeping section depends on an architecture that does not exist yet

Annex IV expects the documentation to describe the logging mechanism that satisfies Article 12 and Article 19. Most enterprise AI deployments today record application-side request and response payloads in unstructured JSON, rotated nightly into object storage. The records lack the identity context, the data classification, the policy state, and the cryptographic integrity that Article 19 expects. The documentation can describe what should exist, but the assessment file becomes inaccurate at the moment the system is placed on the market.

The risk management documentation expects a continuous process

Article 9 expects the risk management process to be continuous and iterative, with documented updates as new risks are identified through post-market monitoring. Documentation that captures a single point in time fails this requirement. The conformity file must reflect the current state of the risk management process, including changes since the certificate was issued.

Change management requires version control over the policy state

Article 43(4) requires a new conformity assessment when the AI system is substantially modified. The provider must therefore version-control the policy state, the model version, and the data governance configuration. Without policy versioning in the runtime layer, the provider cannot demonstrate which version was in effect on a given date, and the audit file diverges from operational reality.

The notified body queue is the practical constraint

For systems requiring the third-party route, the lead time at notified bodies has become a practical compliance constraint. Providers planning to place systems on the Union market in late 2026 or early 2027 should already be in the queue. Late entries into the queue will not receive certificates before the August 2, 2026 high-risk effective date and cannot rely on grandfathering provisions for systems placed on the market after that date.

Mandate vs Compliance

The text of Article 43 is procedural. The substantive requirements that the conformity assessment must verify operate at the architecture level. The gap between the procedural and the substantive is where most providers are exposed.

Disclosure test

The notified body or the national competent authority asks: produce the audit log for AI request 47832 against your high-risk system, including the identity context, the data classification, the policy version, and the decision outcome. A compliant provider produces the record within minutes. A non-compliant provider produces JSON application logs with missing fields and a workflow of engineers reconstructing the context from production traces. The disclosure failure feeds back into a finding against the conformity file.

Vendor liability

The provider, defined under Article 3, is the entity that develops the system or places it on the market under its own name or trademark. The provider bears the conformity assessment obligation. The deployer, defined separately, bears the Article 26 deployer obligations. Where an enterprise builds an internal AI system, the enterprise is the provider for that system and bears both sets of obligations.

Compliance gap

The compliance gap is architectural. The conformity file describes an architecture. The architecture must actually exist and must continue to produce the records Annex IV describes. Where the architecture is absent or where the record-keeping layer fails the Article 19 test, the conformity assessment is defective even if every page of the file is present.

DeepInspect

This is the architecture the EU AI Act presumes in the record-keeping section of Annex IV. DeepInspect sits at the AI request boundary as an external enforcement layer that operates as a stateless proxy between authenticated users or agents and any LLM endpoint. The proxy evaluates each request against per-route, per-role, identity-bound policies. The per-decision audit record is committed by the proxy, independent of the application, before the model response returns to the calling system.

The record contains a verified identity for the requester, the role and authorization context, the data classification applied to the prompt, the policy version that governed the decision, the decision outcome, and a cryptographic signature that prevents post-hoc modification. The proxy versions the policy state, which gives the change-management section of Annex IV the data it needs. The record is the artifact a notified body or a national competent authority accepts under Article 12 and Article 19.

If you are facing the August deadline, let's talk.

Beyond the EU AI Act

The same architectural pattern satisfies the audit-readiness requirements in adjacent regimes. DORA Article 19 requires log retention and contemporaneous records for digital operational resilience in financial services. Fannie Mae LL-2026-04 requires disclosure on demand for AI and ML decisions in mortgage origination. Texas TRAIGA took effect January 1, 2026 with civil penalties and AG enforcement. Each regime uses different vocabulary for the same infrastructure requirements: an inspection layer on the AI request path that writes a tamper-evident, identity-bound record at decision time.