← Back to Blog

The PII Dilemma in Generative AI

One of the most significant barriers to enterprise AI adoption is the risk of data leakage. Employees frequently use Large Language Models (LLMs) to summarise customer emails, analyse financial reports, or debug code. In doing so, they inadvertently expose Personally Identifiable Information (PII) to external model providers [1].

Relying on employees to manually scrub data before pasting it into a prompt is a failed strategy. Human error is inevitable. Furthermore, relying on the model provider's promise not to use your data for training is insufficient for highly regulated industries like finance, healthcare, and government [2].

What is Inline PII Redaction?

Inline PII redaction is a security mechanism that intercepts the prompt before it is sent to the LLM. It scans the text for sensitive information, replaces it with synthetic tokens (or masks it), forwards the safe prompt to the model, and then seamlessly re-injects the original data into the response before presenting it to the user.

This process ensures that the external model provider never sees the actual PII, while the user experiences no degradation in the quality or context of the AI's response.

How the Enforce Mode Handles Redaction

Enforce Mode can operate as a reverse proxy for connected AI traffic. When a request is routed through the Gateway, it can execute a configured redaction pipeline before the request proceeds:

  1. Interception: The prompt is intercepted at the Gateway layer, within the organisation's sovereign boundary.
  2. Detection: The Gateway uses a combination of regular expressions, pattern matching, and lightweight Named Entity Recognition (NER) models to identify PII. This includes names, email addresses, phone numbers, credit card numbers, Medicare numbers, and custom organisational patterns.
  3. Masking: Identified PII is replaced with contextual tokens. For example, "John Smith's phone number is 0412 345 678" becomes "[PERSON_1]'s phone number is [PHONE_1]".
  4. Model Processing: The masked prompt is sent to the LLM. The LLM processes the request and generates a response using the tokens (e.g., "I have updated the record for [PERSON_1] with the new number [PHONE_1].").
  5. Re-injection: The Gateway receives the response, maps the tokens back to the original data, and re-injects the PII before delivering the final text to the user.

The Compliance Advantage

Configured inline PII redaction can reduce the exposure of identified personal information before a request reaches an approved model. Organisations remain responsible for validating detection coverage, data flows, residency requirements and privacy obligations for each use case [3].

"Inline redaction is the bridge between the utility of public LLMs and the strict compliance requirements of the enterprise. It allows you to use the best models in the world without compromising your most sensitive data."

Conclusion

As AI becomes integrated into daily workflows, securing the data path is essential. Inline PII detection and redaction on configured enforcement paths provides one layer of defence within a broader customer privacy, access and assurance model.

References

[1] CyberCX, "Data Leakage via Public LLMs," CyberCX Insights, 2026.
[2] Office of the Australian Information Commissioner (OAIC), "Privacy and Generative AI," OAIC, 2026.
[3] Cetus AI, "Sovereign AI: A Reference Architecture for Australian Government," Cetus AI Labs, Q4 2025.