A Cybersecurity Awareness Month series from Thompson Coburn’s Data Governance, Privacy and Cybersecurity practice group
Throughout Cybersecurity Awareness Month, Thompson Coburn has examined how organizations can put AI to work while keeping control of their data. The series has covered what organizations retain, whether existing data can be used for a new AI purpose, and what happens when AI surfaces access gaps that were already there.
In this final installment, we turn to the organizations helping businesses deploy AI: their technology vendors. Our third installment asked whether an organization has the authority to let a vendor use its data. This one looks at the other side of that relationship, where the vendor has made promises to the organization.
When an AI vendor promises to protect your data, how do you confirm the promise holds in practice?
The Contract Is Signed. The Questions Remain.
Consider a hypothetical. A company is preparing to roll out an AI assistant across its business units. The vendor’s materials promise enterprise-grade security. Its agreement addresses confidentiality, restricts the use of customer data for model training, and references established security practices.
Procurement completes its review. Legal negotiates the agreement. Information Security reviews the vendor’s documentation. The implementation team begins connecting the tool to business systems.
Several important questions are still open. The agreement may not say whether its training restriction covers every feature and every subprocessor. It may not address whether the vendor’s employees or contractors can review prompts and outputs, or how long the vendor keeps information in system logs. The company may not know whether it can set, on its own, the permissions that determine what the assistant can reach. And no one may be assigned to notice when a routine product update changes any of those answers.
Organizations have faced these questions about technology vendors for years. AI raises the stakes because of how much these tools can reach and how quickly they change.
When Practices Don’t Match Promises
Two FTC enforcement actions show the gap that can open between what a technology provider represents and what its systems, personnel, and business model actually do.
In May 2023, the FTC alleged that Ring failed to restrict employees’ and contractors’ access to customers’ private videos, used customer videos to train algorithms without consent, and failed to implement adequate security safeguards. Under the settlement, Ring agreed to pay $5.8 million for consumer refunds and to delete data, models, and algorithms derived from videos it had allegedly unlawfully reviewed. Ring’s parent company said it disagreed with the allegations. The questions in our hypothetical about who at a vendor can review customer content are the same questions the FTC’s allegations raised.
In June 2024, the FTC finalized an order against Avast, a company that marketed software to protect consumers from online tracking. The FTC alleged that Avast sold consumers’ browsing data to more than 100 third parties through a subsidiary after promising its products would protect against tracking. The order bans Avast from selling or licensing browsing data for advertising, requires a $16.5 million payment for consumer redress, and requires deletion of the data and any products or algorithms derived from it.
Neither case involved an enterprise AI procurement. Both show how a provider’s commercial incentives can pull against its privacy commitments, and both ended with orders to delete models or algorithms built from the data. As our second installment discussed, the consequences of a provider’s data practices also reach its customers: Blackbaud’s customers inherited the effects of the provider’s own retention failures.
FTC staff have addressed AI vendors directly. In a January 2024 post, staff in the FTC’s Office of Technology warned that companies offering AI models as a service have a business incentive to keep ingesting data to improve their models, which can conflict with commitments made to customers. The post stated that those commitments must be honored wherever they appear, including terms of service and promotional materials, and that companies failing to honor them may be liable under the laws the FTC enforces.
For customers, this creates two responsibilities. The first is to understand what the vendor has actually promised and whether those promises meet the organization’s legal and business requirements. The second is to confirm the organization has the visibility, contract rights, and operational controls to manage its reliance on those promises. A vendor’s contractual obligations remain important. The contract alone does not show that the practices are in place, or that they will stay that way.
What Existing Law Expects of Vendor Oversight
For institutions subject to the GLBA Safeguards Rule, much of this is already required. The Rule directs covered institutions to oversee their service providers by taking reasonable steps to select providers capable of maintaining appropriate safeguards, requiring those safeguards by contract, and periodically assessing providers based on the risk they present and the continued adequacy of their safeguards. An AI vendor that receives customer information is a service provider like any other. The AI-specific questions below fit inside that existing obligation.
NIST’s voluntary Generative AI Profile points in the same direction. Its suggested actions include updating procurement due diligence and vendor assessments for generative AI, inventorying third parties with access to organizational content, including contract clauses that let an organization evaluate a provider’s processes and standards, and establishing incident response plans for third-party AI technologies.
None of this requires a separate procurement function for AI. Organizations can adapt existing third-party risk management by adding targeted AI questions, defining escalation triggers, and setting a review rhythm proportionate to the information and functionality involved. A lower-risk productivity tool may warrant a streamlined assessment. A platform with access to regulated records, or the ability to take actions in operational systems, likely requires deeper scrutiny. Oversight should reflect the organization’s actual exposure.
From Vendor Assurances to Operational Accountability
A practical AI vendor review should establish five things.
- Commitments: What has the vendor actually promised? Review the agreement, data processing terms, applicable policies, and product documentation together. Check whether commitments on confidentiality, retention, model training, security, and subcontracting are consistent across them. Watch for exceptions, documents incorporated by link, and provisions that let the vendor change terms on its own. A promise not to train a general-purpose model may still allow the vendor to retain information for evaluation, abuse monitoring, or product improvement.
- Controls: How are those promises carried out? Determine what information the vendor receives, which of its personnel and subprocessors can access it, and what controls restrict its use, including access management, logging, encryption, retention settings, and separation of customer environments. Certifications and independent assessments are useful evidence, but check their scope. An assessment of a vendor’s general security program may not cover the data-use commitments tied to a particular AI feature.
- Accountability: Who owns the relationship after approval? Legal, Procurement, and Information Security may all take part in the initial review. Someone still has to own the relationship afterward. Name the business owner accountable for the use case, the functions responsible for ongoing oversight, and the people authorized to accept material changes or escalate unresolved risks. The ownership model from our fourth installment applies here too: someone receives reports about the vendor, someone can pause the integration, and someone confirms that problems are fixed.
- Change: Who reviews vendor updates before they take effect? Our third installment described the changes that should trigger renewed review, including new AI features, revised terms, and additional subprocessors. The vendor relationship needs the mechanics to catch them: someone assigned to track release notes and subprocessor notices, contract terms requiring notice of material changes and, where appropriate, a right to review or object, and a decision before affected features are turned on. Not every update needs legal review, but the organization needs criteria for separating routine changes from those affecting data access, permitted use, or risk.
- Response: What happens if commitments are not met? Define the vendor’s obligations to report security incidents, unauthorized processing, and other material failures. Determine what information the organization will need to assess the impact, whether it can suspend integrations or revoke access, and what help the vendor must provide during investigation, remediation, or transition. A right to terminate has limited immediate value if the organization cannot identify which systems are connected, preserve the records it needs, or safely discontinue the service. Our framework for responding when a technology vendor is breached covers these steps in more detail.
Keep Control Beyond the Contract
Over the past month, this series has looked at control through its four components: knowing what data you hold, knowing who and what can reach it, confirming what you are permitted to do with it, and holding vendors to what they have agreed. Each one depends on the same things: someone with authority to decide, the information to decide well, and a process that keeps working after the tool is deployed.
AI vendors offer capabilities most organizations could not build efficiently on their own. Using them well means knowing where the organization relies on a vendor’s representations and where its own controls need to fill the gap. Your vendor’s promise matters. So does your ability to confirm it is being kept and to act when it is not. That is how organizations put AI to work while keeping control of their data.
To discuss how these considerations apply to your organization, reach out to Thompson Coburn’s Data Governance, Privacy and Cybersecurity team. We welcome the opportunity to continue the conversation.
