Your Clients Are Restricting AI Use Of Their Data. Is Your Vendor Program Keeping Up?

In client engagements across financial services, healthcare, and professional services, we're beginning to see a specific problem surface in contract negotiations: language restricting or prohibiting a vendor's use of artificial intelligence (AI) to process a client's data.

• Intellectual property (IP) agreements are beginning to state explicitly whether an engineering drawing or a source file can enter a model.
• Data processing agreements tied to contracts involving protected health information (PHI) are beginning to address whether a vendor's “AI-assisted” feature can route patient data somewhere the original agreement never contemplated.
• Personally identifiable information (PII) clauses are beginning to include specific language addressing AI use of that data.
• In one case, a large enterprise client restricted its vendors to models that had not been trained on data scraped from the public web, a standard that rules out most, if not all, of today's leading frontier models.

This kind of restriction is most common where a third-party risk obligation is already a regulatory requirement rather than a good practice.  Banks, insurers, healthcare organizations, and other industries with information security and privacy regulations have the least room to treat AI-enabled vendor behavior as out of scope, because their duty to know and control third-party risk is usually required by the regulations themselves.

A similar pattern is emerging in non-regulated industries. Engineering firms, market research firms, and other companies whose core service involves handling another  company's IP are increasingly working under contracts where a large enterprise client has written in AI-specific data-use restrictions, protecting its own designs, specifications, or proprietary research from that service provider's AI adoption. Two years ago, this kind of clause was rare. Now it shows up in contracts with increasing regularity.

This is as much a mid-market problem as an enterprise one, and mid-market companies are not as well positioned to absorb it. Large enterprises are pushing new AI-specific requirements down their own supply and service chains, into the contracts they hold with software providers, engineering and design firms, staffing partners, and other suppliers, while most mid-market organizations don't have anywhere near the third-party risk staffing a large enterprise can dedicate to managing the other side of that relationship. Keeping a third-party risk program current was already hard to staff. AI adds another layer of complexity to a program that, for a lot of mid-market companies, was thin to begin with.

And, of course, with all topics related to AI, this one is moving so fast it is hard to keep up.

What Traditional Third-Party Risk Requires

None of this fits cleanly into how most third-party risk management (TPRM) programs are built. Traditional TPRM asks three questions of a vendor relationship:

1. What service does the vendor provide?

2. What data do they receive?

3. What controls do they maintain?

Those questions assume the relationship holds still: the vendor approved at onboarding is the same vendor, running the same infrastructure, delivering the same service, at renewal.

Risk tiering is built on data sensitivity and criticality. Reassessment runs on a calendar, annually or at contract renewal, whichever comes first. That model works as long as vendor change is slow enough, and disclosed enough, for a periodic check-in to catch it.

What AI Changes

AI breaks that assumption.

The vendor relationship can now involve a changing chain of models, cloud providers, data sources, agents, plug-ins, and subprocessors, and a vendor can add, swap, or activate any of them without a new procurement event, a new contract, or any signal that would trigger a reassessment under a calendar-driven program. Ncontracts' 2026 survey of financial institutions found that 72% of respondents were only partially aware of which of their vendors used AI, and 16% hadn't assessed vendor AI use at all (The State of Third-Party Risk Management 2026). That gap is structural, not a failure of diligence: the program is asking the right questions at the wrong frequency.

Another report,   Securing and Understanding the Risk of Third-Party AI Use,  explains why this is easy to miss: organizations are moving past the binary “does this vendor use AI” question and asking how AI is embedded in a vendor's offering, including in functions where AI was never the headline feature. A collaboration platform, a document management system, a legal research tool: none of them were bought as AI vendors, and several of them now are. That expansion touches five areas of a vendor relationship at once:

• Data risk:   What happens to the data a vendor's AI touches, and whether it's retained, logged, or used to improve a model.
• Fourth-party risk: What sits behind that vendor as an undisclosed model or infrastructure provider.
• Change-management risk: How a vendor can alter its AI capability without tripping any process a customer would normally rely on.
• Security risk:  The attack surface a new agent or plug-in introduces.
• Output risk:  What happens when an AI-driven result (e.g.,  a price, an eligibility decision, a flagged transaction)  turns out to be wrong.

Each of those is a live finding in a vendor file that hasn't been updated to look for it.

The regulatory backdrop is shifting too, though not in the direction most Net Effect readers need to track closely. The EU AI Act's transparency obligations, phasing in through August 2026, get most of the press, but they carry limited weight for a U.S. mid-market vendor program.

More relevant: a growing number of U.S. states now have their own AI-specific laws on the books, and those are the ones more likely to touch a mid-market vendor relationship directly. The National Institute of Standards and Technology's AI Risk Management Framework (NIST AI RMF) isn't a regulation, but it's increasingly showing up as a reference point inside vendor contracts and as the framework companies reach for when they structure an AI governance program in the first place.

Closing this gap and preparing for a future where this is standard practice for everyone takes three changes to the program you already have:

• Vendor inventory:  Record AI use at the feature and use-case level. A low-risk vendor can still run one high-risk AI feature inside a single workflow, and a vendor-level rating alone won't catch that.
• Disclosure:  Make it a standing contractual obligation rather than a one-time questionnaire answer: whether the vendor uses AI to deliver, support, or improve the service, whether your data can be retained or used for training, and what triggers notice when any of that changes. PwC's June 2025 guidance lands in the same place: disclosure obligations, AI-specific due diligence, and ongoing monitoring, not an annual check-in (“Responsible AI and third-party risk management”).
• Reassessment:  Move from calendar-driven to event-driven, triggered by a model change, a new subprocessor, or a shift from an assistive feature to one making autonomous decisions, none of which line up with a renewal date.

This tracks with what we see directly in our own risk advisory work. Third-party risk is consistently one of the last controls a company gets to as it matures a broader cyber risk program, even though third-party and vendor access shows up again and again in breach disclosures. AI is compressing that delay. Mid-market companies with lean risk teams are feeling it first, driven by AI-specific requirements a large enterprise customer pushes down through its own vendor program, on that customer's timeline rather than their own.

What To Do Now

For a mid-market risk team, four moves make the most difference, roughly in this order:

1. Reassess the vendors that already touch regulated, proprietary, or otherwise sensitive data and are known or suspected to use AI, before working through the rest of the vendor list.
2. Add AI-specific questions to every onboarding and renewal review now, rather than waiting for the next annual cycle to catch up.
3. Put the contract language in writing: disclosure obligations, data-use restrictions, and subprocessor notice requirements, rather than leaving them assumed.
4. Stand up continuous monitoring for the vendors that matter most, since a point-in-time assessment no longer holds for as long as it used to.

That fourth item is where most mid-market programs stall, because ongoing monitoring is hard to sustain with a small team and a spreadsheet. This is where a platform like our partner Drata earns its keep: automating vendor risk questionnaires, centralizing evidence, and flagging changes in a vendor's compliance posture between review cycles instead of waiting for the next one. It's also where our own work with clients tends to concentrate: building the inventory and risk-tiering model, connecting it to a monitoring platform, and in some engagements running the vendor assessment directly, so a lean risk function isn't carrying all of it alone.

The vendors driving this aren't doing anything wrong. The contracts and the assessments built to govern them just weren't written with a moving target in mind, and the clients now writing AI restrictions into their own agreements are the ones who've already noticed.