EU AI Act Deployer Sprint Finale 2026: Complete August Readiness Checklist (50 Items)

Post #5 in the sota.io EU AI Act Deployer Sprint 2026 Series

65 days. That is what separates your SaaS business from the August 2, 2026 deadline when the EU AI Act's full high-risk AI system obligations go live. If your platform deploys high-risk AI — anything touching Annex III categories like HR screening, credit scoring, biometric identification, education assessment, or critical infrastructure — you are already in scope.

Over the past four posts in this sprint series, we worked through each pillar of deployer compliance individually:

• Post #1 (Art.26): The seven core deployer obligations — what you must do, register, monitor, and report
• Post #2 (Art.43): Conformity assessment — self-assessment vs. third-party certification and when you need a notified body
• Post #3 (Art.11): Technical documentation — what you must maintain as a deployer, even when your provider holds the primary documentation burden
• Post #4 (Art.14): Human oversight — designating oversight persons, anti-automation-bias training, and override authority

This finale brings all of it together. The 50-item master checklist below is organized to mirror an actual NCA (National Competent Authority) audit walkthrough. Work through it sequentially, assign owners, and set completion dates. Every item maps to a specific article — no vague compliance theater.

Part A: Deployer Identity and Classification (Items 1–8)

Before you can comply, you need to know what you are deploying and whether it falls in scope.

Item 1 — Confirm high-risk AI classification Review Annex III of Regulation (EU) 2024/1689. If your AI system falls into any of the eight categories (biometric identification, critical infrastructure, education, employment, essential services, law enforcement, migration, administration of justice), it is high-risk. Document this assessment in writing.

Item 2 — Identify all high-risk AI components Catalog every AI feature, module, or third-party API call that could independently qualify as high-risk under Art.6 and Annex III. Many SaaS platforms have embedded high-risk components (a FICO-style credit estimator, an ATS screening module) that the product team did not flag as regulatory.

Item 3 — Map your deployer/provider relationship Under Art.26, your obligations differ based on whether you are (a) a pure deployer using a third-party provider's model, (b) a deployer who has substantially modified the system, or (c) effectively acting as a provider. Document this classification with your legal team.

Item 4 — Register your intended purpose of use Art.26(1) requires deployers to use the AI system only in accordance with the instructions for use from the provider. Document the provider's defined intended purpose and confirm your actual use case is within scope. Any deviation makes you a provider under Art.25.

Item 5 — Identify all affected natural persons Map out which natural persons are subject to decisions made by or with the output of your high-risk AI system. This feeds into your fundamental rights impact assessment (Art.27) and transparency obligations.

Item 6 — Determine your jurisdiction and NCA Under Art.74, enforcement is by the national market surveillance authority of the member state where you are established. Know which NCA has jurisdiction over your operations and whether you need to register with multiple NCAs.

Item 7 — Assess if Art.5 prohibitions apply upstream Even if you are a deployer, using an AI system that itself constitutes a prohibited practice under Art.5 (social scoring, real-time biometric surveillance in public spaces without exception, subliminal manipulation) exposes you to liability. Verify your provider is not supplying a prohibited system.

Item 8 — Document your SME/startup status if applicable Art.62 provides lighter-touch support measures for SMEs and startups. If you qualify (<250 employees, turnover <€50 million, or balance sheet <€43 million), document this to access priority sandbox access, reduced conformity assessment fees, and simplified templates from NCAs.

Part B: Conformity Assessment Documentation (Items 9–18)

Even when your provider bears the primary burden for Art.43 conformity assessment, deployers need to understand and maintain access to the results.

Item 9 — Obtain the conformity assessment outcome from your provider Under Art.13, providers must give deployers instructions for use and sufficient information to comply. This includes the conformity assessment procedure used (internal control under Annex VI, or third-party under Annex VII) and its result. Request this documentation in writing.

Item 10 — Verify the EU declaration of conformity (DoC) Under Art.47, providers must draw up an EU declaration of conformity before placing the system on the market. Obtain a copy. Verify it covers the specific model version and intended purpose you are deploying. A DoC for a prior model version does not cover your use case if the system has been substantially modified.

Item 11 — Check notified body requirement For the Annex III systems listed in Art.43(1) (biometric identification, AI systems used by or on behalf of law enforcement, migration authorities, and the administration of justice), third-party conformity assessment by a notified body is mandatory. If your system falls in this tier, your provider must have a notified body certificate — not just a self-declaration.

