Governance Is a Design Problem

There are two ways a bank can implement AI governance. The first is to build the model, then govern it. The second is to let governance shape how the model is built. They sound similar. They produce completely different outcomes.

The compliance-first approach works like this: a team builds a credit decisioning model. When the model is ready for deployment, it enters the governance process. A model risk function reviews the documentation. An approval committee meets. Questions are asked about explainability, fairness, and monitoring. The team scrambles to produce answers to questions they did not consider during development. The model is approved with conditions. The conditions are partially implemented. Nobody checks.

The design-first approach starts differently. Before the model is scoped, someone asks: “What will the regulator need to see?” Not as a hypothetical — as a constraint that shapes architecture. If the HKMA expects you to explain individual decisions to affected customers, that eliminates certain model architectures entirely. If MAS expects ongoing monitoring for distributional drift, the monitoring infrastructure ships with the model, not six months later as a remediation item.

The difference is not philosophical. It is structural. Compliance-first governance treats governance as a gate — something the model passes through on the way to production. Design-first governance treats it as a load-bearing wall — something that determines what you can build in the first place.

The gate model fails in a specific way. It creates an adversarial dynamic between model developers and the governance function. Developers optimise for passing the gate. They learn what the committee asks and pre-populate answers. The documentation looks comprehensive but describes the model as designed, not the model as deployed. The gap between the two widens over time, and nobody has the incentive to close it.

The wall model fails differently. It is slow. Governance-as-design-constraint means saying no to architectures that would otherwise perform better. It means choosing an interpretable model over a black-box model even when the black box scores higher. It means building monitoring before you know what to monitor. Teams resist this because it feels like governance is preventing them from doing their job. They are correct — that is exactly what it is doing, in the same way that structural engineering prevents architects from building unsupported cantilevers.

The HKMA’s guidance on consumer protection in AI-driven banking services pushes in the design direction without using the word. When the regulator expects “meaningful explanation of AI-assisted decisions,” that is not a documentation requirement. It is an architecture requirement. You cannot meaningfully explain a decision if the system that made it was not designed to be explainable.

Most banks are still running the gate model. The ones that have switched to the wall model did not do it because they read a framework. They did it because they had a governance failure that cost enough to change behaviour. The post-incident review always says the same thing: the controls were insufficient because they were added after the design was locked.

The question is whether your institution needs its own incident to learn this, or whether it can learn from everyone else’s.

Related: [Your AI Risk Tier Is Probably Wrong](Your AI Risk Tier Is Probably Wrong) · [The Agent Governance Gap Is Already Here](The Agent Governance Gap Is Already Here)