Ocena ryzyka w projektach AI: praktyczny framework dla zespołów IT, prawników i biznesu

Dlaczego projekty AI niosą inne ryzyka niż „zwykłe” IT

Systemy uczące się kontra klasyczne oprogramowanie

Klasyczna aplikacja biznesowa zachowuje się przewidywalnie: ten sam zestaw danych wejściowych daje ten sam wynik, dopóki ktoś nie zmieni kodu. W projektach AI wiele rzeczy działa inaczej. Model uczący się nie zawiera „twardo zakodowanej” logiki – jego zachowanie powstaje z połączenia architektury, parametrów oraz danych treningowych. Drobna zmiana któregokolwiek z tych elementów może dać zaskakujący efekt.

Dla zespołów prawnych i biznesowych jest to szczególnie kłopotliwe: trudniej przypisać odpowiedzialność i przewidzieć, jakie scenariusze trzeba uwzględnić w ocenie ryzyka AI. Jeśli klasyczna aplikacja źle nalicza rabat, zwykle wiadomo, że błąd jest w jednym z kilku miejsc w kodzie. Jeśli model rekomendujący oferty zaczyna nagle faworyzować jedną grupę klientów, przyczyna może tkwić w danych, konfiguracji, procesie trenowania albo w tym, że zmieniło się otoczenie biznesowe.

Dochodzi jeszcze zjawisko model drift: nawet dobrze przygotowany model, który dziś jest dokładny i „sprawiedliwy”, za kilka miesięcy może już taki nie być, bo zmieniły się zachowania klientów, produkty albo procesy. Klasyczne oprogramowanie starzeje się wolniej; w systemach AI starzenie się jest wpisane w samą naturę rozwiązania.

Typowe „niespodzianki” w projektach AI

Systemy AI, zwłaszcza generatywne, mają tendencję do zachowań, które w tradycyjnym IT byłyby uznane za poważny błąd projektowy. Modele językowe mogą „halucynować” – przekonująco podawać informacje, które są po prostu zmyślone. Algorytmy predykcyjne z kolei potrafią przejmować uprzedzenia z historycznych danych i utrwalać dyskryminujące schematy.

Dla prawnika „halucynacja” to nie ciekawostka techniczna, tylko potencjalne źródło odpowiedzialności za wprowadzanie w błąd, szkodę majątkową, a nawet naruszenie dóbr osobistych. Dla biznesu to ryzyko reputacyjne i operacyjne: klient, który dostał nieprawdziwą informację od chatbota, może podważać umowę albo nagłośnić sprawę w mediach społecznościowych. Zespół IT często widzi w tym „znane ograniczenie modelu”, ale to nie usuwa ryzyka na poziomie organizacji.

Do tego dochodzi efekt „czarnej skrzynki”. Wiele modeli, zwłaszcza głębokich sieci neuronowych, jest trudnych do objaśnienia w prosty, biznesowy sposób. Gdy organ nadzorczy lub sąd pyta: „dlaczego system odrzucił wniosek tego klienta?”, argument „tak wyszło z modelu” jest kompletnie niewystarczający. W ocenie ryzyka AI kwestia wyjaśnialności staje się jednym z centralnych kryteriów.

Co realnie może pójść źle – dwa krótkie przykłady

Wyobraźmy sobie bank, który wdraża chatbota do obsługi klientów. Model językowy ma dostęp do ogólnych informacji o produktach i regulaminach, ale nie jest idealnie „obudowany” ograniczeniami. Klient pyta o możliwość wcześniejszej spłaty kredytu bez prowizji. Chatbot, bazując na źle skonfigurowanym kontekście, odpowiada twierdząco, choć w regulaminie istnieje opłata. Klient powołuje się na tę informację, bank odmawia, a sprawa trafia do Rzecznika Finansowego i mediów. Z perspektywy prawa dochodzi do sporu o to, czy informacja z chatbota jest wiążąca, a z perspektywy reputacji – do utraty zaufania.

Drugi przykład: system scoringu kredytowego w instytucji pożyczkowej. Model uczy się na danych z ostatnich lat i wykrywa, że mieszkańcy określonych dzielnic częściej zalegali ze spłatami. Zaczyna więc zaniżać scoring w tych lokalizacjach. Statystycznie wszystko się „zgadza”, ale w praktyce prowadzi to do dyskryminacji grup o niższym statusie majątkowym. W świetle RODO mamy do czynienia z profilowaniem i zautomatyzowanym podejmowaniem decyzji, a w świetle projektowanego AI Act – z systemem wysokiego ryzyka, który wymaga szczególnie rygorystycznej oceny wpływu.

Skala działania modeli: mały błąd, duży efekt

System AI wdrożony w dużej organizacji rzadko dotyka pojedynczych użytkowników. Zazwyczaj działa na masową skalę: ocenia dziesiątki tysięcy wniosków, generuje tysiące odpowiedzi na pytania klientów, proponuje dynamiczne ceny dla całych segmentów rynku. Nawet jeśli prawdopodobieństwo jednostkowego błędu jest niewielkie, liczba zdarzeń w skali roku może być ogromna.

Dla zarządu oznacza to konieczność myślenia w kategoriach ryzyka skumulowanego. Nie chodzi tylko o to, czy jedna decyzja będzie błędna, ale czy wiele drobnych odchyleń nie zsumuje się w wzorzec systematycznego naruszenia praw określonej grupy osób. Regulatorzy coraz częściej patrzą właśnie na efekty systemowe, a nie pojedyncze przypadki.

Dlaczego klasyczne podejścia do ryzyka IT nie wystarczą

Tradycyjne zarządzanie ryzykiem IT koncentruje się na dostępności systemów, bezpieczeństwie informacji, ciągłości działania czy klasycznych błędach programistycznych. Dla AI kluczowe są inne pytania: jak model zachowa się na nowych danych, czy faworyzuje jakieś grupy, czy jego decyzje są zrozumiałe dla użytkownika, jak często trzeba go kalibrować.

Standardowy rejestr ryzyk IT, w którym dominuje słownictwo typu „utrata danych”, „awaria serwera”, „brak backupu”, nie obejmuje subtelnych, ale brzemiennych w skutkach zjawisk typowych dla algorytmów uczących się. Bez dedykowanego frameworku ocena ryzyka AI rozmywa się w ogólnych kategoriach i nie prowadzi do konkretnych działań prewencyjnych. Zespół prawny widzi jedynie „nowy system IT”, zespół IT – „jeszcze jedną usługę w chmurze”, a ryzyka etyczne czy społeczne pojawiają się dopiero po fakcie.

