Selling AI or SaaS to an EU Enterprise Customer: What Must Be Ready Before Signature

An EU enterprise technology deal starts before the first contract redline. A customer may request a pilot description, security questionnaire, data-processing terms, AI governance answers and architecture materials while the commercial scope is still moving. Those answers can later become warranties, implementation assumptions or evidence used to interpret the agreement.

The supplier therefore needs more than a contract template. Its proposal, product facts, procurement answers, regulatory analysis, security evidence and contract commitments should describe the same operating reality. The responsible teams need an agreed position on what the service does, what the customer asks for, what law requires and what the business can perform.

This guide reflects the position as at 5 August 2026. It is a practical framework rather than a complete assessment: the customer, supplier, product architecture, data flows, intended purpose, deployment model and Member State may require separate legal, security or local-law review.

1. Define what the customer is actually buying

Start with the delivery model: a multi-tenant SaaS subscription, API access, hosted or embedded AI, a private or dedicated deployment, on-premises software, implementation services or a combination. A pilot also needs a defined purpose, dataset, environment, success criteria and route to production; it should not silently become an unrestricted production commitment.

The order should identify the contracting entity, users and affiliates, territories, standard functionality and customer-specific work. Those facts affect pricing, support, acceptance, data flows, security, intellectual property and regulatory roles. AI and SaaS are not synonyms: SaaS may contain no regulated AI, while AI may be delivered by API, licence, embedded component or managed service. The documents should follow the architecture, not the marketing label.

2. Map the AI Act position before answering the customer

First determine whether the offering is an AI system, uses a general-purpose AI model, or is conventional software. Calling it "AI-powered" does not decide that issue. If the AI Act is relevant, map provider, deployer, importer, distributor and upstream model-provider roles by the functions performed, including territorial links for a non-EU supplier. The contract can allocate cooperation and recourse, but cannot change a mandatory public-law role by label alone.

Intended purpose and customer use matter. The same technology can produce a different role or risk analysis when rebranded, integrated, substantially modified or used in another context. Not every AI vendor provides a high-risk system. Transparency duties, model-level GPAI duties and high-risk classification should be assessed separately, including upstream documentation dependencies.

As at 5 August 2026, the AI Act applies with the timetable amended by Regulation (EU) 2026/1744. Article 50 generally applies from 2 August 2026, although providers of systems generating synthetic audio, image, video or text content that were placed on the market before that date have until 2 December 2026 to comply with Article 50(2). Sections 1, 2 and 3 of Chapter III, except Article 6(5), apply from 2 December 2027 for high-risk systems classified under Article 6(2) and Annex III, and from 2 August 2028 for systems classified under Article 6(1) and Annex I. Procurement may request a forward plan before those later dates, but the response should distinguish current duties from planned readiness.

3. Separate law, customer policy and negotiation position

Classify each customer request before accepting or rejecting it: law applying to the supplier; an obligation applying primarily to the customer; operational support the customer needs; customer policy; or negotiable risk allocation. Requests to follow customer laws, complete an impact assessment, localise data, permit audits or notify regulatory contacts can combine those elements.

A regulated customer may have a legitimate need for supplier evidence or cooperation even where the supplier is not directly subject to the same rule. Conversely, a questionnaire or customer AI policy is not itself legislation. The useful response explains what applies, what the supplier can support, what needs qualification and which additional obligation would require a product, process, price or risk decision.

4. Map personal-data roles and international transfers

Document personal-data flows by purpose, data category, data subject, location and recipient. Controller, processor, joint-controller and independent-controller roles follow who determines purposes and essential means and who processes on whose behalf. Joint controllership requires actual joint determination, not merely interaction. Where the supplier is a processor, Article 28 GDPR terms should cover instructions, security, subprocessors, assistance, return or deletion and audit information.

International transfers require separate analysis. Transfer SCCs under Decision (EU) 2021/914 may be relevant for a third-country transfer without adequacy or another valid mechanism, together with a transfer assessment and any necessary supplementary measures. They are not required in every contract with a non-EU vendor. They are also distinct from Article 28 processor terms: Decision (EU) 2021/915 provides optional standard contractual clauses for controller-processor relationships, while Decision (EU) 2021/914 provides transfer clauses under Chapter V GDPR. A privacy notice and security annex perform separate functions. A single document may sometimes contain more than one function, but the legal analyses remain distinct.

