An AI vendor contract should do more than grant access to a platform. It should identify the system and intended use, allocate regulatory roles, control the use of business and personal data, preserve evidence, set performance and security obligations, and provide a workable exit if the supplier, model or law changes.

This guide is intended for Romanian companies, foreign groups operating in Romania, technology suppliers, procurement teams and businesses implementing generative or other AI tools. It focuses on contract structure. For the wider regulatory framework, read our EU AI Act guide for foreign companies.

Why does an AI vendor contract need a separate review?

AI services can change after signature. A supplier may replace a model, add a subprocessor, change data-retention settings, modify safety controls or alter the geographic delivery chain. Outputs may also be probabilistic rather than repeatable. These features create risks that are not fully addressed by ordinary clauses on software access, uptime and confidentiality.

The EU AI Act allocates obligations according to the system, risk category and operator role. The GDPR applies in parallel where personal data is processed. The contract cannot transfer away statutory responsibility, but it can secure the information, instructions, evidence and cooperation needed for each party to perform its own obligations.

Start with the AI use, not the vendor’s template

Before redlining the agreement, the customer should record what the system will do, whose decisions it will influence, what data enters the system, who receives the output and whether the tool will be integrated into employment, credit, insurance, education, essential services, biometric or other sensitive workflows. The same product can create different legal exposure when deployed for a different purpose.

AI vendor due diligence before contract negotiation

A customer cannot negotiate intelligently without basic information about the service. The due-diligence request should be proportionate to the use and risk, but it commonly covers:

• the legal entity supplying the service and the entities supporting it;
• the model or models used, hosting locations and material third-party dependencies;
• the intended purpose, known limitations and prohibited uses;
• data sources, retention rules and whether customer data is used for training or improvement;
• security controls, incident history, business continuity and disaster recovery;
• testing, accuracy or performance information relevant to the deployment;
• subcontractors, subprocessors and international data transfers; and
• the supplier’s process for regulatory requests, complaints, audit evidence and system changes.

For high-risk deployments, the customer may require contractual access to sufficient documentation, instructions, logs and compliance information to enable it to perform its own obligations under the AI Act. The scope of access should reflect the parties’ respective roles and may need to protect the supplier’s trade secrets and intellectual-property rights. The European Commission’s AI Act information page and its AI Act Service Desk are useful starting points, but the contract must still reflect the particular system and transaction.

What if the service relies on a general-purpose AI model?

Where the service relies on a general-purpose AI model, the customer should also consider whether contractual information rights are needed regarding the model provider, model updates, transparency documentation and downstream restrictions affecting the deployment. These provisions should be tailored to the customer’s position in the AI value chain and should not imply that the customer is entitled to the provider’s complete technical documentation.

What clauses should an AI vendor agreement contain?

1. Define the system, version and intended purpose

The agreement should identify what is actually being supplied. “AI services” is rarely sufficient. The specification should address the model or service version, functions, interfaces, customer environment, authorised users, territories, dependencies and intended use. If classification or performance depends on a specific configuration, that configuration should be documented.

2. Allocate AI Act and GDPR roles separately

The parties should record their assumed roles under the AI Act and set out who provides instructions, documentation, logs, notices and regulatory cooperation. A separate analysis is required under the GDPR. Depending on the facts, the parties may be controller and processor, independent controllers or, in a narrower class of cases, joint controllers.

Where the supplier processes personal data on the customer’s behalf, Article 28 GDPR terms may be required. See our dedicated guide to the Data Processing Agreement in Romania. The DPA should not be treated as the complete AI contract, and the main agreement should not conflict with it.

3. Control prompts, files, outputs and training use

The contract should distinguish customer content, personal data, telemetry, feedback and output. It should state whether each category may be stored, reviewed by humans, used to improve the service or used to train a shared model. Where “no training” is promised, the clause should explain its scope, including whether safety review, abuse monitoring or service analytics remain permitted.

The European Data Protection Board has emphasised that whether an AI model is anonymous must be assessed case by case. A supplier’s assertion that its model is anonymous should therefore be supported by facts rather than accepted as a label. See the EDPB’s summary of Opinion 28/2024.

4. Make performance, limitations and human oversight usable

Conventional uptime metrics do not measure output quality. Depending on the use, the contract may need agreed tests, documented limitations, error reporting, performance monitoring, bias or drift controls, escalation and human-review requirements. The AI Act’s accuracy requirements should not be treated as a guarantee of error-free outputs. Any contractual accuracy or performance commitment should define the relevant task, dataset, test method, threshold and remedy.