Rodzaje ryzyk w projektach AI – mapa, na którą patrzą wszyscy

Podstawowy podział ryzyk w projektach AI

Dobrze skonstruowany framework oceny ryzyka w projektach AI zaczyna się od wspólnej mapy. Chodzi o to, by IT, prawnicy i biznes patrzyli na ten sam krajobraz, nawet jeśli każdy z nich koncentruje się na innym fragmencie. Praktyczny podział obejmuje zazwyczaj następujące kategorie:

• ryzyka prawne,
• ryzyka etyczne i społeczne,
• ryzyka techniczne i bezpieczeństwa,
• ryzyka biznesowe i finansowe,
• ryzyka reputacyjne,
• ryzyka organizacyjne i kompetencyjne.

Te kategorie często się przenikają. Dyskryminujący model (ryzyko etyczne) może prowadzić do pozwów (ryzyko prawne), odpływu klientów (biznes) i kryzysu w mediach (reputacja). Dlatego rejestr ryzyk w projektach AI powinien umożliwiać przypisanie jednego zdarzenia do kilku obszarów i ocenę łącznego wpływu.

Ryzyko prawne: od RODO po odpowiedzialność za produkt

Dla większości organizacji pierwszym skojarzeniem z ryzykiem prawnym w AI jest RODO. I słusznie, bo większość systemów AI przetwarza dane osobowe w mniej lub bardziej oczywisty sposób. Prawdziwe wyzwanie pojawia się jednak wtedy, gdy AI wpływa na decyzje wywołujące skutki prawne lub podobnie istotne dla osób fizycznych – kredyty, ubezpieczenia, rekrutacja, dostęp do świadczeń.

W takich przypadkach w grę wchodzi profilowanie i zautomatyzowane podejmowanie decyzji, a wraz z nimi wymogi dotyczące przejrzystości, prawa do zakwestionowania decyzji oraz obowiązek przeprowadzenia DPIA (oceny skutków dla ochrony danych), jeśli ryzyko jest wysokie. Równolegle pojawia się projektowane rozporządzenie AI Act, które dzieli systemy AI na kategorie ryzyka (niedopuszczalne, wysokie, ograniczone, minimalne) i nakłada dodatkowe wymogi na dostawców i użytkowników systemów wysokiego ryzyka.

Do tego dochodzą kwestie prawa autorskiego (wykorzystanie danych treningowych, generowanie treści), regulacje sektorowe (np. prawo bankowe, prawo medyczne) oraz klasyczne przepisy o odpowiedzialności za produkt i usługę. Jeżeli wynik modelu wpływa na to, że klient ponosi szkodę, pytanie o to, kto odpowiada – dostawca rozwiązania, integrator czy użytkownik biznesowy – nie jest czysto teoretyczne.

Ryzyko etyczne i społeczne: dyskryminacja i utrata zaufania

Ryzyka etyczne rzadko pojawiają się w tradycyjnych rejestrach ryzyka IT, a jednak w projektach AI mają fundamentalne znaczenie. Algorytmiczna dyskryminacja może być niezamierzona, ale jej skutki są realne: wykluczenie z usług, gorsze warunki, stygmatyzacja całych grup społecznych. Nawet jeśli prawo formalnie nie zostało naruszone, opinia publiczna coraz częściej reaguje na takie przypadki bardzo gwałtownie.

Do tego dochodzi brak przejrzystości. Użytkownicy często nie wiedzą, że rozmawiają z chatbotem, a nie człowiekiem, lub że ich dane są wykorzystywane do trenowania kolejnych modeli. Jeśli czują się „zrobieni w konia”, tracą zaufanie nie tylko do konkretnej usługi, ale do całej marki. Ryzyko etyczne szybko przekłada się więc na ryzyko reputacyjne i biznesowe.

Ryzyko techniczne i bezpieczeństwa: dane, drift i ataki

Z perspektywy zespołów IT sercem ryzyka AI są dane. Zanieczyszczony, niekompletny lub stronniczy zbiór treningowy skutkuje modelem, który działa źle lub niesprawiedliwie. Problemem nie jest tylko jakość danych w momencie trenowania, ale także późniejszy brak kontroli nad tym, co dzieje się na wejściu modelu w środowisku produkcyjnym.

Systemy AI są również wrażliwe na specyficzne rodzaje ataków. Ataki adversarial polegają na wprowadzaniu pozornie niewinnych modyfikacji danych wejściowych (np. obrazów), które drastycznie zmieniają wynik modelu. W przypadku modeli generatywnych pojawia się z kolei ryzyko wycieków danych – użytkownicy mogą nieświadomie wklejać do promptów dane wrażliwe, które potem trafiają do logów lub są wykorzystywane do dalszego trenowania.

Dla bezpieczeństwa IT oznacza to konieczność rozszerzenia tradycyjnego programu ochrony o komponent model risk management. Obejmuje on testowanie odporności modeli, monitorowanie zachowania na bieżąco oraz wprowadzanie mechanizmów „bezpiecznego domyślnego działania”, gdy coś idzie nie tak.

Ryzyko biznesowe, reputacyjne i organizacyjne

Z punktu widzenia zarządu ryzyko AI nie kończy się na zgodności z przepisami i bezpieczeństwie. Modele decyzyjne mogą sugerować strategie, które są krótkoterminowo korzystne, ale długoterminowo szkodliwe. Przykładowo, system optymalizujący koszty może odrzucać wnioski klientów o wysokim ryzyku, co statystycznie poprawia wyniki, ale niszczy relacje z lojalnymi klientami w trudniejszej sytuacji.

Ważne jest też ryzyko vendor lock-in. Organizacje, które bezrefleksyjnie uzależniają kluczowe procesy od jednego dostawcy modeli lub chmury, mogą po kilku latach odkryć, że zmiana rozwiązań jest praktycznie niemożliwa. To nie tylko problem techniczny, ale i negocjacyjny – pozycja przetargowa drastycznie słabnie.

Na koniec pozostaje ryzyko organizacyjne: brak kompetencji, brak jasnej odpowiedzialności za governance AI, brak procedur reagowania na incydenty. Nawet najlepiej zaprojektowany framework oceny ryzyka w projektach AI nie zadziała, jeśli nikt nie czuje się odpowiedzialny za jego wdrożenie i utrzymanie.

