Compliance officer nie przegrywa przy pierwszym pytaniu o AI. Przegrywa przy drugim: gdy okazuje się, że odpowiedź na pierwsze pytanie była niepełna. "Jakie systemy AI wykorzystuje wasza organizacja" można odpowiedzieć listą z portfolio IT. Pytanie, które przychodzi potem — "czy to jest pełna lista" — jest pytaniem, na którym rozbija się większość dokumentacji compliance.
Nie: jakie narzędzia AI zakupiła organizacja. Tylko: jakie systemy AI są faktycznie używane, przez kogo, do jakich decyzji, i na podstawie jakiej oceny ryzyka. To są cztery pytania, nie jedno. Pierwsze to lista zakupów. Pozostałe trzy wymagają, aby ludzie opowiedzieli, co robią, w tym co robią bez formalnej zgody. Compliance officer, który ma tylko listę zakupów, ma fałszywe poczucie pokrycia — a to jest bardziej ryzykowne niż brak pokrycia, ponieważ jest raportowane jako kompletne.
Pracownicy, którzy używają narzędzia językowego lub analitycznego bez zakupu przez IT, nie pozostawiają po tym żadnego śladu w rejestrze aktywów. Pozostawiają natomiast ślad w tym, co produkują: raportach, komunikacji z klientami, opiniach. Rozdźwięk między tym, co jest zarejestrowane, a tym, co jest używane, zwykle nie jest umyślnym naruszeniem. Jest wynikiem tego, że organizacja szybciej znajduje narzędzie, niż przechodzi przez proces zatwierdzenia. Compliance nie może zamknąć tej luki poprzez ostrzejszy zakaz — to tylko przesunie użycie dalej poza pole widzenia. Lukę zamyka się, pytając bez sankcji za odpowiedź. Kto boi się wpisu do swojego dossier, nie mówi, czego używa; mówi to, co myśli, że chcecie usłyszeć.
Menedżer ryzyka chce wiedzieć, jak duża jest ekspozycja. Compliance officer chce tego samego, plus coś dodatkowego: czy mogę wykazać, że przestrzegaliśmy procesu, nawet jeśli wynik później okaże się dyskusyjny. To inny rodzaj dowodu. Nie chodzi tylko o klasyfikację systemu, lecz o ślad: kto to oceniał, w jakim momencie, na podstawie jakich informacji, i czy ta ocena została powtórzona, gdy system się zmienił. Systemy AI są aktualizowane bez ogłoszenia; klasyfikacja z pół roku temu mówi niewiele o dzisiejszym systemie. Compliance musi więc pokazać nie tylko wynik, ale proces, który wciąż działa.
"Mamy politykę AI" nie jest odpowiedzią na pytanie, czy ta polityka coś pokrywa. Dokument polityki, który nigdy nie został zweryfikowany względem tego, co jest faktycznie używane, jest deklaracją intencji, a nie deklaracją stanu rzeczy. Czego potrzebuje compliance officer, to inwentaryzacja, która wpisuje się w istniejące kategorie ryzyka — ten sam podział, który już jest używany dla innych ryzyk operacyjnych — tak aby AI nie stało się osobnym, egzotycznym tematem obok reszty ramowego systemu ryzyka, lecz jego częścią.
Compliance officer rzadko opracowuje to samodzielnie. Pytanie, jakie systemy uznaje się za wysokiego ryzyka i jaki dowód jest do tego potrzebny, dotyka tego, co General Counsel powinien wiedzieć o ryzyku AI z perspektywy odpowiedzialności i zobowiązań umownych. Pytanie, czy organizacja technicznie może śledzić, jakie systemy działają, leży po stronie tego, co CIO powinien wiedzieć o ryzyku AI. A pytanie, czy ten temat trafia do zarządu, zanim się eskaluje, należy do tego, co członek zarządu powinien wiedzieć o ryzyku AI. Compliance jest często stroną, która musi połączyć te trzy linie, nie będąc właścicielem samej technologii czy umowy.
Treść regulacji — jakie konkretnie obowiązki obowiązują, według kategorii ryzyka, z jakimi terminami — jest opisana gdzie indziej i zmienia się. Ta strona opisuje mechanizm: jak wie Pan/Pani, co działa, jak to Pan/Pani klasyfikuje, i jak wykazuje Pan/Pani, że proces został przestrzegany. Compliance officer, który szuka aktualnego tekstu prawnego, nie znajdzie go tutaj.
Ile "shadow AI" ma organizacja, zależy od sektora, kultury oraz od tego, jak rygorystycznie wykonywano wcześniejsze zakazy. Ostrzejszy zakaz często koreluje z większym skrytym użyciem, nie z mniejszym. Ten wzorzec nie jest wszędzie taki sam: w budownictwie punkt ciężkości leży przy kalkulacji projektów i planowaniu, podczas gdy w branży instalacyjnej częściej dotyczy diagnostyki serwisowej i analizy usterek. Inwentaryzacja musi więc odbywać się per organizacja; średnia krajowa mówi niewiele o Pana/Pani własnej ekspozycji.
Responsible AI Scan mapuje to, co jest faktycznie używane, klasyfikuje to według roli i poziomu ryzyka, i dostarcza zestaw governance, który wpisuje się w istniejącą strukturę ryzyka — bez wybiegania naprzód względem tego, co już gdzie indziej zostało ustalone. Ten skan jest w budowie. Kto jest tym zainteresowany, może zapisać się na listę oczekujących; nie oferuje się niczego, co nie jest jeszcze gotowe.
Gdy już wie się, jakie systemy AI działają, często pojawia się pytanie następcze: co to znaczy dla obsady personalnej i podziału zadań. To inne wyliczenie niż klasyfikacja ryzyka, i tym zajmuje się FTE TO AI za pomocą skanu pracy, który dla każdego zadania oblicza, jaką część pracy można przekazać AI.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.