Budowa inwentarza i rejestru AI

dlaczego rejestr jest fundamentem

AI Act jest napisany tak, jakbyś już wiedział, jakiego AI używasz. Kilka jego obowiązków odczytuje się wprost z inwentarza, który zakłada się, że posiadasz.

Artykuł 4, kompetencje AI. Obowiązujący od 2 lutego 2025 obowiązek wymaga od providerów i deployerów zapewnienia wystarczającego poziomu kompetencji AI wśród personelu, który obsługuje lub używa systemów AI. Nie da się zaplanować zakresu takiego szkolenia bez wiedzy, jakie systemy są w użyciu i co robią. Rejestr mówi ci, kto musi wiedzieć co.

Artykuł 5, zakazane praktyki. Act zakazuje konkretnego zestawu zastosowań, takich jak social scoring i niektóre techniki manipulacyjne albo biometryczne. Żeby potwierdzić, że żaden z twoich systemów się w nich nie mieści, najpierw potrzebujesz listy systemów do sprawdzenia. Przegląd zakazanych praktyk bez inwentarza za sobą to zgadywanie.

Artykuł 26(6), przechowywanie logów. Systemy wysokiego ryzyka muszą automatycznie generować logi, co jest obowiązkiem nałożonym na providera przez Artykuł 12, a deployer musi przechowywać logi, które generuje system. Żeby wiedzieć, które z twoich systemów niosą ten obowiązek, pracujesz na rejestrze, który nazywa każdy system i jego poziom ryzyka.

Artykuł 27, ocena skutków dla praw podstawowych deployera. Deployerzy niektórych systemów wysokiego ryzyka muszą ocenić wpływ na prawa podstawowe, zanim wprowadzą system do użycia. Ta ocena jest robiona osobno dla każdego systemu. Bez rejestru nie wiesz, które systemy ją wywołują.

Odłóż przepisy na bok, a argument nadal stoi. Dobre governance to klasyfikacja plus wytyczne, nie zakaz. Nie da się napisać wytycznej dla narzędzia, którego nie nazwałeś, ani sklasyfikować przepływu danych, którego nie zmapowałeś. Rejestr to miejsce, gdzie żyje nazywanie i mapowanie. Jeszcze jeden powód, żeby zrobić to dobrze wcześnie: kary są zróżnicowane poziomami. Zakazane praktyki grożą karą do 35 milionów EUR albo 7% globalnego rocznego obrotu, w zależności od tego, co wyższe. Większość pozostałych obowiązków grozi karą do 15 milionów EUR albo 3%. Rejestr to niskokosztowy sposób, żeby pokazać, że potraktowałeś te obowiązki poważnie.

pola rejestru, zdefiniowane

Rejestr jest tak użyteczny, jak jego kolumny. Każde pole poniżej zasługuje na swoje miejsce, bo odpowiada na pytanie, które zada regulator, audytor albo ty sam w przyszłości.

Nazwa systemu. Produkt albo usługa tak, jak nazywają go ludzie. Zapisz konkretną edycję tam, gdzie ma to znaczenie, bo plan enterprise i darmowy plan tego samego produktu mogą mieć inne warunki i inne zachowanie wobec danych.

Właściciel. Wskazana osoba odpowiedzialna za ten system w twojej organizacji. Nie zespół, osoba. Kiedy system nie ma właściciela, to samo w sobie jest ustaleniem wartym zapisania.

Dostawca. Kto dostarcza system. Podmiot prawny, nie tylko marka, kiedy da się go ustalić. To ma znaczenie dla rezydencji danych i dla późniejszego pytania provider kontra deployer.

Dane, jakich dotyka. Jakie kategorie danych wpływają do systemu i z niego wypływają. Dane osobowe, kod źródłowy, dane finansowe, rekordy klientów, wewnętrzna strategia. Trzymaj to na poziomie kategorii. Precyzja w tym miejscu napędza zarówno pole podstawy prawnej, jak i decyzję o poziomie ryzyka.

Rola, jaką pełnisz. Provider albo deployer zgodnie z Act. W większości przypadków jesteś deployerem, używającym systemu, który zbudował ktoś inny.

Poziom ryzyka. Zakazane, wysokiego ryzyka, ograniczonego ryzyka albo minimalnego ryzyka. To pole, od którego zależą obowiązki z Act.

