Ask a business today how their AI programme is going and you will usually hear about models and “benchmark maxxing”: which one they chose, how it scored, what the latest version improved. Ask what happens when the system meets a request its designers never anticipated, and the answers get vaguer.
That gap is where many deployments run into trouble. A model is a general capability. What turns it into something an organisation can put in front of customers, or let near a ledger, is everything wrapped around it: what it is allowed to do, what it knows about this particular business, how it weighs one outcome against another, and how it behaves when it is out of its depth. In many organisations those four things live in people’s heads, in scattered policy documents and in the habits of whoever built the pilot.
Security and compliance are where this catches up with you. In a pilot they are easy to defer, because the users are a small, willing group, the data is a sample, and the risk review is pencilled in for later. Once the system heads for production, the questions arrive together. Which data can it reach? Who approved its limits? What happens when it is wrong?
This is where many enterprise pilots stall. Trusting an AI system is easy to endorse in a steering committee and much harder to sign off on, and a team that cannot show how its system is controlled usually ends up rebuilding it.
The job of an AI delivery pipeline is to get those four things out of people’s heads and into something explicit, testable and owned. Mistral’s Forge material groups them as rules, knowledge, judgement and behaviour. The labels are theirs. What follows is how I would treat each one as a working principle, based on a decade of wins and losses selling and launching AI with enterprise buyers.
Rules are the boundaries the system cannot cross
Start by separating two things that policy documents tend to blur. Hard limits are what the system must never do, whatever the input and however persuasive the request: disclose another customer’s data, approve a payment above a threshold, give advice it is not licensed to give. Risk appetite is different. It covers what the system may do under conditions, such as answering a question if the source is current or taking an action if it can be undone.
Both need to live in the pipeline, not beside it. A policy saying the model “should not” do something is an aspiration. A constraint enforced outside the model, with test cases that try to break it and results someone has reviewed, is a control. The difference matters most under pressure, which is exactly when models are most likely to be talked into things.
Take a bank assistant told never to discuss a credit limit with anyone but the account holder. A persuasive caller can talk past a prompt. Nobody can talk past an identity check that runs before the model ever sees the number.
Knowledge is what the organisation knows and the model doesn’t
A general model knows a great deal about the world and nothing about how your firm actually works: the exception granted to a longstanding client, the reason a product is priced the way it is, the precedent that settles an ambiguous case. Much of that knowledge has never been written down, because the people who hold it never needed to.
Encoding it forces decisions that organisations usually avoid. Which source is authoritative when the policy manual and the operations wiki disagree? How old can a document be before it should not be relied on? Who is responsible for noticing that it has gone stale? A retrieval system will not answer these questions for you. It will retrieve whatever is there, and the model will present it with the same fluency whether it is current or three restructures out of date.
Picture a telco agent that follows its policy to the letter: verify the customer, check eligibility, recommend the best plan. Its catalogue does not show the customer’s existing contract, so it books an upgrade as a brand new subscription, and the customer ends up paying for two plans. Every rule held, and the knowledge failed.
So knowledge has to be treated as a governed asset, with owners, versions and review dates, rather than a pile of documents pointed at an index. The model’s confidence is not evidence of the source’s accuracy.
Judgement needs an explicit definition of good
Most real work is a series of tradeoffs: speed against thoroughness, coverage against caution, cost against the chance of being wrong. Experienced staff make these calls constantly and rarely articulate them. An AI system makes them too, and if nobody has stated how, it makes them in whatever way its training and prompt happen to imply.
Consider a Where Is My Order flow, known as WISMO in ecommerce customer service, with the right rules and data. It finds two records for the same order, created by a retry at checkout. One was dispatched and the other cancelled. Nothing tells it how to weigh records that conflict, or to hand this one to a person, so it guesses. The rules and data were sound. The decision about conflicts was just never made.
The fix is to define success before building, not after. What does a good outcome look like for this task, and who agrees? Which errors are tolerable? Above all, which mistakes are cheaper? Without that decision made up front, evaluation becomes interpretation. The results come in and the team argues about whether they are acceptable.
Written success criteria give the pipeline something to test against. They also give the business owner, rather than the build team, the final word on what acceptable means.
Behaviour is how it speaks and when it steps back
Tone is easy to dismiss as polish. It is not. The same correct answer can reassure or alarm, invite a further question or shut one down, depending on how it is phrased and who is reading it. Matching register to audience and stakes is a design decision, and it belongs in the specification.
The more important half of behaviour is escalation, which means the conditions under which the system stops and hands over to a person. Good escalation logic draws on the other three principles. It weighs confidence (does the system have reliable knowledge here?), stakes (how costly is a mistake?) and reversibility (can the action be undone?). An uncertain answer to a question with little at stake can go out with a caveat. An irreversible action on thin evidence should not happen without a human.
Imagine an internal IT agent configured to deflect tickets by pointing staff to fixes they can make themselves. A finance lead writes, tersely, that the payroll run has failed the night before payday. The agent replies with a cheerful troubleshooting checklist and logs a routine ticket. Nothing in its setup told it to read the urgency, match a terse register, or page the engineer on call when a critical workflow breaks. The model was capable of all three, but its configuration never asked for them.
A system that knows the limits of its competence, and says so, is worth more than one that is right slightly more often but never admits doubt. The first fails visibly. The second fails quietly, and quiet failures are the expensive ones.
How the four fit together
These are not four separate workstreams. Rules constrain judgement, knowledge feeds it, and behaviour is where all three reach the customer. As the examples show, a gap in one surfaces in another, so they belong in one pipeline, designed and tested together.
What enterprise ready should mean
None of this requires every principle to be built into the technical stack from the first release. A rule can be enforced through a reviewed process before it is enforced in code, and knowledge can be governed by named owners before it is governed by tooling. What it does require is that each principle exists somewhere, and is practised as strictly by people as it would be by software.
For many organisations that means disciplined governance of retrieval. The system draws only on approved sources, respects the access rights of the person asking, shows where each answer came from, and works from material someone reviews on a schedule. A pipeline with these fundamentals, in code or in practice, can make a credible claim to enterprise readiness. One without them cannot, however good the model inside it.
The question worth asking
The useful question about an AI deployment is rarely “which model?” It is whether the rules, knowledge, judgement and behaviour around that model have been made explicit enough to test. That is the difference between a demo and a system you can stand behind.
More about Mistral’s Forge is on Mistral’s website.
