Architecture governance: roles, continuous review and compliance

In most organizations, architecture governance stays a point-in-time exercise: a committee that meets, an annual audit, a compliance review scheduled well in advance. Between deadlines, decisions pile up without collective validation — and the committee discovers, at best belatedly, a system that has drifted from what it thought it was governing. TEAF answers this with a governance model structured around named roles and continuous evaluation, not a meeting calendar.

Five roles set out in Book II, not a new layer of hierarchy

Book II (Framework Specification) defines five roles that share governance of the TEAF loop, each responsible for a distinct aspect rather than a single step: the Architecture Owner, holder of overall coherence for a capability domain; the Decision Steward, guarantor of the Living ADR lifecycle; the AI Control Officer, responsible for the AI Control Plane and AI agent routing, security and cost policies; the Capability Owner, named owner of a business capability; and the Compliance Liaison, the link between continuous governance and regulatory obligations. These five roles form the basis of the TEAF certification program, where each role profile details responsibilities, skills and prerequisites.

The Architecture Review Board, and when it shows up

The Architecture Owner and Decision Steward jointly run the Architecture Review Board, the body that arbitrates drifting architecture decisions. It doesn't appear on day one: in the four-phase deployment method (Why, What, How, Who/When), it's set up in Phase 4 — a phase explicitly labeled continuous, not point-in-time — alongside the first active Living ADRs and a sequenced deployment calendar.

Continuous Governance: evaluation replaces the audit

The guiding principle behind all of this has a precise name among the ten principles on the Framework page: Continuous Governance — compliance is assessed continuously, not through point-in-time audits. Concretely, that means every automated execution is logged with a timestamp, every piece of data inferred by an AI agent records the model that produced it, and a confidence threshold triggers mandatory human validation below a defined level — controls that apply as things happen, not during an annual verification campaign.

The explicit link to regulatory compliance

The Compliance Liaison role exists precisely so this continuous governance absorbs regulatory obligations instead of handling them separately: NIS2, the EU AI Act and GDPR. Its mission covers checking that an audit log retains every automated action, that observed risks are documented before any Go/No-Go decision on a POC — not just the benefits — and that permissions granted to AI agents actually cover the sector's regulatory requirements. This role is best identified at project kickoff, particularly in heavily regulated sectors, where late involvement risks costly rework.

Where to start

Positioning an organization against this governance model doesn't require waiting for a full reorganization: the online maturity diagnostic includes a dedicated governance read, and the certification program details, role by role, what's already expected and what's still being built.

• Five roles set out in Book II — Architecture Owner, Decision Steward, AI Control Officer, Capability Owner, Compliance Liaison — share governance without creating an extra layer of hierarchy.
• The Architecture Review Board arbitrates drifting decisions; it's set up in deployment Phase 4, a phase labeled continuous.
• Continuous Governance assesses compliance continuously — logging, human-validation thresholds — rather than through point-in-time audits.
• The Compliance Liaison explicitly links this governance to regulatory obligations: NIS2, the EU AI Act, GDPR.