Podstawy prawne i regulacyjne: RODO, AI Act i otoczenie normatywne

RODO i AI: profilowanie oraz zautomatyzowane decyzje

RODO nie zostało napisane z myślą o generatywnych modelach językowych, ale jego przepisy doskonale „trafiają” w wiele zastosowań AI. Kluczowe pojęcia to profilowanie oraz zautomatyzowane podejmowanie decyzji, które wywołuje skutki prawne lub podobnie istotne dla osoby fizycznej.

Profilowanie to każda forma zautomatyzowanego przetwarzania, której celem jest ocena niektórych czynników dotyczących osoby fizycznej. Systemy scoringu kredytowego, modele oceny ryzyka nadużyć czy algorytmy selekcji CV w rekrutacji to podręcznikowe przykłady. Jeśli na podstawie takiego profilu podejmowana jest decyzja wywołująca poważne skutki (np. odmowa kredytu, odrzucenie kandydata), wchodzimy w obszar art. 22 RODO.

To z kolei rodzi konkretne obowiązki: trzeba zapewnić użytkownikowi prawo do uzyskania „istotnych informacji o zasadach podejmowania decyzji”, możliwość zakwestionowania decyzji oraz – co szczególnie ważne w kontekście oceny ryzyka AI – często konieczność przeprowadzenia DPIA. DPIA nie jest formalnością: ma wykazać, że organizacja zidentyfikowała ryzyka i wdrożyła adekwatne środki ochrony.

AI Act – kategorie systemów i ich konsekwencje

Projektowane rozporządzenie AI Act wprowadza dodatkową warstwę nad RODO. Kluczową ideą jest podejście oparte na ryzyku, które dzieli systemy AI na cztery główne kategorie:

• niedopuszczalne ryzyko – systemy zakazane (np. określone formy manipulacji, scoring społeczny),
• wysokie ryzyko – systemy podlegające surowym wymogom (np. w obszarze finansów, zdrowia, zatrudnienia),
• ograniczone ryzyko – systemy wymagające określonego poziomu przejrzystości (np. chatbota trzeba oznaczyć jako maszynę),
• minimalne ryzyko – pozostałe zastosowania, gdzie wymogi są najmniejsze.

Obowiązki dostawców i użytkowników systemów wysokiego ryzyka

AI Act bardzo wyraźnie rozróżnia rolę dostawcy systemu AI (tego, kto go buduje i wprowadza na rynek) oraz użytkownika (organizacji, która z systemu korzysta). W praktyce w jednym projekcie IT tych ról może być kilka – software house będzie dostawcą, bank czy szpital użytkownikiem, a dostawca chmury dodatkowym podmiotem z własnymi obowiązkami.

Dostawca systemu wysokiego ryzyka ma m.in. zapewnić:

• system zarządzania ryzykiem – od analizy scenariuszy użycia i nadużycia po plan reakcji na incydenty,
• zarządzanie danymi treningowymi i testowymi – opis źródeł, kryteriów doboru, jakości oraz działań ograniczających stronniczość,
• dokumentację techniczną – pozwalającą zrozumieć architekturę, parametry i ograniczenia systemu,
• rejestrowanie działania (logging) – tak by w razie problemu można było odtworzyć decyzje modelu,
• nadawanie instrukcji i ostrzeżeń użytkownikom – jak system stosować, a czego absolutnie nie robić.

Z kolei użytkownik systemu wysokiego ryzyka odpowiada za to, żeby korzystać z niego „zgodnie ze sztuką”: stosować instrukcje dostawcy, mieć odpowiednio przeszkoloną kadrę, monitorować działanie i zgłaszać poważne incydenty. Nie wystarczy więc kupić „certyfikowane AI” i odetchnąć z ulgą – organizacja musi mieć własny proces oceny ryzyka i nadzoru.

Dobrą praktyką jest podpisanie z dostawcą aneksu, który precyzyjnie rozdziela obowiązki w obszarze compliance, monitoringu i reagowania na incydenty AI. Gdy dochodzi do błędu systemu, nikt nie chce zaczynać dyskusji od zdania: „to nie nasza odpowiedzialność”.

Generatywne AI w świetle prawa: treści, dane, własność

Modele generatywne dorzucają kilka osobnych warstw ryzyka prawnego. Z jednej strony pojawia się pytanie o dane treningowe – skąd pochodzą, czy są objęte prawem autorskim, czy przetwarzają dane osobowe. Z drugiej – problem treści wygenerowanych: czy mogą naruszać cudze prawa, dobra osobiste lub przepisy sektorowe (np. dotyczące reklamy wyrobów medycznych).

W praktyce trzeba rozstrzygnąć co najmniej trzy kwestie:

• czy dane, które użytkownicy wprowadzają do modelu (np. w promptach), mogą być użyte do dalszego trenowania – i jak to pogodzić z RODO oraz tajemnicą przedsiębiorstwa,
• kto odpowiada za treści wygenerowane przez model – zwłaszcza jeśli są publikowane lub przesyłane klientom,
• jak opisać to w regulaminach i klauzulach informacyjnych, by nie brzmiało jak żargon prawniczy, ale dawało realną przejrzystość.

Tu szczególnie przydaje się wspólny stół IT–prawnik–biznes: prawnicy wskażą wymogi, IT opowie, co technicznie da się skonfigurować (np. wyłączenie trenowania na danych klientów), a biznes określi, jaka komunikacja będzie akceptowalna dla użytkownika końcowego.

Normy, wytyczne i dobre praktyki poza ustawami

Nie wszystko rozstrzygają przepisy. Coraz większą rolę odgrywają normy techniczne (ISO/IEC dla AI), wytyczne organów nadzorczych (np. EROD w obszarze RODO) oraz wewnętrzne kodeksy etyczne organizacji. Dla projektów AI oznacza to, że „zgodność z prawem” to dopiero poziom podstawowy – dalej jest kwestia zgodności z oczekiwaniami regulatorów i rynku.

Wiele firm tworzy własne AI Policy lub AI Governance Framework, w których łączy obowiązki prawne z zasadami etyki i wytycznymi technicznymi. To właśnie tam lądują reguły dotyczące np. zakazu generowania deepfake’ów, ograniczeń w wykorzystywaniu publicznych modeli do danych poufnych czy wymogów przeprowadzania bias assessment dla modeli decyzyjnych.