5. Require evidence and audit cooperation

The customer may need records to complete an impact assessment, answer a regulator, investigate a complaint or demonstrate human oversight. The agreement should define which information is available, in what format, how quickly and subject to what confidentiality protections. In practice, enterprise suppliers may satisfy some audit requirements through independent certifications, reports and controlled information-sharing mechanisms rather than unrestricted customer audits. Those materials can support due diligence, but they do not automatically answer system-specific questions.

6. Coordinate security and incident notification

Security clauses should address access controls, encryption where appropriate, vulnerability management, segregation, personnel access, business continuity and incident cooperation. Notification should be triggered by defined events and delivered early enough for the customer to meet its own legal and operational duties. Different events may activate different regimes, so a personal-data breach, an incident affecting the AI system and an ordinary service outage should not be collapsed into one undefined term.

7. Address intellectual property and third-party claims

The contract should distinguish rights in customer inputs, supplier technology, configurations, fine-tuning, documentation, feedback and outputs. It should also allocate responsibility for claims involving training material, output, trademarks, confidential information and third-party components. Broad statements that the customer “owns the output” may be insufficient if the supplier cannot grant exclusivity or if protectability depends on applicable law and human contribution. Ownership language should be assessed together with applicable copyright rules, which may require sufficient human authorship for copyright protection.

8. Control subcontractors, subprocessors and model dependencies

An AI service may depend on model providers, cloud infrastructure, safety services and specialist subprocessors. The contract should identify the relevant chain, require notice of material changes and preserve appropriate objection or termination rights. For personal data, the subprocessor mechanism must align with Article 28 GDPR and any applicable international-transfer safeguards.

9. Regulate model and policy changes

Suppliers often reserve broad rights to modify models, acceptable-use policies and technical features. The customer should seek prior notice of material changes, enough information to reassess the deployment and a remedy when a change materially reduces functionality, alters data use, affects compliance or creates an unacceptable risk.

10. Connect liability to the risks that matter

Liability provisions should be read together with warranties, indemnities, insurance and remedies. A general cap may be commercially unsuitable for confidentiality breaches, unlawful data use, IP claims or deliberate misconduct, while unlimited liability for every model error may be unacceptable to a supplier, particularly where outputs remain subject to human review. The negotiated position should reflect control, foreseeability, fees, insurance and the consequences of the intended use.

11. Preserve suspension, termination and transition rights

The contract should explain what happens if the service becomes prohibited, materially non-compliant, insecure or unsuitable for the agreed purpose. Exit terms should cover data and prompt export, configuration records, transition assistance, continuing access where necessary, deletion, certification and surviving confidentiality or audit duties.

12. Align the whole contract suite

The main agreement, order form, specification, DPA, security schedule, service levels and online policies should be checked together. An order of precedence is important where one document allows training while another prohibits it, or where a linked policy can be changed unilaterally. Our broader contract review checklist explains the commercial clauses that remain relevant alongside the AI-specific controls.

Customer and supplier priorities are not identical

A customer usually seeks transparency, stable functionality, control of its data, evidence for compliance and practical exit rights. A supplier needs a defined intended use, customer cooperation, restrictions against misuse, protection for reusable technology and a liability position proportionate to fees and control. A balanced contract should not hide this tension. It should identify which party can prevent, detect and remedy each risk.

Practical experience: how Atrium approaches an AI contract review

AI vendor contract checklist before signature

1. Document the system, intended use, users and decision context.
2. Complete the AI Act role assessment and determine whether the deployment may involve prohibited, high-risk, transparency or other regulated AI use cases.
3. Map personal data, confidential information and international transfers.
4. Collect the main agreement, order, DPA, security schedule and linked policies.
5. Confirm whether customer data, prompts or outputs may be used for training.
6. Test whether supplier documentation supports the customer’s compliance duties.
7. Define relevant performance measures, limitations and human oversight.
8. Align incident notification with legal and operational deadlines.
9. Review IP ownership, licences, third-party material and claims.
10. Control material changes to models, policies, locations and subcontractors.
11. Model liability for realistic failure scenarios.
12. Plan suspension, export, transition and deletion before deployment begins.

Frequently asked questions

Disclaimer: This article provides general information and does not constitute legal advice. The appropriate contract and compliance analysis depends on the system, intended use, data, parties, operator roles, applicable law and complete contract suite.

AI Notice: AI-assisted content, reviewed and approved by a qualified Romanian lawyer.