AI Data Security - Which Data, Through Which Channel, and How to Keep Company Secrets Safe

A secure AI rollout in a company is possible, but it depends on which channel data takes to reach the model. In free and personal chat accounts, conversations may be used to train models unless the user turns that off. In business plans and in the OpenAI, Anthropic and Google APIs, customer data isn't used for training by default, and OpenAI lets you process API requests in a European region. So the biggest risk isn't the model itself, but employees pasting data into personal tools and poorly built integrations.

Where leaks really come from, how personal chat, business plans, the API and your own server differ (training, retention, EU region), a map of data classes and allowed channels, vendor requirements, masking and an accounting firm case.

In this post I show where leaks really come from, how a browser chat, a business plan, the API and your own server differ, how to match the channel to the type of data (with a ready-made map), what to require from a vendor, what a secure data flow with masking looks like, and how an accounting firm that was afraid to send anything to AI handled it.

Where leaks really come from

• Shadow AI. Employees paste contracts, price lists and customer data into personal accounts on free tools on their own initiative. It's a problem of missing rules and missing tools, not technology. More in the post on shadow AI.
• Leaky integrations. API keys stored in code, no data masking, apps from random vendors whose terms reserve rights to your data.
• Attacks on AI applications and agents. Hidden instructions in emails and documents can make a model reveal data. Details in the posts on prompt injection and AI agent security.
• Outside fraud using AI. An attacker doesn't need to break into your systems - cloning the CEO's voice and calling accounting is enough. I cover this in the post on deepfakes and AI fraud.

A browser chat, a business plan, the API or your own server

Two things companies often don't know. First, "we don't train on your data" isn't the same as "we don't store your data" - at OpenAI, API data is kept by default for up to 30 days in abuse monitoring logs, and zero retention requires vendor approval. Second, settings have to be turned on deliberately: the processing region, retention period and administrator access won't set themselves.

A map: which data through which channel

The simplest way to bring order is to split data into four classes and assign allowed channels to each. It's worth putting this map into your company AI policy:

A table like this answers most employee questions of the "can I paste this?" kind without involving IT every time.

What to require from a vendor

Before you connect a tool to company data, check that the vendor:

• Will sign a data processing agreement (DPA) that complies with GDPR.
• Guarantees no training on your data in the contract, not just in marketing materials.
• Clearly defines the retention period and lets you shorten it.
• Allows processing in the EU region (data residency).
• Publishes a list of subprocessors with access to the data.
• Holds certifications such as SOC 2, ISO 27001 or equivalent.
• Encrypts data in transit and at rest.
• Provides logs and access control for administrators.

If you're buying a ready-made app built on the big vendors' models, ask its maker the same questions - it's the app maker, not OpenAI or Anthropic, who decides what happens to the data along the way.

A secure data flow with masking

For personal and confidential data, an architecture in which the model never sees identifying data works well:

1. 1.Source. An email or CRM record reaches the orchestration system.
2. 2.Masking. Before anything goes to the model, a script replaces names, tax IDs, addresses and account numbers with placeholders such as [CLIENT_1].
3. 3.API request. The masked text goes to the model over an encrypted connection, ideally in the EU region.
4. 4.Response. The model returns a draft with placeholders.
5. 5.Restoring data. In your environment, the placeholders are swapped back for the real data.
6. 6.Approval and saving. A person approves the result, and the document goes to an encrypted destination.

A real example: an accounting firm and GDPR

I built automated email replies for a mid-sized accounting firm. The firm was drowning in client questions about filing statuses, and every reply contained amounts, account numbers and social security data. The owner was afraid to send anything to AI.

I used a model through the API with full masking. AI recognized that a client was asking about "July social security", but before the request was sent, the company name was replaced with a placeholder. The model drafted the reply, and the final email was assembled locally, on the firm's own servers.

The result: response time dropped from 2 days to 15 minutes, and clients' identifying data never reached the model.

Logs, access and keys

• Audit trail. Every request to the model is logged in the orchestration system: when, by whom and from which process.
• Access control. A designated group of employees uses the AI tools, ideally through company sign-in (SSO).
• API keys. Stored in a vault or environment variables, never in code, and rotated regularly.
• AI agents. When AI takes actions in systems, you need separate accounts, narrow permissions and limits - I cover them in the post on AI agent security.

GDPR and the AI Act in brief

GDPR applies unchanged: you need a legal basis, data minimization, a processing agreement with the vendor and sometimes an impact assessment (DPIA). I explain when a prompt becomes processing of personal data and when you need a DPIA in the post on GDPR and AI. The AI Act introduces obligations gradually - for most companies using AI in internal processes, it mainly means an inventory of the systems used, transparency toward customers where required, and staff training. Details in the AI Act guide.

The most common mistakes

• A ban without an alternative. Employees use AI anyway, just on personal accounts. It's better to give them a secure tool and clear rules.
• API keys in code. One repository leak and someone is using your budget and data.
• Trusting "magic" apps. A nice app from an unknown vendor with access to your CRM, no processing agreement and no check of what it does with data.
• No human approval. AI sending contracts or offers without sign-off is a legal and reputational risk.
• Assuming defaults are enough. Region, retention and administrator access have to be configured deliberately.

---

I design AI rollouts so customer data and company secrets stay safe - from a data map and tool selection to masking, the processing region, logs and permissions. I do this as part of AI consulting and AI app development. Get in touch - I start with a review of what data reaches AI in your company today, and through which channels.

Worth reading next:

• GDPR and AI - Personal Data in Prompts, DPIA and LLM Vendor Agreements (Practically)
• Shadow AI - Your Employees Are Using AI Without Your Knowledge and That's Your Problem
• AI Agent Security - Permissions, Sandboxing and an Audit Trail Before an Agent Breaks Something
• AI Policy at Your Company and ISO/IEC 42001 - Governance That Doesn't Kill Innovation