2026-09-16

AI deployment case studies: how enterprises get from pilot to measurable results

Drawing on real AI deployment cases, this article breaks down how enterprises define business goals, choose their first use case, complete a pilot in 8 weeks, connect data, systems, and human fallback, evaluate full-cost ROI rigorously, and scale from a single pilot to repeatable rollouts.

1. Define "results" first: not shipping a model, but moving a business metric

The most common misjudgment in enterprise AI projects is treating "the model works" as "the business benefits." Completing knowledge Q&A, generating a report, or achieving high accuracy on a test set only shows that the technical approach may be viable. Real deployment means entering the day-to-day operating chain: the system continuously receives production data or customer requests, reads internal company information within its permissions, produces results that can trigger the next action, and keeps recalibrating based on execution, human corrections, and final business outcomes.

So the object of acceptance should not be an isolated page but a complete process. For example, the output of a replenishment model is not a "sales forecast value" but a purchasing recommendation that has passed through inventory constraints, supply lead times, and approval rules. The output of a customer service model is not just reply text either; it should be able to identify intent, look up orders, perform permitted operations, and hand abnormal requests off to a human agent. If employees still have to copy the recommendation into another system, or the model has no way of knowing whether its result was adopted, the project is at best a demonstrable technical proof of concept that has not yet closed the business loop.

Write the metrics before discussing the model

Each pilot should have only one primary metric, used to answer "what exactly does this investment change?" The primary metric must come from business operations or operating processes, not from the model's own scores. Depending on the scenario, you might choose average handling time, stock-out levels, missed quality defects, sales conversion performance, or cost per task. The metric also needs a clearly written measurement basis, observation period, data source, and control group; otherwise there is no reliable way to compare before and after launch.

Beyond the primary metric, set guardrail metrics to prevent local optimization from damaging the business as a whole. A workable metric framework looks like this:

The primary metric and the guardrail metrics must pass together. For example, if automated customer service lowers average response time but complaints rise and human rework increases, it cannot be judged a success; if a quality inspection model speeds up detection but frequently raises false alarms and stalls the production line, it is likewise not ready for rollout. Project goals should be written as testable business hypotheses—"shorten the end-to-end handling time for a certain type of ticket without raising the complaint rate or compliance risk"—rather than "build AI customer service capability."

Once value enters organizational decisions, IT cannot be the only owner

Tools for individual writing or information search mainly save a single employee's operating time, and their deployment boundaries are relatively clear. Inventory allocation, quality judgments, credit review, production scheduling, and customer case handling, by contrast, affect departmental targets, approval authority, and risk accountability. At that point the IT team can own data interfaces, system integration, and runtime stability, but it cannot decide on its own what results the business can accept.

A pilot usually requires joint participation from the business, technology, and risk or compliance functions, focusing respectively on metrics and process changes, system operation, and the boundaries of automated execution. When frontline operations are involved, the actual users should also take part in rule design and exception reviews. Projects without a business owner can often launch on time, yet struggle to answer where the saved time went, whether errors really decreased, and which department confirms the benefits.

Judge effectiveness by combined results

The value of visual quality inspection in manufacturing lies not only in detection scores but in whether it reduces missed defects and the burden of repeat inspections without slowing the production takt time. A retail replenishment system cannot be judged on forecast error alone; you also need to see whether its recommendations enter the ordering process, and whether stock-outs, overstock, and manual adjustments improve. Even if a medical imaging assistance system can mark suspicious regions, the physician still bears the final judgment; the evaluation should focus on reading efficiency, missed findings, and whether the clinical workflow runs more smoothly.

What these scenarios have in common is that results are usually made up of efficiency, errors, and business outcomes together. Model metrics explain the system's capability; business metrics decide whether to keep investing. At project review, a direct test can be applied: if the team cannot explain what action the AI output will trigger, who is responsible, how the results flow back, and which business metric will change as a result, the project should not enter a formal pilot.

2. Choose the right first use case: a three-way screen on value, feasibility, and risk

The job of the first use case is not to prove the model's capability but to run a closed loop of "input, judgment, execution, review, measurement" with a relatively small scope of change. Prioritize work that happens frequently, follows relatively stable rules, has accessible historical records, involves labor that can be costed, and produces output that can be verified quickly—for example, financial reconciliation, consolidating return waybills, customer service information lookup, product appearance inspection, and store replenishment recommendations. These tasks have relatively clear boundaries, and it is easy to set up comparisons between human results and AI results.

