Budowa inwentarza systemów AI przed 2 sierpnia 2026 r.: praktyczny przewodnik dla MŚP w UE

W skrócie

Większość obowiązków merytorycznych aktu o sztucznej inteligencji zacznie być stosowana od 2 sierpnia 2026 r. — obowiązki wobec systemów wysokiego ryzyka z załącznika III opisane w art. 8–22, obowiązki podmiotu stosującego z art. 26, wymogi przejrzystości z art. 50 oraz rejestracja w bazie UE na podstawie art. 49. Żadnego z tych obowiązków nie da się wykonać bez kompletnego, aktualnego i przypisanego do konkretnych osób inwentarza wszystkich systemów AI w organizacji. Zakazy z art. 5 są stosowane już od 2 lutego 2025 r., a obowiązki dotyczące modeli GPAI od 2 sierpnia 2025 r. (art. 113), tak więc inwentarz przygotowywany dziś musi już teraz uwzględniać przegląd praktyk zakazanych, zapisy o przekazywaniu informacji od dostawców GPAI oraz bieżącą klasyfikację. Dobra wiadomość dla MŚP, które zwykle pracują w warunkach ograniczonych zasobów: prawie na pewno prowadzą Państwo już analogiczne rejestry — rejestr czynności przetwarzania na podstawie art. 30 RODO, rejestr zasobów wymagany przez NIS2 oraz inwentarz aktywów z załącznika A.5.9 normy ISO/IEC 27001. Inwentarz AI najlepiej budować jako rozszerzenie tych źródeł, a nie jako odrębny artefakt. Niniejszy przewodnik podaje schemat inwentarza, mapę ponownego wykorzystania, trzy przykłady z MŚP, najczęstsze pułapki oraz plan wdrożenia w 60 dni, dzięki któremu zdążą Państwo przed terminem.

Dlaczego inwentarz AI jest kluczowy przed 2 sierpnia 2026 r.

Akt o sztucznej inteligencji nie wprowadza jednego, wymienionego z nazwy obowiązku „prowadzenia inwentarza”. Wprowadza natomiast kilkanaście obowiązków, których IOD ani specjalista ds. zgodności nie wykona, jeśli nie wie, jakie systemy AI faktycznie pracują w organizacji, co robią, kto za nie odpowiada i do którego poziomu ryzyka się kwalifikują. Art. 9 o zarządzaniu ryzykiem zakłada listę systemów, na której można tę analizę przeprowadzić. Art. 11 o dokumentacji technicznej zakłada, że objęte zakresem systemy zostały już zidentyfikowane. Obowiązki podmiotu stosującego z art. 26 — nadzór ludzki, monitorowanie, prowadzenie rejestrów zdarzeń, informowanie pracowników objętych systemem — stosuje się do każdego systemu z osobna, czego po prostu nie da się zrobić bez rejestru w układzie „jeden system, jeden wpis”. Rejestracja w bazie UE z art. 49 to zgłoszenie systemowe. Bez inwentarza nie da się ułożyć kolejności prac, ustalić priorytetów ani niczego udowodnić.

Sankcje są tak skalibrowane, by luka kosztowała poważnie. Art. 99 przewiduje kary administracyjne w wysokości 35 mln EUR lub 7 % całkowitego światowego rocznego obrotu za naruszenie zakazów (art. 99 ust. 3), 15 mln EUR lub 3 % za niezgodność z obowiązkami dotyczącymi systemów wysokiego ryzyka (art. 99 ust. 4) oraz 7,5 mln EUR lub 1 % za przekazanie organom notyfikującym i właściwym organom nadzoru informacji nieprawidłowych, niekompletnych lub wprowadzających w błąd (art. 99 ust. 5). MŚP korzystają z częściowego złagodzenia na podstawie art. 99 ust. 6 — kara może zostać ustalona w niższej wysokości spośród kwoty bezwzględnej i wartości procentowej, a nie wyższej — lecz to złagodzenie nie usuwa pułapu i w ogóle nie obejmuje najgroźniejszego scenariusza: sytuacji, w której organizacja w trakcie postępowania kontrolnego okazuje się nie wiedzieć, jakie systemy AI u siebie eksploatuje. Niekompletny inwentarz jest właśnie warunkiem wstępnym sankcji z trzeciej kategorii — bo każda odpowiedź dawana organowi siłą rzeczy ma charakter szacunkowy.

Druga, mniej oczywista oś ryzyka to dostęp do rynku. Art. 79 pozwala organowi nadzoru rynku nakazać działania korygujące wobec niezgodnych systemów wysokiego ryzyka, włącznie z wycofaniem ich z rynku UE. Dla MŚP w modelu B2B SaaS, których kontrakty enterprise zawierają zapewnienia dotyczące zgodności — i których klienci od drugiej połowy 2025 r. zaczęli pytać o zgodność z RIA w procesach zakupowych — niezdolność do przedstawienia inwentarza systemowego na żądanie staje się ryzykiem handlowym znacznie wcześniej niż regulacyjnym. Pierwsi pytający to zwykle przedsiębiorstwa niemieckie, francuskie i holenderskie, które już prowadzą dojrzałe procesy badania dostawców pod kątem RODO. W końcówce 2026 r. nie przyjmą odpowiedzi „jeszcze mapujemy”.

Czym jest „system AI” w rozumieniu art. 3 ust. 1

Art. 3 ust. 1 definiuje system AI jako system maszynowy zaprojektowany do działania z różnym poziomem autonomii po wdrożeniu, mogący wykazywać zdolność adaptacyjną po wdrożeniu i który — dla wyraźnych lub dorozumianych celów — wnioskuje na podstawie otrzymanych danych wejściowych, w jaki sposób generować wyniki takie jak prognozy, treści, zalecenia lub decyzje, mogące wpływać na środowiska fizyczne lub wirtualne. Definicja jest celowo zharmonizowana z definicją OECD zaktualizowaną w 2023 r. i celowo szeroka. Każda organizacja, która przeczyta ją uważnie, ma tę samą pierwszą reakcję: zakres jest szerszy, niż się wydawało.

