Regulamin SaaS z AI. Jak jeden wzorzec pogodzić z klientem B2B, konsumentem i gościem bez konta

Pobrany z internetu regulamin aplikacji abonamentowej. Dopisany akapit o sztucznej inteligencji. Wyłączona rękojmia wobec konsumenta. Licencja na treści udzielana przez podmiot, który tych treści nie wprowadził. Brak procedury zgłaszania treści bezprawnych w aplikacji publikującej treści użytkowników. I zero odpowiedzi na pytanie, kto odpowiada za halucynację modelu wklejoną do oficjalnego dokumentu.

Tak wygląda regulamin SaaS z AI w większości produktów, które wpuszczają do interfejsu kogoś poza pracownikami klienta. Jeśli Twój produkt ma warstwę publiczną — formularz opinii, mapę zgłoszeń, sekcję komentarzy, marketplace — i moduł AI, ten artykuł jest dla Ciebie.

Pokażę, jakie decyzje konstrukcyjne musisz podjąć, żeby jeden wzorzec obsłużył cztery statusy prawne użytkowników: klienta B2B/B2G, członka jego zespołu, konsumenta z bezpłatnym kontem i gościa bez rejestracji. Przy każdej decyzji wskażę, co trzeba zapisać w dokumencie, a co trzeba zbudować w produkcie.

Cztery statusy prawne w jednym regulaminie SaaS — dlaczego to problem

Rynkowa narracja dzieli regulaminy na B2B albo B2C. Realny produkt SaaS z warstwą publiczną wymaga obu naraz — plus wzorca wiążącego anonimowego gościa. Każda z tych warstw ma inne granice swobody kontraktowej.

Jeśli Twój regulamin nie rozróżnia tych statusów, klauzule przeniesione z wzorca B2B — wyłączenie rękojmi, limit odpowiedzialności do wysokości opłaty, sąd siedziby dostawcy, poufność — są wobec konsumenta bezskuteczne lub abuzywne na gruncie art. 385¹ i 385³ k.c. Działasz w przekonaniu, że jesteś zabezpieczony, choć nie jesteś.

Najważniejsze pojęcia, które musisz znać

Zanim przejdziemy do konkretnych decyzji konstrukcyjnych, warto uporządkować terminologię. Poniższe pojęcia pojawiają się w dalszej części artykułu i mają precyzyjne znaczenie prawne.

Skontaktuj się — jeśli nie masz pewności, które z Twoich klauzul wymagają korekty.

Jak związać regulaminem osobę, która nie kliknęła checkboxa

To jedno z najczęstszych pytań dostawców SaaS z warstwą publiczną. Odpowiedź daje art. 8 ust. 3 ustawy o świadczeniu usług drogą elektroniczną: regulamin wiąże, jeśli został udostępniony przed rozpoczęciem świadczenia w sposób umożliwiający pozyskanie, odtworzenie i utrwalenie.

Dla gościa bez rejestracji oznacza to trzy wymagania:

1. Regulamin musi być widoczny i dostępny zanim gość zacznie korzystać z funkcjonalności — np. na stronie publicznego linku, przed otwarciem formularza.
2. Gość musi mieć możliwość pobrania regulaminu w formacie nadającym się do zapisania (np. PDF).
3. Interfejs musi to dokumentować — np. przez logowanie momentu wyświetlenia regulaminu przed pierwszą interakcją.

Checkbox nie jest wymagany. Ale jeśli go nie masz, musisz zaprojektować interfejs tak, żeby spełniał warunki z art. 8. To decyzja produktowa, nie prawna.

Rekomendacja: ustaw konfigurację domyślną na udział z kontem. Decyzję o włączeniu trybu anonimowego przenieś na klienta — razem z jego obowiązkiem informacyjnym wobec użytkowników końcowych.

Rozwarstwienie regulaminu — technika trzech reżimów w jednym paragrafie

Standardowe podejście to dwie wersje dokumentu: jedna dla B2B, druga dla konsumenta. W produkcie z czterema statusami użytkowników to podejście nie działa — generuje luki i niespójności.

Lepsze rozwiązanie: jeden regulamin, rozwarstwiony według statusu podmiotu, nie według tematu. Każdy paragraf dotyczący odpowiedzialności, poufności, sporów czy płatności zawiera trzy reżimy:

Ta technika eliminuje potrzebę dwóch dokumentów i sprawia, że każda klauzula jest czytelna dla każdego statusu.

Sześć decyzji konstrukcyjnych dla warstwy AI w regulaminie

Decyzja 1 — bufor weryfikacyjny zamiast deklaracji o weryfikacji

Zdanie „użytkownik powinien weryfikować wyniki” nie ma żadnej wartości prawnej, jeśli interfejs nie wymusza weryfikacji. Model probabilistyczny dla tych samych danych wejściowych może dać różny wynik, a wynik może być po prostu nieprawdziwy.

Jeżeli instytucja oprze raport na automatycznym podsumowaniu, a raport trafi do dokumentacji urzędowej, błąd modelu przestaje być kwestią jakości oprogramowania i staje się wadą procesu administracyjnego.

Co zapisać w regulaminie:

1. Wprost opisać, że wynik AI ma charakter probabilistyczny i może zawierać błędy.
2. Zakazać opierania decyzji o skutkach zewnętrznych wyłącznie na automatycznym wyniku (spójne z art. 22 RODO i art. 14 oraz 50 aktu w sprawie sztucznej inteligencji).
3. Opisać bufor weryfikacyjny jako stan systemu: treść wygenerowana istnieje, ale nie jest opublikowana do czasu zatwierdzenia przez usługobiorcę.

Co zbudować w produkcie:

1. Stan pośredni — wygenerowana treść widoczna dla użytkownika profesjonalnego, ale niepublikowana.
2. Przycisk zatwierdzenia, bez którego treść nie trafia do widoku publicznego.
3. Logowanie momentu zatwierdzenia z identyfikacją osoby zatwierdzającej.

Decyzja 2 — oznaczanie treści AI w interfejsie i w metadanych

Art. 50 aktu w sprawie sztucznej inteligencji nakłada obowiązek oznaczania wyników systemu AI w formacie nadającym się do odczytu maszynowego. Stosuje się od 2 sierpnia 2026 r. Obowiązek dotyczy każdej osoby fizycznej wchodzącej w interakcję z systemem — niezależnie od jej statusu umownego z dostawcą.

Samo oznaczenie w interfejsie nie wystarczy. Użytkownik eksportuje raport do pliku i usuwa etykietę. Dlatego potrzebne są dwie warstwy:

1. Etykieta w interfejsie — widoczna informacja, że treść została wygenerowana lub wsparta przez AI.
2. Metadane w plikach eksportowanych — oznaczenie maszynowo odczytywalne, które przetrwa eksport.

I trzecia warstwa — zakaz usuwania oznaczeń przez użytkowników zapisany w regulaminie. Bez tego zakazu oznaczenie ginie w pierwszym kroku obiegu dokumentu.

Decyzja 3 — status wyniku AI: brak wyłączności

Klient pyta w negocjacjach: „Czy wizualizacja wygenerowana przez narzędzie jest wyłącznie moja? Czy mogę zakazać innym używania podobnej?”

Odpowiedź zapisana w regulaminie jest tańsza niż spór. Materiał wygenerowany w całości automatycznie może nie stanowić utworu w rozumieniu art. 1 prawa autorskiego. Klient nabywa prawo korzystania, ale nie prawa wyłączne. Inny użytkownik może uzyskać zbliżony wynik przy podobnym zapytaniu.

Co zapisać w regulaminie:

1. Wynik AI nie stanowi utworu w rozumieniu prawa autorskiego, chyba że wkład twórczy użytkownika jest na tyle znaczący, że wynik spełnia przesłanki z art. 1.
2. Klient nabywa prawo korzystania z wyniku — niewyłączne, nieprzenoszalne.
3. Dostawca nie gwarantuje, że wynik będzie unikalny.

Decyzja 4 — licencja na treści użytkownika, który nie jest Twoim klientem

Dostawca potrzebuje licencji na treści, żeby przetworzyć je modelem. Ale nie może jej wziąć od autora, bo autor (np. mieszkaniec korzystający z formularza konsultacji) nie zawiera z dostawcą żadnej umowy.

Rozwiązanie to dwutorowa konstrukcja:

1. Wobec użytkownika końcowego i gościa: licencja udzielana z chwilą przesłania treści, powiązana z informacją wyświetlaną przy formularzu lub na stronie projektu — zanim użytkownik wpisze pierwszy znak.
2. Wobec usługobiorcy profesjonalnego: oświadczenie i gwarancja, że ma prawa i zgody do danych wprowadzanych do aplikacji, wraz z klauzulą zwolnienia dostawcy z odpowiedzialności za roszczenia z tytułu praw autorskich, dóbr osobistych i prywatności.

Decyzja 5 — dwukierunkowa klauzula trenowania modeli

Klauzula trenowania musi być symetryczna. Bez tej symetrii czyta się jak jednostronne przywłaszczenie danych klienta.

Pierwszy punkt wymaga potwierdzenia w umowach z dostawcami modeli — sam zapis w regulaminie nie wystarczy.

Decyzja 6 — warstwa DSA dla aplikacji publikującej treści użytkowników

Jeśli Twoja aplikacja przechowuje i publicznie rozpowszechnia treści użytkowników, może być kwalifikowana jako usługi hostingu lub platforma internetowa w rozumieniu aktu o usługach cyfrowych (DSA). Koordynatorem ds. usług cyfrowych w Polsce jest Prezes UKE, a ustawa z 4 września 2026 r. przewiduje możliwość nakładania okresowej kary pieniężnej do 5% średniego dziennego obrotu dostawcy usług pośrednich za każdy dzień naruszenia.

Minimalne elementy warstwy DSA w regulaminie:

1. Punkt kontaktowy (art. 11 i 12 DSA).
2. Mechanizm zgłaszania treści bezprawnych z wymogami formalnymi zgłoszenia (art. 16 DSA).
3. Uzasadnienie decyzji o ograniczeniu treści z informacją o użyciu narzędzi zautomatyzowanych (art. 17 DSA).
4. Wewnętrzne rozpatrywanie skarg — bezpłatne odwołanie w terminie sześciu miesięcy z udziałem wykwalifikowanego personelu (art. 20 DSA).
5. Środki przeciw nadużywaniu zgłoszeń (art. 23 DSA).
6. Rozdzielony katalog treści nielegalnych i treści niezgodnych z regulaminem.

Dostawcy będący mikro- lub małymi przedsiębiorstwami mogą korzystać ze zwolnienia z sekcji 3 rozdziału III DSA (art. 19), ale wyłącznie jeśli ich usługa kwalifikuje się jako platforma internetowa i spełniają kryterium wielkości z zalecenia 2003/361/WE. Zwolnienie nie obejmuje całego DSA — obowiązki hostingodawcy z art. 16–18 pozostają.

Ważna granica: wsparcie techniczne nie powinno obejmować doradztwa w zakresie moderowania treści użytkowników końcowych. To świadome odcięcie dostawcy od roli merytorycznego moderatora w cudzym procesie.

RODO — rozdział ról i dane szczególnych kategorii

Regulamin musi przypisać role RODO i odesłać do odrębnej umowy powierzenia z regułą jej pierwszeństwa w razie sprzeczności. Trzy obowiązki, o których dostawcy zapominają:

1. Nałożenie na klienta obowiązku zawarcia własnej umowy powierzenia z podmiotem zewnętrznym, któremu nadaje dostęp w roli członka zespołu (np. firma konsultingowa prowadząca konsultacje na zlecenie urzędu).
2. Ograniczenie zakresu danych w trybie bez rejestracji — zalecenie nieprzekazywania szczególnych kategorii danych (art. 9 RODO) w swobodnych wypowiedziach. Komentarz mieszkańca w konsultacjach dotyczących inwestycji drogowej może zawierać informację o stanie zdrowia, sytuacji rodzinnej i adresie. Dane szczególnej kategorii pojawiają się mimochodem.
3. Obowiązki informacyjne wobec osób trzecich (art. 14 RODO) — gdy treści użytkownika zawierają dane osób, które same nie wchodzą w interakcję z aplikacją.

Przetwarzanie treści zawierających dane z art. 9 RODO wymaga odrębnej podstawy z art. 9 ust. 2 — sama podstawa z art. 6 ust. 1 nie wystarczy. Jeśli treści są wtórnie wykorzystywane do trenowania modelu, cel przetwarzania wymaga doprecyzowania i oceny skutków (art. 35 RODO).