Do not screen with a single total-score table. Value, feasibility, and risk should be judged separately: risk is an entry condition, feasibility determines whether delivery can happen on schedule, and only value determines whether the investment is worthwhile. High value cannot offset unusable data, nor can it override unacceptable business liability.

Value estimates cannot stop at "how many labor hours were saved." Reconciliation should also account for losses from duplicate payments, missed orders, and rework; customer service should look at wait times, the rate of handoffs to human agents, and first-contact resolution; quality inspection should cost out missed defects, misjudgments, and scrap; replenishment mainly affects working capital, turnover efficiency, stock-out losses, and disposal of slow-moving goods. Even if a retail replenishment project saves limited operating hours, its business value may still be significantly higher than simple automated report generation, as long as it reduces stock-outs and overstock.

Feasibility assessment must get down to real data and the actual operating environment. Pull a batch of samples spanning multiple periods and check for missing fields, conflicting definitions, coverage of exception cases, and image or text quality; at the same time, confirm account permissions, interface stability, business peaks, and employees' current data-entry habits. If the same field means different things in different systems, or key outcomes lack reliable labels, first unify the definitions and fill in the collection pipeline. Swapping models blindly at this stage usually only makes test results fluctuate without addressing the root cause.

You also need to distinguish "the model can make the judgment" from "the process allows automated execution." Matters where errors are costly and accountability is sensitive—payments, credit decisions, medical diagnosis and treatment—are not suitable for an unreviewed first pilot. A safer approach is to have AI handle document recognition, candidate ranking, risk alerts, or recommendation generation, while the final decision is still made by authorized personnel. A common practice in medical imaging is likewise to mark suspected regions and provide supporting information first, then have the physician confirm, rather than letting the system produce a diagnostic conclusion directly.

Before deployment, assess together whether the target improvement can be verified, whether the data is sufficient and consistently defined, and whether error handling and human takeover are clearly specified. If key questions lack an owner and evidence, proceed to development with caution. For the first use case, it is better to choose a narrow scope with verifiable results than an "all-purpose assistant" that looks important but depends on large amounts of tacit experience.

3. Close the loop within a time box: from business baseline to limited launch

The goal of a pilot is not to deliver a demonstrable model but to complete one business loop that can be judged: a pre-change baseline, validation on real traffic, a plan for handling exceptions, and, at the end, a decision to continue, adjust, or stop based on business data. If the cycle is too short, exceptions are not fully exposed; if it is extended indefinitely, the pilot easily turns into an R&D project with no exit criteria.

Baseline phase: measure the old process first, then discuss what AI can do

The project team should document, step by step, the full path of a task from entry to completion, including entry points, decision conditions, system operations, handoff points, and final output. The baseline should cover at least volume, average and peak handling time, the people involved, errors, and the rework or losses those errors cause. Without this data, even if things "feel faster" after launch, there is no way to confirm whether the improvement came from AI, process simplification, or a change in business volume.

At the same time, sort the steps into three categories: can be executed automatically, requires human review, and must not be processed automatically. Operations with clear rules and reversible consequences are suited to automation; steps involving payments, refunds, permission changes, formal commitments, or sensitive information should retain human confirmation. This boundary must be signed off by the business owner and cannot be left to the model to decide.

Preparation phase: build only high-frequency core tasks, and define failure in advance

The minimum viable version does not aim to cover every branch; it should prioritize tasks with high volume, relatively stable inputs, and clear acceptance criteria. In customer service, for example, you can start with information extraction, ticket classification, and draft replies, without having the system independently handle complex complaints from the start.

Data preparation cannot collect only "normal cases." Beyond the regular test set, build a separate exception sample set covering missing fields, messy formats, duplicate submissions, contradictory information, and edge-case requests. Acceptance criteria should also be set before development: which fields must be accurate, which outputs may be empty, and in what situations the system must decline to answer or hand off to a human agent. Otherwise the team can easily substitute a handful of successful examples for formal acceptance.

Controlled-run phase: enter the real environment, but don't let AI control the final action yet

This phase should complete the accounts, permissions, interfaces, logging, and connections to business systems. Start in shadow mode: the AI processes real tasks and generates results but does not directly affect customers or production data, while humans operate according to the original process, and then the two are compared for correctness, time taken, and reasons for disagreement. If traffic must be introduced, limit it to a controllable queue, internal users, or a very small scope.