Wynikają z tego trzy konsekwencje dla zakresu inwentarza. Po pierwsze — „uczenie maszynowe” nie jest warunkiem koniecznym. System ekspertowy oparty na regułach, który wnioskuje na podstawie bazy wiedzy, mieści się w definicji, choć większość inżynierów nie nazwałaby go AI. Motyw 12 wyłącza z zakresu wybrane klasyczne metody statystyczne i optymalizacyjne pozbawione elementu wnioskowania, ale wyłączenie to jest wąskie i sporne na granicach. W razie wątpliwości lepiej system wpisać do inwentarza, a uzasadnić, dlaczego nie wymaga klasyfikacji do żadnego z poziomów ryzyka.

Po drugie — „różny poziom autonomii” oznacza, że granica między AI a klasycznym oprogramowaniem nie biegnie wzdłuż linii „człowiek w pętli”. System, który wymaga obowiązkowej akceptacji człowieka dla każdego wyniku, nadal pozostaje systemem AI, jeśli te wyniki wnioskuje. Nadzór ludzki z art. 14 jest wówczas elementem projektu systemu AI, a nie wyjściem z zakresu RIA. Narzędzia do przesiewania CV, które prezentują rekruterowi rankingowaną listę krótką do wyboru, są systemami AI nawet wtedy, gdy formalnej decyzji o zatrudnieniu dokonuje rekruter.

Po trzecie — „wyniki mogące wpływać na środowiska fizyczne lub wirtualne” wciągają do zakresu długą listę oprogramowania operacyjnego, którego organizacje rzadko etykietują jako AI: silniki dynamicznego ustalania cen, modele scoringu antyfraudowego, predyktory rezygnacji klientów, klasyfikatory moderowania treści, systemy rekomendacji, automatyczne kierowanie korespondencji, prognozowanie popytu, modele konserwacji predykcyjnej. Większość z nich w klasyfikacji okaże się systemami minimalnego ryzyka, ale i tak należą do inwentarza. Sensem rejestru jest udowodnienie, że klasyfikacja została przeprowadzona, a nie wyłącznie wymienienie systemów, które wyszły jako wysokiego ryzyka.

Mapowanie inwentarza na poziomy ryzyka RIA

Każdy wpis w inwentarzu nosi etykietę poziomu ryzyka, a od tej etykiety zależy reszta dokumentacji. Pięć kategorii — niedopuszczalne, wysokiego ryzyka, ograniczonego ryzyka, minimalnego ryzyka oraz nakładka GPAI — mieści się w jednym rejestrze, a jeden produkt może wygenerować kilka wpisów, jeżeli zawiera kilka rozdzielnych przypadków użycia AI. Wpisy traktujemy jako jednostki pracy zgodnościowej, a nie jako katalog dostawców.

Systemy o ryzyku niedopuszczalnym z art. 5 — osiem zakazanych rodzin obejmujących techniki manipulacyjne, wykorzystywanie podatności, scoring społeczny, predyktywne profilowanie wyłącznie pod kątem ścigania, niezogniskowane pobieranie wizerunków twarzy, rozpoznawanie emocji w miejscu pracy i edukacji, kategoryzację biometryczną według cech wrażliwych oraz zdalną identyfikację biometryczną w czasie rzeczywistym w przestrzeni publicznej do celów ścigania — nigdy nie powinny pojawić się jako aktywny wpis w inwentarzu. Jeżeli istniejący system lub planowany zakup spełnia którykolwiek z zakazów, wpis służy wyłącznie udokumentowaniu decyzji o zaprzestaniu używania. Zakazy są stosowane od 2 lutego 2025 r., więc nie jest to obowiązek przyszły.

Wpisy wysokiego ryzyka — kategorie z załącznika III oraz elementy bezpieczeństwa produktów z załącznika I w rozumieniu art. 6 ust. 1 — niosą najpełniejszy zestaw pól. Trzynastopunktowy zestaw obowiązków z art. 9 do art. 49 generuje wymogi dokumentacyjne, których cienki wpis w rejestrze nie udźwignie. Dla wpisów wysokiego ryzyka inwentarz najlepiej traktować jako indeks wskazujący na osobny dokument techniczny prowadzony zgodnie z art. 11 i załącznikiem IV; sam wpis trzyma jedynie metadane, których audytor potrzebuje, by do tego dokumentu trafić. Obowiązki merytoryczne stosuje się od 2 sierpnia 2026 r. wobec systemów wysokiego ryzyka z załącznika III, a wobec nurtu produktowego z załącznika I i art. 6 ust. 1 — od 2 sierpnia 2027 r..

W obrębie załącznika III działa drugi filtr. Art. 6 ust. 3 przewiduje odstępstwo dla systemów z załącznika III, które nie stwarzają znaczącego ryzyka szkody, ponieważ wykonują wąskie zadanie proceduralne, ulepszają wynik wcześniej zakończonej działalności człowieka, wykrywają wzorce decyzyjne lub odchylenia bez zastępowania ludzkiej oceny albo wykonują zadanie przygotowawcze do oceny objętej załącznikiem III. Profilowanie osób fizycznych zawsze dyskwalifikuje to odstępstwo. Każdy wpis z załącznika III wymaga pisemnej analizy na podstawie art. 6 ust. 3: albo z konkluzją pozytywną (z konkretną podstawą i uzasadnieniem), albo negatywną — potwierdzającą, że system pozostaje w kategorii wysokiego ryzyka.

