The Governed AI Lexicon

Enterprise AI conversations fail on vocabulary more often than on substance. Someone says guardrails and means three different things depending on the room. Someone says evals and the other person hears testing. A senior operator who understands the underlying problem perfectly gets talked past because the words moved faster than the practice did.

This is the working vocabulary, organised into the six areas these conversations actually live in. Each entry gives the definition, what an institution is genuinely worried about underneath it, and what it costs to do properly, because a term you cannot price is a term you cannot make a decision about.

Two notes on how to read it. Nothing here is proprietary or novel; these are the field's terms and we are defining them, not claiming them. And where a control is commonly misunderstood, the entry says so directly rather than staying neutral, because the misunderstandings are where the money gets lost.

Agent. A model that does more than answer: it plans, calls tools, takes multi-step actions, and often delegates. The word gets stretched to cover anything with a loop, so when someone says agent, ask what it can actually do to the world. That answer, not the architecture, is what determines the governance you need.

Orchestrator and worker. A coordinating layer routes work to specialists rather than one model attempting everything. Worth caring about because a single general-purpose assistant degrades as its task space widens: context is finite, and an assistant holding engineering conventions, brand voice, and security rules at once holds all of them badly.

Routing by intent. Sending work to the right capability based on what the person is trying to do rather than requiring them to name a tool. This is the difference between a platform and a toolbox, and it is the control that decides adoption, because if discovery is the user's problem they will use the two capabilities they already know and ignore the rest.

Capability registry. A versioned, owned, discoverable record of what the system can do and when that changed. Unglamorous, and it is what makes everything else auditable, because you cannot explain a decision from fourteen months ago without knowing what the system could do that day.

Model Context Protocol, or MCP. An open standard for exposing tools and data to models through a uniform interface, so a capability is built once and consumed by any compatible client. Introduced in late 2024, so nobody has years of experience with it. What institutions worry about is not the protocol but what it makes easy: agents reaching internal systems.

Least privilege. An agent holds only the tools its job requires. Obvious in principle, routinely violated in practice, because the convenient thing is to give the agent broad access once and stop thinking about it. This is the single cheapest control in this document and the one most often skipped.

Identity propagation. When an agent acts, whose identity is it acting under: its own, the user's, or a service account? This is the unsolved problem in enterprise agent deployment. Get it wrong and your audit trail says a robot did it, which is not an answer anyone can accept.

Circuit breaker. After N failed attempts at the same problem, stop generating variations and escalate, on the theory that the model of the problem is wrong rather than the attempt. Cheap to build, and the real design work is deciding what counts as the same problem. Prevents the most expensive failure mode in agent systems, which is confident repetition.

Context economy. Managing what occupies the model's working memory. Delegation is supposed to save context and frequently floods it instead, because a sub-agent returns everything it saw. The discipline is a return budget: findings come back, transcripts do not.

Retrieval-augmented generation, or RAG. Grounding a model's answers in your own documents by finding relevant material and supplying it as context. The dominant enterprise pattern, because it uses your data without training on it. The mistake is treating it as a search problem. It is a permissions and freshness problem wearing a search costume.

Embeddings and vector search. Text converted into numeric vectors so similarity can be computed, stored in a database built for that comparison. Genuinely useful, and the least important decision in the stack. Which vector database you choose will matter less than how you chunk, who is allowed to retrieve, and what happens when a source changes.

Chunking. How documents get split before indexing. Determines retrieval quality more than model choice does, and it is where most disappointing RAG systems actually went wrong. Split a contract mid-clause and you will retrieve half an obligation with the negation in the other half.

Hybrid retrieval. Combining keyword and semantic search, because pure vector search fails on exact strings: account numbers, error codes, product SKUs, surnames. If your users search for identifiers and your retrieval is semantic-only, it will feel broken in a way nobody can articulate.

Entitlement. Whether this particular user is permitted to see the source a retrieval returned. A recurring and expensive enterprise RAG failure, because a system indexed across a whole document store will happily ground an answer in a document the asker was never cleared for. The index has to carry permissions and enforce them per user at query time, which is meaningfully harder than building the index.

Freshness and invalidation. What happens when a source document changes or is deleted. Deletion is the hard case: a right-to-erasure request has to propagate to the chunks, the embeddings, any cache, and anything fine-tuned on it. That mapping from source to derived artifact must be maintained at ingest, because it cannot be reconstructed afterwards.

Lineage. Being able to trace a generated answer back to the specific source document and version that produced it. This is what makes a generated answer defensible rather than merely plausible, and it is the difference between an interesting demo and something a regulated business can use.

Prompt injection. Instructions hidden inside content the model was asked to read: an email body, an uploaded document, a scraped page, a transcript. The realistic threat to any agent that reads external content and can also act. There is no reliable model-level fix, which is why the control is architectural.

Untrusted-input isolation. The reader of attacker-controllable content runs as a separate agent with read-only tools, returning structured data, instructed that its input is data and never instructions. The point is not to stop the injection from succeeding. It is to arrange for the success to be irrelevant, because it lands somewhere with no authority.

Guardrails. Runtime filters on inputs and outputs: blocking harmful content, PII leakage, off-topic responses. Distinct from evals, which measure quality offline. Guardrails act in the request path and therefore cost latency on every call. People conflate the two constantly and end up with neither.

Provenance. Requiring that every claim trace to a source, enforced as a gate rather than a preference. In financial services this is model risk management applied to generated text. Note carefully that provenance proves where an answer came from and says nothing about whether the reader was entitled to it. Those are different controls solving different problems.

