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.
Related resources from NHI Mgmt Group
- What is the difference between managing AI agents as users and as NHIs?
- What is the difference between controlling AI agents and controlling human users?
- What is the difference between governing AI agents as users and governing them as non-human identities?
- What is the difference between Cross-App Access for AI agents and traditional SSO for human users?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
