The framework
The Governed AI Operating Model
A vendor-neutral way to decide how AI runs in your enterprise — before it runs without you. Four pillars, one reference architecture, and an operating loop you can adopt as principles or run as software.
Without a model
- Every team invents its own AI rules
- Agents call whatever APIs they can reach
- No record of why the AI did what it did
- Models swap silently behind the scenes
- "Who owns this?" has no answer
With the model
- One operating model every team runs
- Tools are allow-listed; risky actions are gated
- Every decision is logged and exportable
- Models are named, versioned, and traceable
- Accountability is built into the boundary
The four pillars
Each pillar is a principle you can prove
A pillar isn't a slogan — it's a control that produces evidence. Here's the principle behind each, what it actually governs, and the artifact it leaves behind.
Govern
Nothing executes by default.
What it controls
Every tool and API an agent can reach is explicitly allow-listed. High-stakes actions wait behind human approval gates. Spend is capped per workflow so a runaway agent can’t run up a bill.
The evidence it produces
A policy record for every action: what was allowed, by which rule, within which limits.
Isolate
The tenant is the unit of trust.
What it controls
Each team or customer runs in a dedicated tenant with its own subdomain, data, keys, and runtime — encrypted at rest and in transit, scoped by role-based access. No shared state to leak across.
The evidence it produces
A clean tenant boundary you can point to: dedicated data, keys, and runtime per customer.
Audit
If it isn’t audited, it didn’t happen.
What it controls
Every decision an agent makes is written to an immutable log — the action, the policy that permitted it, and the human who approved it. The trail is exportable, not reconstructed after the fact.
The evidence it produces
A regulator-ready export: who did what, when, under which policy, with approvals attached.
Attribute
No shadow routing.
What it controls
Models are named and versioned — never silently swapped. Assists are immutable and rollback-able. Every output traces back to the exact logic, version, and inputs that produced it.
The evidence it produces
A straight line from any result to the named model and Assist version that generated it.
Reference architecture
The pillars, expressed as layers
The model maps onto five layers. Every request flows top to bottom — governed, isolated, and audited at each boundary before it ever reaches your data.
Channel Layer
Slack, Teams, Web, API
Slack, Teams, Web, API
Control Plane
Auth, Policy, Routing
Auth, Policy, Routing
Runtime
Assist Execution Engine
Assist Execution Engine
Tool Perimeter
MCP-gated tool access
MCP-gated tool access
Data Plane
Encrypted, isolated storage
Encrypted, isolated storage
The operating loop
How you adopt the model
Establish boundaries
Stand up an isolated tenant with dedicated data, credentials, and runtime. The tenant boundary is the foundation every other control builds on.
Set policy gates
Declare which tools each Assist can reach, define approval gates and spend caps, and scope team access. Policy is versioned and changeable in seconds.
Deploy & audit
Ship the Assist to where your team works. Every action is governed at runtime and written to an immutable trail you can review or export.
Review & tighten
Read the trail, see where gates fired, and tune policy. The model is a loop, not a launch — controls get sharper as you learn how AI is actually used.
Run the model without building it
Drsti Studio is the reference implementation — the four pillars shipped as software, so you adopt the operating model instead of standing up an AI platform team to recreate it.