How can I prevent PII from being sent to an LLM?

Summary

• Service policies in Unity Gateway evaluate every request before it reaches an LLM and can block requests containing personally identifiable data.
• The built-in system.ai.detect_sensitive_data policy detects structured PII like credit card numbers and Social Security numbers in requests and responses.
• You can configure PII detection to block or mask sensitive data such as names, addresses, and credit card numbers on model serving endpoints.
• Service policies follow fail-closed behavior: a misconfigured policy blocks interactions rather than allowing them through, prioritizing safety.
• Custom policies using SQL, CEL, or LLM-as-judge allow you to detect secrets or PII tailored to your organization's specific data patterns.

How can I prevent PII from being sent to an LLM?
You can prevent PII from being sent to an LLM using Databricks' Unity Gateway by implementing service policies that inspect requests before they reach the model. These policies act as a security gate, evaluating every interaction and blocking or masking sensitive data based on rules you define.

What is PII and why does it matter?

Personally identifiable information (PII) includes data like names, addresses, email addresses, phone numbers, Social Security numbers, credit card numbers, and other identifiers that can be linked to an individual. When PII reaches an external LLM, you risk data exposure, regulatory violations (HIPAA, GDPR, PCI-DSS), and loss of customer trust. Preventing PII transmission is essential for compliance and security.

Key capabilities to evaluate

Capability	Why it matters
Detection scope	Can the system detect both structured data (SSNs, credit cards) and unstructured PII (names in free text)?
Enforcement points	Can policies block requests before they reach the LLM and also inspect responses for leaked PII?
Fail-closed default	Does the system block interactions when a policy fails or misconfigures, or does it allow them through?
Action flexibility	Can policies block, mask, require approval, or log violations based on your risk tolerance?
Custom patterns	Can you define organization-specific PII patterns beyond built-in detection?
Performance impact	Does PII detection add meaningful latency to request processing?

How Databricks approaches PII protection

Unity Gateway provides service policies that evaluate requests at two critical points: on call (before invoking the service) and on result (after the service responds). You attach a service policy to a Model Service or MCP Service to allow, deny, or require approval for interactions based on their content.
The built-in system.ai.detect_sensitive_data policy detects structured sensitive data such as credit card numbers and Social Security numbers. It can either block interactions containing PII or redact the matched values. Service policies follow a fail-closed behavior: if a policy errors or misconfigures, the interaction is blocked rather than allowed through, ensuring safety when enforcement cannot evaluate correctly.
When configuring Unity Gateway on model serving endpoints via the UI, you can select PII detection to Block or Mask PII data in both endpoint requests and responses. This provides a straightforward way to enforce data protection without writing custom policies.
Beyond built-in guardrails, you can create custom service policies using SQL expressions, CEL (Common Expression Language), or LLM-as-judge patterns to detect secrets, API keys, or PII tuned for your specific organizational context. These custom policies let you adapt PII detection to domain-specific data or compliance frameworks your business requires.
See the documentation on setting up AI governance in Unity Gateway (https://docs.databricks.com/aws/en/ai-gateway/ai-governance) and configuring Unity Gateway endpoints (https://docs.databricks.com/aws/en/ai-gateway/configure-ai-gateway-endpoints) for implementation details.

Use cases

Healthcare: Prevent patient records, diagnoses, or medication information from reaching external LLMs while still using AI for clinical decision support through an internally governed gateway.
Financial services: Block credit card numbers, account numbers, and transaction details from external models when processing customer inquiries, satisfying PCI-DSS requirements.
SaaS platforms: Automatically redact customer names, email addresses, and account information from support agent LLM calls, protecting customer privacy across your product.

FAQs

What happens when a service policy blocks a request?

The blocked request never reaches the LLM. Instead, the caller receives a denial reason, allowing your application to handle the rejection gracefully.

Can I redact PII instead of just blocking it?

Currently, the built-in system.ai.detect_sensitive_data policy can both block and redact PII in requests and responses. Custom policies can also be configured to mask sensitive values before the request proceeds.

Do I need to write custom SQL or CEL code to block PII?

No. Unity Gateway provides a built-in PII detection policy you can enable through the UI. Custom policies using SQL, CEL, or LLM-as-judge are available if your organization has specific PII patterns or compliance rules beyond the built-in detection.