Testing should focus not only on answer quality but also on how the system fails in production:

• Whether queuing, rate limiting, or cost anomalies appear as concurrency rises;
• Whether tasks can be paused, retried, or switched back to humans when the model is unavailable;
• Whether sensitive expressions and platform-prohibited content can be intercepted before output;
• Whether an interface timeout leads to duplicate submissions, duplicate charges, or duplicate writes;
• Whether human edits, withdrawals, and failure records leave a complete audit trail.

Evaluation phase: launch at low risk, and decide go or no-go on business results

A limited launch should be scheduled for a period with low business volume, full on-call staffing, and the ability to roll back quickly. The launch scope should be specified down to users, channels, task types, and permission levels, with the ability to hand off to a human with one click, stop automated execution, and restore the old process. Rollback is not a line in an emergency document; it should be rehearsed for real before launch.

The final review should compare business metrics before and after the pilot, not showcase a few conversations that went well. It needs to look at handling time, completion rate, the share of human intervention, errors and rework, user impact, and cost per task together. If core metrics improve and risk is under control, traffic can be expanded; if value exists but errors are concentrated in a few steps, narrow the scope and fix them; if the solution relies on heavy human remediation over the long term, or the savings are not enough to cover the added costs, the current approach should be terminated. The value of a time-boxed loop is precisely that it gives the team an actionable conclusion early, rather than accepting "still optimizing" as the default answer.

4. Plug AI into the process: data, systems, and human fallback are all indispensable

The pilot phase is prone to one illusion: the model can answer questions, so the team believes the use case is in production. The real dividing line is not answer quality but whether a business action is triggered after the answer. Only when connected to customer, order, inventory, ticketing, equipment, or finance systems can AI go from an information assistant to a node in the process.

For example, customer service identifying an equipment fault does not mean the problem is solved. It also has to read the equipment model, warranty status, and operating data, determine the service scope, create a repair ticket, and return available appointment slots. Replenishment is the same: generating a demand forecast is only an intermediate result, and the process still has to check inventory, goods in transit, warehouse capacity, and purchasing constraints before submitting a replenishment order to the warehouse system. Where amounts of money, inventory, or customer entitlements are involved, the model should not write directly into core systems; execution should go through rule validation, access control, and approval nodes.

Settle the data contract first, then discuss model performance

Many production errors look like the model misjudging, but the root cause is that business fields are unusable. An order marked "completed" may mean paid in the sales system but delivered in the logistics system; the same customer may also appear as several records because of different phone number formats. If these differences are not reconciled, the model will reason from mutually contradictory facts.

Financial reconciliation illustrates this especially well. Whether the system can exclude duplicate documents and recognize subsequent changes such as refunds or reversals often affects the final books more than text comprehension does. In engineering terms, first establish unique identifiers, status priorities, and cutoff-time rules, and only then have the model handle unstructured vouchers or exception notes.

Design human takeover as a formal branch

Human fallback cannot rely on "find someone when something goes wrong." Every automated chain should define in advance the handoff conditions, receiving role, context to pass along, and handling time limit. Automated execution should usually stop in the following situations: the model is not confident enough; the customer explicitly asks for a human; an interface times out, data is missing, or systems return conflicting results; or the matter involves payments, compliance, health, safety, or a major customer complaint.

When handing off to a human, the system cannot simply throw out "unable to process." It should pass along the original request, the data already read, the model's suggestion, the reason for failure, and the steps already executed, so employees do not have to investigate from scratch. Human edits should also be recorded in a structured way, including what was changed, why, and what the final result was. These records can be used to adjust rules, supplement data, and re-evaluate the model—rather than being fed straight into training without review.

High-risk business should keep humans ahead of AI. In medical imaging, the system can first circle suspected regions and provide risk alerts, but the diagnostic conclusion, treatment recommendation, and sign-off of responsibility should still be done by the physician. The same principle applies to credit, insurance claims, hiring, and production safety: AI handles screening and ranking, while people make the key judgments.

Check that the loop is closed before launch

• Input data has a clear source, update time, and owner.
• Model output maps to concrete actions instead of stopping at text suggestions.
• Rule validation, idempotency control, and audit records are in place before anything is written to core systems.
• After an interface failure, operations can be retried, degraded, or reversed without duplicate orders or duplicate charges.
• Humans can take over at any time and see the full context.
• Human corrections can be tracked and used for subsequent evaluation and process improvement.

