AI Vendor Due Diligence for German Companies: Legal Checklist

AI Vendor Due Diligence: Short Answer

AI vendor due diligence for German companies should be run before signature and before any pilot with real data. The legal checklist should cover GDPR and Article 28 DPA terms, transfers and subprocessors, AI Act role allocation, security and auditability, IP and confidentiality, liability caps, and exit or deletion rights. A DPA is necessary, but it is only one part of the buyer-side review.

• Start with use case, data categories, and whether the tool affects employees, customers, or regulated decisions.
• Check DPA, SCCs, subprocessors, retention, and training restrictions before procurement signs off.
• Ask for AI Act instructions, deployer support materials, and clear role allocation from the vendor.
• Do not accept standard liability, IP, and deletion clauses without comparing them to the real enterprise risk.

AI vendor due diligence for German companies should be completed before contract signature and before any pilot with real data. The legal checklist should cover GDPR and Article 28 DPA terms, transfers and subprocessors, AI Act role allocation, security and auditability, IP and confidentiality, liability caps, and exit or deletion rights. A signed DPA is necessary, but it is only one part of the buyer-side review.

That buyer-side review matters because AI procurement is not just software procurement with a new label. A single AI tool can combine personal data, trade secrets, model-training concerns, high-impact outputs, and workplace implications in one supplier relationship. For German companies, the useful question is therefore: what should be checked before the business uploads real customer, employee, or contract data?

Direct Answer: What Due Diligence Should You Run On an AI Vendor?

The short answer is that a German buyer should run AI vendor due diligence across ten checkpoints before approval:

Checkpoint	Why it matters before purchase
1. Use case and business owner	Risk depends on the actual workflow, not the vendor category.
2. GDPR role allocation	You need to know whether the vendor is a processor, controller, or mixed-role provider.
3. DPA and transfer setup	Article 28 terms, SCCs, and access locations must be documented.
4. Subprocessors and retention	Buyers need visibility into onward processing and deletion.
5. Training restrictions	Inputs, files, prompts, and outputs should not be reused without approval.
6. Security and auditability	The company needs evidence for technical and organisational measures.
7. AI Act role and support	Deployer teams need instructions, intended-purpose limits, and support material.
8. IP and confidentiality	Contract language must protect trade secrets and clarify rights in outputs.
9. Liability and incident terms	Low caps and weak notification clauses leave the buyer exposed.
10. Exit and reassessment	The company needs deletion, export, and re-review triggers.

If the vendor cannot answer these points in a structured way, that is itself a diligence finding. It usually means the procurement cannot safely move to production approval yet.

Why This Checklist Is Different From a General Vendor Assessment

A general software vendor assessment often focuses on privacy terms, security questionnaires, and commercial pricing. That baseline is too shallow for many AI tools because AI procurement frequently combines:

• personal data and confidential business information in the same workflow,
• cloud or support access across multiple jurisdictions,
• potential use of customer content for training or product improvement,
• outputs that can influence contracts, employees, or customer communications,
• supplier terms that disclaim output accuracy while capping almost all liability.

That is why this page should be read together with our broader enterprise AI legal risk framework. If your team first needs the privacy intake path, use our GDPR AI procurement guide and the more detailed GDPR AI vendor assessment checklist.

10-Point Legal and Procurement Checklist

1. Define the use case before reviewing the vendor

Start with the business workflow. A low-risk drafting assistant used on anonymised templates does not create the same exposure as an HR screening tool, an internal search copilot, or a chatbot connected to customer records.

Document at least:

• the business owner,
• the departments that will use the tool,
• the data categories involved,
• whether the tool affects employees, customers, or regulated decisions,
• the expected outputs and integrations.

Without that use-case definition, the legal review will stay too generic to be useful.

2. Check GDPR role allocation, DPA, and transfers

The first legal layer is the privacy package. Buyers should confirm whether the vendor acts as a processor, controller, or partly both, and then test whether the documentation matches that position.

Review at least:

• the Article 28 GDPR DPA,
• storage and access locations,
• SCCs or another Chapter V mechanism for non-EEA transfers,
• retention and deletion settings,
• whether prompts, files, telemetry, or outputs are used for training,
• the vendor’s subprocessor list and update mechanism.

For German companies, employee-facing use cases should also trigger an early check on Section 26 BDSG and possible Article 35 GDPR DPIA duties.

3. Review subprocessors, retention, and training use

Subprocessor visibility matters because many AI vendors rely on multiple infrastructure, safety, moderation, or support layers. The buyer should know not only who is in the chain, but also what data each layer can access and how changes are communicated.

Training and product-improvement rights deserve special attention. If the vendor reserves broad rights to reuse customer prompts, uploaded files, or outputs, the legal and confidentiality review is not finished. This is especially relevant where the tool will receive contracts, HR files, legal analysis, product roadmaps, or support tickets.

4. Check security commitments, audit rights, and incident reporting

Security review should not stop at a generic “enterprise-grade” statement. Procurement and legal should check what the vendor actually commits to in writing.

Ask for:

• technical and organisational measures,
• SOC 2, ISO 27001, or equivalent evidence where available,
• incident reporting timelines,
• breach-notification obligations,
• admin controls and logging,
• audit rights or acceptable substitutes.

If the vendor offers only marketing summaries and no meaningful contractual hooks, the company should treat that as a real procurement risk.

