Kiedy korzystanie z AI wymaga zgody, a kiedy nie

Większość organizacji ustawia nadzór nad AI zero-jedynkowo: zgoda na wszystko albo na nic. Oba warianty zawodzą tak samo, bo traktują jednakowo podsumowanie własnych notatek i integrację zapisującą dane do systemu księgowego. Sensowna granica przebiega gdzie indziej – tam, gdzie praca sięga czegoś, co można uszkodzić: systemu produkcyjnego, danych osobowych lub regulowanych, pracy innego zespołu. Poniżej tej granicy zgoda tylko spowalnia. Powyżej potrzebne jest krótkie zgłoszenie i decyzja w wyznaczonym terminie.

Kluczowe wnioski

• Granicę wyznacza zasięg rozwiązania, nie użyte narzędzie: zapis do systemu produkcyjnego, dostęp do danych osobowych lub regulowanych, albo udostępnienie innym zespołom.
• Zgłoszenie, które nie spełnia żadnego z tych trzech warunków, nie wymaga akceptacji – wymaganie jej wypycha pracę poza proces.
• Ścieżka bez zgód jest bezpieczna tylko wtedy, gdy kontrolę przejmują zabezpieczenia techniczne: narzędzia objęte umową korporacyjną, uprawnienia dziedziczone z kont użytkownika, rejestr wykorzystania na poziomie tenanta.
• Ścieżka z przeglądem potrzebuje terminu odpowiedzi, jednej roli decyzyjnej i ścieżki uproszczonej dla przypadków niskiego ryzyka.
• Decyzja bez daty ponownego przeglądu jest zgodą bezterminową – a rozwiązania przechodzą z jednej kategorii do drugiej bez zgłoszenia.
• Rozbieżność między liczbą pozycji w rejestrze zastosowań a liczbą aktywnych użytkowników z telemetrii licencji to najprostszy test tego, czy nadzór działa.

Dlaczego jeden proces dla wszystkiego zawsze zawodzi

Organizacje zwykle projektują nadzór nad AI jako pojedynczą ścieżkę: każdy pomysł trafia do tego samego formularza, tej samej komisji i tego samego czasu oczekiwania. Wynika to z ostrożności, nie z zaniedbania – skoro nie wiadomo, które zastosowania są ryzykowne, bezpieczniej wydaje się sprawdzić wszystkie.

Skutek jest odwrotny do zamierzonego. Osoba, która chce przetestować prompt do podsumowania własnych notatek, staje w tej samej kolejce co zespół podłączający model do systemu księgowego. Pierwsza z nich po dwóch takich doświadczeniach przestaje zgłaszać cokolwiek i pracuje dalej poza procesem. Druga czeka tak długo, że traci uzasadnienie biznesowe.

W rezultacie organizacja otrzymuje najgorszy możliwy układ: formalny proces, który nie obejmuje większości rzeczywistego użycia AI, oraz rosnący obszar pracy prowadzonej poza nim. Nadzór, o którym raportuje się zarządowi, opisuje wtedy wyłącznie te przypadki, które i tak były bezpieczne.

Rozbieżność da się sprawdzić w kilka minut. Wystarczy zestawić liczbę pozycji w rejestrze zastosowań z liczbą aktywnych użytkowników wynikającą z telemetrii licencji korporacyjnych. Im większa różnica między tymi dwiema wartościami, tym mniejsza część rzeczywistego użycia AI mieści się w procesie – i jest to najprostszy dostępny test tego, czy nadzór w ogóle działa.

Gdzie dokładnie przebiega granica

Pytanie, które sortuje zgłoszenia, brzmi: czy to rozwiązanie sięga czegoś, co można uszkodzić? Trzy warunki wyznaczają odpowiedź.

Pierwszy to zapis do systemu produkcyjnego. Narzędzie, które tylko czyta i przedstawia wynik człowiekowi, ma inny profil ryzyka niż narzędzie, które samo tworzy rekord w ERP, zmienia status w CRM albo wysyła wiadomość na zewnątrz organizacji.

Drugi to dane osobowe lub regulowane. Chodzi o rzeczywisty zakres przetwarzania, a nie o deklarację: prompt, do którego wkleja się fragment umowy z danymi kontrahenta, dotyka danych osobowych niezależnie od tego, jak został nazwany.

Najwięcej sporów budzą narzędzia, które dane osobowe tylko czytają i niczego nie zapisują. Reguła kieruje je na ścieżkę z przeglądem i zgłaszającemu wydaje się to przesadą – a to właśnie te zgłoszenia najczęściej wracają z pytaniami.