Podstawa prawna. Jeśli system przetwarza dane osobowe, podstawa prawna z RODO. Zgoda, umowa, uzasadniony interes, obowiązek prawny i tak dalej. Zostaw puste tam, gdzie nie ma danych osobowych, i zaznacz to wprost, zamiast zostawiać niejednoznaczną lukę.

Flaga przejrzystości z Artykułu 50. Tak albo nie w kwestii tego, czy system wywołuje obowiązek przejrzystości z Artykułu 50. Obejmuje to systemy, które wchodzą w interakcję z ludźmi jako chatbot, generują syntetyczne treści albo produkują deepfake'i. Tam, gdzie flaga to tak, jesteś winien ujawnienie.

Uzasadnienie klasyfikacji. Jedno albo dwa zdania wyjaśniające, dlaczego przypisałeś taki, a nie inny poziom ryzyka i rolę. To pole, które audytorzy cenią najbardziej, bo pokazuje rozumowanie, nie tylko wynik.

Data przeglądu. Kiedy ostatnio przejrzano wpis albo kiedy przypada następny przegląd. Rejestr bez datowanych przeglądów po cichu się dezaktualizuje i przestaje być łatwy do obrony.

Status. Gdzie stoi system. W użyciu, w pilotażu, wycofany, zablokowany, oczekuje na przegląd.

jak go wypełnić

Żadne pojedyncze źródło nie pokaże ci wszystkiego. Składasz obraz z kilku źródeł i akceptujesz, że część użycia AI nie zostawia żadnego śladu.

Dostawca tożsamości i lista aplikacji SSO. Zacznij od swojego dostawcy tożsamości. Lista aplikacji podłączonych przez SSO ujawnia narzędzia AI, które przeszły usankcjonowaną ścieżkę. To najczystsze źródło i naturalne pierwsze podejście.

Granty OAuth dla narzędzi AI. Pobierz pełną listę grantów OAuth i przefiltruj pod kątem aplikacji związanych z AI. To łapie connectory, które otrzymały uprawnienia do czytania firmowej poczty albo dokumentów, w tym te, których IT nigdy nie wdrożyło. W grantach OAuth kryje się zaskakująco duża część realnego dostępu AI.

Konsole administracyjne SaaS. Wiele produktów SaaS, za które już płacisz, dodało funkcje AI. Konsola administracyjna każdej większej platformy mówi, czy funkcje AI są włączone i do jakich danych sięgają. Narzędzie, które rok temu sklasyfikowałeś jako nie-AI, może teraz mieć funkcję AI.

Krótka ankieta wśród pracowników. Zapytaj ludzi wprost, jakich narzędzi AI używają do pracy, łącznie z kontami prywatnymi. Utrzymaj ją krótką i spraw, żeby odpowiadanie szczerze było bezpieczne. Ankieta dociera do użycia, które nie zostawia śladu w katalogu.

Dane z wydatków i kart. Subskrypcje opłacone prywatną kartą i rozliczone w kosztach, albo kartą zespołu poza procesem zakupowym, pojawiają się w danych finansowych, zanim pojawią się gdziekolwiek w IT. Przeszukanie pozycji wydatków pod kątem dostawców AI często ujawnia narzędzia, o których żaden katalog nie wie.

A oto uczciwa część. Część użycia AI nie pojawi się w żadnym z tych źródeł. Prywatne konto założone na domowym urządzeniu, używane do pracy, opłacone prywatnie i nigdy nie rozliczone, nie zostawia śladu, który mógłbyś pobrać. Dlatego ankieta ma znaczenie i dlatego rejestr jest żywym dokumentem. Nie osiągniesz idealnego pokrycia. Dążysz do aktualnego, łatwego do obrony pokrycia, które poprawia się z każdym cyklem przeglądu.

jak sklasyfikować każdy wpis

Dwa pola potrzebują metody za sobą: poziom ryzyka i rolę. Oba mają pułapki, które łapią tych, którzy się spieszą.

ścieżka decyzyjna dla poziomu ryzyka

Przejdź przez nie po kolei i zatrzymaj się na pierwszym, który pasuje.

