EU AI Act NCA Inspection Readiness: 60-Day Action Plan for High-Risk AI Providers (August 2026)

Post #1481 in the sota.io EU AI Act Compliance Series — AUDIT-READINESS-SPRINT #5/5 FINALE

August 2, 2026 is approximately 60 days away. For high-risk AI providers, this marks the date when EU AI Act obligations become fully enforceable and National Competent Authorities (NCAs) can conduct market surveillance inspections under Article 74. If your organisation has not yet structured its compliance work into a concrete sprint, this guide gives you a week-by-week action plan to reach inspection readiness before the deadline.

This is the fifth and final post in the AUDIT-READINESS-SPRINT-2026 series. The previous posts covered NCA inspection triggers and Art.74 market surveillance mechanics, the step-by-step inspection response playbook, the seven Art.11 documentation gaps NCAs find most often, and the Art.15 testing evidence categories inspectors examine. This finale synthesises all of those findings into one actionable 60-day plan.

Why 60 Days Is Enough — If You Start Now

Most high-risk AI providers who have been building under the EU AI Act since 2024 already have components in place: some form of risk assessment, training data records, and testing artifacts. The problem is that these are rarely in the format, structure, or completeness level that an NCA inspection requires.

NCA inspections under Article 74 are not pass/fail audits of whether a product works. They are document-completeness reviews combined with technical interrogation. The inspector arrives with a checklist derived from Annex IV, asks for each item in sequence, and rates completeness. Gaps that would be minor in an internal review become formal findings that extend the inspection timeline or trigger corrective action orders.

Sixty days is sufficient to close those gaps — provided you work in phases and do not attempt everything simultaneously.

The 60-Day Sprint Structure

The plan is divided into eight two-week phases. Each phase has a primary owner (technical team, legal/compliance, or engineering leadership), a primary Article reference, and a concrete output. Phases can overlap where teams are large enough to work in parallel.

Phase 1 (Weeks 1–2): Art.11 Technical Documentation Audit

Primary owner: Technical lead + documentation owner
Primary Article: Art.11 + Annex IV
Output: Gap list with assigned owners and resolution deadlines

Start here because Art.11 Annex IV technical documentation is the first thing an NCA inspector requests. Without a complete Annex IV package, the inspection stalls on day one.

Annex IV requires seven sections. The most commonly incomplete sections are:

Section 2 — Design specifications and development process
Check that you have documented the intended purpose with specificity: which use case, which deployment context, which user population. Vague purpose statements ("general decision support") do not satisfy Annex IV. The purpose must be narrow enough that you can demonstrate your testing was targeted at actual failure modes.

Section 2(d) — Training data specification
This covers data sources, preprocessing steps, and representativeness analysis. If this section links to a data sheet or separate document rather than containing the substance directly, ensure that document is explicitly cross-referenced and accessible in your evidence package. Article 10 obligations on data governance feed directly into this section.

Section 2(f) — Metrics used for accuracy and robustness
The metrics must be stated with numerical values. "We used standard precision/recall" is insufficient. Inspectors look for the specific thresholds you set, the rationale for choosing those thresholds, and evidence that the system met or exceeded them pre-deployment.

Section 4 — Post-market monitoring plan
Many providers have a plan in draft but have not formalised it as a versioned, dated document with named responsible parties. The plan must exist as a formal artifact, not as a standing intention.

Complete a line-by-line Annex IV gap analysis during this phase. Assign a responsible person to each gap and set a resolution date within the sprint.

Phase 2 (Weeks 2–3): Art.9 Risk Management System Review

Primary owner: Risk owner / AI governance lead
Primary Article: Art.9
Output: Updated RMS documentation with closed gaps flagged

Article 9 requires a continuous risk management system, not a one-time risk assessment document. The distinction matters to NCAs because Article 9 explicitly requires review and update whenever circumstances change — model updates, new deployment contexts, significant incidents. An RMS document dated from initial development but never updated since suggests the obligation is being treated as a checkbox rather than an ongoing process.

The four Art.9 components inspectors verify:

1. Risk identification
Does your documentation identify foreseeable misuse scenarios, not just intended use? Article 9 paragraph 2 specifically requires misuse scenarios. If your risk log only covers operational failures and not deliberate or inadvertent misuse by end users, this is a gap.

