Health systems do not need more AI pilots. They need a better way to decide which AI opportunities to pursue, how to deploy them, who remains accountable after deployment and whether they create measurable value.
That is not simply a technology problem. It is an operating model problem.
Over the past several years, health systems have developed AI strategies, established governance committees, selected technology platforms, created vendor partnerships and launched numerous pilots. But as organizations move from experimentation to enterprise deployment, a more consequential set of questions is emerging: Who decides which AI opportunities the organization should pursue? How do those opportunities move into production? Who owns them after deployment? And how does the organization know whether they are creating value?
In my previous Becker’s articles, I argued that AI creates value when it changes how work gets done and described the AI value gap between successful pilots and repeatable enterprise value.
The next challenge is organizational.
If health systems want to cross that gap repeatedly, they need an AI operating model: a repeatable system for moving the right opportunities from idea to production, adoption, measurable outcomes and continuous improvement.
AI strategy is not an AI operating model
Many health systems now have an AI strategy. But strategy describes where an organization wants to go. An operating model determines how it gets there repeatedly.
Without an operating model, AI initiatives often move through an organization differently depending on where they originate. One project begins with a clinical leader. Another comes through IT. Another originates with data science. Another arrives through a vendor relationship or the electronic health record.
Each may follow a different process for prioritization, architecture, security, validation, governance, deployment, monitoring and outcome measurement.
The result is not necessarily a lack of innovation. It is a lack of repeatability. A strong AI operating model creates a common path from opportunity to value.
Put simply, it should enable an organization to:
Choose → Govern → Operationalize → Adopt → Realize value
The objective is not to centralize every AI decision or create another layer of bureaucracy. It is to make the path from AI opportunity to measurable value clear, repeatable and accountable.
The five components of an enterprise AI operating model
The organizational structure will vary by health system. A large academic medical center will not organize AI exactly like a regional health system. But five capabilities should form the foundation of an enterprise AI operating model.
1. Strategy and portfolio: what problems deserve AI investment?
The operating model should begin before anyone selects a model or vendor.
Health systems will increasingly have more potential AI opportunities than resources to pursue them. The first responsibility of an enterprise AI capability is therefore prioritization.
Every proposed initiative should answer several questions: What problem are we solving? Why does it matter? Who owns the problem? What outcome should change? How will we measure that change?
And perhaps most importantly: Is AI the best way to solve it?
Not every problem requires AI. Sometimes workflow redesign, analytics, automation or a simpler rules-based solution will deliver greater value with less complexity.
If AI is appropriate, the next question is whether to build, buy or partner.
The decision should consider strategic differentiation, time to value, integration requirements, internal expertise, total cost of ownership and the maturity of available commercial solutions.
The question is not simply, “Can we build it?” It is, “Should we?”
AI initiatives should compete for resources as part of an enterprise portfolio rather than advance simply because the technology is interesting or a champion is enthusiastic. The objective should not be to maximize the number of AI projects. It should be to allocate scarce organizational capacity to the opportunities most likely to create meaningful clinical, operational or financial value.
2. Governance and decision rights: who can say yes, who can say no and who is accountable?
Healthcare cannot scale AI without governance, but it also cannot scale AI if every use case enters the same lengthy approval process, regardless of risk. A clinician using generative AI to summarize administrative information should not necessarily require the same level of oversight as an AI system influencing a clinical decision.
The operating model therefore needs clear decision rights and risk-based pathways. Who can approve a lower-risk AI application? Which use cases require clinical validation? When should privacy, security, legal or compliance teams become involved? Which decisions require enterprise-level governance? Who has authority to pause or retire an AI system?
Good AI governance should clarify who can say yes, who can say no and who remains accountable after the decision. The level of oversight should increase with the potential impact of the AI. This becomes even more important as AI applications move from predicting and recommending to generating content and, increasingly, taking actions. As autonomy increases, decision rights and controls must evolve with it.
The goal of governance should not be to eliminate all risk. It should be to create enough trust and accountability for responsible AI to scale.
3. Technology and operationalization: can we make deployment repeatable?
A prototype and an enterprise AI capability are fundamentally different things. Production AI requires reliable data pipelines, integration, security, access controls, versioning, observability and monitoring. The requirements also vary by type of AI. Traditional machine learning requires capabilities for deployment and performance monitoring. Generative AI adds requirements around grounding, evaluation and model management. More autonomous AI systems introduce additional considerations around permissions, orchestration and auditability.
But health systems should not have to reinvent these capabilities for every project. The more important question is, What can we standardize and reuse? Can teams reuse deployment patterns and monitoring infrastructure? Can they access approved platforms and models? Can architecture and security reviews follow established patterns? Can lessons from one implementation reduce the effort required for the next?
The real measure of enterprise AI infrastructure is not whether it can support one successful deployment. It is whether every deployment makes the next one easier.
If the 10th AI implementation is as difficult to operationalize as the first, the organization may be scaling projects without building an enterprise AI capability.
4. Workflow and adoption: what will people do differently?
Technology creates potential value. Workflow converts that potential into operational value.
Before an AI initiative moves into production, leaders should be able to answer a deceptively simple question: What will someone does differently because this AI exists?
A clinician might review fewer charts. A revenue cycle specialist might investigate higher-risk claims first. An analyst might spend less time answering repetitive questions. If an organization cannot describe how the work will change, it may have built an AI solution without designing an operational solution. This is also why adoption cannot begin at go-live.
Clinicians, operational leaders and frontline users should participate in workflow design before deployment. Their role is not simply to validate technology after it has been built. They help determine how technology should fit into the work in the first place.
The critical question is not where to put the AI.
It is what work should change because the AI exists.
5. Ownership and value realization: who owns AI after go-live?
Go-live should not mark the end of an AI initiative. It should mark the beginning of AI lifecycle management. Models drift. Workflows change. Patient populations change. Vendor models evolve. Users develop new behaviors. Business priorities shift. Every production AI system therefore needs clear ownership beyond deployment. At minimum, three responsibilities should remain explicit.
Technical ownership: Is the system reliable, secure and performing as expected?
Operational ownership: Is the workflow functioning as intended, and are people using the solution?
Value ownership: Is the AI producing the clinical, operational or financial outcome that justified the investment?
These responsibilities do not necessarily require three different people, but all three must exist. Without clear lifecycle ownership, health systems risk accumulating AI applications that remain technically live long after their operational value has diminished.
Organizations therefore need processes not only for deploying AI, but also for monitoring, improving, revalidating and, when necessary, retiring it. Knowing when to stop an AI solution is part of the operating model.
Centralize standards, federate execution
One of the most common organizational questions is whether AI should be centralized or decentralized. The answer is neither.
Health systems should centralize standards and federate execution. Certain capabilities benefit from enterprise consistency. Governance, architecture, security, technology platforms, validation standards, monitoring practices, vendor evaluation and portfolio visibility should generally follow common standards. But AI value is created inside clinical and operational workflows.
Use-case discovery, workflow redesign, adoption, domain expertise and outcome ownership need to remain close to the people doing the work.
This naturally creates a hub-and-spoke model. The central AI capability becomes the hub, providing standards, platforms, expertise and reusable infrastructure.
Clinical and operational domains become the spokes, identifying problems, helping design solutions, changing workflows and owning outcomes.
But there is an important distinction. The central team should not become an AI factory that simply receives requests from the rest of the organization. Its job should be to make the entire organization better at identifying, deploying and operating AI responsibly.
That is the difference between centralizing AI development and building an enterprise AI capability.
The AI leader’s role is translation
An effective operating model also changes what organizations should expect from AI leadership. The most important AI leader may not be the person who understands the newest model architecture better than everyone else. The role increasingly requires translation.
AI leaders must connect executive strategy with technical capability, clinical problems with data science, innovation with governance, model performance with business outcomes, and technology teams with frontline workflows.
Technical teams need to understand why a workflow matters. Clinical leaders need to understand what AI can and cannot reliably do. Executives need to understand the difference between a successful pilot and a scalable capability. Governance teams need to understand the consequences of both too little and too much control.
This is why enterprise AI leadership cannot sit entirely inside technology, data science, clinical operations or strategy. It must connect them. The AI leader’s job is not simply to build AI. It is to create the organizational conditions under which AI can repeatedly produce value.
Measure the operating model, not just the models
Most organizations know how to measure individual AI models. They track accuracy, precision, recall, calibration, latency, reliability and drift. Those metrics remain important. But an enterprise AI operating model requires another layer of measurement.
Leaders should ask, How quickly do promising use cases move from intake to decision? What percentage of deployed AI solutions achieve their expected outcomes? How much infrastructure and governance can be reused across deployments? How quickly are underperforming solutions improved or retired?
These are not model metrics. They are measures of organizational AI capability. Perhaps the most important question is the simplest: Is the organization getting better at deploying AI?
If the 10th AI deployment requires the same organizational effort as the first, the organization may be accumulating AI applications without building an AI capability.
From AI projects to an organizational capability
Healthcare does not need another layer of AI bureaucracy. It needs a repeatable way to convert AI opportunities into measurable outcomes.
That requires strategy to identify the right problems, governance to establish trust and decision rights, technology to make deployment repeatable, workflow redesign to create adoption, and lifecycle ownership to sustain value.
In my previous Becker’s article, I argued that AI creates value when it changes how work gets done. In the second, I described the AI value gap between successful pilots and repeatable enterprise value. The AI operating model is the organizational machinery for crossing that gap repeatedly.
The health systems that lead the next phase of AI will not necessarily have the most models, the largest AI teams or the greatest number of pilots. They will have something more difficult to build: an organizational capability for repeatedly turning AI into measurable value. That requires becoming exceptionally good at answering three questions: What AI should we pursue? How do we move it safely and efficiently into the workflow? Did it create enough value to sustain and scale?
That is the purpose of an AI operating model. When that capability exists, AI stops being a collection of technology projects.
It becomes part of how the organization operates.
Executive takeaways
● An AI strategy is not an AI operating model. Strategy defines where the organization wants to go; the operating model determines how it gets there repeatedly.
● Build the operating model around five capabilities: strategy and portfolio, governance and decision rights, technology and operationalization, workflow and adoption, and ownership and value realization.
● Centralize standards and federate execution. Enterprise teams should provide common governance, architecture, platforms and monitoring while clinical and operational teams remain close to workflows and outcomes.
● Make governance risk-based and decision-oriented. Organizations need clarity about who can approve, stop and remain accountable for AI as systems become increasingly capable and autonomous.
● Treat go-live as the beginning. Every AI solution needs technical, operational and value ownership throughout its lifecycle.
● Measure organizational capability, not just model performance. Each AI deployment should make the next one faster, safer and easier.
Dr. Yapalparvi is an executive leader in artificial intelligence, machine learning, and healthcare analytics with more than 15 years of experience leading enterprise AI strategy and production-scale AI initiatives across payer and provider organizations. He has led multidisciplinary teams and initiatives spanning payment integrity, hospital-at-home, remote patient monitoring, clinical and operational decision support, revenue cycle analytics, MLOps, and generative AI.
At the Becker's 11th Annual IT + Revenue Cycle Conference: The Future of AI & Digital Health, taking place September 14–17 in Chicago, healthcare executives and digital leaders from across the country will come together to explore how AI, interoperability, cybersecurity, and revenue cycle innovation are transforming care delivery, strengthening financial performance, and driving the next era of digital health. Apply for complimentary registration now.
