EU AI Act Art.71: How NCAs Use the EU Database for Market Surveillance — Developer Response Obligations 2026

Post #1660 in the sota.io EU AI Act Compliance Series — EU-AI-ACT-ART71-DATABASE-REGISTRATION-2026 #4/5

In post #1657 we explained the registration obligation: what systems must register, who is responsible, and when. In post #1658 we covered what Annex VIII Part I requires you to submit. In post #1659 we examined the parallel GPAI registration regime under Art.71(2).

This fourth post addresses the question that most developers have not yet asked: what happens after you register? Specifically, how do national competent authorities use the Art.71 database, what market surveillance powers do they have under Art.74, and what obligations fall on you as a registered developer when an NCA decides to look more closely at your system?

The August 2, 2026 deadline is not just a submission deadline — it marks the moment the Art.71 database becomes operational and NCAs can formally begin database-enabled enforcement. Understanding this dynamic before that date is the difference between being a compliant operator who sails through an NCA inquiry and one who receives a corrective action order.

The Database as a Market Surveillance Intelligence Tool

Art.71 creates what the Regulation calls a publicly accessible EU database. The non-confidential fields — system name, provider identity, intended purpose, Annex III category, CE marking reference — are visible to anyone, including competitors, users, journalists, and advocacy groups.

But the database serves a more targeted function for national competent authorities. For NCAs, the database is not just a public list; it is a queryable intelligence asset that allows them to:

• Identify all registered high-risk AI systems deployed within their jurisdiction by any provider, domestic or foreign
• Cross-reference reported incidents under Art.73 against the database to identify the registered provider and system
• Monitor post-market surveillance reports submitted by providers under Art.72 and compare them against the information in the database
• Track consistency between what a provider submitted at registration and what the system is doing in deployment
• Flag absent registrations — systems that should be in the database but are not

This last point is particularly important. The database makes non-registration visible. Before Art.71, an NCA investigating an AI system had to first establish who built it and what category it fell into. After Art.71, the absence of a registration for a system that clearly qualifies as high-risk under Annex III is itself a prima facie compliance failure — detectable without any field investigation.

What Triggers NCA Scrutiny of a Registered System

Under Art.74, NCAs do not investigate every registered system. Their resources are finite and their mandate is risk-proportionate. The triggers that move a registered system from the database onto an NCA's active docket are well-documented in the Regulation's enforcement architecture:

Trigger 1: Incident Reports Under Art.73

The most common enforcement trigger. Art.73 requires providers of high-risk AI systems to report serious incidents to the NCA of the Member State where the incident occurred. A serious incident is defined as any incident that causes death or serious harm to health, property, or fundamental rights, or any malfunctioning of the system that creates a significant risk of such harm.

When an Art.73 report is filed, the NCA will immediately cross-reference the Art.71 database. They will check:

• Is the system registered as required?
• Does the registration information match what the provider has disclosed in the incident report?
• Has the provider made prior reports for this system?
• What Annex III category applies, and what conformity assessment was conducted?

The incident report thus becomes a gateway to a broader compliance review, not just an incident response. A mismatch between your incident report and your database registration — even an innocent one arising from a system update — will draw additional scrutiny.

Trigger 2: User Complaints and Fundamental Rights Concerns

Citizens, civil society organisations, and public bodies can and do raise concerns about specific AI systems to their national NCAs. The Art.71 database is the NCA's first point of reference when such a complaint arrives: is the named system registered? Under what category? What did the provider claim as the intended purpose?

Complaints are disproportionately likely to arise in the high-risk AI categories most directly affecting citizens: recruitment tools (Annex III, point 2), credit scoring (Annex III, point 5(b)), benefits administration (Annex III, point 5(a)), and biometric categorisation (Annex III, point 1). If you operate in these categories, assume a higher baseline probability of complaint-triggered inquiries.

Trigger 3: Joint Surveillance Activities

The AI Board — established under Art.65 — coordinates joint surveillance activities between NCAs. When a pattern of similar systems across multiple Member States raises concern, the AI Board may trigger coordinated market surveillance sweeps. In these sweeps, the Art.71 database provides the scope: every registered system in the category of concern across all Member States.

