A client walked me through their AI governance last spring and it was, honestly, good work. Approved tool list. Data classification rules about what could go into a prompt. A review standard for anything AI-assisted that reached a customer or a regulator. Training completed by ninety-some percent of staff. They were ahead of most of the organizations I see.
Then I asked what the integrator building two of their three workstreams was doing. Nobody in the room knew. Not "they're compliant" and not "they're not" — nobody had asked. The contract had been signed eighteen months earlier, and it described deliverables, rates, and service levels. It said nothing about how the work would be produced, because at the time there was no reason it would need to.
That's the gap. Most enterprise AI policy was written to govern employees, and most enterprise work isn't done by employees. It's done by integrators, staff-augmentation partners, offshore delivery centers, boutique specialists, and their subcontractors. Every one of those organizations is under the same pressure yours is to deliver faster with fewer people, and they are responding to it exactly the way your own staff did — which is to say, before anyone formally approved it.
What you actually bought
Ask a vendor whether they use AI on your engagement and you'll usually get a confident yes with reassuring adjectives. That answer isn't useful, because the question is wrong. Three much narrower questions get you somewhere.
1. Where does your data go?
Your requirements, your architecture, your defect logs, your incident write-ups. If a contractor is pasting them into a consumer tool on a personal account, your data classification policy has been enforced right up to the boundary of the people who touch the most sensitive material. This is shadow AI again, except you can't see it, you can't survey for it, and you have no administrative visibility into the account it's running under.
2. Who reviewed it before it reached you?
Not whether a review exists — every vendor has a QA step on the org chart. Whether the reviewer has the domain knowledge to catch a plausible-sounding error in your environment. A generated integration spec that reads beautifully and assumes a system behavior that hasn't been true since your last upgrade will pass a generic quality gate without a flicker. That's the rubber-stamp review operating one company removed from you.
3. Can they reconstruct it?
Six months from now, when a design decision turns out to matter, can the vendor show you what the artifact was built from? Or does the trail end at a deliverable and a contractor who rolled off in March? Your chain of custody is only as strong as the weakest link in the delivery chain, and the weakest link is almost always outside your walls.
You can outsource the labor. You can outsource the tooling. You cannot outsource the consequences of how the work was produced — those arrive at your steering committee with your name on them, regardless of whose badge made the artifact.
The frameworks saw this coming
This isn't a novel concern I'm inventing for a blog post. NIST's Generative AI Profile (AI 600-1) names "Value Chain and Component Integration" as one of its twelve risk categories, and the reasoning is blunt: third-party components can be obscured in ways that complicate tracking and forensic analysis, so due diligence and documented provenance have to be contractual rather than assumed. The EU AI Act pushes in the same direction from the legal side — Article 25 allocates responsibility along the value chain and sets out how a party downstream of the original developer can inherit the full obligations of a provider.
Most program delivery work isn't a high-risk AI system and won't be regulated as one. I'm not suggesting you paper your integrator with conformity assessments. I'm pointing out that the people who thought hardest about this concluded that value-chain risk is structural, not incidental — you don't manage it with a relationship and a quarterly business review. You manage it with terms.
Fixing it without blowing up the relationship
The instinct is to prohibit, and prohibition is the wrong move for the same reason it was wrong internally. A vendor told they cannot use AI on your engagement will either price the work as if they aren't and use it anyway, or genuinely comply and deliver slower and more expensively than the market. Neither outcome is what you wanted. The goal is disclosure and standards, not abstinence.
In the Army, you didn't get to tell an investigating officer that the failure happened in an attached unit. If it operated under your task organization, it was yours — which is why competent commanders were specific about standards up front rather than surprised about them afterward. Vendor AI is the same structure. Attached capability, your consequences, so set the standard while you still have leverage, which is during negotiation and not during the incident.
Practically: put an AI disclosure clause in the master agreement and a specific one in each statement of work. Require that AI-assisted deliverables be identified as such — not to penalize them, but so your reviewers calibrate. Extend your data classification rules explicitly to vendor personnel and name the environments where your material may and may not be processed. Ask for the same provenance record you'd demand internally. And require notice when the vendor materially changes how the work is produced, because the delivery model you diligenced at signature is not necessarily the one running today.
- Add an AI disclosure clause at the master-agreement level and restate it per statement of work. Silence in a contract is not a prohibition.
- Ask the three narrow questions — where the data goes, who reviews, whether they can reconstruct — instead of "do you use AI?"
- Require AI-assisted deliverables to be labeled. Labeling changes how your reviewers read, which is the whole point.
- Extend data classification rules to contractor personnel by name, and specify approved environments.
- Require notice of material change to delivery method. The model you bought can be swapped without you hearing about it.
- Audit one vendor deliverable per quarter for provenance. One is enough to tell you what the standard actually is.
The bottom line
Every organization I work with has an AI policy, and nearly all of them have one that governs the smaller half of the work. The people producing your architecture, your test cases, and your migration plans mostly don't work for you, and their tooling decisions are being made against their margin pressure, not your risk tolerance. That's not a scandal — it's just what a modern delivery model looks like once AI reaches it. But an accountability boundary that stops at your badge line is a boundary you've drawn in the wrong place. Someone still signs, and it isn't the vendor.