Budowa wspólnego języka: jak dogadać IT, prawników i biznes

Dlaczego klasyczne „warsztaty IT–biznes” nie wystarczą

Przy „zwykłym” projekcie IT najczęściej wystarczy uzgodnić wymagania funkcjonalne, SLA i budżet. W AI dochodzą wątki, które tradycyjnie były poza radarem: etyka, uprzedzenia w danych, przejrzystość modeli, nadzór regulacyjny. Jeżeli każdy dział zostanie przy swoim słowniku, rozmowa szybko zamienia się w kakofonię.

Biznes mówi o „doświadczeniu klienta” i „konwersji”, IT o „architekturze referencyjnej” i „drifcie modelu”, a prawnicy o „podstawie prawnej przetwarzania” i „proporcjonalności”. Dopiero gdy uda się te światy przetłumaczyć na wspólne pojęcia ryzyka i korzyści, można konstruktywnie zdecydować: ten projekt robimy, ten modyfikujemy, z tego rezygnujemy.

Słownik minimalny: kilka pojęć, które wszyscy muszą rozumieć

Zamiast tworzyć wielki leksykon, lepiej ustalić krótki zestaw terminów, które są używane w każdym projekcie AI. Chodzi o pojęcia, które pomagają nazwać ryzyko i dyskutować o nim bez nieporozumień. Przykładowo:

• model wysokiego wpływu – taki, którego błąd może istotnie zaszkodzić klientowi lub organizacji (niekoniecznie „wysokiego ryzyka” w rozumieniu AI Act),
• decyzja zautomatyzowana – decyzja podjęta bez udziału człowieka lub z udziałem czysto formalnym, bez realnej możliwości ingerencji,
• human-in-the-loop – rola człowieka, który faktycznie ma możliwość zakwestionowania lub zmiany rekomendacji modelu,
• drift – stopniowa utrata jakości modelu w czasie z powodu zmian w danych wejściowych,
• use case krytyczny – scenariusz użycia, w którym błąd systemu ma skutki prawne, zdrowotne albo istotne finansowo.

Takie pojęcia można opisać na jednej stronie w intranecie i odwoływać się do nich w każdym szablonie dokumentacji czy formularzu oceny ryzyka. Nie chodzi o akademicką definicję, ale o użyteczne skróty myślowe.

Mapa interesariuszy i odpowiedzialności

Projekt AI bez jasno przypisanych ról bardzo szybko staje się projektem „niczyim”. Kto odpowiada za jakość danych? Kto zatwierdza dopuszczalne progi błędu? Kto podejmuje decyzję o wyłączeniu systemu? Jeśli te pytania padają dopiero przy pierwszym incydencie, to znaczy, że governance powstał za późno.

Przydaje się prosta mapa odpowiedzialności, np. w formie macierzy RACI, w której pojawią się co najmniej:

• właściciel biznesowy – osoba z jednostki biznesowej, która „zamawia” system i odpowiada za jego wynik biznesowy oraz wpływ na klientów,
• właściciel techniczny – zespół lub osoba odpowiedzialna za architekturę, wdrożenie i utrzymanie systemu AI,
• funkcja compliance/prawna – odpowiedzialna za ocenę zgodności z prawem i politykami wewnętrznymi,
• właściciel danych – za źródła danych, ich jakość, legalność przetwarzania i dokumentację,
• komitet ds. AI lub podobne ciało – które rozstrzyga sporne przypadki i zatwierdza projekty wysokiego ryzyka.

To nie musi być skomplikowana struktura. Nawet w mniejszej firmie da się wyznaczyć konkretne osoby „od AI”, które zbierają w jednym miejscu odpowiedzialność rozproszoną dziś po całej organizacji.

Jak rozmawiać o ryzyku, żeby nie zabić innowacji

Przy AI bardzo łatwo wpaść w dwie skrajności: albo entuzjastyczne „zróbmy wszystko na AI”, albo paraliżujące „to za ryzykowne, odłóżmy na później”. Framework oceny ryzyka ma służyć temu, by zamienić te emocjonalne reakcje na spokojną rozmowę o prawdopodobieństwie, skutkach i możliwych zabezpieczeniach.

Dobrym narzędziem staje się wspólna matryca ryzyka, w której każdy dział może „zaznaczyć” swoje obawy. IT wskaże ryzyko drifta i braku monitoringu, prawnicy – profilowanie wysokiego ryzyka i podstawę prawną, biznes – potencjalny kryzys reputacyjny. Gdy wszystko jest na jednym ekranie, łatwiej zobaczyć, gdzie inwestycja w dodatkowe zabezpieczenia rzeczywiście ma sens, a gdzie ryzyko jest bardziej teoretyczne.

Jeden z banków, z którym pracowałem, wprowadził prostą zasadę: każdy projekt AI musi przejść godzinny „risk review” z udziałem przedstawicieli trzech działów. Dzięki temu część ryzyk udaje się wyłapać jeszcze na etapie pomysłu, a nie po półrocznym wdrożeniu.

Framework oceny ryzyka w projektach AI – przegląd krok po kroku

Krok 1: Identyfikacja zastosowania i kontekstu

Ocena ryzyka zaczyna się od bardzo konkretnego pytania: do czego dokładnie ma służyć ten system AI i na kogo będzie oddziaływać? Ogólne opisy typu „chatbot do obsługi klienta” są za mało precyzyjne. Trzeba zejść do scenariuszy użycia.

Przydatne są trzy proste osie opisu:

• kontekst biznesowy – proces, który ma zostać zautomatyzowany lub wsparty (np. underwriting kredytowy, triage zgłoszeń serwisowych, analiza zdjęć medycznych),
• kontekst użytkownika – kto ma kontakt z systemem (klient detaliczny, pracownik wewnętrzny, lekarz, analityk),
• kontekst decyzji – czy system tylko rekomenduje, czy podejmuje decyzję, oraz jakie skutki ma błąd (niewygoda, strata finansowa, zagrożenie zdrowia).

Taka mini-karta projektu AI, wypełniana na początku, pozwala już na wstępną klasyfikację: czy wchodzimy w grę wysokiego ryzyka (RODO, AI Act), czy raczej w obszar eksperymentu o niewielkim wpływie na osoby fizyczne.

Krok 2: Klasyfikacja ryzyka regulacyjnego

