Czy projektowany system z pewnością podlega pod AI Act?
Obecnie projektuje się wiele zaawansowanych systemów informatycznych, ale nie każdy z nich zostanie zakwalifikowany jako sztuczna inteligencja w rozumieniu AI Act1. Aby było to możliwe, muszą zostać spełnione łącznie dwie przesłanki:
-
system został stworzony z wykorzystaniem przynajmniej jednej metody i podejścia, o których mowa w załączniku I do rozporządzenia (lista jest dosyć obszerna i obejmuje m.in. mechanizmy uczenia maszynowego, różnego rodzaju metody oparte na logice i wiedzy oraz metody szacowania statystycznego);
-
oprogramowanie generuje wyniki, w tym treści, przewidywania, zalecenia lub decyzje, wpływające na środowisko, w którym działa software.
Praktyki niedopuszczalne w projektowaniu AI. Czego należy bezwzględnie unikać?
Kiedy software house ustali, że projekt, który realizuje, z pewnością podlega regulacjom AI Act, już na etapie tworzenia backlogów należy zweryfikować, czy przypadkiem nie uwzględniają one praktyk, które zostały bezwzględnie zakazane przez unijnego ustawodawcę. Ich implementacja stanowi szczególnie jaskrawy przypadek naruszenia przepisów wspólnotowych i może wiązać się z nałożeniem kary nawet do wysokości 40 milionów euro lub 7% światowego obrotu. Jakich praktyk należy się wystrzegać? Przede wszystkim chodzi o systemy:
-
stosujące techniki podprogowe w celu zniekształcenia zachowania odbiorcy, jeżeli może spowodować to u danej lub innej osoby szkodę psychiczną, lub fizyczną;
-
wykorzystujące dowolnej słabości określonej grupy osób ze względu na wiek, niepełnosprawność ruchową lub zaburzenie psychiczne, jeżeli mogłoby to prowadzić do zniekształcenia zachowania danej lub innej osoby, lub powodować u nich szkodę psychiczną, lub fizyczną;
-
implementujące scoring społeczny prowadzący do oceny lub klasyfikacji, lub wiarygodności osób fizycznych, jeżeli miałoby to prowadzić do krzywdzącego lub niekorzystnego traktowania;
-
wykorzystujący zdalną identyfikację biometryczną (np. na podstawie scanningu rysów twarzy, głosu, wzorzec siatkówki oka) za wyjątkiem sytuacji, kiedy jest to niezbędne do zapobiegania najpoważniejszym przestępstwom.
Co w takim razie zrobić, kiedy klient naciska na wdrożenie praktyk niedopuszczalnych? Najprostszym rozwiązaniem jest rezygnacja ze zlecenia, aby nie ryzykować ewentualnego sporu i wysokich kar administracyjnych. Alternatywną strategią może być wykorzystanie jednej spośród dozwolonych metod do osiągnięcia zbliżonego rezultatu.
Warto zwrócić uwagę, że ostateczny tekst rozporządzenia nie jest jeszcze znany, a ostatnie poprawki są jeszcze rozważane przed ostateczną publikacją skonsolidowanego tekstu. Nie ulega jednak wątpliwości, że już teraz firmy zajmujące się tworzeniem oprogramowania implementującego rozwiązania AI mogą uwzględnić główne założenia rozporządzenia, aby uniknąć późniejszych, czasochłonnych zmian.
Ocena skali ryzyka systemu AI
Chcąc zapewnić zgodność z rozporządzeniem, zespół przygotowujący system sztucznej inteligencji powinien odpowiedzieć na pytanie o to, jaki poziom ryzyka reprezentuje oprogramowanie. Unijny ustawodawca skupia się na systemach wysokiego ryzyka. Za takie uważa się software, który spełnia łącznie następujące warunki:
-
system jest związany z produktem objętym unijnym ustawodawstwem harmonizacyjnym. Będą to np. maszyny montażowe, zabawki dla dzieci, dźwigi, rekreacyjne jednostki pływające, urządzenia radiowe, urządzenia przeznaczone do wykorzystania w atmosferze potencjalnie wybuchowej;
-
system lub produkt, którego system jest częścią, podlegają ocenie zgodności przeprowadzanej przez osobę trzecią w celu wprowadzenia produktu do obrotu lub oddania go do użytku.
Należy zwrócić uwagę, że rozporządzenie uprawnia Komisję Europejską do poszerzenia katalogu rozwiązań, które zostaną uznane za systemy wysokiego ryzyka. Z tego względu oceny nie należy dokonywać z wyprzedzeniem, ale na moment przyjmowania zamówienia, ponieważ może się okazać, że w rzeczywistości katalog systemów wysokiego ryzyka będzie bardziej obszerny niż obecnie.
W niedługiej przyszłości może się okazać, że bardzo wiele systemów sztucznej inteligencji będzie musiało spełnić nowe wymagania. Wśród nich można wymienić, chociażby oprogramowanie stosowane przez banki do wykrywania nadużyć finansowych, algorytmy do diagnostyki medycznej czy oprogramowanie maszyn przemysłowych.
Rozporządzenie nie odnosi się do systemów niskiego ryzyka (ang. minimal or no-risk AI). Można do nich zaliczyć algorytmy implementowane w grach czy narzędzia do filtrowania SPAM-u. W tych wszystkich przypadkach rozporządzenie AI Act nie znajduje zastosowania.
O czym pamiętać przygotowując system AI wysokiego ryzyka?
Jeżeli przedmiotem umowy jest stworzenie systemu sztucznej inteligencji wysokiego ryzyka (np. oprogramowania do inteligentnych samochodów albo linii maszynowej w fabryce), należy pamiętać o wdrożeniu wszystkich wymagań wskazanych w rozporządzeniu. Przyjrzyjmy się im po kolei.
Stworzenie systemu zarządzania ryzykiem
Producent musi zaprojektować, utrzymać i rozwijać system zarządzania ryzykiem przez cały cykl życia produktu. Taki system powinien uwzględniać potencjalne ryzyko, jakie może pojawić się:
-
w każdym systemie sztucznej inteligencji wysokiego ryzyka;
-
podczas racjonalnego korzystania z systemu;
-
zgodnie z analizą danych testowych wykorzystywanych podczas przygotowywania oprogramowania.
Ważne jest dążenie do wyeliminowania ryzyka związanego z korzystania z systemem, a tam, gdzie jest to niemożliwe – jego ograniczenia w możliwie największym stopniu oraz prowadzenie mechanizmów kontroli tego ryzyka.
Jak powinny wyglądać testy systemów AI wysokiego ryzyka?
Każdy system zakwalifikowany jako AI wysokiego ryzyka musi przejść procedurę testową, która w możliwie największym stopniu będzie odwzorowywała warunki, w jakim software będzie funkcjonował docelowo. Testy mają za zadanie potwierdzić funkcjonalność systemu oraz spójność jego poszczególnych komponentów, nie muszą one jednak wykraczać poza wykorzystanie sztucznej inteligencji zgodnie z jej przeznaczeniem. O ile w przypadku np. skuterów wodnych przeznaczenie AI jest łatwe do przewidzenia, nie zawsze musi być równie oczywiste. Warto więc zastanowić się, czy procedury testowe nie powinny jednak wykraczać poza niezbędne minimum.
Testy należy przeprowadzać przed wprowadzeniem produktu do obrotu lub oddaniem go do użytku, przy czym wskaźniki i progi probabilistyczne (czyli punkty odniesienia dla konkretnych wartości oraz prawdopodobieństwo wystąpienia określonych sytuacji) powinny być adekwatne do sposobu wykorzystania systemu. Należy zwrócić szczególną uwagę, czy do systemu będą miały dostęp dzieci lub, czy system będzie miał wpływ na tę grupę odbiorców.
Niezależnie od poziomu dokładności potwierdzonego przez testy sandboxowe, każdy system AI musi być projektowany w taki sposób, aby uwzględniał możliwość przejęcia kontroli nad systemem AI przez człowieka. Takie rozwiązania stanowią swego rodzaju „bezpiecznik” na wypadek wystąpienia nieprzewidzianej awarii, której nie przewidzieli twórcy oprogramowania.
Wymagania dla systemów z uczeniem maszynowym
Jedną z bardziej popularnych praktyk AI jest wykorzystanie algorytmów uczenia maszynowego. Takie systemy (lub modele) są trenowane, czyli otrzymują różnego rodzaju zestawy danych w celu ich oceny i wyszukiwania wzorców oraz zależności między informacjami. Narzędzia machine learningu pomagają w takich dziedzinach, jak medycyna, bankowość czy ubezpieczenia, ponieważ modele „rozwijają” się wraz z odbiorcą, ucząc jego nawyków, predyspozycji oraz historii (np. zdarzeń medycznych). Rozporządzenie AI Act przewiduje dodatkowe wymagania dla tego rodzaju algorytmów.
Przede wszystkim wymaga się, aby dane treningowe, walidacyjne i testowe były dostarczane i zarządzane z wykorzystaniem dobrych praktyk. Takie zasady obejmują m.in.:
-
decyzje projektowe;
-
gromadzenie danych;
-
przetwarzanie danych;
-
stworzenie założeń oraz ocenę przydatności danych;
-
badania pod kątem tendencyjności;
-
wykrywanie luk i braków w danych.
Wymaga się, aby dane dostarczone na potrzeby treningów były adekwatne, reprezentatywne, wolne od błędów oraz kompletne, a także uwzględniały różnicowanie specyfiki oceny informacji dla określonego kontekstu, np. geograficznego lub behawioralnego.
W jaki sposób stworzyć dokumentację techniczną systemu AI?
Przepisy rozporządzenia wymagają sporządzenia kompleksowej dokumentacji technicznej projektowanego systemu. Powinna ona zostać przygotowana przed wprowadzeniem systemu do obrotu lub oddaniem do użytku oraz regularnie aktualizowana.
Układ dokumentacji jest dowolny, choć powinna ona zawierać przynajmniej informacje wymienione w załączniku IV do AI Act. Dokumentacja jest wieloczęściowa i obejmuje następujące elementy:
-
ogólny opis AI;
-
szczegółowy opis AI oraz procesu jego opracowywania;
-
szczegółowe informacje w zakresie monitorowania, funkcjonowania i kontroli oraz dokładności; ograniczeń;
-
opis systemu zarządzania ryzykiem;
-
opis zmian dokonanych w całym cyklu życia systemu;
-
wykaz norm zharmonizowanych, które znajdują zastosowanie;
-
kopię deklaracji zgodności z UE;
-
szczegółowy opis systemu stosowanego do oceny skuteczności AI oraz plan jego monitorowania po wprowadzeniu do obrotu.
Przygotowanie w sposób prawidłowy dokumentacji technicznej wymaga nie tylko wiedzy z zakresu programowania czy inżynierii, ale także prawa. Nasi specjaliści z praktyki NewTech mogą zająć się oceną kompletności takiego dokumentu oraz zasugerować zmiany przyczyniające się do jego przejrzystości.
Dbałość o transparentność aplikacji
Dostawca oprogramowania powinien zadbać o transparentność przygotowywanej aplikacji oraz jej przystępność dla docelowego odbiorcy. Oznacza to konieczność opracowania odpowiednio przejrzystego UX, ale też instrukcji obsługi. Takie dokument powinien opisywać, w jaki sposób korzystać z oprogramowania oraz wskazywać>m.in na:
-
tożsamość i dane kontaktowe dostawcy lub jego upoważnionego przedstawiciela;
-
cechy, możliwości i ograniczenia (w tym stopień dokładności) aplikacji;
-
środki nadzoru ze strony człowieka.
Dzięki temu użytkownik od początku wie, z jak dużą dozą ostrożności powinien podchodzić do produktu, a także do kogo – w razie potrzeby – kierować ewentualne skargi lub roszczenia.
Jak zabezpieczyć tworzony system przed błędami?
Dostawca oprogramowania ma obowiązek zadbać, aby tworzony system był odporny na błędy, usterki lub niespójności, które mogą pojawić się nie tylko w samym systemie, ale również w środowisku, dla którego został on zaprojektowany. Dbając o bezpieczeństwo AI należy pamiętać o:
-
zapewnieniu odpowiedniego poziomu dokładności, solidności i cyberbezpieczeństwa;
-
stworzeniu dodatkowych zabezpieczeń typu failsafe albo dostępności do systemu zapasowego;
-
zabezpieczeniu systemów uczących się przed bazowaniem na nieprawidłowych wynikach, co mogłoby prowadzić do narastającej tendencyjności.
Rozporządzenie AI Act nie zawiera dokładnych wytycznych w zakresie bezpieczeństwa, a wskazuje jedynie, że zabezpieczenia powinny być dopasowane do okoliczności i ryzyka. Z pewnością kluczowe znaczenie w wypracowaniu optymalnego poziomu ochrony mają kolejne testy, a także zastosowanie odpowiednio silnych algorytmów kryptograficznych.
Warto skonsultować ze specjalistami z zakresu prawa i nowych technologii optymalny dobór rozwiązań technologicznych tak, aby dostawca oprogramowania nie naraził się na zarzut niestaranności w pracach projektowych.
Dlaczego projektowanie systemów AI wymaga konsultacji prawnych?
Tworzenie systemu wykorzystującego rozwiązania sztucznej inteligencji to nie tylko pisanie kodu źródłowego czy programowanie sterowników. Przygotowując AI na zamówienie klienta należy pamiętać o spełnieniu całego szeregu wymagań prawnych – konieczności stworzenia procedur, polityk bezpieczeństwa, instrukcji, a także ich analizie pod kątem zgodności.
Przeprowadzenie kompleksowego compliance w zakresie AI przez kancelarię prawną daje klientowi pewność, że dostarczane przez niego rozwiązania zostały stworzone w sposób uwzględniający aktualne wymagania przepisów. Dzięki temu developer może czuć się bezpiecznie, ponieważ podpisanie umowy nie będzie wiązało się z zagrożeniami natury prawnej.
Pytania i odpowiedzi
Zgodnie z art. 9 ust. 4 in fine rozporządzenia, należytą uwagę zwraca się na wiedzę techniczną, doświadczenie, wykształcenie, jakich szkolenia oczekuje się od użytkownika, oraz środowisko, w którym ma być wykorzystywany system. W praktyce oznacza to, że więcej zapobiegliwości należy wykazać, projektując AI dla użytkowników należących do grup szczególnego ryzyka, np. dzieci lub osób w podeszłym wieku, niż np. software przeznaczony dla wykwalifikowanych inżynierów.
Jest to dopuszczalne, ale wyłącznie w celu wykrywania i korygowania tendencyjności systemów AI oraz przy zastosowaniu odpowiednio silnych zabezpieczeń pozwalających na pseudonimizację danych lub ich szyfrowanie.
Rejestrem zdarzeń określa się ewidencję wszystkich czynności, jakie były realizowane z wykorzystaniem systemu. Może to być data i godzina jego użycia, referencyjna baza danych, wskazanie danych wejściowych oraz których wybór doprowadził do określonego działania. Tego rodzaju rozwiązania zwykle są „zaszyte” w trybie serwisowym, niedostępnym dla zwykłego użytkownika.
Zaufali nam: