Who Should Own AI Workflows in Your Company?

The instinct to assign AI workflow ownership to a single person or team is understandable. It mirrors how organisations handle other software tools: one team owns the CRM, one team owns the data warehouse. But AI workflow platforms are different in a way that makes single-owner models fragile.

An AI workflow platform sits at the intersection of technical infrastructure, business process design, and day-to-day operational execution. The person who should decide which AI providers to connect is not necessarily the person who should design the workflow logic, and neither of them is necessarily the person who should be running workflow instances against live customer data. Conflating these responsibilities creates two failure modes:

• The bottleneck failure: a single owner becomes a dependency for every change, every new workflow, and every operational question. AI adoption stalls because the owner cannot keep up.
• The governance failure: responsibilities are distributed without structure, so nobody knows who approved a workflow, who can modify it, or who is accountable when something goes wrong.

The solution is to decompose AI workflow ownership into its component responsibilities and assign each one deliberately. In DAVE, this decomposition is built into the platform's role model. The six default tenant roles, Admin, Create, Curate, Use, Reporting, and Financial, map directly onto the distinct ownership responsibilities that a well-governed AI workflow operation requires. Roles are editable, so these defaults are a starting point rather than a constraint: your organisation can adapt them as responsibilities evolve.

Here is how each of DAVE's six default roles maps to a distinct ownership responsibility, and who in a typical organisation should hold it.

Admin: platform and governance ownership. The Admin role carries full tenant administration access. Admin users control who has access to the platform, what roles they hold, which AI providers are connected, and how compliance and security settings are configured. This is not a role for the person who builds the most workflows: it is a role for the person accountable for the platform's security posture and operational integrity. In most organisations this is an IT lead, a platform engineer, or a head of operations with security accountability. The Admin role should be held by the smallest number of people who need it: typically two or three, to avoid a single point of failure without creating an ungoverned pool of administrators.

Create: agent ownership. The Create role grants the ability to create and edit agents. Agents are the AI-powered components that do the actual work inside a workflow: they hold the prompts, the provider connections, and the behavioural logic. Agent ownership belongs to the people who understand both the AI capability being deployed and the business problem it is solving. In practice this is often a technical product manager, an AI engineer, or a senior analyst who works closely with the AI provider configuration. Create role holders do not need to build the workflows that use their agents: that is the Curate role's responsibility.

Curate: workflow design ownership. The Curate role grants the ability to build and modify workflows. Workflow designers assemble agents, routing logic, human review steps, and API calls into coherent processes. This is a process design role as much as a technical one: the best workflow designers understand the business process they are automating, not just the platform mechanics. In many organisations this role belongs to business analysts, operations leads, or product managers who are close to the process being automated. Curate role holders can read agent configurations but cannot modify them, which is the correct separation: workflow designers should be able to use agents without being able to change their underlying behaviour.

Use: operational execution ownership. The Use role grants the ability to run workflow instances and complete assigned tasks. This is the operational layer: the people who use AI workflows as part of their daily work. Use role holders are not building or configuring anything: they are executing processes that have been designed and approved by Curate role holders. In a customer support context, this might be the support team. In a content operation, it might be the editorial team. The Use role is typically the most widely distributed role in a DAVE tenant, held by everyone who interacts with AI workflows as an end user.

Reporting: oversight ownership. The Reporting role grants access to reports and audit logs. This is the oversight function: the people who need visibility into what the AI workflows are doing, how they are performing, and whether anything looks anomalous. In a compliance-conscious organisation, this role belongs to a compliance officer, a data protection officer, or a senior manager who needs operational visibility without needing to build or run workflows. The Reporting role is read-only by design: oversight does not require the ability to change what is being overseen.

Financial: commercial oversight. The Financial role covers commercial and financial oversight of the tenant. The specific permissions for this role are not detailed in the current help documentation: see the gap note at the end of this article.

In organisations that are new to AI workflow platforms, the Admin role tends to accumulate responsibilities it was not designed to hold. The Admin sets up the platform, so the Admin also builds the first agents. The Admin builds the first agents, so the Admin also designs the first workflows. The Admin designs the first workflows, so the Admin also runs the first instances. Within a few weeks, the Admin is the single point of failure for the entire AI operation.

