What does it take to make enterprise AI work?

AI can produce an impressive answer within seconds, but deciding whether a business can rely on said answer requires a whole lot more work. 

At the first Toloka Talks in San Francisco, leaders from Shopify, Google Cloud, Fireworks AI and UPS took us inside their businesses to share how they’re making those decisions and the lessons learned when AI goes live.

The conversation centered on two big questions: When does a business need a specialized model, and how do you know it works?

TL;DR

• Define successful work before choosing a model, test against problems your business encounters, and measure cost per correct outcome.

• Use specialized models for high-volume, repeatable tasks. When evaluating agents, inspect their trajectory, not just the final output.

• Leverage self-service tools for easier deployment, but rely on human expertise to drive evaluation.

Define what a correct outcome looks like

One example shared during the discussion involved a model that performed well on public benchmarks but struggled with delivery charges. The model confused fuel surcharges and residential surcharges, which are treated differently in billing.

The takeaway was to define how you evaluate success before choosing a model. Having a clear idea of the required outcome makes the model decision easier while providing teams with a way to test the details general benchmarks don’t cover.

The same thinking applies to measuring value, with “cost per correct outcome” offering a way to assess what a business gets for its money. A low token price offers limited reassurance if the model repeatedly produces answers the business can’t use. Measuring the cost of successful work gives you a more meaningful basis for comparing the options on the table.

Build tests around the problems your business encounters

Past coding mistakes can help you test how well AI models identify problems. One approach discussed involved assembling a dataset of code changes that had caused production incidents, then testing models against those examples.

The evaluation measures which known problems a model identifies, alongside the issues it misses and the false alarms raised. Results from this approach were reported to correlate closely with performance in everyday coding work. Past failures can become a way to assess whether a model can recognize the problems engineers need to avoid.

The same principle applies beyond coding. Much of the knowledge needed to complete an enterprise task lies in internal systems or correspondence. Company policies also shape what counts as an acceptable answer—you need to test whether a model can apply internal knowledge and follow company policies before relying on it for business tasks.

Repeated tasks create a case for specialization

An approach discussed during the session was to use closed models for early experiments and move to fine-tuned models as tasks become more repetitive and volumes grow.

Product attribute normalization offers one example of this. Recognizing “black” and “noir” as the same color sounds straightforward, but repeating the task across millions of product listings needs more processing power.

Specializing a model for such tasks can improve quality while supporting much greater throughput. Lower costs add to the appeal.

When it comes to defining what customers value in a model’s output, the task becomes more difficult. For instance, they may love a frontier model’s answers without being able to explain exactly why. You’d need to identify which qualities hold weight with customers so you can judge whether a specialized model delivers the same quality.

Evaluate how agents reach an answer

Agents make evaluation more demanding because the final answer tells you only part of the story. Teams need to examine an agent’s trajectory, including whether it followed the required steps. A correct result may conceal an omission earlier in the workflow.

The discussion also pointed toward continued use of different models across a business, combining closed models with fine-tuned ones for work that is repeatable at scale. These decisions depend on evidence about each task, with evaluation continuing as the system changes.

Make room for human expertise

Could deployment eventually become fully self-service? Some teams have the expertise to manage their own deployments and can benefit from self-service tools, while others need engineers to understand the business process and establish the right measures.

Working closely with customers helps uncover their needs, but hiring enough engineers to support every deployment limits how quickly a company can grow. More of the process needs to become self-service, even while some decisions require collaboration.

The discussion returned repeatedly to the practical starting point of defining what successful work looks like and testing for errors that could lead to incorrect charges or missed steps in a workflow.

Better automation can make deployment easier, but the judgement needed to establish whether AI is doing its job still depends on people who understand the work.