--- title: "AI Model Governance: Choosing by Workflow Risk" url: https://www.insulin.dev/blog/ai-model-governance-by-workflow-risk/ canonical: https://www.insulin.dev/blog/ai-model-governance-by-workflow-risk/ type: Blog description: "How to choose an AI model per workflow rather than company-wide: a policy matrix over task type, sensitivity, accuracy, latency, cost and fallback." --- # AI Model Governance: Choosing by Workflow Risk > Canonical HTML version: https://www.insulin.dev/blog/ai-model-governance-by-workflow-risk/ 1. [Home](/) 2. / 3. [Blog](/blog/) 4. / 5. AI Model Governance: Choosing by Workflow Risk # AI Model Governance: Choosing by Workflow Risk Picking one model for the whole company means overpaying for triage and under-thinking the work that matters. Choose per workflow, by what failure costs. ![Sophia Faria](/authors/sophia-faria.jpg) Sophia Faria Aug 27, 2026 ![AI Model Governance: Choosing by Workflow Risk](/images/blog/ai-model-governance-by-workflow-risk/hero.png) Explore AI Summary [![](/logos/company/openai.svg)](https://chat.openai.com/?q=Read%20and%20summarize%20https%3A%2F%2Fwww.insulin.dev%2Fblog%2Fai-model-governance-by-workflow-risk%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Trust%2C%20Agents. "Summarize with ChatGPT")[![](/logos/company/anthropic.svg) ](https://claude.ai/new?q=Read%20and%20summarize%20https%3A%2F%2Fwww.insulin.dev%2Fblog%2Fai-model-governance-by-workflow-risk%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Trust%2C%20Agents. "Summarize with Claude")[![](/logos/company/gemini.svg)](https://www.google.com/search?udm=50&aep=11&q=Read%20and%20summarize%20https%3A%2F%2Fwww.insulin.dev%2Fblog%2Fai-model-governance-by-workflow-risk%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Trust%2C%20Agents. "Summarize with Gemini")[](https://www.perplexity.ai/search/new?q=Read%20and%20summarize%20https%3A%2F%2Fwww.insulin.dev%2Fblog%2Fai-model-governance-by-workflow-risk%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Trust%2C%20Agents. "Summarize with Perplexity") Table of Contents - [Make it an agent-level decision](#make-it-an-agent-level-decision) - [The six dimensions worth writing down](#the-six-dimensions-worth-writing-down) - [Turn the scores into three tiers](#turn-the-scores-into-three-tiers) - [Write the fallback before you need it](#write-the-fallback-before-you-need-it) - [Frequently asked questions](#frequently-asked-questions) - [Takeaways](#takeaways) _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](/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](/jobs/) 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](/blog/ai-job-run-history-and-runs-table/). 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](/blog/ai-agent-failure-handling/), and the sourcing question — your own keys or managed — in [BYOK vs managed models](/blog/byok-vs-managed-models-for-enterprise-ai/). * * * ## 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](/agents/) are scoped, or [book a demo](/schedule-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](https://doc.suger.io/insulin/agents/) — Per-agent model selection and integration scoping — the level at which the policy below is applied. ## Keep reading - [TrustThe AI Agent Sandbox: Test Before ProductionAug 27, 2026](/blog/ai-agent-sandbox-before-production/) - [TrustHow to Design Human Handoffs for AI AgentsAug 24, 2026](/blog/designing-human-handoffs-for-ai-agents/) - [TrustHow to Evaluate AI Agents: A Business-Focused ScorecardAug 19, 2026](/blog/how-to-evaluate-ai-agents-a-business-focused-scorecard/) - [TrustHow to Test an AI Agent Before It Touches a Business SystemAug 19, 2026](/blog/how-to-test-an-ai-agent-before-it-touches-a-business-system/) [Browse every post on the Insulin Blog](/blog/) ### Stay Updated Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.