LogisticsRegulations, Compliance & Governance

Governing AI vendors at a 3PL: the accountability chain in logistics

AI vendor governance at a 3PL is the discipline of staying answerable for AI systems you do not control. Your customer contract names you as the processor; your route optimiser, ETA engine and document-extraction vendors are your sub-processors; their model provider is theirs. Under GDPR Article 28(4), you remain fully liable for every tier below you.

Logistics · Regulations, Compliance & Governance

Atomic Loops EngineeringIndustrial AI practiceReviewed by Atomic Loops Solutions ArchitecturePublished 14 August 202664 min read

Key takeaways

A 3PL is accountable for AI it does not run. Under GDPR Article 28(4), where a sub-processor fails to meet its data protection obligations the initial processor — you — remains fully liable to the customer for that sub-processor's performance. Buying the capability does not transfer the answerability.
Tier AI vendors by data exposure, not by spend. A route optimiser that reads consignee names and addresses and writes into dispatch is a different governance object from an internal chatbot, even when the chatbot's invoice is larger. Exposure and decision authority set the assurance depth; the contract value sets nothing.
Four contractual controls carry almost all the weight for AI specifically: a training-use prohibition on customer data, a model performance floor stated in logistics units with a defined remedy, an incident notification window measured in hours, and audit rights that survive down to sub-processors. Standard software paper contains none of them.
Customers now ask for the whole chain, not your tier. The credible answer is a named list — your vendor, its model provider, the processing location and the change-notice mechanism — which is why the vendors worth keeping are the ones that publish theirs: AWS, for example, states it will update its sub-processor page at least 30 days before engaging a new sub-processor.
A SOC 2 Type 2 report and ISO/IEC 27001 certification answer whether a vendor's security controls are sound. They do not answer whether your consignee data is training a model your customer's competitor will rent next year. That question is answered only by a contract clause and a segregation attestation.

Abbreviations used on this page

3PL: Third-party logistics provider — the operator holding someone else's freight and someone else's data
MSA: Master services agreement — the customer contract the data terms hang off
DPA: Data processing agreement — the GDPR Article 28 contract between controller and processor
SLA: Service level agreement — availability and, for AI, model performance
TMS: Transport management system
WMS: Warehouse management system
ETA: Estimated time of arrival — the most widely resold AI output in logistics
SOC 2: Service Organization Control 2 — the AICPA trust-services attestation report
ISMS: Information security management system — what ISO/IEC 27001 certifies
AIMS: AI management system — what ISO/IEC 42001 certifies
SCC: Standard contractual clauses — the transfer mechanism for personal data leaving the EEA
GPAI: General-purpose AI model — the EU AI Act's term for the foundation model at the end of your chain

What governing AI vendors at a 3PL actually means

A definition, and the chain it describes: your customer's contract, your contract, your vendor's model provider — and where the liability sits along it.

Governing AI vendors at a 3PL is the discipline of remaining answerable, to your customer, for AI systems you neither built nor run. A third-party logistics provider almost never owns the data it processes: the consignee names, addresses, contact numbers, commercial invoices, lane volumes and rate history all belong to a customer who has named the 3PL as a processor in a data processing agreement. When the 3PL then routes that data through a route optimiser, an ETA engine or a document-extraction service, those vendors become sub-processors, and the systems making operational decisions about someone else's freight sit two or three companies away from the party legally accountable for them.

The legal position is unusually blunt. GDPR Article 28(4) (opens in a new tab) states that where a processor engages another processor, the same data protection obligations must be imposed on that other processor by contract, and that where that other processor fails to fulfil its obligations, the initial processor remains fully liable to the controller (opens in a new tab) for the performance of the other processor's obligations. There is no partial transfer, no shared responsibility model and no dilution by distance. Article 28(2) adds the operational half: a processor may not engage another processor without the controller's authorisation, and where the authorisation is general, must inform the controller of intended changes so the controller can object. Both obligations land on the 3PL, and both are unenforceable without a register.

The accountability chain: customer, 3PL, vendor, model provider

Three lanes over the same four parties. The top lane is the paper chain — who owes what to whom. The middle lane is the physical chain — where the customer's shipment data actually travels. The bottom lane is the proof chain — what the 3PL can put in front of a customer. Governance maturity is how closely the three lanes line up.

Human in the loop
Where value leaks
Data & feeds
AI / model
System-of-record action

The process, in words

Paper chain: the customer's master services agreement and DPA name the 3PL as processor and set the purpose, retention and authorisation rules. The 3PL's own vendor contracts must carry those same obligations back-to-back, and the vendor's agreement with its model provider must carry them one link further. Liability does not travel with the data — it returns to the 3PL under Article 28(4) regardless of which link failed.
Data chain: consignee names, addresses, commercial invoices and lane volumes enter the 3PL's TMS or WMS under instruction, are called out to a vendor's AI service for routing, ETA, extraction or scoring, and are frequently passed on again to a general-purpose model API. Unless a training-use prohibition exists and flows down, the last hop is where customer data can end up improving a model that another customer — possibly a competitor — later benefits from.
Proof chain: what the 3PL can actually put in front of a customer. It starts with the register, which is what makes a questionnaire answerable at all; adds the AI schedule and third-party attestations for each tier-1 vendor; adds the named sub-processor list with an advance change-notice route; and ends in a dated, maintained evidence pack. A 3PL's rung on the ladder is simply how far along this lane it can go before the answer becomes 'we would have to ask'.
The dashed links are where governance actually happens: each artefact in the bottom lane is evidence about a specific object in the lane above it. Where a dashed link is missing, the corresponding customer answer is being given on trust.

Step-by-step insights

The customer DPA is the specification, not the constraint: Most 3PLs read the customer DPA defensively, as a list of things they must not do. Read forwards it is more useful: it is a written specification of every right the 3PL needs to hold from its own vendors. Retention limits, deletion timelines, sub-processor authorisation, audit rights, breach notification, processing location — each one is a customer promise that has to have a matching vendor obligation behind it or it is a bare liability. The fastest way to draft an AI vendor schedule is to work down your own customer template and ask, for each clause, 'who gives me this?'.
Where the vendor tier stops being software and starts being a decision: The middle lane hides a distinction that matters enormously in practice. Some vendor AI reads data and returns a suggestion a planner may ignore; some writes into the execution record and changes what happens to freight. A route optimiser that assigns stops, an appointment engine that books doors, a classification tool that sets an HS code — these make decisions with consequences for a customer's goods and, in the customs case, for their regulatory position. Governance depth should follow decision authority as much as it follows data sensitivity, which is why the tiering table further down uses both axes.
The inference hop is the one nobody negotiated: The link from vendor to model provider is where the chain most often becomes opaque, because it was created by the vendor's engineering decision rather than by anyone's procurement. A document-extraction product that used to run a bespoke model may now call a general-purpose AI (GPAI) model through an API; the product name did not change and neither did your contract. This is the single most productive question to ask a tier-1 vendor: which model or infrastructure provider processes our data today, in which region, and under what terms? A vendor that cannot answer in writing has not read its own chain either. The EU AI Act gives GPAI providers their own transparency and documentation duties, which means the information you need to answer a customer increasingly exists — it simply has to be asked for.
Shared model reuse: the commercial question dressed as a technical one: Network-wide learning is a genuine product advantage for visibility and rate-prediction vendors, and it is also precisely what a shipper means when it asks whether its data trains a model its competitors use. The right handling is neither denial nor quiet acceptance: obtain a written statement of what is and is not pooled, decide with the customer whether the trade is acceptable for their data, and record the decision. Customers are far more tolerant of a disclosed trade-off than of discovering one in a vendor's marketing deck.
Why the proof lane is the one customers now audit: Assurance has moved from asserting a posture to producing artefacts. The modern question set — name your AI systems, name your sub-processors, state your processing regions, evidence your training-use position, show your last performance test — cannot be answered with adjectives. The proof lane exists to make each of those answers an extract rather than a project. Its economics are simple: the pack costs weeks to build once and days to maintain, and it replaces a six-week scramble every time a large customer's annual review comes round.
Liability returns even when the data does not: The final node in the top lane is the one operators find hardest to internalise. If a vendor's sub-processor mishandles data, the customer's claim runs to the 3PL, not past it. The practical implications are three: the 3PL must be able to see far enough down the chain to price the risk, must hold contractual recourse against its own vendor for a failure it did not cause, and must carry the insurance and indemnity position to match. A chain you cannot see is a chain you have accepted liability for blind.

Vendor inventory and tiering
The register of every vendor whose product applies AI to customer data, with what each system sees, the decisions it influences, the customer contracts it sits under, the internal owner and the renewal date. Tiering by data exposure and decision authority is what makes the workload finite: most 3PLs find a handful of tier-1 relationships inside a list of dozens.
Contractual controls
The four AI-specific terms that ordinary software paper omits: a training-use prohibition on customer data, a model performance floor stated in operational units with a remedy, an incident notification window short enough to feed your customer's own clock, and audit rights that survive to sub-processors. Plus exit: export format, deletion window, attestation.
Sub-processor chain assurance
Naming and evidencing the tier below your vendor — the model or infrastructure provider, the processing location, the transfer mechanism and the change-notice route. Under the EDPB's controller and processor guidelines (opens in a new tab), roles follow what a party actually decides, not what the contract calls it; a vendor that determines its own purposes for your data has stepped outside the processor role your customer authorised.
Customer transparency
Answering the security questionnaire and the 'do you use AI on our data' question honestly, consistently and fast — from a maintained evidence pack rather than a fresh draft per account. The ICO's accountability and governance guidance (opens in a new tab) frames the same idea for regulators: being able to demonstrate compliance is a separate obligation from being compliant.

The five rungs in detail