Blast radius. How far the damage reaches if an action is wrong. Together with reversibility, this is what should decide autonomy, rather than how capable the model seems.

Reversibility. Whether an action can be undone. The correct axis for autonomy decisions: reversible and contained actions should run alone, and anything irreversible or wide should not. Hard and reversible is safer than easy and permanent.

Propose, confirm, execute. The agent states what it intends, shows a dry run of exactly what would change, and a human confirms before it acts. The right pattern for the small number of actions that send money, delete records, or reach a customer, and the wrong pattern for everything else, because a gate on a reversible action is pure friction and friction sends people around the paved road.

Paved road. The governed path made the fastest path. If the compliant route is slower than the workaround, people take the workaround and your controls become decoration. This is the whole adoption strategy for an internal platform compressed into two words.

Evals. Systematic measurement of output quality against fixed tasks and written criteria. The promotion gate for AI changes and the answer to the only question that matters after a prompt edit: did this make it better or worse? Without evals every change ships on the author's confidence. Most organisations know they need this and have not built it.

Golden set. The fixed collection of tasks with known-good expectations that an eval runs against. Authoring realistic ones is the expensive part of evaluation, not writing the runner.

Held-out split. Tasks deliberately kept out of the tuning loop, so prompts cannot be quietly optimised against the test. Without it, your eval score measures how well you have fit your own exam.

LLM as judge. Using a model to score another model's output against a rubric. Practical and necessary at scale, and it is not deterministic. Measure your judge's variance on unchanged inputs before you interpret any single delta, or you will celebrate weather.

Measured zero versus not instrumented. A dashboard reading zero failures means nothing until you know whether the system measured zero or measured nothing. These look identical on a chart and mean opposite things. An instrument should be able to report that it is not currently instrumented.

Evidence rule. No completion claim without fresh proof produced in the current pass. A component reporting its own success is a claim, not evidence. This one is learned expensively: agents will report clean work that is not clean, and the fix is structural, moving the check to something other than the thing being checked.

First-pass yield. The share of work that clears the process without rework. Borrowed from manufacturing and the most useful single metric for an AI pipeline, because it measures quality rather than volume and it is instantly legible to any operations leader.

Telemetry. What ran, what it cost, what was retrieved, what the human decided. The evidence has to be a byproduct of running the system, not assembled afterwards for an examiner, because a trail reconstructed on request is not a control.

Model tiering. Routing work to the cheapest model that can do it. Every vendor will sell you this and it is genuinely worth doing.

Quality floor. The categories that may never be downgraded regardless of budget pressure: security review, adversarial testing, architecture decisions, final synthesis. This is the half of tiering nobody sells, and it is the half that matters. Cost optimisation that can silently degrade a security review is not optimisation. It is undisclosed risk transfer.

Chargeback and showback. Attributing AI spend to the team that incurred it, either as a real internal charge or as visibility only. The control that stops adoption and budget failure from becoming the same event. Finance will eventually ask who consumed what; the platform should be able to answer before they ask.

FinOps for AI. The general discipline of making AI spend visible, attributable, and controllable. Its distinguishing feature versus ordinary cloud FinOps is that consumption scales with human enthusiasm rather than with traffic, which makes it much harder to forecast.

Nothing in this section is legal advice, and each of these is worth reading in the original rather than through a summary. What follows is what each one is for, so you can tell which conversation you are in.

Model risk management, commonly referenced in US banking through supervisory guidance SR 11-7. Requires that models be documented, independently validated, and monitored. Generative AI strains it because outputs are non-deterministic and because the model is not just the weights: it is the prompt, the retrieval, and the configuration together.

The NIST AI Risk Management Framework. A voluntary US framework organised around four functions: Govern, Map, Measure, Manage. Its real value is as shared vocabulary. When two teams disagree about AI risk, this gives them the same four boxes to disagree inside.

The EU AI Act. Risk-tiered regulation, from prohibited uses through high-risk to limited and minimal, with obligations scaling by tier. It reaches beyond the EU, so it matters to organisations that do not consider themselves European. The first question it asks of any system is which tier it sits in, and that answer drives everything else.

ISO/IEC 42001. A management-system standard for AI, and the certifiable one. If someone in your organisation is asking how to demonstrate governance to a customer rather than to a regulator, this is usually the conversation they are actually in.

The practical point across all four: they overlap heavily and they are not substitutes. An organisation typically needs the model risk discipline for its regulator, the NIST vocabulary for its internal debate, the EU tiering to know its obligations, and the ISO standard when a customer asks for proof.

Most of the value in this vocabulary is in a handful of distinctions that get collapsed. Four are worth holding onto specifically.

Provenance is not entitlement. One proves where an answer came from; the other decides whether this reader was allowed to see it. A system can be perfectly cited and still be a data breach.

Guardrails are not evals. One filters in the request path and costs latency on every call; the other measures quality offline and gates changes. Buying one and believing you have the other is common and expensive.

Measured zero is not not-instrumented. The most dangerous number is the plausible one from an instrument nobody has verified.

Available is not enforced. A control that can be skipped by the person it inconveniences is a suggestion. This is the difference between a governance programme that works and one that exists.

If you take one thing from the whole document, take the question rather than the terms: for any control in your organisation, when did it last produce a result someone independently confirmed was correct, and how would you know if it had quietly stopped working?