5. Prepare an evidence-based customer response pack

A proportionate response pack may include product and architecture, data-flow and hosting, privacy and data-use, subprocessor and third-party, transfer, security, incident, continuity, AI Act role, model dependency, service-level, retention, deletion and exit information. Certifications and insurance evidence should be included only where genuinely held.

The pack should answer what is true for the product and deal, not what appears most convenient in a form. Material limitations should be disclosed clearly and proportionately. Version control also matters: a stale questionnaire, sales deck or security statement can contradict the contract or current architecture.

6. Control product, AI and security claims

Review claims across the website, sales deck, procurement response, product documentation and agreement. Statements about performance, accuracy, human oversight, training data, encryption, hosting, certification or compliance need an identified basis and owner. Absolute claims such as "fully GDPR compliant" or "AI Act certified" are rarely useful if the product facts require qualification.

Qualified, evidence-based language can be commercially stronger because it tells the customer what control exists, its scope and any dependency. A policy or security overview describes the current control environment; a contract creates enforceable commitments. If questionnaire answers are incorporated by reference or treated as warranties, inconsistencies may create misrepresentation or performance risk.

7. Set rules for customer data, prompts, outputs, training and feedback

Separate customer inputs and uploaded data, prompts, outputs, usage and telemetry data, operational logs, abuse-monitoring data, feedback and feature requests. For each category, define permitted purposes, retention, access, confidentiality and whether use for model or product improvement is mandatory, optional or excluded. Any claim that data is anonymised or aggregated should match the actual process and the legal standard being relied on.

Ownership wording does not answer every lawful-use question. A supplier acting as processor cannot use customer personal data for its own training purpose merely because a commercial clause grants improvement rights; processing in the processor role must remain within the controller's documented instructions. If the supplier determines a separate training purpose and the essential means of that processing, it must assess the resulting controller role and the corresponding lawful basis, transparency and purpose-compatibility requirements. Training rights should not be hidden in generic licence language. Output ownership and non-infringement positions need qualification for the product, inputs, upstream terms and applicable law, not a universal copyright conclusion.

8. Address third-party models, subprocessors and open-source dependencies

List the dependencies needed to deliver the service: model providers, cloud infrastructure, subprocessors, external APIs, licensors and material open-source components. These are different categories. A technology provider is a GDPR subprocessor only where it processes personal data on behalf of the supplier in the relevant chain; an upstream model provider, licensor or ordinary subcontractor is not automatically a subprocessor.

The agreement should reflect use restrictions, geographic processing, licence and pass-through terms, availability dependencies and the ability to change a provider. Notice, objection and termination rights should match real alternatives. A promise never to change a subprocessor, model or infrastructure may be incompatible with a maintained service, while unrestricted change rights may be unacceptable for a critical dependency.

9. Set security, incident and resilience commitments the supplier can perform

Commitments on access control, encryption, vulnerability management, incident handling, business continuity, disaster recovery, backups and any stated recovery objectives should describe controls that exist and can be evidenced. Define the contractual incident trigger, notification recipient, initial information, update cadence, investigation and cooperation duties. A contractual notification can be earlier or broader than a statutory notice, so the supplier needs an internal process capable of meeting it.

Customer requirements may reflect national law implementing NIS2, sector rules or policy. Article 21 NIS2 addresses supply-chain security for essential and important entities, and Implementing Regulation (EU) 2024/2690 details supplier-contract measures for the specific categories of relevant entities that it covers, including certain cloud, data-centre, managed-service and online-service providers. This can explain requests about audits, incidents, vulnerabilities and subcontracting, but does not prove that every SaaS vendor is directly subject to NIS2. Outside the Implementing Regulation's defined scope, applicable rules may differ across Member States.

10. Build the correct contract stack

An enterprise deal may use a master services agreement, order form, statement of work, service description, SLA, data-processing agreement, transfer clauses, security annex, acceptable-use policy, AI schedule and support or implementation terms. Each document needs a defined function. The order of precedence should resolve conflicts, particularly where customer purchase orders, online terms, policies or questionnaire answers are incorporated by reference.

Online terms and unilateral updates require care in a negotiated enterprise deal. A customer will need to know which version applies and whether a material change can alter price, functionality, security or data use. Several polished documents that contradict one another can create more risk than one missing clause.

Choose governing law and forum deliberately. Rome I generally respects a commercial choice while preserving relevant overriding mandatory rules, and Brussels I bis can support a qualifying Member State court agreement. The choice should account for enforcement and any required local-law advice.

11. Define service scope, support, acceptance and change control

Set subscription scope, users and affiliates, permitted use, usage limits, customer dependencies, support hours, maintenance, uptime measurement, exclusions, service credits and change procedures for features, APIs and integrations. Commitments should match actual monitoring and support capacity. Beta functions and pilots need limits and a clear conversion or expiry route.

Ordinary access to a standard SaaS product may not fit bespoke-software acceptance testing. Implementation, integration or custom development may need objective acceptance criteria and deemed-acceptance mechanics. Service credits can be a proportionate remedy for some service-level failures, but need not be the exclusive remedy for every breach. Customer paper should not determine the product model accidentally.

12. Allocate intellectual property and customer-specific development

Distinguish background intellectual property, the platform and service, customer data, configurations, integrations, documentation, custom deliverables, feedback, improvements, third-party materials and open-source components. Then define ownership, licence scope, restrictions, confidentiality and permitted reuse. EU software copyright and trade-secret rules form part of the legal setting, but the commercial answer still depends on what is built and funded.

The customer need not own every configuration or improvement. Equally, the supplier should not assume an unrestricted right to reuse confidential customer-specific work. The position should reflect funding, whether the work is productised, the customer's operational need, third-party rights and pricing, with sufficient transition rights if the service ends.

13. Negotiate warranties, liability, indemnities and insurance as one package

Review authority and contract-validity warranties together with service-conformity, documentation, malicious-code, legal-compliance, data-protection, confidentiality, security, IP and AI-output warranties against the actual service. A blanket warranty to comply with every law applicable to the customer can exceed the supplier's role. A broad output non-infringement warranty may also ignore customer inputs, prompted uses, downstream modification and the limits of upstream model terms.

Liability caps cannot be assessed alone. Read excluded losses, super-caps, uncapped risks, indemnities, service credits, termination rights and insurance together, including overlapping remedies for the same event. Indemnities need control of defence, settlement, evidence and mitigation. Additional risk may require a narrower commitment, operational change, insurance confirmation or commercial price rather than an improvised exception to the cap.

14. Keep audits and regulatory cooperation proportionate

Use an evidence ladder: current questionnaires and response packs, independent reports or certifications where held, remote review, trigger-based audit and on-site access only where justified. Set frequency, notice, scope, confidentiality, cost and remediation rules. This can give a regulated customer useful assurance without exposing other customers, trade secrets or security-sensitive systems through unlimited access.

Regulatory cooperation clauses should identify the relevant matter, information and response process. The customer contract may allocate assistance and cost between the parties, but cannot restrict a regulator's statutory powers. A customer-authority request also needs review for privilege, confidentiality, data protection and legal limits before information is disclosed.

15. Plan termination, deletion, portability and switching

Address ordinary termination, breach, insolvency, security or regulatory risk, suspension, transition assistance, export format, retrieval period, continued access, deletion, backups, licence wind-down and fees. Contract termination, GDPR return or deletion, and service switching are related but not identical. The exit design should be tested against what the product can export and erase, including backup cycles and dependencies on third parties.

Where the service meets the Data Act definition of a data processing service, Chapter VI requires written switching terms, including a notice period of no more than two months, an ordinary maximum transition period of 30 calendar days and at least 30 calendar days for retrieval after that period. If the 30-day transition is technically unfeasible, the provider must notify and justify that position within 14 working days of the request and specify an alternative transition period not exceeding seven months. The contract must also address exportable data, security and erasure. The definition can cover SaaS, but not every software licence or hosted product necessarily qualifies, and non-production testing and evaluation services supplied for a limited period receive a specific exemption.

