IT Contracts That Keep Projects on Track: Negotiate Without Chaos or Disputes

Your ERP vendor has sent over a draft agreement. Forty-eight pages. The project manager says to sign because the project is running late. The CFO asks about penalties. The CTO says nobody reads it anyway. You know that in six months this agreement will determine who is responsible for a delayed go-live.

Sound familiar? If so, this article is for you.

An IT contract is not a formality to file away. It is a project-management tool that organizes cooperation, allocates risk and gives both parties predictability. A poorly negotiated implementation agreement creates direct costs, such as contractual penalties, renegotiations and disputes; operational costs, such as delays, downtime and duplicated maintenance costs; and strategic costs, such as vendor lock-in, loss of code rights and blocked product development.

Studies indicate that about 25% of IT projects in Poland fail, and the figure reaches 20% for ERP implementations. With contract values measured in millions of złoty, losses can be substantial.

This article explains how to negotiate an IT contract that organizes work with a vendor instead of generating disputes. It covers five areas to settle before signing, how the AI Act changes agreements for AI tools and practical steps for both customers and vendors.

Key terms before we begin

Before getting into the details, it helps to clarify a few terms used throughout the article.

Why an IT contract is not just a legal document, but a project-management tool

Negotiating IT agreements requires legal, business and technology skills. If only a lawyer is at the negotiating table, the agreement may be formally correct but fail to reflect the project’s realities. If only a project manager is there, the arrangements may be operational but unenforceable.

The problem with arrangements made “over email and calls”

A typical scenario looks like this: business, IT, procurement and the vendor agree on working arrangements in meetings and correspondence. Each party speaks a different language. The agreements are scattered across emails, Slack messages and meeting notes. Then the project enters a difficult phase and nobody knows exactly what was agreed or who is responsible for what.

The contract should bring these perspectives together in one predictable model of cooperation. The point is not to make an 80-page document. It is to answer the questions that will arise in 3, 6 or 12 months, when the project is delayed, the scope changes and the relationship is no longer as comfortable as it was at the beginning.

Why the legal classification of an agreement matters

Polish law has no statutory definition of an “IT implementation agreement.” Courts classify these contracts as unnamed agreements combining elements of a contract for specific work, a service agreement and a license. This is not an academic detail. Classification affects:

The Gdańsk Court of Appeal (case I ACa 1054/14) classified an agreement to implement a computer system as a contract for specific work because its purpose was to achieve a defined result: a functioning system meeting the customer’s requirements. In case XIII GC 1603/17, the court divided the contract into implementation work and service work.

What this means for your business: If your agreement does not specify which elements are “work” (configuration, integration and acceptance) and which are “services” (maintenance, support and SLA), a court may decide how to classify them in a dispute. That classification affects warranty rights, limitation periods and whether you can withdraw with retroactive effect.

Five areas to regulate in an IT contract

1. Scope of work and change management

The most common cause of implementation disputes is an imprecise functional scope. The vendor understands it differently from the customer, the project manager differently from the CTO, and the CFO differently from everyone else.

The agreement should include:

1. A detailed scope, not merely “ERP implementation,” but specific modules, functions, integrations and exclusions.
2. A schedule with milestones linked to payments and acceptance procedures.
3. A change-request process specifying who submits, estimates and approves a change, and its effect on schedule and budget.
4. A definition of “done” describing when a stage is complete and what acceptance criteria each deliverable must meet.
5. A roles-and-responsibilities matrix identifying who makes each decision for the customer and vendor.

No clear change-request procedure is a time bomb. Scope always changes. If the contract does not say how to handle changes, the vendor may impose delay penalties for changes caused by the customer, while the customer may argue that they were within scope.

2. Acceptance and testing procedure

Acceptance is when the customer confirms that the vendor has delivered what it agreed to deliver. It may also determine when VAT becomes payable and when a limitation period begins.

The agreement should include:

1. Measurable, verifiable acceptance criteria agreed before work starts.
2. A testing procedure: who tests, in which environment, using which scenarios, and what error threshold is acceptable.
3. An acceptance protocol specifying the form, time for comments and consequences of no response, including deemed acceptance.
4. A distinction between critical, major and minor defects and how each affects acceptance.
5. A conditional-acceptance procedure for a functioning system with non-blocking defects.

3. Intellectual property rights and code access

Polish copyright law narrowly defines statutory grounds for using computer programs in B2B relationships. Apart from limited exceptions, the agreement is the only basis for lawful software use.

Regulate:

1. Whether economic copyright is transferred or a license is granted, and for which fields of exploitation.
2. Source-code access: whether you receive the code, it is held in escrow, or the vendor retains it.
3. Rights to project documentation, specifications and materials created during the project.
4. Modification rights, including whether you may hire another vendor to develop the software without the original contractor’s consent.
5. The legal status of open-source components and third-party libraries used in the project.

