Can the provider and the deployer be the same entity?

Yes. An organization that develops an AI system in-house and uses it internally is both the provider and the deployer. The dual role does not collapse the obligation set. The organization has to produce the provider artifacts and maintain the deployer evidence. Internally, the same compliance team often owns both, but the artifacts are distinct.

How does the obligation split work for fine-tuned models?

When a deployer fine-tunes a vendor model on its own data, the fine-tuning may constitute substantial modification under Article 43(4), which can make the deployer a provider for the fine-tuned variant. The Commission's interpretive guidance from May 2026 sharpened the test. Deployers that fine-tune should run the analysis early.

What about general-purpose AI providers under Articles 53 and 55?

General-purpose AI providers have a parallel obligation set under Articles 53 and 55. The deployer of a GPAI-based system retains the deployer obligations under Article 26. The GPAI provider carries the upstream obligations. The shared responsibility model the Commission has been articulating allocates responsibility along the value chain.

How long do the deployer's Article 12 records have to be retained?

Article 26 sets a minimum of six months for the deployer's Article 12 logs unless a longer retention is required by Union or national law. Sector-specific regimes regularly require longer retention. Financial services, healthcare, and employment use cases routinely require multi-year retention under sector-specific law.

What evidence does the market surveillance authority inspect?

The market surveillance authority can request the provider's technical documentation, the Annex IV documentation, the conformity assessment artifacts, the EU database entry, the post-market monitoring data, the deployer's Article 12 logs, the deployer's Article 14 oversight evidence, and the deployer's Article 27 fundamental rights impact assessment. Both the provider and the deployer have to produce their respective artifacts on demand.

Does the deployer obligation apply to AI used internally by employees only?

Yes for high-risk uses. The Article 26 obligations attach to the use of a high-risk AI system within the EU, regardless of whether the affected persons are internal employees or external customers. An HR screening tool used internally falls under Annex III point 4(a). A clinical decision support tool used by a hospital's own staff falls under Annex III point 5(a). The deployer obligations apply.

EU AI Act Deployer vs Provider: Who Owns Which Obligation in a High-Risk Deployment

The EU AI Act assigns obligations to two distinct roles: the provider that develops the AI system and places it on the EU market, and the deployer that puts the system into use within the EU. The split runs through every operative obligation. Article 16 and Article 17 set the provider obligations. Article 26 sets the deployer obligations. Article 43 defines the conformity assessment provider-side, and Article 12 sets the traceability requirement that lands on both.

The misread that costs the most is that the deployer can satisfy its obligations by consuming the provider's documentation. The deployer's evidence has to describe the use, not just the system.

I want to walk through what each role owns, where the shared obligations create coordination work, and the operational architecture an enterprise deployer of a vendor-supplied high-risk system needs to land before August 2, 2026.

What the provider owns

The provider's obligations attach to the system as a product placed on the market.

The technical documentation and the conformity assessment

Under Article 11 and Annex IV, the provider produces the technical documentation that describes the AI system: its intended purpose, the training data summary, the architecture, the testing protocols, and the risk management measures. Under Article 43, the provider runs the conformity assessment that confirms the system meets the high-risk requirements in Chapter III, Section 2 before placing it on the market. The conformity assessment can be self-assessment for systems outside the Annex III categories that require a notified body.

The CE marking, the EU database registration, and the declaration of conformity

The provider applies the CE marking under Article 48, registers the system in the EU database under Article 49, and issues the EU declaration of conformity under Article 47. These artifacts are public-facing. The deployer relies on them to confirm the system is properly placed on the market.

Post-market monitoring and the corrective action obligation

Under Article 72, the provider operates a post-market monitoring system that continuously collects data on system performance. Under Article 79, the provider takes corrective actions when non-compliance is detected and notifies the relevant market surveillance authorities. The post-market monitoring is the provider's obligation; the deployer's runtime evidence often feeds it but does not replace it.

Instructions for use

Under Article 13, the provider supplies the deployer with instructions for use that specify the deployer's responsibilities, the human oversight measures expected under Article 14, the limitations of the system, the foreseeable misuse cases, and the post-market monitoring data the deployer should provide back to the provider.

What the deployer owns

The deployer's obligations attach to the use of the system within the deployer's environment.

The use-side traceability and the Article 26 obligations

