Claims made (trigger roszczeniowy) to mechanizm OC, w którym ubezpieczyciel odpowiada za roszczenia zgłoszone w okresie ubezpieczenia — niezależnie od daty zdarzenia. Dominuje w OC zawodowym i D&O. Pełną ochronę dają dopiero data retroaktywna i okres dodatkowy zgłaszania roszczeń (ERP).
Zamykasz JDG po latach kontraktów IT. Pół roku później klient zgłasza roszczenie za błąd sprzed dwóch lat. Twoja stara polisa już nie działa, bo to był trigger claims made, a nikt Ci nie wyjaśnił, co to znaczy.
Na forach programistów B2B co roku wraca to samo: szukanie tańszej polisy, mylenie daty błędu z datą zgłoszenia, zero wiedzy o „ogonie” ochrony. Claims made jest tańszy od alternatyw, ale tylko jeśli rozumiesz jego trzy filary: trigger, datę retroaktywną i ERP.
Wyjaśnimy mechanizm bez żargonu OWU, porównamy go z occurrence i act committed dla Twojego zawodu, pokażemy ceny 2026 i damy checklistę zmiany ubezpieczyciela bez luki w ochronie.
Najważniejsze informacje
- Claims made chroni tylko wtedy, gdy roszczenie wpłynie w czasie aktywnej polisy — data błędu nie ma znaczenia.
- OC zawodowe IT w trybie claims made kosztuje od 1080 zł rocznie przy sumie gwarancyjnej 250 tys. zł.
- Polisa D&O w trybie claims made startuje od ok. 1500 zł rocznie przy sumie 1 mln zł.
- ERP (okres dodatkowy zgłaszania roszczeń) wynosi standardowo 36 miesięcy, rynek oferuje 12–60 miesięcy.
- Rezygnacja z polisy bez ERP po zamknięciu JDG lub zakończeniu kontraktu oznacza brak ochrony przy późniejszym roszczeniu.
- Data retroaktywna nowej polisy powinna sięgać początku pierwszej polisy claims made, nie daty nowej umowy.
- Klauzula claims made opiera się na art. 353¹ KC i art. 822 § 3 KC — brak odrębnej regulacji ustawowej.
Czym jest trigger claims made? Definicja i mechanizm
Claims made to trigger, w którym ubezpieczyciel odpowiada za roszczenia zgłoszone w okresie polisy, niezależnie od daty zdarzenia wyrządzającego szkodę.
Mechanizm czasowy ubezpieczenia OC, w którym ochrona aktywuje się momentem zgłoszenia roszczenia w okresie obowiązywania polisy. Data zdarzenia wyrządzającego szkodę nie ma znaczenia — liczy się wyłącznie to, czy roszczenie wpłynęło, gdy polisa była aktywna.
Tutaj kontraktorzy B2B popełniają najczęstszy błąd. O ochronie decyduje data zgłoszenia roszczenia ubezpieczycielowi, a nie data popełnienia błędu. Skutek bywa brutalny: napisałeś wadliwy kod, gdy polisa działała, ale klient zgłosił roszczenie pół roku po jej wygaśnięciu. Wypłaty nie ma. Na forum 4programmers wraca to regularnie jako nieprzyjemne odkrycie po fakcie.
- Liczy się data zgłoszenia roszczenia, nie data popełnienia błędu
- To rozróżnienie zmienia wszystko przy końcu kontraktu i zmianie polisy
- Claims made jest najbardziej restrykcyjnym z trzech triggerów OC
Claims made to jeden z trzech triggerów czasowych OC, obok loss occurrence i act committed. Rzecznik Finansowy wskazuje, że jest najbardziej restrykcyjny dla ubezpieczonego, bo ochrona kończy się z chwilą wygaśnięcia polisy. Dominuje w OC zawodowym programistów, architektów, radców prawnych i lekarzy oraz w ubezpieczeniu D&O — według PIU w polisach członków zarządu to standard polski i globalny.
Podstawa prawna jest kontraktowa. W Polsce nie ma przepisu wprost regulującego claims made — klauzula opiera się na swobodzie umów (art. 353¹ KC), a modyfikację czasowego zakresu ochrony dopuszcza art. 822 § 3 KC. Ramy ogólne wyznacza ustawa o działalności ubezpieczeniowej i reasekuracyjnej (Dz.U. 2024 poz. 838). To klauzula ubezpieczeniowa modyfikująca standardowy zakres OWU, a nie regulacja ustawowa.
Szukasz frazy 'CLAIMS' w wyszukiwarce? Trigger claims made (mechanizm czasowy OC) to coś innego niż 'program CLAIMS' — oprogramowanie do likwidacji szkód. Ten artykuł dotyczy wyłącznie triggera.
Claims made vs occurrence vs act committed — który trigger chroni Cię lepiej?
Claims made jest najbardziej restrykcyjnym triggerem — ochrona kończy się z wygaśnięciem polisy, a act committed obejmuje szkody długo po jej zakończeniu.
Trzy triggery w jednym zdaniu: claims made liczy datę zgłoszenia roszczenia; loss occurrence — datę powstania szkody; act committed — datę zdarzenia sprawczego. Ten ostatni jest najkorzystniejszy dla ubezpieczonego, bo ochrona „zostaje” przy polisie z okresu zdarzenia, nawet gdy roszczenie wpłynie wiele lat później.
| Trigger | Co aktywuje ochronę | Korzyść dla ubezpieczonego | Ryzyko | Typowe zastosowanie |
|---|---|---|---|---|
| Claims made | Data zgłoszenia roszczenia w okresie polisy | Niższa składka, dostęp do dużych sum | Ochrona ginie z końcem polisy | IT, architekci, radcy, D&O |
| Loss occurrence | Data powstania szkody w okresie polisy | Ochrona przypisana do roku szkody | Spory o moment powstania szkody | OC ogólne i majątkowe firmy |
| Act committed | Data zdarzenia sprawczego w okresie polisy | Odporny na zakończenie polisy | Wyższa składka | OC z długim ujawnianiem skutków |
Rzecznik Finansowy ostrzega: najgroźniejsza luka powstaje przy przejściu z act committed na claims made — stare zdarzenie nie jest już objęte przez żadną polisę. To nie teoria. To klasyczny scenariusz przy corocznej zmianie oferty.
Praktyka wygląda różnie, zależnie od zawodu. Programista i firma IT — niemal zawsze claims made. Architekt i radca prawny — claims made z 36-miesięcznym ogonem. D&O — claims made jako standard, bez realnej alternatywy. OC ogólne i majątkowe firmy — częściej occurrence.
- Niższa składka niż przy occurrence czy act committed
- Łatwiejszy dostęp do wysokich sum gwarancyjnych
- Standard rynkowy w OC zawodowym i D&O — szeroka oferta
- Ochrona wygasa razem z polisą
- Ryzyko luki przy zmianie triggera lub ubezpieczyciela
- Pełna ochrona wymaga daty retroaktywnej i ERP
Dlaczego ubezpieczyciele wolą claims made? Krótszy „ogon” zobowiązań i przewidywalność rezerw obniżają składkę. Dla Ciebie to niższa cena, ale w zamian — wymóg ciągłości i czujności.
- Nie ma 'lepszego' triggera w próżni — wybór zależy od długości ujawniania się skutków błędu w Twoim zawodzie
- W OC zawodowym IT i tak dostaniesz claims made — sztuką jest go zabezpieczyć datą retroaktywną i ERP
Data retroaktywna i okres dodatkowy (ERP) — fundament ochrony claims made
Polisa claims made bez daty retroaktywnej nie obejmie błędu sprzed jej zawarcia — to luka, która ujawnia się dopiero przy roszczeniu.
Najwcześniejsza data zdarzenia, za które polisa zapłaci, jeśli roszczenie wpłynie w okresie ubezpieczenia. Im dalej wstecz sięga, tym szerzej chroni przeszłość.
Czas po wygaśnięciu polisy, w którym wciąż możesz skutecznie zgłosić roszczenie za zdarzenie z okresu ochrony. Nazywany 'ogonem' lub tail coverage.
Bez daty retroaktywnej — albo gdy jest równa dacie startu polisy — błędy z przeszłości są poza ochroną. To milcząca luka: nie widać jej w dniu podpisania, widać dopiero w dniu roszczenia.
ERP działa po drugiej stronie osi czasu. Rynkowy standard to 36 miesięcy, choć spotyka się zakres od 12 do 60 miesięcy, zależnie od ubezpieczyciela. Nie traktuj jednej liczby jako pewnika — sprawdź konkretną wartość w OWU swojej polisy.
Rezygnacja z polisy bez ERP po zakończeniu kontraktu lub likwidacji firmy oznacza brak ochrony za zdarzenia z przeszłości. Roszczenie zgłoszone później pokrywasz z własnego majątku. To najczęstszy i najdroższy błąd przy claims made.
Jest moment, który cały rynek treści ignoruje: zamknięcie JDG, przejście na etat, zakończenie zawodu. Polisa wygasa, a roszczenie za projekt sprzed roku może wpłynąć długo później. Bez wykupionego ERP — zero ochrony.
Przy pierwszej polisie nie masz historii ubezpieczeniowej, więc data retroaktywna zwykle równa się dacie startu. Twoje wcześniejsze projekty nie są objęte. Wiedz o tym przed podpisaniem i, jeśli to możliwe, negocjuj wcześniejszą retrodate. Kontekst czasowy zgłaszania roszczeń wiąże się też z przedawnieniem roszczeń.
Praktyka rynkowa 2026: część ubezpieczycieli oferuje ERP 36 miesięcy domyślnie, ale spotykany zakres to 12–60 miesięcy. Porównaj zapis w OWU przed podpisaniem.
- Trigger to dopiero połowa układanki
- Bez daty retroaktywnej i ERP polisa claims made ma dziury, których nie widać do dnia roszczenia
- Data retroaktywna mówi, jak daleko wstecz; ERP — jak długo po wygaśnięciu
Ile kosztuje polisa w trybie claims made? Ceny 2026 dla IT, D&O, architektów i prawników
OC zawodowe IT w trybie claims made kosztuje od 1080 zł rocznie przy sumie 250 tys. zł, a polisa D&O od 1500 zł przy sumie 1 mln zł.
Dla D&O punkt wejścia to ok. 1500 zł rocznie przy sumie 1 mln zł. Wszystkie liczby to widełki rynkowe, nie cennik konkretnego ubezpieczyciela.
OC zawodowe IT w trybie claims made, dane rynkowe 2026: od ok. 1080 zł rocznie przy sumie 250 tys. zł dla klientów krajowych; 1000–1500 zł przy sumie 250–500 tys. zł; 1500–2300 zł przy obsłudze klientów z UE; od 3000 zł przy klientach spoza UE (USA, Kanada).
| Produkt (claims made) | Suma gwarancyjna | Składka roczna 2026 | Uwaga |
|---|---|---|---|
| OC IT JDG, klienci krajowi | 250 tys. zł | od ~1080 zł | Punkt wejścia rynku |
| OC IT, klienci z UE | 250–500 tys. zł | 1500–2300 zł | Wyższe ryzyko jurysdykcji |
| D&O, mała sp. z o.o. | 1 mln zł | 1500–7000 zł | Zależne od branży i obrotów |
| OC architekta (IARP) | bazowa | ~99 zł (emeryci ~66 zł) | Tylko baza obowiązkowa |
| OC radcy prawnego | bazowa | ~228 zł | Tylko baza obowiązkowa |
Obowiązkowe OC zawodowe z triggerem to dopiero fundament. Architekt w programie IARP płaci ok. 99 zł rocznie, radca prawny ok. 228 zł. Polisy nadwyżkowe i pracowni wycenia się indywidualnie — przy D&O i dużych OC zawodowych nie ma standardowego cennika. Składka D&O dla startupu w pierwszych dwóch latach to 6000–8000 zł, dla dużych firm przy sumie 10 mln zł — 20 000–100 000 zł, a w sektorze finansowym 50 000–200 000 zł.
Claims made bywa tańszy niż occurrence czy act committed, bo krótszy „ogon” zobowiązań i przewidywalność rezerw obniżają składkę. To jednak oszczędność warunkowa — działa tylko przy zachowaniu ciągłości ochrony. ERP i wcześniejsza data retroaktywna podnoszą składkę, ale to nie zbędny dodatek, lecz koszt realnej ochrony zamiast pozornej.
Przy D&O i dużych OC zawodowych składka zależy od branży, obrotów, historii szkód i struktury firmy. Nie ma tabeli z jedną ceną — wycena jest indywidualna.
- Cena claims made jest atrakcyjna, ale 'tania polisa bez ERP' to pozorna oszczędność
- Liczy się koszt całkowitej ochrony, nie sama składka
Oblicz składkę OC z triggerem claims made — sprawdź widełki dla swojego zawodu w kilka minut.
Jak bezpiecznie zmienić ubezpieczyciela przy polisie claims made? Checklist
Zmiana ubezpieczyciela przy claims made bez zsynchronizowanej daty retroaktywnej tworzy lukę — roszczenie za stare zdarzenie nie zostanie wypłacone.
Na forach programistów co roku wraca ten sam rytuał: szukanie tańszej oferty przy odnowieniu. A to akurat moment największego ryzyka luki, nie zwykły wybór ceny.
- Zanim wypowiesz starą polisę — ustal trigger nowej oferty (claims made? occurrence?) i jej datę retroaktywną. Tańsza składka z innym triggerem może oznaczać brak ochrony za przeszłość.
- Synchronizacja retrodate — data retroaktywna nowej polisy powinna sięgać początku Twojej pierwszej polisy claims made, a nie daty nowej umowy.
- Zero luki datowej — koniec starej polisy i start nowej muszą stykać się dzień w dzień. Nawet jednodniowa przerwa może wyłączyć ochronę za zdarzenia z tej luki.
- Notyfikacja okoliczności — zgłoś nowemu ubezpieczycielowi wszystkie znane okoliczności mogące prowadzić do roszczenia (tzw. laundry list). Zatajenie skutkuje odmową wypłaty.
- Plan B — jeśli nowy ubezpieczyciel nie przejmie pełnej historii, rozważ wykup ERP na starej polisie, by domknąć ochronę za okres sprzed zmiany.
Laundry list to po ludzku lista znanych Ci sytuacji, które mogą skończyć się roszczeniem: niedokończony spór z klientem, reklamacja, sygnał o błędzie w projekcie. Nowy ubezpieczyciel musi je znać, zanim obejmie Cię ochroną.
- Trigger nowej polisy zweryfikowany (claims made czy occurrence)
- Data retroaktywna sięga pierwszej polisy, nie nowej umowy
- Daty starej i nowej polisy stykają się bez przerwy
- Lista znanych okoliczności (laundry list) przygotowana
- ERP na starej polisie rozważony jako plan B
- OWU sprawdzone pod kątem definicji 'roszczenia'
'Taniej' u nowego ubezpieczyciela najczęściej oznacza nowszą datę retroaktywną — czyli ukrytą utratę ochrony za lata wcześniejszej pracy. Sprawdź retrodate przed porównaniem składek.
- Przy claims made zmiana ubezpieczyciela to operacja na ciągłości ochrony, nie wybór ceny
- Błąd w synchronizacji retrodate kosztuje cały majątek przy pierwszym roszczeniu
Sprawdź, czy ta polisa spełnia wymogi Twojego kontraktu — porozmawiajmy, zanim wypowiesz starą umowę.
Najczęstsze błędy przy polisach claims made
Najgroźniejszy błąd przy claims made to rezygnacja z polisy po zakończeniu kontraktu bez wykupienia okresu dodatkowego zgłaszania roszczeń.
- Błąd 1 — rezygnacja z polisy po zakończeniu kontraktu lub likwidacji firmy bez ERP: roszczenie zgłoszone później nie ma ochrony.
- Błąd 2 — mylenie daty zdarzenia z datą zgłoszenia: 'błąd był w okresie polisy, więc jestem chroniony' to fałszywe założenie. W claims made liczy się moment zgłoszenia.
- Błąd 3 — zatajenie znanych okoliczności lub niedbałe wypełnienie laundry list we wniosku: ubezpieczyciel może odmówić wypłaty, powołując się na przemilczenie istotnych informacji.
- Błąd 4 — ignorowanie agregatu i reinstatementu: po jednym dużym roszczeniu suma gwarancyjna może wyczerpać się na resztę roku. Sprawdź, czy polisa daje reinstatement (przywrócenie limitu).
- Błąd 5 — niesprawdzenie daty retroaktywnej i definicji 'roszczenia' w OWU: UOKiK po kontroli blisko 200 wzorców umownych wskazał, że nieprecyzyjne zapisy bywają abuzywne, a KNF kwestionuje nietransparentne postanowienia.
Błąd drugi to dokładnie ta luka wiedzy, którą widać na 4programmers. Agregat i reinstatement to z kolei temat, którego konkurencja w ogóle nie porusza. Po jednym poważnym roszczeniu limit potrafi się skończyć, a kolejna szkoda w tym samym roku zostaje bez pokrycia, jeśli polisa nie przewiduje przywrócenia sumy. Nieprecyzyjna definicja „roszczenia” w OWU działa w sporze na Twoją niekorzyść — tu pomaga wiedza o klauzulach abuzywnych.
Programista zamyka JDG i zostaje z roszczeniem
Scenariusz: Programista B2B kończy długi kontrakt, zamyka JDG i rezygnuje z polisy claims made — 'bo już nie pracuje'. Skutek: Sześć miesięcy później dawny klient zgłasza roszczenie za błąd w kodzie sprzed roku. Polisa wygasła, ERP nie został wykupiony — ubezpieczyciel nie odpowiada. Koszt obrony i odszkodowania pokrywa z własnego majątku. Z ERP / ciągłością: To samo roszczenie, ale wykupiony 36-miesięczny ERP. Zgłoszenie wpływa w okresie dodatkowym — ochrona działa, ubezpieczyciel prowadzi sprawę.
Takie roszczenia w OC IT to często czyste straty finansowe — szkoda majątkowa klienta bez uszkodzenia rzeczy. Zakres claims made musi je obejmować.
- 90% problemów z claims made to nie zła wola ubezpieczyciela, lecz brak wiedzy o triggerze, dacie retroaktywnej i ERP
- Wszystkich tych błędów da się uniknąć przed podpisaniem polisy
Claims made nie jest pułapką. To mechanizm, który działa dokładnie tak, jak go skonfigurujesz. Tańszy od occurrence i act committed, dominujący w OC zawodowym IT i w D&O, ale skuteczny tylko przy trzech filarach naraz: aktywnym triggerze, odpowiednio cofniętej dacie retroaktywnej i wykupionym ERP. Sama składka 1080 zł czy 228 zł nic nie znaczy, jeśli polisa ma dziurę, której nie widać do dnia roszczenia.
Najdroższe pomyłki zdarzają się w dwóch momentach: przy corocznej zmianie ubezpieczyciela i przy zamykaniu działalności. Oba da się przejść bezpiecznie — zsynchronizuj retrodate, nie zostawiaj luki datowej i nie rezygnuj z ochrony bez ogona.
Jeśli nie wiesz, jaką datę retroaktywną ma Twoja obecna polisa albo czy ERP w ogóle został wykupiony — to pierwsza rzecz do sprawdzenia, zanim podpiszesz cokolwiek nowego.
Bezpłatna konsultacja — zweryfikujemy Twoją datę retroaktywną i ERP oraz sprawdzimy, czy polisa spełnia wymogi kontraktu B2B. Bez zobowiązań.
Kluczowe informacje do zapamiętania
- Pełna ochrona w trybie claims made wymaga trzech elementów jednocześnie: aktywnego triggera, odpowiednio cofniętej daty retroaktywnej i wykupionego ERP.
- Zamknięcie działalności lub zakończenie kontraktu bez ogona ochrony (ERP) to najdroższy błąd — późniejsze roszczenie obciąża prywatny majątek.
- Przy zmianie ubezpieczyciela tańsza składka z nowszą retrodatą oznacza ukrytą utratę ochrony za lata wcześniejszej pracy.
- Ceny OC zawodowego IT startują od 1080 zł rocznie, ale realna ochrona kosztuje więcej — ERP i wcześniejsza retrodata podnoszą składkę.
- Agregat sumy gwarancyjnej może wyczerpać się po jednym poważnym roszczeniu — przed podpisaniem sprawdź, czy polisa przewiduje reinstatement limitu.
Najczęściej zadawane pytania
Co to są trigger claims made?
Trigger claims made to mechanizm czasowy ubezpieczenia OC, w którym ochrona aktywuje się w momencie zgłoszenia roszczenia ubezpieczycielowi, a nie w chwili popełnienia błędu czy wyrządzenia szkody. Oznacza to, że jeśli roszczenie wpłynie po wygaśnięciu polisy — nawet za błąd popełniony w czasie jej trwania — ubezpieczyciel nie zapłaci. To najbardziej restrykcyjny z trzech triggerów OC, ale jednocześnie dominujący standard w OC zawodowym IT, dla architektów, radców prawnych i w polisach D&O.
Czym różni się claims made od occurrence?
W triggerze loss occurrence ochrona aktywuje się w momencie powstania szkody — jeśli szkoda zaistniała w okresie polisy, ubezpieczyciel odpowiada nawet wtedy, gdy roszczenie wpłynie po jej wygaśnięciu. Claims made odwraca tę logikę: liczy się wyłącznie data zgłoszenia roszczenia, nie data zdarzenia sprawczego. Trzeci trigger, act committed, jest najbardziej korzystny dla ubezpieczonego — ochrona 'zostaje' przy polisie z okresu zdarzenia, nawet gdy roszczenie wpłynie wiele lat później. W OC zawodowym IT dominuje claims made, w OC ogólnym i majątkowym firmy częściej stosuje się occurrence.
Co się stanie z ochroną po zakończeniu kontraktu lub likwidacji firmy?
Jeśli polisa claims made wygaśnie bez wykupionego ERP (okresu dodatkowego zgłaszania roszczeń), ochrona ustaje całkowicie — roszczenie zgłoszone po tym czasie, nawet za błąd sprzed roku, nie zostanie wypłacone. Koszt obrony i ewentualnego odszkodowania ubezpieczony pokrywa wtedy z własnego majątku. Przy wykupionym ERP trwającym standardowo 36 miesięcy roszczenie zgłoszone w tym oknie wciąż aktywuje ochronę. To najczęstszy i najkosztowniejszy błąd przy claims made — zwłaszcza przy zamknięciu JDG lub przejściu na etat.
Czy mogę bezpiecznie zmienić ubezpieczyciela przy polisie claims made?
Tak, ale wymaga to zsynchronizowania kilku elementów. Data retroaktywna nowej polisy musi sięgać początku pierwszej polisy claims made — nie daty nowej umowy, bo inaczej lata wcześniejszej pracy zostają bez ochrony. Koniec starej i start nowej polisy powinny stykać się dzień w dzień, bez przerwy. Przed objęciem ochrony nowy ubezpieczyciel musi też otrzymać listę wszystkich znanych okoliczności mogących prowadzić do roszczenia (laundry list). Jeśli nowy ubezpieczyciel nie przejmuje pełnej historii, rozwiązaniem jest wykup ERP na starej polisie.
Co to jest data retroaktywna w polisie claims made?
Data retroaktywna to najwcześniejsza data zdarzenia, za które polisa zapłaci, pod warunkiem że roszczenie wpłynie w okresie jej obowiązywania. Im dalej wstecz sięga, tym szerzej chroni przeszłość zawodową. Przy pierwszej polisie data retroaktywna zazwyczaj równa się dacie jej zawarcia — wcześniejsze projekty nie są objęte. Przy każdej zmianie ubezpieczyciela kluczowe jest, by nowa retrodate nie 'cofnęła się do przodu', bo oznaczałoby to utratę ochrony za lata pracy objęte poprzednią polisą.
Ile kosztuje OC zawodowe w trybie claims made w 2026?
OC zawodowe IT w trybie claims made zaczyna się od ok. 1080 zł rocznie przy sumie gwarancyjnej 250 tys. zł dla klientów krajowych. Przy obsłudze klientów z UE składka wynosi 1500–2300 zł, a przy klientach spoza UE (USA, Kanada) — od 3000 zł. Polisa D&O dla małej sp. z o.o. kosztuje 1500–7000 zł przy sumie 1 mln zł, a dla startupów w pierwszych dwóch latach 6000–8000 zł. Obowiązkowe OC architekta w programie IARP to ok. 99 zł rocznie, a OC radcy prawnego — ok. 228 zł, jednak to wyłącznie baza obowiązkowa.
Czy klauzula claims made jest legalna w Polsce?
Tak, klauzula claims made jest w Polsce w pełni legalna. Nie ma przepisu wprost ją regulującego — opiera się na swobodzie umów (art. 353¹ KC), a modyfikację czasowego zakresu ochrony OC dopuszcza art. 822 § 3 KC. Ogólne ramy wyznacza ustawa o działalności ubezpieczeniowej i reasekuracyjnej (Dz.U. 2024 poz. 838). Claims made to klauzula modyfikująca standardowy zakres OWU, a nie regulacja ustawowa. UOKiK i KNF kwestionują jedynie nieprecyzyjne lub nieprzejrzyste zapisy w konkretnych wzorcach umownych.