Due diligence dostawcy AI? Dobre praktyki z DORA i NIS2

Po co odkrywać Amerykę na nowo, skoro są już w tym zakresie nie tylko dobre praktyki, ale także bardzo konkretne akty prawne, które rozwiewają wiele wątpliwości. Brzmi dobrze, prawda?

Tak też podchodzę do tej ważnej części AI Governance. Części, która często jest traktowano po macoszemu, bez spojrzenia na szerszy horyzont.

Dzisiaj zaczniemy, a przez wakacje będziemy wątek kontynuować.

Czym właściwie jest DORA i dlaczego powinno mnie to interesować?

Dla tych, którzy nie spotkali się jeszcze z Digital Operational Resilience Act – to akt prawny (UE), który reguluje bardzo wiele aspektów zarządzania ryzykiem ICT dla sektora finansowego.

Jego adresatami są nie tylko same instytucje finansowe, ale także dostawcy tzw. usług ICT, czyli specyficznej (tam zdefiniowanej) grupy usług, które świadczy się na rzecz np. banków czy zakładów ubezpieczeń.

I właśnie dlatego jest to dla nas interesujące. Założę przy tym, że nie rozmawiamy o typowym przypadku „instytucja finansowa – dostawca usług ICT”, ale potraktujemy DORA jako dobre praktyki do wykorzystania wszędzie tam, gdzie pojawi się nam dostawa produktów i usług AI & Data.

Oczywiście, jeżeli jednocześnie wpadniemy w DORA, to – no cóż – mamy więcej roboty do wykonania. Ale…

… jest też bardziej konkretny powód!

A chodzi dokładnie o art. 28 ust. 4 lit. d) DORA, który nakazuje, aby instytucje finansowe dokładały należytej staranności w stosunku do potencjalnych zewnętrznych dostawców usług ICT i zapewniały, aby w trakcie całego procesu wyboru i oceny zewnętrzny dostawca usług ICT był odpowiedni.

Przepisy doprecyzowują także obowiązki w odniesieniu do podwykonawców dostawców, także w zakresie wspomnianego due diligence. Ma to zapewnić, że cały łańcuch dostaw jest należycie chroniony, w tym przypadku przed ryzykami ICT.

To de facto wymóg tzw. due diligence, który jest także zaszyty został także w AI Act w art. 17 ust. 1 lit. l) [zarządzanie zasobami, w tym środki związane z bezpieczeństwem dostaw], choć jest on nieco mniej „bezpośredni”. No, ale jest.

Szczególnym przypadkiem jest też art. 25 ust. 4 tego rozporządzenia, który nakłada szczególne obowiązki dla dostawcy systemu AI wysokiego ryzyka.

Czytaj także: Agentyczna AI: warto poważnie podejść do wdrażania systemu zarządzania bezpieczeństwem informacji

No dobra, ale jak na tym wszystkim skorzystać?

Punktem wyjścia będzie dla nas Rozporządzenie delegowane Komisji (UE) 2024/1773, które doprecyzowuje m.in. oczekiwania względem instytucji finansowej w zakresie należytej staranności względem jej dostawców usług ICT. Ta kwestia została zaadresowana w art. 6, ale prawda jest taka, że cały dokument o tym traktuje, tylko z szerszej perspektywy, także kontraktowej.

To co powinno być dla nas punktem wyjścia to POLITYKA, która odnosić się będzie do naszego podejścia do dostawców. Może to być polityka zakupowa, polityka wyboru dostawców czy jakaś inna polityka, która pokryje nam cały cykl zakupowy, ale także – później – monitorowanie ciągłego spełniania oczekiwanych przez nas warunków.

Takie elementy powinny znaleźć się też w polityce zarządzania systemami AI, choć jedynie jako pewne zagajenie tematu i wskazanie kierunku, a nie jako opis całego procesu.

Ja sugeruję także, aby stworzyć swoistą mapę decyzyjną dla etapów wyboru ścieżki (nasze rozwiązania, podmiot trzeci lub podejście hybrydowe).

Możemy też – mając odpowiednią checklistę podpiąć to jako załącznik do właściwego dokumentu. Aha, nie zapomnijmy także o tym, aby przynajmniej w zakresie kierunkowym zawrzeć te kwestie w naszej strategii (np. IT).

