AI Vendor Due Diligence for German Companies

Short answer

AI vendor due diligence for German companies should start before contract signature and go beyond the DPA. Legal, procurement, and security teams should verify the vendor's GDPR position, EU AI Act role, data and IP terms, audit rights, liability allocation, subcontractor chain, and financial resilience before the tool is approved for use.

• A DPA under Article 28 GDPR is necessary but not sufficient.
• German buyers also need AI Act, IP, liability, and labor-law review.
• High-risk or employee-facing AI tools need deeper documentation checks.
• Vendor insolvency and weak audit rights create real operational risk.

AI vendor due diligence for German companies should cover far more than a signed DPA. Before procurement approves an AI tool, legal and compliance teams should check GDPR compliance, EU AI Act role allocation, data and IP terms, audit rights, liability caps, subcontractors, and the vendor’s financial resilience. That is the practical legal checklist beyond the DPA.

The reason is simple: a DPA only addresses the processor relationship under Article 28 GDPR. It does not tell you whether the vendor trains on your prompts, whether it can pass your data to additional sub-processors, whether outputs create IP risk, whether the tool is part of a high-risk AI system under the EU AI Act, or whether the contract leaves your company carrying the real financial exposure.

For German companies, the right review process should bring legal, procurement, security, and the business owner together before contract signature. This guide explains what to check and what acceptable answers should look like.

Why AI Vendor Due Diligence Goes Beyond the DPA

A classic software vendor review often ends once procurement has a price, IT has cleared security, and legal has signed the DPA. That is not enough for AI tools.

AI vendors create additional risk because they may:

• process large volumes of personal data or confidential business information,
• use customer inputs for model improvement or service analytics,
• rely on long sub-processor chains across the EU and third countries,
• produce outputs that create copyright, confidentiality, or product-liability exposure,
• support decisions about employees, customers, or regulated activities, and
• operate with aggressive liability caps that do not match the real downside.

For a Germany-based company, this means the due diligence lens must combine several frameworks at once:

• GDPR: Articles 28, 32, and 35 on processor contracts, security, and DPIAs.
• EU AI Act: vendor role, risk classification, transparency, GPAI, and high-risk documentation.
• German contract law: especially liability allocation and standard terms review under §§ 305-310 BGB.
• Employment law: notably § 26 BDSG and § 87(1) no. 6 BetrVG where employees are affected.

If you have not yet completed the processor-side review, start with our GDPR AI vendor assessment checklist. The checklist below assumes you are now reviewing the broader legal and commercial risk.

The Legal Checklist: 9 Questions to Ask Every AI Vendor

1. What is the vendor’s role under GDPR and the EU AI Act?

Start by classifying the vendor correctly. Under GDPR, the vendor may be a processor, controller, or in some cases a joint controller. Under the EU AI Act, the same vendor could be a provider, a general-purpose AI model provider, an importer, distributor, or simply a supplier supporting your deployment.

These roles matter because they determine which obligations can be shifted contractually and which cannot. If the vendor uses your data for its own model improvement or analytics purposes, calling the contract a DPA does not make the vendor a pure processor.

What to look for:

• clear statements on whether customer data is processed only on documented instructions,
• a defined AI Act role and whether the tool could fall into Annex III high-risk use cases,
• separation between enterprise customer data and vendor-side product-improvement datasets,
• no hidden controller language in the privacy notice or product terms.

If the role allocation is unclear, the vendor is not diligence-ready. Our EU AI Act August 2026 deadline checklist shows why deployer obligations now have to be built into procurement review.

2. What data enters the system, and where does it go?

Many AI tools begin as low-risk experiments and quickly become business-critical workflows. Teams upload contracts, HR files, source code, support tickets, and customer communications. That changes the risk profile immediately.

You need to know exactly:

1. what categories of data users may input,
2. whether personal data, trade secrets, or regulated data are expected,
3. where the data is stored and processed,
4. whether third-country transfers occur, and
5. how long the vendor keeps prompts, files, logs, and output history.

Under Articles 32 and 35 GDPR, data categories and processing context drive the security review and the need for a DPIA. For employee-facing tools, the threshold for a DPIA is often reached faster than teams expect.

What to look for:

• EU or Germany-based hosting where feasible,
• documented transfer mechanisms for non-EEA processing,
• retention settings that can be configured or shortened,
• separate handling for training data, telemetry, and customer content.

