AI Security: Keeping Company Data Out of Model Training
Written by AI, fact-checked by Jon Ng · 16 min read · 1 August 2026 · Updated 10 November 2026
The biggest blocker to enterprise AI adoption is fear of data exposure, and the fear is reasonable. Most data leaks into AI services quietly: an employee pastes a contract into a chatbot, a plugin sends customer details to an API, or a key gets left in a public file. This guide is a practical, vendor-neutral checklist for CTOs and compliance teams who want the benefits of frontier models without handing over company data.
The short answer
You keep company data out of model training with four layers working together. First, use business or API terms that exclude your data from training, and get that in writing. Second, strip personal and confidential data before a request ever leaves your network. Third, log every request so you can audit what was sent and by whom. Fourth, send the most sensitive work to a model that runs on infrastructure you control.
No single setting does all of that. The rest of this article explains why, and how to put each layer in place without making the tools so awkward that staff go around them.
What "training on your data" actually means
A large language model is built in stages. It is first trained on a huge body of text, and then it is refined, often using examples of real conversations. "Training on your data" means a provider keeps what you typed in, or what the model replied, and uses it as material for a future version of the model. Once something is in a trained model, you cannot take it back out in any practical way.
That is different from three things people often mix it up with:
- Processing. The model reads your prompt in order to answer it. This always happens, and on its own it does not mean the text is kept.
- Retention. The provider stores your prompts and outputs for some period, for example to detect abuse or fix faults. Retention is not the same as training, but stored data can be breached, subpoenaed or read by staff, so it carries its own risk.
- Logging by you. Your own application or proxy records requests. This is good practice, but those logs then become sensitive data you must protect.
The practical point: you need an answer for each of the three, not only for training. A provider can promise "we don't train on your data" and still keep prompts for a month, and your risk team may need to know that.
Terms also differ by product tier. Consumer chat apps, team plans and developer APIs from the same company often come with different defaults for training and retention, and those defaults change over time. Don't rely on what you remember from last year, or on a blog post, including this one. Read the provider's current terms and data-processing documents, and record the date you checked.
Seven places company data really leaks
When teams think about AI data risk, they picture a hacker. In practice the exposure is usually mundane. These are the paths we look for first.
1. Staff pasting into personal accounts
The most common leak is an employee using a free consumer chatbot on a personal login because it is quick and the company has not given them an approved option. Customer lists, draft contracts, source code and board papers all end up in tools the company has no agreement with. Banning these tools rarely works. Giving people a sanctioned alternative that is as easy to use does.
2. Plugins and add-ons that call AI services
Many website and office tools now quietly send text to an AI provider: a form plugin that summarises messages, a helpdesk add-on that drafts replies, a spreadsheet extension that "cleans" data. Each is a new route for customer data to leave, often set up by one person and never reviewed.
3. Browser extensions
AI writing helpers and summarisers in the browser can read every page a person opens, including internal systems. Treat them like any other software that can read sensitive screens, and approve them from a list.
4. Chatbots on your own website
A support chatbot connected to your data can be talked into revealing things it should not, including customer details or its own instructions. This is called prompt injection, and it is covered in OWASP's list of top risks for LLM applications. A chatbot should be tested for it, not just launched.
5. API keys left in the open
AI, payment and cloud keys end up in theme files, public code repositories, .env files and backups on web servers. Anyone who finds one can run up your bill or read what flows through your account. Automated scanners look for these constantly.
6. Logs, transcripts and vendor sub-processors
Your own logs, an analytics tool that records chat transcripts, or an AI vendor that passes data to its own sub-processors can all hold copies. You may have a clean agreement with the model provider and still lose control one hop later.
7. Your public content being collected
Separately from what you send to AI, AI companies' crawlers collect public web pages, which can include material you would prefer not to have copied. We cover this in the website section below.
The architecture: an API proxy layer
The approach we implement for clients is an API proxy layer that sits between employees (and your own applications) and the commercial foundation models. Nobody calls a model provider directly. Every request goes through one controlled gateway, and that gateway does four jobs.
Job 1: scrub personal and confidential data
Before a prompt leaves your network, the proxy detects sensitive items such as names, email addresses, phone numbers, payment card numbers and national ID numbers (for example Singapore NRIC or Japan My Number), and replaces them with placeholders like [EMAIL_1]. When the answer comes back, the proxy puts the real values back in, so the user sees a normal reply while the provider never saw the originals.
Detection is never perfect. Pattern matching is reliable for structured items like card numbers and ID formats, and weaker for free-text details such as a client's name inside a paragraph. Plan for misses: combine scrubbing with the other layers rather than treating it as a guarantee, and test it on realistic samples of your own data.
Job 2: use provider settings that exclude training
The proxy sends traffic only to provider accounts and endpoints whose terms exclude your data from training, and with retention set as short as the provider allows. Because it is centralised, you configure this once, not on every laptop. If a provider changes its terms, you change one route.
Job 3: log every transaction for internal audit
The proxy records who sent what, to which model, and when. That gives compliance a real audit trail and lets you answer "did customer X's data go to an AI service?" with evidence. Because these logs can contain sensitive material, store them inside your own environment, restrict access, and set a retention period.
Job 4: route by sensitivity
Not every request deserves the same treatment. The proxy applies a policy: ordinary drafting and research can go to a commercial model after scrubbing, while requests tagged as highly sensitive are blocked or sent to an open-weights model running on your own infrastructure. This keeps the strongest commercial models available for the work where they matter, without exposing the crown jewels.
A side benefit of this design is that it is provider-neutral. You can switch from one model to another, or add a new one, without retraining staff or rebuilding every integration.
The CTO checklist
Use this as a working list. Each item should have an owner and a date.
- Inventory every AI tool in use. Include approved tools, personal accounts, plugins, browser extensions and AI features inside software you already pay for. Ask staff, and also check network and browser logs.
- Classify your data. Decide what is public, internal, confidential and regulated (personal data, health, financial, client secrets). Write one page a non-technical person can follow.
- Set a rule for each class. For example: public data can go to any approved tool; confidential data only through the proxy to a no-training endpoint; regulated data only to on-premise models or not at all.
- Provide an approved tool that is easy to use. If the sanctioned chat is slower or clumsier than a free app, people will use the free app.
- Move to business or API terms. Make sure each commercial model you use is covered by an agreement that excludes your data from training, and file a copy with the date.
- Deploy the proxy. One gateway for all model traffic, with scrubbing, routing and logging switched on from day one.
- Test the scrubber on your own data. Build a set of realistic fake records and check what gets through. Re-run the test whenever you change the rules.
- Lock down logs. Encrypt them, limit who can read them, and set a retention period that matches your policy.
- Find and rotate exposed keys. Search code repositories, servers and public web files for AI and cloud keys. Rotate anything that has been exposed, and give each application its own key with a spending limit.
- Test every customer-facing chatbot. Try prompt-injection and jailbreak attempts, and confirm the bot cannot reveal other customers' data or its own instructions.
- Review plugins and extensions. Keep an approved list. Remove anything that sends data to an AI service without review.
- Train people briefly and repeatedly. Twenty minutes with real examples does more than a long policy document. Make it clear what to do when someone pastes something by mistake.
- Write an incident step. If sensitive data goes to the wrong service, who is told, what is requested from the provider (deletion, confirmation), and what is recorded?
- Review quarterly. Terms, models and tools change. Put a recurring date in the calendar to re-check provider terms and re-run your tests.
Questions to ask every AI vendor
Whether it is a model provider or a small SaaS product with an "AI feature", the same questions apply. Ask them in writing and keep the answers.
- Is our data used to train or improve any model, yours or a third party's? Is that the default, or something we must switch off?
- How long are prompts and outputs retained, where, and who at your company can read them?
- Which sub-processors receive our data, and in which countries?
- Can we request deletion, and how do you confirm it?
- Is data encrypted in transit and at rest, and what independent security reports or certifications can you show us?
- What happens to our data if we cancel?
- Will you notify us before changing these terms?
A vendor that cannot answer these clearly is telling you something. Treat vague answers as a "no" until proven otherwise.
When data must not leave your walls
Some work should never touch an external API: certain client files, regulated health or financial records, trade secrets, or anything covered by a contract or law that restricts where data may go. For these, run an open-weights model on infrastructure you control, either on your own servers or in a private cloud environment in the region you require.
Be honest about the trade-offs. Self-hosted models usually need capable hardware, someone to maintain them, and may be less capable than the best commercial models on hard tasks. The sensible pattern is not "all on-premise" or "all cloud". It is a routing policy that sends each request to the cheapest option that meets its sensitivity rules, which is why the proxy's routing job matters.
Your website is part of the problem too
So far we have covered data you send out. There is a second side: what AI companies collect from your public site, and what attackers using AI can find on it.
AI crawlers and your content
AI companies run crawlers that copy public web pages. You can tell well-behaved crawlers to stay out through your robots.txt file, and block the rest at your server or at a service like Cloudflare. You can choose to block crawlers that gather material for training while still allowing AI search tools to read and cite your pages, which many businesses want so that they can be recommended in AI answers. Blocking training crawlers should not affect your Google ranking, because Googlebot is a separate crawler.
Keys and files exposed on your site
Public theme files, backups, .env files and database dumps sometimes sit on a web server where anyone can fetch them. Automated tools hunt for exactly these. One leaked AI key can mean someone else is using your account and reading what flows through it.
The AI plugins on your own site
If your WordPress site uses plugins that call an AI service (summaries, chatbots, auto-replies), find out what each one sends. Where possible, replace personal details with placeholders before the request leaves your server, and disclose in your privacy notice which AI services receive visitor data.
Cyber Securitise, the WordPress security product named in our security case study, covers this website side. Its AI Shield features include turning away known AI crawlers, hiding personal data before it reaches AI services, finding exposed keys, and testing site chatbots against prompt injection. There is a free edition and a free scan, covered at the end of this article.
Privacy law: PDPA and APPI
If you operate in Singapore or Japan, AI use sits inside existing privacy law. This is general information, not legal advice, so take advice for your own situation.
- Singapore (PDPA). Organisations must have a purpose for collecting and using personal data, protect it, and be careful when transferring it outside Singapore. Sending customer data to an AI service is a use and, usually, a transfer.
- Japan (APPI). Rules cover how personal information is used, how it is handed to third parties, and what must be disclosed when data goes overseas. A provider that processes data for you still needs oversight.
In both cases the same habits help: know which AI services receive personal data, minimise what you send, keep records, and say plainly in your privacy notice what happens. The proxy's audit log and scrubber are what make those habits possible to prove.
A 90-day rollout plan
You do not need a large programme to get started. A realistic sequence looks like this.
Days 1 to 30: see and decide
- Run the AI tool inventory and find the unapproved use.
- Write the one-page data classification and rules.
- Check the terms for the two or three providers you already use.
- Search for exposed keys and rotate them.
Days 31 to 60: build the gateway
- Deploy the proxy for one team or one use case, with scrubbing and logging on.
- Build your fake-data test set and measure what the scrubber misses.
- Offer the approved chat tool to that team and gather feedback.
Days 61 to 90: widen and harden
- Add sensitivity routing and, if needed, a self-hosted model for restricted work.
- Test customer-facing chatbots for prompt injection.
- Roll out to all staff with short training and an incident step.
- Schedule the first quarterly review.
A one-page AI use policy for small teams
Smaller companies often don't need a long policy document They need one page that staff will actually read. A starting point to adapt with your own advisers:
- Approved tools. List the AI tools and plans staff may use for work, and say that personal accounts are not for company data.
- Never paste. Customer personal data, passwords and keys, unreleased financials, and anything under NDA, unless the tool is approved for that class of data.
- Check before you use it. AI output is a draft. A person checks facts, numbers and names before anything goes to a customer or is published.
- Who to ask. Name one person who approves new tools and plugins.
- Mistakes happen. Say what to do if something sensitive was pasted by accident, and that reporting it quickly is expected, not punished.
- Review date. Put a date on the page and review it at least yearly, since provider terms change.
Pair the policy with the technical layers above. A policy on it's own relies on everyone remembering it on a busy day.
Frequently asked questions
Does using an API instead of the chat app keep my data out of training?
Often the API and business tiers have stricter defaults than consumer chat apps, but this varies by provider and changes over time. Check the current written terms for the exact product and plan you use, and keep a dated copy.
If a provider says it does not train on my data, am I safe?
Not entirely. Training is one risk. Retention, staff access, sub-processors, breaches and legal requests are separate, so you still want scrubbing, logging and a retention limit.
Can redaction catch everything?
No. It is very good for structured data such as card or ID numbers and weaker for free text. Use it together with the other layers and test it on your own data.
Do we need to self-host a model?
Only for data that cannot leave your environment. Many organisations send ordinary work to commercial models through the proxy and keep a small self-hosted model for restricted material.
Will blocking AI crawlers hurt my Google ranking?
Blocking AI training crawlers does not touch Googlebot, so it should not affect Google search. AI search tools can still be allowed if you want to be cited in their answers.
What should we do if someone pastes sensitive data into an AI tool by mistake?
Record what was sent and where, request deletion from the provider through the account or support channel, rotate any keys or passwords that were included, and tell your privacy officer so they can judge whether notification is required.
Does the PDPA apply to personal data we send to AI tools?
Generally yes: sending personal data to an AI provider is still collecting, using or disclosing it, so your PDPA obligations apply. If the provider processes it outside Singapore, PDPC’s Advisory Guidelines on Key Concepts in the PDPA explain the Transfer Limitation Obligation, which requires the overseas recipient to protect the data to a standard comparable to the PDPA. This is general information, not legal advice.
How often should we re-check AI providers' data terms?
At least once a year, and whenever you change plan, add a new tool or the provider announces new terms. Keep a dated copy of what you checked so you can show what applied at the time.
Free WordPress plugin and website scan
If your company runs WordPress, you can cover the website side of this checklist today at no cost. Cyber Securitise offers a free WordPress plugin and a free scan that checks any website in about 20 seconds for leaked AI keys, chatbot safety, AI crawler rules, exposed files, malware, hidden redirects, Google blocklisting and known vulnerabilities.
The paid yearly plan adds the AI privacy filter, which hides personal details before they reach AI services, along with daily scanning, quarantine, backups to your own storage and a dashboard for several sites. Visit the site for current pricing and what the free edition includes.
For the rest of the programme, including the proxy layer, routing policy, scrubbing tests and staff rollout, book a free consultation with Novatise. A mutual NDA is available before we look at anything sensitive.