Constraining a model to your company's methodology is not writing a better prompt or training your own model — it is taking out of its hands whatever cannot go wrong. Four layers: the method written outside the prompt and read at run time, the arithmetic in code, the banned list along with the vocabulary that replaces it, and a brake that stops the action instead of asking for good behaviour. In the Sistema Cuidar report that means AI writes 5 of the 15 sections and not a single number in the document came from a language model.
Why AI delivers good work that is of no use#
The most common complaint from people who started using AI at work is not that it gets things wrong. It is that it gets right something that is not yours: the text is well written, the structure is reasonable — and that is not how your company does it.
The reason is simple. A language model returns something close to the average of what has been published on the subject, and your method has not been published: it lives in two or three people's heads, in an outdated document and in a pile of decisions nobody wrote down. Asking "do it our way" of something that has never seen your way returns everybody's way.
Constraining a model to a methodology is how you fix that — and the answer is not a better prompt. It is four layers, in order of cost:
- The method written down outside the prompt, and read at run time.
- The arithmetic in code, out of the model's hands.
- The banned list, along with the vocabulary that replaces it.
- A brake that stops the action, for whatever cannot depend on goodwill.
| Layer | What it prevents | What it costs | What happens without it |
|---|---|---|---|
| Method written outside the prompt | an answer at the market average | writing the method — the real bottleneck | the model invents a plausible standard and you review everything, always |
| Arithmetic in code | invented numbers | modelling the calculation once | the text sounds convincing and the maths is wrong |
| Banned list + mandatory vocabulary | generic wording, fabricated references | one pass by someone who knows the field | the result reads well and no specialist can sign it |
| Brake that stops the action | the irreversible action | very little — and it is the most forgotten layer | an ignored instruction becomes real damage, and the client tells you first |
If the method is not written down, there is nothing to constrain#
Constraining means comparing against a reference. With no written reference there is no constraint — there is a request, and the model fulfils the request by filling the gap with whatever looks right.
This is the step almost everyone skips, because there is nothing technological about it. In our operation it took the shape of 26 written methodologies — scope, estimation, interface planning, code review, notification maps, legal documents, and so on — executed by 28 commands that do not carry the method inside them: they read the matching methodology at the moment they run (figures for August 2026).
Here is the confession that closes the argument: we designed an internal product and stopped before building it, because the methodology it was supposed to police had not been validated in the field yet. Without it, the product would be a generic chat listening in on a meeting — impressive in a demo, useless when rigour is what you need. The software was the easy part.
The test, before buying any AI layer: could someone new to the company execute this process reading only what is written down? If the answer is no, the model will not either. It will just get it wrong faster, and with more confidence.
The ruler lives outside the prompt, and is read at run time#
There are two ways to give a method to an AI agent. The first is to write the method inside the prompt. The second is to write the method in a document and instruct the agent to read that document when it performs the task.
It looks like an implementation detail, and it is one of the most consequential decisions in the architecture. We made it formally, and the reason is duplication: when the method lives in two places, one of them ages. The rule changes in the document, the prompt keeps applying the previous version, and nothing warns you — the output still looks correct, because it is correct with respect to a rule that no longer holds.
In practice the agent is just an orchestrator: it asks, reads the inputs, validates and generates. The method lives in the document — change the standard and you change it in one place.
The second effect matters even more: the method stays readable for people who do not touch prompts. The person who owns the subject — the psychologist, the auditor, the salesperson — can open the document, disagree, correct it. A method buried inside a prompt becomes the property of whoever writes prompts, and that is how a company's process ends up depending on someone in technology to change its mind.
One technique comes cheap with this architecture: have the agent generate and, in the same turn, review what it generated against the method's own checklist. Generating without reviewing produces work that passes a glance and fails the criteria — and a model is far better at finding what is missing from a finished text than at not forgetting while it writes.
Take the arithmetic out of the model's hands#
This is the layer that separates serious use from a demo, and it comes down to one sentence: if a wrong number has consequences, that number cannot come out of a language model.
Sistema Cuidar, which we built for an occupational health and safety consultancy, is the direct example. The report has 15 sections; AI writes five. The risk matrix, the classification by factor and the charts are calculated from the collected data, deterministically — the model does not touch them. It writes the technical interpretation on top of the already calculated result. That is what makes the document signable by a technical lead: no number in the report came from a language model.
The cheapest version of this layer is constraint by absence, and it is worth copying: do not give the model the data it must not use. Nicky, the support agent we put on the WhatsApp line of Agência OKSE, does not talk about pricing — not because some instruction says "do not discuss prices", but because the agency has no service with a list price and therefore there is no price anywhere in the material she reads. Her content was rebuilt from the agency's official material: positioning, services, frequently asked questions and the real client stories. What is not in there, she has no way of saying.
An instruction that forbids reduces the chance. Absence of the data removes the possibility. Whenever you can pick the second, pick the second.
The banned list — and the vocabulary that replaces it#
Banning without replacing does not work. A model told "do not use vague language" produces different vague language, because it has nothing to put in its place. The list that works has two columns: what is forbidden and what is mandatory.
In the Cuidar report, shallow HR vocabulary is vetoed — "bad climate", "toxic leadership", "lack of resilience" — and auditable occupational terminology is imposed: "low predictability of demands", "role ambiguity", "imbalance between demands and resources". The same list forbids citing any author or reference that is not in the supplied material, which is the most common way an AI-written technical text falls apart on the first check.
The gain is not only stylistic. A list like that is verifiable: you can search the text for a forbidden term and know, in seconds, whether the ruler was respected. A subjective instruction ("write with technical rigour") cannot be verified, and what cannot be verified cannot be enforced.
What instruction cannot guarantee, code can#
Here is the layer almost nobody builds, and the cheapest of them all.
Every rule inside a prompt is a request. A well-written request is honoured almost always — and "almost always" is not a word that works when the action is irreversible. Prose is not enforcement. Whatever must never happen needs something that stops it, not something that asks.
And it is not only about the model failing on its own. The OWASP Top 10 for Large Language Model Applications opens with LLM01: Prompt Injection — text arriving from outside can redirect the model's behaviour. Which means an instruction inside the prompt is attack surface, not a guarantee. If the rule genuinely matters, it cannot live in the same place user content comes in.
In our operation this layer is a policy with a one-line ruler — internal and reversible is free; external or irreversible needs approval — plus a brake in code that applies it: it intercepts the action before it happens and asks for approval instead of denying silently. Two design choices deserve a note, because they are what keeps the brake alive day to day: asking for approval instead of blocking keeps the work flowing, and the brake is tolerant of its own failure — if it breaks, work continues, because a brake that halts the operation gets switched off in the first week and never comes back.
On the client side the same logic shows up in mundane decisions. Nicky never starts a conversation — that is not a good-behaviour instruction, it is an operation designed to be purely inbound. Each contact has its own queue, so two messages in a row do not produce two answers. And she identifies herself as a virtual assistant when asked — this is the honest part of the story: the prototype told her to dodge that question, and it was removed before the agent went live. We found it by reading the prompt, not through a client complaint.
The question that sums up the layer, worth asking of every "never" on your list: if the model does it anyway, how do I find out? If the answer is "from the client", the rule needs code.
| Real constraint | How it was implemented | Layer |
|---|---|---|
| The report cannot contain invented numbers | the maths is code; AI writes the interpretation on top of it | arithmetic in code |
| The agent cannot discuss pricing | there is no price in the material it reads | arithmetic in code (by absence) |
| The report cannot read like motivational text | list of forbidden terms + mandatory terminology | banned list |
| The agent cannot approach anyone | inbound-only operation, no ability to start a conversation | brake in the architecture |
| The agent cannot pass for human | identifies itself as a virtual assistant when asked | explicit rule, verified in the prompt review |
| AI does not publish or send anything outward without approval | brake that intercepts the action and asks for approval | brake in code |
When constraining is not worth it#
Constraining costs the work of writing the method, and there are cases where that cost does not pay off:
- When the task has no fixed shape. Drafts, exploration, the first version of an idea, meeting notes for your own use. There the variety of the answer is its usefulness, and imposing a ruler is bureaucracy.
- When being wrong has no consequence. If the worst outcome is that somebody redoes it, four layers are too expensive for the risk.
- When the process is going to change next month. Writing a method on unstable ground produces a document nobody follows — neither person nor model.
And the honest limit, worth stating plainly: constraining does not make the output right. It makes the output auditable. Human review stays, and in a technical context it stays with whoever signs. What changes is where that person spends time — in Cuidar, the technical lead moved to reviewing and signing instead of compiling spreadsheets and typing text. That is a big change, and it is not the same thing as no review at all.
It is also worth saying where we ourselves fall short. The NIST AI Risk Management Framework, published by the American standards institute in January 2023, organises AI risk management into four functions: Govern, Map, Measure and Manage. The four layers described here cover Govern and Manage well — the ruler is written and the brake exists. Measure is the one missing: systematically measuring how closely what the model produces adheres to the method is work we have not done, and we know of nobody in our market who has. Anyone assembling this now should assemble the measurement alongside it, not afterwards.
Finally, what these layers are not: they do not require training your own model. Fine-tuning adjusts style and format; it does not fix wrong arithmetic or an improper action, which are the two problems that get AI thrown out of a serious process.
Frequently asked questions#
Do I need to train my own model for it to follow my process?#
In most cases, no. Training adjusts the style and format of the answer, but it guarantees neither that the arithmetic is right nor that the forbidden action will not happen — and it costs data, time and maintenance every time the process changes. The four layers that actually solve it are architectural: method written outside the prompt, arithmetic in code, a banned list and a brake that stops the action. We work this way every day, in internal and client products, without training a single model.
Won't a well-written prompt do the job?#
It works for the first week. What breaks later is duplication: when the method is written inside the prompt it exists in two places, and the day the rule changes in the document the prompt keeps applying the old version — silently, looking correct. That is why the ruler lives outside the prompt, in a single document, and the agent is instructed to read that document when it runs.
How do I stop AI from inventing numbers?#
By taking the numbers out of its hands. Arithmetic is code: the calculation, the classification and the charts come from the data, deterministically, and the model writes the interpretation on top of the result. Telling a model not to invent data reduces the problem but does not remove it — as long as it can write a number, a wrong number is possible. When it cannot, it stops being possible.
Can AI be used in a technical document somebody has to sign?#
Yes, under three conditions: no number in the document coming from the model, grounding restricted to a named reference set (no citing an author that is not in it) and human review by whoever signs. What does not change is responsibility — it stays entirely with the signer. What changes is where that person spends time: reviewing instead of typing.
How long does it take to constrain AI to my method?#
The bottleneck is not technical. Anyone who already has the process written down — genuinely written, at the level where a new hire could execute it by reading — assembles the layers in days. Anyone who does not needs the time it takes to write the method, and that is the real work. Which is why the right question before buying any AI layer is: is our way of doing this written down anywhere?
Sources#
- OWASP — "Top 10 for Large Language Model Applications", whose first entry is LLM01: Prompt Injection — https://owasp.org/www-project-top-10-for-large-language-model-applications/
- NIST — "AI Risk Management Framework" (AI RMF), published in January 2023, with the Govern, Map, Measure and Manage functions — https://www.nist.gov/itl/ai-risk-management-framework
Next step#
If you are considering putting AI into a process that has consequences, the first move is not choosing a tool: it is checking whether the method is written down well enough to be enforced. That work is what holds the four layers up, and it is what we do in AI and automation — from the technical report in Sistema Cuidar to the support agent at Agência OKSE. And if what you have today is a product already built by AI with none of these layers, that is a different subject: what can be salvaged from AI-generated code.