To judge whether an AI process is ready to scale, ask one direct question: when the model errs, the data goes stale, or a downstream system is unavailable, can the business continue safely? If the answer is no, what you have built is only a demo, not a production process that can run.

5. Calculate full-cost ROI: don't just compare model API fees

What is most easily underestimated in AI projects is not the model's price but the supporting investment needed to turn the model into a stable business capability. Low API fees do not mean the project is cheap, and a high cost per inference does not mean the project is not worth doing. The criterion should be: how many resources did the company actually commit to obtain one attributable business result?

Build a full-cost ledger first

In the calculation, separate one-time build costs from recurring annual expenses. The former include initial data governance, interface development, equipment purchases, and launch acceptance; the latter include inference resources, review staff, system maintenance, security operations, and model updates. This shows both the barrier to getting started and whether cost per unit of business volume actually falls as the project scales.

Returns must land in financial results

The returns from enterprise AI can come from labor input, error losses, capacity, revenue, and other areas, and the specific scope should be judged in light of the project. These returns should not be lumped together, nor can "higher efficiency" stand in for a monetary amount.

• Labor savings: hours saved can enter the returns sheet only when they correspond to reduced headcount, lower outsourcing fees, incremental work being absorbed, or staff moving to measurable, higher-value tasks.
• Loss reduction: track changes in rework, returns, claims payouts, inventory write-downs, downtime, and compliance incidents, but deduct non-AI factors such as fluctuations in business volume.
• Capacity release: first confirm whether the new processing capacity is being used by real demand. A system that could theoretically process more orders does not mean the company has already gained anything.
• Revenue growth: identify the increment through control groups, phased rollout, or historical baselines, to avoid attributing all the effects of promotions, seasonality, and channel expansion to AI.

Evaluating project returns

Project returns can be evaluated by weighing attributable benefits, total cost, cash tied up, and implementation risk together, with the specific basis determined by the project's circumstances.

The estimate sheet should have at least three columns: baseline, actual pilot results, and scaled-up projection. Benefits not yet realized must be labeled as projections and given conservative, neutral, and optimistic scenarios; one-time investment should be disclosed separately rather than hiding first-period funding pressure through multi-year amortization. If the project depends on human review, review costs must also be estimated against business growth; otherwise, the larger the scale, the more distorted the ROI on paper may become.

The value of case studies lies in the path to returns, not in impressive numbers

A case of appearance inspection for home appliances shows that the return from visual inspection comes not only from fewer inspectors but also from lower repair and return losses after missed defects, and from higher production line throughput. A retail replenishment case shows that the value of a forecasting model should land on inventory holdings, markdowns on slow-moving goods, and stock-out losses, rather than just reporting forecast accuracy. The available case materials do not provide verifiable report names, so their precise amounts and percentages are not cited here; but both types of cases point to the same conclusion: ROI must be tied to auditable business results.

If a project can only show improved model metrics but cannot explain who bears the cost, which account the savings land in, and when the benefits enter cash flow, it has not completed ROI validation. Scaling decisions should be based on realized benefits, not on demo performance or labor-hour conversions under ideal conditions.

6. Expanding from one pilot to many use cases: replicate capabilities, not interfaces

After a pilot passes acceptance, the most common misjudgment is: since the first application works, swapping in a new batch of data and tweaking a few prompts will allow a fast rollout. In real-world expansion, pages and chat windows are usually the easiest to reuse; what is truly expensive is data governance, process integration, access control, and validating results. The goal of scaling is not to mass-copy an application's look but to extract the engineering capabilities proven again and again in the pilot and turn them into a stable foundation.

The first step is to separate "reusable capabilities" from "scenario-specific logic." At the end of the pilot, take an inventory of components and sort the capabilities into at least the following categories:

• Ingestion layer: unified conventions for data formats, field meanings, update frequency, quality checks, and exception handling;
• Intelligence layer: model routing, version management, prompt templates, knowledge retrieval, rules engine, and degradation strategies;
• Control layer: identity authentication, data permissions, sensitive data handling, operation logs, and audit records;
• Operations layer: human review workbench, alerting, quality monitoring, cost tracking, and evaluation templates;
• Integration layer: standard interfaces for business systems, plus mechanisms for task status, writing results back, and retrying failures.

