Projekt AI. Dlaczego dokumentacja musi być perfekcyjna

Każdy projekt technologiczny ma swoją specyfikę, ale pewne elementy są „stałe” i pojawiają się niezależnie od tej specyfiki. Takim elementem jest niewątpliwie dokumentacja, która ma znaczenie nie tylko projektowe (uzyskanie stosownych zgód, określenie wymogów funkcjonalnych i niefunkcjonalnych), ale także organizacyjne (odpowiedzialność) i kontraktowe. Znaczenie dokumentacji rośnie wobec faktu pojawienia się regulacji unijnych, w tym AI Act, które w niektórych sytuacjach będą wymagać konkretnych działań w tym zakresie. Nie uprzedzajmy jednak faktów.

Brak jednego wzorca

Nie ma czegoś takiego jak jeden wzorzec dokumentacji projektowej, podobnie jak nie ma jednej takiej samej organizacji. Stąd też zasadniczo to, jak taka dokumentacja będzie wyglądała i jakim językiem będzie napisana, zależeć będzie od jej twórców, którzy mogą (ale wcale nie muszą) mieć w tym zakresie konkretne wytyczne – o tym piszę w dalszej części artykułu.

Czytaj więcej

Biznes

Responsible AI – jak ustalić metryki wykonalności

Aby zbudować matrycę wskaźników etycznej AI, należy najpierw ustanowić zasady, które będą stosowane w procesie projektowania, rozwijania, wdrażania i stosowania sztucznej inteligencji. Powinny one wynikać z ducha organizacji i wartości, które są w niej przyjęte.

Faktem jest, że akurat obszar IT jest w tym zakresie dość sformalizowany (przynajmniej „na papierze”), a sama dokumentacja techniczna to nie tylko plik Word, ale de facto wszystko to, co znajdziemy w kodzie oprogramowania. Jakość kodu i ewentualne komentarze z pewnością pomagają w aktualizacji czy audycie, ale to oczywiście jedynie pewien wycinek, który naprawdę może wyglądać różnie.

Na zakres informacji będzie wpływał także etap cyklu życia, gdzie wytwarzamy dokumentację będącą efektem m.in. wstępnego przetwarzania danych, trenowania, walidacji czy testowania. Możemy wyróżnić m.in. dokumentację projektową, dla modelu, dla systemu, operacyjną, związaną z bezpieczeństwem czy po prostu techniczną, o której mowa także w AI Act. Powstawać będą także raporty obejmujące założenia oraz efekty konkretnych etapów, a nawet rekomendacje, które mogą posłużyć za wsparcie przy kolejnych krokach. To, co wytworzymy na tych etapach, może determinować także zakres odpowiedzialności wewnętrznej, a – jak wiemy – umowy czy dokumentację tworzymy na czasy kryzysu, a nie pokoju.

Dodatkowe procedury i wymogi

W przypadku systemów AI sprawa może się nieco komplikować, bo oprócz „tradycyjnej” dokumentacji IT możemy (powinniśmy) wprowadzić dodatkową „kwitologię”, która – jeżeli będzie rzetelnie wykorzystywana – pomoże zabezpieczyć nas przed dodatkowymi ryzykami, a także zwiększy efektywność wielu procesów. Choć to oczywiście idealny scenariusz, to warto go rozważyć, bo akurat systemy AI, szczególnie te „dotykające” ludzi, są często źródłem wielu wyzwań, z którymi radzić muszą sobie nie tylko inżynierowie, ale i pozostali interesariusze.

Wielokrotnie przywoływana przeze mnie norma ISO 42001:2023 dotycząca systemu zarządzania ryzykiem zawiera kilka wskazówek odnośnie tego, jaka „dodatkowa” dokumentacja powinna powstawać przy okazji tworzenia i wdrażania systemów AI. Znajdziemy tu np. AI System Impact Assessment, dokumentację procesu walidacji i testowania czy analizę ryzyka wykonywaną per system – to akurat część procesu zarządzania ryzykiem AI, ale to także dokumentacja, więc i o tym nie należy zapominać. W procesie projektowania, rozwijania i wdrażania systemów AI mogą powstawać także karty danych (jako część procesu data governance) czy karty systemów AI, a jeżeli poważnie podchodzimy do kwestii Responsible & Trustworthy AI, to także dodatkowe checklisty, jak chociażby te zaproponowane przez Microsoft. Nie twierdzę, że to najlepszy wybór, ale warto się wzorować na dobrych standardach.

No i nie możemy także zapominać, że w niektórych sytuacjach będziemy mieli przetwarzanie danych osobowych, a to dodatkowa „papierologia”. A jeżeli korzystamy np. z chmury obliczeniowej, to do całościowej dokumentacji powinniśmy włączyć także „Terms & Conditions” wraz z towarzyszącymi politykami, procedurami czy wymogami. Jest tego trochę, a pamiętajmy, że część takiej dokumentacji jest dostępna wyłącznie online i choć dostawcy zapewniają o integralności, to zasada „ufaj, ale kontroluj” powinna mieć zastosowanie. A kontrola to także utrzymywanie dokumentów na własnych zasobach.

Trzy kluczowe warunki

