Polityka zakupowa dla projektów AI & Data. Jak wykorzystać obszar ICT, w tym DORA

Załóżmy, że chcemy w naszej organizacji inwestować więcej w rozwiązania przetwarzające dane i wykorzystujące "AI". Problem polega na tym, że nasze wewnętrzne zasoby są niewystarczające do tego, aby samodzielnie realizować inicjatywy "od A do Z" lub jest to zwyczajnie nieopłacalne. To w zasadzie typowy scenariusz dla wielu dużych organizacji, które nie są firmami technologicznymi i dla których sama technologia jest środkiem do realizacji celu, a nie celem samym w sobie.

W takiej sytuacji stajemy przed dylematem czy próbować mimo wszystko własnymi siłami, czy też wesprzeć się zewnętrznymi dostawcami, którzy nierzadko mają już gotowe rozwiązania lub są w stanie te rozwiązania nam szybko dostarczyć. Zakładając, że rozumiemy znaczenie naszych ograniczeń, zapewne wybierzemy ścieżkę zakupową.

I o ścieżce zakupowej w kontekście rozwiązań AI & Data chciałbym dzisiaj "porozmawiać", bo ta powinna wyglądać nieco inaczej niż "dotychczas". To, że coś działa od lat, nie znaczy, że jest najlepsze dzisiaj. Wiele organizacji staje dzisiaj przed pytaniem - jak zmienić politykę i procedury zakupowe, aby odpowiadały one wyzwaniom nie tylko teraźniejszości. Od razu zaznaczam, że nie jest moim celem zachęcanie Was do tworzenia odrębnych polityk zakupowych, choć wyodrębnienie ścieżki dla projektów AI & Data może być kuszące i dać organizacji "kopa" w zakresie innowacyjnych projektów. Będzie po prostu szybciej, ale i bezpieczniej.

Takie wyodrębnienie może "mieć miejsce" w osobnej liście kontrolnej, np. przy umowach outsourcingowych lub w inny sposób zakorzenione w obsłudze zakupów na dostarczanie oprogramowania.

Na początek uwaga ogólna - zastanawiając się nad procesem zakupowym pod AI nie możemy abstrahować od tego jak wygląda cykl życia (oraz wytwórczy) tego typu rozwiązań, w szczególności nie możemy zapominać o ważnym aspekcie jakim jest kwestia danych, które wykorzystujemy w kontekście tych systemów. Tyczy się to nie tylko "tradycyjnej" AI, ale także LLM'ów, dla których dane również mają znaczenie.

Co ważne, w niektórych miejscach możemy wspierać się np. Rozporządzeniem UE 2022/2554, czyli DORA, które odnosi się do zarządzania ryzykiem ICT. Ryzyko ICT jest przecież immanentną częścią rozwiązań AI & Data, a więc skorzystanie z "gotowych rozwiązań" wydaje się naturalne, nawet jeżeli nie jesteśmy wprost adresatami tego aktu. Szczególnie ważny będzie w tym przypadku art. 6 rozporządzenia delegowanego Komisji (UE) 2024/1173, w którym znajdziemy "należytą staranność", którą powinien cechować się wybór dostawcy dla rozwiązań ICT.