Item 12 — Confirm CE marking is present High-risk AI systems that have completed conformity assessment must bear the CE marking under Art.48 before market placement. Verify the CE mark is present on your provider's system documentation. Operating a CE-unmarked high-risk AI system as a deployer exposes you to penalties under Art.99.

Item 13 — Store the conformity documentation Art.12 and Art.26(6) require deployers to keep the conformity assessment documentation for ten years after the AI system is placed on the market or put into service. Build this into your document retention policy now. Cloud-only storage with no offline backup does not meet this standard.

Item 14 — Track provider re-assessments after modifications If your provider updates the model significantly (retraining, new data sources, architectural changes), the conformity assessment may need to be repeated. Include a contractual clause requiring your provider to notify you of any modifications that affect the AI system's conformity or risk profile.

Item 15 — Assess if your customization triggers a new conformity assessment Under Art.25, if you make substantial modifications — retraining with new data, adjusting the system's purpose, or integrating it in a way that changes its intended purpose — you may become a provider and must perform your own conformity assessment. Legal counsel should review your customization scope.

Item 16 — Document your conformity assessment reliance strategy In your compliance register, note which conformity assessment procedure your provider used, what its outcome was, and how you verified it. This paper trail demonstrates due diligence to an NCA auditor.

Item 17 — Establish a provider compliance monitoring SLA Art.26(1)(c) requires deployers to implement effective oversight of the AI system. This includes monitoring your provider's ongoing compliance. Negotiate annual compliance attestations and right-to-audit clauses into provider contracts.

Item 18 — Verify Annex VIII registration if required High-risk AI systems under Art.43 must be registered in the EU AI database (Annex VIII) before deployment. Confirm with your provider that registration has occurred and obtain the registration number. As a deployer, you have registration obligations of your own under Art.26(8) for systems intended for the categories listed in Annex VIII points 1–6.

Part C: Technical Documentation and Record-Keeping (Items 19–30)

Art.11 places the primary documentation burden on providers, but Art.26 requires deployers to maintain their own records and support the full documentation chain.

Item 19 — Obtain the provider's technical documentation summary Under Art.13 and Art.26(1)(b), the provider must give you the instructions for use. Request also the technical documentation summary that describes the system's capabilities, limitations, and performance metrics. You need this for your FRIA (Art.27) and oversight procedures.

Item 20 — Document your specific deployment context Art.26(1) requires deployers to use the system as intended and in accordance with the instructions for use. Create a Deployment Context Document that describes: (a) exact use case, (b) affected population, (c) geographical scope, (d) integration architecture, and (e) any differences from the provider's intended purpose.

Item 21 — Build a deployer-specific technical annex Even though you are not the system's developer, you must maintain records of your deployment under Art.12 requirements. This deployer-specific annex should include: system version in use, deployment date, configuration parameters, integration touchpoints, and human oversight procedures.

Item 22 — Establish automatic log retention Art.12 requires that high-risk AI systems automatically generate logs of their operation. Under Art.26(6), deployers must retain these logs for at least six months (or longer if sector-specific regulation requires). Configure your infrastructure to capture and retain these logs in tamper-evident storage.

Item 23 — Define data governance for AI input/output Art.10 requirements (which apply to providers) indirectly impose obligations on deployers: if you provide training data or substantially modify the system, you must comply with data governance requirements. Document the data flows into and out of the AI system, including any personal data processing under GDPR.

Item 24 — Create an incident log template Art.73 requires deployers to report serious incidents to their market surveillance authority. Define what constitutes a serious incident in your context (death, serious harm, damage to fundamental rights, discriminatory output at scale). Create a template for incident documentation: date, system version, incident description, affected persons, immediate remediation, and reporting timeline.

Item 25 — Establish a model version change management process When your provider releases a new model version, you need a process to: (a) review the release notes for compliance impact, (b) re-validate your oversight procedures against the new version, (c) update your technical documentation, and (d) decide whether deployment can continue or requires a hold period.

Item 26 — Document performance metrics in your deployment context Your provider's technical documentation contains performance metrics for the intended purpose. Document actual performance metrics in your deployment context. Significant divergence between the provider's benchmarks and real-world performance in your context may indicate the system is being used outside its intended purpose.

Item 27 — Maintain a changes register For every configuration change, integration update, or deployment parameter modification: log the date, the change, the rationale, the person who authorized it, and any re-testing performed. This is the audit trail an NCA will request first.