Trzeci to zasięg. Skrypt, z którego korzysta jedna osoba i który przestaje działać bez konsekwencji dla kogokolwiek innego, jest narzędziem prywatnym. To samo rozwiązanie udostępnione dwudziestu osobom staje się infrastrukturą – i od tego momentu ktoś musi je utrzymywać, dokumentować i wycofać, kiedy przestanie być potrzebne.

Spełnienie któregokolwiek z trzech warunków kieruje zgłoszenie na ścieżkę z przeglądem. Brak wszystkich trzech oznacza, że zgoda nie jest wymagana.

Przypadki niejednoznaczne należy z góry przypisać do ścieżki z przeglądem, a nie zostawiać zgłaszającemu do oceny. Osoba budująca narzędzie rzadko ma pełny obraz tego, gdzie kończą się jej uprawnienia, i pytanie „czy to dotyka danych regulowanych?” jest dla niej pytaniem o wiedzę, której nie posiada. Wątpliwe zgłoszenie skierowane na wolniejszą ścieżkę opóźnia pracę o dwa dni. To samo zgłoszenie przepuszczone bez oceny kończy się incydentem, którego nikt nie przewidział.

Co musi zabezpieczać ścieżka bez zgód

Ścieżka bez akceptacji nie jest zwolnieniem z zasad. Jest przeniesieniem kontroli z procesu decyzyjnego na zabezpieczenia techniczne, które działają zawsze i nie wymagają niczyjej uwagi.

Praktyczny zestaw jest krótki. Dostęp wyłącznie przez narzędzia objęte umową korporacyjną, w której dostawca nie trenuje na treściach klienta – narzędzie spoza tej listy nie jest dostępne z urządzeń służbowych. Uprawnienia odziedziczone z kont użytkownika, bez osobnych kluczy technicznych o szerszym zakresie. Rejestr wykorzystania na poziomie tenanta, pozwalający odtworzyć, kto i z czego korzystał, bez czytania treści.

Przy takim zestawie granica jest egzekwowana przez konfigurację, a nie przez czyjąś pamięć. To jedyny sposób, żeby ścieżka bez zgód była naprawdę bezpieczna, a nie tylko szybka.

Warto przy tym wprost nazwać, czego ten zestaw nie obejmuje. Nie chroni przed błędnym wynikiem przyjętym bez weryfikacji ani przed decyzją podjętą na podstawie odpowiedzi modelu, której nikt nie sprawdził. Odpowiedzią na te ryzyka nie jest kolejna zgoda, lecz zasada, że rezultat pracy narzędzia pozostaje odpowiedzialnością osoby, która go używa – i że w materiałach przekazywanych dalej wskazuje się, co powstało z udziałem modelu.

Czego wymaga ścieżka z przeglądem

Druga ścieżka bywa projektowana jako komisja bez terminu, co w praktyce oznacza jej brak. Żeby działała, potrzebuje trzech rzeczy: określonego terminu odpowiedzi, wyznaczonej osoby decyzyjnej i wyraźnie oznaczonej ścieżki uproszczonej dla przypadków niskiego ryzyka.

Termin jest najważniejszy. Zgłoszenie, na które odpowiedź przychodzi w ciągu dwóch dni roboczych, wraca do procesu; zgłoszenie oczekujące trzeci tydzień uczy całą organizację, że proces należy omijać. W programie prowadzonym dla globalnego producenta FMCG, obejmującym 300 licencji od zarządu po operacje, zbudowaliśmy proces zgłaszania i klasyfikacji ryzyka odwzorowany na AI Act, z wyznaczoną ścieżką uproszczoną i terminem odpowiedzi 48 godzin. Termin był tam warunkiem wiarygodności całej reszty.

Dwa dni robocze to punkt wyjścia, nie dogmat. W organizacji, w której zgodność ocenia jedna osoba, realny termin trzeba ustalić inaczej – ale ustalić trzeba, bo brak terminu jest brakiem procesu.

Decyzja musi też należeć do konkretnej roli, a nie do gremium. Proces kierujący każdą sprawę do działu prawnego nie jest nadzorem, tylko kolejką – dział prawny ocenia zgodność, ale nie ma podstaw do rozstrzygania, czy dane rozwiązanie ma sens operacyjny.

Sama decyzja powinna zawierać cztery elementy: zakres dopuszczonego zastosowania, wskazanie osoby odpowiedzialnej za utrzymanie, warunki, przy których rozwiązanie wymaga ponownej oceny, oraz datę przeglądu. Decyzja bez daty przeglądu jest zgodą bezterminową, a rozwiązanie zmienia się szybciej niż dokumentacja.

Najczęstszy błąd przy wyznaczaniu granicy

