The Problem with Catching Violations After the Fact
A common pattern in early AI governance programs goes like this. The security team stands up a logging pipeline that captures every prompt and every response from the organization's AI systems. A SIEM rule scans those logs for patterns that look like sensitive data — SSNs, account numbers, PHI fragments, source code. When a match is found, an alert fires, and an incident response process kicks off.
This sounds reasonable on paper. In practice, it is closing the barn door long after the horse has left.
By the time the SIEM rule fires, the prompt has already been sent to the model. If the model is a third-party API, the sensitive data has already crossed the trust boundary. If it is a hosted model with retention enabled, the data has already been written to the vendor's logs. If the response was streamed back to the user, the user has already seen it. Detection without prevention is not governance — it is forensic accounting.
This post is about the alternative: enforcing policy at the source, before the prompt ever reaches the model, and before the response ever reaches the user.
What "At the Source" Actually Means
There are two natural enforcement points in any AI system.
PRE_LLM (request path). The user's prompt has been assembled — context, system instructions, retrieved documents, user input. It is about to be sent to the model. This is the last moment at which sensitive data can be detected and stopped before it leaves your perimeter.
POST_LLM (response path). The model has generated a response. It is about to be returned to the user, written to a database, or passed to a downstream system. This is the last moment at which a hallucinated identifier, a policy-violating recommendation, or a leaked piece of training data can be stopped before it is acted on.
Inline enforcement at both points is the architectural difference between "we hope this never happens" and "we structurally cannot let this happen."
Why Healthcare Teams Were the Early Adopters
Healthcare organizations were among the first to push for source-side enforcement, for an obvious reason: HIPAA does not have a "we caught it after the fact" exception. A protected health information (PHI) disclosure to a third-party AI vendor is a reportable breach whether it was deliberate, accidental, or the result of an employee pasting a discharge summary into ChatGPT to "help draft the patient letter."
The healthcare teams we work with have converged on a consistent enforcement pattern.
Layer 1 — Block PHI from Leaving the Perimeter
The PRE_LLM layer scans every outbound prompt for PHI before it can be sent to any AI model. This is not a regex pass over a SSN format. It is a multi-stage pipeline:
- Direct identifier detection for names, dates of birth, MRNs, account numbers, and other high-confidence PHI.
- Quasi-identifier detection for combinations that constitute PHI under the HIPAA Safe Harbor method — for example, ZIP code plus date plus rare diagnosis.
- Free-text PHI inference for narrative content that contains identifying detail without an obvious format trigger.
When PHI is detected, the configurable response is one of: block the request entirely, redact the PHI in place and pass the rest, or route the request to an internal model that is in scope for HIPAA.
Layer 2 — Catch What the Model Generates
The POST_LLM layer scans every response before it reaches the user. This catches a category of incidents that PRE_LLM enforcement structurally cannot: PHI that the model itself generates from its training data or hallucinates with valid format.
We have documented cases at multiple healthcare customers where benign user prompts produced responses containing realistic-looking MRNs in the format used by the customer's EHR. Without POST_LLM enforcement, those MRNs would have been delivered to users, with all the downstream confusion that creates.
Layer 3 — Govern the Browser
Approximately 40 percent of the unsanctioned AI usage at the healthcare organizations we work with happens through web browsers — clinicians and administrators pasting clinical content into consumer AI tools. PRE_LLM enforcement on the API perimeter does not catch this. Browser-side policy enforcement does, by inspecting outbound prompts at the point they are typed or pasted into chat.umaisolutions.com-like surfaces and applying the same policy logic.
Together, these three layers convert "we have an acceptable use policy" into "we structurally prevent the violations that policy describes."
The Same Pattern Outside Healthcare
The healthcare playbook generalizes. The data types change; the architecture does not.
Financial services. Account numbers, customer PII, position data, material non-public information. PRE_LLM blocks them from leaving the perimeter. POST_LLM blocks the model from generating investment advice that exceeds the licensed scope of the assistant. Browser governance prevents traders and analysts from pasting research drafts containing MNPI into consumer AI tools.
Legal. Privileged communications, work product, client matter detail. The risk of waiver from inadvertent disclosure is severe. PRE_LLM enforcement scans for matter identifiers, opposing party names, and privilege markers. POST_LLM enforcement prevents responses that summarize privileged content for users not on the matter team.
Government and defense. Classified or controlled unclassified information markings, personnel data, source-sensitive intelligence. Source-side enforcement is often the only architecturally acceptable answer because after-the-fact detection assumes the data already crossed a boundary it should not have crossed.
The common thread: when the cost of a single leak is high, detection-after-the-fact is not a control. Source-side enforcement is.
Three Common Objections, Answered
"Won't this break our AI features?"
Source-side enforcement, done well, is invisible to legitimate use. UMAI's median PRE_LLM evaluation runs in 1.8 milliseconds. Users do not perceive the latency. The block rate on legitimate requests at our healthcare customers runs under 0.5 percent — and the blocks that do happen typically reflect actual policy violations the user did not realize they were committing.
The features that actually break under source-side enforcement are usually the ones that should not have been built that way in the first place — for example, sending raw clinical narrative to an external API as part of a "summarization" feature without de-identification. Source-side enforcement surfaces those design problems early, when they are cheap to fix.
"Can't a sufficiently determined user work around it?"
Probably, yes — for some classes of policy. The threat model for source-side enforcement is not "stop a determined adversary from exfiltrating data." It is "stop the overwhelming majority of accidental and casual policy violations that constitute the actual risk surface in regulated enterprises." That category is the bulk of the incident volume, and it is exactly what source-side enforcement addresses.
For determined-adversary scenarios, source-side enforcement is one layer in a defense-in-depth posture that also includes endpoint controls, network egress monitoring, and identity-level access restrictions.
"Why not just train the model not to do this?"
Because you do not control the model in most enterprise deployments, and because even when you do, fine-tuning is not a substitute for an enforcement layer with a verifiable audit trail. The auditor's question is not "did you train the model carefully?" It is "show me, for this specific request, that the policy was applied and the verdict was recorded." That answer requires an enforcement layer, regardless of what the model itself was trained to do.
Where to Start
If your organization processes regulated data and is rolling out AI features, the practical sequence is:
- Identify the highest-risk AI surface. For healthcare, this is usually the surface with the most direct path between clinical data and an external model. For financial services, it is usually the surface closest to customer accounts or trading systems.
- Deploy PRE_LLM enforcement on that surface. Start with the data classes whose disclosure has the highest regulatory cost.
- Add POST_LLM enforcement once PRE_LLM is stable. This catches the model-generated-content category that PRE_LLM cannot address.
- Extend coverage to browser-mediated AI usage. This is almost always the surface that contributes the most incident volume relative to the controls applied.
If you want to talk through how this would map to your environment, reach out at contact@umaisolutions.com. We work with healthcare, financial services, insurance, and government teams every week, and we are happy to share what has worked.