At Deluxe, a Minneapolis-based payments and data company, a line of code never goes straight to an AI model. It’s routed through a gateway, which decides which AI to send it to. Depending on which of the platform’s 50-plus AI agents is doing the work, that gateway might route the request to GPT-5.6, Claude Opus, Claude Sonnet or to a model still being evaluated. The developer doesn’t choose. Neither, exactly, does IT.
“Put a gateway between your applications and your models before you scale, not after,” said Yogaraj Jayaprakasam, chief technology and digital officer at Deluxe. It’s straightforward advice that could help companies avoid building distinctgovernance and security controlsmodel by model after the fact.
Most CIOs have already decided to support more than one AI model. What‘s still being sorted out is who decides which model handles what task, and how those decisions evolve as the models, workflows and economics shift under it.
Who sets the rules, who picks the model
Sumeet Mahajan, a partner of AI and data at accounting and advisory firm Grant Thornton, said he sees model assignments as two decisions masquerading as one. “The first is the standing policy: which models are approved, how requests route between them, who pays for it,” he said. “The second is the local design decision: which model handles a given task.”
Within organizations doing this well, a central platform team owns the routing layer, Mahajan said. The business unit running the workflow makes the task-level call, using criteria the platform team sets.
Deluxe uses a similar approach. An AI governance council decides whether a use case is permitted; it weighs security, legal, compliance, data and responsible AI rules. Once the use case clears that bar, the leader accountable for the business outcome picks the model and owns the results.
“Governance establishes what is permissible and what evidence is required,” Jayaprakasam said. “It does not act as a model selection committee.”
Different groups can feed into the model-assignment decision, but only one person should be accountable for it, said Michael Adler, director of AI governance and data protection at the law firm Akerman. In the strongest setups, technical teams test performance and integration, while legal, privacy and risk set the limits, he said. For each deployment, one person should own the routing decision and have the authority to pause the deployment if something goes wrong.
At Merchants Fleet, a New Hampshire-based fleet management and leasing company, a group called the Artificial Intelligence Readiness Council sets the guardrails for AI use across the company. Then, business leaders make the task-level calls within them. The intent, said Chief Technology and Digital Officer Jeanine Charlton, is to “enable rather than gatekeep, register rather than repeatedly re-review and apply scrutiny in proportion to the risk of the use case.”
What public benchmarks miss
When companies decide which model should handle a task, cost is always part of the conversation. But it’s rarely the deciding factor.
Five elements govern model choice at Deluxe: quality, risk, latency, economics and operability. The weighting changes by workload, but economics is the one that surprises people. “A cheaper model that generates more retries, exceptions or human intervention is often the more expensive model,” Jayaprakasam said.
Adler explained, “More sophisticated organizations treat model selection as fit for purpose, not best in show.” Before it’s considered for a task, a model should clear a set of baseline requirements in the areas of confidentiality, data retention and contract terms. Fail one of those, he said, and the model should be out, regardless of price. Only then is the actual task evaluated based on quality, failure modes, latency and the risk of vendor lock-in. Even the setup around the model matters, not just the model itself.
Mahajan of Grant Thornton advised looking at the data before considering the model.
Sensitive or regulated data should go only to models that an organization can host or tightly contract, he said. Then it’s time to determine task fit
Public benchmarks keep evolving, Mahajan said, and score most leading models similarly. They’re also easy to game. It’s useful to build an internal benchmark drawn from cases where a model has already failed in production and then score every candidate model against it, he said. A model that tops the public rankings but fails a private benchmark doesn’t get used.
Between the models
When a multimodel workflow fails, the problem typically isn’t any one model. It’s issues at the seams.
Each AI vendor logs its own calls in its own format, Adler said. One might capture the full prompt and response. Another keeps only metadata. A third system handles tool calls entirely, on its own clock. “The result is an abundance of logs with no single record of what happened,” Adler explained.
Mahajan said he has seen this happen in incident response. Yet just one in five organizations has a tested incident playbook for a model failure, according to Grant Thornton’s most recentAI Impact Surveyof 950 senior IT leaders. An even bigger issue is that those plans were built to handle a single model failure, not multiple models failing together across a handoff, Mahajan said.
The solution is an independent record that sits above vendor logs and follows a request across every move it makes. Deluxe builds that into its AI gateway by default. Governance, in other words, has to follow the workflow. It can’t stop at the edge of a model.
No decision is final
Quality, drift and economics are watched continuously at Deluxe, and a new model release triggers evaluation. Adler recommended two kinds of review: a scheduled one that happens more often for higher-stakes deployments, and an event-driven one that happens when a model version changes, an incident occurs or a credible new challenger clears a predefined bar.
“Newer is a reason to test,” he said, “not a reason to switch.” A model, Jayaprakasam agreed, keeps its role if it continues to earn it.
That kind of ongoing evaluation is itself new work. When a company is running one model, the vendor handles the integration. When several models are operating in production, that work becomes the enterprise’s own. At Deluxe, that means new skills: model evaluation,agent design, workflow orchestration and cost management.
It also means two distinct jobs: Platform teams build the tools and the guardrails; product teams own adoption and outcomes.
“The model can change,” Jayaprakasam said. “But accountability for the workflow and its outcome cannot.”
