Governance arrives before the technology does.

It would be cheaper to build the intelligence first and the governance afterwards. It would also be a mistake. Once a system that touches money is in production, retrofitting controls means asking already-busy teams to rewrite working code while the system keeps running. We have watched that play out before, and it goes badly.

This post explains the order we sequenced our roadmap in, why running it the other way costs more in the long run, and what the trade-off looks like in practice.

The order we chose, and why

We sequenced the roadmap the way regulators would prefer. Three phases, in this order:

Phase 1: Governance

The charter, the steering committee, the use-case register, the acceptable-use rules, the vendor due diligence, the human oversight rules. This is the controls system you would want before the first model runs. We built it before there was a product to apply it to.

Phase 2: Knowledge foundation

Data classification, access groups, source ownership, AI eligibility rules, leakage testing, knowledge storage. Information had to be organised under the governance system before the model could touch it. The classification is what tells the system whether a document is eligible to be retrieved, and by whom.

Phase 3: The intelligence layer

Only now does the Brain itself come online. Internal knowledge search, source-linked answers, AI-assisted drafting, controlled synthesis. By the time the model runs its first retrieval, every document it can see has been classified, every workflow it touches has been registered, and every action it takes is logged.

Customer-facing AI comes later still, after these three phases prove themselves on internal workflows.

What you save by running it in this order

A model that ships before its governance is a model whose controls have to be written under pressure. The team that wrote the model has moved on to the next thing. The team that has to write the controls is auditing live behaviour with one hand and patching it with the other.

Running governance first means:

The use-case register is the single source of truth from day one, not a reconstruction.
The audit log records every action from the first call, not from the date someone decided to start logging.
The data classification is applied at ingest, not retrofitted across years of accumulated content.
The vendor list is documented, not a guess based on whoever was billed last quarter.

Each of these is recoverable retroactively, but the cost of recovery is high and the result is messy.

The cost of the approach we chose

The cost of this approach is patience. We are staffing controls a year before there is a product to apply them to. That is hard to justify to anyone whose mental model is "ship fast and iterate". It is also expensive in headcount: compliance and governance work is the kind of work that does not visibly produce anything until it has to.

We accept this cost for one reason: nothing we ship feels like a workaround. There is no "we know it is not ideal but it is what we could do in the time" surface in the product. Every gate is in its proper place, and every part of the product passes through it.

The alternative is the financial industry's default mode, which is to launch the product, accumulate regulatory debt, and pay it down under enforcement pressure. We have watched that closely, and we know what it does to a company over five years. We chose differently.

What this means for the customer

The customer never sees the gates. They see a bank that works. The audit log, the steering committee, the use-case register, all of these are infrastructure for the people who answer to regulators on their behalf. The customer's experience is what is above the waterline.

Below the waterline, what they get is a system that does not have to rush a regulatory question, and a company that does not have to choose between fixing a control and shipping a feature. That is the dividend on the patience.

FAQ

Questions readers ask

Why does governance come before AI deployment?

Because retrofitting controls onto a live system means asking already-busy teams to rewrite working code while the system keeps running. Governance built up front sets the controls schema (use-case register, data classification, audit log) that every later component plugs into. Built afterwards, it is reconstruction work under enforcement pressure.

What does Phase 1 governance actually look like?

An AI charter that names the principles, an AI steering committee with documented authority, a use-case register that catalogues every place AI is used, acceptable-use rules, vendor due diligence, and named human-oversight rules. All written before any model is deployed against bank data.

How long does the governance phase take?

At Veetso, roughly a year of work before the first production AI use case. Most of that is people-work: writing policy, building the steering committee, training reviewers, and putting in the data classification scheme. It is the part of the roadmap that produces nothing visibly customer-facing.

What is the cost of running the order in reverse?

You ship a model into production with no audit log, then build the log retroactively from whatever traces exist. You discover documents in the model's reach that should not have been there. You re-run KYC reviews under enforcement pressure. The financial industry has watched this play out many times; the cost is measured in years, not quarters.

Does the customer see any of the governance?

No. The audit log, steering committee, and use-case register are infrastructure for the people who answer to regulators on the customer's behalf. The customer's experience is what is above the waterline. The dividend they get is a bank that does not have to rush a regulatory question or trade off shipping for compliance.