You downloaded a terms and conditions template, added a paragraph about artificial intelligence, and published it on your website. The result: the statutory warranty is excluded for consumers, a license to content is granted by an entity that did not submit that content, there is no procedure for reporting illegal content, and no answer whatsoever to the question of who is liable for a model hallucination pasted into an official record. Your SaaS terms and conditions do not protect you in any of these four areas.
The problem is not a lack of diligence. It stems from the fact that a standard template assumes a single relationship: provider–customer. Meanwhile, your application allows access to a B2B customer, a consumer with a free account, and an anonymous guest using a public link. Each of these people is subject to a different legal regime. Add an AI module, obligations under the Digital Services Act (DSA), and sales to the public sector—and a downloaded template becomes a source of risk rather than protection.
In this article, I will explain seven structural decisions you need to make for your terms and conditions to work for all categories of users. Each of them changes not only the document, but the product itself.
Key concepts you need to know
Before we move on to specific decisions, it is worth clarifying the terminology. SaaS terms and conditions for a product with an AI module sit at the intersection of several regulatory frameworks, each of which uses its own definitions.
| Concept | What it means | Why it matters for the terms and conditions |
|---|---|---|
| Right of access | A non-exclusive, non-transferable right to use the application through a browser or API, limited to the subscription term. In the SaaS model, the user does not make a copy of the code—the user receives only the output produced by the software. | Most templates on the market use the language of a “license” carried over from software implementation agreements. This is a mistake—it affects the liability regime and the procedure for terminating the agreement. |
| Input data | Everything submitted to the application: files, text, prompts, comments, and forms. | The terms and conditions must distinguish input data from output—because the rights to them, responsibility for their content, and the legal basis for processing differ. |
| Output | Everything the application generates automatically: summaries, classifications, assessments, alerts, and visualizations. | The model is probabilistic—it may produce different output for the same input data, and that output may be false. This changes the scope of liability and requires separate clauses. |
| DSA (Digital Services Act) | Regulation (EU) 2022/2065 governing the obligations of providers of intermediary services—including platforms that publish user content. It has applied since 17 February 2024. | If your application publishes user content publicly, you are probably subject to DSA obligations: a point of contact, a reporting procedure, and statements of reasons for moderation decisions. |
| AI Act (Artificial Intelligence Act) | Regulation (EU) 2024/1689 governing AI systems in the EU. Article 50 (transparency obligations and the labeling of AI content) applies from 2 August 2026; Article 4 (AI literacy obligation) from 2 February 2025. | The terms and conditions must describe the mechanism for labeling synthetic content—in the interface and in the metadata of exported files. |
| Data Act | Regulation (EU) 2023/2854—applicable from 12 September 2025. Chapter VI imposes switching obligations on providers of data processing services, including SaaS. | The terms and conditions must include a procedure for exporting data in a machine-readable format and an exit path following termination of the agreement. |
| Entrepreneur with consumer rights | A natural person conducting business activity who enters into an agreement that is not directly related to their professional activity. They benefit from consumer protection (Article 385⁵ of the Polish Civil Code). | Clauses effective against an “ordinary” entrepreneur (exclusion of the statutory warranty, limitation of liability) may be ineffective against an entrepreneur with consumer rights. |
Who is on the other side of your application
This question exposes the flaws in every downloaded template. If your SaaS has a public-facing layer—a feedback form, report map, comments section, or participation portal—four categories of entities with different legal statuses operate within a single application:
| User category | Legal status | When the terms and conditions become binding | Scope of protection |
|---|---|---|---|
| Professional customer (B2B/B2G) | Entrepreneur or public-sector entity | Conclusion of the subscription agreement, acceptance of the terms and conditions | Full freedom of contract—exclusion of the statutory warranty is permitted (Article 558 § 1 of the Polish Civil Code), as are a limitation of liability and jurisdiction of the court at the provider’s registered office |
| Member of the customer’s team | A person acting on behalf of the customer (employee, subcontractor) | Acceptance of the terms and conditions when creating an account | Depends on their status—if they act within the scope of the customer’s business, the B2B regime applies |
| Registered end user | Consumer or entrepreneur with consumer rights | Acceptance of the terms and conditions upon registration | Consumer protection: prohibition of unfair terms (Article 385¹ of the Polish Civil Code), right of withdrawal, statutory warranty/conformity with the contract |
| Guest using a public link | An unregistered person who has not accepted a checkbox | Making the terms and conditions available and commencing the provision of services (Article 8(3) of the Polish Act on Providing Services by Electronic Means) | Full consumer protection if the person is a consumer; limited identification options |
Article 8(3) of the Polish Act on Providing Services by Electronic Means links the availability of the terms and conditions to the commencement of service provision, not to a signature. This means that a guest accessing the application through a Facebook link is bound by the terms and conditions—provided that they were available and legible before the guest started using the application.
If your terms and conditions do not distinguish between these four categories, protective clauses (exclusion of the statutory warranty, limitation of liability, confidentiality, and jurisdiction) have only one version. And that version is simply ineffective against consumers and entrepreneurs with consumer rights.
Contact us if you would like to verify whether your terms and conditions distinguish between user categories.
Seven structural decisions for SaaS terms and conditions covering AI
1. Separating liability regimes within a single document
You do not need three separate sets of terms and conditions. You need one template with clearly separated regimes.
The technique is simple: every section in which B2B freedom of contract differs from consumer protection contains separate paragraphs. The first paragraph—the regime for entrepreneurs (statutory warranty excluded, liability limited by reference to fees paid over 12 months). The second paragraph—an express reservation that the preceding paragraph does not apply to consumers or entrepreneurs with consumer rights. The third paragraph—the common regime (force majeure, the specific nature of AI).
You repeat the same technique for:
- Confidentiality—a consumer cannot be required to maintain confidentiality on NDA terms
- Jurisdiction—for consumers, the court with jurisdiction over their place of residence applies
- Availability measurements—a clause stating that the provider’s own measurements are binding may be unfair to consumers (Article 385³ of the Polish Civil Code)
- A marketing clause covering use of a logo—this requires separate consent and cannot be included by default
The maximum penalty imposed by the Polish Office of Competition and Consumer Protection for practices infringing the collective interests of consumers is 10% of the turnover generated in the financial year preceding the year in which the penalty is imposed (Polish Office of Competition and Consumer Protection—unfair terms). This is not a theoretical risk.
2. Human oversight as a system state, not a declaration
“AI output must be verified”—that is just a sentence. It does not protect you from anything.
A review buffer is a system state: AI-generated content exists in the application but is not published until the customer approves it. Publication requires conscious approval by someone familiar with the context.
The difference is fundamental. Imagine this: an AI module summarizes 1,200 comments from residents concerning a road investment plan. The authority pastes the summary into a consultation report, and the report becomes part of the planning documentation. The model omitted an issue raised in 200 comments. If the terms and conditions only contain a declaration about verification, liability for the error is unclear. If the product requires approval before publication, substantive responsibility rests with the person who approved the output while being familiar with the context of the process.
What this requires from the product:
- A “buffer” state in the application—the output is visible but not published
- An approval button that logs the time and identity of the approving person
- An expressly worded prohibition on basing decisions solely on automated output—in the terms and conditions and in the interface
3. Labeling AI content—on two levels
Article 50 of Regulation (EU) 2024/1689 requires AI-generated content to be labeled in a machine-readable format, in a way that is resistant to removal and appropriate to the type of content. The obligation applies from 2 August 2026.
The provision itself does not specify a particular technical standard (C2PA, SynthID, IPTC). The provider must independently select and document a solution that meets the functional requirement.
Labeling must work on two levels:
- Label in the interface—a visible notice that the content was generated or modified by AI
- Metadata in exported files—recorded in a machine-readable format and retained after download
And a third element that most templates overlook: a prohibition on users removing AI labels. Without it, the label disappears at the first stage of the document workflow—and the provider loses evidence that it complied with the obligation.
Penalties for breaches of the AI Act’s transparency obligations may reach EUR 35 million or 7% of global turnover (Regulation (EU) 2024/1689). The national supervisory authority—the Artificial Intelligence Development and Security Commission (KRiBSI)—was established by the Act of 3 July 2026 on Artificial Intelligence Systems (Journal of Laws 2026, item 1003).
4. Rights to AI output—without promises of exclusivity
The model is probabilistic. It may produce different output for the same input data. And the output may simply be false.
The terms and conditions must address three issues:
| Issue | What the terms and conditions should contain |
|---|---|
| Copyright status of the output | Material generated entirely automatically may not constitute a work within the meaning of Article 1 of the Polish Copyright Act—because it lacks an expression of creative activity of an individual nature. The terms and conditions should state this expressly. |
| Scope of the customer’s rights | The customer acquires the right to use the output, but not exclusive rights. The application may generate identical or similar output for another user in response to a similar query. |
| Responsibility for the content of the output | The output is probabilistic and may contain false information. The terms and conditions should name this phenomenon explicitly—instead of using a general “no warranty” disclaimer. |
The absence of this clause creates a gap when a customer wants to prohibit a competitor from using a similar visualization or base an administrative decision on the output. A promise of exclusive rights to AI-generated output is impossible to fulfill—and costly in the event of a dispute.
5. License to user content—a two-track structure
A resident’s comment submitted during consultations concerning an investment may contain information about their health, family circumstances, and address down to the exact building number. The provider needs a license to that content in order to process it using the model. But it cannot obtain the license directly from the author because the author does not enter into any agreement.
The structure must follow two tracks:
- With respect to the end user—the license arises when the content is submitted, based on a mechanism in the terms and conditions combined with a notice displayed next to the form (including for people without an account)
- With respect to the provider—the customer represents and warrants that it has the rights and consents required for content submitted by users participating in its process, together with an indemnity clause covering copyright, personality rights, and privacy
Model training is a separate issue. The terms and conditions should distinguish between three directions:
- Excluding input data from the training of external providers’ public commercial models
- Conditions for using aggregated and irreversibly anonymized data to train proprietary models
- A prohibition on training competing models using the output and interface
6. The DSA layer—if you publish user content
If your application stores information at a user’s request and disseminates it publicly, it is a hosting service—and potentially an online platform within the meaning of Regulation (EU) 2022/2065. Exception: public dissemination is a minor and purely ancillary feature of the principal service (Recital 13 of the DSA).
Obligations that must be reflected in the terms and conditions:
- Point of contact for authorities and users (Articles 11–12 of the DSA)
- Notice-and-action mechanism—a form for reporting illegal content that meets formal requirements, with an exception for material depicting the sexual abuse of children (Article 16 of the DSA)
- Statements of reasons for moderation decisions including information on the use of automated tools (Article 17 of the DSA)
- Internal complaint-handling system—a free appeal within 6 months, reviewed with human involvement (Article 20 of the DSA)
- Measures against misuse of reporting mechanisms—suspension of the rights of persons who frequently submit manifestly unfounded notices (Article 23 of the DSA)
Microenterprises and small enterprises benefit from the exemption from Section 3 of Chapter III of the DSA (Article 19(1)), but not from the hosting obligations in Section 1.
The Polish DSA implementing act (Journal of Laws 2026, item 1296) provides for administrative penalties of up to 6% of worldwide turnover generated in the year preceding the imposition of the penalty.
An additional risk: if technical support answers customer questions such as “can we delete this resident’s comment?”, the provider assumes the role of a substantive moderator in someone else’s process. The terms and conditions should exclude advice on assessing and moderating content created by the customer’s end users from the scope of technical support.
7. An exit path and public-sector readiness
Regulation (EU) 2023/2854 (Data Act) applies from 12 September 2025 and imposes switching obligations on SaaS providers: exporting data in a machine-readable format, removing obstacles to switching providers, and—from 12 January 2027—a prohibition on charging fees for switching providers (except for direct transfer costs).
The terms and conditions should provide for:
- A grace period following termination of the agreement—read-only access and data export (e.g. 6 months)
- A machine-readable export format
- A clear explanation of what happens after the grace period expires (irreversible deletion or anonymization)
- Blocking the deletion of an account with an active project until the owner role has been transferred
If you sell to public-sector entities (local government units, municipally owned companies), standard clauses conflict with the regime that applies to them:
| Standard SaaS clause | Problem in the public sector |
|---|---|
| Non-refundable fees | Conflicts with the principle of equivalence and the obligation to use public funds purposefully |
| Indexation without an amendment (upward only) | Inconsistent with Article 439(2)(4) of the Polish Public Procurement Law—the indexation clause must cover both price increases and decreases |
| 6-month data retention | The authority is required to archive its records—6 months is not enough |
| Exclusion of liability for digital accessibility | Article 5(1) of the Polish Digital Accessibility Act (Journal of Laws 2023, item 1440)—a public-sector entity is responsible for the accessibility of an application made available to residents |
Prepare a version of the template aligned with these obligations—instead of negotiating from scratch for every contract.
What to check in your terms and conditions—a checklist
You can apply the checklist below to your own terms and conditions in a single afternoon. It is not a substitute for a legal audit, but it will show you where the gaps are.
| No. | Checklist question | If the answer is “no” |
|---|---|---|
| 1 | Do the terms and conditions distinguish at least three categories of users (B2B, consumer, guest)? | Protective clauses may be ineffective against consumers |
| 2 | Does the liability clause contain separate paragraphs for entrepreneurs and consumers? | The exclusion of the statutory warranty and limitation of liability are not binding on consumers |
| 3 | Do the terms and conditions define “input data” and “output” separately? | A failure to distinguish between them leads to disputes over rights and liability |
| 4 | Does AI output pass through a buffer state before publication? | A declaration about verification does not transfer responsibility to the customer |
| 5 | Is AI content labeled in the interface and in export metadata? | Risk of violating Article 50 of the AI Act from 2 August 2026 |
| 6 | Do the terms and conditions prohibit the removal of AI labels? | The label disappears at the first stage of the document workflow |
| 7 | Do the terms and conditions expressly state that AI output may not constitute a work and is not exclusive? | Risk of disputes over rights to generated content |
| 8 | Is there a two-track structure for licensing user content (license + customer warranty)? | No legal basis for processing third-party content using the model |
| 9 | Do the terms and conditions separate model training into three directions (external, proprietary, prohibited)? | Risk of allegations that the customer’s data has been misappropriated |
| 10 | Does the application have a point of contact and a procedure for reporting illegal content (DSA)? | Risk of penalties of up to 6% of turnover for failing to provide a notice-and-action mechanism |
| 11 | Do the terms and conditions provide for data exports in a machine-readable format and a grace period? | Non-compliance with the Data Act |
| 12 | Is there a version of the template for public-sector customers (archiving, WCAG, two-way indexation)? | Inability to sell to the public sector or disputes during contract performance |
How we can help
SaaS terms and conditions for a product with an AI module are not a document you can simply download. They are a product decision that requires an analysis of the application’s architecture, user categories, billing model, and sales plans.
We work with SaaS providers, user-content platforms, and companies selling to the public sector. We combine IT law, AI, data protection, and contract law into a single model—instead of splitting these areas into separate engagements.
We offer three levels of support:
- Gap audit and list of required changes—reviewing your terms and conditions against the checklist, identifying clauses ineffective against consumers, missing DSA and AI Act mechanisms, and non-compliance with the Data Act
- Restructuring the template to separate legal regimes—one set of terms and conditions covering B2B customers, consumers, and guests, with AI clauses, a data processing agreement, and a data export procedure
- Comprehensive protection—a template adapted to different sales models (self-service, quotation-based, public sector), a DSA layer with moderation procedures, and support in negotiations with public-sector customers
The first step: a free consultation and a checklist review of your document—contact us.
Terms and conditions as a product feature—key takeaways
SaaS terms and conditions for a product with an AI module must accommodate three legal regimes within a single template. Clauses effective in B2B relationships—the exclusion of the statutory warranty, limitation of liability, and jurisdiction—are ineffective or unfair when applied to consumers. A declaration that AI output must be verified does not transfer responsibility—a review buffer implemented as a system state does. Labeling AI content requires labels in the interface, metadata in exports, and a prohibition on their removal. A license to user content requires a two-track structure. The DSA layer and a Data Act-compliant exit path are obligations, not options.
Each of these decisions changes something in the product, not just in the document. The sooner you make them, the lower the risk that you will have to overhaul your template when you acquire your first major public-sector customer or face your first consumer proceeding.
If you would like to review your terms and conditions against these seven areas—contact us. We will examine your document and identify what needs to change.
Frequently asked questions
My product is B2B, but my customer’s end users are consumers—do I need two sets of terms and conditions?
You do not need to create two separate documents. You need one template with a clear separation of regimes—separate paragraphs for entrepreneurs and consumers in every section where freedom of contract differs. This primarily concerns liability, statutory warranty, jurisdiction, and confidentiality. A single template is easier to maintain than several versions updated in parallel.
How can I make the terms and conditions binding on someone who does not create an account or click any checkbox?
Article 8(3) of the Polish Act on Providing Services by Electronic Means links the availability of the terms and conditions to the commencement of service provision, not to a signature. If the terms and conditions are available and legible before the person starts using the application, the guest is bound by them. Make sure that information about the terms and conditions is visible next to every public form and at every entry point.
Is it enough to state in the terms and conditions that “AI output must be verified”, or do I need to change the product?
The declaration alone does not transfer responsibility to the customer. A review buffer—a system state in which AI-generated content exists but is not published until it is approved—is a mechanism that genuinely allocates responsibility. It requires a product change: a “buffer” state, an approval button, and logging the identity of the approving person.
Does my customer receive exclusive rights to what my tool generates?
Material generated entirely automatically may not constitute a work within the meaning of Article 1 of the Polish Copyright Act—because it lacks an expression of creative activity of an individual nature. The customer acquires the right to use the output, but not exclusive rights. The application may generate identical or similar output for another user in response to a similar query. The terms and conditions should state this expressly.
Is my application subject to the DSA if it publishes user content?
If your application stores information at a user’s request and disseminates it publicly, it probably qualifies as an online platform within the meaning of the DSA. The exception applies where public dissemination is a minor and purely ancillary feature of the principal service. A SaaS product that accepts submissions available only to a closed group is probably not subject to it. Classification requires an analysis of your service architecture.
When do I need to start labeling AI-generated content?
Article 50 of the AI Act applies from 2 August 2026. The obligation covers labeling synthetic content in a machine-readable format. The provision itself does not specify a particular technical standard—the provider must independently select and document a solution. Remember the two layers: a label in the interface and metadata in exported files. And a prohibition on users removing the labels.
