Buying or embedding a third-party AI tool creates obligations that flow to you — under the AI Act and under GDPR.
General information for software and technology companies, not legal advice for your specific facts or jurisdiction — no lawyer-client relationship. See full terms.
Grouped into three clusters — rights, compliance, and operations.
Work through these systematically before signature — a written checklist beats relying on memory during a sales call, and it gives you something concrete to hold the vendor to later.
Do the vendor's terms grant you a usable licence to what the tool generates, or just a revocable right to view results?
Does the vendor claim any right to use your inputs — prompts, documents, customer data — to train or improve their models, and can you opt out contractually, not just via a settings toggle?
If the vendor's model was trained on data with disputed provenance, does their contract offer any indemnity — or does that risk sit entirely with you?
Can you export your data and stop using the vendor without losing access to the historical outputs your business depends on?
Under the EU AI Act, the vendor is usually the "provider" of the underlying model — which often leaves you holding the "deployer" obligations, including the Article 50 disclosure duties, as the integrator.
Does the vendor publish, or contractually commit to provide, a model card, GPAI documentation, or equivalent transparency information you'll need for your own AI Act compliance file?
If personal data passes through the tool, is there a GDPR-compliant DPA in place, and where — geographically — is the data actually processed and retained?
Has the vendor been assessed against SOC 2, ISO 27001 or equivalent, and will they contractually commit to a defined breach-notification window?
What SLA does the vendor offer, and what happens contractually if their outage breaks your own customer-facing commitments?
Could a silent model-version update change your product's behaviour without notice?
If this vendor doubles pricing or gets acquired, is there a realistic migration path — or is this a single point of failure for your product?
Does the vendor's liability cap realistically cover the scale of harm a failure on their end could cause your business?
The question vendors dodge most is Q1 — who owns the output. Most will answer confidently on uptime and security, then get vague fast on IP in generated content. That vagueness is itself the answer; price the risk accordingly.
A support-automation vendor pushed a model upgrade mid-quarter with no changelog. Response tone and accuracy shifted enough that a customer escalated — and the buyer had no contractual notice right that would have caught it earlier, only a support ticket after the fact. The fix sits in Q10 above, agreed before signature, not requested after an incident.
Cross-references the EU AI Act deadlines and GDPR security review resources above for the underlying statutory citations. Current as of July 2026.
Want AI configured to check a vendor contract against this list?
Yes. API-level integration still makes you a "deployer" under the AI Act for whatever the API does inside your product, and still creates a data-processing relationship under GDPR if any personal data passes through the call.
AI vendor terms, model versions and sub-processor lists change more often than typical SaaS vendor contracts. A light annual refresh, not a full redo, is the pragmatic cadence most companies settle on.
That's itself a useful diligence signal — weigh it against how deeply the tool will be embedded in customer-facing workflows. A vendor unwilling to commit to basics for a peripheral internal tool is a different risk than the same refusal for a customer-facing, core-workflow dependency.
20 minutes, free, with the person who does the work — a scoping call, not a sales call.