6 AI Risk Mitigation Strategies for Your DPAs (With PDF Handout)

Start by identifying exactly what data is being processed. Some predictive analytics tools may not involve personal data and don't require a DPA.

Evaluate the pros and cons before adding or agreeing to provisions that say "no personal data will be provided." Many users don't understand what constitutes personal information (like IP addresses) and may inadvertently transfer it anyway.

Decide whether to do an AI amendment to your existing DPA or whether you need a completely new DPA.

Check if there are multiple definitions of the same concept. Typically we see input data and output data definitions that typically appear in the master services agreement (MSA) while personal data terms belong in the DPA. If the same definitions are needed in both documents, make sure they are consistent.

Keep all the indemnification and limitation of liability provisions in the MSA

Include cross-reference provisions between MSA and DPA. It should be looked at really holistically to see what defined terms are in the MSA and ensure that anything personal data related is in the DPA.

What the provider is doing with your data? Recognize that with free or low-cost AI tools, you're paying in the data that you provide. If it's free, maybe you are the product.

Add explicit technical limitations on data types in your DPA, prohibiting transfer of "images, video, and certain structured information" where possible to reduce risk exposure.

Investigate whether they can use your data to create derivative synthetic data. Vendors can keep that data after termination and use it for different contexts, including competitive clients.

Question terms allowing vendors to use "de-identified" or "anonymized" data. Companies are becoming more careful about allowing AI vendors to use data even in de-identified form due to re-identification risks.

Specify security requirements for open-source components, which bring with them increased risk of malware.

Distinguish between different AI technologies when setting permissions, as RAG (retrieval-augmented generation) presents different risk scenarios

Ask for detailed security exhibits with measurable commitments. When vendors take too long on security questions, this is a warning sign: If it takes two weeks to hear back because they're trying to get from their product team what is actually going on with security. Take that as a signal.

Include security assessment rights with specific timelines.

Make deletion requirements explicit.

If the provision says 'upon request,' make sure you have a system to ensure that you make that request. Regulators are focusing on vendors keeping data because no one ever asked us to delete it.

Investigate your vendors' technical capabilities for data deletion. It's surprising how far behind fairly sophisticated companies are, as many lack a rational and easily-explained retention policy.

Consider adding a specific financial consequence. Unless there's a financial number attached to failing to have a deletion process in place, you can wind up with it being overlooked.

Limit what can be derived from seemingly innocent data. In the past, we didn't worry as much because it would take forever to figure out who this person was. With AI, that suddenly becomes much easier.

Limit location data extraction. There are now models that can pinpoint where a photo was taken in any major city just based on the image itself.

Be cautious with all visual data. Consider excluding images, and video. Talk to your product teams. They're able to do more than they want to because they have other priorities.

Use specific classification language that defines which party is a controller and a processor. Is it going to be a data processing agreement or is it going to be a data sharing agreement?

Add language if the vendor's going to use the data for a particular purpose. This might create a controller to controller relationship requiring different protections.

Add diligence documentation requirements as an exhibit. Pre-engagement diligence is so much more important with AI tools compared to traditional SaaS.

Determine whether any adjacent documentation is needed, such as data protection impact assessment.

Add AI risk assessment obligations as a contractual requirement and specify scopes.

Require documentation of decision-making processes with timelines. Create records that memorialized your thinking at the time around the processing of personal information or the risks introduced by the use of this AI tool.

Include requirements for sensitive data. There are tools that will prevent certain data, personal data from entering systems that can blur images like on Google Maps or hide certain known kind of personal data.

Consider adding visual documentation for complex processes.

Identify documentation formats and delivery timelines to ensure they're actually created. Consider adding visual documentation requirements for complex processes.

The DPA talks generally about compliance with all applicable data protection laws while the MSA will talk about compliance with all applicable laws.

Insert specific requirements for automated decision-making governance. Data protection laws include provisions requiring explicit contractual handling regardless of evolving AI laws, in relation to automated decision making technology.

Incorporate specific notification requirements for changes in compliance status. While not directly quoted, Shannon's emphasis on the rapidly evolving landscape implies the need for vendors to notify customers when regulatory changes affect compliance.

Include compliance certification requirements with regular delivery schedules. Given Shannon's emphasis on documentation for regulators, certification requirements provide evidence of ongoing compliance with evolving regulations.

Add cooperation clauses for adapting to regulatory changes. The speakers' emphasis on the changing landscape implies the need for contractual mechanisms to address new requirements cooperatively.

Add SOW-level requirements for critical business issues regardless of legal status. Kate advised: "If you're worried about fairness of outcomes or certain specific types of bias...put that in the SOW, do not depend on law to protect you. Because the laws all over the place right now."

Make sure that whatever we're agreeing to, we can actually do. Then once we agree to something that our teams know about it and can put something in place. Product engineering, security, IT, privacy, legal - needs to be involved because if something goes wrong, everyone will be brought in.

Identify a lead from your product or technology team. Educate them on the obligations, but also the implications of doing it poorly or not at all.

Add implementation verification checkpoints with specific deadlines. While not directly quoted, the speakers' emphasis on operational execution implies the need for verification that contractual requirements have been implemented as agreed.

Insert data deletion reminder mechanisms. Shannon mentioned "Regulators have actually been focused on that in Europe recently" that vendors retain data because "no one ever asked us to delete it," requiring operational processes to trigger deletion requests.