Przyjmijmy, że "typowa" polityka zakupowa składa się z kilku stałych elementów, do których należą [uzupełniam to od razu o kontekst związany z projektami AI & Data:

🎯 cel i zakres polityki, w której powinniśmy uwzględnić również cele, które określiliśmy, np. w strategii co do wykorzystania danych oraz AI; może ona uwzględniać np. większe zainteresowanie konkretnymi rozwiązaniami typu LLM czy też zapewnienie, że kupowane rozwiązania spełniają standardy etyczne;

🎯 przebieg procesu zakupowego - tutaj ważne jest, abyśmy dobrze odzwierciedlili różne scenariusze, a także to, że często projekty są realizowane od fazy POC/testowania przez wdrożenie i operacjonalizację rozwiązania; musimy w tym miejscu uwzględnić to, że zakup rozwiązań może "ewoluować" i rozszerzać się w ramach identyfikacji dalszych potrzeb; nie możemy też pominąć tego jak wygląda sam proces "dochodzenia" do oprogramowania, czyli tzw. Software Development Life-cycle;

🎯 ocena potrzeb i analiza wymagań - tutaj ważne jest, aby uwzględniać zarówno kwestie związane z potrzebami biznesowymi, jak i prawne, które będą determinowały (nie)możliwość nawiązania określonej relacji z dostawcą; w tym miejscu określamy też wymagania funkcjonalne i niefunkcjonalne, a to już bardzo istotny element, któremu powinniśmy poświęcić więcej miejsca w kontekście AI [np. kwestie związane z rozwiązaniami AI/MLOps, dostępnością wysokojakościowych danych]; jest to też miejsce, w którym należy zwrócić uwagę na istniejącą architekturę IT, która może stanowić barierę dla nowych rozwiązań;

🎯 ocena dostawcy i due diligence - tutaj ważne będzie wyodrębnienie procesu oceny dostawców AI & Data ze względu na specyfikę świadczonych przez nich usług i dostarczanych produktów; zwróćcie uwagę na to jak podchodzi do tego wspomniane już rozporządzenie delegowane:

To dobry kierunek. Z pewnością musimy jednak uwzględnić tutaj kwestie związane z AI Act, w szczególności "capacity" do realizacji projektów, które dotyczą systemów sztucznej inteligencji wysokiego ryzyka.

🎯 koszty - tutaj jest to o tyle istotne, że wiele z rozwiązań AI jest dzisiaj "chmurowych", co oznacza, że koszt wykorzystania rozwiązania nie jest z góry znany i trzeba trzymać na tym rękę; innymi słowy trzeba opisać sposób realizowania tzw. FinOps;

🎯 aspekty prawne i umowne - tutaj jest to o tyle istotne, że projekty AI & Data często pojawia się wiele wymogów prawnych, regulacyjnych oraz ETYCZNYCH; polityka zakupowa powinna przewidywać - także w połączeniu z obszarem due diligence - zastosowanie wzorcowych klauzul umownych, które można znaleźć np. tuta j; znaczenie ma to szczególnie wtedy, gdy mówimy o dostarczaniu systemów "AI'actowych";

🎯 zarządzanie cyklem życia rozwiązań - ważne, aby upewnić się w jaki sposób przebiega np. proces monitorowania pod kątem takich zjawisk jak model drift / model decay czy też jak często umowa podlega przeglądowi i aktualizacji; w świecie dynamicznie zmieniających się technologii i dostępu do danych może to być jeden z kluczowych obszarów, który niewątpliwie będzie wymagał monitorowania, np. na wzór rejestrów umów outsourcingowych w sektorze finansowym;

🎯 odpowiedzialność i role - jeżeli mamy wyodrębnione role w zakresie AI Governance, to niewątpliwie ten fakt powinien być odzwierciedlony także w samej polityce; osoby będące właścicielami biznesowymi muszą uzyskać stosowne wsparcie, np. AI stewarda w celu dokonania kompleksowej oceny proponowanych rozwiązań.

Polityki mogą być oczywiście nieco szersze i uwzględniające np. specyfikę sektorów regulowanych (np. outsourcing), ale to już temat na oddzielny felieton. Ważne, żeby polityka była jasna (zawierała też wizualizację samego procesu) i przyczyniała się do osiągania celów biznesowych. Istotna rola będzie tutaj samych jednostek odpowiedzialnych za zakupy, które muszą rozumieć specyfikę tego typu postępowań.

Tak jak wspomniałem, nie musimy tworzyć nowej polityki, ale tylko dostosować ją do specyfiki projektów AI & Data. To wcale nie musi być duża praca, ale jeżeli nie mamy "kompletnie nic", to taka rewizja może być dobrym początkiem dla naszego AI Governance.