Build Governed AI Roles Your Operators Can Run
We turn an approved workflow specification into a production system with bounded access, durable context, auditable outputs, human approvals, cost controls and an operating runbook. A governed AI role is what we build; Virtual Employee is what we call it internally.
- A governed AI role is an AI system embedded in one documented workflow, with a defined boundary, durable context, written approval rules, a queryable audit trail, a cost ceiling and a named human owner. Reliable Group brands these Virtual Employees.
- Five fit criteria decide whether we build: stable workflow, accessible data, measurable output, named owner and an approved risk posture. Four non-fit conditions mean we decline rather than ship a pilot.
- The control framework is published as a matrix on this page: control, owner, evidence and failure response. Not a narrative about lessons learned.
- Testing, acceptance criteria, monitoring, fallback and post-launch ownership are all defined before launch, and acceptance is your call rather than ours.
- Commercially, the unit depends on the workflow. Unit-of-work pricing fits some builds and is wrong for others, and this page says which.
What Has to Be True Before We Build
Five conditions on the left, four disqualifiers on the right. We check these on the first call, and roughly a third of the workflows we are asked about fail one of them, which is a better outcome than discovering it in month three.
We can build when
- The workflow is stable. It has run the same way long enough to be documented, and it is not mid-redesign.
- The data is accessible. The systems the role must read and write are reachable through a service identity your IT team can issue and revoke.
- The output is measurable. There is a test for a correct result that does not require someone to interpret it.
- There is a named human owner inside your company who owns the output and is the escalation point.
- The risk posture is approved. Someone with authority has agreed what the role may complete alone and what needs review first.
We decline, for now, when
- Policy is unresolved. If the rule is not written down or people disagree on it, there is nothing to build against.
- Decision rights are unbounded. A role that is expected to decide anything within a domain cannot have a boundary, and without a boundary there is no control.
- Data access is insufficient. Screen-scraping a system nobody will grant API access to is a dependency, not an architecture.
- No accountable human owner exists. This is the one we hold hardest, because an unowned AI role is the first finding in any audit.
When a workflow fails a criterion, the useful answer is usually a short piece of work that fixes the gap, not a smaller version of the build. We will tell you which one it is.
Where a Governed AI Role Sits
A production AI system is mostly not the model. It is the boundary around it: what identity it holds, what it may write, what it remembers, and where the work goes when it is unsure.
Humans
Layer 1Judgment, exceptions, relationships, escalations
A named owner for every governed AI role, and the approval authority for anything the role is not permitted to decide alone.
Governed AI roles
Layer 2Repeatable workflows with a defined start, end and success test
Bounded scope, durable context, logged inputs and outputs, a cost ceiling and a rollback path. Branded internally as Virtual Employees.
Automation layer
Layer 3Identity, permissions, data contracts, retries, exception routing
Where a workflow becomes an operation. Least-privilege service identities, idempotent writes, and a defined path for every failure mode.
Systems of record
Layer 4ERP, EHR, CRM, billing, ticketing, payroll, data warehouse
Your systems, your tenancy. The operating layer reads and writes through them rather than replacing them.
The Parts, for Reviewers Who Want Them
Expanded detail for security, platform and compliance reviewers. All of it is in the page source whether or not you open it.
Context and memory architecture
Each role has a defined store rather than a conversation history: a canonical record of what it is allowed to remember, explicit retrieval rules for what it loads per task, and explicit update rules for what a completed task writes back.
Retention follows your policy, not ours, and the store sits inside your data boundary. What the role may not retain is written down as plainly as what it may, because in regulated functions the second list is the one that gets reviewed.
Identity, permissions and secrets
Every role runs under its own service identity, issued by your IT team and revocable without touching anything else. Never a human user’s credentials, and never a shared account across roles, because both destroy attribution in the audit trail.
Permissions are scoped to the specific objects and actions the workflow needs. Secrets live in your secret manager. Environments are separated, and no production credential is reachable from a development environment.
Determinism, retries and idempotency
Any write to a system of record is idempotent and carries an operation key, so a retried step cannot post the same entry twice. This is the failure that costs the most to unwind after the fact, and it is cheap to design for up front.
Steps that must not repeat are guarded by state in your systems rather than by the role remembering it already did them.
Model choice and change control
Model selection is per workflow, on accuracy against your own test set, latency, cost and where the data may be processed. We do not standardise on one model across every role, and we will tell you when a smaller model is the right answer.
Role versions are pinned. A model or prompt change is a versioned release with the acceptance suite re-run against it, and the version is recorded on every log entry so an output can always be traced to the exact configuration that produced it.
Security documentation and how to verify it
We publish reviewable security architecture and data-handling documentation rather than certification badges. The architecture, the data-handling detail and the current limits are published in the Trust Center, which is also where the document-request route lives for anything your security team needs that is not public.
Control design for a specific regulated workload is scoped per engagement with your compliance team, and the resulting control set is written into the role specification rather than agreed verbally.
The Virtual Employee Build, Step by Step
Specification in, production system out. The gate at step one is the one that protects everything after it.
Specification lock
We start from the role specification, either from an org-chart design engagement or one you arrive with. We pressure-test scope, approval rules, escalation paths and accountability. Spec lock is a gate: no build starts until your operators agree the spec describes something they can be accountable for.
Context architecture
We design the memory store, retrieval rules and update rules inside your data boundary, and select the model stack and orchestration for this specific workflow. This is where most AI projects break quietly, so it happens before any workflow logic is written.
Governance wire-up
Approval workflows mapped to your actual org chart, audit trails written to your logging infrastructure, role-based access under a dedicated service identity, and escalation routing to the named owner. Built before the role does any real work, not after a reviewer asks.
Build and acceptance testing
The role is built against the spec and run through an acceptance suite on synthetic and historical workloads, including the adversarial cases. Every output logged, every decision traceable, every exception reproducible from the log alone.
Shadow run
The role runs on live volume in parallel with the existing process, producing output that goes to review rather than downstream. Usually two to four weeks. This is where the acceptance thresholds are proved on real data rather than a test set.
Production cutover and handover
Cutover on your decision, with the runbook, the monitoring, the fallback procedure and the named on-call owner all in place first. We hand over an operation your team runs, not a pilot they supervise.
Controls, Owners, Evidence and Failure Response
This table replaces the narrative about lessons learned that used to sit here. Same knowledge, in the form a security reviewer or an internal auditor can actually work from. AI agent governance is a documentation problem more than a modelling one.
| Control | Owner | Evidence | Failure response |
|---|---|---|---|
| Scope boundary | Client function owner | Role specification, versioned, with the boundary stated as in-scope and explicitly out-of-scope actions | Out-of-boundary request is refused and logged as an exception to the named owner. It is not attempted. |
| Access and identity | Client IT or security | Service identity record, permission scope, quarterly access review | Identity revoked by your team without our involvement. The role stops; the workflow reverts to the fallback process. |
| Approval path | Client function owner | Approval rules in the spec, plus a per-output review record in the audit log | No approver available means the output holds in a queue. It does not release on a timeout. |
| Output accuracy | Reliable Group, jointly with the function owner | Acceptance-suite results, shadow-run comparison, ongoing sampled review at the agreed rate | Accuracy below the agreed floor moves the role back to shadow mode. The decision to resume is yours. |
| Audit trail | Client compliance | Per-event log with inputs, model calls, outputs, policy checks and human decisions, queryable directly | A logging failure stops the role. We do not run production work that cannot be evidenced afterwards. |
| Compute cost | Reliable Group, with a client-approved ceiling | Per-event cost recorded on the log, month-to-date against ceiling | Alert at the threshold, hard stop at the ceiling. The workflow reverts to fallback rather than overrunning the budget. |
| Change control | Reliable Group | Versioned releases, acceptance suite re-run, role version stamped on every log entry | A failed acceptance run blocks the release. The previous version keeps running. |
| Incident ownership | Named on both sides before launch | Runbook with severity definitions, contacts and the rollback procedure | Rollback to the previous process, triggered by your named owner without needing our approval. |
Every row has an owner, and most of them are yours. That is the design: a control we own on your behalf is a dependency, and dependencies are what this whole model exists to avoid.
How We Prove It Works, and Who Decides
Acceptance is your decision against thresholds agreed in writing before the build. We do not get to declare our own work finished.
Acceptance criteria, agreed up front
Written into the specification before build: the accuracy floor on your own labelled sample, the maximum acceptable false-positive and false-negative rates for the workflow, throughput at expected and surge volume, and the review rate that applies once live. Numbers, agreed by the function owner, not adjectives.
The test sets
A synthetic set covering the documented happy path, a historical set drawn from your own past volume including the messy cases, and an adversarial set we build specifically to make the role fail. The adversarial set is where the useful findings come from.
Shadow run on live volume
Two to four weeks in parallel with the existing process, output to review rather than downstream. Every disagreement between the role and the current process is examined, and either the role or the acceptance threshold changes as a result.
Monitoring in production
Output volume and latency, sampled accuracy against the agreed review rate, exception-queue depth and age, compute spend against the ceiling, and drift in the input distribution. Alerts route to your named owner, not only to us.
Fallback
Every role ships with a tested path back to the previous process, and it is tested during the build rather than described. The fallback is triggerable by your named owner without escalation to us, and we will not launch a role whose fallback has not been exercised at least once.
Post-launch ownership
Your named owner owns the output and the decision to run or stop. We own the role’s technical behaviour, its releases and its monitoring for the agreed support period. Both are written into the runbook, including who is called at what hour and what counts as an incident.
What the Audit Trail Actually Looks Like
One event, with synthetic values. Auditability is easy to claim on a service page, so here is the shape of the record a role produces.
{
"event_id": "evt_8f2c41",
"workflow": "claim_eligibility_check",
"role_version": "2.4.1",
"triggered_by": "scheduler:queue_intake",
"subject_ref": "clm_SYNTHETIC_00184",
"model_calls": [
{ "step": "extract_coverage_fields", "tokens_in": 1842, "tokens_out": 96 },
{ "step": "compare_to_payer_rules", "tokens_in": 2310, "tokens_out": 148 }
],
"output": { "determination": "eligible", "confidence": 0.94 },
"policy_checks": [
{ "rule": "confidence_floor_0.85", "result": "pass" },
{ "rule": "dollar_threshold_review", "result": "not_applicable" }
],
"human_review": {
"required": false,
"reason": "below_review_threshold",
"sampled": true,
"reviewer": "a.sharma@client.example",
"decision": "agree",
"reviewed_at": "2026-07-14T09:22:11Z"
},
"cost_usd": 0.0071,
"budget_state": { "month_to_date_pct": 41.6, "ceiling_action": "none" }
}Synthetic data. No client record appears above. The parts that matter to a reviewer are the ones people usually leave out: the pinned role version, the policy checks with their results, whether human review was required or sampled and who performed it, the per-event cost, and the budget state at the time of the call. An audit trail that records only the input and the output cannot answer the questions an auditor asks.
How This Is Priced, and When Unit-of-Work Is Wrong
Governed AI roles are not headcount, so we do not price them on a per-seat rate card the way an offshore staffing contract prices humans. Beyond that, the pricing model depends on the workflow, and this page used to imply otherwise.
Unit-of-work pricing fits when the workflow produces a countable unit at predictable volume: a coded claim, a triaged case, a reviewed pull request. You pay for output rather than for compute idling overnight, and your CFO models it alongside other variable operating costs.
Unit-of-work pricing is the wrong model when the unit is not countable or the volume is not predictable. A monitoring role that produces value by finding nothing most days has no natural unit. A build with heavy validation obligations, as in pharmacovigilance, carries cost that is not proportional to volume at all. Low-volume, high-consequence workflows price better on a fixed build fee plus a support retainer, and pretending otherwise just moves risk onto whoever guessed the volume.
In every case, the build fee and the ongoing model are quoted per workflow after the fit assessment, with the compute ceiling stated separately so it is visible rather than buried in a blended rate. Per-seat pricing covers Lever 2, the team that runs the operation alongside the roles, and that is a separate line in the operating model. We are precise about which is which.
The Same Seven Requirements, Applied to Your Workflow
The gate that governs what we build. It is the same list on the AI-Native Operations page, and the same list we hold our own workflows to.
Defined scope
The workflow has a documented start, a documented end and a success test that does not need interpretation.
If it is missing: Not buildable yet. Scope work comes first, in the design engagement or the Blueprint.
Data access
The role can reach the systems and records it needs through a service identity your IT team issued and can revoke.
If it is missing: Blocked. We do not route around access controls or run production work on a human user’s credentials.
Named human owner
One person inside your company owns the output and is the escalation point. Not a committee, and not us.
If it is missing: Not deployable. An unowned AI role is the finding an auditor writes up first.
Approval rules
Written rules for what the role may complete alone, what needs review before it leaves the function, and the sampling rate for the rest.
If it is missing: Runs in shadow mode only, producing output for review with nothing released downstream.
Auditability
Inputs, model calls, outputs and human decisions are logged where your compliance team can query them without asking us.
If it is missing: Not eligible for regulated workflows.
Cost ceiling
A monthly compute budget per workflow, with an alert threshold and a hard stop, agreed before launch.
If it is missing: Not launched. An unbounded compute bill is an avoidable surprise, and we have had it.
Rollback procedure
A tested way to switch the workflow back to the previous process, and a named person who can trigger it.
If it is missing: Not launched. If it cannot be turned off safely, it is not in production, it is an experiment.
Seven for seven, and the workflow is a candidate. Anything less and we say so rather than shipping a pilot that will not survive an audit, a CFO question or a change of sponsor.
Related Services
AI-Native Org Chart Design
Produces the role specifications this service builds against, plus the org chart and unit economics around them.
Learn moreAutomation Layer Implementation
The integration layer between the roles we build and the systems of record they must read, update and escalate through.
Learn moreThe Blueprint
Both levers scoped together, so the roles you build land in an operation that can actually run them.
Learn moreBoth Levers Engaged
This is a Lever 1 service. The governed AI roles are the AI-native operating layer. They pair with GCC Setup and Talent Acquisition on Lever 2: the lean human team inside your own COPO or Flexi entity that runs the roles, makes the judgment calls and owns the exceptions.
The Blueprint scopes both levers in a single engagement.
Start with the Blueprint.
Three to five weeks. Paid engagement. Both levers scoped together.