Where do we start if we have no existing AI register?

Start with workstream 1. Convene a working group across product, engineering, legal, and compliance. Inventory every AI system in the environment: customer-facing features, internal automation, vendor-embedded AI inside SaaS tools, and any general-purpose AI model usage. For each, document the use case, the data flows, the integration boundaries, and a preliminary classification against Article 6. The first pass takes four to eight weeks for a typical mid-market enterprise. The register becomes the operational backbone of the compliance program.

Can we outsource the conformity assessment?

For most Annex III systems, the conformity assessment is conducted internally under Annex VI. External consultants can support the process, but the legal responsibility sits with the provider. For systems that require notified body involvement (biometrics under Annex III Category 1 and safety components of regulated products under Annex I that require third-party assessment), a notified body is mandatory. The notified body list is maintained by the European Commission and varies by Member State.

What documentation do we need to hand to a regulator on day one?

The regulator's first inquiry typically asks for the AI register, the technical documentation for the specific system under inquiry, the conformity assessment record and EU declaration of conformity, the most recent post-market monitoring report, and a sample of Article 12 records covering the specific request or time period under inquiry. The deployer-side documentation includes the Article 26 monitoring records and any Article 27 fundamental rights impact assessments for public-sector deployments. The sample of records is the artifact most organizations cannot produce on demand.

How do we satisfy the human oversight requirement if we have hundreds of decisions per minute?

Article 14 human oversight does not require a human in the loop for every decision. It requires the deployer to assign oversight to people with the competence, training, and authority to intervene under defined risk conditions. The architectural pattern is to define the risk conditions (high data classification, low model confidence, output triggering a policy threshold) and to route those specific decisions to the oversight function while permitting the rest of the traffic to proceed. The runtime evidence stack produces the signal that determines which decisions are escalated.

What is the relationship between AI Act compliance and existing ISO 42001 work?

ISO 42001 is the international standard for AI management systems. The standard covers the management practices that support responsible AI development and use. AI Act compliance and ISO 42001 align in many places: governance structure, risk management, transparency, and post-market monitoring. ISO 42001 certification provides a reasonable governance foundation, though the AI Act obligations sit separately and must be addressed on their own substantive basis. Organizations pursuing both can sequence the work so the ISO 42001 management syst

How to Comply with the EU AI Act: The Six-Workstream Operating Plan

The EU AI Act high-risk regime takes effect on August 2, 2026. Compliance work breaks into six operational workstreams: scope classification under Article 6, technical documentation under Article 11, conformity assessment under Article 43, runtime evidence under Article 12 and Article 19, deployer monitoring under Article 26, and serious incident reporting under Article 73. The penalty exposure under Article 99 reaches €15 million or 3% of global annual turnover per substantive obligation. I see most organizations running three of the six workstreams and missing the runtime evidence work entirely.

I want to walk through each of the six workstreams, what evidence each produces, and the sequencing that gets a deployment audit-survivable before August.

Mandate

Compliance under the AI Act is operational, not theoretical. Every high-risk system must produce evidence at six distinct points. The regulator inspects evidence on demand. The penalty exposure attaches per substantive obligation failure, not per organization.

Workstream 1: scope classification

Identify every AI system in the environment and classify each one against Article 6. The output is a written analysis covering branch one (safety components of regulated products), branch two (Annex III categories), and the Article 6(3) carve-out. Each system gets a classification decision, a reasoning artifact, and a date of analysis. The AI register is the operational artifact that aggregates the classifications and is the first document a regulator inspects.

Workstream 2: technical documentation

For every system classified as high-risk, produce the Article 11 technical documentation. The 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 and updated when material changes occur.

Workstream 3: conformity assessment

Conduct the Article 43 conformity assessment for every high-risk system. Most Annex III systems use the internal conformity assessment procedure under Annex VI. Systems in biometrics under Annex III Category 1 and systems that are safety components of products under Annex I that require third-party assessment must involve a notified body. The conformity assessment produces the EU declaration of conformity and the CE marking.

Workstream 4: runtime evidence

Build the infrastructure that produces Article 12 records automatically and Article 19 retention. The runtime evidence is the per-decision audit record: identity of the natural person involved, input data, output, policy version in effect, data classification, and timestamp. The records are signed, retained for at least six months, and searchable across deployments. This workstream is the one most organizations have not started.