5. Check AI Act role allocation and documentation duties

As of May 22, 2026, the AI Act is already part of real procurement. The Act entered into force on August 1, 2024. Prohibited practices and AI literacy duties started applying on February 2, 2025. Governance rules and obligations for GPAI models started applying on August 2, 2025. The regulation generally applies from August 2, 2026, with Article 6(1) and corresponding obligations applying from August 2, 2027.

That means buyers should already ask vendors for:

• their role under the AI Act,
• intended-purpose limits,
• instructions for use relevant to deployers,
• available documentation on human oversight, logging, and incident support,
• any indication that the tool may be used in an Annex III context,
• transparency support where Article 50 may apply.

For the exact enterprise rollout timeline, see our EU AI Act deadline checklist and our EU AI Act procurement requirements guide.

6. Review IP, confidentiality, and output-use rights

Many AI contracts are strongest where the vendor wants broad rights and weakest where the buyer needs certainty. The legal review should therefore cover:

• ownership or licence position for inputs and outputs,
• confidentiality wording and trade-secret protection,
• restrictions on benchmarking or reuse of buyer data,
• output-related IP claims and available indemnities,
• internal rules on where generated content may be used without human review.

This point matters because output risk is not only about copyright. It is also about wrong answers, leaked confidential content, and generated material being reused outside the context where it was checked.

7. Review liability caps and carve-outs

The commercial contract should be compared to the enterprise’s real downside, not only to annual licence fees. Buyers should examine:

• overall liability caps,
• carve-outs for confidentiality, data breaches, and intentional misconduct,
• whether indemnities sit inside or outside the cap,
• the vendor’s duties to support investigations or regulator requests,
• whether the buyer is left carrying almost all business interruption and third-party claim risk.

If the contract is built like a low-risk SaaS purchase while the deployment is business-critical, the due diligence is incomplete.

8. Screen employee-facing use cases separately

AI procurement becomes more sensitive when the system affects employees or candidates. Recruiting, performance management, scheduling, productivity analysis, and workplace monitoring can trigger:

• Article 35 GDPR DPIA issues,
• Section 26 BDSG employee-data rules,
• AGG discrimination exposure,
• works-council co-determination under Section 87(1) no. 6 BetrVG.

That is why employee-facing AI tools should be escalated before pilot approval rather than treated as a routine IT purchase.

9. Set internal usage limits before approval

Even a well-documented vendor package does not answer how the company itself will operate the tool. Before approval, define:

• which data may and may not be entered,
• which teams may use the tool,
• which settings must remain enabled,
• what human review is mandatory,
• what events trigger reassessment.

This turns the diligence output into an actual operating framework instead of a one-off procurement memo.

10. Plan exit, deletion, and change management

The final checkpoint is often ignored until there is a problem. Buyers should confirm how the company can:

• export relevant data,
• obtain deletion confirmation,
• respond to new subprocessors or major model changes,
• suspend or terminate use quickly if the legal posture changes.

An AI vendor that is easy to buy but hard to exit creates long-tail legal and operational risk.

How This Checklist Differs From a General Vendor Assessment

The difference is depth and consequence. A general vendor assessment asks whether a tool can be bought. AI vendor due diligence asks whether the company can defend the purchase, govern the rollout, and keep using the tool safely once it is embedded in real workflows.

That is why the checklist should connect back to your enterprise-wide AI legal risk framework and, where privacy is the lead issue, to the more focused GDPR AI vendor assessment checklist.

FAQ

What due diligence should a company run on an AI vendor?

A German buyer should review use case, GDPR role allocation, DPA and transfers, subprocessors, training rights, security evidence, AI Act support, confidentiality and IP, liability terms, and exit mechanics. The point is to assess the deployment, not only the software.

Is a DPA enough for AI vendor due diligence?

No. A DPA is necessary for processor terms, but it does not answer training restrictions, transfer risk, AI Act duties, output risk, auditability, or whether the commercial contract leaves the buyer exposed.

What should procurement ask before buying an AI tool?

Procurement should ask what data enters the system, where it is processed, whether customer content is used for training, what subprocessors are involved, what AI Act support exists, how incidents are handled, and how confidentiality, IP, liability, and deletion are allocated.

When does the EU AI Act matter in AI procurement?

It matters already. The AI Act entered into force on August 1, 2024. Prohibited practices and AI literacy duties started applying on February 2, 2025. Governance and GPAI-model rules started applying on August 2, 2025. The regulation generally applies from August 2, 2026, with Article 6(1) and corresponding obligations applying from August 2, 2027.

Do employee-facing AI tools need extra due diligence?

Yes. Those tools can raise DPIA, employment-data, discrimination, and works-council issues in addition to the usual procurement questions. They should be escalated early.

What should the contract cover before approval?

At a minimum, the contract should cover training restrictions, confidentiality, audit rights or substitutes, incident reporting, liability caps and carve-outs, IP terms, subprocessor changes, and deletion or exit support.

Need Help Reviewing an AI Supplier?

If your team is buying AI for HR, legal, customer support, product, or internal knowledge work, the right time for AI vendor due diligence is before signature and before the first real-data pilot. For companies that need broader procurement and governance support, our page on AI legal counsel in Germany shows how Compound Law combines AI Act, GDPR, DPA, contract, and rollout advice in one engagement.

This article provides general legal information only and does not replace advice on a specific procurement or deployment decision.