AI działa? Super. A kto za to odpowiada?

Ostatnio uczestniczyłem w Śniadaniu Klastrowym organizowanym przez Klaster IT (kancelaria Lis.Legal jest dumnym członkiem Klastra). Wydarzenie to wciąż siedzi mi w głowie. I to nie tylko przez miejsce spotkania, czyli Strefę Racing 🏎, ale też przez temat, który został podjęty: wdrażanie AI w organizacjach. A to dotyczy w zasadzie nas wszystkich.

Paweł Wodyński, czyli prelegent omawiający ten temat, słusznie podkreślił, że wdrożenie AI to nie jest po prostu „projekt IT”, ale zmiana modelu operacyjnego organizacji. Skoro AI zaczyna realnie wchodzić w procesy, to pojawia się to, co lubimy najbardziej, czyli prawo, odpowiedzialność i compliance. No i w ten sposób dochodzimy do słusznie lub niesłusznie demonizowanego AI Act.

Kiedy rozmawiam o AI Act, to uspokajam. Zgodność z AI Act to nie jest „rocket science”, szczególnie dla tych, którzy porządnie wdrożyli RODO.

Faktem jest jednak to, że AI Act ma kilka min i musimy, tak jak w przypadku wspomnianego już RODO, być ich świadomi. Pozwoli nam to uniknąć komplikacji na przyszłość. W tym artykule opowiem Wam o jednej z nich.

Czego dowiesz się z tego tekstu?

W skrócie

• AI Act nie ocenia wyłącznie narzędzia albo modelu. Kluczowy jest realny kontekst użycia.
• Ten sam model AI może być zwykłym wsparciem pracy biurowej albo elementem procesu wysokiego ryzyka.
• Organizacja, która zaczyna dostosowywać system AI do nowego celu, może nieplanowanie zmienić swoją rolę.
• Rekrutacja to dobry przykład obszaru, w którym szybka automatyzacja może podnieść poziom ryzyka.
• Przy AI warto sprawdzić use case zanim trafi na produkcję. Późniejsze dokładanie compliance bywa droższe i trudniejsze.

AI Act nie zaczyna się od modelu. Zaczyna się od użycia

W rozmowach o AI łatwo zacząć od pytania: jaki model wybieramy? W praktyce dla AI Act równie ważne, a często ważniejsze, jest pytanie: do czego ten system będzie używany.

Regulacja nie patrzy wyłącznie na sam model albo narzędzie. Znaczenie ma kontekst użycia, przeznaczenie systemu i realny wpływ na ludzi. Ten sam typ technologii może być neutralnym wsparciem pracy biurowej, ale może też stać się elementem procesu, który wpływa na dostęp do pracy, usługi, świadczenia albo innej ważnej decyzji.

Raz jeszcze podkreślę, że dla organizacji wdrożenie AI nie jest wyłącznie projektem IT. Często jest zmianą procesu operacyjnego. A jeśli zmienia się proces, trzeba spojrzeć także na role, odpowiedzialność, dane, nadzór człowieka i governance.

Nie chodzi o straszenie AI Act. Chodzi o to, żeby nie traktować wdrożenia jak prostego dodania narzędzia do stacku. W wielu przypadkach to narzędzie zaczyna współkształtować decyzje biznesowe, a wtedy zmienia się mapa ryzyka.

Fakapy przy AI często nie polegają na tym, że ktoś robi coś spektakularnie źle. Częściej problem zaczyna się od jednej, pozornie niewinnej decyzji produktowej albo technicznej, której skutków nikt wcześniej nie sprawdził.

Przykład? Bardzo proszę, poniżej omówię „klasyk”.

Case study: z analizy maili do rekrutacji

Wdrożyliśmy ogólny model AI. Korzystamy z niego np. do analizy maili, porządkowania korespondencji, tworzenia podsumowań. Wszystko działa, procedury wdrożone, RODO sprawdzone, jesteśmy podmiotem korzystającym z systemu, czyli w języku AI Act: deployerem.