If the tool will process employee data or sensitive customer information, cross-check the deployment against our AI risk assessment guide before approval.

3. Does the vendor use your data for model training or product improvement?

This is still one of the most important questions in how to vet AI vendors. If the vendor can use prompts, uploaded documents, metadata, or outputs for model training, benchmarking, or service improvement, you may have a GDPR problem, a confidentiality problem, and a competitive-risk problem at the same time.

For German companies, the safest position is usually explicit enterprise language stating that customer data is not used to train foundation models or improve shared models, unless you have separately agreed to that use and can legally support it.

What to look for:

• an express no-training commitment for customer content,
• a clear definition of “customer content” that includes prompts, attachments, fine-tuning data, and outputs where relevant,
• opt-out mechanics for telemetry or service-improvement processing,
• deletion or return rights on termination.

A silence point here is not neutral. It is a red flag.

4. What documentation can the vendor provide for EU AI Act due diligence?

As of May 20, 2026, procurement teams should not treat the EU AI Act as future-only law. The Act entered into force on August 1, 2024. Prohibitions and AI literacy duties have applied since February 2, 2025. GPAI and governance rules have applied since August 2, 2025. The broader regime applies from August 2, 2026, subject to specific exceptions.

That means an AI vendor assessment checklist now needs AI Act questions even where the system is not obviously high-risk.

Ask whether the vendor:

• provides a general-purpose AI model or embeds one,
• supplies a system that may fall within Annex III,
• has transparency or instruction-for-use materials ready,
• can support deployer obligations if your company uses the system in a regulated or employee-facing context.

For potentially high-risk systems, the contract should support access to technical documentation, conformity information, human oversight instructions, logging expectations, and incident escalation. Our EU AI Act August 2026 deadline checklist sets out the timing pressure behind those vendor-side asks.

5. Who owns inputs, outputs, feedback, and fine-tuning data?

Many AI contracts are precise on subscription fees and vague on ownership. That is backwards.

Legal teams should review at least four buckets separately:

• inputs: prompts, uploaded files, and structured customer data,
• outputs: generated text, code, summaries, or media,
• feedback: ratings, corrections, user interactions, and support messages,
• fine-tuning or custom models: datasets and weights created for your deployment.

The contract should confirm that the vendor does not obtain avoidable rights over your confidential data and that any license you grant is limited to providing the service. If a custom model is being built for your company, ownership and reuse rights need explicit negotiation.

This is also where IP indemnities matter. Some vendors cover infringement claims tied to the software itself, but exclude all claims arising from AI-generated outputs. That may be commercially unacceptable if teams will publish, ship, or rely on those outputs externally.

6. What audit, security, and incident rights do you actually have?

The phrase “industry-standard security” is not enough. An AI supplier due diligence GDPR review must confirm what evidence the vendor can provide and what happens when something goes wrong.

At minimum, the contract package should address:

• technical and organisational measures,
• security certifications or audit reports,
• breach and incident notification timelines,
• subprocessors and change notices,
• customer audit or review rights,
• cooperation duties for regulator, customer, or internal investigations.

For many enterprise AI tools, direct on-site audit rights are unrealistic. But legal teams should still push for practical substitutes: current SOC 2 or ISO 27001 evidence, a written TOMs annex, penetration-test summaries, and prompt notice of security incidents, policy changes, or subprocessors.

If the vendor refuses meaningful evidence, your company may be taking blind risk. The DPA is only one document inside the larger diligence file.

7. How are liability, indemnities, and warranty disclaimers allocated?

This is where many procurement reviews fail. The vendor’s legal exposure is often capped at one year’s fees, while your company’s downside may include GDPR fines, customer claims, operational outage, and re-procurement costs.

Review the contract for:

• the general liability cap,
• exclusions for indirect or consequential losses,
• data breach carve-outs,
• IP infringement indemnities,
• exclusions for AI outputs or customer misuse,
• warranty disclaimers about accuracy, legality, or fitness for purpose.

Under German law, these clauses also need to be checked through the lens of AGB control under §§ 305-310 BGB. A vendor’s standard terms will not automatically be enforceable simply because they are common in the market. That does not mean every broad limitation fails, but it does mean buyers have more room to negotiate than they often assume.