1. Czy to zakazana praktyka zgodnie z Artykułem 5? Social scoring, niektóre techniki manipulacyjne, niektóre zastosowania biometryczne i reszta listy z Artykułu 5. Jeśli tak, poziom ryzyka to zakazane, a zastosowanie się kończy. To rzadkie w zwykłych narzędziach biznesowych, ale sprawdzenie jest obowiązkowe.
2. Czy to wysokie ryzyko zgodnie z Załącznikiem III? Załącznik III wymienia obszary zastosowań wysokiego ryzyka, w tym AI używane w decyzjach zatrudnieniowych, dostępie do usług podstawowych, ocenie zdolności kredytowej i niektórych funkcjach krytycznych. Jeśli system jest używany do jednego z tych celów, wskazuje to na wysokie ryzyko. Następnie zastosuj wyłączenie z Artykułu 6(3): system, który w innym wypadku byłby wysokiego ryzyka, nie jest wysokiego ryzyka, jeśli wykonuje wąskie zadanie proceduralne, poprawia wynik wcześniejszej aktywności człowieka albo wykonuje podobną ograniczoną pracę, która materialnie nie wpływa na wynik. Zastrzeżenie ma znaczenie: jeśli system wykonuje profilowanie osób fizycznych, wyłączenie nie ma zastosowania i system pozostaje wysokiego ryzyka.
3. Czy wywołuje przejrzystość ograniczonego ryzyka zgodnie z Artykułem 50? Chatbot, z którym rozmawiają ludzie, system generujący syntetyczne audio, obraz, wideo albo tekst, albo taki, który produkuje deepfake'i. Jeśli tak, i nie jest to wysokie ryzyko, poziom to ograniczone ryzyko i jesteś winien ujawnienie z Artykułu 50.
4. W przeciwnym razie, minimalne ryzyko. Większość ogólnych narzędzi produktywnościowych ląduje tutaj. Minimalne ryzyko nie niesie żadnych obowiązkowych obowiązków z Act, choć nadal zapisujesz system i trzymasz się własnego governance.

ścieżka decyzyjna dla roli

Dla każdego systemu zdecyduj, czy jesteś providerem, czy deployerem. Jesteś deployerem, gdy używasz systemu AI, który zbudował ktoś inny i wprowadził na rynek. To typowy przypadek. Jesteś providerem, gdy rozwijasz system AI, albo zlecasz jego rozwój, i wprowadzasz go na rynek albo oddajesz do użytku pod własną nazwą. Budowanie własnego modelu albo niestandardowej funkcji AI w produkcie, który wysyłasz klientom, stawia cię w tej roli.

Pułapka tkwi w Artykule 25. Deployer może stać się providerem systemu wysokiego ryzyka, z cięższymi obowiązkami providera, jakie za tym idą, w konkretnych sytuacjach. Umieszczenie własnej nazwy albo znaku towarowego na systemie wysokiego ryzyka już obecnym na rynku, wprowadzenie w nim istotnej modyfikacji albo zmiana przeznaczenia systemu niebędącego wysokiego ryzyka tak, że staje się wysokiego ryzyka, każde z tych działań może cię przeklasyfikować. Jeśli w istotny sposób dostosowujesz, rebrandujesz albo zmieniasz przeznaczenie systemu AI, sprawdź ponownie swoją rolę, zamiast zakładać, że zostałeś deployerem.

gotowy szablon do użycia

Skopiuj poniższą tabelę do własnego dokumentu, arkusza albo narzędzia do prowadzenia rejestru. Przykładowe wiersze są wyłącznie poglądowe, zastąp je własnymi systemami i uzasadnieniem.