Wpisy ograniczonego ryzyka — chatboty, narzędzia generujące deepfake, treści tekstowe lub multimedialne wytworzone przez AI, systemy rozpoznawania emocji tam, gdzie nie są zakazane — niosą obowiązki przejrzystości z art. 50. Inwentarz musi rejestrować mechanizm informowania per system: lokalizację banneru w czacie, technikę znaku wodnego dla syntetycznych wyników, dziennik przeglądów redakcyjnych dla treści generowanych przez AI publikowanych w sprawach interesu publicznego, sposób oznaczania deepfake po stronie podmiotu stosującego. Obowiązki dla ograniczonego ryzyka stosuje się również od 2 sierpnia 2026 r., a — w odróżnieniu od ścieżki wysokiego ryzyka — żadne odstępstwo nie zwalnia z obowiązku: każdy chatbot wymaga oznaczenia, a inwentarz musi je udowodnić.

Wpisy minimalnego ryzyka stanowią masę rejestru. RIA nie nakłada na nie obowiązków obowiązkowych, ale inwentarz nadal musi udokumentować rozumowanie prowadzące do tej kwalifikacji — udokumentowane uzasadnienie, że system nie mieści się w załączniku III, nie wchodzi w bezpośrednią interakcję z osobami fizycznymi i nie generuje treści syntetycznych. Obowiązek znajomości AI z art. 4 stosuje się niezależnie od poziomu ryzyka, więc inwentarz powinien zarejestrować, jaki zespół pracowników obsługuje każdy system minimalnego ryzyka, i potwierdzić, że pracownicy ci są objęci programem znajomości AI.

GPAI to nakładka, a nie poziom ryzyka. Niemal każdy wpis w inwentarzu MŚP zbudowany na bazie modelu fundamentalnego — GPT-4o, Claude, Gemini, Mistral Large, Llama, Command — to wpis podmiotu stosującego w rozumieniu art. 53 ust. 1 lit. b, dziedziczący informacje przekazane przez dostawcę nadrzędnego. W inwentarzu należy przewidzieć osobne pola na tożsamość modelu nadrzędnego i jego wersję, dostawcę, odniesienie do opublikowanego streszczenia danych treningowych oraz datę ostatniego przeglądu instrukcji obsługi otrzymanej od dostawcy. Trzeba przy tym rozdzielić dwie różne reguły. Art. 25 przenosi obowiązki dostawcy systemu wysokiego ryzyka na podmiot pochodny w trzech przypadkach: gdy podmiot ten wprowadza system wysokiego ryzyka do obrotu pod własną nazwą lub znakiem towarowym, gdy istotnie modyfikuje wprowadzony już system wysokiego ryzyka albo gdy zmienia przewidziany cel systemu nieuznawanego za wysokiego ryzyka (w tym GPAI) tak, że ten staje się systemem wysokiego ryzyka w rozumieniu art. 6. Z kolei motyw 109 dotyczy odmiennej sytuacji: organizacji, która dostraja (fine-tuning) lub w inny sposób modyfikuje GPAI, ale system w wyniku tej modyfikacji nie staje się systemem wysokiego ryzyka. Wówczas obowiązki podmiotu pochodnego ograniczają się do samej modyfikacji — typowo do uzupełnienia dokumentacji technicznej dostarczonej przez dostawcę nadrzędnego o informacje o zmianach, w tym o nowych źródłach danych treningowych. Większość MŚP nie przekracza żadnego z tych progów, ale tylko inwentarz dokumentuje, gdzie ta linia przebiega dla każdego systemu z osobna.

Wymagane pola inwentarza

Obronny inwentarz AI ma w przybliżeniu piętnaście pól na wpis. Należy oprzeć się pokusie dorzucania kolejnych — każde dodatkowe pole to obciążenie utrzymaniowe, a rejestr, który przetrwa, to ten, który pracownicy faktycznie aktualizują, gdy systemy się zmieniają. Poniższa lista to zestaw minimalny obsługujący obowiązki stosowane od 2 sierpnia 2026 r.

• Nazwa systemu i unikalny identyfikator — stała etykieta używana spójnie w dokumentacji technicznej, w rejestracji w bazie UE, w umowach z dostawcami oraz w wewnętrznych zgłoszeniach zarządzania zmianą.
• Osoba odpowiedzialna — jeden imiennie wskazany pracownik organizacji, który odpowiada za aktualność wpisu i za uruchomienie ponownej klasyfikacji w razie istotnej zmiany systemu. Zespół ani dział nie są właścicielem.
• Wskaźnik dostawca/wewnętrzny — czy system jest budowany wewnętrznie, kupowany jako SaaS, czy też wbudowany w większy produkt. Od tego zależy, czy są Państwo dostawcą, podmiotem stosującym, czy jednym i drugim w rozumieniu art. 25 i 26.
• Poziom ryzyka — niedopuszczalny, wysokiego ryzyka (z art. 6 ust. 1 lub z art. 6 ust. 2 w związku z załącznikiem III, ze wskazaniem konkretnego punktu załącznika III), ograniczonego ryzyka (ze wskazaniem konkretnego ustępu art. 50), minimalnego ryzyka oraz — w razie potrzeby — flaga nakładki GPAI.
• Uzasadnienie klasyfikacji — krótka argumentacja prozą, w tym powołanie na odstępstwo z art. 6 ust. 3, o ile było wykorzystane. Lakoniczne uzasadnienia nie przejdą audytu — standardem jest „udokumentowane, ponieważ uzasadnione”.
• Model nadrzędny — dla wpisów GPAI-podmiot stosujący: tożsamość modelu, wersja, dostawca oraz data ostatniego przeglądu instrukcji obsługi otrzymanych od dostawcy nadrzędnego na podstawie art. 53 ust. 1 lit. b.
• Przewidziany cel — konkretny przypadek użycia opisany dla podmiotów stosujących, w sformułowaniu instrukcji obsługi z art. 13. Rozjazd między celem przewidzianym a faktycznym to jedno z najczęstszych ustaleń pokontrolnych.
• Podstawa prawna RODO — dla każdego systemu przetwarzającego dane osobowe: podstawa z art. 6 RODO (oraz przesłanka z art. 9, jeżeli wchodzą dane szczególnych kategorii). Krzyżowe odniesienie do odpowiedniego rekordu z art. 30 RODO.
• Pochodzenie danych treningowych — streszczenie obejmujące źródło, warunki licencyjne, zgodność z opt-out praw autorskich oraz minimalizację lub deidentyfikację. Dla wpisów GPAI-podmiot stosujący pole może wskazywać na opublikowane streszczenie danych treningowych dostawcy nadrzędnego.
• Rodzaj wyniku — prognoza, zalecenie, klasyfikacja, generowanie treści, decyzja. Rodzaj wyniku decyduje o obowiązkach przejrzystości z art. 50 oraz o analizie z art. 22 RODO.
• Wpływ na decyzje — czy wynik wpływa na decyzje o istotnych konsekwencjach dla zidentyfikowanych osób fizycznych i jeżeli tak, jakiej grupy populacji dotyczy (pracowników, kandydatów, klientów, pacjentów, beneficjentów). To pole sygnalizuje, kiedy konieczna jest osobna ocena skutków dla ochrony danych z art. 35 RODO lub ocena oddziaływania na prawa podstawowe z art. 27 RIA.
• Projekt nadzoru ludzkiego — środki z art. 14 faktycznie wdrożone: przegląd przed wdrożeniem, walidacja wyniku, możliwość nadpisania, progi interwencji, ścieżki eskalacji. Ogólnikowe „człowiek przegląda wynik” nie spełnia standardu audytowego.
• Stan oceny zgodności — dla wpisów wysokiego ryzyka: wybrana ścieżka (kontrola wewnętrzna z załącznika VI, ocena zewnętrzna z załącznika VII dla biometrii, ocena zintegrowana dla produktów z załącznika I), data ostatniej oceny oraz numer deklaracji zgodności UE z art. 47.
• Rejestracja w bazie UE — dla wpisów wysokiego ryzyka objętych art. 49: identyfikator rejestracji oraz data ostatniej aktualizacji.
• Data ostatniego przeglądu i wyzwalacz następnego przeglądu — kalendarzowa data ostatniej weryfikacji klasyfikacji oraz zdarzenia, które wymuszą ponowny przegląd (zmiana modelu, zmiana danych treningowych, rozszerzenie celu przewidzianego, integracja z nowym procesem biznesowym).

