Plan gotowości do AI Act na lata 2025-2026

Gotowość do AI Act nie polega na napisaniu jednej polityki AI. Obowiązki zależą od konkretnego systemu, jego przeznaczenia, roli organizacji w łańcuchu wartości oraz sposobu użycia na rynku UE. Ten sam model może być komponentem narzędzia niskiego ryzyka, podstawą systemu wysokiego ryzyka albo modelem ogólnego przeznaczenia objętym osobnym zestawem wymagań. Program zgodności musi więc zaczynać się od inwentaryzacji i klasyfikacji, a nie od wyboru uniwersalnej checklisty.

Harmonogram także wymaga aktualnego obrazu. AI Act wszedł w życie 1 sierpnia 2024 roku. Zakazy i obowiązek AI literacy stosuje się od 2 lutego 2025, a przepisy dotyczące governance i modeli GPAI od 2 sierpnia 2025. Od 2 sierpnia 2026 stosuje się ogólną część rozporządzenia, egzekwowanie i określone obowiązki przejrzystości. Zmienione w 2026 roku terminy dla części systemów wysokiego ryzyka przypadają później, ale nie zwalnia to z kontroli obowiązujących już dzisiaj.

Zbuduj rejestr systemów i ról

Rejestr powinien obejmować systemy tworzone wewnętrznie, kupione produkty, funkcje AI w SaaS, modele udostępniane klientom oraz komponenty osadzone w większych usługach. Dla każdego wpisu trzeba wskazać zamierzone przeznaczenie, użytkowników, proces biznesowy, dane, model i dostawcę, kraje użycia, właściciela produktu oraz osoby dotknięte wynikiem.

Następnie organizacja ustala swoją rolę: provider, deployer, importer, distributor lub dostawca modelu GPAI. Rola może się zmienić, gdy firma modyfikuje system, oznacza go własną marką albo zmienia jego przeznaczenie. Klasyfikacja powinna zapisywać podstawę decyzji, wersję systemu, autora i datę przeglądu. „Używamy API dostawcy” nie jest wystarczającym uzasadnieniem braku obowiązków.

Odetnij praktyki zakazane i zaprojektuj AI literacy

Pierwszym filtrem każdego zastosowania powinna być lista praktyk zakazanych z art. 5. Zespół nie powinien czekać na etap prawny przed wdrożeniem; zakazane zachowanie trzeba wyeliminować z wymagań, danych, mechanizmów produktu i zakupów. Wątpliwe przypadki wymagają udokumentowanej oceny prawnej i decyzji przed eksperymentem z rzeczywistymi użytkownikami.

AI literacy nie oznacza jednego szkolenia dla całej firmy. Osoba kupująca narzędzie, operator podejmujący decyzję na podstawie wyniku, inżynier monitorujący model i zespół wsparcia potrzebują innych kompetencji. Program powinien być oparty na roli i obejmować ograniczenia systemu, właściwe użycie, rozpoznawanie błędów, eskalację i ochronę danych. Dowodem są zakres, uczestnicy, materiały, ocena zrozumienia oraz aktualizacja po zmianie systemu.

Rozdziel obowiązki przejrzystości od wysokiego ryzyka

Nie każdy system podlegający obowiązkowi przejrzystości jest systemem wysokiego ryzyka. Od 2 sierpnia 2026 określone systemy muszą informować użytkownika o interakcji z AI, a treści wygenerowane lub zmanipulowane mają podlegać wymaganym oznaczeniom. Komunikat Komisji z 31 lipca 2026 potwierdza rozpoczęcie egzekwowania oraz stosowanie nowych reguł przejrzystości od 2 sierpnia.

Kontrola produktu powinna sprawdzać, czy informacja jest widoczna w rzeczywistym interfejsie, dostępna przed lub podczas interakcji oraz odporna na zmianę kanału. Dla treści potrzebne są dane o pochodzeniu, mechanizm oznaczenia i test jego zachowania po eksporcie lub przetworzeniu. Sama deklaracja w regulaminie może nie odpowiadać sposobowi, w jaki użytkownik doświadcza systemu.

