Measuring ROI and Risk
An AI program that can't say whether it's working will eventually lose its funding β or, worse, keep running long after it should have been stopped. Measurement is what separates a disciplined program from an expensive act of faith. The architect defines, up front, both the value the program must deliver and the risk it is allowed to carry.

Define success metrics before you build
The single biggest mistake is launching a use case with no agreed definition of success. Decide the metrics before the pilot, so the result is a verdict rather than an argument:
- Value metrics β time saved per task, volume handled, backlog cleared, user satisfaction. Tie these to a baseline you measured beforehand, or you'll have nothing to compare against.
- A clear bar. State the threshold the pilot must clear to graduate. "Cuts research time in half for the records team" is a bar; "people seem to like it" is not.
Metrics chosen up front also keep the program honest when a beloved demo turns out not to move any number that matters.
Track cost, quality, and refusal rate
Operational health needs continuous measurement, not a one-time check. Three signals matter most:
- Cost. Track token spend and infrastructure cost per use case. A local-first routing policy β embeddings and routine work on hardware you control, cloud reserved for the hardest reasoning β is how cost stays sane at scale. Watch the trend, not just the total.
- Quality. Sample real answers and grade them. Are citations accurate? Are responses grounded in retrieved sources or drifting into invention? A shared evaluation harness over a common RAG core lets you measure quality the same way across every use case.
- Refusal rate. How often does the system decline to answer? Some refusal is healthy β it means the tool isn't bluffing. But a rising refusal rate signals gaps in your content or retrieval that are quietly degrading the experience.
Weigh risk against value β and kill what doesn't clear the bar
Value is only half the equation. Every use case carries risk: a wrong answer, a privacy exposure, a biased outcome. In a public-sector context the asymmetry is stark β a small efficiency gain rarely justifies the reputational or legal cost of mishandling citizen data. The governance owner weighs the two explicitly:
- High value, low risk β ship and scale.
- High risk, modest value β redesign to lower the risk, or don't ship.
- Low value, any risk β kill the pilot. This is the discipline most programs lack.
Stopping a pilot that didn't clear its bar is not a failure of the program; it is the program working. Every pilot you retire cheaply protects the budget and credibility of the one that finally succeeds.