2. Risk estimation and evaluation
Are risks ranked with a combination of severity and likelihood? Unranked risk lists do not satisfy Art.9. You need a methodology that produces an ordering, even if the methodology is simple.

3. Risk control measures
For each identified risk, a corresponding control measure must exist. If controls are stated at the design level (e.g., "output filtered by human reviewer") but the operational implementation of that control is not documented, inspectors will flag the gap.

4. Residual risk assessment
Art.9 paragraph 9 requires that residual risks — those remaining after controls — are communicated to deployers. Check that your Art.13 technical instructions to deployers include a residual risk section. This is a frequent gap where the RMS documentation is complete but the downstream communication to deployers is missing.

Phase 3 (Weeks 3–4): Art.15 Testing Evidence Assembly

Primary owner: QA lead / testing team
Primary Article: Art.15
Output: Assembled testing evidence package with index document

Article 15 requires that high-risk AI systems achieve appropriate levels of accuracy, robustness, and cybersecurity. NCAs translate this into a documentation request for your pre-deployment validation package.

The testing evidence package should be assembled as a standalone artifact, not reconstructed from CI/CD logs at inspection time. Inspectors do not have time to navigate build systems. The package must contain:

Accuracy and performance validation records
These are your pre-deployment test suite results against the hold-out evaluation dataset. Include the dataset description (size, composition, collection period), the metric results with version numbers, and the sign-off that approved deployment.

Robustness and edge case testing records
Document that you tested boundary inputs, adversarial inputs, and operational scenarios outside the nominal distribution. Records should include the number of edge case scenarios tested, the failure rate observed, and the decision on acceptability.

Bias and fairness audit records
For systems that produce outputs affecting individuals, Article 15 in combination with Article 10 requires that you have assessed differential performance across protected characteristic groups. The audit record must state the characteristics assessed, the metric, the observed differential, and the acceptability judgment.

Post-deployment accuracy monitoring logs
Article 15 obligations extend to post-deployment. Your monitoring logs from production must be included in the evidence package to demonstrate that accuracy has remained within the pre-deployment validated range. Three to six months of monitoring data is typically sufficient for initial inspections.

Phase 4 (Weeks 4–5): Art.14 Human Oversight Implementation Verification

Primary owner: Product owner + deployment team
Primary Article: Art.14
Output: Human oversight verification report

Article 14 requires that high-risk AI systems allow natural persons to effectively oversee their operation. This is not merely a UI requirement — it is an operational and documentation requirement. NCAs check three things:

Mechanism documentation
Does your technical documentation describe the specific human oversight mechanisms implemented? The description must be concrete: which outputs require human review, what the review interface provides, what authority the reviewer has to override the system.

Capability evidence
Can you demonstrate that the oversight roles are staffed and trained? NCAs may ask for training records, organisational charts showing oversight responsibilities, or audit logs showing oversight actions taken in production.

Override capability
Art.14 paragraph 4 requires that the system can be interrupted or stopped by the human overseer. Document the interrupt mechanism and test evidence that it functions as intended.

Phase 5 (Weeks 5–6): Art.13 Transparency and Deployer Instructions

Primary owner: Legal / product documentation team
Primary Article: Art.13
Output: Finalised deployer instructions package and user-facing transparency notices

Article 13 requires that high-risk AI systems are sufficiently transparent that deployers can interpret their output and users can understand the nature of the AI interaction. NCAs inspect two artifacts:

Instructions for use (deployers)
These must be in a language accessible to the deployer jurisdiction, must describe the characteristics, capabilities and limitations of the system, and must include the residual risk section referenced in Phase 2. Version the instructions document and ensure it corresponds to the current system version.

User transparency notices
Where end users interact directly with the system, they must be informed they are interacting with AI unless this is obvious from context. Check that your user interface or terms of service contains this disclosure and that the disclosure language is specific to the AI component, not a generic data processing notice.

Phase 6 (Weeks 6–7): Art.74 Inspection Protocol Preparation

Primary owner: Compliance lead / legal
Primary Article: Art.74
Output: Inspection response protocol document and evidence package index

With documentation substantially assembled from Phases 1 through 5, Phase 6 prepares the procedural layer: how your organisation will respond when an NCA inspection is triggered.

Inspection response team
Designate in writing: the primary point of contact for NCA communications, the technical lead who will respond to documentation requests, legal counsel who will review NCA correspondence before it is sent. This team designation should be documented and kept current.