For projects involving AI: AI-generated outputs, such as images, text or code, may not qualify for copyright protection if there is no human author. For work created with AI assistance, assess whether the human contribution is creative and the result individual. The agreement should address the status of these outputs.

4. Liability caps and contractual penalties

There are no publicly available Polish market benchmarks for typical SLA terms, liability caps or contractual penalties in IT contracts. Each negotiation therefore starts from one party’s proposed terms. Without knowing market standards, it is easy to accept unfavorable conditions.

Legal framework to know:

1. Article 473 § 2 of the Polish Civil Code: liability for damage caused intentionally cannot be excluded in advance.
2. Article 483: a contractual penalty may be reserved only for failure to perform a non-monetary obligation, not for late payment.
3. Article 484 § 2: a court may reduce a penalty if it is grossly excessive or the obligation has been substantially performed. The parties cannot exclude this rule by contract.

Before signing, check:

1. Whether liability caps are symmetrical and impose comparable limits on both parties.
2. Whether penalties have an aggregate cap proportionate to the contract value.
3. Whether the contract excludes certain matters from the liability cap, such as confidentiality breaches, IP infringement or intentional conduct.
4. Whether delay penalties account for change requests, since a customer’s scope change should not automatically create a penalty for the vendor.

Availability above 99.9% requires multi-level redundancy and geographic distribution, which means higher costs. When negotiating an SLA, make sure the required level matches actual business needs.

5. Exit plan and protection against vendor lock-in

Vendor lock-in is one of the most underestimated risks in IT contracts, especially for cloud and AI projects. If the agreement does not set out how cooperation ends, changing vendors may be technically and financially impractical.

An exit plan should cover:

1. Data migration: format, timing and who pays.
2. A transition period during which the vendor continues providing services to maintain continuity.
3. Access to documentation and configuration, including what the vendor hands over and what remains its property.
4. Cooperation with a replacement vendor, including the scope and terms of handover support.
5. Deletion of data from the vendor’s infrastructure in accordance with the GDPR and security policies.

Contact us to review your IT agreement and identify provisions that may need to change.

How the AI Act changes agreements for AI tools

Regulation (EU) 2024/1689, the AI Act, entered into force on 1 August 2024 and is being phased in. Provisions on prohibited AI practices have applied since 2 February 2025. Rules for general-purpose AI models have applied since 2 August 2025. Full requirements for high-risk AI systems apply from 2 August 2026.

Why this changes contracts

The traditional division, “the provider is responsible for the technology and the customer for its use,” is not enough. The AI Act imposes separate, non-transferable duties on both the provider and the deployer. A contract cannot effectively transfer these obligations to the other party.

Article 25 of the AI Act has direct contractual consequences. A deployer becomes a provider, with the associated regulatory burden, if it:

1. Places its own name or trademark on a high-risk AI system.
2. Makes a substantial modification to the system.
3. Changes the system’s intended purpose so that it becomes a high-risk AI system.

If you buy an AI tool and modify it for your needs, you may unknowingly assume provider obligations, including keeping technical documentation for at least 10 years.

What an AI tool agreement should contain in 2026

Scale of penalties

AI Act penalties may reach EUR 35 million or 7% of global turnover for prohibited practices, EUR 15 million or 3% for high-risk system violations, and EUR 7.5 million or 1% for providing incorrect information to authorities. For SMEs, the lower threshold applies. GDPR penalties may also reach EUR 20 million or 4% of annual turnover.

The scale of these penalties supports investing in appropriate AI contract clauses before implementation begins.

Agile does not remove the need for a contract; it makes one more important

Agile projects can create an unjustified temptation to leave matters such as a high-level plan, project communications and acceptance procedures out of the contract. The argument is: “We are agile, so we do not need a rigid contract.”

That is a mistake. Polish legislation is not tailored to the legal nature of agile implementation work. The contract must reflect how the parties actually work.

How an agile contract differs from waterfall

An agile contract should include:

1. Sprint definition: duration, planning rules and acceptance criteria.
2. Backlog-prioritization rules: who sets order and how priority conflicts are resolved.
3. Iterative acceptance: sprint deliverables and acceptance criteria.
4. Budget controls for time-and-materials work, including how the customer tracks hours and spend.
5. IP rights to each sprint’s outputs, including when rights transfer and whether sprint acceptance triggers the transfer.
6. An exit scenario for ending cooperation while work remains in the backlog.

GDPR duties in cloud and AI contracts that cannot be ignored

Before implementing a cloud or AI tool, your business should answer several questions:

1. What personal data will the system process?
2. Will the vendor act as a processor, and does the agreement include the data-processing agreement required by Article 28 of the GDPR?
3. Will data be transferred outside the European Economic Area, and on what legal basis, such as standard contractual clauses or an adequacy decision?
4. Will the system learn from customer data, and may the vendor use it to train a model?
5. Does the deployment require a data-protection impact assessment under Article 35 of the GDPR?

GDPR penalties may reach EUR 20 million or 4% of annual turnover. Missing clauses in an IT agreement do not remove liability and may increase risk.