For each rung: what it looks like inside a real 3PL, the signals a reviewer can check in an afternoon, the anti-pattern that traps operators there, and what leaving costs.

The ladder runs from Unmapped to Continuously monitored, and each rung is defined by what a 3PL can produce rather than by what it intends. Rung 1 can produce nothing; rung 2 can produce a register; rung 3 can produce contracts that match its customer promises; rung 4 can produce the chain below its vendors; rung 5 can produce all of that with a date on it that is still current. Each rung below is written for a practitioner: the hallmarks describe observable conditions, the diagnostic signals are checks you can run against your own contracts and inboxes this week, and the anti-pattern is the specific mistake most often made trying to leave that rung.

Assurance you can evidence, against position on the ladder

What a 3PL can put in front of a customer stays close to flat through rungs 1 and 2 — a register is real progress internally and answers almost nothing externally — and inflects at rung 3, when outward promises finally have inward rights behind them. The steepest section is rung 3 to 4, where the chain below your vendors becomes visible and the questionnaire stops being a project.

Assurance the 3PL can evidence to a customer by stage

Stage 1 · Unmapped — 26% of operators. Nobody can list which AI systems touch customer shipment data, which vendor runs each one, or which customer contract that vendor sits under.
Stage 2 · Inventoried — 34% of operators. A register exists and vendors are tiered by data exposure, but the contracts behind them are still ordinary software paper.
Stage 3 · Contractually controlled — 22% of operators. Tier-1 vendor contracts carry AI-specific terms back-to-back with the customer promises they support, and someone tests them.
Stage 4 · Chain-assured — 13% of operators. The chain below your vendors is named and evidenced, and customer assurance is produced from a maintained pack rather than written from scratch.
Stage 5 · Continuously monitored — 5% of operators. The register, the chain and the performance floor are live: change notices arrive, floors are re-tested on a cadence, viability is watched and exit has been drilled.

Curve shape: logistic, plotted from the stage data above. Distribution: Ladder structure consistent with NIST's cyber supply chain risk management guidance.

Select a rung

Every rung's full detail is in the page source — the selector only changes which panel is visible, so nothing here depends on JavaScript to exist.

Stage 1

Unmapped

26% of operators sit here

Nobody can list which AI systems touch customer shipment data, which vendor runs each one, or which customer contract that vendor sits under.

Unmapped is rarely a governance vacuum. Most 3PLs at this rung have a supplier onboarding process, an information-security policy and a DPA template that legal is proud of. What is missing is the bridge between that machinery and the AI estate, because the AI estate did not arrive through procurement. It arrived as features inside platforms already in the building: the visibility provider added predictive ETAs, the TMS added an assistant that reads rate emails, the customs broker added classification, and the yard system added a camera model. Nothing was bought, so nothing was assessed.

The consequence is that the operator's exposure is defined by other people's product roadmaps. A vendor can move a workload to a new model provider, change a processing region, or start using aggregated customer data for benchmarking, and the 3PL will learn about it — if at all — from a release note. Meanwhile the customer contract signed eighteen months ago names the 3PL as processor and requires prior authorisation for sub-processors, which is an obligation the 3PL is currently in no position to discharge.

This rung is uncomfortable to leave because the first honest walk-through of the estate always finds something: a document-extraction feature pushing consignee names to a general-purpose model API, a driver app whose vendor retains footage longer than the customer contract allows, a rate engine trained on the lane volumes of three competing shippers. Leaders sometimes prefer not to look. That instinct is backwards. In every customer dispute and every regulatory action in this space, the operator who could not produce a map fared worse than the operator who produced one with problems on it.

In practice

The questionnaire that stopped a renewal

A mid-sized freight forwarder receives its largest customer's annual security questionnaire, which this year has eight new questions about AI. Question one — 'list every AI system that processes our data, and every sub-processor involved' — takes six weeks. The answer, when it arrives, is incomplete: nobody can establish whether the customs classification tool calls an external model, because the contract predates the feature and the vendor's support desk gives two different answers. The renewal is signed late and with a new audit clause attached.

What it looks like

No list exists of vendors whose products apply AI to customer data
AI features were switched on inside platforms bought years earlier, under contracts that never mention models
Customer security questionnaires are answered from memory by whoever is free
Nobody can say whether a consignee address has ever left the operator's own estate

Diagnostic signals you can check this week

Ask for the list of AI vendors. If the answer is a conversation rather than a file, you are here
Open your three largest customer DPAs and compare their sub-processor annexes with what is actually running
Ask any platform vendor's account manager which AI features are enabled on your tenant, and time how long the answer takes
Search your last four security questionnaires for the word 'model'. At this rung the answers are prose, not references to artefacts

Anti-pattern · Banning AI while the estate keeps running

The reflex on discovering an unmapped estate is a moratorium: no new AI tools until governance exists. It fails on contact with reality, because the exposure is inside platforms nobody is going to switch off, and a ban gives operations a reason to stop mentioning what they are using. Every 3PL that has tried this has ended up with the same estate plus a discovery problem. Inventory first, in the open, with an amnesty. You cannot govern what people have stopped telling you about.

What holds you here

There is no list, so every customer question, every contract review and every incident starts with discovery work that nobody has time for.

Highest-leverage next move

Build the register: every vendor whose product applies AI to customer data, what data it sees, which customer contracts it sits under, and who owns it internally.

Cost of leaving

Effort: 4–8 weeks
Team: One security or compliance lead, one operations manager per business unit, part-time
Risk: Low — the work is discovery, and nothing in the operation changes while it runs
To next stage: 1–3 months

If this is you, the next step is

Two weeks: every AI-touching vendor named, tiered by data exposure, mapped to the customer contract it sits under.

Run a vendor discovery sweep

Stage 2

Inventoried

34% of operators sit here

A register exists and vendors are tiered by data exposure, but the contracts behind them are still ordinary software paper.

Inventoried is the rung where the argument stops being about discovery and starts being about leverage. The register exists, it is tiered, and it is honest — and it makes the problem legible in a way that is initially unwelcome, because it shows in one table how many tier-1 vendors are operating under contracts that say nothing about models at all. That gap is not a drafting failure. The contracts were negotiated for software, and the software has since grown a model.

The register earns its keep almost immediately in customer conversations. A 3PL that can answer 'which of your systems apply AI to our data, and what do they see' with a table rather than a paragraph closes questionnaires in days instead of weeks, and the answer is the same one every customer gets. That consistency matters more than it sounds: divergent answers across customers is one of the fastest ways to turn an ordinary assurance exercise into a contractual dispute.

What holds operators here is renewal timing. Every AI clause you want is easiest to obtain at renewal and hardest to obtain in the middle of a term, so the register's most valuable column turns out to be the renewal date. Operators who sort by exposure and then plan against the renewal calendar move up in eighteen months. Operators who wait for a vendor to volunteer better terms wait indefinitely.

In practice

The tier-1 list that was four names long

A contract logistics provider inventories forty-one vendors touching customer data in some form. Tiering by exposure reduces the governance problem sharply: four are tier 1 — a visibility provider with consignee-level ETAs, a document-extraction service reading commercial invoices, a routing engine writing into dispatch, and the WMS vendor's new labour-planning model. The other thirty-seven need a register entry and an acceptable-use rule. The legal team's workload turned out to be four negotiations, not forty-one, and all four had renewals inside fourteen months.

What it looks like

A maintained register lists AI-touching vendors, the data each sees and a named internal owner
Vendors are tiered by data exposure and decision authority, not by spend
Questionnaire answers are consistent between customers because they come from the register
No contract yet contains a training-use prohibition, a model performance floor or an AI-specific notification window

Diagnostic signals you can check this week

Ask to see the register and check whether it has a data-exposure tier and a renewal date per vendor
Compare the AI answers in the last three customer questionnaires; at this rung they finally match
Count how many tier-1 contracts contain the word 'train' or 'training data'. Usually zero
Ask what happens when a vendor changes sub-processors. At this rung there is no mechanism, only a mailing list nobody is on

Anti-pattern · Treating the register as the deliverable

A well-built register feels like completion — it is a real artefact, it answers questions, and it is visibly better than what came before. It is also a description of exposure rather than a control on it. The failure shows up at the first incident: the register names the vendor, the data and the owner, and then the operator discovers there is no contractual notification window, no remedy for a model that has quietly degraded, and no right to see what the vendor's own sub-processor did. Registers do not create leverage. Renewals do.

What holds you here

The register describes exposure but creates no obligations, so every question the register raises has to be answered by goodwill rather than by contract.

Highest-leverage next move

Take the four AI clauses that matter — training use, performance floor, notification window, audit rights that reach sub-processors — into your next tier-1 renewal.

Cost of leaving

Effort: 6–12 months
Team: Compliance lead, commercial or legal counsel, one engineering owner per tier-1 vendor
Risk: Medium — the work is negotiation, and at least one vendor will refuse a clause you need
To next stage: 6–12 months

If this is you, the next step is

We mark your top vendor agreements against the back-to-back table on this page and rank the gaps by renewal date.

Get your tier-1 contracts marked up

Stage 3

Contractually controlled

22% of operators sit here

Tier-1 vendor contracts carry AI-specific terms back-to-back with the customer promises they support, and someone tests them.

Contractually controlled is the first rung where the 3PL's promises to its customer and its rights against its vendor are the same shape. That symmetry is the whole point. A customer DPA that requires deletion within thirty days is a liability if the vendor contract behind it is silent; a customer commitment that AI will not be trained on their data is unenforceable optimism if the vendor's terms reserve a broad right to improve its services. Rung 3 is the work of making every outward promise match an inward right.

The clause that changes behaviour most is the performance floor, because it is the one that converts a quality problem into a contractual event. Availability SLAs are useless here: a degraded ETA model is fully available and quietly wrong, and without a floor there is nothing to trigger. Stating the floor in the operation's own units — mean ETA error on a named lane set, precision on address matching, field-level accuracy on commercial-invoice extraction — also forces agreement on how it will be measured and on whose data, which is where most of the negotiation time actually goes.

