The rules that matter belong in the database
Code can be changed by a well-meaning engineer on a deadline. A constraint cannot. Most of what I mean by governed AI sits in that difference.
In 1999 I took a job at BearingPoint running global resource operations for the high-technology practice. On paper it was a staffing role. In practice it was ten thousand consultants and subcontractors, thirty-odd managers, and about thirty million dollars a month in subcontractor spend moving through a system nobody could see end to end.
What that job cured me of was a belief in individual brilliance. At that scale, the outcome has very little to do with how clever anyone is on a given Tuesday. It has to do with whether the system underneath makes the right thing easy and the wrong thing hard. I have spent the twenty-five years since on variations of the same question.
Programmes don't collapse. They stall.
The public conversation about failed transformation is mostly about technology choices, and that conversation is nearly always beside the point. I have watched large modernisation programmes go wrong across tax, licensing, regulatory and public-service systems, and the technology was rarely the thing that broke.
What breaks is ownership. Approvals that nobody is accountable for. A plan every stakeholder has agreed to and no one is executing. Programmes of this kind almost never collapse — a collapse would at least be legible. They stall, quietly, while everyone involved is working hard and reporting green.
That is the failure mode I built a firm around. And when generative AI arrived, it did not change the diagnosis. It raised the stakes, because a system that drafts faster than anyone can review produces stalled work at a speed no one has seen before.
Fast drafting with slow judgment is not efficiency. It is a backlog with better formatting.
Procedural rules are suggestions
Every organisation I have worked with has a governance policy. Most have a good one. The question is never whether the rule exists — it is where the rule lives.
A rule that lives in a policy document is a suggestion. A rule that lives in application code is a strong suggestion, right up until a competent engineer under deadline pressure works around it for a defensible reason. I have been that engineer's manager, and the reason is usually good.
A rule that lives in the schema is not a suggestion. If the data model will not accept a released document without a recorded approval from someone other than its author, then no amount of deadline pressure produces an unapproved release. The constraint does not negotiate, does not get tired at 2am, and does not have a quarter to make.
This is why the design principle I would defend anywhere is narrow and slightly unglamorous: the rules that matter belong in the database, not in application code. Three of them do most of the work.
No one approves their own work. Maker and checker are different people, structurally, not by convention. Nothing is released that wasn't cleared. The released state is unreachable without the approval record. Every action leaves a record of who took it. Not a log that can be pruned — a row that the rest of the model depends on.
Where the AI actually goes
People expect the interesting part of an AI system to be the model. In our work it is the boundary around the model.
NGOS is the system our firm runs itself on: capture, proposal, staffing, compliance, delivery. AI drafts throughout it. A person approves anything that matters. NEMS is the governance layer around that — controlled documents, maker-checker approval, risk, audit, corrective action.
The distinction that makes it work is between drafting and deciding. A model is genuinely good at producing a first version of a document, a schedule, a response. It is not accountable for the consequences of that document, and it cannot be. So the architecture puts the model on one side of a line it cannot cross by itself, and puts a named human on the other.
That sounds like a limitation. In practice it is the thing that makes the speed usable. You can let a system draft aggressively precisely because you know what it cannot do unilaterally.
We ran it on ourselves first
We built this for our own operation before we offered it to anyone. Roughly five hundred controlled documents and the whole of the firm's work run on it.
That is not a marketing position, and I would not make much of it except that selling an operating discipline you do not practise is a particular kind of dishonest. If the governance is real, it should be inconvenient for us sometimes. It is.
Thirty years in, the question hasn't changed. Only the tools have, and the tools got fast enough that the question finally became urgent.
Saif Rehman is the founder and CEO of NextGen Consulting. More on the work is on the business page.