Optymiści przy takim wdrożeniu i roli deployera mogą powiedzieć: „nic nie musimy”, choć wersja nieco bardziej poprawna to: mamy relatywnie ograniczony zakres obowiązków. Jesteśmy bezpieczni. Możemy działać.

Po jakimś czasie zauważamy, że dostajemy bardzo dużo maili z aplikacjami do pracy, z CV w załączniku. CV jest tak dużo, że nasz dział HR nie jest w stanie wszystkich sprawdzić i działa pod presją. Przecież wśród tych wszystkich aplikacji może znaleźć się kandydat perełka, którego możemy pominąć.

Skoro AI potrafi analizować maile i robić podsumowania, proces działa, procedury są wdrożone, to zespół wpada na pomysł: niech to AI selekcjonuje CV i tworzy ranking kandydatów.

System zostaje dostosowany na danych historycznych z rekrutacji. Dostaje przykłady poprzednich kandydatów, kryteria, informacje o tym, kto przechodził dalej, a kto odpadał.

Efekt?

AI selekcjonuje CV, odsiewa słabsze aplikacje, robi ranking najlepszych. Rekrutacja staje się szybsza, prostsza i „bardziej data-driven”. Miliardy godzin zaoszczędzone. Pełen sukces!

No i wtedy przychodzi prawnik maruda i na wieść o tej genialnej automatyzacji robi wielkie oczy. 😳

Dlaczego?

Bo może się okazać, że nasz wdrożony, bezpieczny, ogólny model AI właśnie stał się systemem wysokiego ryzyka. Rekrutacja to obszar wrażliwy z perspektywy AI Act, bo system może wpływać na sytuację konkretnych ludzi. Zmiana przeznaczenia albo istotne dostosowanie systemu do nowego celu może zmienić jego kwalifikację i rolę organizacji.

Wczoraj było narzędzie do porządkowania skrzynki. Dzisiaj jest element procesu rekrutacyjnego, który pomaga oceniać ludzi. To nie jest kosmetyczna różnica.

Dodatkowo, z racji tego, że zmieniliśmy pierwotne przeznaczenie wdrożonego modelu AI lub istotnie go dostosowaliśmy do nowego celu, ryzykujemy nieplanowany „level up” naszej roli z AI Act. Z roli deployera możemy ewoluować w rolę dostawcy, czyli providera systemu high-risk.

Deployer i provider, czyli dlaczego rola ma znaczenie

W dużym uproszczeniu deployer to podmiot, który korzysta z systemu AI albo stosuje go w swojej organizacji. Provider to dostawca systemu AI.

Deployer zwykle ma węższy zakres obowiązków, bo używa rozwiązania dostarczonego przez kogoś innego. Provider ma obowiązki szersze, bo odpowiada za dostarczenie systemu, jego dokumentację, zgodność i sposób wprowadzenia na rynek albo oddania do używania.

Problem zaczyna się wtedy, gdy organizacja myśli o sobie: my tylko używamy narzędzia, a w praktyce zaczyna istotnie dostosowywać system, zmieniać jego przeznaczenie albo używać go w zupełnie innym kontekście niż pierwotnie zakładany.

To jest moment, w którym proste wdrożenie może przestać być proste. Nie dlatego, że każdy eksperyment z AI automatycznie robi z firmy dostawcę systemu wysokiego ryzyka. Raczej dlatego, że granica między korzystaniem z narzędzia a tworzeniem nowego zastosowania bywa w praktyce mniej oczywista, niż wygląda na slajdzie.

Gdzie pojawia się ryzyko high-risk?

Wracając do naszego case study, system wykorzystywany w rekrutacji może wejść w obszar wysokiego ryzyka. Znaczenie ma nie tylko technologia, ale realny wpływ na ludzi.

Ranking CV, odsiewanie kandydatów albo wspieranie decyzji HR wymaga dużo poważniejszego podejścia niż zwykła analiza skrzynki mailowej. Szczególnie jeśli wynik systemu wpływa na to, kto trafi do kolejnego etapu, kto zostanie odrzucony albo jak człowiek oceni daną kandydaturę.