What operators discover at this rung is that the constraint moves one link down the chain. The vendor signs a training-use prohibition and then explains, reasonably, that inference runs on a general-purpose model API whose terms it did not write. The clause is real, the flow-down is not yet evidenced, and the customer's next questionnaire will ask about exactly that gap. This is the moment rung 4 becomes the priority rather than an aspiration.

In practice

The clause that was true one link up

A 3PL secures a clean training-use prohibition from its document-extraction vendor and reports it to the customer. Six months later the customer's own audit asks which model provider processes the extracted fields and under what terms. The vendor's answer — a hyperscaler's inference API with an enterprise agreement — is fine, but the 3PL had never read it, could not name the processing region, and had no evidence of the flow-down. The clause held. The chain assurance did not exist, and the customer noticed before the 3PL did.

What it looks like

Tier-1 agreements prohibit training shared or other-customer models on customer data, with any exception named and time-limited
A model performance floor is stated in logistics units — ETA error, address-match precision, field-level extraction accuracy — with a defined remedy
Incident notification is measured in hours and flows through to the customer's own 72-hour clock
Exit terms name the export format, the deletion window and the attestation that follows it

Diagnostic signals you can check this week

Pick a customer DPA commitment at random and try to trace it to a matching right in the vendor contract behind it
Ask what contractual event a degraded model triggers. If the only answer is the availability SLA, there is no floor
Check whether the incident notification window in the vendor contract is shorter than your obligation to your customer
Ask when the exit and deletion terms were last read by someone who would have to execute them

Anti-pattern · Accepting 'we are SOC 2 certified' as the answer

A SOC 2 Type 2 report and ISO/IEC 27001 certification are genuinely valuable and genuinely narrow: they attest that the vendor's stated security controls operated effectively over a period. They say nothing about whether your consignee data trains a shared model, nothing about model quality, and nothing about what the vendor's own sub-processor does. Treating an attestation as a substitute for AI-specific terms is the most common way a rung-3 programme convinces itself it is at rung 4. Read the scope section of the report and note what is not in it.

What holds you here

The terms stop at your direct vendor, so any question about the model provider behind it is answered on trust rather than on evidence.

Highest-leverage next move

Obtain the named sub-processor list for every tier-1 vendor, read the model provider's terms yourself, and evidence the flow-down.

Cost of leaving

Effort: 9–18 months
Team: Commercial counsel, security lead, an engineering owner who can define the performance floor
Risk: Medium — a tier-1 vendor may refuse, and the contingency is a second source you have not built
To next stage: 9–18 months

If this is you, the next step is

A back-to-back schedule mapped to your own customer DPA templates, with the performance floor written in your units.

Draft the AI schedule

Stage 4

Chain-assured

13% of operators sit here

The chain below your vendors is named and evidenced, and customer assurance is produced from a maintained pack rather than written from scratch.

Chain-assured is the rung at which the 3PL can answer the question its customers are actually asking. That question is no longer 'do you use AI on our data' — it is 'show me the whole chain'. Answering it requires three artefacts the previous rung did not need: the named sub-processor list for each tier-1 vendor, the model provider's own terms in the 3PL's hands, and a segregation statement that says plainly whether this customer's data contributes to any model another customer benefits from.

The multi-tenant question is the one that turns commercial. A visibility provider's whole value proposition may be that it learns from network-wide data, and network-wide includes your customer's competitors. That is not automatically wrong and it is not automatically disclosable-and-fine either; it is a commercial decision the customer is entitled to make with the facts in front of them. Operators who surface it early sell against it successfully. Operators who let a customer discover it in a vendor's marketing material spend the next quarter in remediation.

The efficiency gain at this rung is large and often the thing that funds it. A maintained evidence pack — register extract, sub-processor chain, attestation library, model performance evidence, exit terms — turns a six-week questionnaire scramble into a two-day assembly, and turns the AI section of a tender response into a differentiator. Several of the largest shippers now score AI governance explicitly, and a 3PL that answers with named artefacts beats one that answers with adjectives.

In practice

The chain that fitted on one page

A 3PL rebuilds its customer assurance answer as a single-page chain map: customer, 3PL, four tier-1 vendors, and for each vendor the named model or infrastructure provider, processing region, transfer mechanism and change-notice route. Two of the four vendors publish sub-processor pages with advance-notice subscriptions; the other two supplied lists under the contract. The map goes into every tender response and every annual review. The first customer to receive it asked for the same artefact from its other two logistics providers, neither of which could produce one.

What it looks like

Every tier-1 vendor's sub-processors are named, with processing locations and transfer mechanisms recorded
The model provider's terms have been read by the 3PL, not summarised by the vendor
Segregation is evidenced: a statement of whether customer data contributes to any shared or multi-tenant model
Customer questionnaires and audit requests are answered from a maintained evidence pack in days

Diagnostic signals you can check this week

Ask for the named sub-processor list of your largest AI vendor and see whether it arrives from a file or from an email request
Ask who has read the model provider's terms. If the answer is the vendor, the chain is asserted rather than assured
Check whether a segregation statement exists per tier-1 vendor and whether it is dated
Time your last customer questionnaire from receipt to complete answer. Days means rung 4; weeks means rung 3

Anti-pattern · Publishing a chain map you cannot keep current

The evidence pack's value is that it is true today. Sub-processor lists change, vendors switch model providers, regions move, and a stale chain map is materially worse than none, because it is a written representation to a customer that has quietly become false. Operators who publish before they have an intake route for change notices spend their credibility twice: once on the map, and once apologising for it. Build the notification intake before the map goes out.

What holds you here

The chain is documented as of a date, and nothing systematically detects the day it stops being true.

Highest-leverage next move

Put the chain under monitoring: change-notice intake, scheduled performance-floor re-tests, viability signals and a drilled exit.

Cost of leaving

Effort: 12–24 months
Team: Compliance lead with a standing forum, vendor owners, one engineer maintaining the evidence pack
Risk: Higher — the exposure is now written down and shared with customers, so accuracy becomes a contractual matter
To next stage: 12–24 months

If this is you, the next step is

Chain map, segregation statements, model performance evidence and exit terms, assembled once and maintained.

Build the customer assurance pack

Stage 5

Continuously monitored

5% of operators sit here

The register, the chain and the performance floor are live: change notices arrive, floors are re-tested on a cadence, viability is watched and exit has been drilled.

Continuously monitored is a much smaller claim than it sounds, and that is what makes it achievable. It does not mean a vendor risk platform or a permanent programme. It means four recurring jobs with owners and dates: process the change notices, re-test the floors, review the viability signals, and rehearse one exit a year. Each is cheap in isolation; together they are the difference between a chain map that was true and a chain map that is true.

Viability is the signal 3PLs under-weight most, and logistics has the clearest public warning in any industry. Platforms with major backers and real adoption do get withdrawn: A.P. Moller – Maersk and IBM announced in November 2022 that TradeLens would be discontinued, with the platform going offline by the end of the first quarter of 2023 — a wind-down measured in months for customers who had integrated it. Whether a wind-down is orderly or an incident depends almost entirely on whether the exit terms were written and rehearsed while the relationship was good.

The reason this rung is rare is that its work is invisible when it succeeds. Nothing happens: notices are processed, floors hold, the vendor stays solvent. The operators who sustain it are the ones who attach the cadence to something already in the calendar — the quarterly customer review, the annual attestation refresh, the renewal cycle — rather than creating a governance forum that competes for attention with the peak season.

In practice

The change notice that arrived in time

A visibility vendor emails a 30-day notice that it is adding a new model-hosting sub-processor in a different region. Because the notice lands in a monitored inbox with a named owner, the 3PL reviews the transfer mechanism, checks it against the two customer DPAs that restrict processing location, and notifies both customers inside their objection window. One customer accepts; one asks for the previous region to be retained and the vendor accommodates it. Total effort: about a day. The same event at rung 2 is discovered months later, by the customer.

What it looks like

Sub-processor change notices arrive at a monitored inbox and trigger a review inside the customer objection window
Model performance floors are re-tested on a schedule against fresh data, not accepted at signature
Vendor viability is watched with named signals — funding, ownership change, support responsiveness, roadmap drift
Exit and data deletion have been rehearsed for at least one tier-1 vendor, and the attestation was produced

Diagnostic signals you can check this week

Ask who monitors the inbox that vendor change notices arrive at, and what happened to the last one
Check when the model performance floor was last re-tested against fresh data rather than accepted at signature
Ask for the date of the last exit rehearsal and the deletion attestation it produced
Ask which viability signals are tracked per tier-1 vendor, and when they were last reviewed

Anti-pattern · Buying a platform instead of assigning the four jobs

At this rung the temptation is a third-party risk management platform that promises continuous monitoring of the vendor estate. The tooling is fine and it monitors the wrong things: security postures and breach feeds, not training-use terms, model floors or sub-processor changes specific to your chain. A platform that automates evidence collection is worth having once the four jobs have owners. Bought first, it produces a dashboard of external signals while the 30-day sub-processor notice sits unread in a shared mailbox.

What holds you here

Sustaining the cadence is an organisational problem, not a technical one — the reviews compete with peak season and quietly lapse.

Highest-leverage next move

Attach each of the four recurring jobs to an existing calendar event and give each a named owner, so the cadence survives a busy quarter.

Cost of leaving

Effort: Continuous
Team: Named owner per tier-1 vendor plus a quarterly governance review with commercial and security
Risk: Concentrated — low-frequency, high-consequence events: a wind-down, an acquisition, a model change nobody was told about

If this is you, the next step is