Under Article 26, the deployer assigns human oversight to natural persons with the competence to perform it, monitors the system in line with the instructions for use, retains Article 12 logs for at least six months unless a longer period is required by Union or national law, and informs the affected persons when a decision is made or supported by the system in defined contexts.

The fundamental rights impact assessment

Under Article 27, deployers that are public bodies or that perform certain functions in the private sector run a fundamental rights impact assessment before deploying the system. The assessment describes the intended purpose of the use, the categories of natural persons likely to be affected, the specific risks of harm, the human oversight measures, and the measures the deployer takes when those risks materialize.

The notification to affected persons

Under Article 26(11), the deployer notifies affected persons when they are subject to a decision made or supported by a high-risk AI system that produces legal effects or similarly significant effects. The notification is automatic. It does not depend on the affected person requesting it.

The post-market data return to the provider

Under Article 72, the deployer returns relevant post-market data to the provider per the instructions for use. The data return is the operational link between the deployer's runtime experience and the provider's post-market monitoring system.

The shared traceability obligation under Article 12

Article 12 requires automatic recording of events over the lifetime of the system. The records have to include the period of use, the input data, the reference database (if any), the output, and the identification of natural persons involved in human oversight under Article 14.

The provider produces logs from the system's perspective: what the system was asked, what it produced, in what configuration. The deployer produces logs from the use's perspective: which user made the request, under which policy, with which data classification, with which human oversight applied. Both sets of logs are required. Neither replaces the other.

Why deployer logs cannot be the provider's logs

The provider deploys the system as a product placed on the market. The system may be deployed at hundreds of deployer sites, each with different identity contexts, different policy configurations, different oversight workflows. The provider's logs describe the system. The deployer's logs describe the local use. The market surveillance authority that inspects a specific deployer site needs the deployer's local logs to reconstruct what happened at that site.

Why provider logs cannot be the deployer's logs

The deployer typically does not have engineering access to the provider's system internals. The provider's logs include data the provider treats as proprietary, including training-data lineage and internal model state. The deployer cannot rely on the provider's logs for its own Article 26 obligations because the deployer does not control the provider's log retention, the access controls, or the legal basis for retaining the logs.

The compliance gap most deployers carry

Most enterprise deployers of vendor-supplied AI systems carry a documentation-only stance into August 2. The vendor produced the technical documentation. The deployer filed the documentation. The deployer assumes the obligation is met.

The Article 26 obligations are not document-filing obligations. They are runtime-evidence obligations. The deployer has to maintain Article 12 logs that demonstrate which user invoked the system, under which policy, with which data, with which oversight applied. The deployer has to maintain the Article 14 oversight evidence: who reviewed which output, when, with which authority to override. The deployer has to maintain the Article 27 impact assessment and update it when the use materially changes.

The vendor's technical documentation does not contain any of this. The vendor's documentation describes the system. The deployer's evidence describes the use.

DeepInspect

This is the deployer's runtime evidence layer that DeepInspect produces. DeepInspect sits at the AI request boundary inside the deployer's environment, intercepts every HTTP request to the vendor-supplied AI system (whether the system is OpenAI, Anthropic, Bedrock, Vertex, Azure OpenAI, or self-hosted), and records a per-decision audit record that includes the identity of the requesting user, the policy version, the data classification of the prompt, the decision outcome, and a tamper-evident signature.

For the deployer's Article 26 obligation, the per-decision records are the source data. The deployer can reconstruct any decision the system supported, identify the user, the policy in force, and the data the system saw. The deployer's audit independence is intact: the records exist regardless of whether the vendor's system later changes its own logging behavior.

If you are deploying a high-risk vendor-supplied AI system in the EU and your traceability strategy depends on the vendor's logs, the August 2 enforcement date will surface the deployer-side gap. Book a demo today.

Beyond Article 26

The deployer-vs-provider split appears in adjacent regimes. The NIST AI Risk Management Framework GOVERN function distinguishes the AI actor roles in similar terms. ISO/IEC 42001 places management-system obligations on the deployer separate from the developer's model-card obligations. The Fannie Mae LL-2026-04 framework treats the lender as the deployer responsible for the AI-supported decisions, regardless of the vendor that supplied the model.

The architecture that satisfies the deployer side of Article 26 satisfies the deployer side of these adjacent regimes. The vocabulary differs across the regulators. The evidence requirement is the same.