EU AI Act Deployer Checklist: 22 Items Every Enterprise Deployer Needs Before August 2, 2026
August 2, 2026 is the enforcement date for the high-risk system obligations under Chapter III, Section 2 of the EU AI Act. Most enterprise compliance teams have a checklist for the provider-side obligations. Fewer have a structured checklist for the deployer side, where the runtime-evidence obligation lands. This article walks through 22 specific items a deployer of a high-risk AI system needs to have in place before August 2, organized into pre-deployment artifacts, runtime-evidence infrastructure, human oversight workflow, notification mechanisms, and ongoing operational requirements. Each item references the specific article of the act it satisfies.
August 2, 2026 is 47 days away as of this writing. The Chapter III, Section 2 obligations of the EU AI Act enter enforcement that day for high-risk AI systems under Annex III. Most enterprise compliance teams have a provider-side checklist covering the technical documentation, the conformity assessment, the CE marking, and the EU database registration. Fewer have a structured deployer-side checklist for the obligations under Article 26, where the runtime-evidence burden lands.
The deployer's evidence describes the use of the AI system within the deployer's environment. The provider's documentation describes the system. Both have to exist. Documentation alone fails the deployer's side of the obligation set.
I want to walk through 22 specific items a deployer needs in place before August 2, organized into five categories: pre-deployment artifacts, runtime-evidence infrastructure, human oversight workflow, notification mechanisms, and ongoing operational requirements. Each item references the specific article of the act it satisfies.
Category 1: Pre-deployment artifacts (Items 1-5)
These items have to be in place before the system is put into use.
1. Classification analysis under Annex III and the May 2026 guidelines
The deployer runs the classification analysis against Annex III with the May 19, 2026 Commission guidelines applied. The analysis confirms whether the system is high-risk and which Annex III point applies. The May 2026 guidelines tightened the criteria for HR screening, clinical decision support, and fraud detection systems. The analysis is documented and signed by the compliance owner.
2. Receipt and review of the provider's instructions for use
The deployer receives the provider's instructions for use under Article 13, reviews the instructions against the planned use case, and identifies any deviation that would constitute an out-of-scope use. Out-of-scope deployments require either renegotiation with the provider or selection of a different system.
3. Confirmation of the provider's CE marking and EU database entry
The deployer confirms the provider has applied the CE marking and registered the system in the EU database under Article 49. The confirmation is recorded in the deployer's vendor management file. A system without the CE marking or the EU database entry cannot be put into use as a high-risk system.
4. Fundamental rights impact assessment under Article 27
For public bodies and for private-sector deployers in the categories Article 27 enumerates, the FRIA is completed before deployment. The assessment describes the intended purpose, the categories of natural persons likely to be affected, the specific risks, the human oversight measures, and the measures the deployer takes when risks materialize.
5. Allocation of human oversight under Article 14
The deployer identifies the natural persons who will perform the human oversight under Article 14, confirms their competence, and documents the oversight assignment in the personnel file. The persons need the authority to override or suspend the AI system's decisions and the training to exercise that authority.
Category 2: Runtime-evidence infrastructure (Items 6-11)
These items support the Article 12 traceability obligation and the related evidence requirements.
6. Per-decision audit pipeline that records identity, policy, classification, and outcome
The deployer operates an audit pipeline that records, for each AI request: the identity of the requesting user, the policy version in force, the data classification of the prompt, the decision outcome, and a timestamp. The records have to be retained for at least six months under Article 26(7), longer if Union or national law requires.
7. Tamper-evident audit records
The audit records carry a cryptographic signature or a hash chain that demonstrates the records have not been modified after creation. Append-only storage is a weak proxy; the records should be signed at write time and verifiable on read.
8. Audit record export capability
The deployer can export the audit records in a structured format on demand. Export is required for market surveillance inspections, internal audit, regulatory cooperation, and data subject rights requests where applicable. A pipeline that does not support export creates a single point of failure for compliance evidence.
9. Policy-state history
The audit pipeline retains the policy state at the moment of each decision, not just the current policy state. A policy that was changed during a covered period produces different decisions before and after the change. The pipeline has to reconstruct the policy timeline against any decision under inspection.
10. Data classification at the prompt layer
The deployer operates a data classification step that runs on prompt content before the model call. The classifier surfaces PII, PHI, payment card data, intellectual property, source code, and customer-defined categories. The classifier output feeds the policy decision and is recorded in the audit record.
11. Identity context at the request layer
The deployer's authentication system passes identity context (user, role, department, authentication strength) to the request layer. The identity context is the anchor for the policy decision and the audit record. A system that operates on a tenant ID only cannot support the granular evidence Article 12 expects.
Category 3: Human oversight workflow (Items 12-15)
These items support the Article 14 human oversight obligation.
12. Documented oversight procedures for each Annex III use case
The deployer documents the oversight procedure for each Annex III use case the system supports: who reviews which decisions, on what timeline, with what authority to override. The procedures are version-controlled and re-reviewed when the system or the use case changes.
13. Oversight evidence capture per decision
The audit pipeline captures, for each decision that received human oversight: which natural person reviewed the decision, when, with what outcome (accepted, modified, overridden), and on the basis of what information. The oversight evidence is the link between Article 12 traceability and Article 14 oversight.
14. Override authority documentation
The deployer documents which natural persons have the authority to override the AI system's decisions, the conditions under which the authority applies, and the audit trail the override produces. Override evidence is part of the Article 14 compliance package.
15. Training and competence records for oversight personnel
The deployer maintains training records for the natural persons assigned to oversight, including the AI literacy training under Article 4 and the use-case-specific training the oversight role requires. Training records support both Article 4 and Article 14 in inspections.
Category 4: Notification mechanisms (Items 16-18)
These items support the Article 26(11) notification obligation.
16. Identification of decisions requiring affected-person notification
The deployer can identify, automatically or near-automatically, the decisions that require notification to the affected person under Article 26(11). The identification depends on the per-decision audit records and the use-case categorization. A pipeline that requires manual identification of each notifiable decision cannot operate at production volume.
17. Notification content and delivery mechanism
The deployer has a notification mechanism that delivers the required information to the affected person: that the decision was made or supported by an AI system, the categories of personal data involved, and the rights the person has under the act and under adjacent regimes (data subject rights under GDPR, the explanation right under Article 22 GDPR where applicable).
18. Affected-person rights workflow
The deployer has a workflow for handling affected-person inquiries: the access right to the deployer's records of decisions affecting the person, the right to request correction of any incorrect personal data the AI relied on, and the cross-reference to GDPR rights where applicable.
Category 5: Ongoing operational requirements (Items 19-22)
These items support the operational obligations that run continuously after the system is put into use.
19. Post-market data return to the provider under Article 72
The deployer returns the post-market data the provider's instructions for use specify. The return cadence and the data scope come from the provider; the deployer's responsibility is to maintain the return as a live data pipeline rather than a periodic manual export.
20. Incident reporting under Article 73
The deployer reports serious incidents to the market surveillance authority and to the provider under Article 73 within the timeframes the article specifies. A serious incident is a malfunction that causes or could cause significant harm. The deployer's incident-response workflow has to include the regulatory reporting path.
21. Conformity monitoring against the provider's documentation
The deployer monitors the system's behavior against the conformity profile the provider documented. Deviation between the documented behavior and the runtime behavior is a signal: either the system is drifting (which triggers the provider's Article 72 obligations) or the use case has shifted (which triggers the deployer's classification analysis).
22. Annual deployer-side compliance review
The deployer runs an annual compliance review against the checklist above, with the review documented and signed by the compliance owner. The review confirms each item is current, identifies any gap, and routes remediation to the appropriate owner. The annual cadence aligns with the typical enterprise compliance program rhythm.
DeepInspect
This is the runtime-evidence infrastructure DeepInspect provides for the deployer side of the obligation set. DeepInspect sits at the AI request boundary inside the deployer's environment as a stateless proxy between authenticated users or agents and the LLM endpoints, enforces identity-bound policy on every request, and writes per-decision audit records with policy version, identity context, data classification, and decision outcome.
For Items 6 through 11, the DeepInspect deployment is the per-decision audit pipeline. For Items 12 and 13, the oversight evidence integrates with the per-decision records. For Item 16, the audit records support the automatic identification of notifiable decisions. For Item 19, the records support the post-market data return to the provider. For Item 21, the records support conformity monitoring.
If you are deploying a high-risk AI system in the EU and the deployer-side runtime-evidence infrastructure is not in place by August 2, the enforcement date will surface the gap. Book a demo today.
Beyond the checklist
The 22 items are the deployer-side floor. A defensible deployer program adds: cross-mapping to NIST AI RMF for organizations that operate in both EU and US markets, cross-mapping to ISO/IEC 42001 for organizations pursuing AIMS certification, cross-mapping to the Fannie Mae LL-2026-04 framework for lenders, and cross-mapping to sector-specific regimes for healthcare, finance, employment, and education.
The shared infrastructure - the per-decision audit pipeline, the identity context at the request layer, the policy enforcement at the gateway, the oversight evidence capture - supports each of these adjacent regimes from the same source data.
Frequently asked questions
- Does the checklist apply to AI systems already in production before August 2, 2026?
High-risk AI systems placed on the market before August 2, 2026 enter scope on August 2, 2027 under the legacy provision in Article 111, unless they undergo substantial modification under Article 43(4), which triggers immediate scope. Deployers should run the substantial-modification analysis on every covered system rather than assume the legacy provision applies. The May 2026 Commission guidelines tightened the substantial-modification test.
- What if the deployer cannot identify the provider?
A high-risk system without an identifiable provider that has applied the CE marking and registered in the EU database cannot be put into use as a high-risk system. The deployer either selects a different system, becomes the provider for the system (with the provider-side obligations attached), or removes the system from the deployment.
- How does the deployer satisfy Article 12 when the provider's system has its own audit logging?
The provider's logs describe the system from the provider's perspective. The deployer's logs describe the use from the deployer's environment. Both are required. The deployer cannot rely on the provider's logs alone because the deployer does not control the provider's retention, access controls, or legal basis for the records. The deployer's audit pipeline runs in the deployer's environment.
- What is the penalty exposure for a deployer non-compliance?
Article 99 sets the penalty caps. Non-compliance with the deployer obligations under Article 26 carries the tier 2 cap of €15 million or 3% of global annual turnover, whichever is higher. National implementing legislation may set additional procedural penalties.
- How does this checklist interact with the FRIA under Article 27?
The FRIA is Item 4 on the checklist for the deployers that have to complete it. The other items support the runtime evidence the FRIA assumes will exist. A FRIA that describes the human oversight measures without the audit pipeline to confirm the measures are exercised is incomplete.
- What is the role of the compliance team versus the engineering team?
The classification analysis (Item 1) and the FRIA (Item 4) sit with the compliance team. The audit pipeline (Items 6-11) and the data classification (Item 10) sit with the engineering team. The oversight procedures (Items 12-15) sit with the operations team. The notification mechanisms (Items 16-18) sit with the customer-facing or HR-facing teams depending on the use case. The annual review (Item 22) sits with the compliance team and routes to each owner.