Joint surveillance activities have precedent in both the NIS2 implementation and the GDPR enforcement cooperation framework. They tend to focus on emerging technologies or deployment contexts that have not yet been tested in practice — exactly the profile of the first wave of Art.71 registrations in 2026.

Trigger 4: Post-Market Surveillance Report Anomalies

Art.72 requires providers to maintain post-market monitoring systems and submit summaries or full reports to NCAs in certain cases. When an NCA receives a post-market report for a system, it will check the Art.71 database for consistency. Anomalies that attract attention:

• The post-market report describes capabilities not disclosed in the registration
• The post-market report identifies user populations different from those stated in the intended purpose field
• The provider's risk profile in the post-market report materially differs from the technical documentation summary registered under Annex VIII Part I

Trigger 5: Proactive Sectoral Sweeps

NCAs are empowered to conduct proactive market surveillance of specific sectors or AI application categories, independent of any complaint or incident. These sweeps are announced through official NCA publications and typically target a sector following regulatory guidance from the Commission or AI Board.

For SaaS developers, sectoral sweeps are the hardest trigger to predict and prepare for. The best defence is ensuring your registration is complete, current, and consistent with your deployed system — so that when an NCA runs a sweep query against the database for your sector, they find a well-documented, apparently compliant operator, not a sparse or stale registration.

Art.74: What NCAs Can Actually Do

Art.74 establishes market surveillance authorities as the operational framework for NCA action after the August 2026 deadline. The key powers that apply to registered high-risk AI systems are:

Power 1: Request All Documentation

Art.74 empowers NCAs to request that providers make available, within a specified deadline, all documentation required under Chapter III of the Regulation. For high-risk AI systems, this means:

• The complete technical documentation required under Art.11 and Annex IV
• The logs maintained under Art.12, to the extent required by law
• The post-market monitoring plan required under Art.72
• Any serious incident reports filed under Art.73
• The EU declaration of conformity under Art.47
• The written instructions for deployers provided under Art.13

The documentation you registered in the Art.71 database is a summary — a pointer. The NCA request is for the underlying substance. Your internal systems must be capable of responding to an NCA documentation request with a complete, coherent package on short notice.

Practical implication: build your technical documentation system so that the Art.11 / Annex IV package is exportable in a single structured output. An NCA expecting a response within 10 business days will not be sympathetic to "our documentation is spread across Confluence pages."

Power 2: Access Premises and Systems

NCAs have the power to carry out on-site audits of providers' premises. This includes access to the physical infrastructure on which the AI system runs, the systems used to maintain logs and technical documentation, and — where necessary — access to the AI system itself for testing.

For SaaS developers operating on EU-hosted infrastructure, this power has a concrete form: the NCA may request access to your production or staging environment, your model versioning system, your logging pipeline, and your data governance records.

Practical implication: if your AI system runs on US-hosted infrastructure with EU-origin data, an NCA exercising Art.74 inspection powers faces a jurisdictional problem — they can audit you (the provider) but cannot directly compel access to data held outside the EU. This is one of the EU hosting compliance angles that makes Art.9, Art.10, and Art.12 record-keeping on EU infrastructure materially reduce your enforcement risk.

Power 3: Request Corrective Action

Where an NCA finds a compliance gap, Art.74 empowers it to order the provider to take corrective action within a specified timeframe. Corrective actions range from:

• Updating the Art.71 database registration to reflect current system state
• Modifying or adding information to the technical documentation
• Implementing additional risk mitigation measures in the AI system
• Suspending or restricting the system's deployment pending corrective action
• In the most severe cases, withdrawing the system from the market

The corrective action power is where market surveillance transitions into enforcement. The timeline from an NCA investigation opening to a corrective action order typically runs 60–120 days in other EU regulatory contexts (GDPR, NIS2). Given the AI Act's novelty, expect this timeline to be longer in the first two years of enforcement.

Power 4: Notify the Commission and Other NCAs

When an NCA takes action against a high-risk AI system registered in the Art.71 database, it notifies the Commission and the NCAs of other Member States. This notification obligation — designed to prevent forum shopping and ensure EU-wide consistency — means that a corrective action order in one Member State becomes visible to all NCAs within days.

