Responsible AI: The Provider-Deployer Obligation Split Under the EU AI Act

One of the most common compliance miscalculations for responsible AI in 2026 is misidentifying your organization’s role in the AI supply chain. Whether you are a provider — an organization that places an AI system on the market or puts it into service — or a deployer — an organization that uses an AI system under its own authority — determines which obligations under the EU AI Act apply to you, which controls you must build, and which documentation you must produce. Getting this wrong means either building compliance infrastructure you do not need, or failing to build infrastructure you are legally required to have by August 2, 2026.

This post explains the responsible AI obligation split between providers and deployers for high-risk AI systems, maps those obligations to the NIST AI Risk Management Framework ↗, and identifies the steps organizations in each role should be taking now.

How the Law Draws the Line

Under Regulation (EU) 2024/1689 — the EU AI Act — a provider is any natural or legal person that develops an AI system with the intent of placing it on the market or putting it into service under their own name. A deployer is any natural or legal person that uses an AI system under their own authority for professional purposes, except when that use is purely personal.

The practical implication: a company that builds an automated hiring screening tool and licenses it to other employers is a provider. An employer that licenses that tool and uses it to screen candidates is a deployer. Many organizations occupy both roles simultaneously — building internal AI systems makes you a provider in relation to those systems, even if no external market transaction is involved.

The Act’s high-risk AI categories are defined in Annex III and include employment screening, credit scoring, essential services (utilities, water, heating), education, biometric identification, critical infrastructure, law enforcement, border control, and administration of justice. If your AI system touches any of these domains, the provider-deployer split is not academic — it maps directly to specific obligations with enforcement deadlines.

What Providers Must Do: Article 16 and Article 9

Article 16 ↗ lists twelve categories of obligation for providers of high-risk AI systems. The operationally significant ones are:

Quality management system. Providers must implement a documented quality management system under Article 17, covering the full development lifecycle: data governance, design methodology, testing procedures, documentation standards, and post-market monitoring.

Conformity assessment. Before placing a high-risk system on the market, providers must complete a conformity assessment. Depending on the system’s domain, this may be a self-assessment or may require a notified body. Either way, the resulting EU declaration of conformity and CE marking must exist before deployment.

Technical documentation. Providers must produce documentation sufficient for national competent authorities to assess regulatory compliance — purpose, design logic, performance metrics, training data description, and risk evaluation findings.

Post-market monitoring. Article 16 requires providers to operate a post-market monitoring system, tracking the system’s performance in production and reporting serious incidents to the relevant national authority.

Automatic log preservation. Where providers retain control over deployed systems, they must preserve the automatically generated logs the system produces.

The foundation under all of these is the Article 9 risk management system ↗: a continuous, iterative process that must operate across the full lifecycle of the high-risk AI system. Article 9 requires providers to identify and analyze foreseeable risks, estimate risks from intended use and misuse, incorporate findings from post-market data, and adopt mitigation measures that reduce residual risk to an acceptable level. Testing against prior-defined metrics and probabilistic thresholds is mandatory before market deployment.

In terms of the NIST AI RMF’s four functions, provider obligations map primarily to GOVERN (quality management system, accountability structures), MAP (system scoping, intended-use analysis, affected-population identification), MEASURE (conformity testing, bias evaluation, performance benchmarking), and MANAGE (risk treatment, post-market monitoring, incident response). An organization that has implemented the NIST AI RMF with depth in all four functions has most of the technical groundwork for EU AI Act provider compliance — but it must still produce the specific documentation formats and pass the conformity assessment process the Act prescribes. For tooling that supports continuous monitoring under the Measure and Manage functions, SentryML ↗ tracks the relevant MLOps and observability practices.

What Deployers Must Do: Article 26

Article 26 ↗ obligations for deployers are operationally distinct from provider obligations — they focus on use, oversight, and notification rather than design and conformity assessment.

Instructions compliance. Deployers must use high-risk AI systems in accordance with the provider’s published instructions for use. Deploying a system outside its documented intended purpose shifts responsibility toward the deployer.

