The Build-Operate Divide: Bridging Product Vision and AI Operational Reality

How do you turn a promising AI concept into a product that reliably delivers its intended value? Getting something built is only part of the problem. Operational challenges can prevent a good concept from reaching its potential, and addressing them requires three connected capabilities: evaluations, human review, and a team structured to act on what they reveal.

Jeremy Silva approaches this problem as the product lead at Freeplay, which helps teams operationalize AI products. Chris Hernandez brings the perspective of leading speech analytics at Chime, with a background spanning customer experience and machine learning. Their shared concern is what it takes to keep improving quality after the initial build.

The transition from traditional ML to generative AI changes how much work is needed before a team can begin learning from a product. In Silva’s comparison, traditional ML demands substantial starting data and long training cycles. Generative AI lets teams use the intelligence already present in base models to make smaller organizational data assets useful.

Lower barriers to entry make iteration faster. That speed increases the need for a quality operations function: the ability to change a product quickly must be matched by the ability to assess those changes.

Silva reports a recurring pattern across dozens of enterprise teams at Freeplay: an initial prototype, sometimes already shipped as a production V1, encounters a quality chasm before it becomes a reliable V2 that delivers real customer value. The missing ingredient is reliability, and his prescription is repeated iteration.

The loop connects three kinds of work:

1. Monitoring: observe the product’s behavior.
2. Experimentation: develop and try changes.
3. Testing and evaluation: assess those changes through human review, automatic evaluation, or both.

Silva connects product quality to a team’s ability to move through this loop repeatedly and quickly. Evaluation is broad here; it includes the human work of examining outputs as well as automated checks.

At scale, keeping that loop moving becomes an operations responsibility. Someone must make the review, experimentation, and testing work happen consistently. The irony is that delivering high-quality AI still requires substantial human effort. Faster model development makes that work more central to the product.

Hernandez illustrates the problem with a joking anecdote: he asks an LLM who invented Wi-Fi, and it answers Abraham Lincoln. He immediately qualifies the example as perhaps extreme. Its purpose is to make a familiar failure vivid: even capable models can produce wrong answers with considerable confidence.

Unchecked hallucinations can mislead customers and misinform decisions. In healthcare, even a small error can carry substantial risk. Human-in-the-loop review gives people a place to guide the system while generative AI handles much of the work. The need becomes especially clear when a response depends on nuance, empathy, or context—qualities that fast content generation alone does not guarantee.

Scale changes the consequences. An isolated mistake may appear manageable; repeating that failure across many interactions can make it dangerous. Hernandez’s warning is that teams can end up scaling risk alongside output when they expand automation without human judgment.

A human flag or correction has value beyond catching the immediate mistake. It supplies a signal for refinement, reinforcement, or retraining, helping future behavior move closer to human expectations. Review is a feedback mechanism, not just a safeguard. Collecting a correction and changing the system are separate steps: a label supplies evidence for improvement; it does not automatically update model weights.

Hernandez describes teams without enough people to review thousands of model outputs, limiting both improvement and measurement of current quality. Model-graded evaluations help, but he argues that they still need a human element. Without review capacity, the team struggles both to identify what should change and to understand how well the current system works.

Existing quality and customer experience teams offer a practical source of that capacity. Contact-center staff already evaluate interactions at scale, identify edge cases, and define what good service looks like. Their expertise can inform AI behavior directly. As their responsibilities expand, they move from measuring outcomes toward shaping what the system should do next.

As generative AI enters operations, quality assurance gains a forward-looking responsibility. QA teams become prompt testers, model shapers, and AI performance monitors as well as auditors. Their ability to assess nuanced conversations and surface edge cases gives them a useful starting point for this work.

Hernandez traces that expansion from the familiar work of auditing, coaching, and compliance. Looking back roughly a quarter-century, he describes QA professionals listening to calls and evaluating interactions. Those skills remain the foundation. The diagram’s overlap contains auditing, scorecards, insights, and edge-case surfacing; its surrounding scope includes strategic AI impact and model monitoring on one side, and prompt testing, annotation, and human-in-the-loop design on the other. Testing prompts and tagging outputs extend the existing discipline into shaping model behavior.

This work also opens participation beyond ML and engineering teams. Recognizing a good output does not require knowing how to build the model pipeline, just as being a good wine connoisseur does not require knowing how to make wine. Domain expertise remains valuable even when its owner does not implement the system. Contact-center and CX teams already possess much of the judgment needed to evaluate the conversations AI products generate.

Silva calls an emerging function the AI quality lead, while noting that he rarely sees that exact job title. He expects the role to become more formalized; Chris and his team are an example of the function already being performed. People can enter it from product, operations, or engineering. What matters is deep customer and domain understanding combined with the ability to diagnose quality problems systematically.

The daily work makes that ownership concrete:

• Evaluation: label data, define evaluation criteria, and maintain testing datasets.
• Experimentation: run experiments and tests, and optimize prompts.
• Coordination: identify quality issues and prioritize fixes with product managers and engineers.

These responsibilities connect an understanding of customer needs to a repeatable process for improving outputs.

Writing production code is often outside this role. With suitable tools and team structure, a quality lead can make hands-on contributions through prompt engineering, evaluation, and experimentation without implementing the production application. The team design must make those contributions possible, rather than treating coding as the only direct route to improving the product.

Silva reports success with one or two empowered people performing this function in smaller deployments, while larger enterprises need a substantial quality team. This is an observation about staffing at different scales, not a workload-based sizing rule. A small organization can begin by assigning clear ownership; increasing scale calls for enough capacity to sustain the same quality work.

When review resources are scarce, Hernandez recommends prioritizing high-risk areas and interactions where trust matters most. Put people at actual decision points, where their judgment can affect the outcome, rather than adding review merely for appearances. Bring operations and CX teams into the product lifecycle early so they can help define quality, build golden sets of reference examples, and test real-world edge cases.

Launch begins the operating responsibility. Track performance, flag hallucinations, measure impact, and iterate. Celebrating a release is reasonable, but the team must be ready to determine whether deployed outputs continue to meet expectations. That ongoing work is what makes the improvement loop part of the product’s operation.

Scaling therefore depends on people as well as technology. QA, operations, support, and frontline teams need to be strategic partners in the AI system’s development and operation. Hernandez closes by framing generative AI scale as an operational liability and responsibility alongside the technical challenge: embedding quality, human feedback, and the right people in the loop is how faster building becomes better building.