How long does it take to get to a passing posture on all 23 items?

The full work runs twenty to thirty weeks for a typical mid-market enterprise with several high-risk deployments. Items 1 to 5 (scope) take four to eight weeks. Items 6 to 11 (documentation) take eight to sixteen weeks. Items 12 to 18 (runtime evidence) take six to twelve weeks if started early. Items 19 to 22 (deployer monitoring) take four to eight weeks once items 12 to 18 are in place. Item 23 (incident reporting) takes two to four weeks once the evidence layer is operational. The work can run in parallel across workstreams, which is how the August 2 deadline is reachable from a Q2 2026 start.

Which items does a regulator typically inspect first?

The inquiry pattern follows items 1, 6, 12, and 19. The AI register tells the regulator what systems are in scope. The technical documentation tells the regulator what the system was designed to do. The Article 12 records tell the regulator what the system actually did. The human oversight assignment tells the regulator who was responsible for catching anomalies. A deployer that can produce all four on demand has the posture that survives the first wave of inquiry.

Can we use the same evidence layer for multiple high-risk systems?

Yes. A single runtime evidence stack can support multiple high-risk deployments across multiple use cases. The records are tagged with the system identifier, the policy version, and the deployment context. The deployer's compliance function queries the same evidence layer regardless of which system the inquiry covers. The architectural consolidation reduces the operational cost compared to per-system evidence stacks.

What if our deployment is global but only some of our customers are in the EU?

The territorial scope under Article 2 covers AI systems whose output is used in the EU. A deployer with global operations and EU customers must run the compliance posture for the EU-customer use cases. The work can be scoped to the EU traffic by partitioning the runtime evidence stack and applying the AI Act controls to that partition specifically. The non-EU traffic remains subject to the deployer's other regulatory obligations but not the AI Act specifically.

How do we handle items 12 to 18 if our AI runs entirely inside a vendor's SaaS tool?

The deployer's Article 12 and Article 19 obligations attach regardless of where the model runs. If the AI runs inside a vendor's SaaS tool, the deployer must require the vendor to produce the records and to make them available on demand. The procurement contract is the operational artifact that secures this. A deployer that cannot enforce vendor-side record production faces the obligations directly with no operational ability to satisfy them.

EU AI Act Compliance Checklist: The 23 Items Your Deployment Must Pass

The EU AI Act high-risk regime takes effect on August 2, 2026. Compliance work is operational. The 23 items below are the substantive checks a deployment must pass to satisfy Articles 8 to 27 of the regulation, with penalty exposure under Article 99 reaching €15 million or 3% of global annual turnover per substantive obligation. Items 1 to 5 cover scope. Items 6 to 11 cover documentation. Items 12 to 18 cover runtime evidence. Items 19 to 22 cover deployer monitoring and oversight. Item 23 covers incident reporting. Most deployments I look at are running items 1 to 11 and missing 12 to 18.

I want to walk through each item with the specific artifact that satisfies it.

Scope checks (items 1 to 5)

These items establish whether the regime applies and which sub-systems carry the obligations.

Item 1: AI register exists and is current

The deployer maintains a written register of every AI system in the environment, including customer-facing features, internal automation, and vendor-embedded AI inside SaaS tools. The register lists the use case, the data flows, the integration boundaries, and the classification. The register is updated at every material change and reviewed at minimum annually.

Item 2: Classification under Article 6 is documented per system

For each system in the register, the deployer has produced a written analysis against Article 6 covering branch one (safety component of regulated products under Annex I), branch two (Annex III categories), and the Article 6(3) carve-out. The analysis is dated and signed by the responsible function.

Item 3: Annex III scope is documented for each high-risk system

For each system classified as high-risk under branch two, the specific Annex III category is identified and the reasoning is documented. Systems falling under multiple categories are documented per category.

Item 4: Article 6(3) carve-out claims are documented

For systems where the carve-out is claimed, the deployer documents the specific carve-out provision (narrow procedural task, improvement of previously completed human activity, detection of decision-making patterns, or preparatory task), the reasoning, and the evidence supporting the claim. The carve-out cannot apply if the system profiles natural persons.

Item 5: General-purpose AI model usage is registered

For each general-purpose AI model used by a high-risk system, the model is identified, the provider is named, and the dependencies are documented. The provider's transparency obligations under Article 53 are tracked.

Documentation checks (items 6 to 11)

These items establish the design-time evidence the regulation requires.

Item 6: Technical documentation under Article 11 exists per high-risk system

For each high-risk system, the technical documentation covers the intended purpose, the design specifications, the training and validation data, the accuracy metrics, the foreseeable misuse, the cybersecurity controls, the human oversight expectations, and the post-market monitoring plan. The documentation is maintained over the system's lifetime.