• Ogólny asystent do pisania (plan enterprise) · Właściciel: Head of IT · Dostawca: Dostawca A · Dane, jakich dotyka: Dokumenty wewnętrzne, brak danych osobowych zgodnie z polityką · Rola: Deployer · Poziom ryzyka: Minimalne · Podstawa prawna: Nie dotyczy, brak danych osobowych · Flaga Art. 50: Nie · Uzasadnienie klasyfikacji: Ogólne narzędzie produktywnościowe, nie jest zastosowaniem z Załącznika III, brak wyzwalacza przejrzystości · Data przeglądu: 2026-06-01 · Status: W użyciu
• Chatbot obsługi klienta na stronie · Właściciel: Support Lead · Dostawca: Dostawca B · Dane, jakich dotyka: Wiadomości klientów, dane kontaktowe · Rola: Deployer · Poziom ryzyka: Ograniczone · Podstawa prawna: Uzasadniony interes · Flaga Art. 50: Tak · Uzasadnienie klasyfikacji: Wchodzi w interakcję z ludźmi jako chatbot, wymagane ujawnienie z Art. 50, nie jest zastosowaniem z Załącznika III · Data przeglądu: 2026-06-01 · Status: W użyciu
• Narzędzie do przesiewu CV w rekrutacji · Właściciel: Head of HR · Dostawca: Dostawca C · Dane, jakich dotyka: Dane osobowe kandydatów, CV · Rola: Deployer · Poziom ryzyka: Wysokie ryzyko · Podstawa prawna: Zgoda / uzasadniony interes, DPIA w dokumentacji · Flaga Art. 50: Nie · Uzasadnienie klasyfikacji: Zastosowanie zatrudnieniowe z Załącznika III, profilowanie kandydatów, więc wyłączenie z Art. 6(3) nie ma zastosowania, wymagana FRIA na mocy Art. 27 · Data przeglądu: 2026-06-01 · Status: Oczekuje na przegląd
• Wewnętrzny model prognozowania popytu · Właściciel: Data Team Lead · Dostawca: Zbudowany wewnętrznie · Dane, jakich dotyka: Zagregowane dane sprzedażowe, brak danych osobowych · Rola: Provider · Poziom ryzyka: Minimalne · Podstawa prawna: Nie dotyczy, brak danych osobowych · Flaga Art. 50: Nie · Uzasadnienie klasyfikacji: Zbudowany i używany wewnętrznie, nie jest zastosowaniem z Załącznika III, rola providera bo rozwinięty wewnętrznie · Data przeglądu: 2026-06-01 · Status: W pilotażu

Klucz pole po polu: nazwa systemu plus edycja tam, gdzie zmienia warunki; właściciel jako wskazana odpowiedzialna osoba, nie zespół; dostawca jako podmiot prawny tam, gdzie da się go ustalić; dane, jakich dotyka, na poziomie kategorii, co napędza podstawę prawną i poziom ryzyka; rola sprawdzana ponownie po każdym rebrandingu, modyfikacji albo zmianie przeznaczenia; poziom ryzyka ze ścieżki decyzyjnej; podstawa prawna z jawnym „nie dotyczy" tam, gdzie jej nie ma; flaga Art. 50 na tak tam, gdzie system jest chatbotem, generuje syntetyczne treści albo produkuje deepfake'i; uzasadnienie klasyfikacji w jednym albo dwóch zdaniach; data przeglądu jako ostatni przegląd albo następny termin; i status jako w użyciu, w pilotażu, wycofany, zablokowany albo oczekuje na przegląd.

utrzymanie

Rejestr to żywy dokument. Trzy nawyki utrzymują go w zgodzie ze stanem faktycznym.

Cykl przeglądów. Ustal stały harmonogram powrotu do każdego wpisu. Kwartalny pasuje większości organizacji, bo funkcje AI i warunki dostawców zmieniają się szybko. Przegląd roczny to minimum. Przy każdym przeglądzie potwierdzasz poziom ryzyka, rolę, dane i status, i aktualizujesz datę przeglądu.

Ścieżka zgłaszania nowych narzędzi. Zdecyduj, jak nowe narzędzie AI trafia do rejestru, zanim wejdzie do szerokiego użycia. Powiąż to z istniejącym procesem weryfikacji narzędzi AI, tak żeby narzędzie było klasyfikowane w momencie zatwierdzenia, nie miesiące później. Wskazany właściciel zgłoszeń i docelowy czas realizacji utrzymują ścieżkę użyteczną.

Ponowna klasyfikacja przy zmianie systemu. Narzędzie, które zyskuje funkcję AI, poszerza dane, jakich dotyka, albo zmienia swój cel, może zmienić poziom ryzyka albo przesunąć cię z deployera na providera. Traktuj istotną zmianę jako wyzwalacz do ponownego przejścia przez ścieżki decyzyjne poziomu ryzyka i roli dla tego wpisu. Pole uzasadnienia klasyfikacji to miejsce, gdzie zapisujesz, co się zmieniło i dlaczego wartość się przesunęła.