Human oversight. Deployers must assign competent personnel with the training and authority to oversee system operations and intervene. The EU AI Act’s language on human oversight is specific: oversight mechanisms must be capable of detecting and correcting anomalous behavior, not merely logging it. For organizations building or procuring these controls, GuardML ↗ covers defensive AI tooling and safety mechanisms.

Log retention. Deployers must retain the automatically generated logs produced by the high-risk AI system for a minimum of six months.

Worker notification. Before deploying a high-risk AI system that affects workers, deployers must inform employees and their representatives of the deployment.

Individual notification. Deployers must inform individuals when a high-risk AI system is making or substantially assisting a decision that affects them.

Fundamental Rights Impact Assessment (FRIA). Public authorities using high-risk AI systems, and private bodies performing public tasks, must conduct a FRIA before deployment and notify supervisory authorities.

In NIST AI RMF terms, deployer obligations concentrate in GOVERN (accountability, roles, policies for use), MAP (scoping systems in use against the Annex III categories), and MANAGE (human oversight mechanisms, log retention, incident notification). The MEASURE function applies to deployers primarily through operational monitoring rather than pre-deployment testing — that burden sits with providers.

When You Are Both

Organizations that build and operate their own AI systems — internal recruiting tools, credit risk models for internal decisions, predictive maintenance for critical infrastructure — are simultaneously providers and deployers. They carry the full set of obligations from both Article 16 and Article 26, with no division of responsibility between an external vendor and an internal team.

This is the most demanding compliance position, and also the most common one in regulated industries. Financial services, healthcare, and critical infrastructure operators who have built AI systems in-house need to have completed both a conformity assessment (provider obligation) and have standing human oversight procedures in place (deployer obligation). The August 2, 2026 deadline is not a starting point — organizations that have not yet mapped their systems against Annex III categories, run their Article 9 risk management cycle, or identified the personnel responsible for Article 26 oversight are behind the schedule the Act implies.

AI security teams should note that the Article 9 foreseeable-misuse analysis requires treating adversarial inputs as a documented risk category. Prompt injection, model inversion, and adversarial examples are not optional considerations — they are foreseeable in any AI system exposed to external input. AI security researchers track these attack patterns at aisec.blog ↗, and the attack surface analysis belongs in your Article 9 documentation.

What to Do This Quarter

1. Map your role. For every AI system your organization builds or uses professionally, determine whether you are the provider, the deployer, or both. The definition turns on who developed the system and placed it into service — not on who pays for it.

2. Run the Annex III screen. Check whether any system qualifies as high-risk under the Act’s eight-category list. Employment, credit, education, essential services, and biometrics are the categories that most frequently catch organizations by surprise.

3. Providers: initiate the Article 9 risk management cycle. Document your known and foreseeable risks, establish testing metrics, and assign ownership of post-market monitoring before the conformity assessment can be completed.

4. Deployers: document your human oversight chain. Identify the specific personnel responsible for oversight of each high-risk system, confirm they have received training, and establish the intervention procedures they are expected to follow.

5. Both: verify log retention is operational. Automatic logs must be retained for six months. If your AI systems do not currently produce structured logs, that gap needs to be closed before the August 2026 deadline, not after.

Sources

• EU AI Act — Article 9: Risk Management System ↗ — The binding text of Article 9, which requires providers to operate a continuous iterative risk management system across the full AI lifecycle, with specific testing obligations before market placement.

• EU AI Act — Article 16: Obligations of Providers of High-Risk AI Systems ↗ — The twelve-category list of provider obligations, including quality management systems, conformity assessment, technical documentation, and post-market monitoring.

• EU AI Act — Article 26: Obligations of Deployers of High-Risk AI Systems ↗ — The deployer-specific requirements: instructions-compliant use, human oversight assignment, log retention, worker and individual notification, and FRIA obligations for public bodies.

• NIST AI Risk Management Framework (AI RMF 1.0) ↗ — The U.S. federal voluntary framework organizing AI risk management around four functions — GOVERN, MAP, MEASURE, MANAGE — with crosswalk mappings to EU and international standards available through the NIST AI Resource Center.