Evidence package index
Create a master index document that maps each Annex IV section to the specific document that satisfies it, including document name, version, date, and location. When an inspector asks for Section 2(f) accuracy metrics, you hand over the index entry, then retrieve the document. This reduces inspection delays and demonstrates organisational readiness.

Response timeline planning
Under Article 74, NCAs typically give providers 15–30 business days to respond to documentation requests following an inspection notice. Identify in advance which gaps in your package would require more than five business days to close if an inspection arrived today, and prioritise closing those gaps in the final weeks of the sprint.

Phase 7 (Week 7): Mock Inspection

Primary owner: Compliance lead
Output: Mock inspection report with open items list

Run an internal mock inspection using your assembled documentation package. Have a team member who was not involved in assembling the package act as the inspector and work through each Annex IV section requesting the relevant document. Record:

• Items where the document was immediately available: ready
• Items where the document required searching or reconstruction: at risk
• Items where the document was absent or incomplete: gap

All items rated at risk or gap become the Week 8 priority list.

Phase 8 (Week 8): Close Remaining Gaps and Freeze Documentation

Primary owner: All
Output: Inspection-ready documentation package, version locked

Address all items rated at risk or gap from the mock inspection. Prioritise by inspection consequence severity:

1. Missing Annex IV sections (immediate NCA finding, inspection suspended)
2. Undated or unsigned documents (document integrity finding)
3. Missing residual risk section in deployer instructions (Art.9 + Art.13 gap)
4. Monitoring log gaps (Art.15 post-deployment finding)

After closure, version-lock the package. The locked package becomes your inspection-ready artifact. Any changes to the system after the lock date trigger an update obligation to the package — document the update process so you can demonstrate version control to an inspector.

Pre-Inspection Readiness Checklist

Use this checklist in the final week to verify readiness:

Art.11 Annex IV

• All seven Annex IV sections populated with substance (not placeholders)
• Section 2 includes specific intended purpose statement
• Section 2(d) data specification present and cross-referenced
• Section 2(f) accuracy metrics with numerical thresholds stated
• Section 4 post-market monitoring plan formalised and dated

Art.9 Risk Management System

• RMS documentation last reviewed within 90 days (or after most recent system change)
• Foreseeable misuse scenarios documented
• Risk controls mapped to identified risks
• Residual risk communicated in deployer instructions

Art.15 Testing Evidence

• Pre-deployment validation records assembled as standalone package
• Bias and fairness audit records present
• Post-deployment monitoring logs available for prior 3–6 months
• Version correspondence between testing records and current system version

Art.14 Human Oversight

• Oversight mechanism documented in technical documentation
• Interrupt/stop capability tested and evidenced
• Oversight roles documented (if applicable)

Art.13 Transparency

• Deployer instructions finalised, versioned, language-accessible
• Residual risk section present in deployer instructions
• User transparency notice in place (where applicable)

Procedural

• Inspection response team designated in writing
• Evidence package master index created
• Mock inspection completed and gaps closed

The AUDIT-READINESS-SPRINT Series: Complete

This post concludes the five-part AUDIT-READINESS-SPRINT-2026 series. The series has covered:

1. Post #1477 — What EU AI Act Art.74 Market Surveillance Means for SaaS Providers: understanding when and why NCAs conduct inspections
2. Post #1478 — NCA Inspection Response Step-by-Step Playbook: the procedural response from first notice to inspection close
3. Post #1479 — The 7 Art.11 Documentation Gaps NCAs Find Most Often: the documentation gaps that extend inspections
4. Post #1480 — Art.15 Compliance Testing Evidence: What NCA Inspectors Actually Examine: the testing artifact categories inspectors request
5. Post #1481 (this post) — The 60-day action plan: structured sprint to close gaps before August 2, 2026

The August 2 deadline is not the end of EU AI Act compliance obligations — ongoing monitoring, annual documentation reviews, and post-market surveillance continue beyond enforcement day. But August 2 is the date when NCA inspection risk becomes real. Getting your documentation, testing evidence, and response protocols into inspection-ready shape before that date is the most leverage-efficient compliance investment you can make this summer.

sota.io runs on EU infrastructure (Hetzner Germany) with no US parent company and no CLOUD Act exposure. Your AI Act compliance documentation never leaves EU jurisdiction when you deploy on sota.io. Learn more about EU-native deployment →