Workstream 5: deployer monitoring

Implement the Article 26 deployer obligations: human oversight assignment with the competence and authority requirements, monitoring of operation against the intended purpose, log retention, and worker notification where applicable. The monitoring infrastructure produces evidence that the oversight is functioning at runtime and that the system is operating inside the documented bounds.

Workstream 6: serious incident reporting

Establish the Article 73 process for reporting serious incidents to the national competent authority and to the provider. Reporting timelines vary by incident severity: forty-eight hours for incidents involving widespread infringement or critical infrastructure, two days for incidents involving death, and fifteen days for other reportable incidents. The reporting process draws on the runtime evidence to produce the report.

Compliance gap

Most organizations I look at have built workstreams 1, 2, and 3. They are missing workstreams 4, 5, and 6. The gap pattern is consistent.

Documentation without evidence

Workstreams 1 to 3 produce documentation. The documentation describes how the system should operate. The documentation does not prove the system operated that way. The Article 12 obligation is to record what actually happened, per request. A team that has produced a beautiful technical documentation package and has no runtime evidence stack fails the substantive obligation regardless of the documentation quality.

Monitoring as application observability

Workstream 5 monitoring is purpose-specific to the high-risk regime. It is not application uptime, throughput, or error rate. It is monitoring against the intended purpose, the accuracy figures published in the technical documentation, and the foreseeable misuse cases identified during the conformity assessment. Most teams that say "we monitor the system" are running application observability. The Article 26 monitoring stack is different infrastructure.

Incident reporting without source evidence

Workstream 6 incident reporting requires source evidence: which request produced the incident, which policy was in effect, which natural person was involved, what classification applied. Without the runtime evidence from workstream 4, the incident report is reconstructed from logs that were not designed to support the reporting. The forty-eight-hour and two-day reporting windows do not accommodate manual reconstruction.

The sequencing question

The workstreams are not independent. Workstream 4 produces evidence that workstreams 5 and 6 consume. Workstream 1 identifies the systems that workstreams 2, 3, 4, 5, and 6 apply to. The sequencing that gets a deployment to August 2 looks like this:

Weeks 1 to 4: complete workstream 1 (scope classification and AI register). Weeks 4 to 12: complete workstream 2 (technical documentation) and workstream 4 (runtime evidence infrastructure) in parallel. Workstream 4 produces evidence that goes into the workstream 2 accuracy section. Weeks 8 to 16: complete workstream 3 (conformity assessment), which depends on the workstream 2 outputs. Weeks 12 to 20: implement workstream 5 (deployer monitoring) and workstream 6 (incident reporting), both of which depend on workstream 4. Weeks 20 to 24: dry-run a regulator inquiry, identify the gaps, and remediate.

The runtime evidence work has to start early. Building it after the documentation is done leaves the documentation referencing infrastructure that does not exist.

What good compliance looks like at August 2

A deployer that has run the six workstreams to completion has a current AI register, technical documentation per high-risk system, completed conformity assessments with signed EU declarations of conformity, a runtime evidence stack producing per-decision audit records, an assigned human oversight function with the runtime signal it needs, and an incident reporting process that can produce a complete report inside the regulator's timelines.

The evidence is searchable and exportable. The deployer 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 regulator's inquiry runs against a known evidence layer, not against reconstructed application logs.

DeepInspect

This is the runtime infrastructure that satisfies workstream 4 and supplies workstreams 5 and 6. DeepInspect sits as a stateless proxy between authenticated users or agents and the LLM. Every request produces a signed per-decision record containing identity, role, policy version, data classification, outcome, and timestamp. The records are retained for the deployer's specified period, searchable across the full deployment, and exportable to the deployer's compliance function.

For the AI Act, the operational consequence is that workstreams 4, 5, and 6 are built on a single evidence layer. The deployer monitoring stack reads from the per-decision records. The incident reports are generated from the same records. The documentation in workstream 2 cites the evidence layer as the audit infrastructure the regulation requires.

If you have AI deployments inside the high-risk regime and your August 2 readiness is documentation without runtime evidence, that readiness is incomplete.

Book a demo today.