Item 28 — Implement data minimization and retention for AI inputs Under Art.26(1)(e) and applicable GDPR requirements, deployers must not feed more personal data into the AI system than is strictly necessary for the intended purpose. Document your data minimization approach and implement automated deletion of AI-processed personal data after the purpose has been fulfilled.

Item 29 — Create a documentation master index Index all AI-related documentation in one place: provider technical docs, conformity assessment results, DoC, CE marking, deployment context document, log retention configuration, FRIA, oversight procedures, incident log, and the audit trail from your changes register. An NCA audit should be satisfiable from a single documentation package.

Item 30 — Conduct a documentation gap assessment Before August 2, 2026, perform a gap assessment against the documentation requirements. Assign each gap an owner, a remediation action, and a deadline. Track completion in your compliance register.

Part D: Human Oversight and Operational Controls (Items 31–43)

Art.14 is the operational heart of deployer compliance. It requires meaningful human oversight — not checkbox oversight.

Item 31 — Designate your human oversight persons by name Art.14(1) and Art.26(1)(d) require deployers to designate and train natural persons to perform oversight. Name these individuals in your compliance register. "The team" is not sufficient — there must be specific, trained, accountable humans.

Item 32 — Define the oversight duty in job descriptions Human oversight cannot be an informal add-on responsibility. Formal human oversight duties under Art.14 should appear in job descriptions, performance objectives, and accountability frameworks. This demonstrates to an NCA that oversight is structural, not nominal.

Item 33 — Conduct certified AI literacy training Art.14(6) requires deployers to ensure that the natural persons responsible for oversight have sufficient AI literacy. Conduct formal training covering: how the specific AI system works, its known limitations, its error modes, automation bias risk, and the override procedure. Document training completion with dates and trainee names.

Item 34 — Publish and enforce an automation bias policy Automation bias — deferring to the AI output without independent judgment — undermines meaningful oversight. Create a written policy that prohibits rubber-stamping AI outputs. Include specific guidance for your system's domain: if the AI recommends reject for a credit application, the human must apply independent assessment criteria, not simply confirm the AI decision.

Item 35 — Build the ability to interpret outputs Art.14(4) requires that oversight persons can interpret the AI system's output. Ensure your UI provides sufficient explanatory information: confidence scores, contributing factors, comparison to thresholds. Where interpretability is limited, restrict decision authority accordingly — a human who cannot interpret the output cannot provide meaningful oversight.

Item 36 — Implement the override capability Art.14(1) requires the ability to override, disregard, or reverse the AI output. This must be technically implemented, not just policy-stated. Test that: (a) the override button or mechanism exists in your UI, (b) override actions are logged, (c) override is accessible in under 30 seconds in a normal workflow, and (d) override does not require manager approval that would introduce de facto pressure not to exercise it.

Item 37 — Implement the stop/pause mechanism Art.14(5) specifically requires the ability to stop the AI system. For a SaaS deployer, this means: a kill switch that disables the AI system for a specific user, case, or globally; a procedure to fall back to manual processing; and authorization levels for who can trigger a stop. Document and test this quarterly.

Item 38 — Establish monitoring for performance drift Art.26(1)(c) requires deployers to monitor the AI system's operation for compliance with the instructions for use. Set up dashboards that track output distributions, override rates, and anomalous patterns. A sudden spike in adverse decisions against a protected group is a signal requiring immediate investigation.

Item 39 — Create an escalation path Not all oversight persons can resolve all issues. Define an escalation path: oversight person → team lead → compliance officer → external counsel → NCA reporting. Every level should have a defined decision time (e.g., escalation within 2 hours, resolution within 24 hours, NCA reporting within 15 days for serious incidents under Art.73(2)).

Item 40 — Conduct quarterly oversight audits Schedule quarterly internal audits of how human oversight is actually being practiced. Review a sample of cases where the AI made a recommendation and evaluate whether the override rate is plausible, whether documentation of the human decision is adequate, and whether automation bias patterns are visible in the data.

Item 41 — Perform the Fundamental Rights Impact Assessment (FRIA) Art.27 requires deployers of high-risk AI systems to conduct a FRIA before deployment. This is not optional even if your provider has performed their own risk assessment. Your FRIA must cover the specific context of your deployment: affected population demographics, potential discriminatory impact, access to remediation mechanisms, and consultation with civil society or affected groups where feasible.

Item 42 — Establish a user rights and redress mechanism Under Art.26(1)(g) and the broader GDPR framework, individuals subject to AI-assisted decisions have rights including explanation and challenge. Build a mechanism that allows affected persons to request a human review, receive an explanation of the AI's role in the decision, and have their case re-evaluated. Document this mechanism in your privacy policy and terms.

