AI model governance is the policy that decides which model powers each workflow, based on what the task requires and what a wrong answer would cost — rather than standardizing the whole company on one model.
Most companies make this decision once, badly, in both directions at the same time. They pick a single capable model and route everything through it, which means a query that classifies incoming email costs the same as one drafting a contract summary. Or they pick a cheap default and discover months later that the workflow nobody thought was important was the one generating customer-facing text.
Model choice is a per-workflow decision because the cost of being wrong is a per-workflow property. A misclassified support ticket is an annoyance. A wrong number in a board summary is not.
Make it an agent-level decision
The right unit for model policy is the agent, not the organization. An agent already has instructions describing its job and a scope describing what it may reach; the model is the third property of the same object.
This is how Insulin treats it — agents let you pick the model that suits the work, on the reasoning that a quick triage agent and a deep analysis agent do not need the same one. That framing is the useful part: you are not choosing a company model, you are choosing per job, and the job is already defined.
Which specific models are available to you, and the data-processing terms attached to each, depend on your configuration — confirm those before writing a policy that names any of them. What follows is the shape of the decision, not a recommendation of particular models.
The six dimensions worth writing down
A workable policy scores each workflow on six things. Most of them are not about capability.
Consequence of error. The first and heaviest. Does a wrong output get caught by a human immediately, or does it reach a customer, a record, or a decision?
Sensitivity of input. What is in the prompt. A workflow reading public documentation and one reading employee records are different governance problems regardless of which model handles them.
Accuracy and reasoning demand. How much genuine analysis the task needs — as opposed to how impressive we would like it to be.
Latency tolerance. Interactive chat and an overnight job have very different requirements, and the overnight one can afford the slower, more careful option.
Cost per run × frequency. The product, not either alone. A slightly more expensive model on a workflow that runs four times a day is noise; on one that runs forty thousand times, it is the budget.
Residency and processing terms. Where data may be processed, and under what commitments. This is often the binding constraint, and it is the one most likely to overrule everything above.
Turn the scores into three tiers
Do not build a matrix with twenty cells. Three tiers cover almost everything.
High-consequence work — customer-facing text, anything touching money, anything feeding a decision nobody will re-check. Use the most capable option available, keep approval on, and accept the cost. Frequency is low; it does not matter.
Routine work — classification, routing, extraction, summarizing for a human who will read the source anyway. Use the efficient option. This is the volume, and it is where model choice actually moves the bill.
Exploratory work — drafting, brainstorming, first passes a person will heavily edit. Cheapest defensible option; the human is the quality gate by construction.
The tier is set by consequence, and cost only chooses within a tier. Getting that order backwards — starting from budget and asking what you can afford — is how the customer-facing workflow ends up on the cheap default.
Write the fallback before you need it
Every tier needs a documented behaviour for when its model is unavailable or degraded. This is the part that gets skipped and the part that bites.
The wrong answer is silent downgrade — quietly routing a high-consequence workflow to a lesser model because the preferred one timed out, and nobody notices because the output still looks fine. That is worse than the workflow failing, because a failure is visible.
Decide explicitly per tier: retry, queue, fail loudly, or downgrade with a flag on the output and a note in the run history. For high-consequence work the answer is almost always fail loudly. How failures should be handled more generally is covered in AI agent failure handling, and the sourcing question — your own keys or managed — in BYOK vs managed models.
Frequently asked questions
What is AI model governance? The policy deciding which model powers each workflow, based on what the task requires and what a wrong answer costs — rather than standardizing the entire company on one model.
Why choose a model per workflow? Because the cost of error is a property of the workflow. A misclassified support ticket and a wrong figure in a board summary do not warrant the same model, or the same budget.
What should drive the choice? Consequence of error first, then input sensitivity, reasoning demand, latency tolerance, cost times frequency, and data residency. Consequence sets the tier; cost only chooses within it.
How many tiers do I need? Three is usually enough: high-consequence work on the most capable option with approval on, routine high-volume work on the efficient option, and exploratory drafting on the cheapest defensible one.
What happens when the chosen model is unavailable? Whatever you decided in advance. The failure mode to avoid is silent downgrade — for high-consequence work, fail loudly rather than quietly producing plausible output from a lesser model.
Takeaways
- Model choice belongs to the agent, alongside its instructions and its scope — not to the company.
- Score workflows on consequence of error, input sensitivity, reasoning demand, latency, cost times frequency, and residency.
- Three tiers is enough. Consequence sets the tier; cost only chooses within it.
- Starting from budget rather than consequence is how customer-facing work ends up on the cheap default.
- Write the unavailable-model behaviour per tier. Silent downgrade is worse than visible failure.
Set the model where the job is defined: see how agents are scoped, or book a demo.
Sources
Primary sources for the platform rules cited above. Last verified August 27, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure.
- Suger docs: Insulin agents — Per-agent model selection and integration scoping — the level at which the policy below is applied.
Keep reading
Stay Updated
Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.