Governance bolted onto the end of delivery is a tollbooth. Teams see it, resent it, and look for the exit ramp. Governance embedded in the delivery method is a set of guardrails on a road they are already driving. Same controls, opposite experience, and only the second one holds under delivery pressure.
The architecture function already has a method for moving a capability from idea to production. In most enterprises that method is the TOGAF Architecture Development Method, or a close relative. This article wires AI governance into that method phase by phase, so that a model cannot progress through delivery without passing the control that belongs at each stage. Governance stops being a gate and becomes the path.
§ 4.1Why the ADM is the right host
The ADM already does three things AI governance needs. It moves work through defined phases with entry and exit criteria. It has an Architecture Board that reviews and approves at checkpoints. And it produces artifacts at each phase that become evidence. You do not need a parallel governance process. You need to inject AI-specific controls into the phases and artifacts you already run.
The alternative, a standalone AI governance workflow that runs beside delivery, guarantees friction. Two processes compete for the team's time, the governance one loses, and you are back to paper. Host governance inside the method the organization already follows.
Principle
Do not create a new process for AI governance if an architecture governance process already exists. Extend it. Every new parallel workflow is a workflow teams will route around. The ADM's authority to gate delivery is exactly the authority AI governance needs and rarely has on its own.
§ 4.2The ADM, phase by phase, with AI controls
Here is the injection map. For each phase, the AI-specific control and the artifact it produces. The artifacts double as your crosswalk evidence from AG-02.
| ADM phase | AI governance control | Artifact produced |
|---|---|---|
| Preliminary | Establish AI principles, risk-tier definitions, and the governance operating model | AI architecture principles; tiering rubric |
| A · Architecture Vision | Assess AI use-case risk; screen for prohibited / high-risk category; confirm human-oversight need | AI impact & risk-tier assessment |
| B · Business Architecture | Define the decision the model informs, the affected persons, and the accountability owner | Decision map; named owner; oversight design |
| C · Data Architecture | Confirm data lineage, quality, consent, residency; approve training sources | Data lineage record; residency sign-off |
| C · Application Architecture | Require governed-platform patterns: registry, guardrails, evaluation, logging | Reference-architecture conformance check |
| D · Technology Architecture | Confirm monitoring, observability, access controls and rollback capability | Control-plane design; monitoring plan |
| E · Opportunities & Solutions | Independent validation scope agreed; effective-challenge plan set | Validation plan; challenge record |
| F · Migration Planning | Deployment gate defined; exception process; go-live risk sign-off | Go-live approval; exception log |
| G · Implementation Governance | Architecture Board enforces conformance; deploy blocked without registry entry | Board approval; conformance certificate |
| H · Change Management | Drift monitoring, revalidation triggers, model-retirement criteria | Monitoring dashboard; revalidation record |
Read Phase G carefully. Implementation Governance is where the Architecture Board already has the authority to block non-conformant work. That authority is the enforcement mechanism AI governance usually lacks. You are not asking for new power. You are pointing existing power at a new class of risk.
§ 4.3The Architecture Board becomes the enforcement layer
Most enterprises already have an Architecture Board that reviews solutions for conformance to standards. Extend its remit to AI conformance and you have your enforcement layer without a new committee. The Board's checkpoint at Phase G becomes the point where a model without a registry entry, an owner, a validation record and a monitoring plan simply does not pass.
This connects directly to the operating model in AG-03. The AI Governance Committee sets the standards and rules on high-risk approvals and exceptions. The Architecture Board enforces conformance to those standards at the delivery checkpoint. Two bodies, clean handoff: one decides what good looks like, the other refuses to let non-good ship.
US enterprise
Map Phase E and G artifacts to SR 11-7 validation and effective-challenge expectations. The validation plan produced in Phase E is your effective-challenge evidence; the Board approval in Phase G is your independent sign-off before use. Supervisors respond well to governance embedded in an existing, auditable delivery method rather than a bespoke AI process.
GCC / MENA
Phase C's residency sign-off is where SAMA and PDPL data-localization requirements get enforced by construction. Add a Sharia-conformance checkpoint at Phase B for Islamic-finance products, so the Sharia board's input shapes the design rather than blocking it at launch. The Board approval in Phase G maps to the named-accountability expectation.
§ 4.4A worked example: the model that skipped Phase C
Worked example
A team built a customer-churn model that quietly used a third-party enrichment dataset. Because governance was a launch-time review rather than a phased control, the data provenance question surfaced two days before go-live, when someone in legal asked where the enrichment data came from. It came from a source the bank had no license to use for this purpose. The launch slipped a quarter. Had the Data Architecture control in Phase C been a required exit criterion, the question would have arrived in week two, when changing the data source was cheap. The cost of a control is set by where in the lifecycle it fires.
The lesson is the economics of timing. A control that fires early is cheap because the design is still soft. The same control fired at launch is expensive because everything is built around the wrong assumption. Embedding controls in the ADM is not only about enforcement. It is about firing each control at the phase where fixing the problem still costs little.
§ 4.5Start where you are
You do not need a mature ADM to begin. If your architecture practice is lighter, pick the three checkpoints that matter most and enforce those first: a risk-tier assessment at inception, a data and provenance sign-off before build, and a conformance check before deploy. Three well-enforced gates beat nine aspirational ones. Add the rest as the practice matures.
With governance now living inside the delivery method, the next article goes down a layer to the thing every model depends on and every program underinvests in: data governance, the true foundation on which all of this rests.
Host AI governance inside the delivery method you already run. A parallel governance workflow is a workflow teams route around.
Inject a specific control and artifact into each ADM phase, so a model cannot progress without passing the control that belongs at that stage.
Extend the existing Architecture Board to enforce AI conformance at Phase G. You are pointing existing authority at new risk, not creating new power.
The AI Governance Committee sets standards; the Architecture Board enforces conformance. Clean handoff between the two bodies.
Fire each control at the phase where fixing the problem is still cheap. If you can only enforce three gates, choose tiering, data provenance, and pre-deploy conformance.