A weekly Founder Note on the infrastructure, decisions and operating models shaping enterprise AI.
A pilot can prove that AI is capable. It cannot, by itself, prove that an enterprise is ready to depend on it.
The hardest questions emerge after the demo: who owns the result, what happens on a bad day, how does the system learn, and will the economics still work at real volume?
Moving into production is an operating discipline. It requires a clear workflow, a measurable outcome and a way to detect and correct failure.
Start with a narrow business outcome
A pilot described as 'an AI chatbot' is too broad to manage. A pilot that helps a service team resolve a defined set of customer questions within an agreed time and quality standard is easier to evaluate.
Name the user, the task and the baseline. Measure resolution, time spent, accuracy, escalation and customer experience before and after deployment. Set the conditions under which the system should stop or hand off.
The objective is not to maximize the number of automated conversations. It is to improve the outcome of the workflow.
Prepare knowledge and permissions
Production systems need approved, current sources. Each source should have an owner, a version and a rule for who may access it. Where documents conflict, the system needs a priority order or a human escalation.
An AI assistant should not be able to retrieve information simply because it exists in an indexed repository. Access must follow the person's role and the purpose of the interaction.
This work can feel less exciting than a model demo. It is often where reliability begins.
Build an evaluation loop before launch
Create a representative set of cases: common requests, exceptions, ambiguous questions, policy changes and attempts that should be refused or escalated. For a multilingual service, include real language variation, accents and code-switching.
Define what a correct result means for each case. Test the complete chain, including recognition, retrieval, model response and action. Repeat the evaluation when a model, prompt, policy or integration changes.
After launch, sample real outcomes and feed corrections back into knowledge, terminology, rules and tests. Production quality is maintained, not declared once.
Design for interruption and cost
A service should have a plan for timeouts, unavailable models, poor audio, missing sources and uncertain outputs. Customers need a clear next step, and employees need enough context to take over.
Estimate cost at the expected volume, including speech, model calls, infrastructure, telephony, monitoring and human review. Track latency as customers experience it, not only the speed of one model call.
A workflow that works only under ideal conditions or a small pilot budget is not ready to become a core service.
Assign a real owner
Technology, operations, domain experts and risk teams each have a role. Someone still needs to own the end-to-end result.
That owner should see a regular view of quality, escalations, failures, language-level performance, cost and business impact. They need authority to pause a use case, update its knowledge and change its boundaries when evidence demands it.
Enterprise AI becomes infrastructure when this cycle of measurement and improvement is routine.
What next
What this means for enterprise leaders
Before expanding an AI pilot, ask its team for one page: the workflow and baseline, success threshold, source owners, escalation rules, evaluation cases, cost at target volume and the person accountable for results.
If those answers are unclear, the next investment should be in the operating system around the model. That is what makes a promising pilot dependable.
The next Founder Note will explore how enterprises can make these capabilities reusable across teams instead of rebuilding each AI workflow from the beginning.