EU AI Act Market Surveillance 2026: What NCAs Are Testing and What SaaS Developers Must Prepare For

Post #1375 in the sota.io EU AI Act Compliance Series

The EU AI Act's market surveillance regime is not theoretical. From August 2, 2026, National Competent Authorities (NCAs) across the EU have legal powers to demand documentation, inspect premises, require technical access to AI systems, and impose corrective measures. The question for every SaaS team deploying or providing AI features is not if an NCA will come — it is whether you will pass when they do.

This guide covers exactly what NCAs are authorised to test under Articles 74–80, how a surveillance audit typically unfolds, and the concrete checklist every developer team needs before the deadline.

Why Market Surveillance Starts Now

The EU AI Act enforcement timeline has two phases:

1. Prohibited-practices prohibitions — already in force since February 2, 2026
2. High-risk AI system obligations (most SaaS-relevant) — fully effective August 2, 2026 (18 months after entry into force on August 1, 2024)

From August 2, NCAs can open market-surveillance cases against providers and deployers of high-risk AI systems listed in Annex I and Annex III. They can also act on complaints from deployers, affected persons, and civil-society bodies.

Several NCAs — including Germany's BNetzA and France's CNIAI — have already published their market-surveillance methodology documents. These pre-announce exactly what they plan to look for. The pattern is consistent: documentation first, technical testing second, corrective action third.

The Legal Framework: Articles 74–80

Article 74 — Market Surveillance Authorities

Member states designate one or more national market-surveillance authorities (MSAs). These may be the same body as the notified body supervisor, or a separate regulator. Article 74(1) gives them competence over all AI systems within their territory except:

• GPAI models — supervised by the EU AI Office under Chapter V bis
• Financial-sector AI — supervised by financial regulators (EBA, ESMA, EIOPA) for their regulated entities

MSAs have the right to request documentation, conduct remote or on-site inspections, test AI systems in real or simulated operating conditions, and order immediate corrective actions.

Article 75 — Powers of MSAs

The core power set:

Article 76 — GPAI Model Supervision

For general-purpose AI (GPAI) models — systems like large language models with broad capabilities — the EU AI Office in Brussels is the primary supervisor, not national NCAs. However, if a GPAI model is integrated into a high-risk AI system deployed in a member state, the national NCA supervises the high-risk deployer, and can request the AI Office to investigate the underlying GPAI model.

Practical implication: if you use Claude, GPT-4, Gemini, or any major LLM as the backbone of a system that falls under Annex III, your NCA can audit your integration and the EU AI Office audits the model provider.

Articles 77–80 — Enforcement Escalation

What NCAs Actually Examine

Based on published NCA guidance, enforcement-preparedness consultations, and the explicit requirements in the AI Act, here is what market-surveillance inspectors request.

1. Technical Documentation (Annex IV)

Annex IV defines 8 mandatory sections of technical documentation. Every provider of a high-risk AI system must have this documentation before placing the system on the market.

Developer action: Annex IV documentation is version-controlled. Every production release must trigger a documentation update. NCAs look for documentation dates that do not match release dates — a red flag.

2. Risk Management System (Article 9)

Article 9 requires a continuous risk-management process covering the entire lifecycle of the AI system. The NCA will ask for:

• Risk identification records (initial assessment + updates)
• Risk analysis and evaluation (qualitative/quantitative)
• Risk mitigation measures and evidence they were implemented
• Residual risk acceptance records
• Review cadence documentation (when and who reviews risks)

The risk management system is not a one-time document — it must show evidence of ongoing activity. Inspectors look for audit trails showing periodic review.

3. Data and Data Governance (Article 10)

Training, validation, and testing datasets must be subject to data governance practices. NCAs inspect:

• Data sources and acquisition records
• Data labelling and annotation methodology
• Bias identification and mitigation measures
• Privacy-impact assessments for training data
• Evidence that prohibited data (biometric, sensitive categories) was handled lawfully
• Data-lineage records — tracing training examples back to source

If you use third-party datasets (Hugging Face, Common Crawl, commercially licensed corpora), your records must show you have rights to use them for training and can demonstrate their provenance.

4. Logs of Operations (Article 12)

Article 12 requires high-risk AI systems to automatically generate logs sufficient to allow post-hoc investigation of the system's behaviour. NCAs test whether:

• Logs are immutable (append-only, tamper-evident)
• Logs capture: input, output, confidence/score where applicable, timestamp, session context
• Logs are retained for the minimum period (5 years for systems in Annex III categories; 3 years otherwise — check your sector annex)
• Logs are accessible to NCAs on request within a defined timeframe

