Quick question before you upload three months of inbound and outbound data for a peak-season forecast: do you know what the model will remember?
In 2023, Samsung engineers pasted chip source code into ChatGPT to debug it, and the code ended up in training data. Samsung makes chips. You run a warehouse, and your data looks less "critical" — until you actually list it. Customer SKUs and sales velocity. Carrier contract rates. Every picker's productivity numbers. Supplier settlement prices. If that goes into a public model's training set, you have not leaked a line of code. You have leaked the economics of your entire business.
Let me rank your warehouse data by how dangerous it is in the wrong hands.
Tier one: customer commercial data. SKU-level sales, inbound and outbound cadence, inventory positions — that is a brand's trade secret, and as a 3PL you almost certainly signed confidentiality clauses covering it. Feeding it to a third-party model outsources your confidentiality obligation to a system you do not control.
Tier two: price data. Your carrier discounts, the rates you quote customers, supplier settlement prices. Price is the last card on the negotiation table. Once a model has it, a competitor can extract it with the right prompts.
Tier three: people data. Picker units per hour, error rates, attendance. US states keep tightening employee data privacy — California's privacy laws now cover employee data too. Your legal counsel will not love real personnel data going into a model.
None of this means you cannot use AI on warehouse data. It means you desensitize first, and you do it properly. Here is the checklist I walk clients through.
Strip direct identifiers. Customer names, carrier names, employee names, badge numbers — all replaced with meaningless random IDs. Not "Customer A," which anyone can reverse-engineer. Random IDs, with the mapping table stored offline.
Generalize quasi-identifiers. Pick paths precise to the slot become zone-level. Timestamps precise to the minute become hourly. SKU-level data gets aggregated to category wherever the analysis allows. The rule I give every team: the model always gets the coarsest granularity the analysis can survive on.
Transform price data. Contract rates and quoted fees either stay out of the dataset or go through normalization — convert them to an index, for example. The model needs relative relationships between prices, not your actual floor.
Read the data terms before you sign anything. Does your AI tool's terms of service say user inputs will not be used for training? Enterprise and free tiers often differ on exactly this point. The free tier is cheap because your data is the payment.
And the fifth item, for data that still feels too hot after all of that: run it locally. A locally deployed open-source model will not match the frontier models, but the data never leaves your network. This is a genuine trade-off between capability and safety, and on this one I side with safety every time.
Get three sentences into the contract
When you sign with an AI vendor, the data terms cannot live only in the sales deck. They have to be on paper. Three sentences are non-negotiable. One: user input data will not be used for model training — stated explicitly, no wiggle room. Two: where the data is stored, how long it is kept, and whether it is deleted on expiry. Three: breach notification obligations and liability — how fast they tell you, and what they pay. If any of the three is missing, legal should send it back.
Re-read the terms at every renewal, because AI companies change their terms faster than anyone. Last year's promise may not survive this year's update. Do not auto-renew; review the data clauses first.
If you serve EU customers, there is another layer: under GDPR, employee and customer data are personal data, and moving them to servers abroad needs proper transfer mechanisms. Before you feed data containing EU personnel into a foreign vendor's model, make sure the transfer chain is compliant. Do not wait for the regulator to ask.
The process fix: who is allowed to export data
What technology cannot prevent, process has to. I recommend one simple rule: any bulk export of business data to an external AI tool requires approval from whoever owns the data. The approval checks three things: was it desensitized, were the contract terms reviewed, and is there a coarser alternative. Small companies without a data owner can have the founder approve — the point is that "export" cannot be one person's casual click.
The approval form does not need to be fancy. One page: what data, which tool, what desensitization, expiry date. That one page will save you in an audit. Keep the forms for at least as long as your data retention policy requires — auditors love asking for last year's.
Then there is the reality of shadow AI. You can write all the policies you want; meanwhile a sales rep pastes a customer quote into a free chatbot to "polish" it before a deadline. It happens in every company. You cannot prevent it, so channel it: buy the company an approved enterprise AI tier with the data terms negotiated, and the incentive to use the free tier disappears. Budget for it in IT — it is cheaper than one leak.
Training matters too, but skip the slide deck. Show the operations team two real cases, hand them a one-pager on what can and cannot be pasted, and you will get further than an hour on privacy law.
Here is your homework for tomorrow, and it takes twenty minutes. Export a real dataset from your system and play attacker: can you identify a specific customer from it? Can you back out the true cost of a lane? If you can, your desensitization is not done.
A model will never keep your secrets for you. The only confidentiality guarantee in the whole pipeline is the work you do before the data goes in.