We run a tabletop wind-down of one tier-1 AI vendor: export, cutover, deletion, attestation, customer comms.

Rehearse an exit

Where 3PLs actually sit on the ladder

The distribution across the five rungs, and why the move from Inventoried to Contractually controlled is the one most operators stall on.

Most 3PLs are at rung 2. The distribution is weighted heavily toward operators who have done the discovery work — a register exists, vendors are tiered, questionnaire answers are consistent — and who have not yet converted any of that into contractual rights, because the contracts in question do not come up for renewal on the register's schedule. A much smaller group has the chain below its vendors named and evidenced, and a very small group keeps that picture current on a cadence.

Distribution of third-party logistics providers across the governance ladder

Illustrative distribution. The shape — a large Inventoried mode, a sharp fall after Contractually controlled — mirrors the third-party risk gap that named external research reports across industries; it is not a survey of 3PLs and should not be quoted as one.

Share of 3PLs

26% — 1 · Unmapped
34% — 2 · Inventoried (the plateau)
22% — 3 · Contractually controlled
13% — 4 · Chain-assured
5% — 5 · Continuously monitored

Source: Illustrative distribution, anchored to Verizon DBIR third-party findings and NIST supply chain risk guidance

The plateau at rung 2 has a structural cause rather than a motivational one. A register is built in weeks by a small team with no external dependency; contractual controls require a counterparty to agree, and the moment of maximum leverage — renewal — arrives on the vendor's calendar, not yours. Operators who close the gap do one specific thing: they sort the register by exposure, look up the renewal dates of the tier-1 entries, and treat those dates as the programme plan. Everything else follows, because a clause conceded at renewal costs nothing and the same clause requested mid-term costs a commercial concession.

The second cause is that the risk is genuinely borrowed. A 3PL's own security posture can be excellent while its exposure sits in a vendor's estate, and third-party involvement in breaches is rising fast enough that named research now treats it as a headline finding rather than a subsection. NIST's cyber supply chain risk management guidance (opens in a new tab) and the Cloud Security Alliance's Cloud Controls Matrix (opens in a new tab) both make the same structural point: controls that stop at your own boundary do not describe your risk. Neither framework was written for AI specifically, which is exactly why the four AI clauses further down this page have to be added on top rather than assumed inside an existing certification.

Tiering AI vendors by data exposure, not by spend

A route optimiser reading consignee addresses is not a chatbot. The tiering table, and the two axes that decide how much assurance each vendor earns.

Tier AI vendors by what they see and what they decide, because those two properties — not contract value, not vendor size — determine how much of your customer's exposure passes through them. A £30,000 route optimiser that reads consignee names and addresses and writes assignments into dispatch carries more of your customers' risk than a £300,000 platform whose AI feature summarises your own internal policy documents. Spend-based tiering, inherited from ordinary procurement, systematically over-governs the second and under-governs the first.

Tier	What it sees and decides	Typical logistics examples	Assurance depth	Review cadence
Tier 1 — customer-identifiable and decision-bearing	Consignee-level personal data or customer-commercial data, and the output changes what happens to freight	Route and stop-sequence optimisers, appointment and door scheduling, ETA engines shared with the end consignee, customs classification, driver scoring	Full AI schedule: training-use ban, performance floor, notification window, audit rights to sub-processors, named chain, segregation statement, rehearsed exit	Quarterly, plus on every change notice
Tier 2 — customer-commercial, advisory only	Customer rate, volume or lane data, but the output is a recommendation a human accepts or ignores	Rate and capacity prediction, lane benchmarking, spend analytics, quote drafting from customer emails	Training-use ban, named sub-processors, notification window, exit and deletion terms; performance floor optional	Semi-annually
Tier 3 — operational-internal, decision-bearing	No customer-identifiable data, but the output writes into the operation	Yard camera dwell detection, wave release, labour planning on the 3PL's own workforce data, replenishment triggers	Performance floor and rollback, worker-data terms where cameras or productivity metrics are involved, standard security attestation	Annually
Tier 4 — assistive, no customer data	Public or internal non-customer content only, advisory output	Assistants over internal policy and SOP documents, marketing content tools, code assistants on non-customer repositories	Register entry, acceptable-use rule, confirmation that customer data cannot be pasted in	On renewal
Tier 0 — undeclared and switched on	Unknown, because the feature arrived inside a platform already in the estate	AI assistants added to an existing TMS, visibility platform, customs tool or WMS by release note	Discovery first: establish what the feature sees before assigning a tier. Treat as tier 1 until proven otherwise	Immediate

AI vendor tiering for a 3PL. 'Assurance depth' is the minimum that tier earns; a vendor may qualify upward on either axis. Review cadence assumes the register is maintained by a named owner per tier-1 vendor.

Tier 0 deserves its own row because it is where most 3PL exposure actually lives. Nothing was procured, so nothing was assessed, and the feature's data reach is whatever the vendor's product decision made it. The rule that keeps this manageable is to treat an undeclared feature as tier 1 until the vendor answers three questions in writing: what customer data does the feature process, which sub-processor performs the inference, and is our data used to train anything beyond our own tenant. A vendor that will not answer those in writing has told you what tier it belongs in.

How much assurance does this vendor earn?

Plot each register entry on customer data exposure against decision authority. The quadrant sets the minimum control set — and only one of the four requires the full schedule, which is what makes the programme finite.

Operational autonomy

Yard, wave release, labour planning on your own data
Risk is operational, not contractual
Controls: performance floor, rollback, worker-data terms

Tier 1 — the full schedule

Routing, appointment booking, customs classification, shared ETAs
Both axes high: this is where the customer's exposure concentrates
Controls: every clause in the back-to-back table, plus a rehearsed exit

Low ceremony

Internal assistants, document summarisation over your own policies
Register entry and an acceptable-use rule
Cheap to govern; do not spend the programme here

The quiet quadrant

Extraction and classification that reads manifests but only suggests
Under-governed because nothing visible happens
Controls: full data terms and named chain; performance floor can be lighter

Decision authority — top: Writes into the execution record, bottom: Advisory — a human may ignore it

Customer data exposure — left: Internal and operational data only, right: Consignee-identifiable or customer-commercial

The bottom-right quadrant is where 3PLs are most often caught out. A document-extraction service reads commercial invoices, packing lists and delivery notes — some of the most sensitive customer-commercial material in the operation — and produces suggestions a clerk confirms. Because nothing executes automatically, it feels low-risk and gets governed like a productivity tool. In data terms it is a tier-1 relationship, and it is frequently the vendor that pushes the most customer content to an external model API. Grade the quadrant on what the vendor sees, not on how visible its output is.

The back-to-back table: what you promise, what you must hold

Every commitment in your customer's DPA needs a matching right in the vendor contract behind it. Nine rows where standard software paper leaves a 3PL exposed.

The contractual controls that matter are the ones that make your outward promises enforceable inward. A 3PL's customer contract is, read forwards, a specification of rights the 3PL must hold from every vendor in the chain — and ordinary software paper supplies almost none of them for AI specifically. The table below runs down the customer-side obligation, states the vendor-side right that must sit behind it, gives the 3PL-specific test that tells you whether the clause is real, and names what silence costs. This is not a procurement exercise: every row is negotiated at renewal against a vendor you are already using.

What you promise your customer	What your vendor contract must give you back-to-back	The 3PL-specific test	What silence costs
Customer data is processed only on the customer's documented instructions	An explicit prohibition on training shared, multi-tenant or other-customer models on customer data, with any permitted exception named, purpose-limited, time-limited and flowed down to sub-processors	Ask whether a model improved by your consignee data serves any other tenant. A 'no' that is not in the contract is a product roadmap, not a commitment	Your customer's lane volumes, rate history and delivery patterns improve a model their competitor rents next year
Sub-processors are authorised, listed and notified in advance of change	A named sub-processor list as a contractual annex, a minimum advance notice period for changes, and a right to object with a stated consequence	Ask for the list as a file. If it arrives as an email written that afternoon, there is no mechanism — only a person	You breach the authorisation clause in your own customer DPA without knowing the change occurred
The service performs to the standard the customer contracted for	A model performance floor in operational units — mean ETA error on a named lane set, address-match precision, field-level extraction accuracy, false-positive rate per shift — with the measurement method, the dataset and a restoration window	Ask which contractual event a degraded model triggers. If the only answer is the availability SLA, the model can be up and wrong indefinitely	Silent degradation across a multi-year term, discovered by a customer's OTIF report rather than by you
Personal data breaches are notified without undue delay so the customer can meet its 72-hour clock	A notification window measured in hours from the vendor's awareness, with a defined minimum content set and a named contact route that is not a support portal	Check that your vendor's window is materially shorter than your obligation to your customer. Equal windows leave you zero triage time	Your customer's regulatory clock starts before you know, and the failure to notify becomes your failure
The customer may audit, or receive evidence, of how its data is handled	Audit and inspection rights that expressly survive to sub-processors, plus an obligation to provide the sub-processor's own attestation where direct audit is impractical	Trace one audit right from your customer DPA to your vendor contract to the model provider's terms. Most chains break at the second hop	You accept a customer audit obligation you cannot discharge, and the gap surfaces during the audit itself
Customer data stays in the agreed locations and moves only under a valid mechanism	Named processing and storage regions per service, the transfer mechanism in use, and advance notice before any region changes	Ask where inference runs — not where the account is billed. Model APIs frequently process in a different region from the platform's data store	A transfer occurs outside your customer's agreed mechanism, and the standard contractual clauses in your customer's DPA no longer describe reality
Customer data is returned or deleted at the end of the relationship	Named export formats per data asset, a delivery window in days, a deletion window covering backups and any derived artefacts, and a written deletion attestation	Ask specifically about derived artefacts: embeddings, extracted fields, corrected addresses, tuned model weights. Standard deletion clauses cover the upload, not the derivative	You certify deletion to your customer on your vendor's word, with no attestation behind it
Customer data is kept separate from other customers'	A written segregation statement covering storage, inference and any model training or fine-tuning, distinguishing tenant-isolated from pooled processing	Ask the question in model terms, not storage terms. Tenant-isolated storage with a pooled model is a common and rarely disclosed configuration	You answer a customer's segregation question accurately about the database and inaccurately about the model
You are transparent about automated decisions affecting the customer's goods and people	Allocation of EU AI Act roles in writing — who is provider, who is deployer — and the information and technical access a provider needs from a component supplier	Check whether you white-label the vendor's AI into your own service. Under EU AI Act Article 25, putting your name on a high-risk system makes you its provider, with the provider's obligations	You inherit provider obligations by branding, having never done a conformity assessment or built the technical documentation

