← All AI Engineer talks

AI Engineer World's Fair 2025

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

Jeremy Silva· FreeplayChris Hernandez· Speech analytics lead, Chime12:50

Read the talk

The Build-Operate Divide: Making AI Quality a Working Practice

A promising AI product needs more than a launch: evaluations, human feedback, and clear quality ownership turn rapid development into reliable improvement.

From a talk by Jeremy Silva and Chris Hernandez

What happens after the first version ships?

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.

0:000:25
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:00 · section reference included

Faster development increases operational demands

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.

Development constraintTraditional MLGenerative AI
Starting dataSubstantial data needed to beginSmaller organizational assets can be useful
Model preparationLong training cyclesExisting base-model capabilities
IterationSlower development cyclesFaster experimentation

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.

Slide titled “The Evolution from Traditional ML to Gen AI,” with a downward arrow beside “Barriers to entry” and an upward arrow beside “Speed of iteration.”
The shift to GenAI lowers barriers to entry and increases iteration speed.
1:121:24
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

1:12 · section reference included

Crossing the quality chasm

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.

2:092:27
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

2:09 · section reference included

Confident errors need human judgment

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.

3:343:45
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

3:34 · section reference included

Feedback needs reviewers

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.

5:095:21
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

5:09 · section reference included

Expanding QA beyond retrospective audits

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.

Venn diagram titled “QA at the Center of GenAI Adoption.” The left circle lists strategic AI impact and model monitoring; the overlap lists auditing, scorecards, insights, and edge case surfacing; the right lists prompt testing, annotation, and HITL design.
QA spans model monitoring, auditing, prompt testing, annotation, and HITL design.

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.

6:527:02
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:52 · section reference included

Give AI quality an owner

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.

Slide titled “The AI Quality Lead Role,” with columns for key attributes and day-to-day duties, including identifying quality issues, defining evaluation criteria, managing testing datasets, optimizing prompts, and prioritizing fixes with PMs and engineers.
The AI quality lead role combines customer understanding with practical evaluation and improvement duties.

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.

9:099:20
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

9:09 · section reference included

Place review where it matters, then keep operating

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.

11:1311:28
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

11:13 · section reference included

Resources

Updates since the talk

  • Freeplay’s current guide to expert labeling, production spot checks, ground-truth datasets, review queues, and calibration of automated evaluators.

