You've Already Solved the AI Data Problem

Every AI conversation in logistics eventually hits the same wall. Someone in the room, usually the person who actually owns the data, says a version of this:

"Our contract rates are the business. Our carrier terms are the business. I'm not sending that to a model that's going to learn from it and hand it to a competitor."

That's the right instinct. It's the person doing their job. The trouble is that the concern usually gets aimed at the decision to use AI at all, when the thing it should be aimed at is one layer down: how the system is built.

This isn't a new kind of problem

The assumption underneath the objection is that proprietary data is safest when it stays still, that any system touching it is a system that leaks it.

But look at how the business already runs. You transmit contract rates and volumes to trading partners over EDI, and have for decades. Your TMS is likely hosted by a vendor. Your 3PL sees your customers, your broker sees your lanes, your payroll provider holds data that would end the company if it walked. In each case the data left the building. In each case the answer wasn't refusal. It was contracts, access controls, encryption, audit trails, and a clear look at the counterparty.

That's the playbook, your organization is already fluent in it, and it applies to AI the same way it applied to every system before it. This argument has run before, too. Fifteen years ago the sentence was "we can't put our data in the cloud." Before that, "we can't put our rates on a VAN," the value-added networks that now carry most of the industry's EDI traffic. Both were reasonable at the time. Both got resolved the same way: the controls matured and buyers learned which questions to ask.

So the question worth asking isn't whether proprietary data can be protected here. It can. The question is what specifically has to be true before this data touches this system, and that's answerable.

The questions that actually matter

1. Is my data used to train the model? Ask in writing, and get it in the contract rather than the FAQ. Enterprise and API tiers typically answer this differently than free consumer products.

2. How long is it retained, and where? Inputs are often stored briefly for abuse monitoring even when they aren't used for training. Find out the window, the region, and whether zero-retention options exist for your tier.

3. Whose infrastructure is it running on? This is the one most people skip and the one that resolves the objection cleanest. If the workload runs in your own cloud account and region, the governance question collapses into the one you already answered when you put your TMS data there.

4. Who are the subprocessors? Your vendor's vendors inherit your data, and their terms may not flow through to you.

Worth noting: the practical exposure in most organizations isn't a carefully evaluated enterprise deployment. It's an analyst pasting customer rates into a free chatbot on a personal account to reformat a spreadsheet, because no sanctioned option exists. A clear internal path is usually the fastest way to close that gap.

Architecture is the answer, not policy

A usage policy tells people what not to do. Architecture makes the safe path the only path. The controls that hold up are the second kind.

Keep the workload in your account. Managed model services from the major cloud providers let you call frontier models from your own account, in your own region. Prompts and completions aren't stored and aren't used to train anything. Your data, storage, and orchestration never leave your environment. The model call itself runs on managed infrastructure the model provider can't see, over the cloud's private network rather than the public internet. Access is governed by the same permissions you already maintain, and every call lands in the audit log you already collect.

Retrieve, don't fine-tune. Fine-tuning bakes your data into model weights: hard to audit, hard to revoke, hard to scope by user. Retrieval leaves the data in the system of record, pulls only the slice needed at query time, and inherits the permissions already on that system.

Redact at the boundary. Not everything needs to reach the model. Customer names and account numbers can be swapped for placeholder tokens on the way in and restored on the way out, so the model does its work without ever seeing who the customer is.

Log everything, scope by role. If you can't reconstruct who asked what and what context was retrieved, you don't have a governance story yet. The model has no opinion about who should see contract rates. Your retrieval layer enforces that before anything is passed as context.

One pattern, many use cases

We've built this pattern end to end: a document arrives by email, lands in object storage, triggers a function that assembles context, calls a frontier model through a managed service in the same account, writes structured output to a database, and sends a response. Production deployment, with every component in one cloud account and a CloudTrail entry for every call. No data uploaded to a third-party tool, no training on inputs, nothing persisted outside the boundary.

The useful property is that none of that changes with the workload. Document intake, exception triage, chargeback assembly, contract and tariff interpretation, internal knowledge retrieval: different business problems, identical control surface. So the decisions about training, retention, residency, scoping, and logging get made once, and every use case after that inherits them. When someone asks where the data goes, the answer is a diagram, not a reassurance.

One caveat worth being honest about: the pattern is straightforward to describe and genuinely non-trivial to build. Retrieval that actually respects the permissions on the source system, redaction that doesn't break the workflow it sits in, prompts that hold up against real freight documents rather than clean examples, and the IAM and infrastructure work underneath all of it. That's the distance between reading this post and having it in production. The architecture is the easy part to agree on. The build is where the time goes.

What about private, offline models?

There's a stronger version of "keep it in your boundary": run an open-weight model on your own hardware, with no outbound call at all. For air-gapped facilities or a genuinely can't-leave-the-premises data class, that's the answer.

For most operators it solves a problem the in-account pattern already solved, while adding a GPU fleet, a serving stack, and permanent operational ownership. "On our hardware" also isn't automatically secure. It moves the entire burden onto your team. The distinction worth holding: "put the model on our servers" and "keep our data under our control" are different requirements, and the second one is available a layer up for considerably less.

SOC 2 is evidence, not an answer

At some point a vendor will send you a SOC 2 report, and the conversation tends to stop there. It's useful, independent evidence that a company does what it says, but it answers a narrower question than most buyers assume.

And the limitation that matters most here: SOC 2 does not tell you whether your data is used to train a model. That's a contractual commitment, not a Trust Services Criterion. If it was never made in writing, there's nothing for an auditor to test. A vendor can have an immaculate report and permissive terms. Ask for both documents, every time.

Worth knowing as this matures: SOC 2 wasn't designed for AI-specific risk at all, which is why ISO/IEC 42001 has emerged as the AI governance standard layered on top of it. Expect more enterprise buyers to start asking for both.

If you're building internally, the mirror image applies: running on compliant infrastructure doesn't make your application compliant. You inherit the infrastructure controls and own everything above them, which the architecture above largely covers, and which is a good argument for building it that way from the start.

A procurement checklist

On the data:

On the controls:

On the audit:

A vendor who can answer these in one call has thought about it. One who needs to check with the team on most of them is telling you something useful.

The part that keeps costing money

While the question stays open, the operational math doesn't move. Document intake still takes hours it shouldn't. Chargeback disputes still get abandoned because nobody has time to chase the paperwork. Exception handling still lives in tribal knowledge and someone's inbox. Those costs compound quietly, and they compound whether or not the AI question has been settled.

The concern is legitimate, and the people raising it are usually the ones who should be. It's also answerable. Your data can be protected here for the same reason it's protected everywhere else it already travels: protection is a set of controls you implement, not a wall you stand behind.

If you want to work through these eleven questions with your team, or talk about what the in-account pattern looks like against your own stack, reach out. We do free 30-minute sessions: no pitch, just the answers you need before anything touches production data.