I spend a good part of my weeks in rooms where the same conversation repeats in different clothes, and one thing caught my attention: the question people ask me has changed in nature. Two years ago it was technical — “which model are we using?”. Today it arrives far blunter and far more uncomfortable: “we spent the year’s budget on AI, show me what changed in the results”.

It took me a while to understand why that question stops so many people, because it isn’t a lack of technical answer. When I pull the thread, the pattern I find is almost always the same: the company has dozens of AI initiatives running and nobody can say how many reached production, which data stores they touch, or who answers if one of them fails in front of a customer. Technology isn’t missing — it never was. Governance is. And without it, AI adoption becomes recurring cost dressed up as innovation.

The conversation moved from “should we use it” to “who answers when it goes wrong”. Regulators, internal audit and the board now demand traceability for AI-assisted decisions. If you don’t have a use-case inventory, you simply have no way to answer.

What is AI governance?

Let me start with what it is not, because this is exactly where I tend to lose the room in the first five minutes: AI governance is not a committee that approves slide decks. When I say “governance”, what most people hear is “one more approval gate” — and the resistance is immediate. Being honest, that resistance is justified, because that’s how a good share of governance initiatives actually end up.

What I argue for is something else. AI governance is the set of rules, controls and cadences defining who may use which AI capability, over which data, with what level of autonomy, and under whose accountability. I treat it as an organisational architecture decision, not a bureaucratic process — and that distinction changes the design completely.

The fastest way I’ve found to explain the difference is to put both realities side by side. The first column isn’t a caricature: it’s what I find in most initial assessments.

For me the practical difference fits in one sentence: in the first column AI is a perpetual experiment; in the second it’s a production asset. And a production asset has an owner, a cost and a metric.

The problem it solves

When I look back and group the cases I’ve followed, the pain shows up in three shapes. All of them expensive, all of them avoidable.

The first is shadow AI, and it’s the one that bothers me most because it’s also the most badly diagnosed. When the company doesn’t offer an official path, the team finds its own — and sensitive data starts flowing through tools outside the perimeter, with no logs, no defined retention, no contract. I’ve seen this treated as a disciplinary problem more than once, and it never worked. The problem isn’t the professional; it’s the absence of a legitimate, fast route.

The second is the eternal pilot: proofs of concept that impress in the demo and never survive first contact with real load, dirty data and audit requirements. It took me a while to see the root cause, but today it seems obvious — they die because they were designed to convince, not to operate. They’re internal sales artefacts, and their success criteria ended the moment the room applauded.

The third is cost without a counterpart. Tokens are cheap per unit and expensive at scale, and that arithmetic trap gets underestimated with a frequency that still surprises me. Without a per-use-case ceiling and a value metric, the bill grows quietly until it becomes a cost-cutting agenda item. And then comes the worst possible outcome: the cut arrives linear and hits precisely the use case that was working, because nobody had a number to defend it.

How it works — step by step

What follows isn’t a consulting framework. It’s the order in which things actually work when there’s urgency, a tight budget and a board asking for answers — and I’d say the order matters more than any single item in isolation.

1. Inventory what already exists. Before approving anything new, map the AI initiatives in flight, official and unofficial. You’ll find more than you expect.
2. Classify by risk, not by hype. An assistant that summarises internal meeting notes and an engine that influences credit decisions cannot pass through the same screen.
3. Write the usage policy on one page. What’s allowed, what isn’t, which data is eligible, what requires human review. If it doesn’t fit on one page, nobody will read it.
4. Establish the production gate. No use case reaches production without: a named owner, classified data, a metric with a baseline, a rollback plan and a cost ceiling.
5. Measure value against a baseline. “It got faster” is not a metric. Cycle time before and after, rework rate, cost per transaction — those are.
6. Reassess on a cadence. Models, pricing and capability shift every quarter. The use case that didn’t pay off six months ago may pay off today. And the reverse is equally true.

The real dangers of AI (none of them is the killer robot)