For SaaS developers operating across multiple EU markets, this cross-notification is both a risk and a design constraint. It means you cannot resolve a compliance problem with the German NCA and then continue operating the same non-compliant system in Austria and the Netherlands. The EU market is one enforcement space.

Developer Response Obligations During an NCA Investigation

When you receive formal notice that an NCA has opened a market surveillance inquiry into your registered system, specific obligations and recommended practices apply.

Step 1: Acknowledge and Designate a Contact

The NCA notice will typically request a formal acknowledgment within 5–10 business days and will ask you to designate a named contact person with authority to respond on behalf of the provider. If you have an authorised representative (Art.22 of the Regulation), they should be your first call — they are legally positioned as the NCA's primary interlocutor.

If you lack an authorised representative: this is a serious gap. Art.22 requires providers established outside the EU who place high-risk AI systems on the EU market to appoint an EU-based authorised representative. If you are a non-EU provider without an authorised representative, the NCA inquiry will immediately expand to address that compliance failure in addition to whatever prompted the inquiry.

Step 2: Assemble Your Documentation Package

The NCA will specify what documentation it is requesting. Standard first-round requests typically cover:

• The complete technical documentation under Art.11 / Annex IV
• The conformity assessment documentation under Art.43
• The post-market monitoring plan under Art.72
• Any incident reports filed under Art.73
• The written instructions for deployers under Art.13(1)

Cross-reference everything against your Art.71 database registration. Any inconsistency between your registered information and your documentation package — even an innocuous one caused by a system update since registration — must be proactively flagged and explained. Do not wait for the NCA to find the discrepancy.

Step 3: Update the Art.71 Database if Necessary

If the NCA inquiry reveals that your Art.71 registration is materially outdated — because the system has changed in ways that affect its compliance status, the intended purpose has evolved, or the deployment context has expanded — you must update the database registration promptly.

Failure to maintain an accurate registration is itself a compliance failure under Art.49(2) (which requires providers to keep the database information current). Proactively updating before a corrective action order is issued demonstrates good faith and typically results in a less severe outcome.

Step 4: Respond Promptly and Completely

NCAs are sensitive to providers who respond to formal requests incompletely or with unexplained delays. Within the AI Act enforcement framework, as in GDPR enforcement, the quality of a provider's response to an investigation is a factor the NCA considers when deciding whether to issue a corrective action order and what severity to apply.

A complete, well-organised, promptly delivered documentation package with a clear explanatory cover letter does not guarantee a clean outcome — but an incomplete, delayed, or disorganised response virtually guarantees that the NCA will open a deeper inquiry.

Step 5: Preserve Logs and System State

From the moment you receive an NCA notice, you are on constructive notice that the logs and system records relating to your AI system may be relevant to the investigation. Implement a litigation hold equivalent: pause any automatic log rotation or deletion for the system in question, preserve all relevant technical documentation as it exists at the date of notice, and document any changes made to the system after the inquiry opens.

This preservation obligation is not explicitly stated in Art.74 but follows from the general cooperation obligation and the NCA's power to request documentation. A provider who cannot produce logs because they were automatically deleted after the inquiry opened will find the NCA drawing adverse inferences.

The Art.71 Database After Enforcement

What happens to your database registration when an NCA takes enforcement action? This is an area where the Regulation provides limited explicit guidance, but the design logic points to the following outcomes:

Corrective Action Without Market Restriction

If the NCA orders corrective action that does not involve withdrawing or restricting the system — for example, updating technical documentation or improving the post-market monitoring plan — you remain registered and operational. You update your Art.71 registration to reflect any changes made in response to the corrective action order.

Suspension of Market Availability

If the NCA orders the system's deployment to be suspended pending corrective action, this is a material change to the system's status that affects the Art.71 registration. Providers should consider whether the Art.74 compliance status flag in the database needs to reflect the suspension and whether the registration information needs to be updated accordingly.

Withdrawal from the Market

If the NCA orders withdrawal — the most severe sanction short of a penalty — the system is removed from the market and its Art.71 registration is no longer active in the sense that it supports current market availability. The registration record is preserved, but the system is no longer deploying in the EU.

For cross-border SaaS developers, a market withdrawal order from one Member State triggers the cross-notification obligation under Art.74, meaning all NCAs are informed. Operating the same system in other Member States after receiving a withdrawal order in one is not legally tenable without addressing the underlying compliance failure.

