Which Models for Which Work | AI Strategy

Buying AI used to mean picking a supplier: you signed for a model, handed out access, and called that the strategy. Buyers now choose among frontier proprietary systems, open-weight models, managed cloud services, local installs, specialized agents and suite copilots, and each comes with its own economics, oversight load, update cycle and failure modes. Treat them as interchangeable and you end up paying for an expensive default on every workflow while controlling very little of it.

The open-model debate doesn't help much when it comes to purchasing. One camp presents open weights as the route to competition and national autonomy. The other sees uncontrolled capability with security baggage. Both camps have a point, but the argument gives no rule for what to put on which workflow next Tuesday.

What you need is a model mix table, a plain record that assigns each task the capability, oversight and accountability it warrants. The evidence suggests those assignments will keep changing. Stanford Human-Centered AI Institute (HAI)'s 2026 AI Index shows the performance gap between leading U.S. and Chinese systems shrinking and agentic tools moving fast, while transparency for the strongest models remains patchy. The Organisation for Economic Co-operation and Development (OECD) has pointed out that "open source" doesn't transfer cleanly from ordinary software to foundation models, because openness comes in degrees. The National Telecommunications and Information Administration (NTIA) report on open weights reaches a similar conclusion: open models have real advantages, but governments and buyers still need to monitor them and be able to respond when risks shift. Organizations have to make the same call about their own use.

The strategic mistake is letting one model category quietly become the default for every kind of work.

Model choice is now a portfolio decision

For a founder or enterprise buyer, each model class has work it suits. A frontier API often fits tasks where reasoning depth, tool connections, vendor support and fast upgrades matter more than unit cost. An open-weight model often fits tasks where data location, customization, offline operation, cost stability or legal jurisdiction matter more than peak score. A bundled copilot suits work that already happens in email, documents, code repos, CRM or support software, and a smaller specialist model suits narrow, repetitive jobs where "good enough" really is enough.

Those assignments should move as prices fall, benchmarks flatten, internal data improves, rules become clearer and evidence of failures accumulates. Independent evaluators such as Artificial Analysis show how poorly annual procurement cycles fit this market, since quality, price, latency, context length and open-weight availability keep shifting. A model that looked inadequate last quarter may be fine now. One that looked cheap at the API layer can turn expensive once review effort, retries, context volume and agent loops appear in the real cost figures.

The executive's job is to keep model use from drifting into unmanaged infrastructure, so every AI workflow needs a written class, owner, rationale, fallback, review load and exit condition.

What to track

A useful model mix table groups work by who holds the decision rights over it.

Work Class	Likely Model Choice	Control Test	False Positive
Frontier judgment support	Frontier API or managed enterprise model	Does quality matter enough to justify premium cost and vendor dependency?	Using the best model because the task feels important but has no measured quality threshold.
Repeatable internal production	Open-weight, hosted open model, or smaller tuned model	Can the company govern data, cost, latency, and failure recovery better with more control?	Assuming self-hosting is cheaper while ignoring engineering, security, and evaluation work.
Office and workflow assistance	Suite copilot or application-native AI	Does the AI live where the work record, permissions, and audit trail already live?	Buying convenience that creates invisible shadow work and unclear responsibility.
Regulated or sensitive work	Constrained deployment with explicit assurance and human checkpoints	Can the buyer prove provenance, access control, monitoring, and rollback?	Treating a vendor security page as a substitute for workflow-level assurance.
Low-value commodity drafting	Cheapest adequate model or no model	Does the output save enough time after review to justify any AI path?	Automating marginal work because the marginal token price looks low.

What "open" can mean for a model

"Open-source AI" bundles several different claims. A model might disclose its code, weights, architecture, training data, evaluations, prompts or deployment steps, or only some of those. Research use might be allowed while commercial use is barred. Downloading can be easy while running at scale is hard, and experimenting can be easy while the data sources, safety tests and training provenance stay murky.

The OECD's terminology warning applies here. Software source code can be inspected, changed and redistributed under known rules. Model "openness" often means you get the weights without a full account of how they were produced, what data shaped them, or how behavior will shift after later fine-tunes.

Openness is better scored against purpose: is the access you get enough for the job you intend to run?

What sovereignty actually requires

Governments and large organizations want more say over data flows, domestic capability, regulatory compliance and supply dependence, and sovereignty arguments now carry real weight in these decisions. Linux Foundation research on sovereign AI notes that open source is often presented as a foundation for autonomy because it offers flexibility and visibility. Organizations operating across borders should take that seriously and not dismiss it as politics.

Sovereignty can still become a posture with little behind it. An organization can declare the goal while depending on foreign chips, clouds, advisers and model updates, with an internal team too thin to assess or maintain the stack. Hosting locally or running open weights doesn't settle the matter on its own. What counts is whether you can run, examine, update, secure and exit the system without unacceptable reliance on someone else.

Smaller companies rarely need a national position. They need to be able to move data when they must, set control points, manage suppliers and keep costs from drifting.

Where the cost goes with open weights

Open-weight models can cut the sticker price of capability, but the cost moves elsewhere: per-token spend turns into hosting, GPUs, engineering time, monitoring, evaluation, compliance and incident handling. The trade sometimes pays off; in other cases it duplicates infrastructure you didn't need.

A cost table should carry six lines: model access, compute, integration, evaluation, review effort and switching cost. When those stay hidden, buyers end up comparing brochure prices.

Frontier providers still make a clean case in many situations. A closed model can be the rational choice when the vendor carries the infrastructure load, ships updates quickly, offers enterprise controls and gives you a real support path. Closed doesn't mean worse, and open doesn't mean cheap. Weigh the control you gain against the operational load you take on.

A written record for each production workflow

The National Institute of Standards and Technology (NIST) AI Risk Management Framework and Generative AI Profile set out a simple sequence: govern, map, measure, manage. Applied to model selection, it means every production workflow needs a short record of its own.

Name the work this model performs.
State why this model class beats a cheaper, more controlled or more capable alternative.
List the data allowed into the model and the data forbidden from it.
Set the quality threshold that justifies production use.
Measure the review burden the workflow creates.
Define the failure that triggers rollback, replacement or human-only operation.
Name the owner of the next model-mix review.

The last item is the one people skip. A sound choice in January can be waste by July, and without a scheduled check the mix keeps encoding assumptions that no longer hold.

What to ask the AI team for

Don't accept a single-model plan. Ask for a model mix table covering the ten workflows where AI use actually matters, and for each one require the model class, rationale, cost line, control line, quality threshold, data scope, review load, fallback and next review date.

Then look at the overall shape. Frontier models on every workflow suggest nobody is watching cost. Open weights everywhere can mean control is standing in for quality or support. Suite copilots on everything can hand the application vendor quiet ownership of the record of future work. And if no category of work is marked "no model," governance is incomplete.

A sound portfolio puts frontier capability where it changes judgment, open and smaller models where control and economics dominate, and vendor bundles where the workflow record already lives, with AI declined wherever review effort exceeds the return. Because capability in that portfolio is rented and control has to be maintained, every default assignment should carry a review date, so it gets rechecked before something breaks.