At Ai4 this year, a panel tackled one of the hardest problems in enterprise AI right now: how do you take a pilot that works and turn it into something that runs across the whole company?

Our Field CTO, Raghu Vatte, joined Reena Solomon (Head of AI Partnerships, Airbus), Seth Siegler (Chief Innovation Officer, eXp Realty), and Tracy St.Dic (Global Head of Talent, Zapier), moderated by Alina Rivilis (Director, Data Science & AI, Fairstone Bank of Canada).

The panel didn’t land on a single silver-bullet metric. What it landed on instead was more useful: a shared picture of where scaling efforts actually break, and what the organizations getting it right are doing differently.

1. There Is No Single KPI That Tells You It’s Time to Scale

The reality: Executives keep asking for the one signal that says “go”. The panel’s answer, in different words, was the same: it doesn’t exist.

Pilots stall for a predictable reason: they get built technology-first instead of problem-first. When a team starts with the tool and works backward to a use case, the ROI story never quite holds together, and it never earns the trust to expand past the original team.

What this means for you: Before you build, get specific about whose problem you’re solving and what the cost of that problem actually is today. If you can’t answer that, no dashboard is going to save the pilot later.

2. Trust Is the Real Bottleneck, Not Technology

The insight: Raghu framed this as a two-sided problem. On one side, end users are being asked to trade predictable, deterministic software for probabilistic AI output, and that’s a real shift in how they do their job every day, not a small ask. On the other side, business owners have often put real money into a pilot and are left with anecdotes (“this feels good”) instead of hard numbers on cost, benefit, and reach.

Without tooling that gives a genuine cost and ROI picture, and without human-in-the-loop feedback that builds user confidence, Raghu was direct about the outcome: the project stays a pilot. Indefinitely.

What this means for you: Build the measurement layer at the same time as the pilot, not after. If leadership can’t see real cost-benefit numbers and users don’t have a way to give feedback and see it acted on, scaling will stall no matter how good the underlying model is.

3. Buy vs. Build Comes Down to What You’re Actually Good At

The framework: Every panelist converged on some version of the same rule: build where it’s core to your advantage, buy where it isn’t.

Raghu put it plainly: platforms built specifically to take AI systems from inception to production, like AI Squared’s, exist because most companies shouldn’t be spending their engineering time reinventing orchestration and control-plane infrastructure. That’s not where their differentiation lives. Where it makes sense to build is when the capability is core IP, or when a business needs to own the outcome for reasons of safety, compliance, or competitive edge.

What this means for you: Ask what you’re actually trying to protect before deciding to build. If the answer is “control over something safety-critical or truly differentiating,” build it. If the answer is “we didn’t look for a tool,” buy it.

4. Citizen Development Is a Double-Edged Sword

The tension: Several panelists praised citizen development as a way to self-fund AI adoption and get tools built by the people closest to the problem. Raghu agreed with the upside, but pushed back on the rest of the room with a warning from experience running large federal and enterprise deployments: unmanaged citizen development doesn’t stay cheap.

A tool built by one team becomes a pilot, then an MVP, then something that needs a maintenance owner, a compliance review, and a budget line nobody planned for. Multiply that by dozens or hundreds of teams and the total cost of ownership balloons fast.

What this means for you: Give builders freedom over the value they add, not over every layer underneath it. A shared model router instead of everyone picking their own LLM, and standard guardrails instead of every team inventing its own, keeps the innovation without the runaway maintenance bill.

The closing point: Raghu’s advice here cut against a common instinct in the room: stop trying to get a 5,000 or 20,000-person workforce to adopt a brand-new application. People have spent years becoming experts in the tools they already use, and asking them to abandon that expertise for something new, every few months, breeds resistance that has nothing to do with whether the AI itself works.

The better path is infusing AI into the systems people already know, as a widget or a workflow layer, so adoption doesn’t require retraining an entire organization from scratch.

What this means for you: When you’re planning your next agentic rollout, ask where your people already live day to day, and design to meet them there instead of pulling them somewhere new.

Conclusion

Scaling AI from pilot to enterprise isn’t a switch you flip. It’s an iteration model: a bigger pilot, then a bigger experiment, then an initiative, then something enterprise-wide. The organizations that get there fastest aren’t the ones with the flashiest model. They’re the ones who start with the problem, build trust and measurement from day one, know exactly what they should build versus buy, keep citizen development inside real guardrails, and meet their people where they already work.