EU AI Act Providers vs Deployers: Who Owns Article 16 vs Article 26 Obligations

The EU AI Act assigns different obligations to providers and deployers of high-risk AI systems. Article 16 covers provider obligations. Article 26 covers deployer obligations. The split matters because most enterprises operating AI in the EU are deployers, not providers, and the deployer obligations get routinely underestimated. The provider built the system; the deployer puts it into use under its own authority. The Digital Omnibus on AI, which entered into force on July 27, 2026, pushed the application date for these obligations back: standalone Annex III high-risk systems now have until December 2, 2027, and AI embedded in products already covered by EU product-safety law (Annex I) has until August 2, 2028. The deferral bought time, not an exemption, and it did not touch which role owns which obligation.

The split is not always intuitive. A SaaS vendor that integrates a foundation model and resells it under their own brand becomes a provider under Article 25, even though they did not train the underlying model. An enterprise that takes a vendor's high-risk AI system and modifies it substantially can become the provider of the modified system. A deployer that puts a CE-marked high-risk system into use still owns most of the operational obligations regardless of who built the system.

I want to walk through the provider-deployer split as the regulation actually assigns it, the cases that flip the assignment, the architectural artifacts each side needs to produce, and the documentation patterns that hold up under a deployer audit.

TL;DR

The EU AI Act splits high-risk obligations in two: Article 16 for providers, Article 26 for deployers. Providers build and certify the system; deployers use it correctly, staff human oversight, and keep the logs. Four situations flip a deployer into a provider: substantial modification, branding and resale, repurposing for a new intended purpose, and crossing GPAI systemic-risk thresholds. The Digital Omnibus on AI deferred the application date for these obligations, standalone high-risk (Annex III) to December 2, 2027 and embedded high-risk (Annex I) to August 2, 2028, but Article 50 transparency duties and GPAI provider obligations stayed on the original August 2026 schedule. The role split and the evidence each side has to produce did not change.

The default split

The default assignment is straightforward when the AI value chain has clear roles.

Provider obligations under Article 16 include the risk-management system (Article 9), data and data governance (Article 10), technical documentation (Article 11), record-keeping/automatic logging in the system as designed (Article 12), transparency and information to deployers (Article 13), human oversight design (Article 14), accuracy and cybersecurity (Article 15), and the quality management system (Article 17). The provider also handles conformity assessment, EU declaration of conformity, CE marking, and registration in the EU database before placing the system on the market.

Deployer obligations under Article 26 include using the system in accordance with the provider's instructions, assigning human oversight to natural persons with the necessary competence, and making sure input data stays relevant and sufficiently representative for the intended purpose. The same article requires monitoring operation, suspending use when the system presents a risk to health, safety, or fundamental rights, keeping the automatically generated logs under the deployer's control for at least six months (Article 26(6)), informing affected persons about the use of the high-risk system, and conducting a Fundamental Rights Impact Assessment (Article 27) where applicable.

A clean way to summarize the default split: the provider proves the system was built right; the deployer proves the system is being used right.

The cases that flip the assignment

Four cases change the default assignment and turn a presumed deployer into a provider for regulatory purposes.

Substantial modification (Article 25(1)(c)). A deployer that makes a substantial modification to a high-risk AI system becomes the provider of the modified system. The regulation defines substantial modification as a change to the intended purpose or a modification that affects compliance with the high-risk requirements. Fine-tuning a foundation model on the deployer's own data, materially changing the system's classification thresholds, or adding a tool surface that changes the action space all sit on the edge of substantial modification and warrant a deliberate decision; I break down where that edge actually sits in substantial modification under the EU AI Act.

Branding and resale (Article 25(1)(a)). An organization that puts its name or trademark on a high-risk AI system already placed on the market becomes a provider of that system. A SaaS company that integrates a third-party AI system and resells it as its own product is in this category by default unless the contractual arrangement explicitly preserves the underlying provider's role.

Repurposing for a new intended purpose (Article 25(1)(b)). An organization that puts an existing system into service for a different intended purpose than what the original provider declared becomes the provider for that new purpose. The classic case is taking a general-purpose system and deploying it for an Annex III high-risk use case it was not originally documented for.

GPAI integration that crosses systemic-risk thresholds. The general-purpose AI provisions create a separate role for GPAI providers with additional obligations triggered when the model crosses computational or capability thresholds. An enterprise that builds on top of a GPAI model is typically not the GPAI provider, but the integration choices the enterprise makes can affect whether the resulting system is itself a high-risk AI system.

The architectural artifacts each side needs

The artifacts the provider produces are different in kind from the artifacts the deployer produces.