SLA, billing i offboarding — co zmienić w standardowych klauzulach

Dostępność — co realnie obejmuje gwarancja

Jeśli z czasu niedostępności wyłączasz awarie chmury i interfejsów dostawców chmurowych, gwarancja obejmuje tylko wąską warstwę własną. Czas przetwarzania operacji AI jest asynchroniczny i niezależny od przepustowości łącza — wyłączenie go z gwarancji responsywności jest uzasadnione, ale klient musi o tym wiedzieć.

Postanowienie o wiążącym charakterze pomiarów dokonanych narzędziami dostawcy — wobec konsumenta może być oceniane jako abuzywne (art. 385³ pkt 19 k.c. — przyznanie wyłącznego uprawnienia do zmiany cech świadczenia).

Billing — jednostka rozliczeniowa i pula operacji AI

Model rozliczeniowy oparty na rzeczywistej jednostce sprzedaży (np. projekt, nie stanowisko) plus osobna pula jednostek za operacje AI wymaga trzech zapisów:

1. Brak kumulacji niewykorzystanych jednostek między okresami.
2. Blokada funkcji AI po wyczerpaniu puli — z jasnym komunikatem w interfejsie.
3. Doładowanie rozliczane proporcjonalnie do dni pozostałych w okresie.

Przy automatycznym odnawianiu subskrypcji zapewnij: przypomnienie przed odnowieniem, łatwą rezygnację przed pobraniem opłaty (najpóźniej 1 dzień przed rozpoczęciem kolejnego okresu) i odrębny tryb zmiany ceny wobec konsumenta z aktywną zgodą.

Offboarding — okres karencji i eksport danych

Po rozwiązaniu umowy dane powinny być dostępne w trybie tylko do odczytu i eksportu przez określony czas (np. sześć miesięcy), w formacie nadającym się do odczytu maszynowego — co odpowiada wymogom aktu w sprawie danych (2023/2854) i obowiązkowi wydania treści po odstąpieniu konsumenta.

Po upływie okresu karencji — nieodwracalne usunięcie albo pełna anonimizacja. Ale uwaga: jeśli Twoim klientem jest podmiot publiczny, standardowa klauzula „usunięcie wszystkich danych po zakończeniu usługi” może kolidować z obowiązkami archiwizacyjnymi wynikającymi z rozporządzenia Prezesa RM z 18 stycznia 2011 r. i ustawy o narodowym zasobie archiwalnym. Regulamin musi przewidywać blokadę usunięcia na czas obowiązku archiwizacyjnego i eksport w uzgodnionym formacie.

Klient publiczny — co zmienić we wzorcu, żeby przeszedł przez proces zakupowy

Jeśli sprzedajesz podmiotom publicznym, skonfrontuj wzorzec z ich obowiązkami:

Checklist — co sprawdzić w regulaminie SaaS z AI

Jak możemy pomóc uporządkować regulamin Twojego SaaS z AI

Regulamin SaaS z AI to nie dokument do skopiowania — to zestaw decyzji produktowych. Trzy z nich — bufor weryfikacyjny, oznaczanie treści AI, procedura zgłoszeń — nie istnieją, jeśli nie ma ich w kodzie.

Pomagamy dostawcom SaaS przejść od wzorca pobranego z internetu do regulaminu, który odzwierciedla rzeczywisty produkt i obsługuje wszystkie statusy prawne użytkowników. Pracujemy na trzech poziomach:

1. Audyt obecnego wzorca — przegląd regulaminu pod kątem bezskutecznych klauzul, brakujących warstw (konsumencka, DSA, AI Act) i rozbieżności z produktem. Efekt: lista krytycznych poprawek z oceną ryzyka.
2. Przebudowa regulaminu — rozwarstwiony wzorzec z definicjami AI, klauzulami trenowania, licencją na treści użytkowników, umową powierzenia i modelem rozliczeniowym dopasowanym do produktu.
3. Pełna dokumentacja — regulamin, polityka AI, procedura DSA, umowa powierzenia i ścieżka sprzedaży do podmiotów publicznych z uwzględnieniem WCAG, archiwizacji i reżimu zamówieniowego.

Znamy realia zespołów produktowych: szybkie wdrożenia, równoległe projekty, ograniczone zasoby. Dlatego projektujemy zasady tam, gdzie faktycznie powstaje ryzyko — nie tworzymy dokumentów na zapas.

