Going From Building AI to Running It

The pilot worked. Now the query volume belongs to your EHR, your claims platform, and your infrastructure budget. Here's what running AI in healthcare asks of the systems underneath it.

Most healthcare AI budgets fund building. A model bake-off, a prompt library, a pilot with 6 clinicians, a demo that lands with the CFO. Then the pilot succeeds, the workflow goes live, and the bill moves from the AI team to the infrastructure team. Nobody wrote that line item.

Silk and Microsoft ran a webinar on exactly this problem, titled AI Inferencing: Don't Break Your Architecture. Eduardo Kasner, Chief Data and AI Officer for Microsoft's high-tech sector, gave the cleanest definition I've heard. Training builds the brain. Inferencing is the brain at work, running semantic search, RAG, and agentic workflows against your live data. Kasner's argument is about databases. Ours is about what sits on top of them in healthcare, where the system of record has a 20-year uptime expectation and a compliance team attached.

Inference is the part that touches production

Every useful answer an agent gives starts with a lookup. Kasner calls this grounding, and it's the difference between a model that recites and a model that works. In healthcare, grounding means the member record, the claim history, the prior auth policy, the clinical note from last Tuesday.

So every step in an agentic workflow is a query somewhere. A prior auth agent that checks eligibility, pulls the guideline, reads the note, and drafts the determination has hit 4 systems before a human sees anything. Multiply that by every case in the queue and you've built a new class of database client that never sleeps and never batches.

The accuracy versus load trade

Kasner names a paradox worth pinning to the wall. To make the AI more accurate, you feed it more data, more context, and more complex queries. That load lands on production databases, the systems of record. Limit the data and the AI is fast but wrong. Give it everything and the system slows to a crawl or falls over.

Healthcare feels this harder than banking or e-commerce, because the accuracy bar is higher and the systems are older. Our own χ-BENCH testing found frontier agents complete only 28% of complex healthcare workflows. The reflex fix is more context. More context is the exact thing that loads the EHR. You can't prompt your way out of an architecture problem.

Three ways teams get the data wrong

Kasner sees organizations fall into the same traps when they try to feed data to AI. The first is the lakehouse pipe dream, where everything gets consolidated into one store that's elegant on the whiteboard and too slow and expensive in practice. The second is vector database sprawl, which adds layers of latency and an operational tax nobody budgeted.

The third is the default most teams land on, which is hitting production directly.

"The worst choice is blindly hitting production." Eduardo Kasner, Chief Data and AI Officer, High-Tech, Microsoft

Here's why that default is so dangerous. When a pilot fails, the load goes away. When a pilot succeeds, query volume doesn't grow, it multiplies. A workflow that ran 50 cases a week in the pilot runs the whole queue in production, and the EHR team finds out from a latency alert. In healthcare there's a second cost stacked on top. As we argued in The Data Tollbooth, you often pay the application vendor for access to your own data and then pay the inference vendor to reason over it. Blind production hits make both meters spin.

Six priorities, translated for healthcare

Kasner's list of what leadership has to get right is the right list. The healthcare column is ours.

Isolation is the answer, at 2 layers

Kasner's prescription is isolation. AI development is iterative, which is a polite way of saying you'll break things, so give teams high-performance, isolated copies of production data to experiment against. Elastic scaling or instant environment duplication keeps the experiments off the systems the business runs on.

We'd push that one layer up. In healthcare, isolating the data isn't enough, because the thing that grows out of control is the workflow. The system of record should feed the agent and never own the job. We made that case in You Still Need Your System of Record, and running AI is where it bites.

In practice that looks like three habits. Run every agent inside a harness that reads from the system of record through governed connectors, so a runaway workflow throttles at the harness and never at the EHR. Simulate the workflow end to end before it sees production traffic, so you learn the 28% problem in a sandbox instead of a claims queue. Meter cost and latency per workflow from day one, so the CFO sees the inference bill before it becomes a surprise.

Building AI is a project. Running it is an operating discipline, and the architecture underneath decides whether the discipline is possible.