Proving the value: how to know an AI-enabled change is worth scaling

By Mahsa Rezaei, Co-founder & Executive Director · Leads OpenBuild

Many organizations now have a redesigned workflow on paper, or an AI tool that looked impressive in a demo. Far fewer can say whether the change actually made things better: for staff, for the people they serve, and for the organization’s capacity. Without that evidence, a good idea either fades quietly or gets rolled out everywhere on hope alone.

OpenBuild exists for that gap. Its job is value realization: putting one redesigned change to work, proving whether it creates real value, and deciding what it would take to scale.

Start with a baseline

You cannot prove improvement without knowing where you started. Before anything changes, capture how the work runs today. Time matters, but it is only one measure. Look at quality and errors, waiting time, rework, staff workload and experience, and the outcomes that matter most to the people you serve. If you only measure speed, speed is all you will notice.

Put the simplest version to work

The goal is not a perfect system. It is the simplest working version of one redesigned step, built with practical, low-code tools and your existing systems, and used by real staff on real work. Small and real beats large and theoretical: you learn more from one week of actual use than from months of planning.

Choose the right level of autonomy

Before the change goes live, decide how much of the task is left to AI. In an assisted setup, AI drafts or recommends and a person approves anything consequential. In a supervised setup, AI handles bounded tasks while people monitor and step in on exceptions. In an autonomous setup, AI handles routine, low-consequence, reversible tasks within defined limits. Most first changes should start at assisted, with a named person accountable and clear escalation paths.

Measure value honestly

Once the change has run, compare the results with the baseline. Include what the numbers cannot show: what staff noticed, where exceptions appeared, and whether the new review work cancelled out the time saved. Honest measurement sometimes shows that a change helps less than hoped. That is valuable to know before you invest further.

Decide: scale, modify, pause or stop

• Scale: the change created clear value, and you know what scaling requires.
• Modify: it showed promise, but something needs to change first, such as the workflow, the controls or the training.
• Pause: the idea is sound, but the timing, data or capacity is not right yet.
• Stop: the evidence says it is not worth it. That is a valid answer, and it saves you from scaling the wrong thing.

Plan what scaling really takes

A change that works for one team does not automatically work everywhere. Before rolling it out, plan the people side (who uses it, who owns it, what training they need), the data side (access, quality and privacy), the governance side (approvals, monitoring and escalation), and the cost of running it at scale. A scale plan turns a promising result into an organizational decision.

From proven value to a new structure

Once a change is proven and spreading, the organization around it has to adapt too: roles shift, decision rights move, and AI takes on part of the work. That is where the next stage begins, designing how teams should be structured so the change lasts.