AI systems add another dimension: an AI Act fundamental-rights impact assessment (FRIA) may be combined with a DPIA. The agreement should specify who conducts these assessments and how the parties cooperate.

Checklist: what to review before signing an IT contract

Use this practical framework as an internal review document before closing negotiations.

Customer’s perspective

Vendor’s perspective (software house/integrator)

The agreement is signed, but cooperation is deteriorating. What now?

Even the best contract cannot resolve every issue that emerges in day-to-day cooperation. Regulatory, economic, technological or organizational changes may bring the parties back to the negotiating table. Negotiating IT contracts is, in practice, an ongoing process.

If you have signed a maintenance or implementation agreement and cooperation is deteriorating, for example, the parties disagree about ticket priorities, response times or liability, do not wait for a formal dispute.

What to do:

1. Identify specific differences between the contract and how the parties actually work together.
2. Prepare an amendment that clarifies the working model before the dispute becomes formal.
3. Decide internally who enforces contract terms for acceptance, SLAs and change requests, and how performance will be monitored after signing.
4. Train project managers, product owners and IT leads on contract mechanisms so the agreement is a working tool, not an archived document.

We can help

We provide legal services to technology companies, from startups to scale-ups. We combine contract, IT and AI law with IP protection in a model tailored to how your business actually runs projects.

How we work on IT contracts:

1. Review existing agreements: assess scope and change requests, acceptance and testing, IP rights, liability caps and penalties, and exit plans. Identify gaps between the contract and actual cooperation.
2. Risk and negotiation-priority map: prepare an internal list of red flags, must-haves and nice-to-haves, approved by business, IT and the board.
3. Negotiation and documentation: negotiate firmly while helping the parties close the deal, and draft agreements that reflect how the team works.
4. AI project support: review clauses under the AI Act and GDPR, data and output rights, provider/deployer roles and regulatory-change scenarios.
5. Amendments and renegotiations: for agreements already in force that no longer work under project pressure.
6. Team training: show project managers, product owners and IT leads how to use contract mechanisms in day-to-day work.

We do not create documents “just in case.” We design rules where risk or value actually arises, from development through sales.

Contact us with your draft IT agreement. Within 48 hours, we will provide a risk map and a recommendation on where to begin negotiations.

An IT contract that works under pressure: summary and next steps

The greatest contract risk is not having no agreement. It is having an agreement that looks good on paper but fails under project pressure.

A well-negotiated IT contract organizes scope, allocates risk, governs changes and gives both parties a way to solve problems before they become disputes. In 2026, as the AI Act imposes new duties on providers and users of AI systems and implementations grow more complex, a sound contract structure is not merely a legal cost; it is a condition for a predictable project.

If you are negotiating an implementation agreement, buying an AI or cloud tool, or finding that your current agreement no longer works, contact us. We can help structure a contract that organizes the project instead of generating disputes.

Frequently asked questions

A vendor has sent its standard implementation agreement. What should I review first?

Start with five areas: (1) whether scope is precise and understood the same way by both parties; (2) whether there is a change-request procedure; (3) whether acceptance criteria are measurable; (4) who owns code and documentation when the project ends; and (5) how cooperation can end under the exit plan. If any area is missing or drafted only for the vendor’s benefit, the agreement may need to be renegotiated.

How should I set up change requests so scope changes do not block the project?

Specify who may submit a change and in what form, who estimates it, who approves it, its effect on schedule and budget, and what happens if the parties disagree on its price. Without this process, the vendor may impose penalties for customer-driven delays while the customer argues the changes were in the original scope.

We are buying an AI tool. How can we protect against vendor lock-in and data loss?

Regulate data migration, including format, timing and cost; the transition period; access to documentation and configuration; cooperation with a new vendor; and deletion of data from the vendor’s infrastructure. Also check whether the vendor may use your data to train its model and on what legal basis. Under the AI Act, assess whether modifying the system for your needs could change your role from deployer to provider.

I run a software house. How can I negotiate with a large corporate customer without taking on all the risk?

Prepare your own framework agreement instead of negotiating only from the customer’s template. Check that penalties and liability caps do not shift 100% of the risk to you. Address customer-caused delays, such as missing data, decisions or resources. Confirm that the scope is deliverable within your resources and budget and that the schedule matches your team’s capacity.

The agreement is signed, but cooperation is breaking down. Can anything still be done?

Yes. Do not wait for a formal dispute. Identify differences between the contract and actual practice, then propose an amendment clarifying service priorities, response times, liability and communication. The sooner the working model is clarified, the lower the risk of a lengthy dispute.

Who should be involved in negotiating an IT contract?

IT contract negotiations require legal, business and technology perspectives. The table should include a lawyer for contract structure and risk, a business representative for scope, budget and priorities, a CTO or technical lead for feasibility and dependencies, and a project or delivery manager for schedule, resources and acceptance. A lawyer alone is not enough: the agreement may be formally correct but fail to reflect the project.