Wykorzystanie istniejących rejestrów

Najtańszy inwentarz AI to ten, który rozszerza istniejące rejestry, a nie buduje się go od zera. Trzy źródła organizacyjne pokrywają większość pól wymienionych powyżej — i większość dyscypliny zarządczej potrzebnej, by utrzymać je w aktualności.

Rejestr czynności przetwarzania prowadzony na podstawie art. 30 RODO obejmuje rdzeń danych osobowych każdego systemu AI, który przetwarza dane o zidentyfikowanych osobach fizycznych. Rejestr ten zawiera już podstawę prawną, kategorie danych, kategorie osób, których dane dotyczą, kategorie odbiorców, transfery międzynarodowe oraz harmonogram przechowywania — czyli zestaw, który inwentarz AI musi albo zduplikować, albo do niego odesłać. Praktyczny ruch to dodanie kolumny „odniesienie do systemu AI” do istniejącego rejestru czynności i — po stronie inwentarza AI — odsyłanie do odpowiedniego wpisu w rejestrze czynności zamiast powielania pól danych osobowych. Oceny skutków dla ochrony danych z art. 35 RODO oraz oceny oddziaływania na prawa podstawowe z art. 27 RIA — które obejmują podmioty publiczne, podmioty prywatne świadczące usługi publiczne oraz dodatkowo każdy podmiot stosujący (publiczny lub prywatny) system z załącznika III §5(b) dotyczący zdolności kredytowej lub system z załącznika III §5(c) dotyczący ustalania stawek ubezpieczeń na życie albo zdrowotnych — powinny być z poziomu inwentarza linkowane, a nie kopiowane do wnętrza wpisu.

Rejestry zasobów wymagane przez NIS2, tam gdzie istnieją, pokrywają oś operacyjną i bezpieczeństwa informacji. Krajowe ustawy transponujące NIS2 — termin transpozycji upłynął 17 października 2024 r., a Komisja Europejska w listopadzie 2024 r. wszczęła postępowania o uchybienie zobowiązaniom przeciwko 23 państwom członkowskim, które tego terminu nie dotrzymały; transpozycja postępowała falami przez 2025 i 2026 r. — wymagają od podmiotów kluczowych i ważnych prowadzenia rejestru zasobów ICT i zależności. W MŚP objętych zakresem NIS2 rejestr ten zwykle zawiera już platformy chmurowe, zależności SaaS i krytyczne oprogramowanie, na którym pracują obciążenia AI. Oznaczenie systemów AI w rejestrze NIS2 i zwrotne odniesienie do inwentarza AI synchronizuje oba reżimy i eliminuje sytuację, w której rejestr NIS2 organizacji wykazuje SaaS dostarczany przez podmiot zewnętrzny, ale nie sygnalizuje, że ten SaaS osadza w sobie przypadek użycia AI objęty zakresem RIA.

ISO/IEC 27001:2022, załącznik A.5.9 (dawniej A.8.1.1 w wersji z 2013 r.), wymaga inwentarza informacji i innych powiązanych aktywów, w tym oprogramowania, usług i samych informacji. W MŚP certyfikowanych według ISO inwentarz aktywów wymagany przez A.5.9 jest naturalnym nośnikiem rejestru AI. Ścieżka audytowa wymagana przez ISO 27001 — właściciel, klasyfikacja, zapis zmian — odwzorowuje się na pola inwentarza AI wymienione powyżej. Potraktowanie inwentarza AI jako podzbioru inwentarza aktywów ISO 27001, a nie nowego artefaktu, oszczędza podwójnej pracy utrzymaniowej, daje rejestrowi AI rytm przeglądów istniejącego SZBI i unika nazbyt powszechnego stanu, w którym rejestr aktywów SZBI i inwentarz AI rozjeżdżają się we wzajemnie sprzecznych wersjach.