Back-to-back AI clauses for a 3PL. Left column: what your customer's contract already makes you promise. Middle: the right you must hold from your vendor for that promise to be enforceable. Right: what happens when the clause is absent — in every case a cost paid later, by someone who did not negotiate the contract.

Where that other processor fails to fulfil its data protection obligations, the initial processor shall remain fully liable to the controller for the performance of that other processor's obligations.
GDPR Article 28(4)

Three rows in that table are worth an extra note. The training-use row is the one vendors resist most and concede most often at renewal, because a purpose-limited exception — model improvement confined to your own tenant, for the term only — usually satisfies both sides. The transfers row is the one that most often invalidates an answer already given to a customer: the European Commission's standard contractual clauses (opens in a new tab) describe a specific route between named parties, and a vendor moving inference to a different region quietly makes your customer's annex wrong. An SCC annex naming an exporter, an importer and a described transfer is a factual representation, not a general permission, so the annex has to be revisited every time the chain moves. And the AI Act row is the one 3PLs discover late: Article 25 (opens in a new tab) provides that a distributor, importer, deployer or other third party is considered the provider of a high-risk AI system where it puts its own name or trademark on one already placed on the market — so a white-labelled optimiser makes the 3PL the provider, with the provider's obligations. The European Commission's AI Act pages (opens in a new tab) are the primary reference for which obligations attach where.

Write the floor in units your operation already reports
A quality floor expressed as model accuracy is unenforceable in practice, because nobody in the operation measures it. Expressed as mean ETA error in minutes on a named lane set, or field-level accuracy on commercial-invoice extraction, or address-match precision on a defined postcode sample, it becomes a number your own reporting already produces and a vendor cannot dispute after the fact.
Make the notification window shorter than your own obligation
Your customer, as controller, has 72 hours from awareness to notify its supervisory authority under GDPR Article 33 (opens in a new tab). A processor must notify the controller without undue delay. If your vendor's window equals your obligation, you have no triage, no assessment and no drafting time — so the vendor clause needs to be measured in hours, with a defined minimum content set so the first notification is useful rather than a placeholder.
Attach an attestation to the deletion clause
Deletion terms without a written attestation give you nothing to hand a customer. The attestation should name the data assets, the derived artefacts, the backup horizon and the date completion occurred. It costs a vendor almost nothing at signature and is close to unobtainable once a relationship has ended badly.
Anchor the security clauses to a framework, not to a description
Article 32 requires appropriate technical and organisational measures; the text itself (opens in a new tab) is deliberately non-prescriptive. Naming ISO/IEC 27001 (opens in a new tab) for the information security management system (ISMS) and ISO/IEC 42001 (opens in a new tab) for the AI management system (AIMS) turns a paragraph of adjectives into a scope you can ask to see and a certificate whose lapse is a contractual event. The ISMS certificate tells you the vendor runs security properly; the AIMS certificate is the one that speaks to how it governs models, and it is still rare enough that asking about it is itself a useful signal.

Assuring the chain below your vendor

Your vendor's model provider is your customer's problem too. The five-layer assurance stack, and which layer each rung of the ladder first requires.

Assuring the chain means obtaining, in writing and from a source you control, the identity and terms of every party below your direct vendor that processes customer data. That is a narrower job than it sounds and a harder one than it looks: narrow, because for most 3PLs it concerns four or five tier-1 relationships; hard, because the tier below your vendor was chosen by your vendor's engineering team, may have changed since you signed, and is frequently described to you in a summary rather than supplied as a document. The stack below is the set of artefacts that turns that description into evidence.

The assurance stack, layer by layer

Each layer is annotated with the rung that first requires it. A 3PL trying to answer a chain question from the register alone is attempting rung 4 with rung 2 artefacts — which is why the answer takes six weeks and still contains a 'we believe'.

Register layer
Stage 2+
- AI vendor inventoryEvery vendor whose product applies AI to customer data
- Data-exposure tierWhat it sees and what it decides, per the tiering table
- Named internal ownerOne person accountable per tier-1 vendor
- Renewal dateThe column that turns the register into a plan
→
Contract layer
Stage 3+
- AI scheduleThe nine back-to-back rows, appended to the master agreement
- Performance floorIn ETA minutes, extraction accuracy, match precision
- Notification windowHours from vendor awareness, with a minimum content set
- Exit and deletion termsExport format, window, derived artefacts, attestation
→
Chain layer
Stage 4+
- Named sub-processor listAs a contractual annex or a published, subscribable page
- Model provider termsRead by the 3PL, not summarised by the vendor
- Processing location and mechanismWhere inference runs, and under which transfer route
- Change-notice routeMinimum advance period and a right to object
→
Evidence layer
Stage 4+
- Attestation librarySOC 2 Type 2 reports, ISO certificates, with scope noted
- Segregation statementStorage, inference and training, stated separately
- Performance evidenceThe last floor test, its dataset and its result
- Customer-facing chain mapOne page, dated, issued with every tender response
→
Monitoring layer
Stage 5+
- Change-notice intakeMonitored route, named owner, review inside the objection window
- Floor re-test cadenceFresh data on a schedule, not acceptance at signature
- Viability signalsOwnership change, funding, support responsiveness, roadmap drift
- Exit rehearsalOne tier-1 wind-down tabletop per year, with the attestation produced

Pipeline described

Register layer (stage 2+) — AI vendor inventory: Every vendor whose product applies AI to customer data; Data-exposure tier: What it sees and what it decides, per the tiering table; Named internal owner: One person accountable per tier-1 vendor; Renewal date: The column that turns the register into a plan
Contract layer (stage 3+) — AI schedule: The nine back-to-back rows, appended to the master agreement; Performance floor: In ETA minutes, extraction accuracy, match precision; Notification window: Hours from vendor awareness, with a minimum content set; Exit and deletion terms: Export format, window, derived artefacts, attestation
Chain layer (stage 4+) — Named sub-processor list: As a contractual annex or a published, subscribable page; Model provider terms: Read by the 3PL, not summarised by the vendor; Processing location and mechanism: Where inference runs, and under which transfer route; Change-notice route: Minimum advance period and a right to object
Evidence layer (stage 4+) — Attestation library: SOC 2 Type 2 reports, ISO certificates, with scope noted; Segregation statement: Storage, inference and training, stated separately; Performance evidence: The last floor test, its dataset and its result; Customer-facing chain map: One page, dated, issued with every tender response
Monitoring layer (stage 5+) — Change-notice intake: Monitored route, named owner, review inside the objection window; Floor re-test cadence: Fresh data on a schedule, not acceptance at signature; Viability signals: Ownership change, funding, support responsiveness, roadmap drift; Exit rehearsal: One tier-1 wind-down tabletop per year, with the attestation produced

Step-by-step insights

Register layer — the renewal date is the most valuable column: Registers are usually built for completeness and then used for reporting, which wastes them. The column that changes outcomes is the renewal date, because every AI clause in the contract layer is cheap at renewal and expensive mid-term. Sorting the register by exposure and then by renewal turns an amorphous governance ambition into a dated sequence of four or five negotiations, each of which has a natural moment. Operators who do this move from rung 2 to rung 3 in one contract cycle; operators who wait for vendors to offer better terms do not move at all.
Contract layer — a schedule, not a rewrite: The mistake is treating this as a renegotiation of the master agreement, which invites a long legal engagement and often stalls. The workable shape is a short AI schedule appended to the existing contract, covering only what is AI-specific: training use, performance floor, notification window, chain disclosure, segregation, exit of derived artefacts. Everything else in the agreement stays untouched. Vendors accept schedules far more readily than amendments, and a schedule is portable across your estate — the same document goes to every tier-1 vendor, which is what makes the fourth negotiation faster than the first.
Chain layer — read the model provider's terms yourself: The single most informative hour in this whole discipline is reading the terms of the model or infrastructure provider your vendor calls. You will typically learn three things your vendor's summary omitted: whether inference data is retained and for how long, whether an opt-out governs any service-improvement use, and which region actually processes the request. Some providers make this easy — AWS, for instance, publishes its sub-processor list and states it will update the page at least 30 days before engaging a new sub-processor, with an email subscription for changes. Where a provider publishes, subscribe. Where it does not, the obligation has to come through your vendor's contract.
Evidence layer — read the scope section, not the logo: An attestation is only as useful as its scope. A SOC 2 Type 2 report names the systems, the trust services criteria and the period it covers, and it is common for the AI component of a platform to sit outside the boundary described. The same applies to ISO/IEC 27001 certificates, whose statements of applicability define what was assessed. Record the scope alongside the certificate in your library, because the question a customer's auditor asks is not whether the vendor is certified but whether the service you use is inside the certified boundary.
Monitoring layer — four jobs, not a programme: This layer fails when it is designed as a governance function and succeeds when it is designed as four recurring jobs with owners: process the change notices, re-test the floors, review the viability signals, rehearse one exit. Attach each to something already in the calendar — the quarterly business review, the annual attestation refresh, the renewal cycle — because a standing forum competing with peak season loses. The measure of this layer is not meetings held; it is whether the last sub-processor change notice was reviewed inside the customer objection window.

