Everything so far has been principle, operating model and discipline. This article is the blueprint. If governance is an architectural property, then somewhere there is an architecture that carries it, and the point of a reference architecture is that governance stops being something people do and becomes something the platform enforces whether they think about it or not.
What follows is a reference architecture for a governed AI platform, built in layers, with the control plane running through all of them. It is deliberately technology-neutral. Your cloud, your model provider and your tooling will differ. The layers and the controls they carry will not. Treat this as the pattern to instantiate, not the products to buy.
§ 7.1The governing idea: a control plane, not a checklist
A governed AI platform separates two things that ungoverned platforms tangle: the data and model plane, where AI work happens, and the control plane, which governs that work. Every model, every dataset, every inference passes through the control plane, which enforces registration, guardrails, evaluation, logging and monitoring as conditions of operation rather than as steps someone remembers.
The consequence is that governance is not something a team adds to a project. It is the environment the project runs inside. A model deployed to this platform is registered because the platform will not serve an unregistered model. It is monitored because monitoring is wired into serving. The safe path is the only path the platform offers.
Architectural thesis
Governance controls belong in a control plane that every model must traverse, not in a checklist every team must complete. The test of your architecture: can a team deploy a model that skips a required control? If yes, the control lives in a checklist. If no, it lives in the platform. Aim for no.
§ 7.2The layers
| Layer | Purpose | Governance carried |
|---|---|---|
| Data layer | Governed data access for training & inference | Lineage, quality, consent, residency enforcement (AG-05) |
| Model registry | System of record for every model | Owner, risk tier, validation status, version, approval gate |
| Build & evaluation | Training, testing, validation pipeline | Reproducibility; fairness, robustness & adversarial evaluation |
| Guardrail layer | Runtime input/output controls | Content filters, prompt-injection defense, output constraints, PII redaction |
| Serving layer | Model deployment & inference | Access control, rate limits, registry-gated deployment, rollback |
| Observability layer | Logging, monitoring, drift detection | Full inference logging, drift & fairness monitoring, alerting |
| Control plane | Cross-cutting policy enforcement | Policy-as-code, exception logging, audit-evidence generation |
Read the layers bottom to top as a request's journey. Data is accessed under governance. A model is pulled from the registry, which refuses unapproved versions. It runs inside guardrails that filter input and output. It serves under access control and rate limits. Every inference is logged and monitored. The control plane enforces policy across all of it and emits the evidence. Governance is not a stage in that journey. It is the road.
§ 7.3The four controls that earn their place
The registry as the gate
The model registry is the single most important governance component, because it is the choke point. If deployment is physically impossible without a registry entry carrying an owner, a risk tier, a validation status and an approval, then four controls are enforced by one mechanism. Every governance question about a production model has an answer, because the registry holds it. Build this first.
Guardrails as runtime enforcement
Guardrails are the controls that run on every request, especially for generative systems. Input guardrails defend against prompt injection and reject out-of-scope requests. Output guardrails filter toxic or non-compliant content, redact leaked PII, and constrain the model to permitted responses. Guardrails are where the model's generative freedom meets the institution's boundaries, in real time, on every call.
Evaluation as a pipeline stage
Evaluation is validation made continuous and automatic. Fairness tests, robustness tests, adversarial tests and quality benchmarks run as a required stage of the build pipeline, and their results attach to the registry entry. A model cannot reach "approved" status without passing evaluation. This is where AG-06's extended validation toolkit becomes executable rather than aspirational.
Observability as the always-on control
Every inference is logged with enough context to reconstruct what happened and why. Drift detection watches for the input distribution moving away from training. Fairness monitoring watches outputs across groups. Alerting routes anomalies to the owner. Observability is what makes the difference between discovering a problem yourself and reading about it in a regulator's findings.
Worked example
A bank rebuilt its scattered AI efforts onto a single governed platform with a registry-gated serving layer. A business unit tried to deploy a model directly to a serving endpoint, bypassing the registry, the way they always had. The deployment failed, because the serving layer only accepts artifacts the registry has approved. The team's first reaction was frustration. Their second, after they registered the model and it went live cleanly in an hour, was that the gate had cost them nothing and given them an owner, a tier and a monitor for free. The control was invisible until someone tried to skip it, which is the mark of governance built into the architecture.
§ 7.4Policy as code
The control plane's enforcement should be expressed as code, not prose. Policy-as-code means your governance rules are machine-readable and machine-enforced: risk-tier definitions, required controls per tier, residency-to-endpoint mappings, and approval requirements all live as executable policy the platform applies automatically. When policy changes, you change the code, and the platform enforces the new rule everywhere at once. When an auditor asks how a control is enforced, you show them the policy that runs, not the document that describes intent.
US enterprise
Map the evaluation stage and observability layer to SR 11-7 validation and monitoring evidence; the registry is your model inventory. If you send data to third-party model endpoints, the guardrail and data layers are where you enforce that regulated data does not leave permitted boundaries. Cloud-native tooling covers most layers; the governance value is in wiring them into one enforced control plane rather than leaving them optional.
GCC / MENA
The data layer's residency enforcement and the serving layer's endpoint control are load-bearing here. If sensitive data must stay in-region, the platform must make it architecturally impossible to route that data to a non-compliant model endpoint. This often pushes toward in-region or private model hosting, decided at the serving and data layers. Policy-as-code lets you encode residency rules once and enforce them on every inference.
This platform assumes models that predict or generate. The next article confronts what happens when the model does not just produce an output but takes an action: the governance of agentic AI, where autonomy changes the risk and the architecture has to change with it.
Separate the data/model plane from a control plane every model must traverse. Governance becomes the environment, not a step.
The registry is the choke point. Registry-gated deployment enforces owner, risk tier, validation status and approval through one mechanism. Build it first.
Guardrails enforce input and output controls at runtime on every request; evaluation makes validation a required, automatic pipeline stage.
Observability is the always-on control: full inference logging, drift and fairness monitoring, alerting to the owner. It decides whether you or the regulator finds the problem first.
Express enforcement as policy-as-code so rules are machine-enforced and changeable in one place. In the GCC, residency and endpoint control are the load-bearing layers.