Developer action: Structured JSON logging to an immutable log sink (CloudWatch with log stream protection, Elasticsearch with index lifecycle management with write-once policy, etc.) is the minimum. A "write-once" bucket policy for audit logs satisfies Article 12.

5. Human Oversight Provisions (Article 14)

Article 14 requires that high-risk AI systems are designed to be overseen by a natural person. NCAs verify that:

• There is a technical mechanism to override, pause, or stop the AI system output
• Operators (deployers) have been informed about the scope and limits of human oversight
• The system's outputs are interpretable enough for a human to evaluate

This is particularly important for automated decision systems (HR screening, credit scoring, medical-device integration). The NCA will simulate a scenario where the AI produces a borderline output and check whether the human oversight mechanism is functional.

6. Conformity Assessment Evidence (Article 43)

Annex III systems require a conformity assessment. For most software providers, this is self-assessment (the standard path); for certain Annex III categories (biometrics, critical infrastructure), a notified-body assessment is mandatory.

NCAs look for:

• Declaration of Conformity (Article 47) — signed, dated, on file
• CE marking in product documentation
• Registration in the EU database for high-risk AI systems (Article 49) — the EUDB public register
• If notified-body involvement is required: the certificate, the notified body's identification number

The EUDB registration is the first thing inspectors check because it is publicly accessible. If your system is in-scope and not registered, the audit will escalate immediately to a formal non-compliance procedure.

7. Post-Market Monitoring Plan (Article 72)

Providers must maintain a post-market monitoring plan that collects and analyses operational data on system performance. NCAs will request:

• The monitoring plan document
• Data collected since market launch
• Reports of serious incidents (Article 73) — submitted to the NCA within 15 working days
• Any corrective measures taken in response to monitoring data

8. Incident Reporting Records (Article 73)

Serious incidents involving high-risk AI systems must be reported to the MSA of the member state where the incident occurred. An incident is "serious" if it results in:

• Death or serious injury to a person
• Serious damage to property
• Serious adverse societal impact within the scope of the AI Act

NCAs will check whether you have a documented incident-response procedure and whether any incidents since August 2, 2026 were reported within the 15-working-day window.

How a Market Surveillance Audit Unfolds

A typical NCA audit has three phases:

Phase 1: Documentary Review (remote, 30–60 days)

The NCA sends a formal information request (Article 75(3)). You have 10 business days to respond. They will request:

1. Technical documentation (Annex IV)
2. Declaration of Conformity
3. EUDB registration confirmation
4. Risk management system documentation
5. Log retention policy
6. Incident reports (if any)

At this phase, many cases close. If documentation is complete and coherent, the NCA files a "compliant" record and closes the case — often without further contact.

Phase 2: Technical Testing (on-site or remote API access)

If documentary review raises questions, or if the audit was triggered by a complaint or incident, the NCA moves to technical testing. This can include:

• API-level testing in a sandboxed environment (you provide a test account)
• Review of model card or system card
• Bias and accuracy tests using the NCA's own evaluation set
• Inspection of logs in production or a representative replica

NCAs have increasingly requested model access to test GPAI-backed high-risk systems, leading to coordination with the EU AI Office under Article 76.

Phase 3: Corrective Action or Formal Proceedings

What Triggers a Market Surveillance Investigation

NCAs initiate investigations via four pathways:

1. Complaint — from a deployer, affected person, or civil-society body (Article 74(4))
2. Incident notification — triggered by your own Article 73 report
3. Cross-border referral — another NCA flags the system in a coordinated review
4. Proactive sampling — NCAs select systems for review from the EUDB register at random or based on sector risk priorities

The highest-risk sectors for proactive surveillance in 2026: recruitment AI (Annex III.4), credit scoring (Annex III.5), education and vocational training (Annex III.3), and law enforcement (Annex III.6 — public-sector deployers).

The Developer Readiness Checklist

Use this 47-item checklist to assess your audit readiness before August 2, 2026.

Technical Documentation (Annex IV)

• Intended purpose clearly defined and version-controlled
• System architecture diagram current (matches prod)
• Input/output specifications documented with data types and edge cases
• Changes since last release documented in changelog
• Harmonised standards applied are listed with version numbers
• Test methodology described: dataset, metrics, thresholds
• Instructions for use written for deployers (not just end users)
• Documentation dates match release dates

Risk Management (Article 9)

• Risk register exists with identified risks, likelihood, impact
• Risk mitigation measures documented with implementation evidence
• Residual risks accepted with sign-off record
• Review schedule defined (e.g., quarterly or on each major release)
• Reviewer identity and credentials recorded

Data Governance (Article 10)