Item 43 — Train front-line staff on the oversight charter Beyond the designated oversight persons, all staff who interact with AI outputs should receive basic AI literacy training covering: what the system does and does not do, what to do when an output seems wrong, and how to escalate. This is a proportionate requirement under Art.14(6) for staff with any touchpoint to the AI system.

Part E: Incident Reporting and Ongoing Monitoring (Items 44–50)

Item 44 — Build the Art.73 reporting workflow Prepare now for serious incident reporting under Art.73. Create a workflow that triggers when a serious incident is suspected: immediate preservation of logs and decision data, notification to the compliance officer, preliminary assessment of severity, and preparation of the NCA notification. Reporting deadlines are: 15 days for all serious incidents (Art.73(2)), 10 days where a death may have occurred (Art.73(4)), 2 days for widespread incidents or critical infrastructure impact (Art.73(3)).

Item 45 — Notify your provider of serious incidents Under Art.26(1)(f), deployers must notify providers when they identify a serious incident or malfunction. Include this as a contractual obligation with defined response SLAs (e.g., provider acknowledges within 4 hours, provides preliminary assessment within 24 hours, delivers remediation plan within 5 days).

Item 46 — Subscribe to provider security and compliance bulletins Your post-market monitoring under Art.26(1)(c) depends partly on information from your provider. Subscribe to their security advisories, compliance updates, and model change notifications. Assign someone to review these and escalate to your compliance officer when they affect your deployed system.

Item 47 — Maintain and exercise a business continuity plan for AI downtime If the AI system becomes unavailable (provider outage, NCA-ordered suspension, serious incident investigation), you need a manual fallback process. Document this process, ensure staff know it exists, and exercise it annually. The fallback process must maintain service continuity without degrading the rights protections that the AI system was required to provide.

Item 48 — Schedule your internal pre-August audit Book a final internal compliance audit for mid-July 2026. This gives you two weeks before August 2 to remediate any remaining gaps. The audit should run through this entire 50-item checklist with evidence review, not just self-attestation.

Item 49 — Prepare your NCA registration if required Art.26(8) requires certain deployers to register in the EU AI database for AI systems intended to be used for the purposes listed in Annex VIII points 1–6 (primarily law enforcement, border management, and administration of justice). Verify whether your system or use case triggers this obligation and complete registration before August 2, 2026.

Item 50 — Conduct a post-August 2 review within 90 days The first weeks of live enforcement will reveal practical ambiguities that no compliance checklist can fully anticipate. Schedule a 90-day post-deadline review: assess how oversight is working in practice, what incidents or near-misses have occurred, what guidance NCAs have published, and what peer companies have done differently. Update your compliance register and procedures accordingly.

Implementation Timeline: 65-Day Sprint

Do not attempt all 50 items simultaneously. The foundation phase creates the ownership structure that makes everything else executable. Start there.

Penalty Exposure

Non-compliant deployers face penalties under Art.99. The structure is:

• Failure to comply with deployer obligations (Art.26): Up to €15,000,000 or 3% of global annual turnover, whichever is higher
• Providing incorrect, incomplete, or misleading information to notified bodies or NCAs: Up to €7,500,000 or 1% of global annual turnover

For a €10 million ARR SaaS company, a 3% penalty is €300,000. For a €100 million ARR company, it is €3 million. The cost of compliance — predominantly process and documentation — is a fraction of that exposure.

The more significant risk for many deployers is reputational. NCAs are expected to publish enforcement decisions. A finding that your HR screening tool deployed a high-risk AI system without proper human oversight is not a regulatory footnote — it is a front-page story for your enterprise prospects.

Series Recap: What We Covered

Deploy on sota.io: Compliance Infrastructure for EU AI Act Deployers

Managing 50 compliance items across multiple AI systems requires infrastructure — audit trails, documentation storage, access controls, and deployment isolation that keeps compliance evidence separate from production workloads.

sota.io provides EU-sovereign cloud infrastructure that helps AI Act deployers maintain the separation of concerns between production AI workloads and compliance records. All data stays in EU jurisdiction, which simplifies Art.26 data governance obligations and supports GDPR compliance across your AI pipeline.

The August 2 deadline is 65 days away. Start with items 1–8 today: classify your system, document the provider relationship, and identify your NCA. Everything else in this checklist follows from that foundation.