Internal AI Product Strategy: Governance and Trust Architecture

Problem

The hard question is never whether a language model can answer questions about the business. It can. The hard question is whether anyone should act on the answer.

I wrote this internal strategy for FREENOW, a leading European mobility platform, during the final stages of their AI Product Manager hiring process. The subject was how a business like that gets from AI experiments to production. I framed the problem as trust rather than capability, because the models available off the shelf are already good enough for most internal questions. What is usually missing sits around them. Agreed definitions. A boundary on what can be retrieved. A clear answer to who is accountable when the output is wrong.

Without those, an AI feature scales the wrong thing. It takes the ambiguity a company has learned to live with and serves it back at volume, in a tone that makes it sound settled.

My role

Sole author. I framed the problem, designed the architecture, and wrote the plan: a semantic layer, the retrieval logic around it, a tiered governance model, and a twelve-month roadmap from foundations to scale.

Outcome

• A complete internal strategy: semantic layer architecture, RAG pipeline logic, tiered governance model, and a 12-month roadmap to production-ready AI
• A governance model in which every automated answer traces back to a certified definition, and a named human owns every consequential decision

How I solved it

Double Diamond, and refusing to skip the first diamond

The temptation with an AI brief is to start at the solution, because the solution is the fun part. I ran the Double Diamond properly instead. The first diamond was spent widening the problem before narrowing it: where does an answer come from today, who checks it, what happens when it is wrong, and which of those failures anyone would actually notice. That framing changed the whole strategy. The bottleneck was never generation. It was that nobody could point at an answer and say where it came from.

A semantic layer: every metric defined once, certified before AI touches it

Most of the numbers a company runs on carry more than one definition, each defensible inside the team that maintains it. People absorb that difference without noticing they are doing it. A model cannot. It resolves the ambiguity by choosing one source, then reports the result with no seam where the choice was made.

So the first layer of the architecture is a semantic layer where each metric is defined once, owned by a named person, and certified before anything can query it. The rule is blunt on purpose:

If a metric is not in the semantic layer, the model cannot answer questions about it.

That constraint does more work than any amount of prompt engineering. It also makes the scope of the project finite and visible, which is what turns a governance ambition into something a team can actually plan around.

Retrieval with a boundary

The RAG pipeline sits on top of that. Retrieval is scoped to certified sources, the answer carries its sources back with it, and a question that falls outside the certified set returns a refusal with a pointer rather than a plausible guess. An honest "I can't answer that yet" is cheap. An answer that is wrong and sounds right is not.

Green, Amber, Red

Governance is where most AI strategies get vague, so I made it a routing decision. Green covers low-stakes, reversible questions: the model answers, the interaction is logged, nobody is blocked. Amber covers anything that leaves the team or informs a spend decision: the model drafts, a reviewer signs off, the sign-off is recorded. Red is never automated. The model can assemble the evidence, and a named human makes the call.

The important detail is what sets the tier. Not the model's confidence score, which tracks how typical an output looks rather than whether it is right. What sets the tier is the decision itself. How reversible is it, and who carries the consequence when it goes wrong? Answering that is product work rather than platform work, which is why I put the routing rules in the strategy instead of leaving them to whoever built the pipeline.

Twelve months, in that order

The roadmap runs foundations first: certify the metrics people actually ask about, stand up the governance model, instrument everything. Scale comes last, and only into the areas the evidence justifies. Sequencing it the other way around produces an impressive pilot and a stalled rollout, because every question the foundations would have answered arrives later anyway, with an audience attached.

What shipped

A written strategy: problem framing, the semantic layer architecture, the RAG pipeline logic, the tiered approval model, and a twelve-month roadmap setting out what has to be true before each phase starts.

What worked

Spending the first diamond on the trust problem rather than the tooling. Naming an owner for every certified metric, which turned an abstract standard into a list of people. Gating each roadmap phase on evidence from the last one.

What I'd do differently

Put a rough cost model next to each phase. Governance work is easy to defer when nobody has priced what a wrong answer costs, and a number would have made that argument for me.