The most common question you'll get is "can AI do this — and how?" The honest answer is usually "yes, but choose the lightest approach that works." Here's the decision, with each option explained — including RAG — and what each one means for governance.
Quick advisor — answer three questions
The four approaches
Prompting
Effort: low · daysRAG (retrieval-augmented generation)
Effort: med · weeksFine-tuning
Effort: high · weeks–monthsAgents
Effort: high · highest riskThe rule of thumb (and the cheapest path to value)
Climb only as far as the problem forces you. Each rung adds cost, risk, and governance overhead.
- Start with prompting. Astonishing amount of value lives here.
- Add RAG when it needs your own knowledge or must cite real sources.
- Fine-tune only when a narrow, high-volume task still isn't consistent enough.
- Reach for an agent only when the job genuinely requires acting in systems — and then scope its access tightly.
Build vs. buy
A separate question, and the evidence is blunt: across enterprise studies, buying or partnering succeeds roughly twice as often as internal builds (MIT, 2025). Default to buying the capability and owning the governance, integration, and change — build only where it's a genuine differentiator.
This is the lightweight version of the same call Assess makes for a specific workflow (is AI even the right tool, at what autonomy). Use this to teach and decide quickly; use Assess to produce the governed brief.
Before you green-light an AI use case, you need its risk tier — defensible, not a gut call. Answer five questions; get a tier, the controls it requires, and the most autonomy it should ever have. The same logic the Operating Model uses, in 30 seconds.
Profile the risk
This is the quick version of the autonomy-by-consequence call Assess makes in full, and it tiers into the same control library you set in the Operating Model. Use it to triage fast; use Assess for the governed brief.
RAG — retrieval-augmented generation — is the most common way to make a general model answer from your knowledge instead of its own. Here's what it is, how it works, and the one thing about it that's a governance problem.
How to explain it to an exec: "It's an open-book exam. The model isn't remembering your policies — it's looking them up at answer time. Which means whatever it's allowed to look up, it can repeat."
Not quite, and the gap is the whole point. Naming a source isn't access: tell a plain model "the handbook is on our wiki" and — with no tool to fetch it — it can't read a word, so it paraphrases a guess. The real choice is how it retrieves. A live-fetch tool ("open the book to the page named and read it") is always current and needs no pipeline — but it grabs whole pages, has to know which one, and slows as content grows. RAG ("a librarian who has read everything, returns the three exact paragraphs that answer the question across all of it — with the source") wins on precision, scale, cost and citations. The trade-off runs the other way on freshness: a live fetch always reads the current page, while a RAG index is only as fresh as its last sync. Rule of thumb: one handbook that fits in the prompt → just hand over the doc; a whole wiki, many sources, citations, or per-person access → RAG.
How it works
When it's the right call
It needs to answer from your current internal facts — manuals, policies, product data, tickets — and you want answers you can trace to a source.
Your content is thin, stale, or ungoverned (RAG inherits its quality), or you actually need a behaviour/style change — that's fine-tuning, not RAG. RAG adds knowledge, not skills.
For the full "prompt vs RAG vs fine-tune vs agent" decision, use the Approach advisor.
RAG can surface anything it can retrieve. If a user asks a question and the system pulls a passage from a document they shouldn't see, RAG has just leaked it. So retrieval must enforce the same permissions as the source — RAG inherits your data's access rules, not only its content. Two non-negotiables: scope retrieval to what the user is allowed to see (least-privilege, the same control you set in the Operating Model), and always show citations so every answer is verifiable.
"AI agent" is the most overloaded term in the building right now — and you'll be asked to make decisions about agents while the word still means five different things. Here's the version you can explain to anyone, with the part that actually matters for risk.
Model vs. agent — the distinction that matters
The engine
Claude, GPT, Gemini. On its own it reads and writes text. It can't see your systems or do anything in the world — it just produces words.
The entity that acts
That same model, wired up so it can actually do things — call tools, read and write to systems, remember, and decide its own next step toward a goal.
How to explain it to an exec: "The model is the brain. The agent is the brain plus hands, keys, and a job — and we govern the hands and keys, not just the brain."
Autonomy is a dial, not a switch
The single most important governance decision about an agent is how much it's allowed to do on its own — and you set that by consequence and reversibility, not by how impressive the demo is.
Why access is the real risk
An agent's danger isn't its intelligence — it's its blast radius. The same model is harmless as a read-only summarizer and dangerous with write access to your finance system. So the governing questions are always: what can it reach, read or write, and who approved that?
An agent given more tools/permissions than the task needs. The fix is least privilege — grant the minimum access, nothing "just in case."
Malicious text in a document or email tricks the agent into misusing its tools. The more it can do, the worse this gets.
Payments, deletions, sends. These need "check first" autonomy and a kill-switch — never "runs itself."
An agent that can both initiate and approve the same action breaks a basic control. Split them, as you would for a person.
You approve models once (the register in Operating Model); you govern each agent — its owner, autonomy, and least-privilege access. Assess sets an agent's autonomy by consequence; Monitor tracks what it touches and how it behaves.
Two words used loosely. The model is just an engine. Scaffolding is what's built around one model call to make it reliable; orchestration is what coordinates many steps into a workflow. Most of what looks like "the AI is clever" is good scaffolding and orchestration — not a smarter model.
How to explain it to an exec: "The model is the engine. Scaffolding is the car built around it — the steering, the dashboard, the seatbelts. Orchestration is the route and the traffic lights for a whole trip with several stops."
Make a single answer dependable
The instructions and structure wrapped around one model call so the output is reliable and usable: a clear system prompt, a structured output format (so the result is parseable, not loose prose), the tools it may call, worked examples, breaking a big ask into steps, and self-checking / retries when it gets something wrong. A capable model with strong scaffolding beats a stronger model with none.
Coordinate the whole job
The control flow over multiple steps: what runs when, passing each step's output to the next, branching ("if it's a refund, do this"), looping, running calls in parallel, holding state across steps, and handling errors. The "conductor" — frameworks like LangGraph, CrewAI, AutoGen or n8n, and durable engines like Temporal for long-running flows.
The distinction that actually matters: workflow vs agent
Orchestration comes in two shapes, and the difference is a governance decision, not just a technical one.
The steps are defined in advance — do A, then B, then if X do C. Predictable, testable, governable. The right default for most production work: the same input takes the same route every time.
The model decides which tools and steps to use at runtime to reach a goal. Flexible for open-ended work, but less predictable and harder to govern. The more the model controls the flow, the more it behaves like an agent — and the more it needs the autonomy + least-privilege controls in the agent guide.
Climb only as far as the task forces it: a single well-scaffolded call → a fixed workflow of a few steps → a free-roaming agent — last, and tightly scoped. Reliability and governability drop at each rung while cost and failure modes rise, so reach for the next rung only when the one below genuinely can't do the job. (Same discipline as the Approach advisor — most "we need a multi-agent system" turns out to be one good prompt with structured output.)
There's no perfect hallucination detector — anything claiming 100% is overselling. But the rate can be cut hard, most of what slips through can be caught, and the rest gated. The whole approach rests on one idea: it's hard to check "is this true about the world?", but easy to check "does this answer match a source we provided?"
First — what "grounding" actually is
Grounding means the model answers from source text put in front of it at the moment of the question (via RAG, or just pasting the document) — not from the fuzzy memory baked into training. It's the difference between recalling and reading.
Q: "What's our refund window?" → "30 days."
Plausible, possibly wrong — and the real problem is there's nothing to check it against. It's a guess recalled from training.
Retrieve "Returns Policy §2 — items may be returned within 30 days of delivery," put it in the prompt → "30 days [Returns Policy §2]."
Now the answer is copied from real text and verifiable against it.
The quiet payoff: grounding doesn't only lower hallucination — it turns an unanswerable question ("is this true?") into a checkable one ("does this match the source?"). That's what makes every check below possible.
Then — what the "checks" actually look like
Concrete, in rough order of catch-per-effort:
Pick a faithfulness rate (share of answers fully supported by their source) and track it on a test set and a sample of live traffic, so a prompt or model change shows up as that number moving. The honest stack: grounding does the heavy lifting → citation + faithfulness checks catch most of what slips → structural checks nail the fabricated specifics → a human gates the high-stakes remainder. No magic filter — layers.
When an agent goes into production it stops being a project and becomes a thing that acts on its own every day. Someone has to be accountable for it — the way a manager is accountable for a report. The most common governance hole isn't a missing control; it's an "owner" field with a name in it and nothing behind the name.
"Owner: Head of AI Engineering." Comforting on a slide. But when the agent mis-routes a case at 2am, nobody knows who decides, who can pull it, or who answers to the board. The name is decoration.
A named person with written responsibilities, decision rights, escalation triggers, a review cadence and the authority to throttle or stop the agent. Accountability that survives contact with a bad day.
What the role actually is
Five things, written down before go-live — not inferred after an incident:
No agent reaches production without a named agent manager and those five lines filled in — same status as a security sign-off. This is the 70% people-and-process layer made concrete: the cheapest, highest-leverage governance you can add, because every other control — identity, monitoring, thresholds — loses its teeth if no human is actually on the hook to act on it.
Every agent acts inside your systems as some identity. If that identity is a shared human login, or a long-lived service account nobody owns, you've created an ungoverned actor with standing access — one that acts on its own, around the clock, faster than anyone watching. Non-human identity is the discipline of governing the agent's own identity and secrets across its life.
A person logs in, does a few things, logs out. Access is occasional, attended, and tied to someone you can call. Offboarding happens when they leave.
Persistent — credentials live as long as the agent. Autonomous — it acts with no human at the keyboard. At scale — one pattern spins up many agents. None of the human assumptions hold.
The controls that close it
Not a new platform — a handful of controls wired to your existing IAM / PAM:
For every agent you put live, make someone answer: Does it have its own identity? Is there a rotation trigger? Is there a revocation path on decommission or incident? Three questions, every time, catch the failure modes that turn an agent into a standing breach. It's a control domain in your Operating Model and a line in every Assess governance pack — not a separate security product to buy.
The job of a new AI leader isn't to ship a few projects — it's to install the operating system the enterprise keeps running long after you. This is the guided version: score where your OS is today across the eight domains, see the load-bearing gaps, and get a 30/60/90 sequence to install it.
1 · Where's your AI operating system today?
Eight domains. Score each on evidence, not optimism — Missing · Ad-hoc · Defined (written down, owned) · Operating (running, with proof).
2 · Your 30 / 60 / 90 — install the OS
Not a project plan — the install sequence for the system above. Leaders who succeed treat the first 90 days as installing the OS, not delivering AI. 0 / 20 done
3 · Starter artifacts (you author, the suite structures)
The highest-leverage things to have on paper. The tool gives structure and makes them auditable; the content and the calls are yours.
Measure your own success by the quality and adoption of the operating system you leave behind — the one that keeps the enterprise getting better at AI long after you move on. Not the number of pilots you shipped.
The first thing a new AI leader owes the business is a translation: from business strategy into a handful of AI themes anyone can repeat. This is the canvas for it — a framing aid, not a strategy generator. You fill it; the discipline is in what you leave out.
The five boxes
Author this yourself, on one page, and socialize it before you rank a single use case — the themes become the lanes in Prioritize, and the north-star becomes the top line in Monitor. The tool structures it and makes it auditable; the judgment is yours.
One structural choice shapes everything: how central is the AI capability? Get it wrong and the CoE becomes the bottleneck every request queues behind. Answer four questions for a recommended shape — and the charter it needs whatever the answer.
Mission & mandate (why it exists, what it owns) · what the hub owns vs. the spokes · interfaces & hand-offs between them · decision rights (who decides what, alone vs. escalated) · funding model · and a maturity path (how governance becomes more self-service over time). In regulated firms, governance stays central regardless of the shape. The tool helps you choose the model and structure the charter — you still write the actual content.
You don’t author standards content in a tool — that’s engineering and policy work. But you do govern whether each standard exists, is owned, and is actually adopted. Score the six that matter; the gaps are your standards backlog.
CISO check — beyond these six: is your model-risk process visibly integrated with enterprise MRM / ERM (yes / partial / no)? That integration is what a regulator or CISO looks for first.
This governs the existence and adoption of standards — not their content. Owners in Engineering, Data, Security and Risk write the standards; you make sure each exists, has a name against it, and is actually used. Wire the security line to the non-human identity controls and the risk tiers in the Operating Model.
Production AI runs on a handful of hands-on activities — prompt libraries, reusable skills, evals, guardrails, RAG, fine-tuning, LLMOps, and the operating model that holds them together. Each is below in plain English, with an honest read of how hands-on a leader can be versus what they direct — because most of it involves far less "coding" than the word "engineer" implies.
1 · Prompt libraries & prompt management
Do it · little/no codeA versioned, shared collection of an org's best prompts — treated as reusable assets, not one-off chat messages.
2 · Skills & reusable assets (e.g. Claude skills)
Do it / Direct · markdown + sometimes light scriptsPackaged, reusable capabilities the AI is given once and reused everywhere — often shipped as "skills."
3 · Evals & evaluation
Direct it · design-led, light code to runHow a team proves an AI output is actually good — before it ships and continuously after. One of the most common technical gaps in AI programmes.
4 · Guardrails & hallucination / IP-risk control
Direct it · design-ledThe controls that keep an AI inside the lines — what it can say, do, see, and when a human must step in.
5 · RAG done right
Direct it · engineers build, the lead sets the barGrounding the model in internal content at answer time (covered conceptually in the Approach advisor — here's what "good" looks like in production).
6 · Fine-tuning — when it's actually worth it
Decide it · rarely done by handTraining a model further on curated examples so it absorbs a style, format or narrow behaviour. Here is the leader's call.
7 · LLMOps — running AI in production
Direct it · requirements-led, engineers run itEverything that keeps a deployed AI reliable, affordable and observable — sometimes called FMOps / LLMOps.
8 · Standing up an AI Center of Excellence
Do it · no code (this is the leadership job)The org design that turns scattered experiments into a production AI capability.
Five of the eight a leader can genuinely do hands-on — prompt libraries, skills, eval and guardrail design, and standing up the CoE. The code-heavy three — RAG, LLMOps, fine-tuning — a leader directs and judges rather than hand-codes, and even those increasingly have configure/low-code paths (the "configure before build" point). The job is knowing when each is the right tool, and whether it is any good — not writing the pipeline.