Kolejny krok to „przyłożenie” do projektu szablonów prawnych: RODO, AI Act, regulacje sektorowe. Nie chodzi o pełną analizę prawną na tym etapie, tylko o decyzję, czy projekt trafia na ścieżkę standardową, czy wzmocnioną.

Dla RODO kluczowe pytania są zwykle te same:

• czy system przetwarza dane osobowe,
• czy dochodzi do profilowania,
• czy wynik profilowania jest używany do podejmowania decyzji wywołujących skutki prawne lub podobnie istotne,
• czy obejmuje dane wrażliwe (zdrowie, pochodzenie etniczne, poglądy polityczne, itp.).

Jeśli odpowiedź „tak” pada kilka razy, projekt prawdopodobnie wymaga DPIA i włączenia działu ochrony danych na wczesnym etapie. Równolegle warto dokonać wstępnej klasyfikacji zgodnie z AI Act: czy to potencjalnie system wysokiego ryzyka (np. zatrudnienie, edukacja, kredyty, infrastruktura krytyczna), czy raczej kategoria ograniczona lub minimalna.

Na tej podstawie można utworzyć „ścieżki” w procesie portfela projektów: np. projekt AI wysokiego ryzyka wymaga akceptacji komitetu ds. AI, pełnej DPIA i dodatkowych testów technicznych, podczas gdy projekt niskiego ryzyka przechodzi uproszczoną ocenę.

Krok 3: Analiza danych – źródła, jakość, legalność

Każdy model jest tak dobry, jak dane, którymi go karmimy – to truizm, ale w ocenie ryzyka trzeba go potraktować bardzo dosłownie. Analiza danych obejmuje trzy poziomy:

• źródła – skąd pochodzą dane (systemy wewnętrzne, źródła publiczne, dostawcy zewnętrzni),
• jakość – kompletność, spójność, aktualność, reprezentatywność wobec populacji docelowej,
• legalność – podstawa prawna przetwarzania, zgodność z umowami, licencjami i regulaminami.

Kluczowe pytanie brzmi: czy dane użyte do trenowania i walidacji modelu są adekwatne do celu i nie wprowadzają systematycznych uprzedzeń. Jeśli model ma wspierać proces rekrutacji, ale dane historyczne pochodzą z okresu, gdy firma nie zatrudniała praktycznie żadnych kobiet na stanowiskach technicznych, to ryzyko utrwalenia tej nierówności jest oczywiste.

W praktyce przydaje się prosty formularz „karty danych” (data sheet) dołączony do dokumentacji projektu. Zawiera opis zbioru, kryteria jego doboru, informacje o przeprowadzonych analizach biasu oraz wskazanie, kto może z niego korzystać i w jakim celu.

Krok 4: Ocena wpływu na osoby fizyczne i interesariuszy

Nawet jeśli przepisy nie wymuszają formalnej DPIA, dobrze jest wykonać chociaż uproszczoną ocenę wpływu na osoby, których dane lub decyzje będą dotknięte działaniem systemu. Chodzi o przełożenie technicznych parametrów modelu na realne życie użytkowników.

Pomocne jest zadanie kilku prostych pytań:

• co się stanie, jeśli model się pomyli – jaką szkodę poniesie użytkownik, a jaką organizacja,
• czy użytkownik ma możliwość zakwestionowania wyniku lub decyzji,
• czy istnieją grupy szczególnie narażone (np. osoby w trudnej sytuacji finansowej, pacjenci, dzieci),
• czy model może prowadzić do systematycznego wykluczania określonych grup,

Krok 4 (ciąg dalszy): Ocena wpływu – jak głęboko wejść

• czy użytkownik wie, że ma do czynienia z systemem AI, a nie człowiekiem,
• czy informacja zwrotna jest zrozumiała (np. „odrzucono wniosek, bo brak zdolności kredytowej” vs. „decyzja negatywna – kod 738”),
• jakie są ścieżki naprawcze – reklamacja, ręczna weryfikacja, dodatkowe wyjaśnienia,
• czy istnieje ryzyko tzw. efektu mrożącego (np. ludzie przestają korzystać z usługi, bo boją się „czarnej skrzynki”).

Przy dobrze prowadzonym projekcie ta analiza nie ląduje w szufladzie. Zamiast tego część wniosków wraca do projektu funkcjonalnego: pojawia się dodatkowy ekran z wyjaśnieniem decyzji, procedura eskalacji do człowieka, progi pewności modelu, poniżej których decyzję zawsze podejmuje pracownik.

Dobrym trikiem jest przejście przez scenariusz „dzień z życia użytkownika” – krok po kroku, z perspektywy klienta czy pracownika. Kilkanaście minut takiego ćwiczenia często ujawnia ryzyka, których nie wychwyci nawet najdokładniejsza tabela.

Krok 5: Ocena modelu – jakość, stabilność, wyjaśnialność

Kiedy wiadomo już, co system robi i kogo dotyka, przychodzi czas na sam model. Nie chodzi tylko o to, czy ma dobre metryki na zbiorze testowym, ale jak zachowuje się w realnym świecie i czy da się wytłumaczyć jego decyzje osobom nietechnicznym.

Przyglądając się modelowi, zwykle analizuje się trzy grupy zagadnień:

• jakość predykcji – metryki dopasowane do problemu (precyzja, recall, AUC, F1, MAE itp.),
• stabilność i odporność – wrażliwość na zmiany danych wejściowych, ryzyko drifta, zachowanie w skrajnych przypadkach,
• wyjaśnialność – zdolność do uzasadnienia decyzji na poziomie zrozumiałym dla użytkownika i regulatora.

W praktyce oznacza to kilka konkretnych decyzji. Czy w danym use case możemy sobie pozwolić na model „czarnej skrzynki”, jeśli zapewnimy porządny nadzór człowieka? A może lepiej wybrać nieco słabszy model, ale taki, którego logikę łatwiej opisać i obronić przed klientem i organem nadzorczym?

Przykład z dużej firmy ubezpieczeniowej: analitycy zaproponowali głęboką sieć neuronową do wyceny szkód, bo dawała najlepsze wyniki. Po dyskusji z działem obsługi klienta i prawnym zespół przeszedł na bardziej przejrzysty model gradient boosting z warstwą reguł biznesowych. Wyniki były minimalnie słabsze, ale za to możliwe stało się przygotowanie prostych wyjaśnień decyzji dla klientów, co znacząco ograniczyło liczbę reklamacji.

Krok 6: Projektowanie mechanizmów kontroli i nadzoru