As at 5 August 2026, a provider may still impose reduced switching charges that do not exceed costs directly linked to the switch. From 12 January 2027, switching charges must not be imposed. Standard service fees, proportionate early-termination penalties and separately requested additional services are distinct. The contract should not promise a broader migration result than the law, architecture and supplier can deliver.

16. Build the negotiation position before receiving customer paper

Prepare an issues matrix with the preferred position, acceptable fallback, escalation point, deal-breaker, internal owner and approval authority for each major topic. Mark facts needing technical confirmation, obligations requiring operational implementation and requests that should affect price or delivery. Decide whether a gap needs a product change, process improvement or contract exception rather than discovering that choice during a customer call.

This structure makes clause negotiation serve the deal. It also prevents one team from accepting a warranty, deadline or data use that another team cannot perform. Clause-by-clause improvisation may produce a signed document, but not an executable agreement.

17. A practical pre-signing checklist

Before signature, confirm:

• the exact product, delivery model, contracting entity, users and permitted territories;
• the pilot or production scope and intended customer use;
• the AI Act system, model, role, territorial and risk position;
• the personal-data roles, data-flow map and international-transfer position;
• the current, evidence-based customer response pack;
• approved product, AI, performance, privacy and security claims;
• the subprocessor, model-provider and other material dependency list;
• service, support, incident and resilience commitments the teams can perform;
• customer-data, prompt, output, training and feedback rights;
• background IP, customer-specific work and third-party licence positions;
• authority for warranties, indemnities, liability caps and insurance statements;
• the proportionate audit and regulatory-cooperation position;
• termination, export, retrieval, deletion, portability and switching mechanics;
• and issue owners, escalation points and signature authority.

18. How Tatra Legal can help

Tatra Legal can help define the EU-facing contract and procurement workstream, map AI Act and data-protection roles, review questionnaires and supporting evidence, and prepare a coherent customer response pack. The work can then move into negotiation positions, drafting or review of the agreement stack and direct negotiation with the customer or its lawyers.

Where the matter requires technical, security, AI, data-protection or Member State input, relevant specialists can be coordinated under an agreed scope. Ongoing support can maintain positions across repeat enterprise deals. This does not guarantee procurement approval, signature, customer acceptance, certification or compliance in every jurisdiction.

Preparing for an EU enterprise procurement or contract process? Tatra Legal can help align the product facts, regulatory position, customer evidence and contract terms, then support the negotiation towards an executable agreement.

19. Practical takeaway

The deal starts before the customer's first redline. Product facts, evidence and contractual commitments should remain aligned, and customer requests should be classified rather than accepted or rejected automatically. A supplier should promise only what it can perform, with third-party dependencies and internal approvals understood. Exit and switching belong in that analysis before signature, not only when the relationship ends.

Legal references

• Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744, in particular Articles 2-3, 6, 25, 50, 53-56, 111 and 113 and Chapter III, Sections 1-3.
• European Commission guidelines on AI system definition, Article 50 transparency and GPAI provider obligations.
• European Commission General-Purpose AI Code of Practice, as an assessed voluntary compliance tool rather than binding law.
• Regulation (EU) 2016/679, in particular Articles 4, 26, 28, 32-33 and 44-49.
• Commission Implementing Decisions (EU) 2021/914 and (EU) 2021/915.
• EDPB Guidelines 07/2020 on controller and processor concepts and Recommendations 01/2020 on supplementary transfer measures.
• Regulation (EU) 2023/2854, in particular Articles 2(8), 23-31 and 50.
• Directive (EU) 2022/2555, in particular Article 21, and Commission Implementing Regulation (EU) 2024/2690, Annex point 5.1, where applicable.
• Directive 2009/24/EC on the legal protection of computer programs.
• Directive (EU) 2016/943 on the protection of trade secrets.
• Regulation (EC) No 593/2008, in particular Articles 3, 4 and 9.
• Regulation (EU) No 1215/2012, in particular Article 25 and the rules on recognition and enforcement of judgments.