How to evaluate and test an AI workflow

OutsourcingVN is operated by Netbase JSC, which scopes and runs accountable project teams for buyers who would rather not build every capability internally. This is the testing chapter of the AI workflow automation guide, and the commercial route is AI workflow automation. Everything below applies whoever builds the workflow, including your own team.

A demonstration is not an evaluation

A demonstration is a supplier choosing inputs. An evaluation is you choosing inputs in advance, with someone recording what happened on every one of them, including the ones that went badly. The two feel similar in a meeting and are worth completely different amounts.

The practical test is reproducibility. If a supplier cannot hand you the input cases, the expected results, the actual outputs and the scoring rule, you watched a demonstration. Ask for the four artefacts by name.

Build the evaluation set from real cases

An evaluation set is a collection of real inputs with an agreed correct answer for each. Three rules make it useful.

Take the cases from production, not from imagination. Sample a period of genuine traffic. Invented cases carry the assumptions of the person who invented them, which are the same assumptions the build will contain.

Include the awkward ones deliberately. Real distributions are mostly easy cases, so a random sample flatters the system. Add the cases people argue about, the ones with missing fields, the ones in a second language, the ones where two categories both look right, the malformed and abusive ones, and the ones your current process gets wrong today.

Label them with the people who own the outcome. The person who handles the work decides what a correct result is. Where two reviewers disagree, that disagreement is a finding: the rule is unclear for humans too, and the workflow will not fix that. Record it rather than resolving it silently.

Keep part of the set unseen during the build, so there is a fair set to judge against at the end. Evaluation data is production data: Netbase security practices include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request. Where data cannot leave your environment, the evaluation runs inside it.

Agree the acceptance criteria before anyone builds

Acceptance criteria written after the results exist are not criteria; they are a description. Settle these before the first line of code:

• which cases the workflow must handle automatically, and which it must hand to a person;
• what counts as a correct result for each task, in the process owner's words;
• what an unacceptable failure looks like, separately from an ordinary miss;
• who decides go, change or stop, and on what evidence;
• what the workflow must never do, regardless of how confident it is.

The fifth point does more work than the rest. A moderation workflow that never auto-deletes, a document workflow that never posts a payment unreviewed: those boundaries are cheaper to enforce than to test. Where a boundary needs a person, human-in-the-loop AI workflows covers how to place them so the review is real rather than decorative.

What to measure, by task type

Different tasks fail differently, so a single accuracy number hides more than it shows. Thresholds are yours to set on your own data; this page publishes no figures of ours.

Two measures belong in every task type: how often the workflow declines to act, and how often it acts confidently and wrongly. The second is the one that hurts. How much of this you can enumerate depends on the shape you built, which is the subject of AI agent or automated workflow.

Regression testing when a prompt, a model or a rule changes

Three things can change under an AI workflow: the prompt, the surrounding rules, and the model itself. Any of them can move behaviour without anyone touching the feature you care about.

Treat the evaluation set as a regression suite. Before a change ships, re-run it and compare case by case rather than in aggregate, because a stable headline can hide cases that flipped in both directions. Model changes deserve particular care: Netbase works with commercial and open-source AI models chosen per project, and a provider updating a hosted model is a change you did not make and may not be told about. That is one reason model choice is a design decision, discussed in AI model selection for business workflows.

Store the runs. A scored history turns "it seems worse lately" into a dated comparison.

Shadow running, then a staged rollout

Shadow running is the cheapest real test there is: the workflow sees live traffic, produces its output, and that output goes nowhere except a log. It catches what an offline set cannot, including inputs nobody thought to sample and integrations that behave differently under load.

Then widen in stages rather than switching over. Start with the narrowest slice that still produces useful volume, keep the previous process available, and agree in advance what sends you back. A planned rollback is an operational step; an unplanned one is an incident.

After go-live: what to watch, and who watches it

Measure a small number of things continuously and review them on a fixed rhythm: volume by decision, escalation and override rates, cases where a person reverses the workflow, refusals and errors, latency, and usage against the limits you set. The override rate is the most honest of these, because it is the reviewers telling you what the evaluation set missed.

Someone has to own it. Netbase project teams draw on business analysis, project management, solution architecture, development, QA and UI/UX roles, and delivery runs remote-first from Hanoi in Agile increments with weekly reviews, using AI-assisted engineering under human review. After handover the named owner can be yours or ours, but it must be named, with a documented threshold at which the workflow is paused. A workflow nobody watches degrades quietly: the classifieds platform we delivered used AI-powered content filtering that flags offensive content into an admin moderation dashboard, and the value of that design is that a human queue makes drift visible. Netbase has also delivered anonymised client AI projects including retrieval-based knowledge assistants, document AI and MLOps pipelines. More worked examples sit on AI automation use cases and in the classifieds moderation record.

What you receive, so you can re-run it yourself

Handover is not complete until you can repeat the evaluation without the supplier in the room. Ask for the case set and labels in an open format, the scoring rule or script, every recorded run with its date and configuration, the prompts and rules under version control, a runbook for re-running and for pausing the workflow, and a written list of known limitations and untested conditions. Handover and exit covers the wider transfer.

If a workflow is already in production and none of this exists, that is a reasonable scope for a technical audit sprint: a timeboxed reconstruction of the evaluation and an evidence pack you can act on.

How we run this, and what it cannot tell you

This page describes the method we apply on AI workflow projects and the evidence we hand over. It contains no accuracy figures, benchmarks or savings of ours, because results measured on one client's data do not predict yours: task, data and threshold differ every time. The limitation is real. An evaluation set is a sample, so it bounds what you know rather than proving the workflow correct, and a set built today drifts as your inputs change. Re-sampling on a schedule is part of the design, not an admission that the first set was wrong.

Re-run the evaluation before you trust the workflow

Bring a few weeks of real cases, the exceptions that make people argue, and the name of the person who decides what correct means. For how we source the claims on this page, see our methodology. When you are ready, submit a project. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.

Related services and solutions