For business-critical or regulated use cases, compare the contract against the deployment context and the controls in your internal risk assessment. If the contract shifts every meaningful risk back to you, the tool may not be suitable without negotiated changes.

8. Does the deployment trigger German labor-law or discrimination issues?

If the AI tool will affect employees, candidates, or workplace monitoring, the legal review needs to go wider again.

Common triggers include:

• CV screening and candidate ranking,
• employee performance analysis,
• scheduling and productivity tools,
• sentiment, emotion, or behavioral scoring,
• internal copilots that analyse workforce communications or work product.

These use cases can engage § 26 BDSG, Article 35 GDPR, the AGG, and works council co-determination under § 87(1) no. 6 BetrVG. Under the EU AI Act, employment-related systems are also among the most obvious high-risk categories.

What to look for:

• a documented human review layer for consequential decisions,
• no black-box use of AI for hiring or discipline,
• bias-testing or validation materials from the vendor,
• readiness to involve the works council early where required.

For employee-related tools, due diligence is not just a vendor-contract exercise. It is also an internal governance exercise.

If your use case touches recruiting or monitoring, also review our guides on AI hiring tools in Germany and AI employee monitoring.

9. Is the vendor financially and operationally stable enough?

A final point that is easy to overlook: legal due diligence should include basic supplier resilience.

Ask whether the vendor:

• is adequately capitalised,
• discloses its contracting entity and governing law clearly,
• has enterprise support commitments and escalation paths,
• can maintain the service if a foundation-model dependency changes,
• offers export, migration, and deletion support if you need to leave.

This matters because many AI products still depend on a small number of upstream model, cloud, and infrastructure suppliers. If your vendor becomes insolvent, materially changes terms, or loses access to a core model, your legal and operational risk can crystallise quickly.

For critical workflows, legal should coordinate with procurement on step-in planning, exit rights, and data portability.

A Practical Review Workflow for German Procurement Teams

If you are building an internal AI vendor due diligence process, keep it simple and repeatable:

1. Scope the use case. Identify the business owner, user group, data categories, and whether the tool affects employees, customers, or regulated decisions.

2. Run the GDPR baseline. Confirm the vendor role, DPA, sub-processors, transfers, TOMs, retention, and training position.

3. Add the AI-specific layer. Check AI Act role allocation, high-risk indicators, transparency materials, output/IP terms, and model-dependency risk.

4. Review the contract economics. Compare liability caps, indemnities, service levels, and termination rights against the real business exposure.

5. Document the decision. Record why the tool was approved, conditionally approved, or rejected, and what usage limits apply.

This documented approach helps if you later need to justify the procurement decision to management, auditors, data protection authorities, or the works council.

Frequently Asked Questions

Is a DPA enough for AI vendor due diligence?

No. A DPA addresses only one part of the risk landscape. German companies should also review AI Act relevance, model-training rights, IP ownership, audit rights, liability allocation, employee-data implications, and vendor solvency before signing.

What should German companies ask an AI vendor before signing?

Ask who the vendor is under GDPR and the EU AI Act, where the data goes, whether customer content is used for training, what technical and legal documentation exists, what audit rights you get, how incidents are reported, what indemnities apply, and whether the vendor is financially stable.

When does the EU AI Act matter in procurement?

It matters now. On May 20, 2026, companies procuring AI in Germany are only weeks away from the August 2, 2026 general application date for most AI Act rules. Procurement teams should therefore build AI Act questions into vendor review now, not after go-live.

Do employee-facing AI tools require extra review in Germany?

Yes. They can trigger GDPR DPIAs, § 26 BDSG, works council rights under § 87 BetrVG, and the EU AI Act’s high-risk employment category. These tools need a deeper legal and governance review before deployment.

Need Help Reviewing an AI Vendor?

If your team is comparing AI tools for contract review, customer service, HR, internal copilots, or other business-critical workflows, do not stop at the DPA. A good review checks the full legal and contractual allocation of risk before the purchase order is signed.

Compound Law advises companies in Germany and the DACH region on AI vendor GDPR compliance, AI Act procurement, AI contract negotiation, and employee-facing AI governance. For a specific vendor or deployment, get individual legal advice before rollout.

---

This article provides general legal information only and does not constitute legal advice. Specific deployments require individual legal assessment under the GDPR, the EU AI Act, and applicable German law.