I’ll admit I have little patience for the public conversation about AI risk. While superintelligence gets debated on conference panels, the incidents that actually reach the crisis committee are far more mundane — and far more frequent.

The first is leakage by convenience, and it changed how I design controls: sensitive data almost never leaves the company out of bad faith, it leaves because the official path was too slow and somebody had to ship by Friday. A policy that ignores this asymmetry of speed is doomed to be worked around — and punishing it afterwards doesn’t bring back the data that already left.

The second is miscalibrated trust, the one that worries me most technically. The model is wrong with exactly the same fluency with which it is right: no hesitation in the voice, no footnote of uncertainty, no visible sign that this sentence was invented. In a regulated process, a well-written wrong answer is more dangerous than no answer at all, because it passes through human review without raising suspicion. To me that’s an interface problem, not a model problem.

The third is the accountability vacuum, and I consider it the most corrosive. When the decision belongs to “the AI”, it stops belonging to anyone. That’s why I insist on a named human per use case — not as a compliance formality, but for a pragmatic reason: without that name, nobody has a real incentive to correct the system when it starts to drift.

There’s also dependency with no exit, the risk I feel most directly as an architect: an architecture coupled to a single provider, with no abstraction layer, turns a price change announced thirty days in advance into a budget crisis with no technical alternative inside the deadline.

And finally, the quietest of all: deskilling. It doesn’t produce incidents, it produces erosion — which is why it almost never makes it into the risk matrix. When a team delegates judgement, and not just execution, it gradually loses the ability to audit its own tooling. The symptom only surfaces years later, when someone has to explain why the system decided what it decided and there’s no longer anyone in the room able to answer.

From the field: the AI incidents I’ve followed rarely came from the model. They came from misconfigured permissions, from a prompt with sensitive data pasted inside it, and from a process with no human review where review was mandatory.

From application developer to AI engineer

This is the fastest career transition I see today and, in my reading, the most poorly explained.

The shift is already underway: application developers being moved into AI engineer roles, where AI stops being the end product and becomes the working tool. The day-to-day changes shape — far less typing of code, much more specifying, reviewing and integrating. The model writes the draft; the professional decides whether it enters the repository, and answers for it if it goes in wrong.

What catches my attention is the mistaken reading that comes with this shift: that AI has made fundamentals disposable. My experience points to the opposite. Reading code remains harder and more valuable than writing it, and AI has multiplied the amount of code to be read. Architecture decisions, transaction boundaries, data models and API contracts remain human work, because they depend on a business context that doesn’t fit in the model’s window. And there’s an uncomfortable truth I repeat whenever I can: whoever can’t evaluate a solution also can’t evaluate the solution AI proposes. The tool doesn’t create judgement — it only accelerates those who already have it.

What changes is the nature of the demand. Context engineering becomes worth more than prompt syntax: knowing what to put in the model’s window and, above all, what to leave out separates a useful answer from a plausible hallucination. Systematic evaluation stops being optional, because without a test set for model output “it got better” becomes an opinion. Guardrails and observability enter as engineering requirements, since tracing input, output, cost and latency per call is what makes predictable operation possible. And cost awareness becomes part of the design, because the AI engineer is usually the first to notice when an apparently innocent choice multiplies the bill tenfold.

Above all of that I’d put critical review. Accepting an AI suggestion without understanding it is the equivalent of approving a pull request without reading it — with the aggravating factor that the error now scales at the speed of the tool, not at the speed of the person typing.

My executive read is direct: the developer who only shipped code is exposed; the one who ships outcomes is not. AI compressed the mechanical part of the work and amplified the value of the part requiring judgement.

And there’s an organisational trap I need to say plainly, because I’ve seen it happen: renaming the role doesn’t make the transition. Switching the title from “developer” to “AI engineer” without offering a track covering evals, context, cost and security repositions nobody — it merely transfers the risk from the company to the individual, demanding a competence the company never provided. Repositioning belongs in the governance layer, not in HR alone.

How the world and professionals need to adapt

