Technologiczna (techniczna?) odporność sztucznej inteligencji. Kolejne zderzenie z listą do samooceny systemów AI

Dziś kontynuujemy serię artykułów poświęconych dokumentowi „The Assessment List for Trustoworthy Artificial Intelligence (ALTAI)” opracowanemu przez ekspertów Komisji (UE). W ostatnich odsłonach pochylaliśmy się m.in. nad zagadnieniem odpowiedzialności czy udziału człowieka. Dzisiaj przyjrzymy się odporności (technologicznej), czyli głównie tematowi cyberbezpieczeństwa. Prawidłowe zaadresowanie ewentualnych luk może znacznie zminimalizować ryzyko odpowiedzialności w przypadku „wywalenia” się systemu opartego o sztuczną inteligencję. Zaczynamy! 

W dzisiejszych – cyfrowych – czasach zapewnienie (cyber)bezpieczeństwa staje się jednym z najważniejszych wyzwań dla praktycznie każdego podmiotu (na marginesie warto wskazać, że pojawił się nowy projekt ustawy o krajowym systemie cyberbezpieczeństwa – zmiany są duże i poświęcę im odrębny cykl). Eksperci Komisji (UE) podkreślają, że przy projektowaniu systemów opartych o sztuczną inteligencję niezwykle istotne jest zapewnienie, że już na etapie projektowania wykorzystywane rozwiązania zapewnią (jakąś) odporność na zidentyfikowane ryzyka. Obejmuje to także te ryzyka, które mogą wynikać np. z interwencji ludzkiej czy „cyfrowej”, która może doprowadzić do negatywnych skutków. Warto spojrzeć też na rekomendacje ENISA w sprawie tworzenia oprogramowania (pisałem o tym dokumencie w tym artykule).

W kontekście tego punktu listy eksperci Komisji zaproponowali kilka obszarów, które należy wziąć pod uwagę audytując własne rozwiązania

Odporność na ataki i cyberbezpieczeństwo 

W pierwszej kolejności powinniśmy odpowiedzieć sobie na pytanie o to czy nasz system AI może mieć negatywny wpływ na otoczenie, w tym naszych klientów (o specyficznych systemach hi-risk AI i projekcie rozporządzenia pisałem m.in. tutaj). Przy czym takie negatywne skutki powinniśmy rozumieć dość szeroko, tj. nie tylko jako szkodę fizyczną, ale również materialną czy utracone korzyści.

Analizując tą kwestię musimy uwzględnić też różne warianty (scenariusze), tj. wystąpienie błędów technicznych, ataki stron trzecich, nieodpowiednie użycie (niezgodne z celem) czy różnego rodzaje manipulacje. Warto rozważyć też odpowiednią certyfikację, np. zgodną z wymogami unijnymi, ale także przeanalizować czy mamy zgodność z powszechnie stosowanymi standardami. To pozwoli nam z kolei – wraz z odpowiednimi stress-testami – na odpowiedzenie sobie na pytanie o to czy (i jak) nasz system sztucznej inteligencji jest odporny na różne cyberataki, jak np. data poisoning (szczególnie niebezpieczne na etapie trenowania modelu, bo może wpływać np. na to, że dany algorytm będzie dyskryminował).

To oczywiście jedynie część ćwiczenia…

…bo nie możemy zapomnieć o tym, że musimy odpowiedzieć na to jakie rozwiązania mamy, aby zapewnić wymagany poziom bezpieczeństwa dla naszego systemu. Obejmować będzie to więc całokształt rozwiązań organizacyjnych (o wymogach wynikających z ustawy o krajowym systemie cyberbezpieczeństwa pisałem m.in. tutaj) i technicznych, w tym jakie mamy procedury i procesy w tym zakresie, ale także jak komunikujemy się z odbiorcami naszych systemów, np. czy dostarczamy aktualizacje. Ważne będzie też regularne przeprowadzanie testów penetracyjnych, a szczególne wymagania mogą pojawić się np. w przypadku handlu algorytmicznego czy robo-advisory (więcej w tych artykułach).

Ogólne bezpieczeństwo 

To pewien standard. Musimy przede wszystkim dostosować nasze rozwiązania do zidentyfikowanych ryzyk. A jeżeli mamy zidentyfikowane ryzyka, to musimy je mierzyć i wyznaczać sobie momenty, w których potrzeba reakcji. Na to odpowiada de facto cały system zarządzania ryzykiem. W przypadku sektora finansowego najczęściej tego typu ryzyka „pakowane” są w obszar ryzyka operacyjnego. To nie tylko bezpieczeństwo naszych klientów, ale również nasze. Warto więc posiłkować się rozwiązaniami, które już funkcjonują w sektorach regulowanych, nawet jeżeli nie prowadzimy aż tak skomplikowanej działalności.

Precyzja

To w sumie trudny temat. Nawet najbardziej zaawansowane systemy AI potrafią się mylić i to całkiem poważnie. Rozwój sztucznej inteligencji i uczenia maszynowego przyśpieszył, ale nadal nie dysponujemy na tyle dobrymi danymi, aby zawsze mieć pewność co do efektywności naszych rozwiązań. No i pozostaje kwestia ustalenia satysfakcjonującego poziomu, który wcale nie musi oscylować w okolicach 98-99%, przy czym mamy pewne zastrzeżenie:

„Accuracy is only one performance metric and it might not be the most appropriate depending on the application. Monitoring false positives, false negatives, F1 score can help to determine if accuracy is actually reflecting the system’s performance”

Eksperci Komisji wskazują tutaj, że powinniśmy zrobić rachunek sumienia, tj. sprawdzić z jakich danych korzystamy i czy są one wystarczająco dobrej jakości, aktualne, kompletne i rzeczywiście odpowiednie. Pojawia się także pytanie o to co zrobimy w przypadku, kiedy system osiągnie niską „accuracy” i czy jesteśmy na to przygotowani. Ważna jest też komunikacja do użytkowników końcowych.

Niezawodność, plany awaryjne i odtwarzalność

Wszystko się ze sobą w jakimś stopniu zazębia. Mamy tutaj wskazanie, że powinniśmy mieć odpowiednie procedury i procesy pozwalające na ocenę tego czy AI działa, jak trzeba, tj. realizacje określone cele, np. oparte o KPI, a jeżeli nie to jakie mamy narzędzia szybkiego reagowania. Musimy mieć też możliwość zweryfikowania tych obszarów, w szczególności “reproducibility”, czyli odtworzenia schematu działania AI (zastosowanych metod czy zakresu danych). Ważne jest też monitorowanie jak nasz algorytm się uczy.

I to tyle na dzisiaj. W kolejnej odsłonie prywatność i zarządzanie danymi, czyli de facto kontynuacja tego wątku.