A hospital buys enterprise AI the way it buys any material system: through a procurement path with named signatories, a budget line that is either capital or operating, an IT security review, and a committee that can stop the deal cold. Most enterprise AI is bought as opex, a recurring subscription or a per-entity licence, because that is the line item a CIO can approve without triggering a full capital process. And deals rarely die on price. They die in the security review, or on the desk of a CFO who was never shown a payback he can defend.
If you sit on either side of this table, stop treating procurement as a formality after the demo goes well. Every buyer in this market has seen a demo that worked. The procurement path is where the decision gets made, and knowing the route is the difference between a signed contract in one budget cycle and a proof of concept that never converts.
Capex or opex, and why the answer decides the signatory
The first fork is budget classification, because it determines who signs and how long the route is.
A capital purchase buys an asset the hospital owns and depreciates: servers, an on-premise appliance, a perpetual licence, a large one-time build. It goes through the capital budgeting process, which in most large Indian hospital groups is an annual or half-yearly cycle with a capex committee, a threshold above which the board or a group CFO must approve, and a depreciation schedule finance cares about. If you miss the window, you wait for the next one.
An operating purchase is a recurring cost: a monthly subscription, an annual per-entity licence, a managed service with a setup fee and a monthly run rate. It comes out of the operating budget, which a CIO or Head of Digital typically controls up to a delegated authority limit. Below that limit the signatory is the CIO. Above it, finance and sometimes the group COO enter.
This is why the smart structure for most AI deployments is opex. A voice agent priced as a setup fee plus a monthly recurring charge, or a compliance layer licensed per entity per year, lands on the operating line and inside the CIO's delegated authority for the pilot. The one caution: an on-premise deployment that the hospital's own security posture demands can push part of the cost back into capex, because owned infrastructure is a capital asset. Decide the deployment architecture and the budget classification together, because one dictates the other.
The signatories, in the order they actually appear
The people who sign are not who a first-time vendor expects. The demo is usually arranged by a clinical champion or a Head of Digital who wants the tool. That person is your sponsor, not your signatory.
The CIO or CTO owns the technical decision and, up to a delegated limit, the budget authority. This is where an opex deal genuinely stops and starts.
The CFO owns the money and the objection that kills the most deals. The CFO is not evaluating your technology. The CFO is evaluating whether the payback is real, whether the number on the slide will show up in the P&L, and whether this recurring cost can be defended in a budget review nine months from now. A CIO who walks in without a defensible business case is asking the CFO to take a technology bet on faith, which no CFO does twice.
The procurement committee owns the process and the negotiating power over terms. In a large group this is a standing committee, sometimes with an RFP requirement above a spend threshold. It is where a competitor's counter-bid, an incumbent HMIS vendor's objection, or a simple demand for three reference customers can add a full budget cycle to your timeline.
The Medical Director or a clinical governance body enters whenever the tool touches a clinical workflow, which for an AI scribe or a decision-support tool is always. This is where the liability question surfaces, and it has a specific shape in Indian healthcare.
Where the deals actually die
Three places, in rough order of frequency.
The IT security review is the most common graveyard, where an underprepared vendor loses weeks. The hospital's security team, or its DPO under the Digital Personal Data Protection Act 2023, will ask where patient data goes, who can access it, whether it leaves the hospital's boundary, how it is encrypted, and what the audit trail looks like. A vendor who cannot answer these in writing, with a data flow diagram and an access-control model, does not fail the review so much as stall in it indefinitely. Treat the security questionnaire as a deliverable to arrive with.
The CFO objection is the second graveyard, a business-case failure disguised as a pricing objection. When a CFO says the price is too high, the CFO usually means the payback is not legible. A recurring AI cost that cannot be tied to a specific saving or a specific revenue recovery is, from a finance seat, an open-ended liability. The deals that clear this gate come with a business case that separates cost-side savings from revenue-side capture, models payback per site rather than as one blended number, and is honest that costs land before returns arrive.
The liability question is the third, and most vendors handle it badly by trying to make it disappear. A Medical Director will ask who is responsible when the AI gets something wrong. Liability decomposes by failure class. Clinical judgment stays with the clinician, and vicariously with the hospital, under Indian law regardless of what a vendor contract says. No pathway moves clinical accountability onto a software company. What a vendor can carry is system behaviour: output outside the intended-use envelope, a note attributed to the wrong encounter, a retrieval pulling the wrong record, an uptime breach, a data obligation under DPDP. That belongs in the contract as accuracy thresholds, an SLA, and a capped indemnity with data breach carved out of the cap. A vendor who offers to absorb clinical liability is selling comfort it cannot legally deliver.
How long the route takes
Enterprise healthcare buying is slow, and pretending otherwise loses credibility with anyone who has done it. In the wider health IT market, sales cycles have been stretching: 63 percent of 107 US health IT vendor executives reported sales cycles lengthening, most commonly by 30 to 60 days, with 12 percent citing extensions beyond 90 days (Source: Black Book Research Flash Survey, late October 2025). That survey reflects a US market shock rather than Indian conditions, so read it as a directional signal that these cycles move in months, not as an Indian benchmark [verify: a named, dated India-specific hospital AI procurement cycle-length figure].
For a large Indian hospital group, the route runs like this. The opex pilot clears the CIO's delegated authority relatively fast, which is why pilots are structured as opex. Then the security review, the business case for the CFO, and clinical governance run in parallel if you are organised and in series if you are not, and that difference is worth a full budget cycle. Scaling to a group-wide rollout re-enters the process at a higher spend threshold, which usually means the procurement committee, and sometimes the capital budget if the deployment architecture changes.
The lever that shortens all of this is sequencing. Run the security documentation, the business case, and the clinical governance conversation as three parallel workstreams from the day the pilot is agreed, each with a named owner on the hospital side. Deals close when these run at once, not one after another.
What both sides should take from this
For the buyer: classify the spend early, because capex and opex send the deal down different routes with different signatories. Insist on a business case you can defend to your own CFO. Make the vendor produce the security documentation before the review. And force the liability conversation early, because a vendor who cannot decompose it honestly has not deployed in a regulated setting.
For the vendor: the sale is won by arriving at each gate with what that gate needs. Structure the pilot as opex so it clears the CIO. Bring the security pack, the defensible business case, and the honest liability position unprompted. Every gate you clear before you are asked is a budget cycle saved.
Frequently asked questions
What is the procurement process for hospital AI?
A hospital procures AI through a defined path: an internal sponsor arranges the demo, the spend is classified as capital or operating, the deal clears the relevant budget authority, an IT security review checks data handling under DPDP 2023, a business case satisfies the CFO, and clinical governance reviews any tool that touches patient care. In large groups a procurement committee, sometimes with an RFP requirement above a spend threshold, governs terms. It runs in months, and moves faster when the security review, business case, and clinical review run in parallel rather than in sequence.
Is hospital AI a capex or an opex purchase?
Most enterprise AI is bought as opex: a recurring subscription, a managed service with a setup fee and monthly charge, or a per-entity annual licence. Opex lands on the operating budget, which a CIO usually controls up to a delegated authority limit, so it avoids the slower annual capital cycle. It becomes a capital purchase when the hospital buys an owned asset such as on-premise servers or a perpetual licence, which goes through the capex committee and a depreciation schedule. The deployment architecture decides the classification.
Who signs off on AI purchases in a hospital?
The chain typically runs from a clinical champion or Head of Digital who sponsors the tool, to the CIO or CTO who owns the technical and budget decision up to a delegated limit, to the CFO who owns the money and the payback objection, to a procurement committee that owns terms, and to the Medical Director whenever the tool touches a clinical workflow. The sponsor who arranges the demo is rarely the final signatory.
Why do hospital AI deals stall in procurement?
They stall in three places most often. First, the IT security review, when a vendor cannot document in writing where patient data goes, who accesses it, and what the audit trail is under DPDP 2023. Second, the CFO gate, when the business case cannot tie the recurring cost to a defensible payback. Third, clinical governance, when the vendor mishandles the liability question by claiming to absorb clinical accountability it cannot legally carry. Deals clear these gates when the vendor arrives with the security documentation, a defensible business case, and an honest decomposition of liability by failure class.