• Data sources documented for training, validation, test sets
• Data labelling process described with inter-annotator agreement records
• Bias scan performed and results documented
• Special-category data handling reviewed for GDPR compliance
• Third-party dataset licences on file
• Data-lineage chain traceable to source

Logging (Article 12)

• Production logs are immutable (write-once sink or tamper-evident storage)
• Logs include: timestamp, input hash, output, confidence/score, session context
• Log retention policy written and matches statutory minimums
• Logs accessible to authorised auditors within 24 hours of request
• Logging does not store personal data beyond the minimum necessary

Human Oversight (Article 14)

• Override / pause / stop mechanism exists and is functional
• Deployer documentation explains how to activate human oversight
• System output is interpretable (not a black-box score without rationale)
• Tested: human can intervene before output becomes irreversible action

Conformity Assessment (Article 43)

• Determined whether self-assessment or notified-body assessment is required
• Self-assessment record completed and signed
• If notified body required: certificate on file with expiry date
• Declaration of Conformity (Article 47) completed and signed
• CE marking applied to product documentation and packaging

Registration (Article 49)

• System registered in EU AI Act database (EUDB)
• Registration number recorded in internal system of record
• Registration reflects current version and intended purpose
• Update procedure in place for re-registration on major changes

Post-Market Monitoring (Article 72)

• Post-market monitoring plan written
• Data collection pipeline live in production
• Review cadence defined (at minimum annually)
• Monitoring data accessible for NCA request

Incident Reporting (Article 73)

• Serious incident definition documented and communicated to ops team
• Incident detection procedure in place (alerting, triage)
• 15-working-day NCA reporting timeline is in runbook
• NCA contact details for each operating country are on file
• Incident report template prepared

Frequently Asked Questions

We use a third-party AI API (OpenAI, Anthropic, Google) — are we still subject to market surveillance?

Yes. If your SaaS product provides a high-risk AI application (e.g., CV screening, credit risk scoring) and you use an LLM API as the underlying model, you are the provider of the high-risk AI system. The LLM vendor is a GPAI model provider supervised separately by the EU AI Office. Your NCAs will audit your system, your documentation, your risk management — not just the model.

We are a startup under 10 employees and €2M revenue — does the AI Act apply?

The AI Act has no SME exemption for compliance obligations, but it does provide SMEs with lighter conformity-assessment pathways and access to regulatory sandboxes (Article 57). However, the documentation and logging obligations apply to all providers regardless of size. The fines are proportionate (6% of global turnover — which is smaller for startups), but the compliance obligation is not waived.

Our AI feature is SaaS (cloud-hosted, subscription). Does that count as "placing on the market"?

Yes. Recital 23 of the AI Act explicitly states that "making available on the market" includes SaaS and API models. If you provide access to a high-risk AI system as a service and users are in the EU, you are in scope.

Which member state's NCA audits us?

If you are established in the EU: your national NCA. If you are outside the EU: the NCA of the member state where your EU-based authorised representative is established, or — absent a representative — the NCA of the member state where affected users are located. Multi-country deployment can involve coordination between NCAs under Article 74(7).

What if the NCA requests data we cannot share for IP or confidentiality reasons?

Article 75(5) provides that NCAs must treat confidential information received in the course of market surveillance as confidential. You can request confidential treatment of trade secrets. However, you cannot refuse to provide documentation on the basis of confidentiality — the NCA obligation overrides commercial confidentiality for enforcement purposes.

Action Plan: 60 Days to Audit Readiness

What Comes Next in This Series

This is Post #2 of the EU AI Act National Competent Authorities series (EU-AI-ACT-NATIONAL-COMPETENT-AUTHORITIES-2026):

1. ✅ NCA Country Guide — Who enforces the AI Act in Germany, Spain, France, Netherlands, Italy, Poland
2. ✅ Market Surveillance — What NCAs test and the 47-item developer checklist (this post)
3. 🔜 Regulatory Sandbox Access — How SaaS startups use Article 57 sandboxes before August enforcement
4. Post-Market Monitoring — Article 72 incident reporting, corrective actions, serious incident thresholds
5. Enforcement Finale — Complete compliance toolkit for the August 2, 2026 deadline

Market surveillance under the EU AI Act is not an abstract regulatory process — it is a structured audit with defined powers, defined documentation requirements, and defined escalation paths. The teams who are ready are the ones who treated compliance as an engineering problem: version-controlled documentation, immutable audit logs, tested override mechanisms, and a registered EUDB entry. The 47-item checklist above is the minimum viable compliance posture. Start with the gaps that are most visible to an inspector — Annex IV documentation and EUDB registration — and work inward.

The deadline is August 2, 2026. That is 65 days from today.