Wróćmy jednak do samej DORA i nałóżmy na podejście „finansowe” nasze oczekiwania w zakresie AI. DORA zobowiązuje, abyśmy w polityce określili odpowiedni i proporcjonalny proces wyboru i oceny potencjalnych zewnętrznych dostawców usług ICT.

Rekomenduję, aby stworzyć sobie jakieś narzędzie (niech to będzie excel), który ułatwi nam nie tylko zbieranie informacji od dostawcy, ale także dokumentowanie tych kwestii, bo dla potrzeb zarówno operacyjnych (weryfikacja SLA), jaki i audytowych to bardzo ważna kwestia.

Ja stworzyłem dla Was narzędzie (edukacyjne), które pokazuje jak mogłoby to wyglądać (uwzględnia ono także kwestie NIS2, DORA oraz AI Act).

Taki proces wyboru powinien zmierzać do tego, że dostawca [modelowo DORA pokazuje 6 aspektów; my je trochę rozszerzymy]:

[1 – rozwiązania organizacyjne, doświadczenie i reputacja] cieszy się odpowiednią reputacją biznesową, posiada wystarczające umiejętności, wiedzę fachową i odpowiednie zasoby finansowe, ludzkie i techniczne, stosuje standardy bezpieczeństwa informacji, ma odpowiednią strukturą organizacyjną, mechanizmy zarządzania ryzykiem i kontroli wewnętrznych oraz, w stosownych przypadkach, posiada zezwolenia lub rejestracje wymagane do świadczenia usług ICT wspierających krytyczne lub istotne funkcje w sposób wiarygodny i profesjonalny.

Co to oznacza w kontekście dostawców rozwiązań AI?

    powinniśmy przeprowadzić tzw. biały wywiad, który zweryfikuje możliwości finansowe (sprawozdanie finansowe), ale także reputację na rynku i umiejętności (referencje są tego uprawdopodobnieniem!);

    musimy zweryfikować czy dostawca „ma ludzi” do naszego projektu i czy zapewni on ciągłość świadczenia usług (także infrastrukturalnie), co może być istotne nie tylko na etapie wdrożenia, ale także w kontekście utrzymania);

    powinniśmy upewnić się, że dostarczane rozwiązania bazują na uznanych standardach, nie tylko w zakresie bezpieczeństwa, ale także np. zarządzania danymi (DAMA-BOK) czy etycznej sztucznej inteligencji godnej zaufania, będzie to dla nas szczególnie ważne w kontekście systemów AI wysokiego ryzyka i art. 10 AI Act;

    musimy zweryfikować czy dostawca poważnie podchodzi do kwestii zarządzania ryzykiem, choć oczywiście to obszar, który trudno zaadresować, ale np. możemy podpytać czy stosowane są standardy NIST AI Risk Management Framework i czy uwzględniane są ryzyka z np. MIT AI Risk Repository (mam dla Was narzędzie!);

    dla rozwiązań AI, które podlegają AI Act Act powinniśmy oczekiwać co najmniej potwierdzenia, że przepisy są lub będą przez podmiot stosowane, ale uwaga – często dostawcy będą od tego uciekać lub wskazywać, że skoro przepisy obowiązują, to nie trzeba niczego potwierdzać – to może być pomarańczowa lampka);

    ocenić powinniśmy także wiarygodność podmiotu, co możemy zrobić zarówno przez referencje, jak i spojrzenie na portfolio projektów – tutaj jednak musimy ostrożnie do tego podchodzić, bo dostawcy lubią czasem nieco pewne kwestie podkoloryzować;

    nie jestem fanem żądania od dostawcy pakietu polityk i procedur, ale czasami powinniśmy zebrać coś więcej niż oświadczenia dotyczące ich posiadania, np. opis posiadanego systemu zarządzania (np. ISO), co może wzmocnić naszą wiedzę na temat podmiotu i zwyczajnie go uwiarygodnić.

[2 – ciągłe monitorowanie, uczenie i dostosowywanie] jest w stanie monitorować istotne zmiany technologiczne i określić wiodące praktyki w zakresie bezpieczeństwa ICT oraz wdrażać je, w stosownych przypadkach, aby dysponować skutecznymi i solidnymi ramami operacyjnej odporności cyfrowej.

I tu dzisiaj utniemy, żeby przed oficjalnym startem wakacji Was nie przytłoczyć. Zachęcam do zapoznania się z narzędziem edukacyjnym do vendor assessment, który uwzględnia także rekomendacje OECD.