These modules should be as configuration-driven as possible, but you should not chase "one set of parameters for every business." A shared foundation solves the problem of redundant builds; scenario adaptation solves the problem of business correctness; neither can replace the other.

So every time a use case is added, the business objects, risk boundaries, human intervention points, and acceptance samples should be worked out again. The model can be shared, but the knowledge base may not be; the retrieval framework can be shared, but retrieval rules usually need adjusting; the permission system can be unified, but the granularity of authorization must be redefined by the business. If the team only copies the original interface and prompts, problems will usually surface quickly on edge cases.

The second step is to establish ongoing cross-functional governance. Each use case should clearly assign responsibilities across business, technology, and risk as appropriate, covering process adoption, system operation, cost, permissions, compliance, and human fallback respectively. The relevant owners should jointly decide the launch scope and stop conditions, rather than leaving the technical team to bear the outcome alone.

The operating rhythm should be fixed as well. Review accuracy, exception rates, the share of cases returned by humans, actual usage, and response times weekly; reconcile benefit metrics such as hours saved, processing cycles, and changes in business losses monthly. Model versions, knowledge content, and business rules should each have a designated maintainer, with update times, reasons for changes, validation results, and rollback methods recorded. Without these mechanisms, the more pilots you run, the harder it becomes to manage legacy configurations and gaps in accountability.

Practices publicly disclosed by ICBC show that its AI applications already cover many business lines and a large number of specific tasks, while China Merchants Bank is advancing business transformation through collaboration between employees and AI agents. Both paths show that scaling is not a matter of continually buying isolated tools but of maturing unified technical capabilities, role divisions, and operating systems at the same time. To judge whether a company is ready to expand, look for three signals: whether new use cases are onboarded mainly through configuration rather than rewriting underlying systems, whether business differences have been independently validated, and whether someone is responsible for quality and returns over the long term. If any one of the three is missing, build that capability first before expanding deployment.

7. Recognize failure signals: when to fix, and when to stop

The most dangerous state for an AI pilot is not throwing errors but "appearing to still run": the model has call volume, the project team keeps tuning, reports still cite accuracy, yet business staff have already routed around the system, human review has not decreased, and end-to-end handling time has actually grown longer. To judge whether a project is healthy, you cannot look only at model metrics; you must also check business adoption, real quality, economic results, and risk control.

First distinguish model errors from system errors

Quality degradation in real processes is often not just a lack of reasoning capability. The model may not have received the latest order status, the knowledge base may still contain expired rules, an interface may return missing fields, or an upstream system may use a different data definition. Continuing to tweak prompts at this point only makes the problem temporarily less visible. Data quality sets the ceiling on achievable performance, so every error should be assigned to an actionable category: missing data, status delay, retrieval failure, rule conflict, model misjudgment, human operation, or process design flaw.

Take customer service as an example: if the system needs to query equipment status and schedule repairs, merely improving the fluency of answers is meaningless. In engineering terms, you also need to verify the availability of internal interfaces, how the system degrades under concurrency pressure, content filtering rules, and whether it can hand off seamlessly to a human agent when the model is unavailable. The safer approach is to start with low-risk time windows and a limited number of requests while keeping human takeover in place, rather than switching over all traffic as soon as average accuracy meets the target.

Set up a three-level decision: fix, pause, stop

• Keep fixing: the business value still holds, the problems are concentrated in identifiable data, interaction, or system steps, and the cost of fixing them is lower than the expected return. In this case, keep traffic limited and validate changes one by one.
• Pause scaling: the impact of errors is growing, human takeover is unreliable, audit records are incomplete, or the economic return has not yet been validated by real business metrics. Pausing is not giving up; it means going back to process, data, and permission design.
• Stop the project: the target task itself occurs too rarely, users have no sustained need, compliance boundaries cannot be met, or even at reasonable quality, maintenance and review costs still exceed the returns that can be realized. At that point, continued investment usually just sustains sunk costs.

Decisions should not be triggered by a single demo or one week of data. Before the pilot starts, agree on business metrics, the quality floor, risk red lines, and exit conditions, and review trends on a fixed cycle. Pay particular attention to whether the human correction rate is falling, whether exceptions recur, whether processing cycles are genuinely shorter, and whether the time saved is converted into capacity or revenue.

