Budgeting for AI in the Health System Annual Operating Plan

Why AI budgets leave production obligations unfunded

AI spend in a health system rarely sits in one place. Clinical departments fund use cases, operations funds workflow tools, and IT absorbs integration and security. When the annual operating plan is assembled from those separate requests, the visible items are model licences and pilots. The items that arrive later, once an AI system touches PHI in production, tend to have no owner and no line.

Those items include enforcing policy on PHI and tool access while requests are running, keeping evidence that can be examined later, operating the security and compliance processes around AI, and staffing the review of what AI did. None of them is exotic. They are the same kinds of obligations the health system already carries for other systems that handle ePHI, applied to a new component.

The practical response is to treat AI as a lifecycle exercise. The plan should show what it costs to build, what it costs to run, and what it costs to control and evidence, and it should assign each to a named budget owner. The cost categories in this guide are a planning structure, not a published benchmark. Adjust them to your own risk analysis and portfolio.

Six line items for the AI operating budget

A usable structure has six lines. The first three are mostly familiar. The last three are the ones most often missing from the plan.

• Capability and use-case spend: Licences, model access and delivery cost, grouped by use-case type: diagnosis and treatment, patient engagement and adherence, and administrative applications. Grouping this way makes the different levels of PHI exposure visible.
• Data and integration work: Data preparation and connections to clinical systems, APIs and tools. Mostly one-time, with recurring maintenance. Authentication, transmission security and integrity measures often sit in IT security budgets, so reference them explicitly.
• Runtime policy enforcement: Controls that decide, at the moment of a request or tool call, what AI may access or do with PHI. Initial configuration is one-time. Policy changes and operation recur.
• Audit-ready evidence: Capture, storage, retention and review of AI activity records. Recurring, and separate from licence fees.
• Security and compliance operations: Risk analysis updates, control testing and compliance reporting for AI within the existing Security Rule process.
• Staffing and ownership: Named roles for policy decisions, evidence review and incident response. Often the largest omission.

Separating one-time build costs from recurring run costs

The distinction that matters most for the operating plan is what continues after go-live. Integration, data preparation and initial control configuration are build costs. They can be scoped, scheduled and capitalized or expensed according to your finance policy. Log retention, evidence review, risk analysis updates, compliance operations and staffing are run costs. They repeat every year and grow with the number of AI use cases in production.

A pilot budget that includes only build costs gives a misleading picture. A pilot may run on a limited data set with manual oversight, which hides the cost of continuous enforcement and review. When the same system moves to production, the run costs appear without a matching budget line, and the program either stalls or is funded from another owner's budget.

A simple discipline helps. For every AI initiative, require the intake form to state the expected run cost for runtime control, evidence and review alongside the licence and build estimate. Finance can then see the multi-year commitment before approving the first stage.

What HIPAA audit controls mean for the budget

The audit controls standard at 45 CFR 164.312(b) requires hardware, software and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. The Security Rule's Subpart C standards apply to covered entities and business associates with respect to ePHI. The standard is technology-neutral and does not mention AI. Applicability to an AI system rests on whether that system contains or uses ePHI, so confirm scope with compliance counsel. Model endpoints, tool or API calls and integration layers in the PHI path are the components to examine first.

The standard has two verbs, record and examine. A budget that funds only capture of records has funded half of it. Review effort, with a named owner, belongs in the plan. OCR's January 2026 cybersecurity newsletter also notes that a regulated entity's risk analysis and risk management plan can inform its decisions on implementing these security measures, so tie security and audit lines to your documented risk analysis. NIST SP 800-66 Rev. 2 is a useful checklist source when scoping Security Rule activities.

As of October 2026, the codified text still shows audit controls at 164.312(b). A January 2025 proposed rule would redesignate the standard as 164.312(d)(1) and rename it audit trail and system log controls. It is a proposal. A modest contingency for changes to audit and log requirements is reasonable, as is asking vendors how they would respond.