From Architecture Review Board to AI Decision Authority

Many Architecture Review Boards were designed for an earlier era. They review solution diagrams, standards exceptions, integration patterns, and hosting choices. Those matters still count, but AI introduces questions the traditional ARB was never structured to answer: what judgment is being delegated, how much autonomy is acceptable, what evidence supports the model, and when the system must return authority to a human.

§ 1Why the old review model is too late and too narrow

A monthly board that meets after design completion will either delay delivery or approve what has already become politically difficult to change. AI governance needs earlier classification and clearer thresholds. The most important decision is often not whether the solution uses an approved technology, but whether the proposed delegation of judgment is acceptable at all.

The review body must also look beyond architecture artifacts. It needs evaluation evidence, data provenance, operational thresholds, human intervention design, vendor terms, and post-production monitoring commitments.

§ 2A decision authority, not another committee

An AI Decision Authority should have defined jurisdiction and delegated power. It should know which decisions product teams can make within approved patterns, which require specialist review, and which require executive risk acceptance. Ambiguous authority produces escalation theatre and encourages teams to shop for the answer they want.

The authority should combine architecture, business, data, security, legal, risk, and operations without requiring every function to attend every case. Risk tiering should determine the participants and evidence burden.

The authority should combine architecture, business, data, security, legal, risk, and operations without requiring every function to attend every case. Risk tiering should determine the participants and evidence burden.Chief Architect field note

§ 3Continuing assurance changes the lifecycle

AI systems change through new data, model updates, prompt changes, vendor releases, and shifting business conditions. Approval cannot be permanent. The operating model needs triggers for re-evaluation: material model changes, drift, new data use, expanded autonomy, incidents, or regulatory change.

This is why the decision authority must be connected to monitoring. The same thresholds used in approval should inform production alerts and reapproval. Governance becomes a lifecycle rather than a gate at the beginning.

§ 4What the Chief Architect should do now

Rewrite the ARB charter to include AI decision rights, risk tiers, evidence expectations, exception authority, and reapproval triggers. Remove topics that can be automated or delegated so the board spends time on judgment rather than routine conformity.

Create a fast path for approved patterns and a clear high-impact path for consequential systems. Publish service-level expectations for decisions. A governance body that cannot respond at delivery speed will be bypassed, regardless of its formal authority.

§ 5Executive takeaway

The ARB should not disappear, but it must evolve. In the AI era, architecture governance is no longer only about technology fit. It is about the controlled delegation of judgment and autonomy. That requires an authority with the mandate, evidence, and lifecycle connection to make decisions that hold.