Dlatego organizacja powinna sprawdzić, czy nie zmieniła przeznaczenia systemu albo nie dostosowała go istotnie do nowego celu. W praktyce warto zadać proste pytanie: czy nadal używamy tego samego narzędzia w tym samym kontekście, czy zrobiliśmy z niego część procesu decyzyjnego o większej wadze?

Jeśli odpowiedź brzmi: to już inny proces, to compliance też powinien zostać oceniony od nowa.

Co może się zmienić w obowiązkach?

W praktyce mogą dojść albo istotnie urosnąć takie obszary jak:

• dokumentacja systemu,
• analiza i zarządzanie ryzykiem,
• zasady nadzoru człowieka,
• logi,
• monitoring działania,
• instrukcje użycia systemu,
• odpowiedzialność za proces i decyzje.

Jedna szybka decyzja usprawniająca proces może zmienić wcześniejsze założenia wdrożeniowe, odpowiedzialność i zakres obowiązków.

Compliance by design zamiast „compliance ogarnie się później”

Compliance powinien być częścią projektowania procesu, nie dodatkiem po wdrożeniu. Przy AI to szczególnie ważne, bo późniejsze dokładanie zgodności bywa droższe, trudniejsze i bardziej konfliktowe z tym, jak proces już działa.

W praktyce warto sprawdzać use case zanim system trafi na produkcję. Nie po to, żeby blokować biznes, tylko po to, żeby uniknąć sytuacji, w której działający proces nagle okazuje się źle zakwalifikowany prawnie.

Dobre wdrożenie AI nie polega na tym, że każda decyzja przechodzi przez długi formalny komitet. Chodzi raczej o sensowną bramkę: ktoś wie, do czego system będzie używany, jakie dane wejdą do procesu, czy system wpływa na ludzi i kto odpowiada za nadzór.

Stąd moja praktyczna rekomendacja: stosujcie zasadę compliance by design, a nie zasadę „compliance ogarnie się później”. Bo później może być już produkcja, decyzje, logi, audyt i pytanie: „kto właściwie miał to sprawdzić?”.

Rada od prawnika: pytania, które warto zadać przed wdrożeniem AI

Przed wdrożeniem AI warto zatrzymać się na chwilę i odpowiedzieć na kilka praktycznych pytań:

• Do czego dokładnie używamy systemu AI?
• W jakim procesie działa system?
• Czy system wpływa na ludzi, kandydatów, pracowników, klientów albo użytkowników?
• Czy system tylko wspiera człowieka, czy realnie selekcjonuje, ocenia albo rekomenduje decyzję?
• Czy zmieniliśmy pierwotne przeznaczenie narzędzia?
• Czy dostosowaliśmy model lub system do nowego celu?
• Kto odpowiada za proces, dane, nadzór i decyzję?
• Czy mamy dokumentację użycia, ryzyk i zasad kontroli?

Te pytania nie są hamulcem dla biznesu. Są sposobem, żeby szybciej odróżnić bezpieczny eksperyment od use case’u, który wymaga poważniejszego przygotowania.

Co warto zrobić teraz?

Na start warto:

• zinwentaryzować use case’y AI,
• przypisać role i odpowiedzialności,
• ocenić, czy use case może być high-risk,
• sprawdzić dane i podstawy przetwarzania,
• opisać nadzór człowieka,
• ustalić zasady dokumentowania i monitorowania działania.

Nie każda organizacja potrzebuje od razu rozbudowanego programu AI governance. Ale każda organizacja, która używa AI w procesach wpływających na ludzi, powinna wiedzieć, gdzie AI działa, po co działa i kto odpowiada za wynik.

Chcesz sprawdzić swój use case AI?

Jeżeli korzystasz z AI w procesach HR, sprzedaży, obsługi klienta, analizie dokumentów albo automatyzacji decyzji, warto sprawdzić, czy sposób użycia nie zmienia roli i obowiązków z AI Act.

Możemy pomóc ocenić use case, uporządkować role, ryzyka i dokumentację oraz przygotować zasady AI governance dla zespołu.

Umów bezpłatną konsultację

Tekst powstał jako rozwinięcie materiału przygotowanego po Śniadaniu Klastrowym Klastra IT.