Case study
A Near Miss, Traced Through the Gate
Based on an internal healthcare governance proof of concept, not a live customer deployment or an independently audited system.
The Setup
A hospital operations assistant is helping coordinate a blood delivery. A nurse asks it to dispatch a unit of O-negative blood to Mercy General. The assistant checks inventory, confirms the unit, and the action goes through, permitted, logged, done.
The workflow continues. The same shipment needs a handoff report sent to a third-party logistics API, so the courier's system knows what is coming. The assistant, trying to be thorough, includes the patient's medical record number in that handoff, reasoning it might help the courier's records match up correctly.
It does not ask permission. It just proposes the action, the way agents do, one more step in an otherwise routine chain.
Where the AI's Role Actually Matters
This is worth pausing on, because it is easy to read a blocked action as the AI doing something wrong. It did not. The assistant was reasoning helpfully, inside a plausible interpretation of its task. Non-deterministic reasoning engines do this constantly, they fill in gaps with judgment calls a human would have caught, or would not have thought to make at all.
The AI's real value shows up right after the block, not before it. RALAIC does not just reject the action and go silent, it returns a structured reason, which constraint was not satisfied, without disclosing the sensitive content that triggered it. The assistant takes that signal and adapts, asking a clarifying question, proposing a corrected version of the same task, the same way it already does when a unit ID does not match inventory. The person on the other end experiences a normal, slightly chatty back and forth, not a system failure. That smoothness is the AI doing its job well, inside a boundary it did not get to set for itself.
What Gets Blocked, and Why
Before the handoff reaches the logistics API, RALAIC evaluates it, specifically the patient MRN, headed toward an external endpoint never approved to receive protected health information. Three checks run in that one evaluation: governance, is this endpoint approved, no. Cost, negligible either way. Confidentiality, does this payload carry PHI to an unapproved destination, yes. The action is withheld. The record is written before the routing decision is even finalized, so an entry exists whether the action goes through or not.
What RAL Actually Created
This is the artifact, the thing that exists afterward that did not exist before:
Nobody reads this in the moment. It sits in the ledger, complete, timestamped, tied to the exact proposed action, available the instant anyone needs it, an auditor, a regulator, the privacy officer, six months from now.
The Cost That Was Prevented
Because the block happens before transmission, not after, the entire downstream cost of that action is avoided, not just the API call to the logistics vendor, but every token the assistant would have spent processing a response, handling an error from the courier's system, or retrying the request. The evaluation itself is fast and fixed cost regardless of what it is checking. The action it stopped would have cost far more to run than to block. That is what the 98 percent figure in the record represents, not a discount, the difference between paying for a mistake and not making one.
The Compliance Battle That Did Not Happen
Without this checkpoint, here is the realistic version of what follows. PHI reaches a third-party system that was never vetted as a business associate. Maybe it is noticed during a routine review weeks later. Maybe it is not noticed until the vendor has a breach of their own and the patient's MRN turns up somewhere it should not be. Either way, the organization is now proving what happened after the fact, reconstructing intent from logs, explaining to a regulator why the safeguard was not in place, absorbing legal exposure that scales with how long the gap went unnoticed.
With the checkpoint, none of that occurs, and there is a record proving why, the moment anyone asks. The difference is not just the incident. It is the entire conversation that would have followed it.
Who Sees What
The doctor sees nothing unusual. Clinical work keeps moving.
The lab and blood bank see the assistant ask for a resubmission through an approved channel, the same tone as any other clarifying question.
The IT officer sees the ledger entry above, enough to confirm the block and its cause, never the MRN itself.
The privacy officer sees the specific evidence a HIPAA audit control actually requires, a timestamped, bound record that a proposed disclosure was evaluated and stopped before data left the environment.
Compliance and admin see this rolled up in aggregate, block rate, recurring violation categories, resource metrics across every evaluation, an actual answer when someone asks how do we know this is working.
The Same Architecture, a Different Room
Take the identical pattern and put it in a customer support context instead of a hospital. A support agent, working a refund request, reasons its way toward including a customer's full account history in an email to a third-party fraud-review vendor, again, trying to be thorough, again, not malicious. The same evaluation runs. The same kind of block occurs if that vendor is not on the approved list. The same kind of ledger entry gets written.
The customer experiences none of this. Their refund still gets handled. The agent still resolves the ticket. What is different is invisible to them and permanent for the business, a record now exists proving the sensitive data never left the approved boundary, the exact thing a security review or a customer trust audit would otherwise have no way to verify after the fact.
What This Does Not Yet Cover
In the interest of the same honest framing used throughout RALAIC's other materials, two limitations are worth naming directly, since a technical evaluator will ask about both.
Manual override. If a person with legitimate access manually copies a patient identifier into their own email client, entirely outside any AI agent's proposed action, that activity is outside RALAIC's scope. RALAIC governs what an agent proposes to do, not everything a human does with their own access. This is why RALAIC is positioned to partner alongside existing data loss prevention tooling and human-behavior monitoring, not replace them.
Image and unstructured content. Whether the confidentiality check reliably catches sensitive content smuggled into non-text channels, an image, a screenshot, an encoded attachment, depends on the underlying classification method, and this is an open question under active review rather than a settled capability. One protection does hold up even here: governance constraints that check the destination endpoint are payload-agnostic, so an unapproved endpoint gets blocked regardless of whether the content inside can be fully classified. That is a partial answer, not a complete one.
A case study that only shows what works is a marketing document. One that also names what is still being solved is evidence the architecture is being built by someone who understands where the hard problems actually are.