Ustal obowiązki dla GPAI i zależności dostawców

Organizacja korzystająca z modelu ogólnego przeznaczenia potrzebuje dokumentacji dostawcy wystarczającej do zaprojektowania własnej kontroli. Powinna znać ograniczenia, warunki użycia, sposób zgłaszania incydentów, zmiany wersji, politykę danych i informacje potrzebne do dokumentacji downstream. Jeżeli sama udostępnia GPAI, musi ocenić obowiązki z art. 53, a dla modelu z ryzykiem systemowym także dodatkowe wymagania.

Kodeks postępowania dla GPAI opublikowano 10 lipca 2025 roku jako dobrowolne narzędzie wspierające zgodność w obszarach przejrzystości, prawa autorskiego oraz bezpieczeństwa. Podpisanie kodeksu nie zastępuje analizy zakresu produktu. Zakupy powinny zawierać prawa do informacji, logów, powiadomień o zmianach i dowodów testów, zamiast opierać się na marketingowej nazwie modelu.

Przygotuj systemy potencjalnie wysokiego ryzyka

Klasyfikacja wymaga sprawdzenia art. 6 oraz załączników I i III, w tym przeznaczenia w obszarach takich jak biometria, infrastruktura krytyczna, edukacja, zatrudnienie, usługi podstawowe, egzekwowanie prawa czy migracja. Nie wolno zakładać, że każde użycie w regulowanej branży jest wysokiego ryzyka ani że produkt niskiego ryzyka pozostanie nim po zmianie przeznaczenia.

Rozporządzenie (UE) 2026/1744 przesunęło stosowanie obowiązków z rozdziału III, sekcji 1–3: dla przypadków z art. 6 ust. 2 i załącznika III na 2 grudnia 2027, a dla systemów z art. 6 ust. 1 i załącznika I na 2 sierpnia 2028. To czas na przygotowanie zarządzania ryzykiem, governance danych, dokumentacji technicznej, logów, nadzoru człowieka, monitoringu po wdrożeniu i oceny zgodności. Odkładanie prac do ostatniego kwartału pozostawi zależności techniczne bez dowodu.

Osadź kontrolę w cyklu produktu

Klasyfikacja i pakiet dowodowy powinny być warunkiem wejścia do developmentu oraz wydania, odpowiednio do ryzyka. Zmiana modelu, danych, interfejsu, grupy użytkowników, automatyzowanego procesu lub dostawcy może zmienić ocenę. Pipeline wydania powinien rejestrować wersję, testy, zaakceptowane ograniczenia, właściciela oraz plan monitoringu.

Wysoki wynik benchmarku nie wystarczy. Potrzebne są testy w warunkach zbliżonych do użycia, przypadki osób dotkniętych wynikiem, mechanizm nadzoru, możliwość zakwestionowania rezultatu i sygnały nieprawidłowego działania. Incydentowy runbook musi obejmować szkodliwe wyniki, wyciek, drift, obejście nadzoru i niedostępność dostawcy, z możliwością zatrzymania lub wycofania systemu.

Mierz gotowość przez kompletność decyzji

Przydatne miary to: udział systemów z nazwanym właścicielem i przeznaczeniem, czas od zmiany do ponownej klasyfikacji, pokrycie ról właściwym AI literacy, udział wydań z kompletnym pakietem dowodowym, wiek otwartych ustaleń, czas obsługi incydentu i liczba zależności dostawców bez prawa do potrzebnych informacji. Każda luka powinna prowadzić do działania, akceptacji ryzyka albo ograniczenia użycia.

Komitet AI nie powinien zatwierdzać wszystkich drobnych zmian. Ma ustalić progi, rozstrzygać przypadki o wysokim wpływie i nadzorować wyjątki. Zespoły produktowe wykonują powtarzalne kontrole w codziennym procesie. Taki model pozwala przedstawić organowi nie tylko politykę, lecz łańcuch dowodów od klasyfikacji przez wydanie po monitoring i reakcję.