The fastest way to leak sensitive data through an AI feature is not a sophisticated attack. It is a well-meaning developer piping a whole customer record, a full support transcript or a shared drive folder into a prompt because it was easier than deciding what the model actually needs. Once that data reaches a third-party model, it is copied into logs, traces and possibly vendor storage you do not control. If you want to protect data exposure in AI systems, the work starts before the model call, with data classification.
Why AI raises the stakes on data exposure
Traditional applications move data along paths you designed: this table, this API, this screen. AI features blur those paths. A retrieval system can pull any indexed document into context. An agent can call tools that return more fields than anyone expected. A chat transcript can contain a national ID number the user pasted in without being asked.
Then that context goes to a model provider, and copies of it land in several places: your application logs, your observability platform, the provider's abuse monitoring, and sometimes caches or evaluation datasets. Each copy is another place sensitive data can leak from, and another thing to account for when a regulator or a customer asks where their data went.
The fix is not to stop using AI. It is to know what each piece of data is, decide what is allowed to reach which model, and enforce that in code.
Classify data before it reaches a model
Most organizations already have some data classification policy, often a document nobody looks at. For AI work it needs to become something your pipeline can read. A simple four-tier scheme works for most teams:
| Class | Examples | AI handling rule (example) |
|---|---|---|
| Public | Marketing pages, published docs, product catalog | Any approved model |
| Internal | Internal wikis, process docs, non-sensitive tickets | Approved vendors with no training on data |
| Confidential | Customer PII, contracts, financials, HR records | Redact or tokenize first; approved in-region vendors only |
| Restricted | National IDs, health records, payment data, credentials | Never sent to external models; self-hosted only, or excluded |
The important part is tagging data at the source. Label database columns, document collections and file stores with their class, and carry that label through your retrieval index and tool outputs. Then the orchestration layer can make a decision on every request: what is the highest class in this context, and is this model allowed to see it?
A policy check might look like this in configuration:
models:
gpt-hosted-eu: { max_class: internal, region: eu }
claude-hosted-me: { max_class: confidential, region: me-central }
local-llm: { max_class: restricted, region: on-prem }
rules:
- if: context.max_class > model.max_class
then: block_and_log
- if: user.country == "SA" and context.has_personal_data
then: require_region in [me-central, on-prem]Model names and regions above are placeholders. The point is that the decision is made by policy in code, not by whoever wrote the prompt.
PII redaction and minimization
The best way to protect data is to not send it. Before you redact anything, ask whether the model needs the field at all. A model drafting a reply about a delayed order needs the order status and delivery date. It does not need the customer's phone number, address or payment method.
For data the task genuinely touches, use a few techniques together:
- Field selection. Tools and retrieval return only the fields a flow needs. This is the cheapest and most effective control.
- Detection and redaction. Run PII detection on free text (user messages, documents, transcripts) and replace matches with placeholders before the model call. Combine pattern rules for structured identifiers with an NER model for names and addresses.
- Reversible tokenization. Swap values for tokens such as
[CUSTOMER_1]or[PHONE_2], keep the mapping on your side, and restore values in the final output only if the user is allowed to see them. - Language coverage. Test redaction in every language you support. Detectors tuned on English often miss Arabic names, mixed scripts, and local formats for IDs and phone numbers.
Accept that redaction is probabilistic. It will miss things, which is why it sits alongside vendor controls and access rules rather than replacing them.
Data residency and regulation
Where data is processed matters as much as what is processed. For Gulf organizations this is often the deciding factor in vendor and architecture choices.
Saudi Arabia
Saudi Arabia's Personal Data Protection Law (PDPL) has been fully enforced since 14 September 2024. It covers how personal data is collected, processed and transferred outside the Kingdom, so any AI feature that sends Saudi residents' personal data to an overseas model provider needs a clear legal basis and a transfer assessment. SDAIA, which oversees data and AI in the Kingdom, has also published AI ethics principles, an AI adoption framework and generative AI guidelines. Those are guidance rather than binding law, but they are a good signal of what reviewers will expect. Work with your legal team on specifics; the architectural takeaway is to keep in-Kingdom or approved-region processing available for personal data.
UAE and the EU
The UAE has a federal PDPL, and in the DIFC, Regulation 10 (2023) specifically covers personal data processed by autonomous and semi-autonomous systems, including AI. If you serve European users, the EU AI Act is phasing in on top of GDPR, with general-purpose AI model obligations applying since 2 August 2025 and further obligations following on later dates.
Practically, design so that region is a routing decision. If your gateway can send a request to an in-region endpoint, a self-hosted model, or a global endpoint based on the user and the data class, you can adapt to new rules without rebuilding. Our AI consulting services often start with exactly this mapping of data flows to jurisdictions.
Vendor retention settings and contracts
Every model provider has defaults for how long they keep prompts and outputs, whether they use them for training, and who can access them for abuse review. Those defaults differ between consumer apps, standard API access and enterprise agreements, and they change over time. Do not assume. Check and record them for each vendor and each product tier you use.
A short checklist for each AI vendor:
- Is customer data used for model training by default, and can it be turned off contractually?
- How long are prompts and outputs retained, and is a zero or reduced retention option available for your account?
- Which regions can process and store your data?
- Which sub-processors are involved?
- What happens to data in features like file storage, assistants, or fine-tuning, which often have separate retention rules from plain API calls?
- Is there a data processing agreement that covers your regulatory needs?
Apply the same review to the rest of the stack: vector databases, observability and tracing tools, and any MCP servers or third-party tools the agent calls. Your tracing platform may end up holding more sensitive data than your model provider does.
Access controls and logging
Enforce permissions in retrieval and tools
An AI assistant should never show a user something they could not open themselves. Filter retrieval results by the requesting user's permissions before they enter the context window, and run tool calls with the user's identity rather than a shared service account. Multi-tenant products need hard tenant isolation in indexes and caches, so one customer's documents cannot appear in another customer's answers.
Log for accountability, not for leakage
You need logs to investigate incidents and answer data subject requests. You do not need full copies of every sensitive prompt sitting in a log index for years. Good practice looks like this:
- Log the request ID, user, data classes in context, model and region, tools called, and the policy decision.
- Mask or tokenize sensitive values before they reach logs and traces.
- Set retention periods for AI logs that match your policy, and delete on schedule.
- Restrict who can view raw prompts and outputs, and log that access too.
- Make AI data part of your deletion process, so a user's erasure request also removes their data from memory stores, indexes and evaluation sets.
When this is in place, you can answer "what data did this feature send, to whom, and where?" with a query rather than a guess. Teams building this into an existing product often pair it with work from our AI integration services team, since most of the controls live at the integration points.
How Softzee can help
We help teams map their data flows, set classification and residency rules, and build the redaction, routing and logging that enforce them, with particular experience in Saudi and UAE requirements. If you are about to put sensitive data near a model, book a call and we will review the plan with you.