Granicę wyznacza się najczęściej według narzędzia, a nie według zasięgu. Powstają wtedy listy rozwiązań dozwolonych i zakazanych, aktualizowane po każdej premierze na rynku.

Ten podział nie działa, ponieważ to samo narzędzie obsługuje oba rodzaje pracy. W jednym oknie powstaje podsumowanie własnych notatek, w drugim – integracja zapisująca dane do systemu produkcyjnego. Klasyfikacja przypisana do narzędzia musi więc być albo tak restrykcyjna, że blokuje pracę nieszkodliwą, albo tak liberalna, że przepuszcza wdrożenie wymagające oceny.

Klasyfikacja przypisana do zasięgu jest odporna na zmianę rynku. Nowy model czy nowa platforma nie zmieniają odpowiedzi na pytanie, czy dane rozwiązanie zapisuje do systemu produkcyjnego, dotyka danych regulowanych albo staje się wspólną infrastrukturą – a to jedyne pytania, które mają znaczenie dla ryzyka.

Jak wygląda wdrożenie tego podziału

Podział na dwie ścieżki jest prosty do opisania i trudny do utrzymania, ponieważ rozwiązania przechodzą z jednej kategorii do drugiej. Narzędzie zbudowane przez jedną osobę do własnego użytku po kilku miesiącach bywa używane przez cały zespół – i w tym momencie przestaje być pracą prywatną, choć nikt tego nie zgłosił.

Z tego powodu granica wymaga okresowego przeglądu, a nie jednorazowej klasyfikacji. W modelu operacyjnym, który zaprojektowaliśmy dla pionu finansowego globalnej platformy dostaw obejmującego kilkanaście zespołów, punktem wyjścia była sieć osób odpowiedzialnych w każdym zespole oraz mechanizm zgłoszeń z odpowiedzią na każdy pomysł w ciągu tygodnia. Sieć istniała nie po to, by kontrolować, lecz po to, by ktoś w ogóle wiedział, co powstaje – organizacja nie miała wcześniej jak odróżnić nieszkodliwego skryptu jednej osoby od narzędzia zapisującego dane do SAP.

Warto też przewidzieć przypadek odwrotny. Rozwiązanie, które nie jest już używane, powinno zostać wycofane i odłączone od danych. Utrzymywanie nieużywanej integracji z dostępem do systemu produkcyjnego jest ryzykiem bez żadnej korzyści.

Wyznaczenie granicy nie wymaga narzędzia ani platformy. Wymaga zapisania trzech warunków, wskazania roli podejmującej decyzję, ustalenia terminu odpowiedzi i sprawdzenia, czy zabezpieczenia techniczne rzeczywiście obejmują ścieżkę bez zgód.

Krótka zasada, którą wszyscy w organizacji znają, działa lepiej niż obszerny dokument, do którego nikt nie zagląda. Koszt pojawia się tam, gdzie zasady nie ma i każdą sprawę trzeba rozstrzygać od nowa.

FAQ

Czy ścieżka bez zgód nie jest po prostu brakiem nadzoru?

Nie, o ile kontrola została przeniesiona na warstwę techniczną. Nadzorem jest tam konfiguracja: dostęp wyłącznie do narzędzi objętych umową korporacyjną, uprawnienia dziedziczone z konta użytkownika i rejestr wykorzystania. Różnica polega na tym, że te zabezpieczenia działają zawsze, a zgoda działa tylko wtedy, gdy ktoś o nią wystąpi.

Kto powinien podejmować decyzję na ścieżce z przeglądem?

Jedna wyznaczona rola, a nie gremium. Dział prawny ocenia zgodność, ale nie ma podstaw do rozstrzygania, czy rozwiązanie ma sens operacyjny. Decyzja należy do osoby odpowiadającej za dany obszar procesu, z opinią prawną jako jednym z wejść.

Co zrobić, gdy nie wiadomo, po której stronie granicy leży zgłoszenie?

Skierować je na ścieżkę z przeglądem. Osoba budująca narzędzie rzadko ma pełny obraz swoich uprawnień, więc pytanie o zakres danych jest dla niej pytaniem o wiedzę, której nie posiada. Dwa dni oczekiwania kosztują mniej niż incydent.

Jak często weryfikować przypisanie rozwiązania do ścieżki?

Przy każdej zmianie zasięgu i dodatkowo w ustalonym cyklu. Narzędzie zbudowane do własnego użytku bywa po kilku miesiącach używane przez cały zespół i od tego momentu jest infrastrukturą, choć nikt tego nie zgłosił. Dlatego każda decyzja powinna mieć datę ponownego przeglądu.