Who should be allowed to build AI inside a company?
People should be allowed to build AI within a permissioned delivery system that matches data sensitivity and operational impact to explicit controls, evidence and accountable ownership.
Companies usually start with a false choice: let everyone build with AI or keep it inside a central technical team. One creates unmanaged risk; the other creates a queue. A workable model separates the right to propose, build, approve and operate.
Separate four different rights
- Propose
- Describe a problem, desired outcome and the business process that may change.
- Build
- Configure instructions, knowledge, tools and workflow logic inside an approved boundary.
- Approve
- Accept the residual risk for a specific data class and operational effect.
- Operate
- Run, monitor, pause and improve the workflow after it enters real work.
The same person can hold more than one right, but the rights should remain visible. A finance specialist may be the best person to build a reconciliation assistant while a system owner approves its access and an operations owner accepts responsibility for the live process.
Use risk tiers instead of job titles
| Tier | Typical work | Minimum controls |
|---|---|---|
| Explore | Synthetic or public data; no external action | Approved model, private workspace, no tools |
| Assist | Internal data; human reviews every output | Scoped knowledge, access policy, audit metadata |
| Act | Workflow can change records or contact people | Exact tools, approval gates, test evidence, rollback |
| Critical | Material legal, financial, safety or customer impact | Independent review, strict segregation, monitoring and incident ownership |
Make the common controls automatic
- Identity and workspace membership determine which data and tools are visible.
- Model access is allow-listed by exact deployment and data class.
- Tool execution is deny-by-default and limited to explicit actions.
- Approvals are required before higher-impact actions, publishing or production release.
- Audit records contain actors, policy decisions and hashes—not prompts, files or responses.
- Every production workflow has an owner, version, test result and immediate stop control.
What the first review should ask
- What business outcome and existing process will change?
- Which data can enter the workflow, and which data must never enter it?
- Which models, knowledge sources and tools are required?
- What can the system do without a person approving the step?
- How will quality, cost, latency and incidents be observed?
- Who can stop the workflow, and what happens to work already in progress?
Broad participation and strong governance are compatible when permissions, evidence and accountability live in the delivery path instead of a document people can route around.
Common questions
- Should only developers be allowed to build AI workflows?
- No. Domain specialists often understand the work best. The platform should let them build inside boundaries that match the data and impact, while technical and operational owners review the parts for which they are accountable.
- Does every AI workflow need human approval?
- Every production workflow needs accountable approval, but not every execution needs a human click. Runtime approval should be reserved for actions whose risk cannot be reduced enough through scope, policy, testing and reversibility.
- Who owns an internal AI workflow after launch?
- A named operational owner should own outcomes, monitoring, change decisions and the stop procedure. Platform teams own the shared controls; they should not silently become owners of every business process built on top.