Napisz do nas — ustalimy, który wariant odpowiada etapowi Twojego produktu.

Podsumowanie

Jeden regulamin SaaS z AI musi obsłużyć cztery statusy prawne użytkowników — inaczej klauzule, na których polegasz, są wobec części z nich bezskuteczne. Każda z sześciu decyzji konstrukcyjnych opisanych w tym artykule wymaga zmian zarówno w dokumencie, jak i w produkcie. Obowiązki przejrzystości z aktu w sprawie sztucznej inteligencji (art. 50, stosowany od 2 sierpnia 2026 r.) oraz wymogi aktu o usługach cyfrowych dotyczą Twojego produktu niezależnie od tego, czy je uwzględnisz w regulaminie.

Sprawdź swój wzorzec. Zidentyfikuj luki. Jeśli potrzebujesz wsparcia — napisz do nas.

Najczęściej zadawane pytania

Czy mój regulamin wiąże osobę, która korzysta z aplikacji bez rejestracji i nie akceptuje żadnego checkboxa?
Tak, pod warunkiem spełnienia wymogów z art. 8 ust. 3 ustawy o świadczeniu usług drogą elektroniczną — regulamin musi być udostępniony przed rozpoczęciem świadczenia, w sposób umożliwiający pozyskanie, odtworzenie i utrwalenie. Checkbox nie jest wymagany, ale interfejs musi dokumentować moment udostępnienia regulaminu.

Czy potrzebuję dwóch osobnych dokumentów — jednego dla klientów biznesowych i drugiego dla użytkowników końcowych?
Nie. Lepszym rozwiązaniem jest jeden regulamin rozwarstwiony według statusu podmiotu. Każdy paragraf dotyczący odpowiedzialności, poufności czy sporów zawiera trzy reżimy: dla przedsiębiorcy, dla konsumenta i przedsiębiorcy na prawach konsumenta oraz reżim wspólny. To eliminuje luki i niespójności między dwoma dokumentami.

Które z moich obecnych klauzul są wobec konsumenta bezskuteczne?
Najczęściej: wyłączenie rękojmi (art. 558 § 1 k.c. działa wyłącznie wobec przedsiębiorcy), limit odpowiedzialności do wysokości opłaty, zapis na sąd siedziby dostawcy, klauzula poufności i postanowienie o wiążącym charakterze pomiarów dostawcy. Wobec konsumenta i przedsiębiorcy na prawach konsumenta mogą być uznane za abuzywne na gruncie art. 385¹ i 385³ k.c.

Kto odpowiada, jeśli model wygeneruje nieprawdziwe podsumowanie, a mój klient wykorzysta je w oficjalnym dokumencie?
Regulamin powinien rozdzielać odpowiedzialność: dostawca odpowiada za udostępnienie mechanizmu weryfikacji (bufor weryfikacyjny), a klient — za zatwierdzenie treści przed publikacją lub wykorzystaniem w procesie. Bez bufora weryfikacyjnego w produkcie podział odpowiedzialności opisany w regulaminie może być trudny do wyegzekwowania.

Czy moja aplikacja jest platformą internetową w rozumieniu DSA?
Jeśli przechowuje i publicznie rozpowszechnia treści użytkowników — może tak. Platforma internetowa w rozumieniu art. 3 lit. i DSA to usługa hostingu, która przechowuje i publicznie rozpowszechnia informacje na żądanie odbiorcy. Samo przechowywanie bez publicznego dostępu nie kwalifikuje jako platforma. Kwalifikacja wymaga oceny modelu technicznego i umownego Twojego produktu.

Czy mogę trenować własne modele na danych klientów, jeśli je zanonimizuję?
Regulamin powinien wprost przewidywać taką możliwość — prawo do agregacji i nieodwracalnej anonimizacji danych w celu trenowania modeli własnych. Ale anonimizacja musi być faktycznie nieodwracalna (nie pseudonimizacja), a jeśli treści mogą zawierać dane z art. 9 RODO, potrzebujesz odrębnej podstawy z art. 9 ust. 2 i oceny skutków (art. 35 RODO). Sam zapis w regulaminie nie zastąpi technicznej weryfikacji procesu anonimizacji.