Terms and conditions for a subscription-based application downloaded from the internet. An added paragraph on artificial intelligence. Statutory warranty rights excluded for consumers. A content licence granted by an entity that did not upload the content. No procedure for reporting illegal content in an application that publishes user content. And no answer whatsoever to the question of who is liable for a model hallucination inserted into an official document.
This is what SaaS terms and conditions with AI look like for most products that allow people other than the customer’s employees to access the interface. If your product has a public-facing layer — a feedback form, issue map, comments section, marketplace — and an AI module, this article is for you.
I will explain the structural decisions you need to make so that a single set of terms can cover four legal categories of users: a B2B/B2G customer, a member of their team, a consumer with a free account, and an unregistered guest. For each decision, I will indicate what needs to be included in the document and what needs to be built into the product.
Four legal categories in one set of SaaS terms and conditions — why this is a problem
The prevailing market narrative divides terms and conditions into B2B or B2C. A real SaaS product with a public-facing layer requires both at once — plus standard terms binding anonymous guests. Each of these layers is subject to different limits on freedom of contract.
| User category | Example | Basis for being bound by the standard terms | Limits on freedom of contract |
|---|---|---|---|
| Professional customer (B2B/B2G) | Public authority, consulting firm, property developer | Subscription agreement, acceptance of the terms and conditions | Broad — exclusion of statutory warranty rights, liability cap, jurisdiction clause in favour of the courts at the provider’s registered office |
| Member of the customer’s team | External consulting firm granted access by the customer | Terms and conditions accepted when registering an account | Broader than for consumers, but requires a separate data processing agreement |
| End user with a free account (consumer) | Resident creating an account in a public consultation application | Acceptance of the terms and conditions upon registration | Limited — Articles 385¹ and 385³ of the Civil Code, the Consumer Rights Act, GDPR |
| Unregistered guest | Person accessing the application through a public link, without a checkbox | Article 8(3) of the Act on the Provision of Electronic Services | Limited — there is no checkbox, so the terms are binding if made available before the service begins |
If your terms and conditions do not distinguish between these categories, clauses copied from a B2B template — exclusion of statutory warranty rights, a liability cap limited to the amount of the fee, jurisdiction of the courts at the provider’s registered office, confidentiality — will be ineffective or unfair in relation to consumers under Articles 385¹ and 385³ of the Civil Code. You believe you are protected when you are not.
Key concepts you need to know
Before we move on to specific structural decisions, it is worth clarifying the terminology. The concepts below appear later in this article and have precise legal meanings.
| Concept | What it means | Why it matters for the terms and conditions |
|---|---|---|
| Input Data | Anything entered into the application — text, files, prompts, comments | Without this definition, you cannot establish a licence for user content or draft a model-training clause |
| Output | Anything the application generates automatically — summaries, classifications, ratings, alerts, visualisations | Without this definition, you cannot distinguish liability for a model error from the customer’s liability |
| Verification buffer | A system state in which generated content exists but has not been published — publication requires approval by a professional user | Turns a statement about the “need for verification” into a product feature |
| Right of access | A non-exclusive, non-transferable right, limited to the subscription term, to use the features through the interface — instead of a software licence | In a cloud model, the code is not reproduced on the user’s side, so a copyright licence is imprecise |
| Unfair contract term | A contractual provision that has not been individually negotiated and shapes the consumer’s rights in a manner contrary to good practice, grossly infringing their interests (Article 385¹ of the Civil Code) | Exclusion of statutory warranty rights, binding provider measurements, jurisdiction at the provider’s registered office — these may be ineffective against consumers |
Get in touch — if you are unsure which of your clauses need to be revised.
How to bind someone who has not clicked a checkbox to the terms and conditions
This is one of the most common questions asked by SaaS providers with a public-facing layer. The answer is provided by Article 8(3) of the Act on the Provision of Electronic Services: the terms and conditions are binding if they were made available before the service began in a manner that allows them to be obtained, reproduced and stored.
For an unregistered guest, this means three requirements:
- The terms and conditions must be visible and accessible before the guest begins using the features — for example, on the public-link page, before the form is opened.
- The guest must be able to download the terms and conditions in a format that can be saved (e.g. PDF).
- The interface must document this — for example, by logging when the terms and conditions were displayed before the first interaction.
A checkbox is not required. But if you do not use one, you must design the interface to meet the requirements of Article 8. This is a product decision, not a legal one.
Recommendation: make participation with an account the default configuration. Leave the decision to enable anonymous mode to the customer — together with their obligation to provide information to end users.
Layering the terms and conditions — three regimes within a single clause
The standard approach is to create two versions of the document: one for B2B customers and one for consumers. This approach does not work in a product with four user categories — it creates gaps and inconsistencies.
A better solution is one set of terms and conditions, layered according to the party’s status rather than by subject matter. Each clause concerning liability, confidentiality, disputes or payments contains three regimes:
| Regime | Who it covers | Example liability clause |
|---|---|---|
| Business user | B2B/B2G customer, team member acting in the course of business | Exclusion of statutory warranty rights (Article 558 § 1 of the Civil Code), liability capped at the fees for 12 months, jurisdiction of the courts at the provider’s registered office |
| Consumer and sole trader with consumer rights | End user with a free account, sole trader acting outside their professional field | No exclusion of statutory warranty rights, liability for failure of the digital service to conform to the contract (Articles 43m and 43n of the Consumer Rights Act), jurisdiction determined under the general rules |
| Common regime | All users | Exclusion of liability for force majeure (including sudden unavailability of cloud provider interfaces, failures of external models, or an administrative ban on the use of AI technology), the specific characteristics of AI output |
This technique eliminates the need for two documents and makes each clause clear for every user category.
Six structural decisions for the AI layer in the terms and conditions
Decision 1 — a verification buffer instead of a declaration about verification
The sentence “the user should verify the outputs” has no legal value if the interface does not enforce verification. A probabilistic model may produce different outputs for the same input data, and an output may simply be false.
If an institution bases a report on an automated summary and the report becomes part of official records, the model error ceases to be a software quality issue and becomes a defect in the administrative process.
What to include in the terms and conditions:
- State explicitly that AI output is probabilistic and may contain errors.
- Prohibit decisions with external effects from being based solely on automated output (consistent with Article 22 GDPR and Articles 14 and 50 of the Artificial Intelligence Act).
- Describe the verification buffer as a system state: generated content exists but is not published until approved by the customer.
What to build into the product:
- An intermediate state — generated content visible to the professional user but not published.
- An approval button without which the content cannot enter the public view.
- Logging of the approval time and the identity of the person who approved it.
Decision 2 — labelling AI content in the interface and metadata
Article 50 of the Artificial Intelligence Act imposes an obligation to label AI system outputs in a machine-readable format. It applies from 2 August 2026. The obligation applies to every natural person interacting with the system — regardless of their contractual status in relation to the provider.
Labelling in the interface alone is not enough. A user exports a report to a file and removes the label. Two layers are therefore required:
- Interface label — visible information that the content was generated or assisted by AI.
- Metadata in exported files — a machine-readable label that survives export.
And a third layer — a prohibition on users removing labels, included in the terms and conditions. Without this prohibition, the label disappears at the first stage of the document workflow.
Decision 3 — status of AI output: no exclusivity
During negotiations, the customer asks: “Is a visualisation generated by the tool exclusively mine? Can I prohibit others from using a similar one?”
An answer set out in the terms and conditions is cheaper than a dispute. Material generated entirely automatically may not constitute a work within the meaning of Article 1 of the Copyright Act. The customer acquires a right to use it, but not exclusive rights. Another user may obtain a similar output from a similar query.
What to include in the terms and conditions:
- AI output does not constitute a work within the meaning of copyright law unless the user’s creative contribution is significant enough for the output to satisfy the criteria of Article 1.
- The customer acquires a non-exclusive, non-transferable right to use the output.
- The provider does not guarantee that the output will be unique.
Decision 4 — a licence for content from a user who is not your customer
The provider needs a licence for the content in order to process it using the model. But it cannot obtain that licence from the author because the author (e.g. a resident using a public consultation form) does not enter into any agreement with the provider.
The solution is a two-track structure:
- For the end user and guest: a licence granted when the content is submitted, linked to information displayed next to the form or on the project page — before the user types the first character.
- For the professional customer: a representation and warranty that they hold the rights and consents required for data entered into the application, together with a clause indemnifying the provider against claims concerning copyright, personality rights and privacy.
Decision 5 — a two-way model-training clause
The training clause must be symmetrical. Without that symmetry, it reads like a unilateral appropriation of the customer’s data.
| Direction | What it governs | Sample provision |
|---|---|---|
| Third-party provider models | Exclusion of input data from the training of public commercial models | “The customer’s input data is not used to train or fine-tune public models operated by third-party providers” |
| The provider’s own models | The right to aggregate and irreversibly anonymise data to train the provider’s own models | “The provider may use anonymised and aggregated data to develop its own models, provided that the data is irreversibly anonymised” |
| Competing models | Prohibition on training competing models using the outputs | “The customer may not use outputs to train or fine-tune models that compete with the application” |
The first point must be confirmed in agreements with model providers — a provision in the terms and conditions alone is not enough.
Decision 6 — the DSA layer for an application that publishes user content
If your application stores and publicly disseminates user content, it may qualify as a hosting service or an online platform within the meaning of the Digital Services Act (DSA). The President of UKE is Poland’s Digital Services Coordinator, and the Act of 4 September 2026 provides for the possibility of imposing a periodic penalty payment of up to 5% of the average daily turnover of the intermediary service provider for each day of non-compliance.
Minimum elements of the DSA layer in the terms and conditions:
- A point of contact (Articles 11 and 12 DSA).
- A mechanism for reporting illegal content, including formal requirements for notices (Article 16 DSA).
- A statement of reasons for decisions restricting content, including information about the use of automated tools (Article 17 DSA).
- An internal complaint-handling system — a free appeal within six months, reviewed by qualified staff (Article 20 DSA).
- Measures against misuse of the notice system (Article 23 DSA).
- Separate catalogues of illegal content and content that breaches the terms and conditions.
Providers that are micro or small enterprises may benefit from the exemption from Section 3 of Chapter III DSA (Article 19), but only if their service qualifies as an online platform and they meet the size criterion in Recommendation 2003/361/EC. The exemption does not cover the entire DSA — the hosting provider obligations under Articles 16–18 remain applicable.
An important boundary: technical support should not include advice on moderating end-user content. This deliberately distances the provider from the role of substantive moderator in someone else’s process.
GDPR — allocation of roles and special categories of data
The terms and conditions must assign GDPR roles and refer to a separate data processing agreement, specifying that it takes precedence in the event of a conflict. Three obligations that providers forget:
- Requiring the customer to enter into its own data processing agreement with an external entity to which it grants access as a team member (e.g. a consulting firm conducting consultations on behalf of a public authority).
- Limiting the scope of data in unregistered mode — a recommendation not to disclose special categories of data (Article 9 GDPR) in free-text statements. A resident’s comment in a consultation on a road development may contain information about their health, family circumstances and address. Special-category data may be disclosed incidentally.
- Information obligations towards third parties (Article 14 GDPR) — where user content contains the data of individuals who do not themselves interact with the application.
Processing content containing data covered by Article 9 GDPR requires a separate legal basis under Article 9(2) — a legal basis under Article 6(1) alone is not sufficient. If content is subsequently reused to train a model, the purpose of processing must be specified more precisely and a data protection impact assessment must be conducted (Article 35 GDPR).
SLA, billing and offboarding — what to change in standard clauses
Availability — what the guarantee actually covers
If you exclude failures of the cloud and cloud provider interfaces from downtime, the guarantee covers only a narrow layer under your own control. AI operations are processed asynchronously and independently of connection bandwidth — excluding them from a responsiveness guarantee is justified, but the customer must be aware of it.
A provision stating that measurements taken using the provider’s tools are binding may be considered unfair in relation to consumers (Article 385³ point 19 of the Civil Code — granting an exclusive right to alter the characteristics of the performance).
Billing — billing unit and AI operations allowance
A billing model based on the actual unit of sale (e.g. project rather than seat), plus a separate allowance of units for AI operations, requires three provisions:
- Unused units do not roll over between billing periods.
- AI features are blocked when the allowance is exhausted — with a clear message in the interface.
- Top-ups are charged pro rata based on the number of days remaining in the period.
For automatically renewing subscriptions, provide: a reminder before renewal, an easy way to cancel before the fee is charged (no later than 1 day before the next period begins), and a separate procedure for changing prices for consumers, requiring active consent.
Offboarding — grace period and data export
After termination of the agreement, data should remain available in read-only mode and for export for a specified period (e.g. six months), in a machine-readable format — consistent with the requirements of the Data Act (2023/2854) and the obligation to provide content following a consumer’s withdrawal from the contract.
After the grace period — irreversible deletion or complete anonymisation. But be careful: if your customer is a public-sector entity, the standard clause stating that “all data will be deleted after the service ends” may conflict with archiving obligations under the Regulation of the Prime Minister of 18 January 2011 and the Act on the National Archival Resources. The terms and conditions must provide for deletion to be suspended for the duration of the archiving obligation and for export in an agreed format.
Public-sector customers — what to change in the standard terms so they pass the procurement process
If you sell to public-sector entities, compare your standard terms with their obligations:
| Standard SaaS clause | Problem for the public-sector customer | What to change |
|---|---|---|
| Non-refundable fees | Public procurement rules and public finance discipline — non-refundability must be justified by the service model | Describe the setup and resource reservation costs that justify non-refundability |
| Price adjustment without an amendment | Article 439(1) of the Public Procurement Law requires a price adjustment mechanism in contracts lasting more than 6 months, but the mechanism cannot transfer all risk to the contracting authority | Specify an objective index (e.g. Statistics Poland), a trigger threshold and a price adjustment cap |
| Deletion of data after the agreement ends | Consultation records are subject to archiving, and outputs may constitute public information (Act on Access to Public Information) | Provide for export before deletion and suspend deletion for the duration of the archiving obligation |
| Liability cap | Article 433 of the Public Procurement Law prohibits transferring the contractor’s sole liability to the contracting authority | A monetary cap is permitted, but it cannot exclude liability for intentional harm, breaches of confidentiality or breaches involving personal data |
| No digital accessibility requirements | Digital Accessibility Act — a public-sector entity must ensure that the application is accessible in accordance with EN 301 549/WCAG | Include an obligation in the agreement to design and maintain the application in accordance with WCAG; the public authority remains responsible towards residents, but the provider is contractually liable |
Checklist — what to review in SaaS terms and conditions with AI
| No. | Area | Review question | Priority |
|---|---|---|---|
| 1 | User categories | Do the terms and conditions distinguish between all categories of people using the product, including unregistered guests? | Required |
| 2 | Incorporation of standard terms | Does a guest without an account see the terms and conditions before they begin using the features, and can they download them? | Required |
| 3 | Unfair contract terms | Does every clause limiting liability, excluding statutory warranty rights or specifying court jurisdiction include an explicit carve-out for consumers? | Required |
| 4 | AI definitions | Do the terms and conditions define input data and output separately? | Required |
| 5 | Verification buffer | Is verification of AI outputs a product feature rather than merely a sentence in the terms and conditions? | Required |
| 6 | Labelling AI content | Is AI content labelled in the interface and in the metadata of exported files, and do the terms and conditions prohibit the removal of labels? | Required |
| 7 | Status of the output | Do the terms and conditions describe the output as non-exclusive and explain the uncertainty as to whether it qualifies as a work? | Required |
| 8 | Licence for user content | Is the content licence granted upon submission (for the end user) and supported by a representation from the customer (for B2B)? | Required |
| 9 | Training clause | Does the clause distinguish between three directions: external models, proprietary models and competing models? | Required |
| 10 | GDPR | Are the roles assigned, is the data processing agreement separate, and is the customer required to enter into its own data processing agreement with external team members? | Required |
| 11 | DSA | Does the application publishing user content have a point of contact, a notice mechanism, reasons for sanctions and an appeal procedure? | Required |
| 12 | SLA | Has the customer knowingly accepted the list of exclusions from the availability guarantee? | Recommended |
| 13 | AI billing | Do the terms and conditions describe what happens when the allowance is exhausted, the absence of rollover and the pro rata top-up rule? | Recommended |
| 14 | Offboarding | After the agreement ends, is the data available in read-only mode and for export in a machine-readable format? | Recommended |
| 15 | Public-sector customer | Do the standard terms account for archiving, public information, digital accessibility and the public procurement regime? | Recommended |
How we can help organise the terms and conditions for your SaaS product with AI
SaaS terms and conditions with AI are not a document to copy — they are a set of product decisions. Three of them — the verification buffer, labelling AI content and the notice procedure — do not exist unless they are implemented in the code.
We help SaaS providers move from a template downloaded from the internet to terms and conditions that reflect the actual product and cover every legal category of user. We work at three levels:
- Audit of the current standard terms — a review of the terms and conditions for ineffective clauses, missing layers (consumer, DSA, AI Act) and discrepancies with the product. Outcome: a list of critical revisions with a risk assessment.
- Restructuring the terms and conditions — layered standard terms with AI definitions, training clauses, a licence for user content, a data processing agreement and a billing model tailored to the product.
- Complete documentation — terms and conditions, AI policy, DSA procedure, data processing agreement and a sales pathway for public-sector entities that takes account of WCAG, archiving and the public procurement regime.
We understand the realities of product teams: rapid deployments, concurrent projects and limited resources. That is why we design rules where the risk actually arises — we do not create documents just in case.
Contact us — we will determine which option is right for your product’s current stage.
Summary
A single set of SaaS terms and conditions with AI must cover four legal categories of users — otherwise, the clauses you rely on will be ineffective against some of them. Each of the six structural decisions described in this article requires changes both to the document and to the product. The transparency obligations under the Artificial Intelligence Act (Article 50, applicable from 2 August 2026) and the requirements of the Digital Services Act apply to your product regardless of whether you address them in the terms and conditions.
Review your standard terms. Identify the gaps. If you need support — contact us.
Frequently asked questions
Are my terms and conditions binding on someone who uses the application without registering and does not accept any checkbox?
Yes, provided that the requirements of Article 8(3) of the Act on the Provision of Electronic Services are met — the terms and conditions must be made available before the service begins, in a manner that allows them to be obtained, reproduced and stored. A checkbox is not required, but the interface must document when the terms and conditions were made available.
Do I need two separate documents — one for business customers and another for end users?
No. A better solution is one set of terms and conditions layered according to the party’s status. Each clause concerning liability, confidentiality or disputes contains three regimes: one for business users, one for consumers and sole traders with consumer rights, and a common regime. This eliminates gaps and inconsistencies between two documents.
Which of my current clauses are ineffective against consumers?
Most commonly: exclusion of statutory warranty rights (Article 558 § 1 of the Civil Code applies only to business users), a liability cap limited to the amount of the fee, jurisdiction of the courts at the provider’s registered office, a confidentiality clause, and a provision stating that the provider’s measurements are binding. In relation to consumers and sole traders with consumer rights, these may be deemed unfair under Articles 385¹ and 385³ of the Civil Code.
Who is liable if the model generates a false summary and my customer uses it in an official document?
The terms and conditions should allocate liability: the provider is responsible for making a verification mechanism available (the verification buffer), while the customer is responsible for approving the content before publication or use in a process. Without a verification buffer in the product, the allocation of liability described in the terms and conditions may be difficult to enforce.
Is my application an online platform within the meaning of the DSA?
If it stores and publicly disseminates user content — it may be. An online platform within the meaning of Article 3(i) DSA is a hosting service that stores and publicly disseminates information at the request of a recipient. Storage alone, without public access, does not qualify as a platform. Classification requires an assessment of your product’s technical and contractual model.
Can I train my own models using customer data if I anonymise it?
The terms and conditions should expressly provide for this possibility — the right to aggregate and irreversibly anonymise data to train proprietary models. However, the anonymisation must genuinely be irreversible (not pseudonymisation), and if the content may contain data covered by Article 9 GDPR, you need a separate legal basis under Article 9(2) and a data protection impact assessment (Article 35 GDPR). A provision in the terms and conditions alone does not replace technical verification of the anonymisation process.