Poza tymi trzema źródłami warto dotknąć dwóch sąsiednich rejestrów: rejestru dostawców prowadzonego przez zakupy (zwykle obejmuje on każdy zewnętrzny SaaS, z którego korzysta organizacja, i często jest najszybszą drogą do kompletnego przeglądu „AI w cieniu”) oraz rejestru zgód lub podstaw umownych prowadzonego przez ochronę danych (który obsługuje już stronę RODO każdego systemu AI skierowanego do klientów). Gdy inwentarz AI jest budowany jako federacja odniesień między tymi rejestrami, a nie jako nowy arkusz kalkulacyjny, narzut utrzymaniowy spada o około połowę, a międzyreżimowa spójność, którą cenią audytorzy, pojawia się w sposób naturalny.

Trzy przykłady inwentarzy MŚP

Konkretne przykłady wyostrzają dyscyplinę. Trzy krótkie przypadki pokazują, jak schemat inwentarza wygląda w praktyce dla dostawcy HR-tech, FinTechu i MedTechu — każdy z nich typowy dla wczesnego etapu europejskiej spółki najbardziej narażonej na termin 2 sierpnia 2026 r.

HR-tech: 50-osobowy dostawca SaaS w Monachium

Produkt to system rekrutacyjny (ATS) z dwoma funkcjami opartymi na AI: streszczaniem CV zbudowanym na bazie GPT-4o oraz wewnętrznym rankingiem kandydatów wytrenowanym na historycznych danych rekrutacyjnych klienta. W inwentarzu znajdują się dwa odrębne wpisy, nie jeden. Wpis A — streszczanie CV — to samodzielnie system ograniczonego ryzyka (przejrzystość typu chatbot z art. 50 ust. 1, ponieważ rekruter widzi streszczenie wyraźnie oznaczone jako wygenerowane przez AI), z nakładką GPAI-podmiot stosujący wskazującą OpenAI jako dostawcę nadrzędnego. Wpis B — ranking kandydatów — to bezdyskusyjnie system wysokiego ryzyka w rozumieniu załącznika III pkt 4 lit. a (zatrudnienie, rekrutacja, wybór kandydatów); spółka jest dostawcą, ponieważ system jest wprowadzany do obrotu w UE pod jej własną nazwą. Wpis B niesie pełen trzynastopunktowy zestaw obowiązków z art. 9–49; wpis A — wyłącznie obowiązek informowania z art. 50 ust. 1 i zapis przekazany przez dostawcę GPAI. Właścicielem obu wpisów jest dyrektor produktu, a wskazanym liderem ds. RIA w dziale prawnym — właściciel dodatkowy. Inwentarz odsyła krzyżowo do rejestru aktywów ISO 27001 (spółka jest certyfikowana) dla obu wpisów oraz do rejestru czynności RODO w polach danych osobowych. Oba wpisy oznaczają datę 2 sierpnia 2026 r. jako wyzwalacz zamknięcia dokumentacji technicznej z art. 11 i załącznika IV.

FinTech: 30-osobowy start-up kredytu konsumenckiego w Wilnie

Produkt to aplikacja kredytu konsumenckiego z dwoma komponentami AI: modelem scoringu kredytowego wytrenowanym na danych własnych i sygnałach z otwartej bankowości oraz modelem wykrywania oszustw nałożonym na telemetrię transakcyjną. Model scoringowy wpada w załącznik III pkt 5 lit. b — ocena zdolności kredytowej osób fizycznych — i jest domyślnie systemem wysokiego ryzyka; spółka jest dostawcą, wprowadza system na własną platformę i prowadzi ocenę zgodności w trybie kontroli wewnętrznej z załącznika VI. Model wykrywania oszustw korzysta z wyłączenia tekstowego zapisanego wprost w treści załącznika III §5(b), które wyklucza „systemy AI wykorzystywane do wykrywania oszustw finansowych” z kategorii zdolności kredytowej już na poziomie samej kategorii — a to wyłączenie inne niż proceduralna derogacja z art. 6 ust. 3, która filtruje systemy z załącznika III ogólnie. Wpis w inwentarzu musi jasno wskazywać, z którego z tych „wyjść” spółka korzysta. Ponieważ wyłączenie z §5(b) jest wąskie (obejmuje wykrywanie oszustw, a nie każdy scoring ryzyka transakcyjnego), zespół prawny rozsądnie utrzymuje pozycję defensywną: częściowy zestaw kontroli wysokiego ryzyka pozostaje wokół modelu antyfraudowego, a każde rozszerzenie celu modelu poza wykrywanie oszustw uruchamia ponowną klasyfikację. Graniczny przypadek to chatbot obsługi klienta zbudowany na Mistralu Large; staje się on wpisem C ograniczonego ryzyka z nakładką GPAI-podmiot stosujący. Krzyżowe odniesienie do rejestru czynności RODO jest tu kluczowe, bo do scoringu kredytowego stosuje się art. 22 RODO (zautomatyzowane podejmowanie decyzji w indywidualnych przypadkach), a inwentarz musi udowodnić prawo osoby, której dane dotyczą, do uzyskania interwencji człowieka, wyrażenia własnego stanowiska i zakwestionowania decyzji. Art. 27 RIA również tu zadziała — każdy podmiot stosujący system z załącznika III §5(b) musi przeprowadzić ocenę oddziaływania na prawa podstawowe, niezależnie od tego, czy podmiot ten jest publiczny, czy prywatny. IOD jest wskazanym właścicielem obu wpisów wysokiego ryzyka; chatbot należy do dyrektora ds. obsługi klienta.

MedTech: 20-osobowy start-up zdalnego monitorowania w Dublinie

