Where enterprise AI programs stall
I use five stages when discussing AI maturity with executive teams: experimentation, departmental wins, platform foundation, operationalized AI and an AI-native organization. The distinction I spend the most time on is between departmental wins and a platform foundation. Several successful teams can still depend on separate definitions, informal support and one person who knows how each integration works. Expanding access exposes those dependencies.
The gap between stage two and stage three is where organizations lose 12 to 18 months, and it is rarely a technology problem. The CIO wants a platform. Business units want quick wins. Nobody owns data governance. My advice is consistent: solve the org design problem first, then the technology problem. An operating model is how you do that before you expand access.
Name the work that continues after launch
An operating model describes who does the work once the implementation team moves on. For enterprise AI that includes reviewing new question types, maintaining source access, resolving definition disputes, assessing behavior changes and responding to incidents. None of it disappears because the interface is conversational.
Start with the recurring events the service will face. A source schema changes. A manager moves to another division. A metric owner revises a definition. A model or client version changes. A user receives an answer they cannot reconcile. For each event, name an owner, the evidence needed and the expected response.
Keep the agreement practical. A pilot may need a one-page ownership register and a weekly review. As users and dependencies increase, add the support coverage and change controls they require. Use existing governance processes where they fit. Creating a second approval track for AI can leave people uncertain which one governs a real incident.
Separate business authority from technical operation
The business owner decides whether an answer supports the intended decision. The technical owner maintains the service and investigates behavior. The data owner resolves questions of meaning and quality. In a small team one person may hold several roles, but the decisions stay distinct.
Take a revenue number that disagrees with an executive report. An engineer can show which records were queried but has no authority to decide whether cancellations belong in the metric. The CFO's team can settle the definition but may need technical evidence to see how the result was produced. The operating model connects those two responsibilities instead of leaving them to hallway conversations.
Do not let the original developer become the permanent interpreter of every result. Years ago I helped build an internal enterprise data integration platform, well before managed integration products became mainstream, and the hardest lesson was not technical. Knowledge that lived in two people's heads became the bottleneck. Turn repeated explanations into maintained definitions, known limitations and reviewer guidance.
Treat every change as a service change
A connector update, a new source or a revised tool description can change behavior while the interface looks identical. Define which changes require reevaluation, scaled to consequence. A wording improvement and a permission change should not get identical review, but both need an owner.
Maintain a small representative evaluation set with ordinary questions, important exceptions, ambiguous requests and access denials. Record which version and configuration passed. When behavior shifts, compare evidence instead of memories of an old demo.
Plan retirement alongside expansion. A source becomes unreliable, a workflow loses its owner or a pilot ends without a case to continue. Document who disables access, what users see and how records are retained under policy.
Give users a support contract, then test it
Users need to know what the assistant is for, what evidence to inspect and where to report a problem. A short service description covering supported decisions, freshness expectations and review obligations does more than an architecture diagram. Treat repeated confusion about a metric as a definition problem, not a training gap, and give every responsibility a backup owner.
Before expanding access, have the sponsor run the ownership register against one source change, one disputed metric and one support ticket. If each has a named owner and a workable resolution path, the service can absorb growth. If not, close the gap first. That is what moving from stage two to stage three actually looks like.