The Art.71 Database and Your Post-Market Monitoring System

One practical integration point that many providers underestimate is the relationship between Art.72 post-market monitoring and Art.71 registration accuracy. The post-market monitoring system under Art.72 generates data about how the deployed system is performing in the real world — user feedback, performance metrics, identified biases, incident rates.

This data will inevitably produce information that affects whether the registered description of your system — its intended purpose, risk category, deployment context, user population — remains accurate. When post-market data reveals material drift between registration information and reality, you have two options:

1. Update your Art.71 registration to reflect the evolved system
2. Realign your deployment to match the registered system description

Neither option is always comfortable, but both are preferable to being caught in an NCA investigation where your Art.71 registration describes a different system from the one your post-market data reflects.

The integration between Art.71 and Art.72 is best handled by making your post-market monitoring system output a regular registration-consistency check: a structured comparison of current system state against registered state, flagging any drift that exceeds a defined threshold. This is an automated compliance control, not a manual process.

Practical Timeline: From Database-Active to NCA Investigation

For providers planning their post-August 2026 compliance operations, a rough timeline of how an NCA investigation typically develops:

T+0 (August 2, 2026): Art.71 database becomes operational. NCAs begin systematic review of registrations in their jurisdiction.

T+0 to T+3 months: NCAs conduct initial desk review of registrations. Systems with incomplete registrations, inconsistent information, or operating in high-priority categories (biometrics, employment, benefits, credit) receive closer attention.

T+3 to T+6 months: First formal inquiries are sent. Providers receive documentation requests with 10–15 business day response windows.

T+6 to T+12 months: Based on documentation review, NCAs escalate to on-site audits for a subset of cases. First corrective action orders issued.

T+12 to T+24 months: Second wave of enforcement based on post-market monitoring data collected in the first year. Systems that registered cleanly but whose post-market reports reveal performance gaps become the focus.

This timeline is speculative but based on the enforcement ramp-up patterns observed in GDPR (2018-2019), NIS2 (2023-2024), and DORA (2025). The AI Act is more technically demanding than any of these predecessors, which suggests the early enforcement period will be longer, not shorter.

Key Developer Obligations Summary

EU Hosting and Art.74 Inspection Risk

One dimension of Art.74 that SaaS developers often overlook is the intersection with data residency. NCAs can request on-site access to production infrastructure and data as part of a market surveillance audit. If your AI system processes EU personal data on US-hosted infrastructure, an NCA seeking to inspect your training data, logs, or model behaviour faces a jurisdictional friction point.

This friction does not protect you — it complicates you. The NCA may issue a corrective action order requiring you to bring the relevant data and infrastructure into EU jurisdiction as a condition of continued EU market operation. Meanwhile, your response to the NCA's Art.74 request is complicated by the need to navigate US data access laws and potentially conflicting obligations.

Providers operating exclusively on EU-hosted infrastructure eliminate this friction entirely. Your NCA contact is clear, your data is accessible under EU law, and your cooperation response is straightforward. This is the regulatory risk reduction that EU-native infrastructure delivers — not in abstract GDPR terms, but in concrete Art.74 enforcement terms.

Conclusion

The EU AI Act Art.71 database transitions from a registration requirement to a live enforcement tool on August 2, 2026. NCAs are empowered under Art.74 to use that database as a market surveillance intelligence asset: to identify systems, cross-reference incidents, compare registration information against post-market behaviour, and trigger investigations when anomalies emerge.

As a registered developer, your obligations do not end at registration. They include maintaining registration accuracy, responding promptly to NCA inquiries, preserving logs and documentation on notice, and cooperating with any corrective action process. The quality of your response to an NCA investigation is a direct input to the severity of the outcome.

In the final post of this series, we will bring together the complete Art.71 compliance checklist — from initial registration readiness through ongoing maintenance and NCA response preparation — to give you a single, actionable document for the August 2026 deadline.

sota.io provides EU-hosted infrastructure for developers building AI systems that need to stay compliant with the EU AI Act, GDPR, and DORA. All workloads stay within EU jurisdiction — relevant to Art.74 inspection readiness and Art.12 record-keeping requirements. View plans →