Sztuczna inteligencja coraz częściej jest oferowana jako gotowa usługa w modelu SaaS. Klient otrzymuje panel, asystenta, analizę dokumentów, kreator pism, workflow i abonament. W tle jednak często działają zewnętrzne modele AI dostarczane przez dużych dostawców technologii.
Czy taki model jest bezpieczny? Tak — ale tylko wtedy, gdy dostawca potrafi wykazać, gdzie trafiają dane, kto je przetwarza, jakie są ograniczenia systemu i jak zapewniono zgodność z RODO, AI Act oraz wymaganiami cyberbezpieczeństwa.
Ten artykuł jest przeznaczony dla dostawców platform AI, firm planujących wdrożenie sztucznej inteligencji, jednostek publicznych, kancelarii prawnych, działów compliance, IOD, specjalistów ds. cyberbezpieczeństwa, audytorów oraz osób odpowiedzialnych za zakup i ocenę usług SaaS wykorzystujących AI.
Nie ma nic złego w oferowaniu platformy AI opartej na zewnętrznych modelach, pod warunkiem że klient wie, jak działa usługa, gdzie trafiają dane, kto jest podprocesorem, jakie są ograniczenia systemu i jakie zabezpieczenia wdrożono.
Czym jest taki model biznesowy?
Typowy model działania wygląda następująco: klient korzysta z platformy SaaS, wgrywa dokumenty albo wpisuje zapytanie, platforma wykonuje własną logikę biznesową, pobiera dane z bazy wiedzy, stosuje reguły bezpieczeństwa, a następnie wysyła część informacji do zewnętrznego modelu AI. Model generuje odpowiedź, która wraca do platformy, jest prezentowana użytkownikowi i często zapisywana w historii, logach albo aktach sprawy.
Wartość dostawcy nie musi polegać na tym, że sam stworzył model bazowy. Wartością może być:
- bezpieczna aplikacja SaaS,
- specjalistyczny interfejs dla konkretnej branży,
- integracja z dokumentami klienta,
- anonimizacja lub pseudonimizacja danych,
- kontrola dostępu,
- logi audytowe,
- workflow zatwierdzania,
- dobór właściwego modelu do konkretnego zadania,
- integracja z bazami wiedzy,
- polityka retencji,
- umowa powierzenia danych,
- zgodność z wymaganiami RODO, AI Act i normami ISO.
To oznacza, że nie sprzedaje się „samego AI”. Sprzedaje się bezpieczny proces wykorzystania AI w organizacji.
Co w takim modelu jest dobre?
Zaletą takiego podejścia jest szybkie wejście na rynek i możliwość wykorzystania bardzo dobrych modeli bez budowania ogromnej infrastruktury technicznej. Dzięki temu mniejsze firmy mogą tworzyć specjalistyczne rozwiązania dla prawa, administracji, finansów, cyberbezpieczeństwa, edukacji, obsługi klienta czy zarządzania dokumentacją.
Drugą zaletą jest możliwość ograniczenia tzw. shadow AI. Jeżeli organizacja nie zapewni pracownikom bezpiecznego narzędzia, będą korzystać z prywatnych kont, darmowych chatbotów albo przypadkowych narzędzi online. Z punktu widzenia RODO i cyberbezpieczeństwa jest to znacznie bardziej ryzykowne niż kontrolowana platforma, która ma umowę powierzenia, logi, retencję, role użytkowników i jasno określone zasady korzystania.
Trzecią zaletą jest standaryzacja. Dobrze zaprojektowana platforma AI może wymusić minimalizację danych, ostrzeżenia przed wprowadzaniem danych wrażliwych, zatwierdzanie wyników przez człowieka, rejestrowanie użycia systemu oraz stosowanie dozwolonych przypadków użycia.
Czwartą zaletą jest elastyczność. Platforma może korzystać z różnych modeli w zależności od zadania: innego do prostego streszczenia, innego do analizy długich dokumentów, innego do OCR, innego do klasyfikacji, a jeszcze innego do zapytań wymagających większej dokładności. To pozwala optymalizować jakość i koszty.
Co jest problematyczne?
Największym problemem jest brak przejrzystości. Klient powinien wiedzieć, czy ma do czynienia z własnym modelem dostawcy, czy z platformą wykorzystującą modele zewnętrzne. Nie chodzi o ujawnianie całego know-how technicznego, lecz o uczciwe pokazanie przepływu danych, kategorii dostawców i ról poszczególnych podmiotów.
Drugim problemem jest odpowiedzialność. Dostawca platformy może twierdzić, że model bazowy należy do innej firmy, więc nie odpowiada za jego błędy. Z perspektywy klienta usługa jest jednak kupowana od dostawcy platformy. Jeżeli system wygeneruje błędne pismo, nieprawdziwe orzeczenie, wadliwe streszczenie albo błędną rekomendację, klient będzie oczekiwał wyjaśnień od podmiotu, z którym zawarł umowę.
Trzecim problemem jest przetwarzanie danych osobowych. W promptach, dokumentach, historii rozmów, logach, embeddingach i odpowiedziach AI mogą pojawić się dane osobowe, dane szczególnych kategorii, dane dzieci, dane pracowników, dane mieszkańców, dane pacjentów, dane klientów albo informacje objęte tajemnicą zawodową.
Czwartym problemem jest łańcuch dostaw. Platforma może korzystać z dostawcy modelu, dostawcy chmury, dostawcy OCR, dostawcy transkrypcji, dostawcy monitoringu, dostawcy systemu ticketowego i dostawcy poczty. Każdy z tych podmiotów może być elementem ryzyka.
W ocenie takiej usługi nie wystarczy sprawdzić, czy system „działa”. Trzeba ustalić, czy jest audytowalny, czy ma właściwe umowy, czy dane są minimalizowane, czy klient zna podprocesorów, czy określono retencję, czy wykonano ocenę ryzyka i czy użytkownik wie, że wynik AI wymaga weryfikacji przez człowieka.
Dostawca platformy AI powinien być w stanie udowodnić, a nie tylko zadeklarować, że usługa jest bezpieczna, zgodna i kontrolowana.
Ryzyka dla ochrony danych osobowych
Z punktu widzenia RODO podstawowe pytanie brzmi: kto, w jakim celu, na jakiej podstawie i przez jaki czas przetwarza dane.
W wielu wdrożeniach biznesowych klient będzie administratorem danych, dostawca platformy będzie podmiotem przetwarzającym, a dostawcy zewnętrznych modeli mogą być dalszymi podmiotami przetwarzającymi. Nie można jednak przyjmować tego automatycznie. Jeżeli dostawca platformy samodzielnie określa cele i sposoby przetwarzania, wykorzystuje dane klienta do własnej analityki, doskonalenia usługi, trenowania modeli albo tworzenia własnych zbiorów, może wystąpić również jako administrator albo współadministrator.
Ten układ musi wynikać z umowy, dokumentacji i faktycznego sposobu działania systemu, a nie tylko z deklaracji handlowej.
Najważniejsze ryzyka RODO to:
- brak umowy powierzenia danych,
- brak podstawy dla podpowierzenia,
- niepełny wykaz podprocesorów,
- transfer danych poza Europejski Obszar Gospodarczy bez właściwej oceny,
- niejasna retencja promptów, plików, odpowiedzi i logów,
- wykorzystywanie danych klienta do trenowania lub ulepszania modeli,
- nadmierne logowanie treści zapytań,
- brak minimalizacji danych,
- brak mechanizmu usunięcia danych po zakończeniu umowy,
- brak oceny potrzeby wykonania DPIA,
- brak rozdzielenia danych poszczególnych klientów,
- brak jasnych zasad korzystania z danych szczególnych kategorii.
Szczególnie ryzykowne jest założenie, że „model AI wszystko anonimizuje” albo że „skoro dane są w promptach, to nie są już danymi osobowymi”. To błędne podejście. Dane osobowe mogą występować zarówno w dokumencie źródłowym, jak i w zapytaniu, odpowiedzi, logu technicznym, historii rozmowy oraz indeksie wektorowym.
Stanowisko EROD: model AI nie usuwa automatycznie…
W ocenie ryzyk związanych z platformami AI/SaaS warto uwzględnić stanowisko Europejskiej Rady Ochrony Danych. EROD w Opinii 28/2024 dotyczącej przetwarzania danych osobowych w kontekście modeli sztucznej inteligencji zwróciła uwagę na kwestie, które mają bezpośrednie znaczenie dla dostawców i klientów takich usług.
Po pierwsze, nie można automatycznie zakładać, że model AI, który był trenowany lub wykorzystywany z udziałem danych osobowych, jest zawsze anonimowy. Ocena anonimowości wymaga analizy konkretnego przypadku, w tym prawdopodobieństwa pozyskania danych osobowych z modelu albo z jego odpowiedzi. Dla dostawców platform AI oznacza to konieczność posiadania dokumentacji potwierdzającej, jakie dane są przetwarzane, czy trafiają do modelu, czy są utrwalane, czy są wykorzystywane do dalszego uczenia oraz jakie środki ograniczające ryzyko zastosowano.
Po drugie, EROD podkreśla znaczenie zasady rozliczalności. Dostawca platformy AI nie powinien opierać się wyłącznie na deklaracji, że „dane nie są przetwarzane” albo „model jest anonimowy”. Takie twierdzenia powinny mieć pokrycie w architekturze systemu, umowach z podprocesorami, polityce retencji, testach bezpieczeństwa, konfiguracji API oraz dokumentacji przepływu danych.
Po trzecie, jeżeli dane osobowe są przetwarzane w celu rozwoju, wdrożenia lub korzystania z modelu AI, należy prawidłowo określić podstawę prawną przetwarzania. W przypadku powoływania się na prawnie uzasadniony interes konieczna jest realna analiza: czy interes jest zgodny z prawem, konkretny i aktualny, czy przetwarzanie jest konieczne oraz czy interes dostawcy lub klienta nie jest nadrzędny wobec praw i wolności osób, których dane dotyczą.
Po czwarte, dla klientów korzystających z platform AI istotne jest nie tylko to, czy ich własne dane są bezpiecznie przetwarzane, ale również to, czy dostawca platformy potrafi wykazać, że modele i usługi zewnętrzne wykorzystywane w łańcuchu przetwarzania nie powstały i nie działają w sposób sprzeczny z zasadami RODO. W praktyce oznacza to potrzebę badania dostawców, żądania dokumentacji, oceny podprocesorów i prowadzenia rejestru ryzyk.
Wniosek jest prosty: w usługach AI nie wystarczy samo zapewnienie, że „dane są bezpieczne”. Potrzebne są dowody: umowy, rejestry, oceny ryzyka, DPIA tam, gdzie jest wymagana, polityka retencji, wykaz podprocesorów, opis transferów, testy bezpieczeństwa oraz możliwość wykazania, że dane klienta nie są wykorzystywane do celów innych niż uzgodnione w umowie.
Ryzyka cyberbezpieczeństwa
Platformy AI/SaaS przetwarzające dokumenty są atrakcyjnym celem ataku. Mogą zawierać umowy, akta spraw, dane osobowe, tajemnicę przedsiębiorstwa, dokumentację prawną, dane finansowe, dokumenty kadrowe, dane infrastruktury IT i informacje o zabezpieczeniach organizacji.
Najważniejsze ryzyka cyberbezpieczeństwa to:
- prompt injection, czyli próba wymuszenia na modelu ujawnienia danych lub obejścia instrukcji,
- wyciek danych z bazy wiedzy lub RAG,
- błędna izolacja danych różnych klientów,
- przejęcie kont użytkowników,
- brak MFA,
- nadmiarowe uprawnienia administratorów,
- ujawnienie promptów systemowych,
- data poisoning, czyli wprowadzenie złośliwych lub zmanipulowanych danych do bazy wiedzy,
- model stealing, czyli próba odtworzenia działania modelu lub logiki systemu,
- model inversion, czyli próba uzyskania danych z odpowiedzi modelu,
- brak monitoringu nietypowych zapytań,
- brak testów bezpieczeństwa specyficznych dla AI,
- brak procedury reagowania na incydenty AI.
W klasycznej aplikacji SaaS chroni się konta, bazę danych, API i infrastrukturę. W aplikacji AI trzeba dodatkowo chronić kontekst, prompty, odpowiedzi, modele, embeddingi, logikę systemową, źródła wiedzy oraz integracje z dostawcami zewnętrznymi.
Ryzyka jakości i odpowiedzialności za wynik
AI potrafi wygenerować odpowiedź językowo poprawną, logiczną i przekonującą, ale nieprawdziwą. W przypadku prostych zastosowań skutkiem może być strata czasu. W przypadku prawa, administracji, finansów, HR, medycyny albo cyberbezpieczeństwa skutkiem może być realna szkoda.
Typowe błędy AI to:
- zmyślone podstawy prawne,
- nieistniejące orzeczenia,
- błędne sygnatury,
- pominięcie istotnego wyjątku,
- błędne streszczenie dokumentu,
- fałszywe przypisanie informacji do osoby,
- niewłaściwa klasyfikacja sprawy,
- błędna rekomendacja działania,
- nieuprawnione wnioski z niepełnych danych,
- zbyt pewny ton mimo braku podstaw.
Dlatego platforma AI nie powinna być przedstawiana jako system, który zastępuje specjalistę. Bezpieczniejszy model to: AI przygotowuje projekt, analizę lub propozycję, a człowiek weryfikuje, zatwierdza i odpowiada za użycie wyniku.
Ryzyka regulacyjne związane z AI Act
W przypadku AI Act kluczowe znaczenie ma nie sama technologia, ale przeznaczenie systemu. Ten sam model może być użyty do prostego streszczenia dokumentu albo do wsparcia decyzji dotyczącej człowieka. Ryzyko prawne w tych dwóch przypadkach będzie zupełnie inne.
Dostawca platformy powinien klasyfikować konkretne przypadki użycia, a nie tylko całą platformę jako „niskiego ryzyka”.
Przykładowo:
- streszczenie dokumentu może być zastosowaniem niższego ryzyka,
- chatbot obsługujący użytkownika wymaga przejrzystości,
- analiza CV może wejść w obszar wysokiego ryzyka,
- ocena pracownika może wejść w obszar wysokiego ryzyka,
- wsparcie decyzji administracyjnej wobec osoby może wymagać szczególnej oceny,
- scoring finansowy może być wysokiego ryzyka,
- analiza danych medycznych wymaga bardzo ostrożnego podejścia,
- biometria może być wysokiego ryzyka albo zakazana, zależnie od celu.
Dostawca powinien mieć listę zastosowań dozwolonych, ograniczonych i zakazanych. Bez tego klient może użyć platformy w sposób, którego dostawca nie przewidział, ale który nadal będzie kojarzony z jego produktem.
Przykładowe case studies
Case 1: kancelaria prawna analizuje akta spraw
Kancelaria korzysta z platformy AI do streszczania pism, porównywania wersji umów i przygotowywania projektów odpowiedzi. Wartość biznesowa jest duża: oszczędność czasu, szybkie porządkowanie dokumentów, wsparcie pracy prawnika.
Ryzyka są jednak istotne. Dokumenty mogą zawierać dane osobowe, tajemnicę zawodową, dane kontrahentów, dane finansowe i informacje procesowe. Jeżeli platforma wysyła dokumenty do zewnętrznego modelu, kancelaria powinna wiedzieć, gdzie trafiają dane, czy są przechowywane, czy są używane do trenowania i kto ma do nich dostęp.
Wymagane minimum: umowa powierzenia, wykaz podprocesorów, zakaz trenowania na danych klienta, retencja, szyfrowanie, MFA, logi, możliwość usunięcia danych, ocena potrzeby DPIA oraz jasna instrukcja, że wynik AI jest projektem wymagającym weryfikacji prawnika.
Case 2: urząd wykorzystuje AI do projektów odpowiedzi na pisma mieszkańców
Urząd chce przyspieszyć przygotowywanie projektów pism, odpowiedzi na wnioski i streszczeń dokumentów. To może być dobry kierunek, jeżeli AI nie podejmuje decyzji administracyjnej, lecz wspiera pracownika.
Ryzyka są podwyższone, ponieważ dokumenty urzędowe mogą zawierać dane mieszkańców, dane dzieci, dane zdrowotne, dane majątkowe, informacje o sprawach administracyjnych i dane z postępowań. Dodatkowo urząd musi wykazać rozliczalność, retencję, bezpieczeństwo i kontrolę dostępu.
Wymagane minimum: ocena potrzeby DPIA, klasyfikacja przypadków użycia, zakaz używania AI do automatycznego podejmowania decyzji, zatwierdzanie wyniku przez pracownika, rejestr użycia, umowa powierzenia, ocena transferów, polityka retencji, procedura incydentu oraz szkolenie użytkowników.
Case 3: firma używa AI do wstępnej selekcji CV
Pracodawca chce automatycznie analizować CV, oceniać kandydatów i wskazywać najlepsze osoby do rozmowy. Biznesowo może to wyglądać atrakcyjnie, ale prawnie jest to jeden z bardziej ryzykownych przypadków.
System może wpływać na dostęp człowieka do zatrudnienia. Może powielać uprzedzenia, dyskryminować, błędnie oceniać kandydatów albo wykorzystywać dane, które nie powinny mieć znaczenia w rekrutacji.
Wymagane minimum: szczegółowa klasyfikacja AI Act, DPIA, ocena ryzyka dyskryminacji, jasne kryteria oceny, nadzór człowieka, dokumentacja działania systemu, możliwość zakwestionowania wyniku, minimalizacja danych, ograniczenie profilowania i pełna transparentność wobec kandydatów.
Case 4: spółka wykorzystuje AI do analizy zgłoszeń cyberbezpieczeństwa
Zespół IT używa AI do streszczania alertów, analizy logów, przygotowania rekomendacji działań i porządkowania incydentów. To może zwiększyć skuteczność zespołu bezpieczeństwa.
Ryzyko polega na tym, że do systemu mogą trafić adresy IP, identyfikatory użytkowników, loginy, fragmenty konfiguracji, nazwy systemów, podatności, klucze techniczne albo informacje o incydencie. Niektóre z tych danych mogą być danymi osobowymi albo informacjami wrażliwymi z punktu widzenia bezpieczeństwa.
Wymagane minimum: zakaz wprowadzania haseł, tokenów i kluczy, filtrowanie danych, DLP, logi dostępu, szyfrowanie, ograniczenie retencji, izolacja środowisk, testy prompt injection oraz procedura eskalacji incydentów.
Case 5: firma finansowa używa AI do analizy ryzyka klienta
Instytucja finansowa chce wykorzystać AI do analizy dokumentów klienta, historii transakcji lub ryzyka umownego. W tym przypadku ryzyko regulacyjne i RODO jest bardzo wysokie, zwłaszcza jeżeli wynik może wpływać na dostęp do usługi, cenę, ocenę wiarygodności albo decyzję finansową.
Wymagane minimum: klasyfikacja AI Act, DPIA, ocena wpływu AI, jasne zasady nadzoru człowieka, dokumentacja modelu, ograniczenie danych wejściowych, testy jakości, testy stronniczości, logi decyzji i możliwość wyjaśnienia wyniku.
Case 6: dostawca platformy zmienia model AI bez poinformowania klienta
Dostawca platformy korzysta z kilku modeli zewnętrznych. Po zmianie jednego z modeli odpowiedzi stają się krótsze, mniej precyzyjne albo inaczej interpretują dokumenty. Klient nie wie, że doszło do zmiany, ale widzi pogorszenie jakości.
To pokazuje ryzyko braku zarządzania zmianą. Zmiana modelu, dostawcy, regionu przetwarzania, retencji lub parametrów działania powinna być kontrolowana, testowana i dokumentowana.
Wymagane minimum: rejestr modeli, wersjonowanie, testy regresji, informowanie klientów o istotnych zmianach, procedura zatwierdzania zmian i możliwość powrotu do poprzedniej konfiguracji, jeżeli jest to technicznie i umownie możliwe.
Co takie firmy powinny wdrożyć?
Dostawca platformy AI/SaaS powinien wdrożyć nie tylko aplikację, ale system zarządzania usługą AI.
Podstawowy pakiet powinien obejmować:
- politykę AI,
- rejestr systemów AI,
- rejestr przypadków użycia,
- klasyfikację AI Act,
- analizę ryzyka AI,
- analizę ryzyka RODO,
- DPIA, jeżeli jest wymagana,
- ocenę wpływu systemu AI,
- rejestr modeli i dostawców,
- rejestr podprocesorów,
- rejestr transferów poza EOG,
- politykę retencji,
- regulamin korzystania z platformy,
- umowę powierzenia danych,
- procedurę zmiany modelu,
- procedurę incydentu AI i RODO,
- testy bezpieczeństwa AI,
- testy jakości odpowiedzi,
- logi audytowe,
- mechanizm human review,
- szkolenia AI literacy,
- limity tokenów i monitoring kosztów,
- SLA i zasady wsparcia.
Jak się standaryzować?
Najlepszy kierunek to nie pojedynczy dokument „zgodności z AI”, ale zintegrowany system zarządzania.
Dostawca powinien rozważyć oparcie się na następujących standardach:
- ISO/IEC 27001 — bezpieczeństwo informacji,
- ISO/IEC 27701 — zarządzanie prywatnością i rolami w przetwarzaniu danych osobowych,
- ISO/IEC 42001 — system zarządzania sztuczną inteligencją,
- ISO/IEC 23894 — zarządzanie ryzykiem AI,
- ISO/IEC 42005 — ocena wpływu systemu AI,
- ISO 9001 — jakość usługi, reklamacje, zmiany, odpowiedzialność i doskonalenie,
- ISO 22301 — ciągłość działania, jeżeli usługa ma znaczenie krytyczne dla klienta.
Standaryzacja nie powinna polegać na deklaracji marketingowej. Powinna tworzyć dowody: rejestry, polityki, procedury, testy, raporty, zatwierdzenia, logi, przeglądy i audyty.
Co dostawca powinien zapewnić klientowi?
Klient powinien otrzymać pakiet informacji pozwalający ocenić, czy usługa może być bezpiecznie używana w jego organizacji.
Rzetelny dostawca powinien zapewnić:
- opis działania platformy,
- informację, czy korzysta z modeli zewnętrznych,
- wykaz kategorii dostawców i podprocesorów,
- umowę powierzenia danych,
- informację o transferach poza EOG,
- politykę retencji danych,
- deklarację dotyczącą trenowania modeli na danych klienta,
- opis zabezpieczeń technicznych i organizacyjnych,
- zasady szyfrowania,
- zasady kontroli dostępu,
- informacje o logach audytowych,
- zasady usuwania danych po zakończeniu umowy,
- instrukcję bezpiecznego korzystania z AI,
- listę zastosowań zakazanych lub wymagających dodatkowej oceny,
- SLA,
- procedurę zgłaszania incydentów,
- informacje o istotnych zmianach modeli lub dostawców,
- możliwość audytu lub pakiet audytowy,
- wsparcie w ocenie DPIA i klasyfikacji AI Act.
Dla klientów publicznych, finansowych, medycznych i regulowanych taki pakiet nie jest dodatkiem. Jest warunkiem odpowiedzialnego wdrożenia.
Czego klient powinien wymagać przed zakupem?
Przed zakupem platformy AI klient powinien zadać dostawcy co najmniej następujące pytania:
- Czy system korzysta z modeli zewnętrznych?
- Jakich kategorii modeli używa?
- Czy dane są przekazywane poza EOG?
- Czy dostawca ma umowę powierzenia?
- Kto jest podprocesorem?
- Czy dane klienta są używane do trenowania modeli?
- Jak długo przechowywane są prompty, pliki, odpowiedzi, logi i embeddingi?
- Czy można usunąć dane po zakończeniu umowy?
- Czy system ma MFA i role użytkowników?
- Czy istnieją logi audytowe?
- Czy wynik AI jest oznaczony jako wymagający weryfikacji?
- Czy system był testowany pod kątem prompt injection?
- Czy dostawca prowadzi rejestr zmian modeli?
- Czy klient otrzyma informację o istotnej zmianie dostawcy lub modelu?
- Czy są określone zastosowania zakazane?
- Czy wykonano klasyfikację AI Act?
- Czy dostawca wspiera ocenę potrzeby DPIA?
- Czy są procedury incydentowe?
- Czy są limity użycia i kontrola kosztów?
- Czy dostawca posiada system zarządzania bezpieczeństwem, prywatnością i AI?
Jeżeli dostawca nie potrafi odpowiedzieć na te pytania, wdrożenie powinno być wstrzymane albo ograniczone do testów na danych sztucznych, testowych lub skutecznie zanonimizowanych.
AI jako usługa wymaga zaufania i rozliczalności
Platformy AI/SaaS oparte na zewnętrznych modelach są naturalnym kierunkiem rozwoju rynku. Mogą przynieść realne korzyści: automatyzację pracy z dokumentami, szybszą analizę informacji, wsparcie specjalistów, ograniczenie niekontrolowanego korzystania z prywatnych narzędzi AI oraz lepszą kontrolę nad użyciem sztucznej inteligencji w organizacji.
Warunek jest jeden: taka usługa musi być przejrzysta, audytowalna i zarządzana.
Dobre rozwiązanie AI to nie tylko efektowna odpowiedź modelu. To cały system: dane, użytkownicy, role, uprawnienia, logi, retencja, dostawcy, umowy, klasyfikacja ryzyka, testy, nadzór człowieka, cyberbezpieczeństwo i odpowiedzialność.
Największe ryzyko nie polega na tym, że firma korzysta z zewnętrznego modelu. Największe ryzyko polega na tym, że klient nie wie, że tak jest, a dostawca nie ma pełnej kontroli nad przepływem danych, retencją, podprocesorami, kosztami, jakością odpowiedzi i zastosowaniami wysokiego ryzyka.
Z perspektywy audytora bezpieczna platforma AI powinna spełniać trzy warunki:
- jasno informować, jak działa i z jakich kategorii dostawców korzysta,
- zapewniać klientowi rozliczalność w zakresie RODO, AI Act i cyberbezpieczeństwa,
- mieć wdrożony system zarządzania AI, ryzykiem, bezpieczeństwem i prywatnością.
Dopiero wtedy można mówić o odpowiedzialnym oferowaniu AI jako usługi.
Warto sprawdzić ryzyka przed wdrożeniem
Wdrożenie platformy AI/SaaS albo oferowanie takiej usługi klientom powinno być poprzedzone niezależną oceną ryzyk. Szczególnego sprawdzenia wymagają: przepływy danych, role RODO, umowy powierzenia, podprocesorzy, transfery poza EOG, retencja promptów i logów, wykorzystanie zewnętrznych modeli, zabezpieczenia techniczne, klasyfikacja przypadków użycia według AI Act oraz zasady nadzoru człowieka nad wynikiem AI.
Taka analiza nie musi blokować innowacji. Przeciwnie — pozwala uporządkować usługę, przygotować dokumentację dla klienta, ograniczyć ryzyko prawne i techniczne oraz wykazać, że AI jest wdrażana w sposób odpowiedzialny, bezpieczny i audytowalny.
Jeżeli organizacja planuje wdrożenie AI albo dostawca przygotowuje platformę AI/SaaS do oferowania klientom, warto przeprowadzić audyt przedwdrożeniowy obejmujący RODO, AI Act, cyberbezpieczeństwo, podprocesorów, retencję, logi audytowe i dokumentację zgodności.
FAQ
Czy firma może oferować AI, jeżeli korzysta z zewnętrznych modeli?
Tak. Samo korzystanie z zewnętrznych modeli AI nie jest problemem. Problem pojawia się wtedy, gdy dostawca nie informuje klienta, jak działa usługa, kto uczestniczy w przetwarzaniu danych, czy dane trafiają poza EOG, jaka jest retencja i czy dane klienta są wykorzystywane do trenowania modeli.
Czy prompt może zawierać dane osobowe?
Tak. Prompt może zawierać dane osobowe, dane szczególnych kategorii, dane pracowników, klientów, mieszkańców, pacjentów, kontrahentów albo informacje objęte tajemnicą zawodową. Dane osobowe mogą wystąpić również w odpowiedzi AI, historii rozmowy, logach technicznych, załączonych dokumentach i indeksach wektorowych.
Czy dostawca platformy AI zawsze jest podmiotem przetwarzającym?
Nie zawsze. W wielu przypadkach dostawca SaaS będzie podmiotem przetwarzającym, a klient administratorem danych. Jeżeli jednak dostawca samodzielnie określa cele i sposoby przetwarzania, wykorzystuje dane do własnej analityki, rozwoju usługi lub trenowania modeli, może wystąpić jako administrator albo współadministrator.
Czy każda platforma AI jest systemem wysokiego ryzyka według AI Act?
Nie. Ryzyko zależy przede wszystkim od przeznaczenia i konkretnego przypadku użycia. Inaczej ocenia się streszczenie dokumentu, inaczej analizę CV, ocenę pracownika, scoring finansowy, wsparcie decyzji administracyjnej albo zastosowania medyczne. Dostawca powinien klasyfikować konkretne przypadki użycia, a nie tylko całą platformę jednym ogólnym stwierdzeniem.
Czy wystarczy deklaracja, że dane nie są używane do trenowania modelu?
Nie. Taka deklaracja powinna mieć pokrycie w umowach, konfiguracji usługi, dokumentacji technicznej, polityce retencji, wykazie podprocesorów i warunkach korzystania z zewnętrznych modeli. Klient powinien otrzymać dowody, a nie tylko ogólne zapewnienie handlowe.
Czy korzystanie z AI może ograniczyć shadow AI w organizacji?
Tak. Kontrolowana platforma AI z umową powierzenia, logami, retencją, rolami użytkowników i zasadami korzystania może ograniczyć ryzyko używania przez pracowników prywatnych lub niesprawdzonych narzędzi AI. Warunkiem jest wdrożenie jasnej polityki korzystania z AI i szkolenie użytkowników.
Czy przed wdrożeniem AI trzeba wykonać DPIA?
Nie zawsze. Najpierw należy ocenić, czy planowane przetwarzanie może powodować wysokie ryzyko dla praw i wolności osób fizycznych. Jeżeli tak, DPIA będzie wymagana. W praktyce DPIA należy szczególnie rozważyć, gdy system AI przetwarza duże ilości danych osobowych, dane szczególnych kategorii, dane dzieci, wspiera ocenę osób albo może wpływać na ich prawa lub sytuację.
Artykuł ma charakter informacyjny i ekspercki. Nie stanowi indywidualnej opinii prawnej ani audytu konkretnego systemu AI. Ocena zgodności powinna być wykonana dla konkretnego przypadku użycia, architektury, kategorii danych, dostawców, umów i sposobu wdrożenia.