Item 7: Instructions for use under Article 13 are produced per high-risk system

The provider produces instructions for use that include identity and contact details, system characteristics, expected accuracy, resilience properties, cybersecurity profile, foreseeable misuse, intended purpose, and human oversight measures expected of the deployer.

Item 8: Data governance under Article 10 is documented

For each high-risk system, the deployer documents the training, validation, and test data sets, the data quality criteria, the bias detection and mitigation measures, and the data minimization decisions.

Item 9: Conformity assessment under Article 43 is completed

For each high-risk system, the conformity assessment is completed under the procedure that applies (internal assessment under Annex VI for most Annex III systems, notified body involvement for biometrics under Annex III Category 1 and safety components of products requiring third-party assessment under Annex I).

Item 10: EU declaration of conformity is signed

The provider signs the EU declaration of conformity for each high-risk system. The document is dated, identifies the system and the provider, and references the conformity assessment procedure used.

Item 11: CE marking is affixed and the system is registered

The provider affixes the CE marking to the system documentation and registers the system in the EU database through the AI Office portal.

Runtime evidence checks (items 12 to 18)

These items establish the per-decision evidence the regulation requires. Most deployments fail here.

Item 12: Article 12 automatic recording is in place

For each high-risk system, automatic recording of events over the system's lifetime is implemented. The recording is structural to the system's operation and cannot be disabled by an operator.

Item 13: Article 19 retention floor is met

Automatically generated logs are retained for at least six months. Where sector-specific retention applies (financial services, healthcare, government), the longer retention period governs.

Item 14: Identity of natural persons is recorded per output

For each output of the high-risk system, the audit record identifies the natural person involved in any human verification. Systems running on shared service credentials produce identity records that resolve to the credential, not the human, and fail this item.

Item 15: Input data and reference databases are recorded

For each output, the input data leading to the output and the reference databases against which the input was checked are recorded.

Item 16: Policy version at the moment of decision is recorded

The audit record includes the version of the policy that governed the decision at the moment of decision. This item is the one most application-level logging stacks omit.

Item 17: Records are tamper-evident

Records are signed, hashed, or otherwise integrity-protected so post-hoc modification is detectable. The application that produced the output cannot modify the record after the fact.

Item 18: Records are searchable by user, by request, and by time range

The deployer's compliance function can produce, on demand, the complete record set for any specific request, any specific user, any specific time range, or any specific policy version. The search interface is operational, not theoretical.

Deployer monitoring checks (items 19 to 22)

These items establish the runtime deployer obligations under Article 26.

Item 19: Human oversight is assigned with competence, training, and authority

For each high-risk system, the deployer has assigned human oversight to natural persons with the competence, training, and authority to intervene under defined risk conditions. The assignment is documented and the assignees have received training.

Item 20: Monitoring of operation against intended purpose is in place

The deployer monitors the operation of the system against the intended purpose, the accuracy figures published in the technical documentation, and the foreseeable misuse cases identified during the conformity assessment. The monitoring is purpose-specific and distinct from application observability.

Item 21: Worker notification under Article 26(7) is completed where applicable

For deployers that are employers using high-risk AI systems in the workplace, affected workers and worker representatives have been informed before the system was put into service.

Item 22: Fundamental rights impact assessment under Article 27 is completed for public-sector deployments

Public-sector deployers have completed the fundamental rights impact assessment before deploying high-risk systems, covering the categories of natural persons affected, the foreseeable risks of harm, and the safeguards in place.

Incident reporting check (item 23)

Item 23: Serious incident reporting process under Article 73 is operational

The deployer has an established process for reporting serious incidents to the national competent authority and to the provider, with the reporting timelines (forty-eight hours for incidents involving widespread infringement or critical infrastructure, two days for incidents involving death, fifteen days for other reportable incidents). The process draws on the runtime evidence to produce the report.

DeepInspect

This is the infrastructure that satisfies items 12 to 18 and supplies items 19, 20, and 23. DeepInspect sits as a stateless proxy between authenticated users or agents and the LLM. Every request produces a signed per-decision record with identity, role, policy version, data classification, outcome, and timestamp. The records satisfy items 12, 13, 14, 15, 16, 17, and 18 as a single architectural primitive.

For items 19 and 20, the same record set feeds the deployer's human oversight function with the runtime signal it needs to intervene under defined risk conditions. For item 23, the records are the source data the incident report draws on. The deployer's compliance function moves from inquiry to response without manual reconstruction.

If you are running through this checklist and items 12 to 18 are open, your readiness gap is at the runtime evidence layer.

Book a demo today.