Model AI nie jest jak most, który raz zbudowany stoi 30 lat. To raczej ogród – jeśli nikt go nie dogląda, szybko zarasta. Dlatego w frameworku oceny ryzyka osobne miejsce zajmuje projekt monitoringu i nadzoru.

Na tym etapie zespół odpowiada sobie na kilka kluczowych pytań:

• jakie metryki będą monitorowane na produkcji (np. rozkład wejść, wskaźniki błędów, różnice między grupami użytkowników),
• jakie są progi alarmowe i kto je definiuje (biznes, IT, compliance),
• jak wygląda procedura „stop” – kto i w jakich sytuacjach może wstrzymać działanie systemu,
• w jakim cyklu będą przeglądane wyniki działania systemu (np. komitet raz na kwartał),
• czy przewidziano logi i audyt ścieżki decyzji, pozwalające odtworzyć przebieg zdarzeń.

W przypadku use case’ów wysokiego ryzyka dobrze działa zasada „podwójnej pętli”: bieżący monitoring operacyjny (czy system działa poprawnie dziś) oraz cykliczny przegląd strategiczny (czy system nadal powinien działać w tej formie, w tym procesie, przy obecnym otoczeniu prawnym).

Technicznie taki nadzór to nie tylko dashboard w narzędziu MLOps. To także procedury – kto odbiera alert, co robi w pierwszej godzinie, kiedy angażuje prawników lub PR. Bez tego monitoring jest jak alarm przeciwpożarowy bez straży pożarnej.

Krok 7: Środki zaradcze i „warstwy bezpieczeństwa”

Ocena ryzyka bez propozycji środków zaradczych zamienia się w katalog strachów. Ramą dla rozmowy mogą być tzw. warstwy bezpieczeństwa – od danych, przez model, aż po procesy i komunikację z użytkownikami.

Typowe kategorie środków obejmują m.in.:

• na poziomie danych – lepsze oczyszczanie danych, usunięcie pól niepotrzebnych, automatyczne wykrywanie anomalii, anonimizacja lub pseudonimizacja,
• na poziomie modelu – regularyzacja i ograniczenia, techniki fairness (np. rebalancing zbiorów), dodatkowe testy odporności na ataki typu data poisoning i adversarial,
• na poziomie systemu – walidacje wejść (input validation), ograniczenia zakresu działania (np. blokada generowania pewnych rodzajów treści), mechanizmy fallback do prostszych reguł,
• na poziomie organizacyjnym – szkolenia użytkowników, procedury obsługi incydentów, jasna polityka korzystania z narzędzi generatywnych,
• na poziomie komunikacji – transparentne informowanie o użyciu AI, prosty język w regulaminach, kanały zgłaszania nieprawidłowości.

Kiedy różne działy widzą, że przy każdym zidentyfikowanym ryzyku pojawia się także konkretny „zabezpieczacz”, dyskusja staje się znacznie spokojniejsza. Nagle mniej jest „nie wolno”, a więcej „dajmy to, ale z tymi warunkami i pod tym nadzorem”.

Krok 8: Dokumentacja i ścieżka audytu

Nie ma zgodności bez śladu. Przy systemach AI dokumentacja to nie tylko wymóg prawnika, lecz także polisą ubezpieczeniową na wypadek incydentów czy audytu zewnętrznego. Co istotne, nie musi to być encyklopedia – ważniejsza jest kompletność niż objętość.

Przydatny zestaw dokumentów „minimalnych” to m.in.:

• karta projektu AI – z opisem celu, kontekstu, interesariuszy,
• karta danych – z opisem zbiorów, źródeł, analiz jakości i biasu,
• opis modelu – architektura, metryki, wyniki testów, ograniczenia,
• raport z oceny ryzyka / DPIA – wraz z decyzjami, kto co zatwierdził,
• plan monitoringu i nadzoru – metryki, częstotliwość przeglądów, procedury reakcji,
• rejestr zmian – istotne aktualizacje modelu, danych, parametrów.

Dobrym nawykiem jest prowadzenie „dziennika decyzyjnego”: krótkich notatek z kluczowych decyzji (np. wybór modelu, kompromisy między dokładnością a wyjaśnialnością). Gdy po dwóch latach ktoś zapyta „dlaczego wtedy zrobiliście to tak, a nie inaczej?”, odpowiedź jest na wyciągnięcie ręki.

Krok 9: Przeglądy okresowe i re-ewaluacja ryzyka

Ryzyko AI nie jest stałe. Zmienia się otoczenie regulacyjne, dane wejściowe, zachowania użytkowników, a nawet sama strategia firmy. Dlatego rozsądny framework nie kończy się w momencie produkcyjnego wdrożenia – przewiduje cykliczne przeglądy.

W praktyce sprawdza się prosty rytm: coroczny (lub częstszy przy systemach krytycznych) przegląd projektu, podczas którego zespół odpowiada m.in. na pytania:

• czy system jest nadal używany zgodnie z pierwotnym celem,
• czy zmienił się zakres danych lub krąg osób, na które system oddziałuje,
• czy pojawiły się nowe wytyczne regulatorów lub orzecznictwo wpływające na ocenę ryzyka,
• czy incydenty z ostatniego okresu wymagają zmiany parametrów, modelu lub zasad nadzoru,
• czy na rynku pojawiły się nowe, bezpieczniejsze technologie, które opłaca się wdrożyć.

Takie przeglądy nie muszą być wielkim ceremoniałem. Czasem wystarczy dwugodzinne spotkanie z udziałem właściciela biznesowego, technicznego i compliance, zakończone krótką notatką i zaktualizowaną kartą ryzyka.

Krok 10: Włączenie frameworku w „normalne” procesy IT i biznesowe

Osobny „proces AI”, który żyje obok reszty organizacji, szybko stanie się martwy. Aby framework oceny ryzyka rzeczywiście działał, trzeba go wpleść w istniejące mechanizmy: zarządzania portfelem projektów, architekturą, bezpieczeństwem informacji, a nawet HR.

W praktyce oznacza to kilka konkretnych kroków organizacyjnych:

• dodanie prostych pytań AI do formularza zgłoszenia projektu (czy używa uczenia maszynowego, czy przetwarza dane osobowe, czy wpływa na decyzje o klientach),
• włączenie „check-pointów AI” do procesu architektonicznego – np. obowiązkowa konsultacja z zespołem ds. AI lub komitetem przed przejściem do fazy budowy,
• powiązanie kart ryzyka AI z rejestrem ryzyk korporacyjnych, aby zarząd widział łączny obraz,
• krótkie szkolenia dla product ownerów i menedżerów: kiedy zgłaszać projekt na ścieżkę wzmocnioną, jak korzystać z matryc ryzyka, jak czytać raporty z monitoringu modeli.

W jednej z organizacji wystarczyło dodać trzy pola do istniejącego formularza „wniosek o projekt” i prostą instrukcję: jeśli odpowiedziałaś „tak” na dwa lub więcej pytań, oznacz projekt jako AI i zaplanuj przegląd z zespołem ds. ryzyka technologicznego. Dzięki temu pomysły AI przestały „przemykać bokiem” poza formalnym procesem decyzyjnym.

Przykładowy „lightweight” workflow dla małego projektu AI

Nie każdy projekt wymaga rozbudowanej orkiestracji. Czasem chodzi o prosty model rekomendacji produktów w sklepie internetowym czy klasyfikację zgłoszeń supportowych. Da się zbudować lekką wersję frameworku, która nie zadusi innowacji biurokracją.

Taki uproszczony workflow może wyglądać tak:

1. Mini-karta projektu – jedna strona z opisem use case’u, danych, użytkowników.
2. Check-lista regulacyjna – 10–15 pytań tak/nie. Jeśli większość to „nie”, projekt idzie ścieżką lekką; jeśli kilka „tak” – krótka konsultacja z prawnikiem/RODO.
3. Prosta karta danych – co to za dane, skąd pochodzą, czy ktoś je „przejrzał pod kątem biasu”.
4. Podstawowe metryki i testy – zrozumiałe dla biznesu: jaka jest skuteczność, jak zmienia się w czasie, co się dzieje przy skrajnych przypadkach.
5. Mini-plan monitoringu – dwie-trzy metryki, prosty próg alarmowy i nazwisko osoby odpowiedzialnej.
6. Notatka z akceptacji – zgoda właściciela biznesowego i technicznego, ewentualnie szybka konsultacja z compliance.

Efekt? Nawet mały zespół, bez rozbudowanego działu prawnego, ma uporządkowany sposób myślenia o ryzyku. A jednocześnie nie potrzeba tygodni na wypełnianie szablonów – kilka godzin rozsądnej pracy wystarcza, by świadomie podjąć decyzję „wchodzimy z tym na produkcję”.

Jak mierzyć „dojrzałość” w zarządzaniu ryzykiem AI

Żeby wiedzieć, dokąd zmierzać z frameworkiem, dobrze jest uchwycić aktualny poziom dojrzałości organizacji. Tu przydaje się prosta skala – nie po to, by kogoś oceniać, ale by móc planować kolejne kroki.

Przykładowe poziomy można opisać tak:

• Poziom 1 – ad hoc – projekty AI powstają „z pasji” zespołów, bez wspólnego języka, bez jednolitej dokumentacji, ryzyko ocenia się intuicyjnie.
• Poziom 2 – podstawowy – istnieje prosty formularz zgłoszenia projektów AI, kilka podstawowych szablonów (karta projektu, karta danych), sporadyczne przeglądy z udziałem prawnika/RODO.
• Poziom 3 – ustrukturyzowany – działa komitet lub funkcja odpowiedzialna za AI, są ścieżki standardowa i wzmocniona, regularne przeglądy projektów i incydentów.
• Poziom 4 – zintegrowany – zasady AI wplecione w procesy IT i biznesowe, portfel projektów AI widoczny na poziomie zarządu, metryki ryzyka raportowane regularnie.
• Poziom 5 – optymalizujący – organizacja uczy się z każdego incydentu, ulepsza procesy, prowadzi dialog z regulatorami i klientami, włącza perspektywę etyczną w strategię produktową.

Większość firm technologicznie dojrzałych celuje w poziom 3–4: wystarczająco uporządkowany, żeby nie tonąć w chaosie, ale nadal elastyczny. Poziom 5 jest zwykle ambicją dużych graczy lub sektorów szczególnie regulowanych, jak medycyna czy finanse.

Dlaczego ten framework „robi różnicę” w rozmowie IT–prawnik–biznes

Najczęściej zadawane pytania (FAQ)

Na czym polega różnica między ryzykiem w projektach AI a zwykłym ryzykiem IT?

W klasycznym IT ta sama funkcja, przy tych samych danych, daje ten sam wynik, dopóki ktoś nie zmieni kodu. W AI logika nie jest „twardo zakodowana” – model uczy się zachowania z danych i parametrów. Niewielka zmiana danych treningowych, architektury czy sposobu trenowania może dać zupełnie inne rezultaty.

Do tego dochodzi zjawisko „starzenia się” modeli (model drift): system, który dziś działa dobrze i sprawiedliwie, za kilka miesięcy może już faworyzować inne grupy lub gorzej przewidywać wyniki, bo zmieniło się otoczenie biznesowe. Klasyczne podejścia do ryzyka IT skupiają się na awariach, backupach czy bezpieczeństwie, a w AI trzeba dodatkowo brać pod uwagę np. stronniczość, halucynacje czy wyjaśnialność decyzji.

Jakie są główne rodzaje ryzyka w projektach AI?

Praktyczna mapa ryzyk w AI obejmuje kilka przenikających się obszarów. Dzięki temu prawnicy, IT i biznes mogą rozmawiać o tym samym, używając zbliżonego języka.

• Ryzyka prawne (RODO, AI Act, prawo autorskie, odpowiedzialność za produkt).
• Ryzyka etyczne i społeczne (dyskryminacja, naruszenie praw człowieka, wykluczenie grup).
• Ryzyka techniczne i bezpieczeństwa (błędy modeli, podatność na ataki, jakość danych).
• Ryzyka biznesowe i finansowe (złe decyzje kredytowe, nietrafione rekomendacje, straty).
• Ryzyka reputacyjne (kryzysy w mediach, utrata zaufania klientów i regulatorów).
• Ryzyka organizacyjne i kompetencyjne (brak odpowiedzialności, brak wiedzy o AI w zespołach).

Jedno zdarzenie może dotyczyć kilku kategorii naraz. Dyskryminujący algorytm to jednocześnie problem etyczny, prawny, biznesowy i reputacyjny.

Jakie przepisy prawa najczęściej dotyczą systemów AI w firmach?

