EU AI Act Art.16 NCA Obligations, Serious Incident Reporting & Complete Provider Compliance Checklist: The Art.16 Finale for August 2026

Post #5 in the sota.io EU AI Act Art.16 Provider Obligations Series

The first four posts in this series walked through what a high-risk AI provider must build before placing a system on the EU market: the risk management system, corrective action pipelines, conformity assessment, CE marking, and database registration. This final post covers what happens after the system goes live — and what Art.16 demands of providers in ongoing relationship with national competent authorities (NCAs).

Three obligations complete the Art.16 picture. First, Art.16 in combination with Art.21 imposes a standing duty to cooperate with NCAs: provide documentation, enable audits, respond to information requests. Second, Art.73 requires providers to report serious incidents within legally defined timeframes — 2, 10, or 15 calendar days depending on severity. Third, Art.74 gives NCAs broad market surveillance powers including the authority to order a system off the market. Understanding these three obligations — and building the processes to meet them — is what separates a compliant provider from one that passes an initial audit but fails under live regulatory scrutiny.

What Art.16 says about NCA cooperation

Art.16 lists provider obligations in sub-paragraphs (a) through (k). The NCA-facing obligations sit in the later sub-paragraphs. Art.16(g) requires providers to take corrective actions and notify the relevant national competent authority when required under Art.20. Art.16(h) requires registration. But the operative NCA cooperation duty is established not in Art.16 itself but in Art.21, which Art.16 incorporates by reference.

Art.21 — Cooperation with competent authorities — states that providers shall, upon request by a competent authority, provide all information and documentation necessary to demonstrate conformity with the requirements set out in Chapter III Section 2. This includes:

• The technical documentation required under Art.11 and Annex IV
• Logs retained under Art.19
• Post-market monitoring reports under Art.72
• Corrective action records under Art.20
• Results of conformity assessment procedures under Art.43

The phrase "upon request" does not mean passive availability. It means active, timely provision. NCAs conducting market surveillance under Art.74 set response deadlines — typically between 10 and 30 days in Member State implementing legislation — and failure to respond is itself a violation that can trigger enforcement.

What NCAs can ask for

Art.74 grants market surveillance authorities extensive powers. They may:

1. Request access to source code or executable versions of the AI system where necessary to assess conformity
2. Require a sample of outputs from the system for evaluation
3. Commission third-party testing of the system at the provider's expense
4. Issue temporary market restrictions if the system poses an unacceptable risk while the investigation is ongoing
5. Order a system recall or withdrawal from the market if conformity cannot be demonstrated

The system access rights under Art.74(10) are particularly significant for AI providers. Regulators can demand that providers set up access in a controlled environment — including cloud-hosted inference endpoints — within a specified timeframe. Providers who have structured their system architecture around EU jurisdiction (keeping inference, logs, and model weights within EU Member States) are structurally better positioned to respond to these requests without triggering US Cloud Act or UK surveillance conflicts.

Confidentiality protections under Art.78

Art.78 provides some protection for commercially sensitive information shared with NCAs. Market surveillance authorities must treat as confidential:

• Trade secrets and intellectual property in the technical documentation
• Source code shared under Art.74(10)
• Test methodologies and benchmarks marked confidential by the provider

In practice, Art.78 does not mean providers can refuse to share information. It means the NCA is bound by professional secrecy obligations and cannot disclose the content to third parties outside the investigation. Providers should mark sensitive sections of their technical documentation explicitly as confidential when submitting to NCAs, with a brief explanation of the commercial sensitivity.

Art.73 Serious Incident Reporting: the process and the timelines

Art.73 is one of the most operationally demanding Art.16 obligations for providers of high-risk AI systems listed in Annex III. Any serious incident — defined in Art.3(49) as a malfunction, failure, or unexpected result that causes or could reasonably cause death, serious harm, significant disruption of critical infrastructure, or fundamental rights violations — must be reported to the market surveillance authority of the Member State where the incident occurred.

What counts as a serious incident

The definition in Art.3(49) is deliberately broad. In practice, providers should treat the following as presumptively reportable under Art.73:

• A decision made by the AI system that directly contributed to physical injury or death
• An AI output used in a law enforcement, employment, credit, or healthcare context that caused significant harm to an individual
• A system failure affecting critical infrastructure (energy grids, water systems, financial services, transport)
• A system breach or manipulation that could expose sensitive personal data processed by the AI system
• An output that constitutes a systematic violation of fundamental rights across a defined population

