Portal self-service w ubezpieczeniach. Jakie wymagania i regulacje musi spełniać?
Klient kupuje polisę przez internet. Odpowiada na pytania, wybiera wariant ochrony, akceptuje dokumenty i opłaca składkę. Kilka miesięcy później kwestionuje zakres ubezpieczenia. Twierdzi, że podczas zakupu nie został poinformowany o istotnym wyłączeniu odpowiedzialności.
Ubezpieczyciel próbuje odtworzyć przebieg transakcji. Ma dane klienta, numer polisy i potwierdzenie płatności. Nie może jednak ustalić, jaką wersję formularza klient wypełnił i jakie informacje zobaczył przed zawarciem umowy.
To przykład problemu, który może występować w starszych portalach samoobsługowych. System prawidłowo obsługuje sprzedaż, ale nie zapewnia wystarczających informacji do wykazania prawidłowości procesu.
Nowe rekomendacje KNF dotyczące dystrybucji ubezpieczeń, przyjęte 26 czerwca 2026 r., sprawiają, że warto ponownie przyjrzeć się takim rozwiązaniom. Większość rekomendacji powinna być stosowana najpóźniej od 1 lipca 2027 r. Jednocześnie ubezpieczyciele muszą uwzględniać przepisy DORA, RODO oraz wymagania dotyczące dostępności cyfrowej.
W tym artykule opisuję, jakie obowiązki mogą wpływać na portal self-service w ubezpieczeniach. Pokazuję również, które elementy istniejących systemów należy zweryfikować i kiedy modernizacja może być uzasadniona.
Czy KNF wymaga wdrożenia portalu self-service?
Nie. KNF nie nakłada na wszystkie zakłady ubezpieczeń ogólnego obowiązku wdrożenia portalu samoobsługowego. Wymagania prawne i nadzorcze dotyczą sposobu realizacji określonych procesów. Chodzi między innymi o analizę potrzeb klienta, przekazywanie informacji o produktach, dokumentowanie sprzedaży, obsługę szkód i zarządzanie ryzykiem.
Jeżeli ubezpieczyciel sprzedaje polisy przez internet, musi zapewnić zgodność tego procesu z właściwymi przepisami. Jeżeli umożliwia klientom zgłaszanie szkód online, powinien odpowiednio zorganizować obsługę tych zgłoszeń.
Portal self-service może ułatwiać realizację obowiązków. Nie zastępuje jednak procedur, kontroli wewnętrznej ani odpowiedzialności zakładu ubezpieczeń.
Z perspektywy CIO i dyrektora Digital najważniejsze pytanie brzmi więc inaczej: czy obecny system pozwala prawidłowo realizować wymagane procesy i udokumentować ich przebieg?
Rekomendacje KNF 2026. Co trzeba sprawdzić w portalu ubezpieczeniowym?
26 czerwca 2026 r. KNF przyjęła uchwałę nr 190/2026 dotyczącą dystrybucji ubezpieczeń. Rekomendacje mają ograniczyć nieprawidłowości związane z dopasowaniem produktów do potrzeb klientów, realizacją obowiązków informacyjnych i nadzorem nad dystrybucją. Ich zakres jest szerszy niż sprzedaż internetowa. Obejmuje także organizację dystrybucji, wartość produktów dla klientów, współpracę z pośrednikami i kontrolę wewnętrzną.
Większość rekomendacji powinna być stosowana od 1 lipca 2027 r. Dla rekomendacji 7.9 w zakresie części oszczędnościowej produktu przewidziano termin 1 lipca 2028 r.
Obowiązuje zasada „zastosuj lub wyjaśnij”. Zakłady, które nie stosują rekomendacji i nie zamierzają ich stosować, powinny poinformować KNF o sposobie osiągnięcia celów nadzorczych. Termin przekazania informacji upływa 15 lipca 2027 r.
Czy portal potrafi wykazać, dlaczego zaproponował konkretną polisę?
Wyobraźmy sobie klienta kupującego ubezpieczenie turystyczne. W formularzu wskazuje kraj podróży, planowaną aktywność i oczekiwany zakres ochrony. System proponuje polisę, ale nie zapisuje pełnego zestawu odpowiedzi ani wersji reguł, które doprowadziły do wyboru produktu. Jeżeli później pojawi się spór dotyczący dopasowania ochrony, ubezpieczyciel może mieć trudność z odtworzeniem procesu.
Art. 8 ustawy o dystrybucji ubezpieczeń wymaga określenia wymagań i potrzeb klienta przed zawarciem umowy. Proponowana umowa powinna odpowiadać tym wymaganiom i potrzebom.
Nowe rekomendacje KNF rozwijają oczekiwania dotyczące realizacji tego obowiązku.
Rekomendacja 8.1 wskazuje, że przy projektowaniu APK należy uwzględniać między innymi rodzaj produktu, potrzebne informacje, istotne wyłączenia odpowiedzialności i kanał dystrybucji.
Rekomendacja 8.2 odnosi się do rozwiązań umożliwiających klientowi zrozumienie procesu i podjęcie świadomej decyzji. Obejmuje także ustalenie jego potrzeb oraz ocenę, czy ograniczenia ochrony nie stoją z nimi w sprzeczności.
Rekomendacja 8.7 dotyczy dokumentowania APK w zakresie umożliwiającym utrwalenie informacji i wykazanie zgodności zaproponowanej umowy z wymaganiami klienta.
Rekomendacja 8.8 pozostawia zakładowi wybór sposobu dokumentowania APK, z uwzględnieniem kanału dystrybucji i formy kontaktu. Warto sprawdzić, czy system zapisuje informacje wykorzystane podczas APK, pozwala odtworzyć zastosowane reguły produktowe i powiązać wynik analizy z konkretną umową.
Przechowywanie wersji formularzy, historii odpowiedzi i identyfikatorów reguł decyzyjnych może ułatwiać wykazanie prawidłowości procesu. KNF nie nakazuje jednak stosowania konkretnej bazy danych, formatu logów ani układu formularza. Są to decyzje projektowe, które powinny wynikać z potrzeb organizacji i wymaganego zakresu dokumentacji.
Czy można wykorzystać dane klienta z wcześniejszych transakcji?
Tak, ale trzeba uwzględnić zasady określone w rekomendacjach. Rekomendacja 8.3 dopuszcza wykorzystanie informacji uzyskanych wcześniej lub pochodzących z innych źródeł. Zakład powinien jednak poinformować o tym klienta i umożliwić ich weryfikację.
Rekomendacja 8.4 dotyczy sytuacji, w której klient odmawia przekazania informacji potrzebnych do APK. Powinien zostać poinformowany o konsekwencjach odmowy.
W starszym portalu dane mogą być automatycznie pobierane z CRM lub systemu polisowego. Problem pojawia się, gdy klient nie wie, które informacje zostały wykorzystane, albo nie ma możliwości ich zweryfikowania. W takim przypadku modernizacja może wymagać zmian w formularzu i integracji. System powinien umożliwiać prezentację odpowiednich danych oraz obsługę ich aktualizacji.
Czy klient widzi różnice między wariantami ochrony?
Klient wybiera między trzema wariantami ubezpieczenia. Portal pokazuje wysokość składki, sumę ubezpieczenia i nazwy pakietów. Różnice w wyłączeniach odpowiedzialności są dostępne dopiero po otwarciu osobnych dokumentów. Taki sposób prezentacji może utrudniać świadomy wybór.
Rekomendacja 9.3 z tej samej uchwały wskazuje, że jeżeli kilka produktów lub wariantów odpowiada wymaganiom klienta, zakład powinien wyraźnie wskazać występujące między nimi różnice.
Z kolei rekomendacja 10.2 odnosi się do informacji o ofercie. KNF oczekuje jednoznacznego informowania o istotnych wyłączeniach i ograniczeniach odpowiedzialności przy prezentowaniu korzyści produktu.
Dla zespołu odpowiedzialnego za portal oznacza to potrzebę sprawdzenia sposobu prezentacji wariantów, warunków ochrony i dokumentów. Pomocne mogą być czytelne porównania, odpowiednio zaprojektowane komunikaty i powiązanie informacji produktowych z aktualnymi warunkami ubezpieczenia.
Nie każdy problem UX jest naruszeniem regulacji. Słaba czytelność formularza może jednak utrudniać realizację obowiązków informacyjnych. W naszym e-booku „10 błędów UX/UI w portalach ubezpieczeniowych” opisujemy problemy projektowe, które warto przeanalizować przy modernizacji cyfrowych procesów obsługi klienta.
Dokumentowanie sprzedaży. Czy ubezpieczyciel wie, co klient zobaczył przed zakupem?
Klient kwestionuje warunki polisy. Ubezpieczyciel dysponuje aktualnymi OWU, ale od czasu zawarcia umowy dokument był kilkukrotnie zmieniany. System nie pozwala jednoznacznie ustalić, która wersja została przedstawiona podczas zakupu. Problem dotyczy możliwości wykazania realizacji obowiązków informacyjnych.
Rekomendacja 10.3 przewiduje przechowywanie dowodów wykonania tych obowiązków zgodnie z zasadami przyjętymi przez zakład. Warto zweryfikować, czy portal umożliwia powiązanie transakcji z wersją dokumentu, datą jego udostępnienia i odpowiednimi zdarzeniami w procesie.
Pomocne mogą być repozytorium wersji dokumentów, rejestr zdarzeń oraz integracja z systemem polisowym. Nie oznacza to obowiązku rejestrowania każdego kliknięcia klienta. Zakres dokumentowania powinien odpowiadać rzeczywistym wymaganiom, a sposób przechowywania danych musi uwzględniać również RODO.
Odnowienie polisy. Czy system uwzględnia zmiany produktu?
Automatyczne odnowienia są wygodne, ale mogą tworzyć problemy, jeżeli portal wykorzystuje historyczne dane bez uwzględnienia zmian warunków ochrony.
Przykładowo klient odnawia ubezpieczenie na kolejny rok. Produkt zachował nazwę, ale zmieniły się wyłączenia odpowiedzialności. System wykorzystuje odpowiedzi z poprzedniej APK i nie uwzględnia wpływu zmian na dopasowanie ochrony.
Rekomendacja 8.11 odnosi się do odnowienia stanowiącego zawarcie umowy. Przewiduje poinformowanie klienta o wykorzystaniu posiadanych danych i możliwości ich aktualizacji.
Rekomendacja 9.2 wskazuje potrzebę weryfikacji zmian produktu, które mogą wpływać na zgodność ochrony z wymaganiami i potrzebami klienta. Dla portalu oznacza to potrzebę sprawdzenia reguł odnowienia, dostępu do historycznych danych i integracji z katalogiem produktów.
Ważne są również wyjątki. Rekomendacje 7.2 do 7.16 nie znajdują zastosowania do określonych odnowień umów zawartych przed wdrożeniem rekomendacji, jeżeli kontynuacja następuje na identycznych warunkach z punktu widzenia ubezpieczonego. Dokument przewiduje także wyłączenia dla wybranych kategorii produktów.
Nie należy więc zakładać, że każda automatyczna kontynuacja wymaga identycznych zmian w systemie.
Kontrola dystrybucji. Czy dane z różnych kanałów są spójne?
Duży ubezpieczyciel może sprzedawać polisy przez własny portal, aplikację mobilną, agentów i partnerów zewnętrznych. Każdy kanał korzysta z innych formularzy, systemów i sposobów dokumentowania procesu. Jeżeli organizacja nie ma dostępu do porównywalnych informacji, kontrolowanie jakości dystrybucji staje się trudniejsze.
Rekomendacja 24.5 dotyczy dokumentowania określonych czynności nadzorczych wobec przedsiębiorców uczestniczących w dystrybucji. Rekomendacja 29 odnosi się do kontroli wewnętrznej, audytu i funkcji zgodności. W tym obszarze warto ocenić przepływ informacji między kanałami, spójność danych oraz możliwości raportowania i identyfikowania nieprawidłowości. Nie zawsze wymaga to wymiany systemów. Czasem wystarczy ujednolicenie modelu danych i sposobu przekazywania informacji.
DORA. Czy portal ubezpieczyciela jest przygotowany na awarię i cyberatak?
Od 17 stycznia 2025 r. stosowane jest rozporządzenie DORA, czyli rozporządzenie UE 2022/2554. Obejmuje ono między innymi zakłady ubezpieczeń i reasekuracji, z uwzględnieniem wyłączeń przewidzianych w art. 2. DORA dotyczy zarządzania ryzykiem ICT, obsługi incydentów, ciągłości działania, testowania odporności cyfrowej i współpracy z dostawcami technologii.
Co się dzieje, gdy portal działa, ale system polisowy jest niedostępny?
Klient loguje się do portalu. Widzi swoje dane, ale nie może pobrać polisy ani zmienić zakresu ochrony. Powodem jest awaria integracji z systemem wewnętrznym. Z perspektywy klienta nie ma znaczenia, który komponent przestał działać. Nie może wykonać potrzebnej czynności. Art. 11 i 12 DORA dotyczą zarządzania ciągłością działania ICT oraz zasad tworzenia kopii zapasowych i odtwarzania systemów.
Nie oznacza to obowiązku zapewnienia całkowitej bezawaryjności. Ubezpieczyciel powinien jednak odpowiednio identyfikować ryzyka i przygotować się do zakłóceń. Warto sprawdzić, które procesy zależą od pojedynczych systemów, jak szybko można odtworzyć ich działanie i jakie alternatywne sposoby obsługi są dostępne.
Awaria modułu aktualizacji adresu nie musi mieć takich samych konsekwencji jak niedostępność procesu zgłaszania szkód. Dlatego oba procesy mogą wymagać różnych mechanizmów ciągłości działania.
Czy portal umożliwia wykrywanie incydentów?
Art. 9 i 10 DORA dotyczą ochrony systemów ICT oraz wykrywania nietypowych działań i potencjalnych incydentów. Starszy portal może mieć poprawnie zabezpieczony ekran logowania, ale korzystać z API, które nie weryfikuje wystarczająco uprawnień do pobierania dokumentów.
W takim przypadku problem dotyczy całej architektury. Samo wdrożenie dodatkowego uwierzytelniania nie rozwiąże podatności w integracji. Audyt powinien więc objąć mechanizmy dostępu, bezpieczeństwo API, aktualizacje komponentów, monitoring oraz obsługę incydentów.
Czy dostawca portalu spełnia wymagania DORA?
DORA poświęca dużo uwagi ryzyku związanemu z zewnętrznymi dostawcami usług ICT. Art. 28 do 30 określają wymagania dotyczące zarządzania takimi relacjami i odpowiednich postanowień umownych.Szczególne obowiązki dotyczą usług wspierających funkcje krytyczne lub istotne.
Dla ubezpieczyciela oznacza to potrzebę sprawdzenia odpowiedzialności dostawcy, dostępu do danych, podwykonawców, możliwości audytu i zasad zakończenia współpracy. Ważna jest także możliwość dalszego rozwoju systemu. Jeżeli każda zmiana procesu wymaga przebudowy wielu zależnych komponentów, dostosowanie portalu do nowych wymagań może być kosztowne.
Rozdzielenie interfejsu od logiki biznesowej, udokumentowane API i ograniczenie zależności od jednego dostawcy mogą ułatwiać modernizację. Są to jednak rozwiązania architektoniczne, a nie obowiązkowy model wskazany przez DORA.
Rozporządzenie przewiduje również zaawansowane testy TLPT. Nie każdy ubezpieczyciel ani każdy portal podlega temu obowiązkowi. Dotyczy on podmiotów wyznaczanych według zasad określonych w art. 26.
Polski Akt o Dostępności. Czy portal ubezpieczeniowy musi być dostępny cyfrowo?
Od 28 czerwca 2025 r. stosowana jest ustawa o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze. Jej zakres obejmuje między innymi usługi handlu elektronicznego. Może to dotyczyć internetowej sprzedaży polis konsumentom.
Nie oznacza jednak, że każdy portal ubezpieczeniowy automatycznie podlega wszystkim wymaganiom ustawy. Zakres obowiązków zależy od charakteru usługi i jej funkcji.
Dostępny formularz to za mało, jeśli klient nie może kupić polisy
Wyobraźmy sobie, że klient korzystający z czytnika ekranu przechodzi przez formularz zakupu. Może uzupełnić dane i wybrać wariant ochrony. Problem pojawia się przy komunikacie o błędzie, którego technologia wspomagająca nie odczytuje. Klient nie może zakończyć procesu.
Dlatego ocena dostępności powinna obejmować całą ścieżkę. Od prezentacji oferty, przez formularze i komunikaty, po dokumenty i potwierdzenie transakcji.
Standard WCAG i odpowiednie normy techniczne pomagają projektować oraz oceniać dostępność. Nie należy jednak sprowadzać wymagań ustawowych wyłącznie do wyniku automatycznego testu.
Warto również rozdzielić zgodność z wymaganiami dostępności od ogólnej użyteczności. Portal może być dostępny technicznie, a jednocześnie mieć skomplikowany proces zakupowy, który zniechęca użytkowników.
W przypadku portali służących wyłącznie do obsługi istniejących umów potrzebna jest osobna analiza zakresu zastosowania ustawy. Inaczej należy oceniać system, który umożliwia także zawieranie nowych umów lub rozszerzanie ochrony.
Likwidacja szkód. Czy klient widzi aktualne informacje o swojej sprawie?
Rekomendacje KNF dotyczące likwidacji szkód z ubezpieczeń komunikacyjnych są stosowane od 1 listopada 2022 r. Obejmują między innymi organizację procesu, dokumentowanie czynności, komunikację i prawidłowe ustalanie świadczeń. Portal self-service może wspierać realizację tych wymagań. Klient może zgłosić szkodę, przesłać dokumentację i sprawdzić status sprawy.
Problem pojawia się wtedy, gdy informacje w portalu nie odpowiadają stanowi sprawy w systemie likwidacyjnym. Przykładowo likwidator wydał już decyzję, ale klient nadal widzi status „w trakcie analizy”. Problemem nie jest sam interfejs. Problem leży w przepływie informacji między systemami.
Podobnie jest z dokumentacją. Możliwość przesłania zdjęć nie przynosi oczekiwanych korzyści, jeżeli pliki nie zostają prawidłowo przypisane do sprawy. Dlatego audyt powinien objąć integracje, historię komunikacji, statusy spraw i sposób udostępniania dokumentów.
Nie oznacza to, że KNF nakazuje wszystkim ubezpieczycielom zapewnienie całodobowego zgłaszania szkód przez portal. Jest to funkcjonalność, która może poprawiać obsługę klienta.
RODO i AI Act. Jakie dodatkowe wymagania dotyczą portalu?
Portal ubezpieczeniowy przetwarza dane osobowe. W niektórych procesach mogą to być również dane dotyczące zdrowia. Dlatego należy uwzględnić zasady RODO dotyczące legalności przetwarzania, minimalizacji danych, bezpieczeństwa i realizacji praw osób fizycznych.
Art. 25 dotyczy ochrony danych w fazie projektowania. Art. 32 określa wymagania dotyczące bezpieczeństwa przetwarzania. Szczególnej uwagi wymaga także art. 22, który reguluje określone przypadki zautomatyzowanego podejmowania decyzji.
W praktyce warto sprawdzić, czy portal ogranicza dostęp do danych zgodnie z uprawnieniami, realizuje odpowiednie zasady retencji i pozwala obsługiwać żądania klientów.
Osobnym zagadnieniem jest wykorzystanie AI. Asystent odpowiadający na pytania o warunki polisy ma inne zastosowanie niż system automatycznie oceniający ryzyko ubezpieczeniowe i ustalający cenę.
AI Act przewiduje szczególne wymagania dla określonych systemów wysokiego ryzyka. Załącznik III obejmuje między innymi wskazane zastosowania AI w ocenie ryzyka i ustalaniu cen w ubezpieczeniach na życie i zdrowotnych dotyczących osób fizycznych. Ostateczna klasyfikacja zależy od zasad rozporządzenia i konkretnego zastosowania.
O możliwościach wykorzystania sztucznej inteligencji w obsłudze klientów pisaliśmy w artykule „Czy AI zmienia projektowanie self-service?”.
Przy modernizacji warto oddzielić zastosowania informacyjne od rozwiązań wpływających na decyzje dotyczące klientów. Pozwala to trafniej określić wymagania prawne, technologiczne i organizacyjne.
Jakie regulacje trzeba uwzględnić przy modernizacji portalu?
| Regulacja | Kogo dotyczy | Wymagania istotne dla self-service | Termin stosowania | Konsekwencje technologiczne |
|---|---|---|---|---|
| Rekomendacje KNF 2026 | Zakłady objęte zakresem rekomendacji | APK, informacje produktowe, dokumentowanie i kontrola dystrybucji | 1.07.2027, z wyjątkiem części rekomendacji 7.9 | Formularze, reguły produktowe, historia transakcji |
| DORA | Podmioty objęte rozporządzeniem, z wyłączeniami | Ryzyko ICT, incydenty, ciągłość działania, dostawcy | 17.01.2025 | Bezpieczeństwo, monitoring, odporność i integracje |
| Polski Akt o Dostępności | Usługodawcy objęci ustawą | Dostępność określonych usług, w tym handlu elektronicznego | 28.06.2025, z przepisami przejściowymi | Dostępne procesy, formularze i dokumenty |
| Rekomendacje KNF dotyczące likwidacji szkód | Zakłady objęte rekomendacjami | Komunikacja, dokumentacja, przebieg likwidacji | 1.11.2022 | Integracja z systemami likwidacji szkód |
| RODO | Administratorzy i podmioty przetwarzające dane osobowe | Bezpieczeństwo, legalność przetwarzania, prawa osób | 25.05.2018 | Uprawnienia, retencja, ochrona danych |
| Ustawa o dystrybucji ubezpieczeń | Dystrybutorzy objęci ustawą | APK, informacje przedumowne, dopasowanie oferty | 1.10.2018, z późniejszymi zmianami | Formularze, dokumenty i reguły sprzedażowe |
| AI Act | Podmioty wykorzystujące AI w zakresie objętym rozporządzeniem | Obowiązki zależne od zastosowania i klasyfikacji systemu | Etapowo, według odpowiednich przepisów | Klasyfikacja zastosowań, nadzór, dokumentacja |
Daty i zakresy zastosowania wynikają z właściwych aktów prawnych oraz rekomendacji. Nie wszystkie wymagania dotyczą każdego zakładu lub każdej funkcji portalu.
Jak sprawdzić, czy portal self-service jest gotowy na wymagania regulacyjne?
Audyt warto rozpocząć od konkretnego procesu. Przykładowo od zakupu polisy, jej odnowienia lub zgłoszenia szkody. Należy przejść całą ścieżkę klienta i sprawdzić, jakie informacje są zbierane, jakie dokumenty są prezentowane i które działania zostają utrwalone. Następnie trzeba ustalić, jakie systemy uczestniczą w procesie i czy możliwe jest odtworzenie jego przebiegu.
Sama analiza interfejsu nie wystarczy. Problemy mogą znajdować się w regułach produktowych, integracjach, sposobie przechowywania danych lub procedurach organizacyjnych.
1. Audyt APK i cyfrowej sprzedaży
Pierwszy etap powinien objąć formularze, reguły doboru produktów, informacje przedumowne i dokumentowanie transakcji. Warto przeprowadzić testy różnych scenariuszy. Przykładowo klient odmawia odpowiedzi na pytanie, zmienia dane w trakcie zakupu albo wybiera wariant ochrony niezgodny z wcześniej wskazanymi potrzebami. Trzeba sprawdzić, jak reaguje system i czy wynik procesu można później odtworzyć.
Rezultatem powinna być mapa luk w procesach sprzedażowych, powiązana z właściwymi przepisami i rekomendacjami KNF.
2. Audyt zarządzania treścią i dokumentami
Kolejny obszar to sposób zarządzania OWU, informacjami produktowymi i dokumentami przekazywanymi klientom.
Należy sprawdzić, czy system pozwala przypisać konkretną wersję dokumentu do transakcji. Ważne jest również ustalenie, kto może aktualizować treści i jak zmiany są publikowane w różnych kanałach.
Przykładowo nowe warunki ubezpieczenia mogą zostać opublikowane na stronie internetowej, ale portal klienta nadal korzysta ze starszej wersji dokumentu. Taka niespójność może wynikać z rozproszonego zarządzania treścią i braku odpowiednich integracji.
Rezultatem powinna być ocena spójności informacji oraz możliwości dokumentowania obowiązków informacyjnych.
3. Audyt dostępności i użyteczności
W pierwszej kolejności należy ustalić, które funkcje portalu podlegają wymaganiom dostępności wynikającym z przepisów. Następnie warto przeprowadzić testy formularzy, dokumentów, nawigacji i całych procesów. Powinny one uwzględniać technologie wspomagające oraz różne sposoby korzystania z systemu.
Osobno należy ocenić użyteczność. Nawet prawidłowo działający formularz może zawierać zbędne kroki lub niejasne komunikaty.
Rezultatem powinna być lista barier dostępności i problemów UX wraz z priorytetami zmian. Nie należy traktować każdej niedogodności użytkownika jako naruszenia prawa.
4. Audyt bezpieczeństwa, architektury i integracji
Ten etap powinien objąć mechanizmy uwierzytelniania, zarządzanie uprawnieniami, bezpieczeństwo API, monitorowanie zdarzeń oraz ciągłość działania. Warto również sprawdzić zależności między portalem a systemami polisowymi, CRM i systemami likwidacji szkód.
Istotne jest ustalenie, czy zmiana jednego procesu wymaga ingerencji w wiele innych komponentów.
Przykładowo dodanie nowego pytania do APK może wymagać zmian w formularzu, logice produktowej, integracji i sposobie archiwizacji danych. Jeżeli każda z tych modyfikacji wymaga osobnego wdrożenia, dostosowanie procesu do nowych wymagań może trwać znacznie dłużej. Rezultatem audytu powinna być ocena ograniczeń architektonicznych, ryzyk technologicznych i możliwości dalszego rozwoju platformy.
W raporcie Jak zbudować portal self-service pokazujemy praktyczne zagadnienia związane z projektowaniem i wdrażaniem takich rozwiązań.
5. Mapa luk i plan modernizacji
Audyt nie powinien kończyć się listą znalezionych błędów. Zarząd, IT i Compliance potrzebują informacji, jakie działania należy podjąć, z jakiego powodu i w jakiej kolejności.
Dlatego wyniki warto uporządkować według wpływu na zgodność regulacyjną, ryzyko operacyjne, doświadczenie klienta oraz koszt i złożoność zmian.
| Obszar audytu | Przykładowy problem | Oczekiwany rezultat |
|---|---|---|
| APK | Brak możliwości odtworzenia danych wykorzystanych przy doborze polisy | Mapa luk w dokumentowaniu procesu |
| Informacje produktowe | Brak powiązania transakcji z wersją OWU | Plan wersjonowania i archiwizacji |
| Odnowienia | Brak weryfikacji zmian warunków produktu | Rekomendacje dotyczące reguł odnowienia |
| Dostępność | Niedostępne elementy procesu zakupowego | Lista barier i plan dostosowania |
| DORA | Zależność istotnego procesu od pojedynczej integracji | Ocena ryzyka i scenariusze ciągłości działania |
| Architektura | Kosztowne zmiany formularzy i procesów | Plan modernizacji z priorytetami |
Ocena zgodności prawnej powinna odbywać się we współpracy z Compliance lub odpowiednimi ekspertami prawnymi. Zespół technologiczny może następnie ustalić, jakie zmiany są potrzebne w systemie.
Takie podejście pozwala rozdzielić trzy sytuacje. W pierwszej wystarczy aktualizacja procedury. W drugiej potrzebna jest modyfikacja konkretnego procesu. W trzeciej problem wynika z architektury portalu i wymaga szerszej modernizacji.
Czy dostosowanie do rekomendacji KNF wymaga wymiany całego portalu?
Nie zawsze. Jeżeli portal umożliwia elastyczne zarządzanie formularzami, dokumentami i regułami biznesowymi, wiele zmian można wprowadzić bez przebudowy całej platformy.
Inaczej wygląda sytuacja, gdy system ma silnie powiązane komponenty, ograniczone możliwości integracji i niewystarczające mechanizmy dokumentowania działań. Wówczas każda kolejna zmiana może zwiększać koszty utrzymania. Problem nie musi dotyczyć jednego przepisu. Może wynikać z tego, że architektura utrudnia dostosowywanie procesów do nowych potrzeb.
Przed podjęciem decyzji o modernizacji warto porównać koszty dalszego rozwijania obecnego rozwiązania z kosztami przebudowy wybranych komponentów. W e-point projektujemy i rozwijamy platformy self-service dla instytucji finansowych. Łączymy projektowanie procesów cyfrowych, integracje i rozwój oprogramowania.
Znaczenie długoterminowego rozwoju rozwiązań technologicznych pokazuje również nasza współpraca z PZU. Duże organizacje potrzebują systemów, które można rozwijać wraz ze zmianami procesów i wymagań biznesowych..
FAQ
- Czy KNF wymaga przeprowadzenia audytu portalu do końca 2026 r.?
Nie wskazano ogólnego terminu 31 grudnia 2026 r. na przeprowadzenie audytu portalu. Rekomendacje określają terminy dostosowania działalności i oczekiwania dotyczące kontroli wewnętrznej. Wcześniejszy audyt jest uzasadnionym sposobem przygotowania organizacji.
- Czy ubezpieczyciel musi zapisywać każde kliknięcie klienta?
Nie. Rekomendacje 8.7 i 8.8 dotyczą dokumentowania APK, a rekomendacja 10.3 przechowywania dowodów realizacji obowiązków informacyjnych. Nie ustanawiają uniwersalnego obowiązku zapisywania wszystkich kliknięć.
- Czy automatyczne odnowienie polisy wymaga ponownego przeprowadzenia APK?
Zakres obowiązków zależy od charakteru odnowienia. Rekomendacja 8.11 dotyczy informowania klienta o wykorzystaniu posiadanych danych i możliwości ich aktualizacji. Rekomendacja 9.2 odnosi się do weryfikacji zmian produktu mogących wpływać na dopasowanie ochrony.
- Czy DORA wymaga przeniesienia portalu do chmury?
Nie. DORA nie narzuca modelu hostingu. Wymaga odpowiedniego zarządzania ryzykiem ICT i relacjami z dostawcami. Zarówno infrastruktura własna, jak i rozwiązania chmurowe muszą zostać ocenione w świetle właściwych obowiązków.
- Czy każdy portal ubezpieczeniowy musi spełniać wymagania Polskiego Aktu o Dostępności?
Nie automatycznie. Ustawa obejmuje określone produkty i usługi, w tym usługi handlu elektronicznego. Zakres zastosowania należy ustalić na podstawie rzeczywistych funkcji portalu.
- Czy wykorzystanie AI w portalu oznacza, że system jest wysokiego ryzyka?
Nie. Klasyfikacja zależy od zastosowania AI i odpowiednich przepisów AI Act. Asystent informacyjny może podlegać innym obowiązkom niż system wykorzystywany do oceny ryzyka i ustalania cen w określonych ubezpieczeniach.
- Czy modernizacja portalu zapewnia zgodność z KNF i DORA?
Nie automatycznie. Zgodność zależy również od procesów, dokumentacji, kontroli wewnętrznej i organizacji pracy. Technologia może wspierać realizację obowiązków, ale nie zastępuje odpowiedzialności ubezpieczyciela.