This pattern is understandable in early adoption but becomes a structural problem as usage grows. The Admin role is designed for governance, not production. An Admin who is also the primary workflow builder cannot objectively review the workflows they built. An Admin who also runs workflow instances has no separation between the person who configured the system and the person who operates it. These separations exist in DAVE's role model for the same reason they exist in financial controls and software deployment pipelines: the person who builds a thing should not be the only person who can check it.

The practical fix is to assign roles to the right people before workflows go into production, not after. In DAVE, user management is handled at Admin, then User Management. An Admin can create user accounts, assign one or more roles to each user, and update role assignments as responsibilities evolve. Role changes take effect on the user's next login. The minimum necessary roles principle applies: give each person only the roles they need for their specific responsibility. A workflow designer does not need the Create role. A reporting analyst does not need the Use role. A platform administrator does not need to be the person who runs workflow instances.

Multiple roles can be assigned to a single user where responsibilities genuinely overlap. A senior AI engineer who both builds agents and designs workflows can hold both Create and Curate. A small team in early adoption might have one person holding Create, Curate, and Use while the operation is getting started. The role model is a tool for governance, not a rigid org chart: use it to reflect actual responsibilities, and revise it as the team grows.

One of the most useful ways to think about AI workflow ownership is through the lens of governance checkpoints: the moments in a workflow's lifecycle where a human decision is required before the process continues. These checkpoints are not just a safety mechanism: they are ownership moments, points where a specific person or role is accountable for what happens next.

DAVE's workflow node types include Human Review and User Interaction nodes, which are designed to insert these checkpoints into an automated process. A Human Review node pauses a workflow instance and requires a designated reviewer to approve, reject, or modify the output before the workflow continues. A User Interaction node collects input from a user before proceeding. Both node types create an explicit record of who made the decision and when.

From an ownership perspective, governance checkpoints clarify accountability in a way that fully automated workflows cannot. When a workflow produces an output that a customer or regulator questions, the question is not just what the AI did: it is who reviewed it and approved it. A workflow with Human Review nodes has a clear answer. A workflow without them does not.

The practical implication for ownership design is that the people who hold the Use role, the operational execution owners, are also the people who hold the Human Review responsibility. They are not passive consumers of AI output: they are active participants in the governance of the process. Designing workflows with this in mind, identifying which steps require human judgment and assigning the right Use role holders to those steps, is one of the most important decisions a Curate role holder makes when building a workflow.

The right ownership model for a team that is deploying its first AI workflow is different from the right model for a team running twenty workflows across three business units. Here is how ownership responsibilities typically evolve as AI workflow maturity increases.

Stage 1: Exploration (one to three workflows, small team). At this stage, one or two people hold most of the roles. The person who sets up the platform (Admin) is often also the person who builds the first agents (Create) and the first workflows (Curate). This is acceptable as a starting point, but the team should document which responsibilities belong to which role even if one person currently holds all of them. When the second person joins the AI workflow operation, the role assignments should split along the documented lines, not be duplicated wholesale.

Stage 2: Scaling (four to fifteen workflows, dedicated team). At this stage, role separation becomes operationally necessary. The Admin should be a dedicated platform owner, not a workflow builder. Agent creation should be owned by the people closest to the AI capability being deployed. Workflow design should be owned by the people closest to the business process being automated. Operational execution should be distributed to the teams who use the workflows. Reporting access should be granted to whoever is accountable for oversight. In DAVE, this means revisiting user role assignments at Admin, then User Management and ensuring each person's roles match their current responsibilities, not their responsibilities from Stage 1.

Stage 3: Governance (fifteen-plus workflows, cross-functional use). At this stage, the ownership model needs to be formalised beyond role assignments. Who approves a new workflow before it goes into production? Who reviews agent configurations when an AI provider changes its model behaviour? Who is notified when a Human Review step is consistently overridden by operators? These questions require documented processes, not just platform permissions. The role model in DAVE provides the technical enforcement layer: the Admin controls who can do what. The governance layer above it, the policies and review processes, is the organisation's responsibility to define. The platform enforces the permissions; the team enforces the policies.