W europejskich realiach punkt wyjścia to zwykle RODO. Wiele systemów AI przetwarza dane osobowe, a gdy na tej podstawie podejmowane są istotne decyzje (np. kredyty, rekrutacja, ubezpieczenia), pojawia się profilowanie i zautomatyzowane podejmowanie decyzji z całym pakietem obowiązków: przejrzystość, możliwość zakwestionowania decyzji, często także DPIA (ocena skutków dla ochrony danych).

Kolejny poziom to projektowane rozporządzenie AI Act, które dzieli systemy na kategorie ryzyka (niedopuszczalne, wysokie, ograniczone, minimalne) i nakłada rygorystyczne wymogi na systemy wysokiego ryzyka, np. scoring kredytowy czy rekrutację. Równolegle działają przepisy sektorowe (np. prawo bankowe, medyczne), prawo autorskie (dane treningowe, generowane treści) oraz ogólne zasady odpowiedzialności za produkt i usługę.

Co to jest „model drift” i dlaczego jest ważny w ocenie ryzyka AI?

Model drift to sytuacja, w której model AI stopniowo traci jakość lub zaczyna zachowywać się inaczej, niż zakładano, choć kod i architektura się nie zmieniły. Zmienia się za to świat: zachowania klientów, oferta produktów, procesy wewnętrzne, a nawet warunki gospodarcze.

W praktyce wygląda to tak: model scoringowy trenowany na danych sprzed kilku lat dobrze ocenia ryzyko kredytowe „wczorajszych” klientów, ale słabiej radzi sobie z nowymi segmentami lub zmienionymi produktami. Jeśli organizacja nie monitoruje jakości i sprawiedliwości decyzji modelu, może przez długi czas nie zauważyć, że systematycznie krzywdzi jakąś grupę albo generuje koszty.

Jakie konkretne ryzyka wiążą się z wykorzystaniem chatbotów i modeli generatywnych?

Najczęstszy problem to tzw. halucynacje, czyli przekonujące, ale fałszywe odpowiedzi. Z perspektywy prawa to potencjalne wprowadzanie w błąd, szkoda majątkowa, a czasem także naruszenie dóbr osobistych. Dla biznesu to z kolei ryzyko reputacyjne: klient może publicznie pokazać sprzeczne informacje uzyskane od chatbota i od człowieka.

Dodatkowo pojawia się ryzyko ujawniania danych poufnych (gdy model „przecieka” treści z treningu lub kontekstu), naruszenie prawa autorskiego w generowanych treściach, a także problem odpowiedzialności za obietnice składane przez chatbota. Przykład z praktyki: klient powołuje się na obietnicę „braku prowizji” wygenerowaną przez bota, a bank musi tłumaczyć się przed regulatorem, dlaczego komunikacja była niespójna z regulaminem.

W jaki sposób AI może prowadzić do dyskryminacji i jak to ocenić w ramach ryzyka?

Modele uczą się z historii, a historia bywa stronnicza. Jeśli w danych z przeszłości jakaś grupa częściej dostawała odmowę kredytu albo gorzej płatną pracę, model może uznać, że to „dobry wzorzec” i powielać ten schemat w przyszłości. Statystycznie wszystko może wyglądać poprawnie, ale w efekcie umacniamy nierówności.

Ocena ryzyka powinna więc obejmować testy niedyskryminacji (np. analiza wyników dla różnych grup klientów), przegląd cech używanych przez model (np. lokalizacja, zawód, sposób zatrudnienia) oraz ocenę skutków decyzji dla określonych grup. Przy systemach wysokiego ryzyka (kredyty, rekrutacja, dostęp do świadczeń) to już nie tylko kwestia etyki, lecz także wymóg prawny i przedmiot szczególnego zainteresowania regulatorów.

Czy klasyczny rejestr ryzyk IT wystarczy do zarządzania ryzykiem AI?

Klasyczny rejestr ryzyk IT obejmuje zwykle takie pozycje jak utrata danych, awaria serwera, brak backupu czy podatność na ataki. To ważne, ale nie obejmuje zjawisk typowych dla systemów uczących się: halucynacji, stronniczości, braku wyjaśnialności, model driftu czy ryzyka skumulowanego (mały błąd powielony na tysiącach decyzji).

Dlatego w praktyce stosuje się uzupełniający framework ryzyk specyficznych dla AI, który:

• dodaje kategorie etyczne, społeczne i prawne związane z automatycznym podejmowaniem decyzji,
• uwzględnia monitoring modelu po wdrożeniu (jakość, sprawiedliwość, stabilność),
• łączy perspektywę IT, prawników i biznesu w jednym rejestrze, tak aby jedno zdarzenie można było ocenić z kilku stron.

Bez takiego rozszerzenia ryzyka AI „rozpływają się” w ogólnych kategoriach IT i łatwo przeoczyć problemy, które dotykają tysięcy klientów jednocześnie.

Kluczowe Wnioski

• Projekty AI niosą inne ryzyka niż klasyczne IT, bo zachowanie modelu zależy od danych treningowych, architektury i procesu uczenia, a drobna zmiana w którymkolwiek z tych elementów może radykalnie zmienić wyniki.
• Modele uczące się „starzeją się” szybciej niż tradycyjne oprogramowanie (model drift), więc nawet dziś poprawny i „sprawiedliwy” system za kilka miesięcy może generować błędne lub dyskryminujące decyzje.
• Typowe zjawiska jak halucynacje modeli językowych czy przejmowanie uprzedzeń z danych to nie ciekawostki techniczne, lecz realne źródła odpowiedzialności prawnej, szkód finansowych i kryzysów reputacyjnych.
• Efekt „czarnej skrzynki” sprawia, że trudno obronić się przed regulatorem czy sądem – organizacja musi być w stanie sensownie wyjaśnić, dlaczego model podjął daną decyzję, a nie zasłaniać się stwierdzeniem „tak wyszło z algorytmu”.
• Nawet niewielki błąd modelu, uruchomiony w skali tysięcy decyzji dziennie, może prowadzić do systematycznego krzywdzenia całych grup klientów, co interesuje regulatorów znacznie bardziej niż pojedyncze incydenty.
• Klasyczne podejście do ryzyka IT (awarie, backupy, bezpieczeństwo infrastruktury) nie obejmuje specyficznych zagrożeń AI, takich jak stronniczość, brak wyjaśnialności czy zachowanie modelu na nowych danych.