Produkt to aplikacja zdalnego monitorowania pacjentów z jednym przypadkiem użycia AI: algorytm sygnalizuje istotne klinicznie zmiany parametrów życiowych na podstawie ciągłej telemetrii z urządzenia ubieralnego. System jest wyrobem medycznym w rozumieniu rozporządzenia (UE) 2017/745 (MDR) i nosi oznakowanie CE w tym reżimie. Wpis w inwentarzu AI to system wysokiego ryzyka w rozumieniu art. 6 ust. 1 — AI jest elementem bezpieczeństwa produktu objętego unijnym prawodawstwem harmonizacyjnym wymienionym w załączniku I (wyroby medyczne), a ocena zgodności jest prowadzona przez stronę trzecią. Obowiązki merytoryczne z RIA dla wysokiego ryzyka stosuje się do tego wpisu od 2 sierpnia 2027 r., a nie od 2 sierpnia 2026 r., ze względu na odroczony harmonogram art. 6 ust. 1 w art. 113. Ocena zgodności jest zintegrowana z istniejącą procedurą MDR; ta sama jednostka notyfikowana, która działa w ramach MDR, obejmuje również prace dla RIA, a obowiązki specyficzne dla AI (dokumentacja techniczna z art. 11, zarządzanie ryzykiem z art. 9, przejrzystość dla pracowników ochrony zdrowia z art. 13) nakładają się na istniejącą dokumentację techniczną. Wpis w inwentarzu odsyła do dokumentacji technicznej MDR, zamiast ją duplikować; właściciel SZJ to ta sama osoba, która już przewodniczy odpowiedzialności za system zarządzania jakością z art. 10 MDR; inwentarz odsyła do rejestru czynności RODO w polach przetwarzania danych zdrowotnych na podstawie art. 9 ust. 2 lit. h RODO. Pułapką jest tu odroczony termin: MedTech, który omyłkowo potraktuje 2 sierpnia 2026 r. jako swój wyzwalacz, kończy z równoległą pracą certyfikacyjną prowadzoną dwanaście miesięcy za wcześnie.

Luki, na które wpadają MŚP

W praktyce inwentaryzacyjnej w MŚP powtarzają się trzy kategorie luk, a każda z nich w cichy sposób podkopuje rejestr, jeśli nie jest tropiona świadomie.

AI w cieniu to luka największa. Marketing wprowadza Jaspera, ChatGPT Team albo Copy.ai do redagowania treści. Sprzedaż podpina Gong, Apollo czy Lavendera do nagrywanych rozmów i mailingu. Inżynieria używa GitHub Copilota, Cursora albo Codeium bez formalnej decyzji zakupowej. HR puszcza ankiety przez ChatGPT i przepuszcza odpowiedzi otwarte przez klasyfikator nastrojów. Każde z tych zastosowań to przypadek użycia AI w rozumieniu art. 3 ust. 1, niemal na pewno samodzielnie ograniczonego lub minimalnego ryzyka, ale niewidoczny dla centralnego inwentarza, dopóki ktoś nie zapyta. Lekarstwo jest proceduralne: jednostronicowy formularz deklaracji rozsyłany do każdego kierownika działu z prośbą o wymienienie wszystkich narzędzi AI używanych przez zespół w ostatnich sześciu miesiącach, powtarzany kwartalnie, z weryfikacją krzyżową przez zestawienie kart zakupowych i ewidencję wydatków SaaS. Pierwsza runda deklaracji w typowej 50-osobowej spółce SaaS ujawnia od dwunastu do dwudziestu narzędzi AI, o których centralna funkcja zgodności nie wiedziała.

AI wbudowane w SaaS to druga luka. Coraz częściej standardowy produkt B2B SaaS, z którego organizacja korzysta od lat, po cichu dodał funkcje AI w 2024 i 2025 r. — Salesforce Einstein, HubSpot AI, Notion AI, Slack AI, Zoom AI Companion, Microsoft 365 Copilot, funkcje Gemini w Google Workspace, Atlassian Intelligence. Organizacja-gospodarz jest podmiotem stosującym każdy z tych podsystemów AI, choć zakup pierwotnie dotyczył samego narzędzia produktywności. Inwentarz musi rejestrować każdą podfunkcję AI jako odrębny wpis, a nie zwijać ją do wiersza produktu nadrzędnego. Każdy dostawca jest z kolei podmiotem stosującym GPAI nad dostawcą modelu fundamentalnego, więc łańcuch przekazywania informacji jest trzywarstwowy: model fundamentalny (OpenAI/Anthropic/Google) → dostawca SaaS (HubSpot/Microsoft/Slack) → organizacja-gospodarz. Wpis w inwentarzu musi nazwać wszystkie trzy warstwy, jeśli obowiązki podmiotu stosującego mają być egzekwowalne.

Zmiany modelu to luka trzecia i najbardziej śliska. Dostawca SaaS zmienia bazowy model GPAI — powiedzmy z GPT-4 na GPT-4o albo z Claude 3.5 na Claude 4 — bez zmiany powierzchni produktu, a wpis w inwentarzu po stronie podmiotu stosującego po cichu staje się nieaktualny. Lekarstwo to dodanie pola „zablokowana wersja modelu” oraz wymóg ponownej klasyfikacji jako wyzwalacza przy zmianie modelu nadrzędnego. U dojrzałych dostawców zmiana jest zwykle ogłaszana w kanale notatek wydawniczych, do którego zespół zakupów powinien być zapisany; u dostawców mniej dojrzałych wpis powinien wprost odnotować, że tożsamość modelu nadrzędnego jest zmienna, a rytm przeglądu tego wpisu — zacieśniony (kwartalny zamiast rocznego).

Częste problemy z przypisywaniem odpowiedzialności

Najczęstszą przyczyną, dla której inwentarz AI dryfuje w stronę bezużyteczności, jest przypisanie odpowiedzialności do zespołu lub działu, a nie do imiennie wskazanej osoby. „Wpis 7 należy do zespołu produktu” to nie-odpowiedź w chwili, gdy system istotnie się zmienia, a nikt wpisu nie aktualizuje, bo nikt osobiście tej aktualizacji nie był winien. Dyscyplina, która spaja każdy inny rejestr regulacyjny — wskazany imiennie IOD za rejestrem czynności RODO, wskazany imiennie CISO za rejestrem aktywów ISO 27001, wskazana imiennie osoba kontaktowa NIS2 w zgłoszeniu w państwie członkowskim — to ta sama dyscyplina, której wymaga inwentarz AI.

