As AI agents become more integrated into day-to-day operations—from answering customer queries to summarising internal reports—companies face a fundamental challenge: how do we safely share sensitive data with AI models?

Whether you’re experimenting with OpenAI’s GPT models, Google Gemini, or building your own AI assistants, data privacy is a show-stopper. And for good reason.

The Problem: AI Is Powerful—But Data Privacy Is Non-Negotiable

Let’s say you want to send data to an AI agent to summarise a client email or generate insights from customer records. Chances are, that data includes personally identifiable information (PII)—names, phone numbers, addresses, even Medicare numbers in Australia’s case. You have a few options, none of them ideal:

• Manually censor the data before it goes to the model. It’s time-consuming and prone to human error.
  
• Use an enterprise AI solution (like ChatGPT or Gemini Enterprise) and trust their privacy guarantees.
  
• Deploy an existing model in a secure environment—run a pre-trained AI model on-prem, air-gapped, or behind firewalls.
  

Across the board, teams are forced to choose between AI capabilities and privacy confidence.

But what if there was a middle ground?

Smarter Solutions: Techniques for Anonymising Data Before It Hits the Model

We’ve been working on modular approaches to pre-process and anonymise data—without losing context or functionality—before it goes into an AI system. Here’s how it can work:

🔐 1. Tokenising SQL with Encryption

For structured queries, we use SQL tokenisers to encrypt queries before they go to the AI. This lets the model help optimise or correct the query without ever seeing sensitive table names or column values. After processing, the query can be decrypted and executed safely.

A look under the hood

Our approach works by first using specialised open sourced libraries like sqlparse to break the query down into its fundamental components, or “tokens.” We examine the type of each token. 

If a token is a core SQL command (like SELECT, FROM, WHERE), an operator (=, >), or punctuation, it’s left as is. However, if the token is a potentially sensitive identifier (a table name, column name, or alias) or a literal value (like ‘Payment Pending’ or 0), it’s swapped out for a generic placeholder (e.g., <IDENTIFIER_1>, <LITERAL_1>). 

This creates a structural template of the original query while storing all the original values in a separate “de-anonymisation map,” ensuring the AI can process the query’s logic without accessing any sensitive data.

A Fun Example (The Ice Cream Incident!)

Imagine you work at a hospital where a patient, Sherman Cone, has just been admitted after eating three entire tubs of “Triple Chocolate Fudge” ice cream. To review his case, you need to query the hospital’s patient database. Sending a raw SQL query containing his details to an AI for help with analysis would expose confidential patient data.

To prevent this, our solution automatically redacts the query. It replaces every sensitive detail (table names, column names, and specific values) with generic placeholders. This process generates two outputs: a safe, anonymized query to send to the AI, and a private “map” that allows us to restore the original details from the AI’s response.

Original Query (Before Redaction)

This is a sensitive query containing Sherman’s protected health information that should not be shared with an external service.