What is the difference between regulating AI makers and regulating AI users?

Regulating AI makers focuses on the companies building or offering the model, while regulating AI users targets the organisations deploying it in real business processes. The difference matters because some laws require the vendor to meet obligations, but others impose duties on the employer or customer, such as audits, disclosures, or risk controls for specific use cases.

Who the rule is aimed at changes the control surface

AI makers are the parties creating, tuning, packaging, or operating the model service, so regulation there tends to focus on design-time and platform obligations such as safety testing, documentation, provenance, and systemic safeguards. ai users are the organisations putting the system into a business workflow, so the regulatory emphasis shifts to deployment choices, oversight, and whether the use case itself is controlled appropriately.

That split matters because the same model can be low-risk in one setting and high-impact in another. A vendor may ship a generally capable system, but the user can still create the real compliance exposure by deciding what data it sees, what decisions it influences, and whether humans can review or override outputs.

When the user side is the regulatory target, the practical question is less “who built the model?” and more “who is accountable for how it was used in production?” That distinction is why audit trails, disclosures, approval gates, and use-case restrictions often sit with the deploying organisation even when the model comes from a third party.

How maker regulation and user regulation differ in practice

Maker-focused rules usually address the upstream risk of unsafe capability entering the market. They can require model evaluation, transparency about training or limitations, incident reporting, and controls on release or distribution. The goal is to reduce harm at source before the system is widely embedded in other organisations’ processes.

User-focused rules usually govern downstream operation. They ask whether the deploying organisation has selected an appropriate use case, protected the inputs and outputs, and monitored the system after go-live. In practice, this is where policy turns into operational control, because deployment context determines whether the model is making recommendations, automating actions, or handling regulated data.

A useful way to think about the difference is supply versus use. Maker obligations are about what is brought to market; user obligations are about what is done with it. In regulated sectors, both can exist at the same time, and the same control may be split across parties, such as the maker providing documentation while the user performs impact assessment and internal approval.

Why the boundary matters for accountability and governance

The boundary changes who must prove compliance when something goes wrong. If the legal duty sits with the maker, regulators will look first at the provider’s testing, disclosures, and model governance. If the duty sits with the user, they will look at procurement, implementation, data handling, approval workflows, and the operational decisions that turned a general-purpose system into a business control.

That is why cross-functional ownership is essential. Legal, procurement, security, risk, and business owners may each hold a piece of the answer, but the organisation deploying the system should be able to show which party owns each obligation, which evidence exists, and which use cases are explicitly allowed or prohibited.

For teams assessing vendor tools, the key is to separate contract language from operational reality. A vendor promise does not remove the deploying organisation’s duty to validate outputs, constrain access, or document the actual business purpose. Conversely, a strict internal policy cannot compensate for a provider that fails to supply the information needed to use the system safely.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST AI RMF and NIST SP 800-63 set the technical controls, while ISO/IEC 42001:2023 and EU AI Act define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.OV-01 — Organizational Context and Responsibilities	Clarifies who owns AI obligations across maker and user roles.
Recommendation — Assign accountability for AI governance across vendors and deployment owners.
NIST AI RMF	GOVERN — Govern AI Risk	AI governance directly covers role separation, accountability, and deployment oversight.
Recommendation — Define maker and user responsibilities in your AI risk governance program.
ISO/IEC 42001:2023	4.2 — Understanding the needs and expectations of interested parties	Supports deciding whose obligations apply to an AI system in context.
Recommendation — Map legal and stakeholder obligations to the party operating each AI use case.
EU AI Act	Article 25 — Responsibilities along the AI value chain	Directly distinguishes upstream provider duties from downstream deployer duties.
Recommendation — Allocate compliance tasks between providers and deployers by role.
NIST SP 800-63	1.1 — Digital Identity Models and Assertions	Useful where deployment accountability depends on authenticated access and assurance in AI workflows.
Recommendation — Use strong identity assurance for approvals and high-impact AI workflow access.

Practitioner Guidance

What to prioritise: Classify every AI use case by obligation owner first, then map controls to the maker, the deployer, or both. If the law or contract is unclear, treat the deployment organisation as accountable for the business process until ownership is explicitly assigned.

What to verify: Confirm who can change the model, who can expose it to new data, who can approve a new use case, and who must retain evidence of review, testing, and user-facing disclosures. If those answers live only in procurement language, the control is not yet operationalised.

Practitioner takeaway: The governance error is assuming that “third-party AI” means “third-party responsibility”; in most real deployments, the maker may supply the system, but the user still owns the risk created by how it is embedded in the business.