W praktyce sprawdzają się trzy wzorce. Pierwszy to jeden lider ds. RIA, zwykle ulokowany w funkcji prawnej lub zgodnościowej, który prowadzi centralny rejestr i jest właścicielem wpisów najwyższego ryzyka (systemów wysokiego ryzyka z załącznika III, w których dokumentacja techniczna z art. 11 wymaga wkładu wielofunkcyjnego). Drugi to model federacyjny, w którym lider ds. RIA prowadzi sam rejestr i metodykę, a poszczególni właściciele produktu lub funkcji są imiennie wskazani na każdym wpisie — odpowiedni dla organizacji SaaS, w których nowe funkcje AI wchodzą co kwartał i gdzie jednoosobowa centralizacja każdego wpisu tworzyłaby wąskie gardło. Trzeci to model współwłasności, w którym każdy wpis wysokiego ryzyka ma wskazanego właściciela biznesowego (kierownik produktu lub szef odpowiedniej funkcji) i wskazanego właściciela kontroli (IOD lub lider ds. RIA) — właściciel biznesowy odpowiada za aktualność wpisu wraz z ewolucją systemu, właściciel kontroli — za realizację zestawu obowiązków. Każdy z modeli jest obronny; nieobronne jest pozostawianie wpisów z odpowiedzialnością na poziomie zespołu lub bez właściciela.

Drugim problemem jest brak współwłaściciela na wpisach międzyfunkcyjnych. Kanonicznym przypadkiem jest HR-tech: właściciel produktu funkcji rankingu kandydatów jest naturalnie umieszczony, by prowadzić dokumentację techniczną, ale obowiązek informowania pracowników, których dane są przetwarzane, zgodnie z art. 26 ust. 7 spoczywa na funkcji HR po stronie klienta, a nie po stronie dostawcy. Jeżeli wpis w inwentarzu dostawcy nie nazywa kontrpartnera-właściciela wewnątrz każdej organizacji-klienta, nie da się udowodnić kaskadowych obowiązków podmiotu stosującego z art. 26, a instrukcji obsługi z art. 13 po stronie dostawcy nie da się prawidłowo zaadresować. Dokumentacja onboardingu klienta i wzór umowy o świadczenie usług muszą zawierać klauzulę, która zobowiązuje klienta do wskazania właściciela ds. RIA po stronie podmiotu stosującego przed aktywacją.

Art. 26 ust. 5 zasługuje na osobną wzmiankę, bo to jeden z nielicznych obowiązków podmiotu stosującego, który zaskakuje nawet zdyscyplinowane inwentarze. Podmioty stosujące systemy wysokiego ryzyka monitorują działanie systemu na podstawie instrukcji obsługi i — w stosownych przypadkach — informują dostawców zgodnie z art. 72. Jeżeli mają podstawy uznać, że stosowanie zgodne z instrukcją obsługi może spowodować, że system stwarza ryzyko w rozumieniu art. 79 ust. 1, muszą bez zbędnej zwłoki poinformować dostawcę lub dystrybutora oraz właściwy organ nadzoru rynku — i zawiesić używanie systemu. W praktyce oznacza to, że każdy wpis wysokiego ryzyka wymaga imiennie wskazanego właściciela monitorowania po stronie podmiotu stosującego, udokumentowanej ścieżki eskalacji kończącej się we właściwym krajowym organie nadzoru oraz pisemnego protokołu zawieszenia, który można uruchomić bez dodatkowej zgody wewnętrznej. Wskazanie tych ról zbyt późno, gdy system jest już w produkcji, to jedno z najczęstszych ustaleń wczesnych przeglądów egzekucyjnych. (Należy odróżnić tę regułę od art. 26 ust. 4, który dotyczy jakości danych wejściowych; obowiązek monitorowania, eskalacji z art. 79 ust. 1 i zawieszenia systemu jest zakotwiczony w art. 26 ust. 5).

60-dniowy plan budowy

Sześćdziesiąt dni wystarczy, by wydać obronną pierwszą wersję inwentarza, jeżeli prace są ułożone w czystej sekwencji, organ zarządzający akceptuje rytm na początku, a istniejące rejestry są ponownie wykorzystane, a nie duplikowane. Plan poniżej zakłada typowe MŚP zatrudniające od 30 do 100 osób, bez wcześniejszej funkcji nadzoru nad AI, oraz wskazanego do tej pracy lidera ds. RIA przekrojowego względem funkcji.

Dni 1–10 — zakres i mapowanie ponownego wykorzystania. Lider ds. RIA gromadzi istniejący rejestr czynności RODO, inwentarz aktywów ISO 27001 (jeżeli dotyczy), rejestr NIS2 (jeżeli wchodzi w zakres), listę dostawców z funkcji zakupów oraz ewidencję wydatków SaaS. Każdy wpis we wszystkich tych rejestrach jest przeglądany pod kątem powiązań z AI, a te, które AI dotyczą, oznaczane są dla inwentarza. Lider opracowuje schemat inwentarza — zestaw piętnastu pól wymienionych powyżej z ewentualnymi rozszerzeniami specyficznymi dla organizacji — i przedkłada go do akceptacji IOD-owi, CISO (jeżeli istnieje) i sponsorowi z poziomu organu zarządzającego. W tym samym oknie zapadają decyzje narzędziowe: arkusz kalkulacyjny, platforma GRC lub rozszerzenie narzędzia obsługującego rejestr czynności RODO. Dla MŚP bez platformy GRC ustrukturyzowany arkusz pod kontrolą wersji z obowiązkowymi polami przeglądu wystarczy w pierwszej wersji.

