AI Vendor Contracts in Romania: EU AI Act and GDPR Clauses
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.
Key points for companies buying AI services in Romania:
- Classify the AI use and the parties’ roles before negotiating warranties and liability.
- Do not assume that a standard SaaS agreement or a GDPR DPA covers AI-specific risk.
- State whether prompts, files, outputs and usage data may be retained or used for training.
- Require enough information, logs and cooperation to meet the customer’s own legal duties.
- Connect service changes, security incidents and regulatory events to notice, remediation and exit rights.
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.
Practical distinction: the AI Act analysis, the GDPR role analysis and the commercial allocation of risk are related but separate. A supplier described as a “provider” under the AI Act is not automatically a “processor” under the GDPR.
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.
Select a layer to see the question that should be answered before signature.
Identify the product, model, version, functions, integrations, users, prohibited uses and decision context. Classification begins with the actual deployment.
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?
| Contract layer | What the clause should resolve | Risk if unclear |
|---|---|---|
| System and permitted use | Product, model, version, functionality, users, integrations, territories, intended purpose and prohibited uses. | The service is used outside its tested or agreed purpose. |
| Regulatory roles | AI Act operator roles, GDPR roles, responsibility matrix and cooperation duties. | Each party assumes the other will supply evidence or perform a mandatory task. |
| Data and training | Permitted inputs, retention, model training, improvement, isolation, deletion and export. | Confidential or personal data is retained or reused beyond the customer’s expectation. |
| Performance and oversight | Relevant metrics, limitations, testing, human review, logs, notices and remediation. | Outputs cannot be evaluated, challenged or reconstructed when a problem occurs. |
| Security and incidents | Technical measures, vulnerability management, notification triggers, timing and cooperation. | The customer learns too late or receives too little information to respond lawfully. |
| IP and output rights | Rights in inputs, outputs, configurations, documentation, feedback and third-party materials. | The customer lacks the rights needed for its intended commercial use. |
| Change control | Notice of model, policy, subprocessor, location and functionality changes, plus testing and objection rights. | A compliant deployment becomes materially different during the contract. |
| Liability and exit | Warranties, indemnities, caps, insurance, suspension, termination, transition, export and deletion. | The remedy is commercially unusable when the service fails or must be withdrawn. |
Click a row, or focus it and press Enter, to highlight one negotiation layer.
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
A typical client mandate begins with the operating facts, not a generic AI checklist. Atrium Romanian Lawyers first maps the proposed use, data flows, parties, model dependencies and decisions affected by the tool. We then review the full contract suite, identify provisions that do not match the deployment and separate mandatory compliance points from negotiable commercial risk.
The work may include a priority risk report, tracked changes, replacement clauses and a negotiation list for the business and technical teams. Particular attention is given to training rights, confidentiality, GDPR roles, security incidents, documentation, model changes, intellectual property, liability and exit. This section describes our review method and does not disclose any client’s confidential facts.
AI vendor contract checklist before signature
- Document the system, intended use, users and decision context.
- Complete the AI Act role assessment and determine whether the deployment may involve prohibited, high-risk, transparency or other regulated AI use cases.
- Map personal data, confidential information and international transfers.
- Collect the main agreement, order, DPA, security schedule and linked policies.
- Confirm whether customer data, prompts or outputs may be used for training.
- Test whether supplier documentation supports the customer’s compliance duties.
- Define relevant performance measures, limitations and human oversight.
- Align incident notification with legal and operational deadlines.
- Review IP ownership, licences, third-party material and claims.
- Control material changes to models, policies, locations and subcontractors.
- Model liability for realistic failure scenarios.
- Plan suspension, export, transition and deletion before deployment begins.
Frequently asked questions
Does every AI vendor contract need a GDPR DPA?
No. A DPA is required where the factual relationship meets the controller-processor conditions under Article 28 GDPR. Other arrangements may involve independent or joint controllers. The roles should be assessed from the actual processing, not only from the labels in the contract.
Can an AI supplier use customer prompts to train its model?
That depends on the contract, product settings, supplier role, transparency and applicable data-protection and confidentiality rules. The agreement should state clearly which data may be used, for what purpose, for how long and whether an effective opt-out or enterprise isolation applies.
Does an AI Act clause transfer compliance responsibility to the supplier?
No. A contract can allocate tasks, information duties, warranties and remedies, but it cannot remove statutory obligations imposed on a party by law. Each operator should understand and perform the duties attached to its own role.
Should the contract name the underlying AI model?
Usually, the system and relevant dependencies should be described with enough precision to understand what is being supplied. If the supplier may change the underlying model, the contract should address notice, testing, material degradation, data implications and the customer’s available remedies.
Who owns AI-generated output?
The answer depends on the contract, the output, applicable intellectual-property law, human contribution and third-party material. The agreement should distinguish ownership from a licence to use and should address infringement claims and supplier restrictions.
Can a Romanian lawyer review a foreign vendor’s English-language AI contract?
Yes, where the agreement concerns a Romanian company, Romanian operations or applicable EU and Romanian requirements. The scope should identify whether separate advice is needed for clauses governed exclusively by another country’s law.
Negotiating an AI vendor contract connected with Romania?
Atrium Romanian Lawyers assists customers and technology suppliers with AI, SaaS and IT contract review, drafting and negotiation, including GDPR, security, intellectual-property, liability and exit provisions.
Discuss the contract with a Romanian lawyerDisclaimer: 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.
