Insight · Platform & governance
From pilot to governed production
Most AI pilots don't stall in the model — they stall at the review board. This is the landing zone a first Digital Worker needs before it touches production data, and the question each component answers.
The pilot plateau
The pattern repeats across health, government and regulated enterprise: a pilot works, the demo lands, everyone agrees it should go to production — and then it doesn't. Not because the model degraded, but because production asks questions the pilot was never built to answer. Who approved this output? What data did it read, under whose authority? How do we know it still performs the way it did at evaluation? Who do we call when it's wrong?
Pilots are built to prove capability. Production systems in regulated environments are built to survive scrutiny. The gap between the two is not more prompt engineering — it is a platform layer, and the organisations that cross the plateau are the ones that build it once, deliberately, before the first worker deploys.
The practice calls this layer the landing zone, borrowing the cloud term deliberately: the governed environment workloads deploy onto, so that each one inherits its controls instead of reinventing them. A Digital Worker without a landing zone is a chatbot with production credentials.
The seven components
Seven components, each earning its place by answering a question a review board will actually ask. Skip one and the question doesn't go away — it just arrives without an answer, usually late in the approval cycle.
01 · LLM GATEWAY
One controlled door to every model
All model traffic — every provider, every worker — routes through a single gateway that enforces authentication, rate limits, cost attribution and data-handling policy. No team calls a model API directly; no prompt leaves the boundary unlogged. Model providers become swappable behind the gateway rather than embedded in every workload.
"What AI is running in this organisation, and how would we turn one model off?"
02 · GUARDRAILS
Boundaries enforced in the platform, not the prompt
Input and output controls that run outside the model: PII and secret detection, topic and scope boundaries, injection screening, format validation. A scope of work is a promise; guardrails are the mechanism that keeps the promise when the input is adversarial, malformed or simply unexpected. Asking the model to police itself is not a control.
"What stops this system doing something outside its mandate?"
03 · EVALUATION HARNESS
Evidence that it works, produced before it runs
Golden datasets that encode what "done well" measures as, red-team suites for the failure modes that matter, and regression gates in CI/CD so nothing ships that scores worse than what it replaces. Evaluation evidence is a deliverable, not a promise — it is what the review board approves, and the baseline drift is measured against later.
"How do you know it works — and how will you know it still works after the next change?"
04 · OBSERVABILITY & TRACING
Every output traceable to its inputs
Full tracing from output back through the rule that fired, the evidence read and the calculation made — plus operational telemetry: latency, cost, error and escalation rates, and drift monitoring against the evaluation baseline. When behaviour shifts, the platform surfaces it before a stakeholder does.
"When it produced that answer, can you show me exactly why?"
05 · HUMAN-IN-THE-LOOP CONTROLS
Autonomy graduated to risk, in the workflow
Review queues, confidence thresholds, and sign-off gates for consequential outputs — built as platform primitives, not bolted onto each worker. High-stakes decisions carry named human sign-off: a Digital Worker escalates; it does not decide. The controls make the escalation boundary operational instead of aspirational.
"Where exactly does a person come into this, and can we prove they did?"
06 · NON-HUMAN IDENTITY & ACCESS
The worker is a privileged identity — govern it like one
Each Digital Worker gets its own identity with least-privilege, policy-based access to the systems its scope of work requires — nothing more, revocable in one place, with every data access audited. The same discipline applied to a privileged human hire: credentials, entitlements, joiner-mover-leaver. Shared service accounts with broad grants are how pilots leak into production unnoticed.
"What can this thing actually reach, and who approved that?"
07 · DECISION CAPTURE & AUDIT TRAIL
The record that outlives the conversation
An immutable, retention-governed record of what the worker did, saw, decided and escalated — designed for the auditor who arrives in three years, not the developer debugging today. In regulated settings this is the component that converts operation into accumulating compliance evidence, instead of a liability nobody can reconstruct.
"Show us what it did last March."
The build order
Organisations rarely need all seven at equal depth on day one — but the order matters, because retrofitting is where programs bleed time:
- Gateway and identity first (01, 06) — the choke points. Retrofitting either means re-plumbing every workload built without them.
- Evaluation and decision capture before the first worker ships (03, 07) — evidence can't be generated retrospectively; there is no back-dating an audit trail.
- Guardrails, tracing and human-in-the-loop harden with the first real workload (02, 04, 05) — they need production traffic to be tuned against, which is one reason the first workload should be a forgiving one.
Built this way, the landing zone is a fixed cost the first worker carries and every subsequent worker inherits — each one deploys faster and cheaper onto platform, rails and governance that already exist. Five workers built ad hoc are five bespoke risks; five on one landing zone are a workforce.
The regulatory read
None of this is speculative compliance. The components map directly onto what Australian frameworks already ask for: the Voluntary AI Safety Standard's guardrails on testing, transparency, human oversight and record-keeping; the Australian Government AI Ethics Principles on accountability and contestability; and, where software approaches a medical-device boundary, the TGA's expectations of traceability and post-market monitoring. A landing zone doesn't guarantee approval — it means the review board's questions have answers that were designed in, not written the week before the meeting.
Where this architecture comes from
This is the architecture the practice builds in AI Platform & Governance Architecture engagements, on frameworks adopted as standard at a national health agency — and it is the environment the practice's own workers run in on remediant.ai: decision capture, drift monitoring and full audit trails, operational in production.