One System, Then a Practice

They had pilots and no path to production. We built one system inside their controls. Their engineers built the second.

Where they were

A Fortune 500 healthcare company, about 400 engineers, and more AI pilots than anyone had counted: document extraction in notebooks, a chatbot over internal policy, two vendor proofs of concept in procurement. None had a path to production. Each hit the same wall: PHI, identity, audit, and no owner after the demo.

What was in the way

Not the models. Three things:

• No boundary for AI. Nobody had written down where PHI could go in a model call, what a model could see, or what got logged. Every proposal became a quarter-long security review.
• No way to know it still worked. Prompt changes shipped on feel. Production ran a model two generations old because nobody could test an upgrade.
• No owner. AI sat between platform, data, and a working group. Working groups don't carry pagers.

What we built

We went in through their identity provider, their cloud, and their CI. No side environment. Their data platform already ran a de-identification pipeline, built for analytics and already through their audit. Nobody in the AI conversation knew about it. It became the boundary.

Intake was four stages with a boundary between each. Documents arrived by fax and portal; ingestion normalized and extracted them inside the PHI boundary. De-identification ran on the extracted content. A classification model saw only that content, keyed to an opaque document ID. A routing service took the result and moved the original document to its queue. The model never held a patient's identity and never needed to.

Running extraction and classification entirely inside their data center was the other option on the table, and the architecture was built so it could move there without a redesign. For routing, de-identified content was enough, so the hosted path shipped first and the local path stayed available.

The first target was inbound document intake: about 38,000 documents a week by fax and portal, classified by hand at about four minutes each and routed to one of 31 queues. It touched production data, ran under production controls, and had users who would notice if it was wrong. In production, 78% of documents route automatically, the misroute rate is 1% against 5% for the manual process, and time to the right queue is 3.5 hours, down from two days.

Their engineers wrote the intake service and the routing logic. We wrote the PHI boundary and the eval harness, then reviewed every change that touched them.

What their team built next

The second system, a clinical summary for prior authorization reviewers, was scoped and built by their team on the same architecture, with us mostly out of the room. It preps the case; the reviewer makes the call. What they have now:

• Standards in the repo: reference architecture and PHI boundary, as templates.
• Eval gates in CI on every model, prompt, or tool change.
• A named owner, and one intake path for the next proposal.