EU AI Act Provider Obligations for SaaS Companies Shipping a High-Risk Feature
SaaS provider obligations under EU AI Act Art 16: risk management, technical file, Art 43 conformity, Art 47 DoC, Art 49 registration. Deadline 2 Dec 2027.
Article 16 of Regulation (EU) 2024/1689 names the provider — the entity that develops or places an AI system on the market under its own name — as the party carrying the heaviest compliance load. If your SaaS product includes an AI feature that classifies as high-risk under Article 6 and Annex III, you are that provider. The obligation stack is not a checklist to tick once. It runs from system design through post-market monitoring and culminates in a formal conformity assessment, a signed Declaration of Conformity, CE marking, and EU-database registration before you ship. The deadline for stand-alone Annex III systems is 2 December 2027 under the Digital Omnibus agreed in May 2026 (the original 2 August 2026 date has been deferred).
This page walks the Article 16 obligations in the order you encounter them in practice. The general obligation map for all provider roles is at ai-compliance/provider-obligations; the prior question — whether your SaaS is a provider or a deployer — is answered at ai-compliance/for-saas. Here the role is settled: you ship the feature, you carry the obligations.
First: confirm you are the provider, not a deployer
Article 3(3) defines a provider as an entity that develops an AI system or has it developed and places it on the market or puts it into service under its own name or trademark. If you embed a third-party model (say, a GPAI API) into a feature and ship it to customers under your product name, you are the provider of that feature. Your customers who use the feature are deployers.
There is one complication specific to SaaS companies building on foundation models: the Article 25 trap. Article 25 states that a deployer of a GPAI model who integrates it into a product and ships it under their own name takes on provider obligations for the resulting system. That is almost certainly the situation you are in. The GPAI model vendor remains the provider of the model itself and must supply Annex XII documentation to downstream builders under Article 53. That Annex XII technical summary is useful evidence for your own technical file — but it does not substitute for your Article 11 documentation, which covers the high-risk system you have built on top.
Substantial modification triggers a provider role reset. If you take a third-party AI system that was already placed on the EU market and modify it in a way that affects its risk profile or intended purpose, Article 3(23) defines that as a substantial modification — and under Article 25, the modified system is treated as a new system placed on the market by you.
The Article 16 obligation stack, article by article
Article 9 — Risk management system
You must establish, implement, document, and maintain a risk management system throughout the entire lifecycle of the system. The system is an iterative process: identify and analyse known and foreseeable risks; estimate and evaluate risks in normal use and reasonably foreseeable misuse; adopt risk-mitigation measures; evaluate residual risk after mitigation.
Article 9(7) links the risk management system to the training, validation, and testing data: the data measures for Article 10 are part of what your Article 9 RMS must address. In practice, the RMS is not a one-time document — it is a running log of risk identification, mitigation decisions, and monitoring results that forms the spine of your technical file. Under the Article 17 QMS (see below), your RMS procedures must be documented.
Article 10 — Data and data governance
Every high-risk AI system that uses training data must meet Article 10 requirements. Training, validation, and testing datasets must be subject to appropriate data governance practices: they must be relevant, sufficiently representative, and as free of errors as practicable, considering the intended purpose. Critically, Article 10(5) permits processing of special-category personal data (health data, biometric data) where strictly necessary to detect and correct bias — but only with adequate safeguards.
Article 10 is about the data your system was built on, not about staff competence (that is Article 4, AI literacy, which has applied since 2 February 2025). Conflating the two is a common compliance error.
Article 11 and Annex IV — Technical documentation
Article 11 requires you to draw up technical documentation before placing the system on the market and to keep it up to date. Annex IV specifies nine content areas, including: a general description of the system and its intended purpose; a description of the elements of the system and the development process; information on training, validation, and testing; information on post-market monitoring; and a declaration of conformity.
This is the document that a market-surveillance authority will ask to see. It should be version-controlled. Retention period is ten years under Article 18. If you use a GPAI model, the Annex XII documentation your model vendor provides under Article 53 is an input to your Annex IV file — it tells you the model's capabilities, limitations, and known risks that you must address in your own risk management.
Article 13 — Transparency and instructions for use
Article 13 requires high-risk systems to be designed and developed in a way that is sufficiently transparent to enable deployers (your customers) to interpret the system's output and use it appropriately. The instructions for use must cover: the system's identity, purpose, and performance level; the types of individuals or groups on whom it is intended to be used; what human oversight is required; and any known limitations, biases, or circumstances where performance may degrade.
The instructions for use are not a marketing document. They are a compliance artefact that accompanies the product and tells the deployer what they must do to maintain lawful use. If a deployer violates the instructions, the liability shifts: Article 25 and Article 26 both contemplate role changes when the intended-use boundary is crossed.
Article 14 — Human oversight by design
Article 14 is not a policy requirement. It is a design requirement. You must build the system so that natural persons can effectively oversee it during deployment — meaning the system must be designed to allow oversight even when it is running in a SaaS context where your engineers are not physically present. That requires: an interface allowing deployers to understand outputs and identify anomalies; the ability to disregard, override, or reverse the system's output; and, where the system can operate with reduced human oversight, appropriate mechanisms to detect and handle situations requiring human intervention.
Article 14(4) introduces a "stop" capability: deployers must be able to interrupt the system with a stop button or equivalent procedure. If your SaaS feature feeds into automated downstream decisions, you must architect for that interruption point.
Article 15 — Accuracy, robustness, and cybersecurity
Article 15 requires high-risk systems to be designed for appropriate levels of accuracy, robustness, and cybersecurity. Robustness here is the statute's own term — it means resilience to errors, faults, and inconsistencies in inputs, including adversarial inputs. This is an engineering specification, not a product description. Your Article 9 RMS should contain the threat model, and your Annex IV documentation should record the testing methodology and results.
For SaaS providers, cybersecurity is particularly material: you hold customer data, you run inference infrastructure, and your system's outputs may inform decisions affecting individuals. Article 15(3) specifically mentions resilience against attempts by third parties to alter use, behaviour, performance, or integrity.
Article 17 — Quality management system
Article 17 requires providers to put in place a quality management system covering: a strategy for regulatory compliance; techniques and procedures for conformity assessment; examination procedures for serious incidents; data management procedures; record-keeping; accountability and responsibility maps; and internal audit procedures. For an early-stage SaaS company, the QMS does not need to be elaborate — but it does need to exist as documented policy, version-controlled and owned by a named person or team.
ISO/IEC 42001:2023 (the AI management system standard) maps well to Article 17 and provides a governance scaffold that also generates evidence for Articles 9, 10, and 11. ISO 42001 certification is voluntary and is not the same as the Article 43 conformity assessment — but a company that has built to the standard will find the technical-file assembly significantly easier.
Article 19 — Automatically generated logs
Article 19 requires providers to ensure their high-risk systems automatically generate logs to the extent technically feasible. Providers must keep these logs for a minimum of six months, where the logs are under their control. The logs support both the Article 72 post-market monitoring system and any incident investigation under Article 73.
Article 43 — Conformity assessment (Annex VI internal control)
Before placing a high-risk Annex III system on the EU market, you must complete a conformity assessment under Article 43. For most Annex III systems — categories 2 through 8 (critical infrastructure, education, employment, essential services, law enforcement, migration, justice/democracy) — this is an internal self-assessment following the Annex VI procedure. You do not need a notified body.
The Annex VI procedure has three parts: (1) verify that your system meets all requirements in Articles 9–15; (2) examine the technical documentation to confirm conformity; (3) keep the documentation available for ten years. The outcome is the signed Article 47 Declaration of Conformity and the right to affix the Article 48 CE marking.
The exception is Annex III point 1 (biometrics): for remote biometric identification systems where harmonised standards have not been applied, the Annex VII notified-body route is required.
Article 47 — EU Declaration of Conformity
The Declaration of Conformity is a formal document in which you (the provider) assert that the high-risk system conforms to the Act. Article 47 specifies what it must contain: system identification, the provider's details, a statement of conformity, and references to the technical documentation. One Declaration can cover multiple systems if they are sufficiently similar. The Declaration must be drawn up in the official language of each EU member state where you place the system — English alone does not suffice unless you are selling exclusively in English-speaking jurisdictions.
Article 48 — CE marking
Once conformity assessment is complete and the Declaration of Conformity is signed, you affix the CE marking to the system, or to its packaging or accompanying documentation where affixing it to the system itself is not feasible. Article 48(4) prohibits affixing the CE marking before the Article 43 assessment is complete.
Article 49 — Registration in the EU database
Before placing the system on the EU market, providers must register it in the EU database for high-risk AI systems under Article 71. Article 49 sets out what the registration must cover: the information listed in Annex VIII, which includes the system's purpose, capabilities, the conformity assessment route taken, and the Declaration of Conformity reference. Registration is separate from the conformity assessment — both must be done, in that order.
Article 72 — Post-market monitoring
Article 72 requires you to maintain a post-market monitoring system for the lifetime of the system. The system must actively collect, document, and analyse data on performance, near-misses, and incidents in production. For SaaS providers, the Article 19 automatic logs are the primary data feed into this system. Your monitoring system must be able to detect performance degradation, unexpected behaviours, and new risks that were not identified at the time of conformity assessment. Where the system is used by multiple deployers, you need a structured feedback mechanism to receive incident reports from them.
Article 73 — Reporting of serious incidents
Article 73 requires you to report serious incidents to the market-surveillance authority of the member state where the incident occurred. Timelines under Article 73:
- 15 days from awareness of an incident (general rule, Art 73(2))
- 2 days for a widespread infringement or serious and irreversible harm to critical infrastructure (Art 73(3))
- 10 days where a person has died (Art 73(4))
An incomplete initial report is permitted; it must be followed by a complete report (Art 73(5)). "Serious incident" is defined in Article 3(49): an incident that directly or indirectly causes or could cause death, serious harm, or significant disruption to critical infrastructure or services, or that affects democratic processes or violates fundamental rights.
The deployer's duty is related but distinct: under Article 26, deployers must monitor and flag incidents and risks to you as the provider. Art 73 reporting to authorities is your obligation, not theirs.
The Article 25 trap: building on a GPAI API
A SaaS company that calls a foundation model API to power a high-risk feature faces a specific compliance geometry. The model vendor is the GPAI model provider; under Article 53, they owe downstream builders (you) technical documentation — in the form of Annex XII — covering the model's capabilities, limitations, and known risks. They also owe a policy for complying with copyright law and a summary of the training data.
That Annex XII documentation is your starting point, not your ending point. You are the provider of the high-risk AI system. Your obligations under Articles 9–15, 17, 19, 43, 47, 48, 49, 72, and 73 all attach to the system you have built — which includes but is not limited to the underlying model. If the model vendor's Annex XII reveals a known bias or capability limitation, your Article 9 RMS and your Article 11 technical file must address it.
The trap is this: some companies assume that if the foundation model is GPAI-compliant, they inherit that compliance. They do not. GPAI compliance covers the model layer. The application layer — the high-risk feature you have built — requires its own full stack.
Deadlines and penalties
The deadline for stand-alone Annex III high-risk systems is 2 December 2027. For high-risk AI systems embedded in Annex I products (safety components of machinery, medical devices, etc.), the deadline is 2 August 2028. These are the dates confirmed under the Digital Omnibus political agreement of 7 May 2026; formal adoption is expected before the original 2 August 2026 date.
Non-compliance with most provider obligations — Articles 9–15, 17, 43, 47, 48, 49, 72, 73 — falls under Article 99(4): a maximum of €15,000,000 or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher. Under Article 99(6), for SMEs and start-ups the fine is capped at the lower of the two figures — a genuine proportionality protection, but not a reason to delay.
How Confir helps
Assembling the Article 16 stack from scratch is time-intensive. Confir generates the Article 11 / Annex IV technical documentation pack, produces the Article 47 / Annex V Declaration of Conformity, and runs the structured assessment across the four compliance areas that map to Articles 9, 10, 11, 13, 14, 15, 43, 72, and 73. The engine is rule-based and deterministic: the same intake produces the same finding, every rule that fires is human-readable, and the output is audit-defensible. The conformity assessment runs in under three sessions. No consultants, no implementation project. From €600/year at confir.eu.
Frequently Asked Questions
If I build a high-risk AI feature using a third-party API, do I carry the Article 16 provider obligations?
Yes. Under Article 25, when you develop an AI system on top of a GPAI model and place it on the EU market under your own name, you become the provider of that system. The GPAI model vendor carries the Article 53 obligations for the model layer and must supply you with Annex XII documentation. You carry Articles 9–15, 17, 19, 43, 47, 48, 49, 72, and 73 for the high-risk feature you have built. There is no compliance pass-through from the foundation model to the application built on it.
What is the difference between the Article 43 conformity assessment and ISO/IEC 42001 certification?
The Article 43 conformity assessment is a statutory requirement: you must complete it before placing a high-risk Annex III system on the EU market. For most Annex III categories (points 2–8), it is an internal self-assessment under the Annex VI procedure — no notified body required. ISO/IEC 42001 certification is voluntary and demonstrates your AI management system meets the standard's controls. It generates useful evidence for Articles 9, 11, and 17, but it does not substitute for the Article 43 assessment. The two are complementary, not interchangeable.
My SaaS feature scores job applicants. The customer (an HR team) reviews every decision. Does that shared oversight mean I'm a deployer, not a provider?
No. The fact that your customer exercises human oversight makes your customer the deployer under Article 26 — it does not change your role. You developed the feature and place it on the market under your name; you are the provider under Article 3(3) and carry all Article 16 obligations. The deployer's Article 26 obligations run alongside yours, not instead of yours. Your Article 13 instructions for use must tell the deployer what oversight is required.
What is a "serious incident" under Article 73, and what are the reporting timelines?
Article 3(49) defines a serious incident as one that causes or could cause death, serious harm to persons, significant disruption to critical infrastructure or services, or violation of fundamental rights. You report to the market-surveillance authority of the member state where the incident occurred: within 15 days of awareness in general; 2 days for widespread or critical-infrastructure harm; 10 days where a person has died. An initial incomplete report is permitted and must be followed by a complete one. This is a provider obligation. Your deployers (customers) report incidents to you under Article 26 — they do not report to authorities directly.
What is the registration obligation under Article 49, and is it separate from the conformity assessment?
Yes — they are sequential requirements. After completing the Article 43 conformity assessment and signing the Article 47 Declaration of Conformity, you register the system in the EU database under Article 71 before placing it on the market. Registration requires the information in Annex VIII, including the system's intended purpose, the conformity assessment route, and a reference to the Declaration. Registration is not a substitute for conformity assessment, and conformity assessment is not a substitute for registration.
When does the Digital Omnibus deadline change take effect, and what was the original date?
The original high-risk Annex III deadline was 2 August 2026. Under the Digital Omnibus — a Commission proposal of November 2025 that reached political agreement between Parliament and Council on 7 May 2026, with formal adoption expected before August 2026 — the deadline for stand-alone Annex III systems moves to 2 December 2027 and for Annex I product-embedded systems to 2 August 2028. This deferral applies to high-risk obligations only; the Article 50 limited-risk transparency rules still apply from 2 August 2026.
Related guides
- SaaS company obligations
- Articles 6-11 risk tiers
- SMB compliance requirements
- Articles 6–29 compliance checklist
- Article 3 definitions
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →