Why Most AI Vendors Don't Publish a Do-Not-Automate List
A hospital's AI vendor said the tool was "fully compliant" and "healthcare-ready". That was the pitch, spoken-out loud in the sales meeting.
The actual contract said something else. Customer data could be used to improve the vendor's own model. Outputs were provided "as-is", with no warranty of accuracy or bias mitigation. Vendor liability was capped at one month of fees. None of that was hidden exactly, it just wasn't what got said in the room.
I'm Boudhhayan Duttaa, founder of Batti Jalao, an AI-led healthcare marketing growth consultancy based in Guwahati. We built BattiOps, a fixed-price Agentic AI readiness audit, specifically because that gap between what a vendor says out -oud and what a vendor will actually put in writing is where most hospital AI deployments quietly go wrong. This piece is about the document that almost no AI vendor publishes and what its absence should tell a hospital evaluating one.
Why 95% of AI Pilots Fail To Move A P&L
Roughly 95% of enterprise Agentic AI pilots deliver no measurable P&L impact, per MIT NANDA's 2025 research. Gartner projects more than 40% of Agentic AI projects would be cancelled by the end of 2027. Deloitte's own read of the MIT findings is specific about where the failure actually sits. The barrier is workflow and organisational policy, not the underlying model. Pilots don't fail because the AI is bad, rather because nobody diagnosed which processes it could safely run before turning it loose on all of them.
A real, published academic framework backs this up from the buyer's side. 'The Health AI Partnership's Vendor Disclosure Framework' published in NEJM AI, exists specifically because hospitals face significant challenges in evaluating vendor-developed AI systems owing to limited guidance on what information to request from vendors during procurement and because, in absence of that guidance, vendors routinely provide inconsistent or incomplete answers. That's not a hospital failing to ask the right question, it's a structural gap in an entire market.
Suitability × Risk And The Four Buckets
BattiOps scores every process a hospital is considering for automation against two axes, how suitable it is for an AI agent to run and what happens if the guardrails fail. Multiply the two and every process sorts into one of four buckets.
Deploy Now: Suitable and low-risk, the agent runs it, human-checked for 30 days.
Pilot: Suitable but sensitive, the agent drafts and staff approve until it's graduated on a clean run.
Redesign First: Not structured enough yet to automate safely at all.
Do-Not-Automate: Clinical or high-harm, staying human by design, permanently, not as a temporary placeholder.
That fourth bucket is the one worth sitting with.
The Register Itself And Why Most Vendors Never Publish One
Releasing a lab result to a patient, approving a prescription refill, etc. These are clinical acts and BattiOps names them explicitly, by name, in a 'Do-Not-Automate' register handed to the hospital in writing. Most AI vendors never produce anything like it, not because the limitation doesn't exist, but because publishing one runs directly against the sales incentive that built the industry. A vendor's entire pitch is built on what the tool can do. A written list of what it deliberately won't touch reads, to a sales team, like a weakness being volunteered.
That's precisely backwards from how a hospital should read it. Procurement specialists reviewing third-party AI risk are blunt about this now. A SOC 2 report, a HIPAA statement and a signed BAA do not answer the actual AI questions a hospital needs answered such as 'Does the vendor train on our data' or 'Can the tool produce wrong outputs that affect care or billing' or 'Who else touches the data behind the scenes', etc. A compliance checklist is not a disclosure of limitations, rather it's a mark of honest intent.
What This Looks Like When It Goes Wrong
Let's circle back to the opening example. A healthcare staffing firm brought in an AI-powered screening tool to analyse candidate resumes and generate job-match summaries for hospital clients. The vendor's implementation team called it "fully compliant" and "healthcare-ready", the same phrase, almost word for word, that shows up in pitch after pitch across this industry. However, customer data could be used to improve the vendor's own model, outputs were provided "as-is" with no warranty of accuracy or bias mitigation and vendor liability was capped at a single month of fees. These terms simply sat in a document nobody in the sales conversation walked the buyer through line by line.
This is not a story about a bad vendor, it's the default shape of the market. A vendor optimising for a signed contract has every incentive to describe capability out-loud and let the limitations sit quietly in the fine print, because that's what closes deals. A hospital's job in procurement isn't to assume bad faith, it's to stop treating the pitch and the contract as if they say the same thing, because they routinely don't.
What This Means For How A Hospital Should Evaluate Any AI Vendor
Ask for the exclusion list before the capability list. Any vendor can describe what their tool does. Ask what it's been deliberately kept away from and watch how the conversation changes.
Read the contract, not the pitch deck. The gap between "healthcare-ready" said out-loud and "outputs provided as-is, no warranty" written down is exactly where liability actually lives.
Treat silence as an answer. A vendor that has never considered what it shouldn't automate hasn't done the diagnostic work, it's simply hoping nothing goes wrong in production.
Separate suitability from risk explicitly. A process can be technically easy for an agent to run and still belong in the 'Do-Not-Automate' bucket, because the two questions are genuinely different and most vendors only ever answer the first one.
Ask who signs-off on overrides. A written escalation pathway for when the AI gets something wrong is a different document from a general compliance statement and most procurement conversations never get to it.
Is This Only Relevant Io Hospitals Actively Evaluating Vendors Right Now?
If anything, it matters most before a pilot starts, not after one stalls. Once a tool is already live inside a workflow, the review that should have happened at procurement becomes a much harder conversation to have and the sunk cost of the deployment starts arguing against the honest answer.
The register a vendor won't show you is not a missing feature, rather it's the one document that would actually tell you whether they've done the diagnostic work before asking to be let near your patient's data. Worth asking to see it before the next pilot starts, not after it quietly fails.
💡think HATKE!