On the organisation’s side, the most important change is one of framing, and it’s also the hardest to land: the repositioning track needs to be treated as a governance control, not as an HR perk. When I manage to move that conversation to a different agenda, everything changes — because an unprepared team operating a powerful tool is operational risk, and operational risk has an owner, a budget and a deadline, which a perk does not.

Alongside that, I’d suggest inverting a less obvious incentive: reward those who document what AI should not do. That knowledge is far scarcer than the opposite, and it’s precisely what prevents the expensive mistake from repeating. And finally, we need to accept something practice has demonstrated exhaustively — the most effective defence against shadow AI was never prohibition, but the existence of a genuinely fast official path. As long as the legitimate route is slower than the alternative, the alternative wins. Every time.

On the professional’s side, the advice I give is always the same, and it applies as much to me as to whoever is asking: move up the decision chain. Automation consumes tasks, not responsibility, and the boundary between the two is exactly where a career protects itself. Specialise where context is expensive — regulated domains, proprietary data, legacy integration — because that’s precisely where the generic model is weakest, since that’s where the knowledge isn’t on the internet.

And learn to audit AI, not merely to operate it. Anyone learns to operate it in a week; being able to prove the output is wrong is what makes someone irreplaceable, precisely because the tool is fallible by construction.

Production best practices

None of the points below is theoretical: each corresponds to a mistake I’ve watched cost real money, and usually cost it twice. If there’s only one to carry forward, make it the first — most of the governance failures I’ve followed started by writing the policy before knowing what was already running.

• Start the inventory before the policy — rules written over an unknown reality never stick.
• Set the per-use-case cost ceiling on the same day you approve the pilot.
• Require a numeric baseline before the first deploy; afterwards it’s too late to compare.
• Log the prompt, model version and output for use cases in regulated processes.
• Isolate sensitive data by access scope, not by instruction in the prompt. An instruction is not a control.
• Put an abstraction layer between the application and the model provider from day one.
• Review the portfolio quarterly and switch off what hasn’t proven value. Governance also means knowing how to kill an initiative.

Frequently asked questions (FAQ)

Won’t governance slow adoption down?

It’s the objection I hear most, and my answer is that the effect is usually the reverse. What slows adoption is rework, incidents and pilots that fail audit. Well-designed governance is a fast path with criteria, not an obstacle.

Where do we start if we have nothing?

With the inventory, always. A spreadsheet listing use case, owner, data touched and status already resolves the first 80% of the blindness — and it tends to be the deliverable that impresses the board most, precisely because it’s the simplest.

How many people does a governance team need?

Fewer than you’d think. In my experience it works better as a distributed function — one owner per domain — than as a central team, which almost always becomes a bottleneck and, shortly after, a target.

Will developers be replaced by AI?

Not by AI. Eventually by another professional who uses AI with judgement and delivers auditable outcomes. The difference is judgement, not tooling.

How do we measure AI value without vanity metrics?

Ignore user counts and interaction volume — those are the numbers that decorate a slide and don’t sustain a decision. Measure cycle time, rework rate and cost per transaction, always against a prior baseline.

Conclusion

If I had to compress all of this into one sentence, it would be this: AI adoption stopped being a technology problem and became an operations and accountability problem. The companies that will capture value aren’t the ones with the best model — they’re the ones that know which use cases are running, what each one costs, what data it touches and who answers for it.

The same applies to careers, and here I’m speaking for myself too. AI doesn’t eliminate the technical professional; it shifts value from execution to judgement. The developer who genuinely becomes an AI engineer — with evals, context, cost and critical review — becomes more relevant, not less. The one who only swaps badges is the one who’s exposed.

Governance isn’t the brake on AI adoption. It’s what lets you floor the accelerator without leaving the track.

👉 If you’re leading AI adoption — especially in a regulated environment, with audit at your neck and a board asking for numbers, this is the moment to trade enthusiasm for an inventory.
Want to talk about AI governance and repositioning technical teams? Reach out on LinkedIn.