Zanim przejdę do kwestii dokumentacji technicznej dla systemów wysokiego ryzyka objętych AI Act muszę podkreślić jedną ważną rzecz – dobra dokumentacja (techniczna, operacyjna, projektowa etc.) ma szansę powstać jedynie wtedy, gdy:

- mamy wyznaczone osoby, których odpowiedzialnością jest przygotowanie określonych kwitów oraz

- mamy jasno określone zasady tworzenia takiej dokumentacji (polityki, procedury, instrukcje), a w idealnym układzie także wzorce takiej dokumentacji, a także

- zapewniamy proces obsługi dokumentacji, w tym jej przechowywania czy archiwizacji.

Ten ostatni aspekt możemy spełnić tworząc wewnętrzną „wiki”, czyli zestawienie najważniejszych informacji dotyczących w ogóle procesu projektowania, rozwijania i wdrażania AI. W zakresie odpowiedzialności nie unikniemy „twardego” nałożenia obowiązku połączonego z rozliczalnością za ewentualne błędy. Oczywiście musimy mieć świadomość, że niektóre dokumenty to odpowiedzialność więcej niż jednej osoby. Niby banał, ale czasami nam umyka.

Dokumentacja techniczna

Chciałbym nawiązać tu do wspomnianego już przeze mnie (pośrednio) art. 11 AI Act, który określono mianem „dokumentacji technicznej”. Dowiemy się z niego, że:

1) dokumentację techniczną sporządza się w taki sposób, aby wykazać, że system sztucznej inteligencji wysokiego ryzyka spełnia wymogi określone w niniejszej sekcji [wymogi dla systemów wysokiego ryzyka] oraz aby zapewnić właściwym organom krajowym i jednostkom notyfikowanym niezbędne informacje w jasnej i wyczerpującej formie w celu oceny zgodności systemu sztucznej inteligencji z tymi wymogami,

2) jako minimum wskazuje się tutaj elementy określone w załączniku IV do AI Act, który jest dość obszerny i obejmuje tak naprawdę wiele aspektów określonych w art. 9 i nast. AI Act (to wymogi kierowane do dostawcy systemów), ale także informacje odnośnie stosowanych metryk, środków cyberbezpieczeństwa, metod pozyskiwania danych i ich przetwarzania czy procedur związanych z testowaniem i walidacją.

Co ciekawe, w dokumentacji tej należy zawrzeć także:

- szczegółowe informacje na temat monitorowania, funkcjonowania i kontroli systemu sztucznej inteligencji, w szczególności w odniesieniu do: jego możliwości i ograniczeń w działaniu, w tym stopni dokładności w odniesieniu do konkretnych osób lub grup osób, wobec których system ma być stosowany, oraz ogólnego oczekiwanego poziomu dokładności w odniesieniu do jego zamierzonego celu;

- przewidywalnych niezamierzonych skutków i źródeł zagrożeń dla zdrowia i bezpieczeństwa, praw podstawowych i dyskryminacji w świetle zamierzonego celu systemu AI;

- środków nadzoru nad ludźmi potrzebnych zgodnie z art. 14, w tym środków technicznych wprowadzonych w celu ułatwienia interpretacji danych wyjściowych systemów AI przez podmioty wdrażające;

- specyfikacji dotyczących danych wejściowych, w stosownych przypadkach.

Obowiązek dostawcy

Łatwo już było. Sam obowiązek ciążyć będzie na dostawcy, choć ma bezpośrednie przełożenia i na wdrażającego system, bo to on ma obowiązek korzystać (a więc i wdrażać) z systemu zgodnie ze stosownymi instrukcjami, które muszą powstać na bazie dokumentacji technicznej. Artykuł 26 ust. 1 AI Act stanowi, że:

1. Podmioty wdrażające systemy sztucznej inteligencji wysokiego ryzyka podejmują odpowiednie środki techniczne i organizacyjne w celu zapewnienia korzystania z takich systemów zgodnie z instrukcjami użytkowania dołączonymi do systemów, zgodnie z ust. 3 i 6.

2. Wymogi te będą w sposób bezpośredni wpływały na relacje kontraktowe pomiędzy zamawiającymi a dostawcami rozwiązań. Z jednej strony sami dostawcy będą chcieli się zabezpieczyć poprzez zobowiązanie zamawiającego do stosowania instrukcji oraz podejmowania działań naprawczych (corrective actions), a z drugiej samym podmiotom, które będą korzystały z takich systemów, będzie zależało na upewnieniu się, że wszystko jest w porządku ze zgodnościowego punktu widzenia. Przełoży się to na klauzule, które znajdziemy w kontraktach na dostawę. Co do tego nie mam żadnych wątpliwości.

Dokumentacja będzie jednak tworzona także ze względu na wewnętrzną „potrzebę” wynikającą z przepisów prawa czy regulacji (sektor finansowy będzie z pewnością obciążony w tym zakresie znacznie bardziej) i audyty oraz inspekcje, które będą się pojawiały także w związku ze stosowaniem AI Act.

* * *

Dlatego warto już dziś zadbać o przygotowanie zestawienia tego, co w dokumentacji powinno się znaleźć, szczególnie jeżeli także i teraz tworzymy lub wykorzystujemy systemy AI, które w przyszłości będziemy traktować jako systemy wysokiego ryzyka. Taka rewizja znacznie ułatwi działanie.