Which control model fits organisations that both build and deploy AI systems?

They need a system-level control model, not an organisation-level label. Each AI system should be assessed separately for provider and deployer duties, with distinct ownership, evidence, and incident handling paths. That approach avoids the common mistake of applying one compliance template across very different obligations.

Why Dual-Role AI Organisations Need a System-Level Model

Organisations that both build and deploy AI systems sit in two different accountability positions at once. As a provider, they influence model design, training data, documentation, testing, and release criteria. As a deployer, they decide how the system is used, monitored, constrained, and governed in context. NIST’s AI management guidance and the EU AI Act both reflect that split, even if they use different terminology and legal scope. For readers comparing control models, the key point is that a single organisation label does not answer the control question by itself.

That distinction matters because the same AI system can create different obligations depending on whether the organisation is shipping it, operating it, or both. If teams collapse those duties into one internal template, they often miss ownership boundaries, evidence expectations, and escalation paths that are specific to each role. In practice, many organisations discover those gaps only after a review, incident, or regulatory challenge has already forced them to separate the system lifecycle from the corporate org chart.

How the Control Model Works Across Build and Deploy Roles

The right model is to govern each AI system as a distinct unit, then assign provider and deployer responsibilities to the parts of the lifecycle that actually own them. That means one model may be shared by both roles internally, but the control evidence must still be separable. The build side should show how the system was designed, evaluated, documented, and approved for release. The deploy side should show how the organisation selected use cases, set operating constraints, monitored outcomes, and handled incidents after go-live.

This is why the answer is usually not “choose one label for the whole enterprise.” A dual-role organisation needs a system-level control model that can express both sets of duties without merging them. If the same team owns both sides, the records still need to show where development controls stop and operational controls begin. That separation helps with auditability, incident review, and internal accountability, especially when the model is updated, repurposed, or integrated into a workflow that changes the risk profile.

Provider duties typically cover design decisions, evaluation, documentation, release criteria, and technical change control.
Deployer duties typically cover use-case approval, monitoring, user constraints, post-deployment review, and incident response.
Shared governance should record ownership, evidence, and decision points for each AI system rather than for the organisation as a whole.

For organisations operating across both roles, NIST AI RMF provides a practical governance lens, while the EU AI Act gives a sharper role-based compliance distinction for relevant use cases. The most useful approach is to map controls to the system lifecycle and then test whether each role can prove what it is responsible for without relying on the other role’s records. This guidance breaks down when an organisation cannot distinguish model development from downstream operation, because then neither ownership nor evidence can be assigned cleanly.

Where the Model Breaks Down: Reuse, Outsourcing, and Role Drift

Tighter role separation often increases coordination overhead, requiring organisations to balance clearer accountability against slower shared decision-making.

That tradeoff becomes visible when a system is reused in multiple products, handed to a managed service provider, or deployed in a context that changes its impact. In those cases, the original provider controls may remain necessary, but they are no longer sufficient on their own. Guidance versus consensus is also important here: there is broad agreement that role-based accountability is needed, but the exact internal control structure varies by sector, jurisdiction, and assurance model.

One common edge case is a company that builds a foundation model, then wraps it in a business application and operates the application for customers. Another is a team that fine-tunes or configures a third-party model enough that it should be treated as a deployer for the resulting system. In both cases, the control model should follow the actual responsibility split, not the procurement label or the product team’s preferred description. That also means changes in data, prompts, tooling, or downstream integration can shift governance obligations even if the model name stays the same.

For organisations that also manage non-human identities in the AI stack, the ownership boundary should include service credentials, tool access, and automation accounts used by the system. The control model is not just about policy language; it is about proving who can change the system, who can run it, and who must respond when it misbehaves. The model fails when those operational boundaries are assumed rather than documented.

Standards & Framework Alignment

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

NIST AI RMF, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while EU AI Act and ISO/IEC 42001:2023 define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST AI RMF	GOVERN — Govern	Covers system-level AI governance and accountability across lifecycle roles.
Recommendation — Map each AI system to explicit governance owners for provider and deployer responsibilities.
EU AI Act	Article 3 — Definitions	Defines provider and deployer roles that split obligations for dual-role organisations.
Recommendation — Classify each AI system by role and apply the matching obligations to that system.
ISO/IEC 42001:2023	4.1 — Understanding the organization and its context	Fits organisational AI governance where provider and deployer duties must be managed systematically.
Recommendation — Assign AI governance controls to each system and keep accountability separate from the enterprise label.
NIST CSF 2.0	GV.OV-01 — Oversight	Supports oversight of AI systems with separate accountability and evidence paths.
Recommendation — Establish oversight that distinguishes build-time responsibilities from live operating duties.
CIS Controls v8	CIS Control 5 — Account Management	Relevant where AI operations depend on distinct service accounts, tool access, and ownership.
Recommendation — Track and separate accounts that create, deploy, and operate AI systems.

Practitioner Guidance

What to prioritise: Build the control model around each AI system’s lifecycle, not around a single enterprise-wide label. If an organisation both builds and deploys, it should be able to answer two separate questions for every system: who is accountable for release decisions, and who is accountable for live operation.

What to verify: Check that ownership, evidence, and incident handling are split by role in a way that survives audit. If the same record set is being reused for both provider and deployer duties, the organisation probably has a governance gap rather than a control model.

Practitioner takeaway: Dual-role organisations do best when they treat AI governance as a system-by-system accountability map, because that is what exposes where obligations diverge and where internal process is still too generic.