Our recent IAPP web conference on third party AI risk drew a lot of live questions, more than we had time to get through. The session featured Joanne Furtsch (VP of Knowledge and Global DPO, TrustArc), Hilary Wandel (Chief Ethics and Compliance Officer, Dun & Bradstreet), and Darren Abernethy (Shareholder, Greenberg Traurig), and the conversation kept circling back to the same handful of questions. If you missed the webinar, or you caught it live and still have questions, here are the ones that came up most.
What is the “hidden AI problem” everyone on the panel kept referencing?
It is the gap between how AI actually reaches your organization and how your review process is built to catch it. Most privacy and compliance reviews trigger on a contract event: a new vendor, a renewal, an expansion. AI increasingly arrives through a release note instead, a feature a vendor ships into a platform you already approved. Nothing in a typical process flags that moment, so the AI is running before anyone outside the vendor knows it is there.
Why isn’t vetting an AI vendor once, at signing, enough anymore?
Because risk is not a property of the vendor. It is a property of the specific deployment. The panel made the point directly: the same vendor, under the same contract, can carry negligible risk in one use case and high risk in another, and that risk can shift without the customer signing anything new. A chatbot that answers order status questions is not the same risk as one that closes support tickets and issues account credits. Approving the vendor once does not approve every feature it ships afterward.
Are regulators actually already expecting ongoing review instead of a one time check?
Yes. The EU AI Act places obligations on deployers, not only on the companies that build the underlying models, so how you use a tool determines your obligation regardless of who built it. California’s risk assessment regulations under the CCPA require an in scope assessment to be updated within 45 calendar days of a material change, and that clock starts on risk, not on a new signature or invoice. Both rules assume the same thing the panel argued: a contract date was never the right place to anchor review.
Can you give an example of risk changing without anyone approving anything new?
The panel walked through a case study of a mid-size company that ran a full review when it first added an AI chat assistant to its support platform, then did everything right. Eighteen months later, the vendor shipped a voice AI feature with speaker verification and sentiment scoring, both new categories of data, with no new contract, no new invoice, and no review triggered. The company’s process had no door for that change to walk through, so it went live unreviewed.
How do you actually find the AI that is already embedded in your vendor stack?
The panel’s framework starts with discovery before anything else: ask every vendor what models they use, whether those models are proprietary, and what they can show you about how the models were trained and tested. “Proprietary” is a legitimate answer to “can I see your source code.” It is not a legitimate answer to “what risk am I taking on by using this.” From there, score the inherent risk, test the controls that are supposed to manage it, and calculate what risk is actually left over.
What’s the difference between inherent risk and residual risk, and why does it trip people up?
Inherent risk is what a feature would carry with no controls at all. Residual risk is what is left after controls are applied. The common mistake is skipping the first step: a company points to a privacy policy or a certification and assumes it mitigates risk, without ever confirming that the certification actually applies to this specific AI implementation. You cannot calculate a real residual risk number until you have honestly scored the inherent risk first.
What should go into contracts to protect against these silent changes?
The panel’s recommendation was to stop defining “material change” as a modification to the service and start defining it around risk: does the change create a new risk, increase the likelihood or severity of an existing one, weaken a safeguard, or change the purpose or autonomy involved. Practical additions include advance notice clauses for material AI changes, new features that default to off until a customer opts in, and clear scoping of what counts as company data, including prompts, outputs, and transcripts.
Do we need a formal AI governance committee before we can start any of this?
No, and waiting for one is a common trap. The panel’s advice was to build on what already exists: your data governance policy, your privacy program, your IP and security standards. Name one person as the point of contact for vendor AI changes so there is a single place communications land. Route only the highest risk decisions to a governance council and let clear, pre-set guidance handle the lower risk ones, so senior review time goes where it is actually needed.
What is the one thing the panel wanted people to remember?
That AI vendor management is not a photograph, it is a film. You will likely never be able to fully inspect the model inside a vendor’s product. You can always inspect the deployment, and that is what regulators, and eventually your own board, will expect you to be able to show.
Want a step-by-step framework for discovering, scoring, and governing the AI already running in your vendor stack?
Get TrustArc’s Step-by-Step Guide to AI Compliance