In high-risk business, humans should retain final control over key decisions. Any situation that cannot be traced, has no owner, or bypasses review is more urgent than a drop in model accuracy. Enterprise AI should not be treated as a one-off system that ends at delivery either; knowledge updates, data monitoring, exception reviews, and permission audits must become ongoing operational work. Being able to stop errors from spreading in time is usually more valuable than straining to prove a pilot succeeded.

8. FAQ: common questions about taking enterprise AI from pilot to scale

How should a company choose its first AI pilot use case?

Do not start from "which model is most advanced"; look for an entry point in business losses and process friction. Candidate use cases should meet at least three conditions at once: business results are quantifiable, existing data is sufficient to support validation, and the consequences of errors can be contained. Tasks suited to a first pilot are usually high-frequency, well-bounded, and already have a human baseline—for example, ticket classification, quality inspection assistance, knowledge retrieval, or demand forecasting.

When screening, you can build a use-case scoring sheet that judges value, feasibility, and risk separately:

• Value: can it reduce handling time, rework, inventory holdings, or labor input, and are the beneficiaries and the metric owner clearly identified?
• Feasibility: are historical samples usable, can inputs and outputs be defined, and are system interfaces and business permissions obtainable?
• Risk: are errors reversible, can results be reviewed by humans, and does it involve funds, health, safety, compliance, or customer rights?

The first project should not be a core decision process that spans multiple departments and requires overhauling many systems at once. Validating a complete but narrow closed loop first is worth more than building a demo system with broad coverage whose results cannot be attributed.

Can a time-boxed pilot validate a complex enterprise AI project?

A time-boxed pilot can validate "whether it is worth continuing," but it usually does not amount to full productionization. The purpose of a time box is to get real business evidence as quickly as possible, not to deliver the final form. For a complex project, first carve out a minimal closed loop: fix the user scope, limit the data sources, connect to one business node, and keep the original process as a control.

In the early stage, confirm the baseline, the acceptance criteria, and the failure boundaries; in the middle stage, complete data preparation, model evaluation, and process integration; in the late stage, run on limited traffic and record human takeovers, exception types, and actual savings. If, at the end of the pilot, you can only show offline accuracy without real users or changes in business time or cost, validation is not yet complete.

Where complex permissions, strict regulatory requirements, or multi-system changes are involved, a time-boxed pilot is better suited to feasibility assessment and controlled launch. Security review, stability engineering, and organizational rollout should be set up as separate phases and should not be compressed to meet a deadline.

How accurate does AI need to be before it can go live?

There is no universal threshold that applies to every scenario. Accuracy must be judged together with the cost of errors, human review capacity, and how traffic is controlled. The same metric may be acceptable for marketing copy assistance and completely insufficient for credit, medical, or industrial safety decisions.

The go-live decision should at least look separately at: misses and false alarms on critical errors, performance across different business segments, whether confidence can be calibrated, stability under abnormal inputs, and whether the system can degrade gracefully after a failure. Average accuracy can mask a small number of high-loss errors, so it cannot be the sole entry criterion.

A more actionable standard: high-risk results must go through human review; low-confidence requests are automatically handed off to a human; the original process is restored when the model or a dependent system is unavailable; and after launch, continuous sampling is performed with pause conditions defined. High-risk industries in particular should let humans retain key decision rights, with AI handling suggestions, screening, or information organization rather than bypassing the accountable party.

The pilot works but ROI isn't obvious. Should we keep expanding?

First distinguish "value not yet released" from "the economic model doesn't hold up." When the pilot scope is small, fixed investment dilutes the returns; if humans still have to review everything in full, the system is not connected to the formal process, or usage is too infrequent, technical effectiveness will not translate directly into financial returns. In that case, fix the process first rather than immediately replicating it to more departments.

When recalculating ROI, include the full cost—data governance, system integration, inference resources, human review, monitoring and operations, compliance review, and change management—while also confirming whether the benefits can actually be realized. For example, if operating time was saved but overtime, outsourcing, or waiting time did not decrease, the saved hours cannot be converted directly into profit.

Signals that you can keep expanding include: core metrics keep improving, marginal delivery cost is falling, and new use cases can reuse the data pipelines, evaluation system, and governance mechanisms. Signals that you should pause or scale back include: returns depend on heavy human remediation, exception costs rise with traffic, data maintenance consistently exceeds business returns, or value can only be shown by broadening the measurement scope. What should be replicated at scale is reusable engineering capability and governance methods, not the pilot's interface.