Read the complete timestamped transcript
  1. 0:00

    [upbeat music] Um, we titled this talk the build operate divide, 'cause we've ob-observed this troubling trend where, like, good AI product concepts fail to reach their full potential due to operational

  2. 0:25

    challenges. So today, Chris and I are going to be talking about some of the learnings we've gleaned from, like, our experiences on the front lines operationalizing AI products at scale.

  3. 0:34

    By the end of this talk, we hope you're going to leave with an understanding of how you can kind of bridge that gap between product concept, um, and operational reality by understanding how to deliver quality through evals, human review, and how you might build your teams around that.

  4. 0:48

    So a little bit about ourselves. My name is Jeremy. I lead product at a company called Freeplay, um, which exists to help solve a lot of these operational problems and, and help companies ship great AI products.

  5. 0:59

    Hi, everyone. My name is Chris Hernandez. I lead our speech analytics team at Chime. Uh, I've been in the industry for about ten years, uh, from a CX perspective and, uh, about nine years on the ML space.

  6. 1:09

    So excited to be here.

  7. 1:12

    So both Chris and I kind of came from the traditional ML world into the GenAI world, and I thought it was, like, helpful to maybe take a note and talk about, like, what we feel like has changed in this transition.

  8. 1:24

    Um, so I think the biggest difference in my mind is this decreased barrier to entry, right? In the traditional ML world, like, you need tons of data to even get started.

  9. 1:32

    There are these long model training cycle times, and that barrier to entry just kind of like goes down significantly, um, in a GenAI world, right? Like, you can now use the intelligence of the base models to be able to, like, make use of and leverage, uh, smaller data assets within your organization.

  10. 1:49

    And then what comes along with that is this, like, increased iteration speed, which is, like, as the barrier to entry goes down, the speed at which you can iterate starts to go up.

  11. 1:59

    And this increased iteration speed starts to accentuate the need for, like, a high-quality ops function. Um, so we want to take a look at why.

  12. 2:09

    Working across, like, dozens of different enterprise teams at Freeplay, we've noticed this common trend emerge, which is companies will build an initial prototype, maybe they'll even ship a V1 of that thing into production, but they inevitably hit this sort of quality chasm as they try and go from a V1 to a V2 that really drives true value

  13. 2:27

    for the customer. And there's this reliability problem in there. And what we've seen is, like, the only way that you really cross that quality chasm that, and get to a reliable V2 is through iteration.

  14. 2:41

    And so we talk about this iteration loop as you move from monitoring to experimentation to testing, evaluation, and I, I use that word broadly speaking, human review, auto-evaluation, like all these things all kind of come into play.

  15. 2:55

    Um, but what happens is your product quality becomes a direct function of your ability to move through this loop, right? The faster you can iterate, the more times you can move through this loop, the better your product quality becomes.

  16. 3:09

    So it, ops kind of sits at the foundation of this, and especially as you start to scale, right? Like, your ability to move through this loops is, like, ends up being an ops function.

  17. 3:19

    And the, like, not so subtle irony here is that to deliver high-quality AI products, you actually need a ton of human elbow grease. And I'll pass it to Chris here to talk a little bit more about the importance of human experts in this process.

  18. 3:34

    Cool. Awesome. Um, you know, I made the joke that one day I was like, you know, the first time I saw LLMs, we started playing around with it. You know, I typed in like, uh, "I wonder if it actually knows like basic things like, uh, who invented Wi-Fi?"

  19. 3:45

    And then it spit out Abraham Lincoln. I was like, "Oh my goodness- [laughs] ... we're in some trouble." But, uh, all jokes aside, and maybe not that extreme, it is a good reminder that LLMs, and even the smartest ones, can make mistakes, uh, and they often do it with a lot of confidence.

  20. 3:59

    Um, so, uh, that's of course what we call hallucination. And, uh, in the GenAI space, um, it, it, at times, like you got to make sure that, you know, we don't leave it unchecked and that these hallucinations can actually be tricky and risky.

  21. 4:11

    Uh, they could also mislead customers, and they could misinform decisions. And when you think of like companies or industries like healthcare, uh, just a small hallucination could have a lot of risk in it.

  22. 4:21

    Um, so that's where human-in-the-loop comes in. That's why it's important to talk about this today. And human-in-the-loop kind of ensures while GenAI does the heav-heavy lifting, uh, humans are still there to steer the ship and, and drive, drive in the right direction.

  23. 4:34

    Um, so today we're going to talk a little bit more about like human-in-the-loop, why it's important. I don't think this is like groundbreaking, like everyone understands human-in-the-loop. It's been around forever, but just reiterating on the importance of it.

  24. 4:45

    So LLMs right now are just, you know, we know that they're good at, uh, generating content, and they do it really, really quickly. But without humans, they often fall short of real-world reliability, especially when nuance, empathy, and context is required.

  25. 4:58

    Without human-in-the-loop, you're also not scaling productivity, you're scaling risk. And so a [REDACTED:marital_status] hallucination in isolation might not seem like a big idea or big deal, but at scale it could be dangerous.

  26. 5:09

    Um, so, uh, the last point I want to make on that is also each time a, a human flags or corrects an output, it's a signal that we need to be using to help retrain, reinforce the models that we see.

  27. 5:21

    And that's of course how, uh, you know, models are evolving over time. So I want everyone to think of human-in-the-loop not as like a safeguard, it, but as a feedback mechanism or feedback engine, if you will.

  28. 5:32

    So every model output that goes through a human review, that feedback then gets fed for refinement and, and of course, uh, improving the model. And over time, this loop brings AI closer to real human expectations and behaviors.

  29. 5:45

    But there is a challenge and, and speaking with many different teams, the challenge is that we don't have enough people to do all these reviews. Like model-graded evals and evals in general are great, but you still need to have the human element in there.

  30. 5:56

    So most teams don't have enough people to review thousands of the different outputs that you have. And that makes it really, really hard to improve on the models and even measure, uh, the current state of the models that you have.

  31. 6:06

    But there is good news, and so this might not seem like a, a clear path in some of the organizations that you all might be, be part of. Um, but we already have teams that are kind of trained to do this type of work of human-in-the-loop, and those teams are like your quality folks or CX folks within

  32. 6:21

    the operations side of the business. And so especially when you look at call centers, they're already experts in doing the jobs that you need them to do, which is evaluate interactions at scale, spotting a, spotting edge cases and defining what really, what good looks like.

  33. 6:35

    So in this age of A, uh, GenAI, their roles from my perspective is not shrinking, it's continuing to evolve. Um, and they're not just, right, they're not just measuring outputs anymore, uh, or outcomes.

  34. 6:47

    Uh, I think they're really shaping, like, the future and what's next.

  35. 6:52

    So as GenAI becomes, like, more embedded in the operations, quality is also evolving. It's no longer about auditing what's already happened, uh, but it's also about shaping what's gonna happen next.

  36. 7:02

    So the shift change, uh, in the QA teams who are in this ops space, they're not just scorekeepers anymore. They're becoming model shapers, prompt testers, and AI performance monitors.

  37. 7:12

    And if there's any group that's already built for this kind of work, as I mentioned before, you might want to look at your ops team and see if there's anyone in the QA contact centers that could also help expand your projects, uh, even further.

  38. 7:23

    Um, they al- already know how to evaluate the nuanced conversations. They also know how to surface these edge cases like I mentioned before.

  39. 7:30

    So talk a little bit about, like, the evolution of just quality in general or CX. Um, they've been for the most part focusing on auditing, coaching, compliance, uh, but as automation continues to scale, these roles aren't disappearing, but they're actually transforming.

  40. 7:46

    When you look back, you know, 25 years ago, um, right, you know, the, the main roles were just QA professionals were listening to phone calls and evaluating interactions. But we see that as, like, continu- like, a continued evolution where automation is now coming, uh, into play, and these folks are, like, transforming their skill sets to help solve

  41. 8:05

    for larger problems. [sniffs] The diagram that we have here kind of just shows, like, where the QA scope is today and how it's expanding to the GenAI space. At the core, we have what QA has always done, uh, which is auditing interactions, capturing quality behaviors.

  42. 8:20

    But now, as you can see, we scope... The, the scope itself is expanding, and QA professionals are testing prompts now, and they're tagging outputs, and they're really helping shape the model, uh, behavior that we're expecting.

  43. 8:31

    Uh, and there is a beauty in the GenAI space, uh, which is it opens the doors to non-technical folks. Uh, traditionally, uh, only the ML teams, the engineers are the ones that are heavily involved in the outputs and deciding what's gonna, you know, uh, come from it.

  44. 8:44

    Uh, but now, um, uh, you don't need to know how to build, uh, the model pipeline to know what, you know, a good output looks like, uh, just like you don't need to know how to, um, make wine to be a good wine connoisseur.

  45. 8:54

    Uh, the, the outputs or the expertise still matters and just as valuable. Uh, and then the contact center CX teams are, again, already equipped with this. And so, um, it might be something to, to look into and just see how you could expand that reach even further.

  46. 9:09

    So one of the things Chris is talking about here is, like, something we have observed, like, working across a number of custom- customers as well, which is this stor- sort of emerging role of, like, the AI quality lead.

  47. 9:20

    And importantly, like, I've almost never seen it actually called this, but it seems to exist at companies who are having, like, a lot of success in the GenAI space.

  48. 9:29

    And I expect this role to actually become more formalized and gain more traction, right? Like, Chris and his team are an example of this role. Um, and importantly, like, people in this role can come from a variety of different backgrounds, product, ops, engineering.

  49. 9:43

    But, like, the key attributes of what makes someone a good AI quality lead is someone who first and foremost has a deep, deep understanding of the customer need in the domain, and then importantly is a systems thinker and is able to, like, systematically think about how to diagnose and solve these quality problems.

  50. 10:01

    What that looks like day to day is this person is doing a lot of these just kind of, like, this new skill set, labeling data, writing evaluation criteria, running experiments and tests and things like this, and prompt engineering.

  51. 10:15

    And you'll notice that, like, there is something notably missing from that, which is, like, these are often not the people who are writing production code. But I think what has changed so significantly is writing production code is not the only way now that you can contribute in, like, a really hands-on way.

  52. 10:33

    All of these things, like, given the right tool set and the right structure of your team, you can contribute to, like, this iteration loop, the prompt engineering, the evaluation, all this kind of stuff, without necessarily being the one, like, writing the production code day to day.

  53. 10:47

    Chris is talking about, like, how you do this at scale, but we've also seen a lot of success where companies will have one person or two people in this role, um, especially when you have a smaller footprint, and that goes a long way, you know?

  54. 10:58

    So I think what, what Chris is painting is, like, in larger enterprises and as you start to scale this stuff up, you really need, like, a meaningful quality team.

  55. 11:05

    But you can do this by, like, kind of empowering a [REDACTED:marital_status] or couple individuals in this role.

  56. 11:13

    Cool. So I'm just gonna leave you all with a, a, a few last points. You know, I think while human-in-the-loop is important, and, like, we've just spent the last few minutes talking about it, uh, if you don't have the resources, I think, you know, looking at high-risk, high-trust areas is abs- like, an absolute must.

  57. 11:28

    And so insert human-in-the-loop at decision points and not just for show. The next piece is, like, continue to bring your co- like, your ops teams and CX teams into the life cycle early to help what, you know, define what good looks like, uh, so they can help build out golden sets and, uh, tests against real world, real

  58. 11:45

    world edge cases. Um, and then this is another point I wanted to make too, is just, like, the, the fact of, like, launch is not the finish line. Uh, track performance, flag hallucination, me- measure impact, and iterate.

  59. 11:55

    Uh, time and time again, I see teams, like, celebrating, which is great to see celebration of, like, a product actually launching or solution being actually launched. Uh, but the important part there that it's not the end.

  60. 12:04

    It's the beginning, where you need to set up your teams to make sure that the outputs are performing how you expect them to perform. Um, and last but not least, scale is not just about tech anymore.

  61. 12:13

    I think it's about people. And so leveraging QA, ops, uh, and support, and frontline teams, I think as a strategic partner in the GenAI space is gonna be what makes teams successful.

  62. 12:23

    And if there's just one key takeaway today, it's that scaling GenAI isn't just a technical challenge anymore. It's an operational, uh, liability and responsibility. Um, when you embed quality and then human feedback into that loop, the right people, uh, into your GenAI systems, you're not just building faster, but you're also building better.

  63. 12:41

    Um, so anyways, thank you, guys. Appreciate it. [audience applauding] [upbeat music]