Your software house has just signed a fixed-price agreement to implement an AI chatbot. The customer supplied a knowledge base full of duplicates and outdated information. The model hallucinates. The customer refuses acceptance. You check the agreement and find a standard IT contract, with no provisions on input-data quality, hallucinations, or the possibility that the model provider may change its API terms tomorrow.
A hypothetical scenario? Not entirely. Industry signals indicate an approximately 30% increase in legal disputes at IT companies related to generative AI. Regulation (EU) 2024/1689 (the AI Act), which will fully cover high-risk systems from 2 August 2026, requires parties to an agreement to meet obligations that a conventional IT implementation agreement does not address.
AI is probabilistic and depends on data and external providers. If you try to fit it into a conventional software contract, you risk disputes whose costs may greatly exceed the value of the project.
This article sets out six clauses that distinguish a sound AI implementation agreement from a ticking time bomb. It explains how to define scope through KPIs, allocate responsibility for data, regulate intellectual property in AI outputs, and protect against external API outages.
Key terms before we start
Before we get into the details, here are the key terms used in this article.
| Term | Meaning |
|---|---|
| AI Act | Regulation (EU) 2024/1689, the EU law governing artificial intelligence systems. It applies in stages, from 1 August 2024 to 2 August 2028. |
| High-risk system | An AI system whose use may significantly affect individuals’ rights, for example in recruitment, creditworthiness assessment, or medical diagnosis. It is subject to the broadest obligations under the AI Act. |
| GPAI (general-purpose AI model) | An AI model designed for many uses, such as GPT-4, Gemini, or Claude. The model is generally not itself a high-risk system; it becomes part of one when incorporated into a specific system with a defined purpose. |
| Back-to-Back | The principle that your obligations to your customer must not exceed the guarantees you receive from your technology supplier. |
| Garbage In, Garbage Out (GIGO) | The quality of an AI model’s results depends directly on the quality of its input data. Poor data leads to poor results. |
| Human-in-the-loop | A requirement for a person to verify an AI system’s results before a decision is made, particularly a decision with legal or financial effects. |
| PoC (proof of concept) | A project testing phase used to determine whether an AI solution works with your data and in your environment before you invest in a full deployment. |
| Data processing agreement | An agreement required by Article 28 GDPR when an AI system provider processes personal data on behalf of a customer. |
Why a conventional IT agreement does not work for AI deployments
| Area | Conventional IT agreement | AI implementation agreement |
|---|---|---|
| Scope | Defined features and specification | Business objective and effectiveness KPIs, for example accuracy of at least 85% |
| Data | Configuration data and migration | Training data, whose quality determines the result |
| System output | Deterministic: the same input produces the same output | Probabilistic: the same input may produce different outputs |
| Supplier dependency | Licensing and hosting | External model APIs from OpenAI, Google, or Anthropic, whose terms may change without your consent |
| Intellectual property | Copyright in the code | AI outputs are often not protected by copyright |
| Responsibility for errors | A bug is the implementer’s fault | A model hallucination is not a code bug; it has a different cause and requires a different allocation of responsibility |
Each of these differences calls for a separate clause. The following six are the essential minimum.
Clause 1: define the subject matter by KPIs, not features
In a conventional IT agreement, you describe what the system must do through a list of features. An AI implementation agreement must instead state the business objective and how you will measure whether it has been achieved. Why? A probabilistic system never delivers 100% accuracy. If you write only “the system classifies documents” without defining an acceptable accuracy threshold, the customer may refuse acceptance at 95% accuracy, claiming it expected 100%.
The agreement should specify:
- The system’s business objective, for example automatic classification of purchase invoices by cost category.
- Measurable KPIs with acceptance thresholds, for example at least 90% accuracy on a test dataset with a defined structure.
- Measurement conditions: which dataset will be used, for what period, and who will conduct the tests.
- A go/no-go procedure after the proof-of-concept phase, with clear criteria for when the project proceeds to scaling and when it ends.
Change fixed-price billing to an iterative approach. Treat the PoC as a separate phase with its own budget and decision criteria. Only after a successful PoC should the project scale under a Time & Material model with monthly budget reviews. A fixed price amid such uncertainty about model behavior is a gamble for both parties.
| SLA/KPI parameter | Example threshold | Measurement method |
|---|---|---|
| Model accuracy | At least 90% | Test dataset defined in an annex |
| System availability | At least 99.5% | Monthly uptime monitoring |
| API response time | No more than 1 second | Median from production logs |
| Model retraining time | No more than 7 business days | From the request to deployment of the new version |
| Incident response time | No more than 1 hour | From notification to confirmation that it has been received |
Clause 2: data governance and the Garbage In, Garbage Out principle
This is the implementer’s most important safeguard, and one of the clauses most often overlooked.
An AI model learns from data. If the customer supplies a knowledge base full of errors, duplicates, and outdated information, the model will generate incorrect results. Without a GIGO clause, the implementer may be responsible for poor model performance even when the cause lies with the customer’s data.
The agreement should define:
- Quality requirements for input data, including completeness, representativeness, format, and currency.
- The data-validation procedure: who checks the data before training begins and which criteria must be met.
- Consequences if supplied data does not meet the requirements, such as the implementer’s right to suspend work, extend deadlines, or charge additional data-cleaning costs.
- Responsibility for anonymization and labeling, clearly assigning who prepares the data, the customer or the implementer.
Using customer data to further train a general-purpose model raises a serious GDPR risk. If the implementer trains a general-purpose model on customer data, such as patients’ medical data, and then uses it for other customers, this may breach the purpose-limitation principle under Article 5 GDPR and lack a legal basis under Article 6 GDPR.
EDPB Opinion 28/2024 confirms that AI models trained on personal data are fully subject to the GDPR. Whether a model is anonymous must be assessed individually. A model cannot automatically be treated as anonymous simply because it is a model.
The agreement should also define:
- Whether the implementer may use customer data to train general-purpose models. The default should be no.
- Who is the controller and who is the processor under Article 28 GDPR.
- Rules for retaining and deleting data after the agreement ends.
- The obligation to conduct a data protection impact assessment (DPIA) under Article 35 GDPR when the system processes data on a large scale or combines data from different sources.
Contact us if you need help auditing AI agreements or preparing clauses to protect your data.
Clause 3: Back-to-Back obligations for AI model suppliers
Your AI implementation agreement with the customer must not promise more than the technology provider guarantees. This may sound obvious, yet software houses regularly promise 99.9% uptime even when a model provider’s API terms contain no availability guarantee. Providers such as OpenAI offer services “as is”, without continuity guarantees, with request limits (RPM, RPD, TPM), and with the right to change their terms.
- Review the terms of service (ToS) and service-level agreements (SLAs) for every model supplier you use.
- Prepare a comparison of your obligations to the customer and the guarantees made by the supplier.
- Ensure that your SLA does not exceed the supplier’s SLA on any parameter.
- Include an information clause so the customer knows the system uses an external API and accepts the limitations arising from the supplier’s terms.
| Parameter | What you promise the customer | What the model supplier guarantees |
|---|---|---|
| Availability | 99.5% | No guarantee; the service is provided “as is” |
| Response time | No more than 1 second | Depends on load; no SLA |
| API continuity | A stable version | Right to change without notice |
| Price | Fixed in the agreement | Right to change pricing |
Article 25(4) of the AI Act expressly requires a provider of a high-risk AI system and any third party supplying components or services integrated into that system to enter into a written agreement specifying the scope of information, technical access, and assistance. This is a direct legal basis for a Back-to-Back clause. A further risk is that, from 2 August 2025, providers of GPAI models must publish summaries of copyright-protected datasets used for training. If a model proves to have been trained on infringing data, the agreement should state who bears responsibility.
Clause 4: intellectual property in AI outputs and model improvements
Polish copyright law often does not protect AI outputs. Article 1(1) of the Act of 4 February 1994 on Copyright and Related Rights requires a “personal creative contribution”, which content generated autonomously by an AI system does not meet.
As of the first quarter of 2025, Polish courts had issued no ruling directly addressing the legal status of AI outputs.
A draft amendment to the Copyright Act, parliamentary bill no. 1245, included Article 7a on “works created through the operation of automated systems.” It was removed after consultations because no consensus was reached.
Thaler v. Perlmutter (United States, Ninth Circuit, 2023) confirmed that US copyright law requires a human author. The ruling is not binding in Poland, but may indicate a direction of interpretation.
Directive 2019/790 (the Copyright Directive) regulates the text-and-data-mining (TDM) exception for model training, but does not resolve whether AI outputs are protected.
The agreement should include:
- A definition of “AI outputs” as output data covered by a license or trade-secret protection, rather than copyright.
- An allocation of economic rights in outputs to the customer or implementer, depending on the cooperation model.
- Rules on ownership of model improvements and fine-tuned weights, including whether the implementer may use improved weights in other projects.
- A requirement to check outputs for plagiarism and unauthorized adaptations of others’ works.
- A prohibition on attributing AI-generated content to a human, as required by model suppliers’ terms of service, for example OpenAI’s.
Clause 5: allocate responsibility for a code bug versus a model hallucination
In a conventional IT agreement, responsibility for errors is straightforward: if the system does not work as specified, the implementer is at fault. In an AI implementation agreement, the agreement must distinguish responsibility for different causes of error.
| Error category | Cause | Who is responsible |
|---|---|---|
| Bug in integration code | Programming error by the implementer | Implementer |
| Model hallucination | Probabilistic nature of AI | Technology risk to be allocated through the agreement’s allocation of responsibility between the parties |
| Low effectiveness due to poor data | Input data that does not meet requirements | Customer, if the agreement includes a GIGO clause |
| External API outage | Change of terms or outage at the model supplier | Implementer liability exclusion under a force-majeure clause |
| Prompt injection attack | Intentional manipulation of a prompt by a user | Implementer liability exclusion |
The AI Act requires human oversight of high-risk systems. Even for systems that are not high-risk, requiring the customer’s personnel to verify AI outputs before making a business decision can protect both parties. Define which decisions require human review. For example, the customer should verify an AI-generated financial report before making an investment decision. If it fails to do so and suffers a loss based on a model hallucination, the source assigns responsibility to the customer.
Article 22 GDPR reinforces this principle: individuals have the right not to be subject to a decision based solely on automated processing when it produces legal effects or similarly significantly affects them. Human intervention must be real, not “rubber-stamping”.
As to liability for AI-caused harm in the EU, the proposal for an AI Liability Directive (AILD), which would have introduced a presumption of causation and facilitated claims, was formally withdrawn in October 2025. The source therefore states that liability remains governed solely by national tort rules: in Poland, Articles 415, 435 and 436 of the Civil Code address fault-based and risk-based liability. Without EU evidentiary presumptions, contractual clauses remain the only tool described here for allocating responsibility between the parties.
Clause 6: AI Act compliance and a regulatory adaptation mechanism
The AI Act applies in stages. Some obligations are already in force, while others will take effect over the coming months and years. Your agreement must account for this.
| Date | Obligation |
|---|---|
| 2 February 2025 | Ban on prohibited AI practices, for example emotion recognition in the workplace, and AI literacy obligation |
| 2 August 2025 | Obligations for GPAI models, including documentation, dataset statements, and oversight |
| 2 August 2026 | Full application of rules for high-risk systems: conformity assessment, technical documentation, logging, and human oversight |
| 2 December 2027 | Rules for high-risk employment systems, including recruitment and employee evaluation |
| 2 August 2028 | High-risk systems embedded in regulated products |
| Type of infringement | Maximum penalty |
|---|---|
| Use of prohibited AI practices | Up to EUR 35 million or 7% of global turnover |
| Infringement of high-risk system requirements | Up to EUR 15 million or 3% of turnover |
| Providing incorrect information to authorities | Up to EUR 7.5 million or 1% of turnover |
Role-change risk under Article 25 of the AI Act: One of the most serious contractual risks is unintentionally changing from the role of a deployer to that of a provider of a high-risk AI system. A deployer may become a provider of a high-risk AI system if it:
- Labels the system with its own logo or trademark.
- Materially changes the system’s operation, for example through fine-tuning that changes its purpose.
- Changes the intended purpose of a system that was not previously high-risk in a way that makes it high-risk.
In each case, it assumes the full set of provider obligations under Article 16 of the AI Act, including conformity assessment, technical documentation kept for at least 10 years, human oversight, and registration in the EU database.
The agreement should include:
- A precise definition of the system’s intended purpose, which determines its risk category.
- A prohibition on changing the system’s intended purpose without the provider’s written consent and an impact analysis of its classification.
- An adaptation clause requiring each party to notify the other about legal changes that may change the system’s classification.
- An allocation of responsibility for regulatory penalties if the system is found not to comply with the AI Act.
- An obligation to keep logs and technical documentation in line with AI Act requirements.
Checklist: six clauses for an AI implementation agreement
Before signing the agreement, check that it contains all six elements:
| No. | Clause | Review question |
|---|---|---|
| 1 | Scope defined by KPIs | Does the agreement define the business objective and measurable acceptance thresholds? |
| 2 | Data governance (GIGO) | Does the agreement specify data-quality requirements and consequences if they are not met? |
| 3 | Back-to-Back | Do your obligations to the customer stay within the guarantees of the model supplier? |
| 4 | IP rights | Does the agreement regulate rights to AI outputs and model improvements? |
| 5 | Allocation of responsibility | Does the agreement distinguish responsibility for code bugs, hallucinations, poor data, and API outages? |
| 6 | AI Act compliance | Does the agreement address risk classification, changes of intended purpose, and regulatory adaptation? |
How we can help
Preparing an AI implementation agreement requires expertise across three areas: contract law, IT/IP law, and AI Act/GDPR regulation. A standard IT agreement template does not account for any of the six risks described above.
We support founders, CTOs, and product leaders at technology companies in organizing AI contracts, from auditing existing agreements to preparing new templates tailored to their business model.
- Audit of existing IT/AI agreements against the six clauses in this article, with a risk report and recommendations.
- Drafting AI implementation agreement templates with KPI, GIGO, Back-to-Back, IP, liability, and AI Act compliance clauses.
- Review of model suppliers’ terms of service, including a comparison of contractual obligations.
- Support in negotiations with customers and suppliers, with practical negotiation options rather than theoretical analysis.
- Training for sales teams and project managers on explaining why fixed-price AI projects create risks for both parties.
An AI implementation agreement is your only safeguard
The absence of Polish case law on AI outputs, withdrawal of the AILD directive, and phased implementation of the AI Act mean one thing: an AI implementation agreement is the tool that allocates responsibility, IP ownership, and cooperation rules in AI projects.
The six clauses in this article, covering scope and KPIs, data governance, Back-to-Back terms, IP, allocation of liability, and AI Act compliance, are the stated minimum. Without them, each AI implementation carries the risk of a dispute whose cost can greatly exceed the cost of preparing a solid agreement.
If you implement or sell AI solutions and want to organize your contracts, write to us. We can review your agreement and identify gaps.
Frequently asked questions
I have a standard IT implementation agreement. What exactly should I change for AI projects?
Add at least six clauses: scope defined by KPIs rather than a feature list; data governance with a GIGO clause; Back-to-Back terms for model suppliers; IP rules for outputs and model improvements; allocation of responsibility distinguishing code bugs from hallucinations and poor data; and AI Act compliance with a regulatory adaptation mechanism. A standard IT agreement does not address AI’s probabilistic nature, dependence on external APIs, or the lack of copyright protection for outputs.
Can I use customer data to train my general-purpose model and then offer it to other companies?
By default, no, unless the agreement expressly allows it and you have a separate legal basis under Article 6 GDPR. EDPB Opinion 28/2024 confirms that AI models trained on personal data are fully subject to the GDPR. Data collected for one purpose, such as customer service, cannot automatically be used to train models for other entities without a new legal basis. Violating this rule risks GDPR liability, up to EUR 20 million or 4% of turnover, as well as customer civil claims.
How should an agreement define “success” for a probabilistic AI model?
Define success through measurable KPIs and acceptance thresholds, for example model accuracy of at least 90% on a defined test dataset, response time of no more than 1 second, and availability of at least 99.5%. Specify the measurement conditions: which dataset, what period, and who runs the tests. Use an iterative approach: first a PoC with go/no-go criteria, then scaling. Avoid fixed-price terms without a prior PoC; with AI’s probabilistic nature, budget overruns or unmet expectations are a significant risk.
What if an AI model provider, such as OpenAI, suddenly changes its API terms?
Include a Back-to-Back clause: your obligations to the customer must not exceed the supplier’s guarantees. Add an information clause stating that the system uses an external API and that the customer accepts limitations arising from the supplier’s terms. Include outages of external APIs in a force-majeure liability exclusion. Prepare a migration plan for an alternative model supplier and specify who bears the migration costs.
Do AI-generated outputs, such as reports, graphics, or text, belong to me or to the customer?
Polish copyright law does not protect outputs generated autonomously by AI because they lack the “personal creative contribution” required by Article 1(1) of the Copyright Act. As of the end of the first quarter of 2025, Polish courts had issued no ruling on this issue. Rights to outputs therefore need to be regulated contractually: define them as “output data” covered by a license or trade-secret protection, and assign economic rights to a specified party.
Should I run a PoC before the main deployment, and how should the agreement address it?
Yes. Treat the PoC as a separate phase with its own budget, schedule, and go/no-go criteria. Define its scope, for example testing the model on a sample of customer data; the KPIs for proceeding to scaling, such as at least 85% accuracy on a test dataset; the consequences of a negative result, including ending the project without further obligations; and the billing model for later work, such as Time & Material with monthly budget reviews.