Provider artifacts include the technical documentation under Article 11 (system description, design specifications, development process, training data summary, performance metrics, risk-management measures), the EU declaration of conformity, the CE marking, the registration in the EU database, the post-market monitoring plan, the incident reporting procedure, and the documentation provided to deployers under Article 13 that explains capabilities, limitations, intended purpose, performance characteristics, and the human-oversight measures the deployer needs to implement.

Deployer artifacts include the assignment of human oversight roles and the competence evidence for the natural persons in those roles, the input-data review record showing the data is relevant and representative for the intended purpose, the monitoring log showing the system has been observed in operation, the incident log capturing any suspension events and the reasons, the records of automatic logging retained for at least six months under Article 26(6), the Fundamental Rights Impact Assessment where applicable under Article 27, and the records showing affected persons were informed about the AI system's use.

The deployer's logging obligation under Article 26(6) is the artifact most enterprises underestimate. The system as designed must produce the automatic logs under Article 12, a provider obligation; the deployer must actually retain them in a form a regulator can examine. An application that emits logs into a rotated file that gets overwritten every 30 days fails the deployer obligation even when the provider's design satisfied the production obligation.

The documentation patterns that hold up under a deployer audit

Three documentation patterns recur across enterprise deployers preparing for the December 2, 2027 high-risk enforcement date, and building them now rather than in 2027 is what keeps the deferral from turning into a scramble.

The role determination memo is a short document, signed by legal and the business owner, that states the enterprise's role for each high-risk AI system in production: provider, deployer, both, or neither. The determination cites Article 25 explicitly for any case where the default has been flipped. The memo is the single source of truth that all downstream compliance work references.

The Article 26 obligations matrix is a table that maps each Article 26 obligation to the natural person responsible, the artifact that demonstrates compliance, the location of the artifact, the retention period, and the review cadence. It is the operating document of the deployer's compliance posture, and auditors ask for it by name.

The Article 26(6) log architecture diagram shows how every AI request produces a log entry, where the log is stored, how the storage handles retention, how the integrity of the log is protected, and how the deployer would produce the log on a regulator's request. It is the artifact that turns the abstract logging obligation into something a security architect can review.

What sits with the foundation model provider regardless

GPAI providers operating in the EU have their own obligations under the GPAI provisions of the regulation. Those obligations include technical documentation about the model, information available to downstream providers integrating the model, and the additional obligations for models with systemic risk. The deployer is not on the hook for the GPAI provider's documentation; the deployer is on the hook for using the GPAI-integrated system within the parameters the upstream documentation specifies.

This is the case where the contractual arrangement matters as much as the regulatory text. A deployer that selects a foundation model from a provider whose documentation is thin has a deployer-side problem: the input-data and intended-purpose obligations under Article 26 cannot be discharged if the upstream documentation does not specify the parameters. The procurement workflow needs to test for documentation adequacy before contract signing.

The architectural artifact every deployer underestimates: identity-bound logs

Article 12(3) specifies what the automatic logs have to capture for the narrowest and strictest case, Annex III point 1(a) biometric identification systems: period of use, the reference database checked, the input data leading to a match, and the identity of the natural persons involved in verifying the result. That last field is the one most deployers fail across high-risk systems generally, biometric or not. AI systems running on shared service credentials cannot identify the natural person behind a request. The credential identifies the application, not the human or agent on whose behalf the application is acting.

The architectural answer is identity-bound logging at the AI request layer. Every request that reaches the model carries the verified identity of the natural person or agent that initiated it, and the log entry records the identity alongside the request and response. The artifact that satisfies the obligation is a per-decision audit record with identity context attached at the request boundary.

Application logs that the application controls do not satisfy the obligation reliably: the application can suppress them, it can fail to write them on crash, and it can selectively omit the identity field. The control needs to live at the layer that sees every request independently of the application.

DeepInspect

This is the deployer-side infrastructure DeepInspect was built to provide. DeepInspect sits inline between authenticated users or agents and the LLMs they call, binds every request to a verified identity, enforces per-route per-role policies, and writes a per-decision audit record outside the calling application.

For the Article 26 deployer obligations, including the Article 26(6) logging requirement, DeepInspect produces the records the deployer needs in the form an auditor can examine. Each record carries identity, role, policy version, data classification applied, decision outcome, and timestamps with sufficient precision to correlate across systems, signed and tamper-evident. Retention follows the configured period: six months minimum under Article 26(6), longer for jurisdictions and sectors with longer obligations.

For the role determination question, the gateway-layer log is the same artifact regardless of which natural-person role the deployer ultimately occupies. The deployer obligation is the same whether the underlying provider is OpenAI, Anthropic, Bedrock, or an internal fine-tune.

If you are facing the December 2027 high-risk deadline, let's talk.