The layer most often skipped is the evidence layer, and skipping it is what makes chain assurance feel unaffordable. Without a maintained library, every customer question triggers a fresh round of requests to vendors, and the same SOC 2 report gets chased four times a year by four different people. With one, the marginal cost of the next questionnaire is an extract. The AICPA's SOC 2 material (opens in a new tab) is the reference for what those reports do and do not cover, and the Shared Assessments programme (opens in a new tab) maintains the standardised third-party questionnaires that many large shippers now base their own on — worth reading before you write your answers, because answering the standard question set once is cheaper than answering forty bespoke ones.

Answering the customer AI question honestly and repeatably

Nine questions customers now ask, what each is really testing, and the artefact that answers it in an extract rather than an essay.

Answer the customer AI question from artefacts, not from drafting. The 'do you use AI on our data' question has moved in two years from an occasional curiosity to a scored section in tender responses and a standing item in annual reviews, and the operators who handle it well have all done the same thing: they decided what the true answer is once, wrote it down as a set of maintained artefacts, and now assemble responses from those rather than composing a fresh account per account. That consistency is a governance control in its own right — divergent answers across customers is one of the quickest routes from an assurance exercise to a contractual dispute.

What the customer asks	What they are really testing	The artefact that answers it	Stack layer
Do you use AI on our data?	Whether you know. A vague answer reads as an unmapped estate, whatever the words say	Register extract filtered to that customer's contracts, listing system, vendor, data seen and decision influenced	Register
Is our data used to train models?	Whether a competitor benefits from their operational history	The training-use clause itself, plus a segregation statement covering storage, inference and training separately	Contract and evidence
Who are your sub-processors for these systems?	Whether you can see past your own vendor	Named sub-processor list per tier-1 vendor, with the change-notice mechanism stated	Chain
Where is our data processed?	Whether the transfer annex in their own DPA is still accurate	Processing and inference locations per service, with the transfer mechanism in use	Chain
What happens if the model is wrong?	Whether quality is contractual or aspirational	The performance floor, its measurement method, and the result of the most recent test	Contract and evidence
How quickly will you tell us about an incident?	Whether your clock leaves them time to meet their own 72-hour obligation	The vendor notification window, the internal triage route, and the customer contact path	Contract
Can we audit you — and your vendors?	Whether the audit right you granted them is actually exercisable	The audit clause traced through to sub-processors, plus the attestation library where direct audit is impractical	Contract and evidence
Is our data mixed with our competitors'?	The commercial question underneath the technical one	The segregation statement in model terms — tenant-isolated storage with a pooled model is a different answer from full isolation	Evidence
What happens to our data if we leave, or if the vendor does?	Whether exit is a plan or a hope	Export formats, deletion window covering derived artefacts, deletion attestation, and the date of the last exit rehearsal	Contract and monitoring

The customer assurance question set for a 3PL. Every row's artefact should exist before the question arrives; the right-hand column is where it lives in the assurance stack above.

Two answers deserve care because they are where honest operators most often overstate. The first is training use: a truthful answer distinguishes between training a shared model, fine-tuning a tenant-specific model, and using data transiently for inference with no retention — three materially different positions that a single sentence tends to blur. The second is segregation: tenant-isolated storage is common and is not the same as model isolation, and a customer asking about competitors is asking about the model. Both answers are easier to give well when the underlying clause was negotiated deliberately, which is the argument for the back-to-back table rather than a communications exercise. The ICO's AI guidance hub (opens in a new tab) and the IAPP's resource library (opens in a new tab) are both useful for keeping the language precise.

The customer assurance pack: readiness checklist

Eight artefacts. If you cannot produce all eight from a file today, your next large customer questionnaire is a project rather than an extract. Tick as you go — this list works without JavaScript.

A register extract can be filtered to a single customer's contractsNot a whole-estate list you then edit by hand for each account.
Every tier-1 vendor contract contains a training-use position in writingA prohibition, or a named exception that is purpose-limited and time-limited.
A named sub-processor list exists for every tier-1 vendorAs a contractual annex, or a published page you are subscribed to.
Processing and inference locations are recorded per service
A model performance floor exists, with a dated test result behind itIn operational units your own reporting already produces.
The vendor incident notification window is shorter than your obligation to your customerMeasured in hours from vendor awareness, with a minimum content set.
A segregation statement distinguishes storage, inference and trainingTenant-isolated storage with a pooled model is a different answer.
Exit terms cover derived artefacts and produce a written deletion attestationEmbeddings, extracted fields, corrected addresses, tuned weights.

0 of 8 ticked

Nothing ticked — and that is the honest starting point

Almost every 3PL starts here, because none of these artefacts is produced by ordinary procurement. Do not start with the contracts: start with the register, filtered so it can be sliced per customer. Every other item on this list is assembled from it, and the first one takes about two weeks.

Start with the register

What the chain looks like in public

Three publicly documented examples — a platform wind-down, a published sub-processor mechanism, and what a security attestation does and does not cover — read against the ladder.

The public record on AI vendor governance is thin on 3PL programmes and rich on the artefacts those programmes depend on. The three examples below are chosen for that reason: each one is documented by the organisation itself, and each demonstrates a different rung of the ladder. None is an Atomic Loops engagement, and the first is deliberately not an AI system — it is the clearest public test in logistics of what happens when a platform many operators had integrated is withdrawn.

Three public examples read against the ladder

Facts as published by the organisations themselves; verify against the linked source before reusing them. The card images are generated industry scenes from our media library, not operator photography, and no endorsement by any named organisation is implied.

Illustrative scene: logistics professionals reviewing a global network map on a shared digital table

A.P. Moller – Maersk and IBMGlobal carrier and technology partnership · TradeLens platform24

Challenge: TradeLens was announced in 2018 and jointly developed by IBM and GTD Solution, a division of Maersk, as an open industry platform for global trade digitisation. Forwarders, 3PLs, carriers, ports and customs authorities integrated with it, which made each participant's operational data flows partly dependent on a platform none of them controlled.
Approach: In November 2022 Maersk and IBM announced the decision to withdraw the TradeLens offerings and discontinue the platform, stating that while a viable platform had been developed, the full global industry collaboration it required had not been achieved and it had not reached the commercial viability needed to continue as an independent business.
Reported outcome: Maersk stated the intent was for the platform to go offline by the end of the first quarter of 2023, and that all parties involved would ensure customers were attended to without disruption to their businesses — a wind-down window measured in months for organisations that had built integrations against it.; What it shows about the curveViability is a governed attribute, not a market accident, and the ladder's top rung exists because of episodes like this. Participants whose contracts named export formats, deletion terms and a transition window treated the announcement as a planned migration; those without discovered that the exit terms they needed were the ones they had never negotiated. Rehearsing one wind-down a year is what converts a four-month notice from a crisis into a project.

Maersk press release — TradeLens to be discontinued (opens in a new tab)

Illustrative scene: analysts reviewing shipment documents and a network diagram beside a data centre corridor

Amazon Web ServicesCloud and model provider · the tier below most logistics AI vendors34

Challenge: A 3PL's chain assurance depends on a tier it has no contract with. Where a logistics AI vendor runs inference on a hyperscaler, the 3PL needs to know which entities process customer data, in which regions, and what happens when that list changes — none of which its own vendor agreement necessarily supplies.
Approach: AWS publishes a sub-processor page setting out the entities engaged under its data processing addendum, grouped by infrastructure, service support and service improvement, with processing locations recorded. The page states that AWS will update it at least 30 days before engaging a new sub-processor, and that customers who subscribe for updates will be notified by email of changes.
Reported outcome: For a 3PL, that mechanism converts the deepest link in the chain from an assertion into a subscribable feed: the list can be read directly rather than summarised by the vendor, and a change arrives with enough notice to be assessed against affected customer DPAs and passed on inside a customer's objection window.; What it shows about the curveRung 4 is reachable wherever a tier publishes. Where a provider maintains a named list with advance change notice, subscribe to it and record it in the chain map; where a provider does not, the same visibility has to be bought contractually from the vendor in front of it. The asymmetry between those two situations is a legitimate input to vendor selection at renewal.

AWS sub-processors (opens in a new tab)

Illustrative scene: a supply chain control tower with a live network map and freight moving beyond the glass

project44Supply chain visibility and AI orchestration vendor · a typical 3PL tier-1 relationship33

Challenge: Visibility platforms sit squarely in tier 1 for a 3PL: they ingest shipment-level data including consignee detail, and their newer products apply AI agents to that data across carrier outreach and exception resolution. A 3PL's customers will ask what assurance exists behind them.
Approach: project44's published security page states that its control procedures have been verified in a SOC 2 Type 2 report with an annual audit by an independent third party, that it is ISO 27001 certified, and that it follows GDPR where it operates — with the SOC 2 report available on request and a trust centre for supporting material.
Reported outcome: That is a stronger published position than many vendors in the category offer, and it answers a specific question well: whether the vendor's information security controls have been independently examined. A 3PL can record the certification and the report scope in its attestation library and reuse both across customer questionnaires.; What it shows about the curveSecurity attestation and AI assurance are different objects, and conflating them is the classic rung-3 error. A SOC 2 Type 2 report and an ISO 27001 certificate tell you the controls were examined; neither states whether your consignee data trains a shared model, what happens when an ETA model degrades, or which sub-processor performs inference. Those three answers come only from the AI schedule you negotiate on top.

project44 — security (opens in a new tab)

Read together, the three examples describe the same boundary from different sides. A vendor can be well run, independently audited and still be withdrawn; a provider can publish an exemplary chain artefact and still leave the AI-specific questions to the tier above it; and an attestation can be entirely genuine and entirely silent on the thing your customer is asking about. None of that is a criticism of the organisations involved — it is the structure of the market a 3PL is buying into, and the reason governance has to be organised around the chain rather than around any single supplier's credentials.

