This service is about AI that’s already running in your business, sanctioned or not, and what it takes to bring it under control and into production properly: containment first, then model selection, integration, security, the business case and, finally, the approval.

Some of that AI was never approved: a browser extension, a personal account, an agent nobody scoped. That gets contained first, boundaries and sanctioned tools, before anything new gets designed on top of it. The five skills below are what building it properly then looks like, whether you are containing what is already there or starting from scratch.

Most organisations are past the demo. Someone has built something that worked in a meeting, and then the real questions arrive: can it touch production data, can it be trusted in front of a customer, what does it cost at volume, who signs off, and what happens when it is wrong. That gap is not a modelling problem. It is an architecture problem, and it is where AI projects quietly stop.

An AI architect is the person who closes it. The role rests on five skill sets, and only one of them is about AI. The other four decide whether anything ships at all.

What an AI architect is actually for

1. The AI itself

Choosing a model is a trade-off, not a preference: capability against cost, latency, control, and where the data is legally allowed to sit. Retrieval-augmented generation is what makes a model answer from your own documents instead of from the internet’s average opinion. Model Context Protocol is what lets it reach the systems where the work actually happens, rather than sitting in a chat window next to them.

Then the part most pilots skip. A model that is impressive in a demo and wrong once a month in production is a liability, so it needs evaluation before launch and monitoring after it, for drift and for the confident answers that are simply untrue. AI security is its own discipline on top of that: prompt injection turns your own documents into instructions, and retrieval turns a quiet permission problem into a searchable one. Both are design decisions long before they are incidents.

And none of it works on bad data. Lakes, warehouses and databases have to be in a state worth retrieving from, which is the least glamorous and most decisive part of the work.

• Model selection against cost, latency, control and data residency
• Retrieval over your own documents, so answers are grounded and traceable
• Tool and workflow integration, including Model Context Protocol
• Evaluation, testing, and monitoring for drift and hallucination
• Prompt injection, data leakage and AI-specific threat modelling
• Data hygiene across lakes, warehouses and databases
• Acceptable use and ethics, written so people can actually follow it

2. The platform underneath

AI runs on ordinary infrastructure and fails for ordinary reasons. Cloud or on-premises. A managed model or open weights you host yourself. What the network does at volume, what an API contract actually promises, where compute and storage start costing real money. These are the trade-offs that decide whether the thing scales, stays available, and stays inside a boundary you can describe to an auditor.

Twenty years of solution and security architecture is not a side qualification here. It is the qualification. The AI layer is new. Everything holding it up is not.

3. The room where it gets approved

AI projects rarely die in a model. They die in a steering committee. The CFO wants a number. The CISO wants a boundary. Legal wants to know where the data goes and who is liable when it is wrong. And the team that has to change how it works every day wants to know whether this is here to help them or replace them, which is the question nobody asks out loud and everybody acts on.

Getting those four to a yes, with no direct authority over any of them, is a skill in its own right. So is the change management afterwards, because a workflow people quietly refuse to adopt produces exactly the same result as a project that was never funded.

4. The business case

A business case that survives a finance review is not a slide with a percentage on it. It is a payback period with assumptions someone is allowed to argue with, a vendor comparison that was not quietly pre-decided, and an honest position on speed against governance rather than a promise of both.

It also answers the question most AI proposals leave out entirely: what the business does on the morning the model, the API or the vendor is unavailable, and which processes are now quietly dependent on something that has a status page. Continuity planning for AI is new only in the sense that very few people have written one yet.

5. The translation

The output of architecture is artifacts people can act on: a capability map, a target-state design, a roadmap sequenced by dependency rather than by enthusiasm. Before any of that comes the questioning that finds the requirement behind the request. Someone asks for a chatbot. What they need is for three teams to stop answering the same question by hand, eleven times a day, from memory.

Framed as the second thing, it gets funded and it gets used. Framed as the first, it gets a pilot and a shrug. The tool name is never the story. The problem is.

How we get started

• An assessment. Short and scoped. Where you stand, what is safe to do now, and what needs fixing first. A good fit when a pilot already exists and people disagree about it.
• A solution design. Architecture, roadmap and business case in one deliverable, written for both the board and the people who will build it.
• An architect on your team. By the week or by the sprint. I design the solution and then help build it, so you avoid rework, teething problems and a budget that drifts.

Worth a conversation?

30 minutes, no charge and no obligation. Whether it is a pilot nobody will approve, a business case that keeps getting sent back, a board that wants a plan before next quarter or something else entirely, we can talk it through in the meeting.

You can also send a message instead.