Dni 11–30 — odkrywanie i populacja. W tym oknie odbywa się przegląd „AI w cieniu”: jednostronicowy formularz deklaracji do każdego kierownika działu, uzgodnienie z ewidencją wydatków SaaS oraz ustrukturyzowane rozmowy z liderami każdej funkcji (produkt, inżynieria, marketing, sprzedaż, obsługa klienta, HR, finanse, operacje). Każda deklaracja staje się wstępnym wpisem inwentarza. Lider ds. RIA wypełnia pola metadanych z istniejącego rejestru czynności RODO i z rejestrów aktywów wszędzie tam, gdzie dane już są, i otwiera nowe źródło zbierania danych tylko dla pól rzeczywiście specyficznych dla AI (przewidziany cel, rodzaj wyniku, model nadrzędny, pochodzenie danych treningowych, projekt nadzoru ludzkiego). Do końca dnia 30 każdy znany przypadek użycia AI ma wstępny wpis, nawet jeśli klasyfikacja jest tymczasowa, a uzasadnienie szkieletowe.

Dni 31–50 — klasyfikacja i analiza luk. Lider ds. RIA prowadzi każdy wstępny wpis przez drzewo decyzyjne (osiem pytań obejmujących art. 5, załącznik III, art. 6 ust. 1, art. 6 ust. 3, status dostawcy/podmiotu stosującego, nakładkę GPAI, interakcję z art. 50 ust. 1, syntetyczne treści z art. 50 ust. 2/4 oraz ryzyko systemowe z art. 51). Każdemu wpisowi przypisuje się poziom ryzyka wraz z pisemnym uzasadnieniem. Dla wpisów wysokiego i ograniczonego ryzyka lider prowadzi analizę luk wobec odpowiedniego zestawu obowiązków: dla wysokiego ryzyka — trzynastopunktowej linii bazowej art. 9–49; dla ograniczonego — czterech obowiązków informowania z art. 50. Każda luka staje się zadaniem naprawczym z wskazanym właścicielem i datą docelową, sekwencjonowanym względem 2 sierpnia 2026 r. (lub 2 sierpnia 2027 r. dla wpisów z załącznika I i art. 6 ust. 1). W tym samym oknie zapadają decyzje co do zakresu DPIA i oceny oddziaływania na prawa podstawowe z art. 27: każdy wpis wysokiego ryzyka, który przetwarza dane osobowe, uruchamia przegląd DPIA, a ocenę z art. 27 RIA uruchamia każdy wpis wysokiego ryzyka stosowany przez podmiot publiczny, przez podmiot prywatny świadczący usługę publiczną, jak również przez każdego podmiot stosujący system z załącznika III §5(b) dotyczący zdolności kredytowej lub system z załącznika III §5(c) dotyczący ustalania stawek ubezpieczeń na życie albo zdrowotnych — niezależnie od tego, czy podmiot stosujący jest publiczny, czy prywatny.

Dni 51–60 — akceptacja i rytm operacyjny. Inwentarz i lista zaległości z analizy luk są przedkładane organowi zarządzającemu do akceptacji. Punkt RIA zostaje dodany jako stała kwartalna pozycja w porządku obrad zarządu. Właściciel każdego wpisu wysokiego ryzyka jest formalnie wskazany na piśmie, a wraz z nim — właściciele monitorowania na potrzeby art. 26 ust. 5 wraz z prawem do zawieszenia. Umowy z klientami i dokumentacja onboardingu są przeglądane pod kątem klauzul instrukcji obsługi z art. 13 i klauzul kaskadowych z art. 26. Program znajomości AI z art. 4 jest wymierzony, a inwentarz służy do wskazania zespołów pracowniczych obsługujących lub używających każdego systemu. Pierwszy audyt wewnętrzny inwentarza zostaje zaplanowany na koniec I kwartału 2027 r. — sześć miesięcy po wejściu obowiązków, na tyle długo, by eksploatacja produkcyjna ujawniła pierwszą rundę problemów, a na tyle krótko, by luki dało się jeszcze naprawić przed pierwszym cyklem audytu zewnętrznego. Drugą wersję samego inwentarza planuje się na koniec II kwartału 2027 r.

Wnioski i kolejne kroki

Termin 2 sierpnia 2026 r. jest stały i niesymetryczny: koszt opóźnienia z inwentarzem jest znacznie wyższy niż koszt wcześniejszego przygotowania, ponieważ niemal każdy inny obowiązek z RIA na nim się opiera. Praca jest też nietypowo dobrze zharmonizowana z tym, co europejskie MŚP już dobrze umieją — rejestr czynności z art. 30 RODO, rejestry aktywów NIS2, inwentarz aktywów ISO 27001 — więc wysiłek krańcowy jest istotnie niższy, niż sugeruje sama treść regulacji. Pułapką jest traktowanie inwentarza AI jako równoległego artefaktu, a nie rozszerzenia rejestrów już istniejących. Należy go budować jako federację, wskazać jedną osobę jako właściciela każdego wpisu i traktować „AI w cieniu”, AI wbudowane w SaaS oraz zmiany modeli jako trzy kategorie luk, które po cichu podkopią rejestr, jeżeli nie będą tropione świadomie.

Najbliższe sześćdziesiąt dni dla MŚP startującego od zera wygląda następująco: w pierwszym tygodniu wskazanie lidera ds. RIA, w drugim — zamknięcie schematu i planu ponownego wykorzystania, w trzecim i czwartym — przegląd „AI w cieniu”, w czwartym i piątym — wypełnienie pierwszej kompletnej wersji rejestru, w szóstym i siódmym — klasyfikacja i analiza luk każdego wpisu, w dziewiątym — przedłożenie zatwierdzonego rejestru i mapy działań naprawczych organowi zarządzającemu. Do dziesiątego tygodnia inwentarz przestaje być projektem — staje się stałym aktywem operacyjnym z kwartalnym rytmem przeglądu i wskazanym właścicielem każdego wpisu. To jest postawa, którą termin 2 sierpnia 2026 r. nagradza, i to jest postawa, która sprawia, że pozostała praca zgodnościowa wynikająca z RIA staje się wykonalna.