The "could reasonably cause" language means providers cannot limit reporting to cases where harm has already materialised. A near-miss that exposed the system's capacity to cause serious harm is reportable under the same rules.

Reporting timelines: 2, 10, or 15 calendar days

Art.73(3) through Art.73(5) specify three reporting windows depending on incident type:

2 calendar days — for incidents that have directly caused death or appear likely to have caused death within the reporting window. This is the fastest track: providers who become aware that their system may have contributed to a fatality must notify the relevant national authority within 48 hours of establishing the causal link.

10 calendar days — for serious incidents other than those involving immediate death. This covers physical injury, significant infrastructure disruption, or large-scale fundamental rights violations where no fatality has occurred.

15 calendar days — the maximum window for other reportable incidents that do not fall into the above categories, including incidents where the severity of harm is initially unclear and requires internal investigation before the provider can characterise the incident.

A note on common mistakes: These are calendar days from the moment the provider establishes the causal link between the AI system and the incident — not from when the incident occurred. A provider who discovers on day 12 that their AI system contributed to an incident that occurred on day 1 has 2/10/15 days from day 12, not from day 1. The clock starts at knowledge, not at occurrence. The 24h/72h reporting windows that developers associate with DORA Major Incident Reporting (RTS to Art.19) do not apply to AI Act Art.73.

The Art.73 notification format

The initial notification does not require a complete root cause analysis. Art.73(3) allows providers to make an initial report with the information available at the time, followed by an updated report as the investigation progresses. The initial notification should contain:

• System identification (product name, version, EU database registration number)
• Date and Member State where the incident occurred
• Nature of the incident and the harm caused or likely caused
• The preliminary assessment of the causal link between the AI system and the incident
• Immediate corrective actions taken or planned

Follow-up reports should be provided as the investigation proceeds. Art.73 does not specify a follow-up deadline, but NCAs conducting the market surveillance investigation under Art.74 will typically impose one.

Connecting Art.73 reporting to your post-market monitoring system

The most effective Art.73 compliance pipelines are built on top of the post-market monitoring system required under Art.72. Providers who have implemented the monitoring infrastructure described in the earlier posts of this series — automated anomaly detection, incident escalation pipelines, audit trail logging under Art.19 — already have most of what Art.73 requires. The missing piece is usually:

1. A classification layer that distinguishes reportable from non-reportable incidents based on the Art.3(49) definition
2. A notification template pre-approved by legal counsel that can be filed within the applicable window
3. A designated contact at the relevant national authority — the list of NCAs designated under Art.70 is maintained by the European AI Office

Providers who wait until an incident occurs to build this pipeline will typically miss the 2-day window in death cases and face enforcement action before they have completed their internal investigation.

Art.99 penalties for Art.16 violations

Art.99 sets out the penalty framework for violations of provider obligations. Non-compliance with Art.16 — including the NCA cooperation obligation and Art.73 serious incident reporting — attracts penalties of:

• Up to €15 million or 3% of global annual turnover (whichever is higher) for most Art.16 violations
• Up to €30 million or 6% of global annual turnover for violations involving prohibited AI practices under Art.5
• Up to €7.5 million or 1.5% of global annual turnover for providing incorrect information to authorities

The serious incident reporting obligation under Art.73 sits within the Art.16 framework, so failure to report within the prescribed window — or filing a materially misleading report — falls under the €15M/3% tier.

Penalties are calculated on the global annual turnover of the enterprise — the same basis as GDPR — which means group-level revenue applies even if the AI system is operated by a subsidiary. SME provisions in Art.99(6) give national authorities discretion to apply lower penalties to small and medium enterprises, but the discretion is permissive, not mandatory.

Complete Art.16 Provider Compliance Checklist

The following checklist covers all Art.16 sub-obligations and the associated Article requirements. Use this as the final audit gate before placing a high-risk AI system on the EU market and as an ongoing compliance calendar after placement.

Before placement (conformity phase)