A 90-day plan: one route optimiser, fully governed

The rung 2 → rung 3 move made concrete on a single tier-1 vendor — the optimiser that reads consignee addresses and writes into dispatch. Contains no new technology.

Governing one vendor properly takes about 90 days; governing the estate takes years, and trying to do the second first is why most programmes stall at the register. The plan below runs the transition on a specific, common 3PL problem: a route and stop-sequence optimiser that reads consignee names and addresses from the TMS, returns assignments that are written back into dispatch, and operates under a contract that was signed before the vendor had a model. Everything in the quarter is discovery, negotiation and evidence — there is no new technology in it at all.

Rung 2 to rung 3 on one tier-1 AI vendor, in one quarter

One vendor, one named owner, one customer contract used as the reference specification. If a phase overruns, narrow the scope — one customer, one region — rather than extending the plan.

Days 1–15
Establish what the vendor actually sees
Take the optimiser and write down, from the integration rather than the sales material, exactly which fields leave your TMS: consignee name, address, contact number, time windows, special instructions. Establish which customer contracts those shipments sit under, and pull the DPAs. Name one internal owner. Then send the vendor three written questions: which sub-processor performs inference, in which region, and is our data used to train anything beyond our own tenant.
A field-level data map and three answers in writing
Days 16–40
Use one customer DPA as the specification
Take your largest affected customer's DPA and mark every clause that implies a right you must hold from the vendor: sub-processor authorisation, notification timing, audit, location, retention, deletion. Turn the marked list into a two-page AI schedule using the back-to-back table on this page. Keep it portable — this document will go to your other tier-1 vendors afterwards, so resist customer-specific drafting.
A portable AI schedule mapped to a real customer obligation
Days 41–70
Negotiate at the renewal, and define the floor
Table the schedule at the renewal or amendment point. Expect the training-use prohibition and the sub-processor annex to be conceded relatively easily and the performance floor to take the longest, because it requires agreeing units, a measurement method and a dataset. Use units your own reporting already produces — mean ETA error in minutes on a named lane set, address-match precision on a defined sample — so neither side has to build a measurement capability to enforce the clause.
A signed schedule with a measurable floor and a remedy
Days 71–90
Produce the evidence and answer the customer
Assemble the pack for this one vendor: register extract, signed schedule, named sub-processor list, processing locations, segregation statement, the first floor test result, exit and deletion terms. Then use it — proactively send the affected customer a one-page chain map rather than waiting for the questionnaire. Subscribe to the vendor's and the model provider's change notices, and put the next floor test in the calendar.
A dated chain map issued to a customer, and a monitored change-notice route

The order matters

Data map before contract drafting
Every hour spent drafting before you know which fields leave the building is wasted, because the schedule's scope definition depends on it. A field-level map also settles the tier argument immediately: once a room has seen that consignee names and addresses leave the estate, the tier-1 classification stops being contested.
Customer DPA before vendor schedule
Drafting the vendor schedule from first principles produces a document your own customer obligations do not need and omits ones they do. Working backwards from a real DPA guarantees the two documents are the same shape, which is the entire point of back-to-back terms.
Renewal before request
The same clause costs nothing at renewal and a commercial concession mid-term. If the renewal is nine months away, use the intervening time on the items that need no counterparty — the map, the schedule, the register — and hold the negotiation for the moment you have leverage.
One vendor before the estate
The schedule, the floor definition and the pack template are all reusable; the negotiation is not. Doing one vendor end to end produces four reusable artefacts and a realistic estimate for the other three, which is a far better basis for a programme plan than a governance framework written in advance.

Vendor viability and the failure modes that break the chain

Governance regresses quietly. Five failure modes account for almost all of it, and four of the five are discovered by a customer rather than by the 3PL.

Vendor governance regresses without anyone deciding to let it, because the conditions that made a chain map true stop holding on someone else's schedule. A vendor changes its model provider, a certificate lapses, a founder sells, a floor stops being tested. None of those events produces an alert unless somebody built one, and four of the five failure modes below are typically discovered by a customer's annual review rather than by the operator. The prevention column is deliberately cheap: each one is a recurring job, not a programme.

Likelihood: highImpact: high

The vendor changes its model provider and nobody reads the notice

A sub-processor change notice arrives at a shared mailbox or a release-notes page and is never routed. The chain map, the customer answers built on it and the transfer annex in the customer's own DPA all become quietly wrong on the same day, and the discrepancy surfaces at the customer's next audit as a written representation that was not true.

PreventionOne monitored intake route for all vendor change notices, a named owner, and a standing review against the customer DPAs that restrict location or authorisation.

Likelihood: highImpact: medium

The model degrades and the availability SLA never fires

ETA error widens after a carrier-mix change, or extraction accuracy falls after a document-format change at a major customer. The service is fully available throughout, so no contractual event occurs, and the degradation is attributed to operational noise until a customer's OTIF or clearance reporting makes it visible.

PreventionA performance floor in operational units with a scheduled re-test on fresh data — quarterly for tier 1 — rather than acceptance at signature.

Likelihood: mediumImpact: high

The vendor is acquired and the terms change at renewal

An acquisition rarely breaks the current contract and frequently changes what the next one offers: new standard terms, a different training-use position, a consolidated sub-processor list, a repriced tier. A 3PL that has not tracked ownership discovers this three weeks before a renewal, with no second source and no time to build one.

PreventionTrack ownership, funding and support responsiveness as named viability signals per tier-1 vendor, reviewed quarterly, and keep one credible alternative warm.

Likelihood: mediumImpact: medium

The attestation lapses or its scope moves

A SOC 2 report covers a period and an ISO certificate covers a scope, and both can quietly stop covering the service you actually use — particularly where an AI component was added after the assessment boundary was drawn. The library still contains a valid-looking document and the customer's auditor reads the scope section that nobody else did.

PreventionRecord report period and scope alongside every attestation, with a diary entry at expiry and a check that the AI service sits inside the assessed boundary.

Likelihood: lowImpact: high

The product is withdrawn and exit was never rehearsed

A wind-down announcement gives months, not years, and the work it triggers — export, format conversion, cutover, deletion, customer communication — has never been performed. Operators discover at that point which of their exit terms were drafted for software rather than for models, and that derived artefacts were never in scope.

PreventionOne tabletop exit rehearsal a year on a tier-1 vendor, covering export format, cutover, deletion of derived artefacts and the attestation, with customer comms drafted in advance.

30%

of breaches involve a third party — double the previous year's share

Verizon 2025 DBIR

30 days

advance notice AWS states it gives before engaging a new sub-processor

AWS, published sub-processor page

~4 months

from the TradeLens discontinuation announcement to the stated platform offline date

Maersk, reported

€10M / 2%

GDPR ceiling for breaching processor and sub-processor obligations under Articles 25–39

GDPR Article 83(4)

The penalty figures are worth stating precisely, because the two GDPR tiers apply to different failures and 3PLs routinely quote the wrong one. Article 83(4) (opens in a new tab) sets a ceiling of €10 million or 2% of total worldwide annual turnover, whichever is higher, for infringements of the obligations of controllers and processors under Articles 8, 11, 25 to 39 — which is where Article 28's sub-processor duties sit. Article 83(5) sets the higher €20 million or 4% ceiling for breaches of the basic principles, which is where a vendor training on customer data without a lawful basis would land. Both are in the Regulation's own text (opens in a new tab), and both attach to the 3PL as processor regardless of which link in the chain caused the failure. The EU AI Act runs a separate ladder on top: Article 99 (opens in a new tab) sets fines of up to €35 million or 7% of worldwide annual turnover for the prohibited practices in Article 5, and up to €15 million or 3% for breaches of operator obligations including a provider's duties under Article 16 — the duties a 3PL inherits by branding a vendor's high-risk system as its own.

Two further frameworks are worth wiring into the same cadence rather than running separately. The NIST AI Risk Management Framework (opens in a new tab) gives a vocabulary for third-party AI risk that maps cleanly onto the register and the floor, and is free to adopt. And for logistics specifically, ISO 28000 (opens in a new tab) security management for the supply chain already requires that outsourced processes affecting security are identified and controlled — which is the same obligation the chain layer discharges, expressed in the language your existing certification audit already speaks. Where a 3PL holds ISO 28000, the AI vendor register belongs inside that management system rather than beside it.

Glossary

Hover a term for its definition — or expand the map full screen. The full definitions are written out below.

Sub-processor: A processor engaged by another processor to carry out processing on the controller's behalf. For a 3PL, every AI vendor touching customer data is one — and under GDPR Article 28(4) the 3PL remains fully liable to the customer for that sub-processor's performance.
Back-to-back terms: Vendor contract clauses drafted so that every obligation the 3PL owes its customer has a matching right the 3PL holds against its vendor. The absence of back-to-back terms is the definition of an uncovered promise.
Data-exposure tier: The register classification that sets how much assurance a vendor earns, based on what customer data its AI sees and how much authority its output has over freight — never on contract value.
Training-use prohibition: A contractual bar on using customer data to train, fine-tune or improve any shared, multi-tenant or other-customer model, with any permitted exception named, purpose-limited, time-limited and flowed down to sub-processors.
Model performance floor: A contractual quality threshold expressed in operational units — mean ETA error, address-match precision, field-level extraction accuracy — with an agreed measurement method, dataset, restoration window and remedy. The clause an availability SLA cannot substitute for.
Segregation statement: A written statement of whether a customer's data is isolated at storage, at inference and at training, treated as three separate questions. Tenant-isolated storage combined with a pooled model is a common configuration and a different answer.
Chain map: The one-page, dated artefact naming every party below the 3PL that processes a customer's data — vendor, model or infrastructure provider, processing location, transfer mechanism and change-notice route.
Change notice: A vendor's advance notification that it intends to add or replace a sub-processor. It is the only routine early warning the chain produces, and its value depends entirely on arriving somewhere monitored inside the customer's objection window.
Deletion attestation: A written confirmation from a vendor that named data assets and derived artefacts — embeddings, extracted fields, corrected addresses, tuned weights — have been deleted, including from backups, with the date completion occurred.
Provider and deployer: The EU AI Act's two principal roles. A 3PL is normally a deployer of a vendor's AI system, but under Article 25 becomes its provider — inheriting the provider's obligations — where it places the system on the market under its own name or trademark.
Attestation scope: The systems, criteria and period a SOC 2 report or ISO certificate actually covers. Recording the scope alongside the certificate matters more than holding it, because AI components are frequently outside a boundary drawn before they existed.
Vendor viability: The likelihood that a vendor continues to operate the product you depend on. Governed through named signals — ownership change, funding, support responsiveness, roadmap drift — and priced through exit terms rehearsed while the relationship is healthy.

