Zgodność z aktem o sztucznej inteligencji od strony inżynierskiej: dokumentacja techniczna, rejestrowanie zdarzeń, nadzór ludzki i zarządzanie danymi
Prawie wszystko, co napisano o unijnym akcie o sztucznej inteligencji, dotyczy zakresu: w której kategorii ryzyka Państwo lądują, czy są dostawcą, czy podmiotem stosującym, czy system łapie się na załącznik III. Na to odpowiadają Państwa prawnicy.
Niemal nikt nie zajmuje się tym, co dzieje się po odpowiedzi. Jeśli system jest wysokiego ryzyka, rozporządzenie żąda systemu zarządzania ryzykiem działającego przez cały cykl życia, zarządzania danymi, które da się udowodnić, automatycznego rejestrowania zdarzeń z określonym okresem przechowywania, dokumentacji technicznej w narzuconej strukturze, nadzoru ludzkiego zaprojektowanego, a nie zadeklarowanego, oraz monitorowania po wprowadzeniu do obrotu, które faktycznie coś zbiera. To są produkty pracy inżynierskiej. I to jest ta część, którą budujemy.
Jak dziś wyglądają terminy
Akt o sztucznej inteligencji (rozporządzenie (UE) 2024/1689) wszedł w życie w sierpniu 2024 r. i jest stosowany etapami. Harmonogram zmienił się w 2026 r. i warto być tu precyzyjnym, bo ta zmiana przesunęła pieniądze i uwagę.
- 2 lutego 2025 r.: zaczęły obowiązywać zakazane praktyki oraz obowiązki w zakresie kompetencji w zakresie AI.
- 2 sierpnia 2025 r.: zaczęły obowiązywać obowiązki dotyczące modeli AI ogólnego przeznaczenia.
- 2 sierpnia 2026 r.: zaczęły obowiązywać obowiązki w zakresie przejrzystości z artykułu 50: poinformowanie, że użytkownik ma do czynienia z systemem AI, oznaczanie treści syntetycznych, ujawnianie rozpoznawania emocji i kategoryzacji biometrycznej oraz oznaczanie deepfake'ów.
- 2 grudnia 2027 r.: obowiązki dla samodzielnych systemów wysokiego ryzyka, po pakiecie Digital Omnibus. Rada i Parlament uzgodniły odroczenie w maju 2026 r., a ostateczne zatwierdzenie nastąpiło w czerwcu 2026 r.
- 2 sierpnia 2028 r.: obowiązki dla systemów AI wysokiego ryzyka wbudowanych w produkty objęte regulacjami sektorowymi.
Dostawcy systemów wysokiego ryzyka zyskali dzięki odroczeniu mniej więcej szesnaście miesięcy. Nie zmniejszyło ono zakresu pracy i nie przesunęło dwóch obowiązków już obowiązujących: przejrzystości z artykułu 50 oraz kompetencji w zakresie AI u osób, które te systemy obsługują.
Co budujemy
Dokumentacja techniczna jako artefakt generowany
Załącznik IV określa, co dokumentacja techniczna musi zawierać: opis systemu, decyzje projektowe, architekturę, wymagania dotyczące danych, metodykę trenowania tam, gdzie ma zastosowanie, procedury walidacji i testowania, metryki, środki zarządzania ryzykiem oraz zmiany wprowadzane w cyklu życia.
Pisany ręcznie, taki dokument jest nieaktualny tydzień po podpisaniu. Budujemy go jako coś, co wytwarza Państwa potok: karty modeli i karty danych generowane z przebiegów trenowania i ewaluacji, opisy architektury i przepływu danych utrzymywane obok kodu, wyniki ewaluacji przypięte do wersji, której dotyczą, oraz historia zmian pochodząca z systemu kontroli wersji, a nie z czyjejś pamięci. Dokument staje się wynikiem builda.
Automatyczne rejestrowanie zdarzeń spełniające artykuł 12
Systemy wysokiego ryzyka muszą rejestrować zdarzenia automatycznie przez cały okres działania, w standardzie pozwalającym na identyfikowalność funkcjonowania i monitorowanie po wprowadzeniu do obrotu, z okresem przechowywania odpowiednim do celu, a w niektórych przypadkach wynoszącym co najmniej sześć miesięcy.
W praktyce oznacza to rozstrzygnięcie, czym w Państwa systemie jest „zdarzenie", zapisywanie wejść, wyjść, wersji modelu, ścieżki decyzyjnej i tożsamości zaangażowanego człowieka, przechowywanie tego w formie, którą da się odpytać po latach, i robienie tego bez gromadzenia danych osobowych, do których nie mają Państwo podstawy. To napięcie (logować dość dla aktu o sztucznej inteligencji, przechowywać dość mało dla RODO) jest właściwym problemem projektowym i przechodzimy przez nie wprost z Państwa działem ochrony danych.
Zarządzanie danymi zgodnie z artykułem 10
Zbiory danych treningowych, walidacyjnych i testowych muszą być adekwatne, wystarczająco reprezentatywne oraz w możliwie największym stopniu wolne od błędów i kompletne, ze zbadaniem pod kątem stronniczości. Spełnienie tego wymaga możliwego do pokazania pochodzenia danych, udokumentowanego źródła, metodyki oceny stronniczości wraz z wynikami oraz zdolności do odtworzenia, które dane dały którą wersję modelu.
Budujemy potok, który zamienia te deklaracje w rzeczy sprawdzalne: wersjonowane zbiory danych, odtwarzalne podziały, automatyczne kontrole jakości danych i ocenę stronniczości na cechach chronionych istotnych dla Państwa zastosowania.
Nadzór ludzki zbudowany, a nie zadeklarowany
Artykuł 14 wymaga, by systemy wysokiego ryzyka były zaprojektowane tak, aby człowiek mógł zrozumieć wynik, zachować świadomość skłonności do automatyzacji, poprawnie zinterpretować rezultat, zdecydować o nieskorzystaniu z niego oraz zainterweniować lub zatrzymać system.
To jest specyfikacja interfejsu użytkownika. Wbudowujemy nadzór w produkt: uczciwie pokazaną pewność i niepewność, widoczne czynniki stojące za wynikiem, możliwość odrzucenia równie łatwą w użyciu jak akceptacja, działający przycisk zatrzymania oraz rejestrowanie każdego odrzucenia, żeby monitorowanie po wprowadzeniu do obrotu miało się z czego uczyć.
Monitorowanie po wprowadzeniu do obrotu i zgłaszanie incydentów
Wymagany jest plan monitorowania, a także zgłaszanie poważnych incydentów właściwemu organowi. Budujemy zasilającą to telemetrię: wydajność śledzoną wobec metryk z Państwa dokumentacji, wykrywanie dryfu na wejściach i wyjściach, kanał zgłoszeń użytkowników docierający do inżynierii oraz obieg incydentu z wbudowanymi terminami, zamiast odkrywania ich w trakcie pierwszego zdarzenia.
Obowiązki przejrzystości z artykułu 50
Już obowiązują. Poinformowanie, że użytkownik ma do czynienia z systemem AI, odczytywalne maszynowo oznaczanie syntetycznego dźwięku, obrazu, wideo i tekstu, oznaczanie deepfake'ów oraz ujawnianie rozpoznawania emocji. Wdrażamy powierzchnie informacyjne i oznaczanie pochodzenia treści (poświadczenia C2PA tam, gdzie to właściwy mechanizm), i sprawiamy, że przeżywają one ścieżki eksportu i ponownego kodowania, które zwykle je usuwają.
Rejestracja i wsparcie przy ocenie zgodności
Systemy wysokiego ryzyka z obszarów załącznika III muszą zostać zarejestrowane w bazie danych UE przed wprowadzeniem do obrotu, a dostawcy muszą przeprowadzić ocenę zgodności. Przygotowujemy wsad techniczny (dokumentację, pakiet dowodowy, artefakty systemu zarządzania jakością po stronie inżynierskiej), i pracujemy obok Państwa jednostki notyfikowanej albo wewnętrznego procesu oceny.
Czego nie robimy
Nie świadczymy pomocy prawnej i nie rozstrzygamy, w której kategorii ryzyka mieści się Państwa system. To ustalenie prawne o realnych konsekwencjach i należy do radcy prawnego albo wykwalifikowanego doradcy ds. zgodności.
Nie sprzedajemy też platformy do zarządzania AI. Takich narzędzi jest wiele i jeśli potrzebują Państwo rejestru systemów AI oraz obiegu polityk, jedno z nich posłuży lepiej niż my. My robimy inżynierię wewnątrz samych systemów.
Dla kogo to jest
Dostawcy systemów AI wysokiego ryzyka z załącznika III (rekrutacja i zarządzanie pracownikami, ocena zdolności kredytowej, taryfikacja ubezpieczeń, ocena w edukacji, kwalifikowanie do usług podstawowych, systemy biometryczne) którzy mają teraz czas do grudnia 2027 r. i sporo do zbudowania.
Producenci wbudowujący AI w produkty objęte regulacjami (wyroby medyczne, maszyny, pojazdy), gdzie akt o sztucznej inteligencji nakłada się na istniejący reżim oceny zgodności, a oba komplety dokumentacji muszą się zgadzać.
Firmy stosujące systemy wysokiego ryzyka kupione od kogoś innego, na których ciążą własne obowiązki: nadzór ludzki, adekwatność danych wejściowych, monitorowanie i przechowywanie rejestrów zdarzeń.
Każdy, kto udostępnia funkcje generatywne użytkownikom w UE, gdzie przejrzystość z artykułu 50 obowiązuje już dziś, niezależnie od kategorii ryzyka.
Jak przebiega współpraca
Techniczna analiza luk, dwa do czterech tygodni. Bierzemy klasyfikację, do której doszedł Państwa dział prawny, i oceniamy systemy wobec wynikających z niej obowiązków inżynierskich. Efektem jest rejestr luk (obowiązek, stan obecny, co trzeba zbudować, pracochłonność), z którego mogą pracować zarówno osoby odpowiedzialne za zgodność, jak i za inżynierię.
Budowa, etapami, zwykle zaczynając od rejestrowania zdarzeń i generowania dokumentacji, bo cała reszta wytwarza dowody, które muszą gdzieś lądować.
Przegląd gotowości przed oceną zgodności, ze skompletowanym pakietem dowodowym i uczciwie nazwanymi lukami, które pozostały.
Standardy i normy
Rozporządzenie (UE) 2024/1689 wraz z załącznikami III i IV; normy zharmonizowane powstające w CEN/CENELEC JTC 21; ISO/IEC 42001 dla systemów zarządzania AI oraz ISO/IEC 23894 dla zarządzania ryzykiem AI; NIST AI Risk Management Framework tam, gdzie spółka matka z USA potrzebuje spójności; oraz RODO, które nie znika i które ogranicza większość decyzji dotyczących logowania.
Najczęstsze pytania
Czy akt o sztucznej inteligencji został odroczony?
Częściowo. Digital Omnibus przesunął obowiązki dla systemów wysokiego ryzyka na 2 grudnia 2027 r. dla systemów samodzielnych i 2 sierpnia 2028 r. dla AI wbudowanej w produkty objęte regulacjami. Zakazane praktyki, kompetencje w zakresie AI, obowiązki dotyczące modeli AI ogólnego przeznaczenia oraz zasady przejrzystości z artykułu 50 nie zostały odroczone i obowiązują dziś.
Korzystamy wyłącznie z systemów AI zbudowanych przez kogoś innego. Czy mamy jakieś obowiązki?
Tak, jako podmiot stosujący. Należą do nich używanie systemu zgodnie z instrukcją, powierzenie nadzoru ludzkiego osobom mającym kompetencje i uprawnienia do jego sprawowania, zapewnienie adekwatności danych wejściowych do przeznaczenia systemu, monitorowanie działania i przechowywanie rejestrów zdarzeń. Lżejsze niż obowiązki dostawcy, ale realne, i warto pamiętać, że istotna modyfikacja systemu albo opatrzenie go własną nazwą może uczynić z Państwa dostawcę.
Nasz system nie jest wysokiego ryzyka. Czy jest coś do zrobienia?
Prawdopodobnie dwie rzeczy. Przejrzystość z artykułu 50 dotyczy pewnych systemów niezależnie od kategorii ryzyka, w tym chatbotów i generowania treści syntetycznych. Kompetencje w zakresie AI z artykułu 4 dotyczą zaś dostawców i podmiotów stosujących w ogólności. Poza tym warto umieć wykazać, jak zapadła decyzja klasyfikacyjna, gdyby organ kiedyś zapytał.
Czy dokumentację techniczną naprawdę da się generować?
W większości tak. Architektura, opisy zbiorów danych, wyniki ewaluacji, metryki, wersje modeli i historia zmian już istnieją w Państwa systemach; praca polega na ujęciu ich w stabilnej strukturze w czasie budowania. Fragmenty faktycznie narracyjne (przeznaczenie, analiza ryzyka, uzasadnienie decyzji projektowych) pisze człowiek, a potem trzyma się je w tym samym repozytorium, żeby wersjonowały się razem z resztą.
Jak akt o sztucznej inteligencji ma się do RODO?
Nakładają się i miejscami ciągną w przeciwne strony, zwłaszcza przy rejestrowaniu zdarzeń. Akt o sztucznej inteligencji chce identyfikowalności, RODO chce minimalizacji i usuwania. Rozwiązaniem jest zwykle pseudonimizacja, staranne wyznaczenie zakresu tego, co jest logowane, i określony okres przechowywania powiązany z udokumentowanym celem. To decyzja projektowa, podejmowana raz i świadomie.
Czy korzystanie z modelu innego podmiotu czyni nas dostawcą tego modelu?
Nie, ale zbudowanie na nim systemu AI może uczynić z Państwa dostawcę tego systemu, wraz z przypisanymi mu obowiązkami. Gdzie dokładnie przebiega granica, zależy od tego, co Państwo budują i jak to przedstawiają, a to pytanie prawne. Konsekwencja inżynierska jest natomiast taka, że i tak należy założyć konieczność posiadania dokumentacji własnego systemu.
Pierwszy krok
Proszę napisać, co robią Państwa systemy i do czego doszli Państwa doradcy prawni w sprawie klasyfikacji. Ocenimy, co te obowiązki oznaczają w kodzie, i przekażemy rejestr luk z pracochłonnością przy każdej pozycji.
Skontaktujcie się z nami, aby umówić techniczną analizę luk wobec aktu o sztucznej inteligencji.
Powiązane usługi
- Agenci AI i integracja MCP: budowa systemów, które ten reżim reguluje
- Rozwój na Rynek UE: szerszy unijny stos zgodności cyfrowej
- Naprawa dostępności stron internetowych: drugi unijny obowiązek, który okazuje się projektem inżynierskim
Gotowy do rozpoczęcia z tą usługą?
Skontaktuj się