• Art.9 RMS implemented: Risk management system documented with risk identification methodology, residual risk mitigation measures, and continuous monitoring plan
• Art.10 data governance: Training data documentation covering data sources, collection methodology, bias testing, and EU jurisdiction compliance for sensitive categories
• Art.11 technical documentation: Annex IV Technical File complete including system description, intended purpose, hardware/software specifications, training methodology, and test results
• Art.12 logging: Record-keeping system capable of automatically generating the logs required under Art.12 covering inputs, outputs, and flagged anomalies
• Art.13 transparency: Instructions for use drafted and available to deployers in the language of each Member State where the system is marketed
• Art.14 human oversight: Human oversight mechanisms designed and documented; override controls tested; personnel training materials prepared
• Art.15 cybersecurity: Accuracy, robustness, and cybersecurity requirements from Art.15 tested and documented in the technical file
• Art.17 QMS: Quality management system operational covering design, development, testing, post-market monitoring, and change management
• Art.43 conformity assessment: Conformity assessment procedure completed (self-assessment or third-party NB assessment depending on system category)
• Art.47 EU DoC: EU Declaration of Conformity drawn up, signed, and retained

At placement (market entry phase)

• CE marking affixed under Art.48 (references the EU DoC)
• Art.49 registration: System registered in EU database with all mandatory fields including EU DoC reference
• Art.16(c) instructions for use: Instructions provided to deployers at time of placement

After placement (ongoing obligations)

• Art.20 corrective actions: Process in place to detect, investigate, and remediate deficiencies; NCA notification procedure ready for cases requiring regulatory disclosure
• Art.21 NCA cooperation: Point of contact designated for NCA requests; technical documentation accessible within response window; briefing process for legal and technical teams on how to handle Art.74 investigations
• Art.72 post-market monitoring: PMS operational with monitoring metrics defined, anomaly thresholds set, and reporting frequency established
• Art.73 incident reporting: Incident classification matrix implemented; reporting templates drafted for 2/10/15-day windows; NCA contacts list maintained and current
• Art.18 documentation retention: All documentation retained for the applicable retention period (10 years for most categories under Art.18)

Ongoing review triggers

• Any substantial modification under Art.45 triggers re-execution of the conformity assessment and update of the EU DoC and database registration
• Any serious incident requires Art.73 notification within the applicable window and update of the post-market monitoring plan
• Any NCA request under Art.74 requires coordinated response within the authority's specified deadline
• Any change in intended purpose, deployment context, or user population triggers review of the instructions for use and the technical documentation

Connecting the five Art.16 posts: the provider's compliance arc

Looking back across the five posts in this series:

Post #1 established the framework: Art.16 is the provider obligations hub, drawing in Art.9 through Art.21 as the substantive requirements. The key insight was that Art.16 is not one obligation but a reference architecture for the entire provider compliance system.

Post #2 covered post-placement obligations, corrective actions under Art.20, and the NCA cooperation duty in the context of market surveillance. The practical takeaway: corrective action is not a last resort but a continuous process, and the duty to notify NCAs kicks in at a lower threshold than most providers expect.

Post #3 addressed the special case of GPAI-dependent high-risk AI systems — where Art.16 provider obligations interact with the obligations of the GPAI model provider. The gap analysis showed that providers who use third-party foundation models need documentation of the GPAI provider's conformity that their own technical file can reference.

Post #4 walked through the sequential chain: conformity assessment → EU Declaration of Conformity → CE marking → database registration. The implementation detail that matters: all four steps must be in sync, and a substantial modification under Art.45 restarts the chain from step one.

Post #5 (this post) closes the arc with the live-operation obligations: NCA cooperation under Art.21, serious incident reporting under Art.73, market surveillance survival under Art.74, and the complete Art.16 compliance checklist.

Together, the five posts cover the full lifecycle of a high-risk AI provider's Art.16 obligations from initial design through ongoing market presence.

August 2026: what happens if you are not compliant

The EU AI Act's enforcement chapter becomes fully applicable on 2 August 2026. From that date, NCAs in each Member State can initiate market surveillance investigations, request technical documentation, conduct audits, and impose penalties under Art.99 for high-risk AI systems that do not meet the Art.16 requirements.

Providers who have not completed their Art.16 compliance programme — risk management system, technical documentation, conformity assessment, CE marking, database registration, and incident reporting infrastructure — by 1 August 2026 face two categories of risk. The first is direct regulatory enforcement if their system is selected for market surveillance. The second is indirect commercial risk: deployers who use high-risk AI APIs will increasingly require contractual representations of Art.16 compliance as a condition of their own Art.26/27 deployer obligations. A provider who cannot produce a CE marking number and a EU database registration ID will find enterprise customers walking away before any regulator acts.

The Art.16 series ends here. The next series will cover Art.26 deployer obligations and Art.27 fundamental rights impact assessment — the other side of the provider-deployer relationship that Art.16 assumes is functioning correctly.