Frequently asked questions

The questions 3PL commercial, security and operations teams ask most often when they start governing the AI in their vendor estate.

Is a 3PL really liable for what its AI vendor's model provider does?

Yes, to its customer. GDPR Article 28(4) provides that where a processor engages another processor and that other processor fails to fulfil its data protection obligations, the initial processor remains fully liable to the controller for the performance of those obligations. In practice this means a customer's claim runs to the 3PL rather than past it, whichever link failed. The 3PL's protection is contractual recourse against its own vendor, which only exists if the AI schedule was negotiated before the incident.

How do we tier AI vendors if almost all of them touch customer data?

Use two axes rather than one. Data exposure asks what the system sees: consignee-identifiable data and customer-commercial data are the high end, internal operational data the low end. Decision authority asks what the output does: writing into dispatch or setting a customs code is high, producing a suggestion a clerk confirms is low. Only vendors high on both need the full schedule, which is usually four or five relationships out of dozens. The rest need a register entry and a proportionate subset of clauses.

What are the four AI clauses that matter most in a vendor contract?

A training-use prohibition on customer data, with any exception named and time-limited. A model performance floor in operational units, with an agreed measurement method and a remedy — because an availability SLA never fires for a model that is up and wrong. An incident notification window measured in hours from vendor awareness, short enough to leave you triage time inside your customer's 72-hour clock. And audit rights that expressly survive to sub-processors. Standard software paper contains none of the four.

A vendor says it is SOC 2 Type 2 and ISO 27001 certified. Is that enough?

It is valuable and it is narrow. Both attest that the vendor's stated information security controls were examined and operated over a defined period and scope. Neither states whether your consignee data trains a shared model, what happens when an ETA model degrades, or which sub-processor performs inference. Record the certificate and, more importantly, its scope, then negotiate the AI-specific terms on top. Treating an attestation as the whole answer is the most common way a rung-3 programme convinces itself it is at rung 4.

How do we find out who our vendor's sub-processors are?

Ask for the list in writing and expect one of three responses. Some providers publish a maintained page with an advance-notice subscription — AWS, for example, states it will update its sub-processor page at least 30 days before engaging a new sub-processor and will email subscribers about changes. Some supply a list on request under the contract. Some cannot answer, which is itself the finding. Where a tier publishes, subscribe and record it in the chain map; where it does not, buy the visibility contractually from the vendor in front of it.

Could our customer's data be improving a model their competitor uses?

It is possible wherever a vendor's value proposition is network-wide learning, which is common in visibility, rate prediction and benchmarking products. The correct handling is neither denial nor silence: obtain a written statement of what is pooled at storage, at inference and at training, decide with the customer whether that trade is acceptable for their data, and record the decision. Customers tolerate a disclosed trade-off far better than they tolerate discovering one in a vendor's marketing material during an audit.

How should we answer a customer asking whether we use AI on their data?

From artefacts rather than drafting, and identically for every customer. The credible answer is a register extract filtered to their contracts, naming the systems, the vendors, the data seen and the decisions influenced, accompanied by the training-use position, the named sub-processor chain, the processing locations and the exit terms. Consistency matters as much as content: divergent answers across accounts is one of the fastest routes from a routine assurance exercise to a contractual dispute, because it suggests the answers are being composed rather than reported.

What is a model performance SLA, and what should a breach entitle us to?

It is a quality floor stated in your own operational units — mean ETA error on a named lane set, address-match precision on a defined sample, field-level accuracy on commercial-invoice extraction — with the measurement method and dataset agreed in the contract. A breach should entitle you to a restoration window with an obligation to remediate at the vendor's cost, service credits that are not the only remedy, and a termination right if the floor is not recovered. Without a floor, degradation produces no contractual event at all.

When is the right time to renegotiate AI terms with an existing vendor?

At renewal, and the register's most valuable column is therefore the renewal date. The same clause that costs nothing when a vendor is competing to retain the account costs a commercial concession mid-term. If the renewal is months away, spend the interval on everything that needs no counterparty — the field-level data map, the portable AI schedule, the register, the customer DPA mark-up — so that the negotiation itself is a single meeting rather than the start of the work.

Does the EU AI Act change our position as a 3PL using a vendor's AI?

It can change your role. A 3PL is normally a deployer of a vendor's system, but Article 25 provides that a distributor, importer, deployer or other third party is considered the provider of a high-risk AI system where it puts its own name or trademark on one already on the market, or substantially modifies it, or changes its intended purpose so it becomes high-risk. White-labelling a vendor's optimiser into your own branded service is exactly that situation, and it brings the provider's obligations with it.

What should our exit terms with an AI vendor actually cover?

Four things standard software exit clauses miss. Named export formats per data asset, with a delivery window in days rather than 'on request'. A deletion window that explicitly covers derived artefacts — embeddings, extracted fields, corrected addresses, tuned model weights — not just the data you uploaded. A written deletion attestation naming the assets and the date. And transition assistance priced at signature rather than quoted at exit, which is the moment you have least leverage in the relationship.

How do we watch vendor viability without building a risk function?

Four named signals per tier-1 vendor, reviewed quarterly alongside something already in the calendar: ownership or funding change, support responsiveness against the contracted times, roadmap drift away from the capability you bought, and any change in the published sub-processor or certification position. Then rehearse one exit a year. Logistics has a clear public precedent — Maersk and IBM announced the TradeLens wind-down in November 2022 with the platform to go offline by the end of the first quarter of 2023 — and a rehearsed exit turns that kind of notice into a project.

About the author

Atomic Loops Engineering

Industrial AI practice

Atomic Loops builds production AI systems for manufacturing, logistics and energy operators — forecasting, routing, document extraction and decision support running against live operational data inside the TMS and WMS layer. A large share of that work sits behind a 3PL's customer contract, so vendor registers, back-to-back data terms and customer evidence packs are engineering deliverables in our logistics practice, not paperwork bolted on afterwards.

· Production AI deployments delivered under 3PL customer contracts and their data processing agreements
· AI vendor registers, data-exposure tiering and back-to-back schedules built with operator legal and security teams
· Customer assurance packs — sub-processor chains, model performance evidence, exit and deletion attestations
· 26 cited sources on this page

Sources

Logistics industry practiceProduction AI systems Atomic Loops has built for freight, warehousing and last-mile operators — including work delivered under 3PL customer contracts.AI adoption and maturity curve in logisticsWhere the capability you are governing sits on the adoption curve, and which KPIs prove it is maturing rather than merely running.AI readiness and transformation roadmap for logisticsThe sequencing decisions — build, buy or partner — that determine how much of your AI estate you will need to govern through someone else's contract.

Find out what your chain actually looks like — then fix the weakest link

We run the assessment with your commercial, security and operations leads, mark your largest AI vendor agreement against the back-to-back table on this page, and leave you with a costed 90-day plan for your weakest dimension. You keep the mark-up and the plan whether or not we build anything.

Book a vendor governance review See our logistics work

Published 14 August 2026 · Last updated 14 August 2026

Key takeaways

Abbreviations used on this page

Score how you govern your AI vendors

What governing AI vendors at a 3PL actually means

The five rungs in detail

Unmapped

Inventoried

Contractually controlled

Chain-assured

Continuously monitored

Where 3PLs actually sit on the ladder

Tiering AI vendors by data exposure, not by spend

The back-to-back table: what you promise, what you must hold

Assuring the chain below your vendor

Register layer

Contract layer

Chain layer

Evidence layer

Monitoring layer

Answering the customer AI question honestly and repeatably

What the chain looks like in public

A 90-day plan: one route optimiser, fully governed

The order matters

Vendor viability and the failure modes that break the chain

The vendor changes its model provider and nobody reads the notice

The model degrades and the availability SLA never fires

The vendor is acquired and the terms change at renewal

The attestation lapses or its scope moves

The product is withdrawn and exit was never rehearsed

Glossary

Frequently asked questions

Is a 3PL really liable for what its AI vendor's model provider does?

How do we tier AI vendors if almost all of them touch customer data?

What are the four AI clauses that matter most in a vendor contract?

A vendor says it is SOC 2 Type 2 and ISO 27001 certified. Is that enough?

How do we find out who our vendor's sub-processors are?

Could our customer's data be improving a model their competitor uses?

How should we answer a customer asking whether we use AI on their data?

What is a model performance SLA, and what should a breach entitle us to?

When is the right time to renegotiate AI terms with an existing vendor?

Does the EU AI Act change our position as a 3PL using a vendor's AI?

What should our exit terms with an AI vendor actually cover?

How do we watch vendor viability without building a risk function?

About the author

Sources

Related reading

Find out what your chain actually looks like — then fix the weakest link