A 2026 Dataiku survey found that 85 percent of CIOs had seen AI projects delayed or blocked due to privacy concerns. Your compliance team's response? Deploy a privacy proxy and call it solved.
Not quite.
Privacy proxies like Dataiku's newly released Kiji Privacy Proxy address a real problem: PII leaking to external AI services through prompts. But the conversation around these tools has spawned several myths that obscure what they actually do and where your compliance gaps remain. Let's separate the marketing from the reality.
Myth 1: A Privacy Proxy Makes Your AI Workflow GDPR-Compliant
Reality: GDPR compliance requires documented lawful basis, purpose limitation, data minimization, and user rights management. A privacy proxy handles one piece: preventing unmasked PII from reaching third-party processors.
You still need:
- Valid legal basis for processing (Article 6)
- Data Processing Agreements with AI vendors (Article 28)
- Records of processing activities (Article 30)
- Data subject access request procedures (Articles 15-22)
The proxy doesn't document why you're processing data, what retention policies apply, or how users exercise their rights. It masks data in transit. That's valuable, but it's not a compliance program.
For SOC 2 Type II audits, you'll still need to demonstrate controls around data classification, access management, and vendor risk assessment. The proxy becomes evidence for one control, not a substitute for your entire trust service criteria.
Myth 2: Local PII Detection Means Zero False Negatives
Reality: Kiji Privacy Proxy uses a quantized DistilBERT model executed through ONNX Runtime for PII detection. It's fast and runs locally, which addresses latency concerns. But machine learning models have error rates.
Consider what happens when:
- A user enters a phone number without standard formatting (555 123 4567 vs. 555-123-4567)
- Context matters ("John Smith" the person vs. "John Smith" the building name)
- Your industry uses domain-specific identifiers (patient MRNs, policy numbers) that weren't in the training data
You need a testing protocol:
- Create a test corpus with your actual data patterns
- Measure precision (false positives) and recall (false negatives)
- Document acceptable thresholds for your risk tolerance
- Implement audit logging for what gets masked and what passes through
For PCI DSS v4.0.1 environments, Requirement 3.4.2 specifically addresses masking of cardholder data in logs and displays. A proxy that misses credit card numbers in non-standard formats creates audit findings, not compliance.
Myth 3: Open-Source Means Free to Operate
Reality: Kiji Privacy Proxy being open-source means you can inspect the code and customize the detection rules. It doesn't mean zero operational cost or zero risk.
You're taking on:
- Infrastructure hosting and scaling
- Model retraining as data patterns evolve
- Dependency management for ONNX Runtime and related libraries
- Security patching for the proxy itself
- Performance tuning when latency impacts user experience
For ISO 27001, Annex A.8.31 requires separation of development, test, and production environments. Your privacy proxy needs the same rigor as any production service: change management, monitoring, incident response procedures.
Budget for engineering time. If your team is already stretched managing your identity provider, API gateway, and secrets management, adding a privacy proxy to the stack means something else gets less attention.
Myth 4: Masking PII Eliminates All AI Privacy Risks
Reality: Privacy proxies address direct PII leakage. They don't address:
Model training on your prompts: Many AI service agreements include clauses about using customer inputs to improve models. Even masked prompts reveal your business logic, security posture, and operational patterns.
Inference attacks: If you consistently mask employee IDs but leave project names intact, an attacker with access to the AI service's logs can correlate patterns and de-anonymize individuals.
Downstream data retention: The proxy masks data before transmission, but what happens to those masked prompts at the AI vendor? Check your Data Processing Agreement for retention periods and deletion procedures.
For NIST Cybersecurity Framework v2.0, the Govern function (GV.RR-02) requires understanding and documenting cybersecurity supply chain risks. Your AI vendor's data practices are part of that supply chain, regardless of whether you mask PII.
Myth 5: Deploy Once, Forget Forever
Reality: PII patterns change. Your organization acquires a European subsidiary and now processes IBAN numbers. You launch a new product with biometric authentication. A regulatory change redefines what counts as sensitive data in your jurisdiction.
Your privacy proxy needs:
- Regular reviews of detection rules against current data inventory
- Testing against new data types before they reach production
- Version control for model updates with rollback procedures
- Metrics on masking rates and latency impact
For NIST 800-53 Rev 5, control SI-4 (Information System Monitoring) applies to privacy controls just as it does to security controls. You need visibility into what the proxy is doing, not just faith that it's working.
What to Do Instead
Don't skip the privacy proxy if you're sending prompts to external AI services. But don't treat it as a silver bullet either.
Start with data classification. You can't mask what you haven't identified. Map where PII lives, how it flows, and which systems need protection. This informs proxy placement and detection rules.
Layer your controls. Combine the privacy proxy with prompt engineering guidelines (don't paste production data into ChatGPT), access controls (who can use which AI services), and monitoring (alert on unusual volumes of masked data).
Test with adversarial inputs. Red team your proxy with intentionally obfuscated PII, edge cases, and data patterns specific to your business. Document what gets through and decide if you accept that risk.
Integrate with your vendor management process. The proxy doesn't replace due diligence on AI service providers. You still need to evaluate their security posture, data handling practices, and compliance certifications.
Privacy proxies solve a specific problem: reducing PII exposure in AI prompts. They don't solve AI governance, compliance program design, or vendor risk management. Use them as part of a defense-in-depth strategy, not as a replacement for one.



