Early access pilots reveal patterns. After working with a set of teams using ZeroDrift across regulated industries, five categories of policy violation showed up with enough frequency that they clearly represent structural problems rather than one-off surprises. This post examines each one, with enough technical detail to understand why it occurs and what an enforcement rule for it actually checks.
One clarification before diving in: these are violation categories, not exhaustive policy frameworks. The specific rules that constitute a violation depend entirely on the organization's active policies. What appears as a violation for a healthcare AI assistant may be completely appropriate for a general-purpose enterprise search assistant. The categories below are common across regulated industries; the specific rule thresholds are yours to define.
1. Unsolicited PII Disclosure
LLMs that have access to user profile data, session history, or any form of CRM-adjacent context will occasionally surface that data in responses where the user did not ask for it and where including it serves no useful purpose. A customer service assistant with access to account information might, when asked about a return policy, include the user's account number in its response. The response is accurate and the data was available, but the disclosure was not requested and creates an unnecessary exposure surface.
This category is particularly problematic because the model is not doing anything wrong from a raw capability perspective. It has relevant context and is including it. The policy constraint is that certain categories of PII should not appear in output unless explicitly requested or strictly necessary to answer the query. Enforcing this at the inference layer requires a rule that identifies PII patterns in the output and checks whether the corresponding input query contains an explicit request for that data category. If not, the PII should be stripped or the response rewritten to omit it.
Detection is reasonably straightforward for structured PII (phone numbers, SSNs, account numbers, email addresses in standard formats). It is harder for unstructured PII like full names in context or location information that appears in plain prose. The enforcement rule needs to cover both, with higher confidence thresholds for the harder categories to manage false positive rates.
2. Off-Topic Legal Advice
Enterprise AI assistants deployed in domains adjacent to legal questions (HR benefits, contracts, regulatory compliance workflows) will regularly receive queries that are asking, in effect, for legal counsel. A benefits assistant asked "can my employer change my healthcare plan mid-year" is being asked a question with a real legal answer that varies by jurisdiction and employment contract. An assistant with good general knowledge will often provide what sounds like a definitive answer.
The violation here is not that the answer is wrong. It is that the assistant is providing legal characterizations without the disclaimers and qualifications required under the applicable policy, and potentially creating a record that an employer's AI system told an employee something about their legal rights that the employer cannot stand behind.
Detection requires a semantic classifier that can identify responses providing legal characterizations or conclusions. The challenge is that the relevant language is often hedged ("generally speaking," "under most circumstances") in ways that make pattern matching insufficient. A classifier trained on examples of appropriate vs. inappropriate legal guidance scoping tends to work well here. The action is usually a rewrite that adds required qualifications and redirects to appropriate professional resources rather than an outright block, because the underlying information is often valid and useful when properly scoped.
3. Financial Guidance Without Disclaimers
AI assistants deployed in financial contexts (wealth management portals, employee benefits platforms, expense management tools) encounter queries that elicit financial characterizations. "Is a traditional IRA better for me" delivered to an HR benefits assistant is, legally speaking, a request for personalized financial advice. An assistant that answers it without the required investment advice disclaimers, or that provides specific numerical recommendations tied to the user's stated situation, may be generating output that creates regulatory exposure under relevant financial services rules.
This category is notably harder to enforce than PII disclosure because it requires judgment about intent and specificity. A response explaining generally how traditional vs. Roth IRA taxation works is educational content and is usually fine. A response that says "given your income and the fact that you're in a higher tax bracket, the traditional IRA will save you roughly X dollars per year" is something different. The line is between educational and prescriptive, and it is not always crisp.
Practical enforcement rules look for three signals in combination: the presence of the user's financial situation in the model's context (income, account balances, tax status), the presence of specific recommendations or comparisons framed as conclusions rather than general information, and the absence of required disclaimer language. All three together constitute a higher-confidence violation signal than any one alone.
4. Disallowed Competitor Mentions
Many enterprise deployment policies include explicit prohibitions on the AI assistant mentioning specific competitor products or companies by name. The concern varies by context: it may be legal (comparative advertising regulations, trade secret implications), commercial (not surfacing alternatives to users in a product support context), or simply an internal brand policy.
Detection for this category is, comparatively, the most straightforward of the five. It is fundamentally a named entity recognition problem with a defined disallowed list. The enforcement engine checks whether any output text contains entities from the configured competitor list and flags or blocks the response if so.
The interesting edge case is implicit mentions. "Other providers in this space charge a significantly higher management fee" does not name a competitor but is providing a comparative claim about the competitive landscape that may still violate the policy intent. Handling implicit comparative framing requires semantic classification rather than entity matching, and many teams start with the named entity rule and add the implicit variant after seeing it in the violation log.
5. Ambiguous Consent Language
When an AI assistant makes statements about what data it can see, what it stores, or what it can do with user information, those statements may or may not accurately reflect the system's actual data handling. In many deployments, the assistant does not have reliable access to the current state of user consent settings or data processing configurations. Statements the assistant makes about data handling ("I don't store your queries," "your data is not shared with third parties") may be accurate at the time the system was designed but may not reflect current operational reality or may not apply in all jurisdictions.
This is the most operationally subtle of the five categories because the violation is not that the statement is false, but that the assistant is making authoritative-sounding statements about data handling it cannot actually verify. Under CCPA and comparable regulations, communicating inaccurate data handling information to users can constitute a violation regardless of intent.
Enforcement for this category typically works as a block-and-redirect: any response that makes affirmative statements about the system's data handling, retention, or sharing practices is blocked or rewritten to redirect to the privacy policy and data handling documentation, where the authoritative and current information lives. This is a conservative approach that trades some conversational utility for clean compliance posture. Teams that want more nuanced handling can configure specific approved language for common data handling queries and have the enforcement rule check that responses in this category use only approved phrasing.
The Common Thread
What these five categories share is that they are all cases where the AI assistant's default behavior, producing a helpful and informative response, intersects with a policy requirement that the assistant has no native awareness of. The model does not know it should not volunteer account numbers. It does not know that jurisdictional legal advice requires qualifications. It does not know which competitors are on the disallowed list or what the current consent disclosure policy says.
These are not failures of model quality. They are failures of the deployment context to enforce constraints that exist outside the model's training data. That is the problem runtime enforcement exists to solve, and these five categories are where it earns its keep in production.