AI Omnibus obowiązuje: nowe terminy i zakazy AI Act

27 lipca 2026 roku unijny AI Omnibus wszedł w życie. Rozporządzenie (UE) 2026/1744 zmienia harmonogram i część mechanizmów AI Act, rozszerza wsparcie dla mniejszych firm, tworzy podstawę unijnego sandboxa regulacyjnego oraz doprecyzowuje nadzór nad systemami wysokiego ryzyka i modelami ogólnego przeznaczenia. Wprowadza też nowe przepisy dotyczące generowania niekonsensualnych materiałów intymnych i materiałów seksualnego wykorzystywania dzieci.

Najważniejsza rzecz dla firmy: wejście w życie nie oznacza, że każdy nowy przepis jest od dziś stosowany w pełnym zakresie. Część terminów została przesunięta na 2027 i 2028 rok, a niektóre nowe zakazy mają datę stosowania 2 grudnia 2026 roku. Zespół compliance powinien pracować na konkretnej osi czasu, a nie na ogólnym haśle „AI Act odroczony”.

Poniższa analiza opiera się na komunikacie Komisji Europejskiej i tekście rozporządzenia 2026/1744 w EUR-Lex. To materiał informacyjny o skutkach technicznych i organizacyjnych, nie indywidualna porada prawna.

Co zmieniło się 27 lipca

Komisja przedstawia AI Omnibus jako uproszczenie administracyjne, które ma zachować zabezpieczenia dla bezpieczeństwa i praw podstawowych. Najbardziej widoczne zmiany dotyczą pięciu obszarów:

nowych terminów dla wymagań systemów wysokiego ryzyka;
proporcjonalnych ułatwień dla small mid-cap companies, nie tylko klasycznych MŚP;
rozszerzenia sandboxów i testowania pod nadzorem;
doprecyzowania zakazanych zastosowań generatywnej AI;
zmian w nadzorze, rejestracji, AI literacy i post-market monitoring.

To nie jest uchylenie AI Act. Obowiązujące już elementy pozostają częścią reżimu, a nowe rozporządzenie zmienia poszczególne artykuły, daty i mechanizmy. Firma nadal musi znać swoją rolę — provider, deployer, importer, distributor albo product manufacturer — oraz klasyfikować każdy przypadek użycia.

Nowe terminy dla systemów wysokiego ryzyka

Wymagania z sekcji 1–3 rozdziału III AI Act będą stosowane według zmienionej osi czasu:

od 2 grudnia 2027 r. dla systemów uznanych za high-risk na podstawie art. 6 ust. 2 i załącznika III;
od 2 sierpnia 2028 r. dla systemów high-risk z art. 6 ust. 1 i załącznika I, czyli związanych z produktami regulowanymi.

W pierwszej grupie znajdują się kategorie opisane funkcją i obszarem użycia, na przykład wybrane systemy biometryczne, zatrudnienie, edukacja, dostęp do usług czy wymiar sprawiedliwości — dokładny zakres zawsze wymaga sprawdzenia aktualnego załącznika i zastosowania. Druga grupa obejmuje AI jako produkt lub komponent bezpieczeństwa produktu podlegającego wymienionemu prawu harmonizacyjnemu.

Przesunięcie terminu nie jest zgodą na rozpoczęcie projektu bez kontroli. Dokumentacja danych, zarządzanie ryzykiem, logowanie, nadzór człowieka, odporność i cyberbezpieczeństwo powstają w architekturze. Dodanie ich tuż przed oceną zgodności może wymagać zmiany modelu, pipeline’u i interfejsu.

AI literacy: uproszczenie nie oznacza braku kompetencji

Komisja wskazuje, że wcześniejszy obowiązek AI literacy dla firm został uproszczony, a większa rola w promowaniu kompetencji przechodzi na Komisję i państwa członkowskie. Nie należy interpretować tego jako dowodu, że szkolenia użytkowników stały się zbędne.

Jeżeli pracownik może przekazać dane osobowe do modelu, zatwierdzić decyzję high-risk lub uruchomić agenta z narzędziami, organizacja potrzebuje udokumentowanych kompetencji jako kontroli ryzyka. Zakres szkolenia powinien wynikać z roli:

zwykły użytkownik zna politykę danych i ograniczenia wyniku;
reviewer rozumie kryteria błędu, bias i wymagane dowody;
administrator kontroluje dostęp, logi, modele i integracje;
właściciel biznesowy odpowiada za cel, mierniki i eskalację;
zespół bezpieczeństwa testuje nadużycia, prompt injection i granice narzędzi.

Dowodem nie musi być masowy certyfikat z identycznym kursem. Lepszy jest rejestr ról, materiałów, testów wiedzy i uprawnień przyznanych po spełnieniu kryterium.

Ułatwienia dla SMC i regulatory sandbox

AI Omnibus rozszerza część proporcjonalnych mechanizmów z MŚP na small mid-cap companies. Ma to ograniczyć obciążenie rosnących firm, które przekroczyły próg MŚP, lecz nadal nie dysponują zasobami największych dostawców.

Rozporządzenie rozwija również dostęp do sandboxów regulacyjnych i wprowadza sandbox na poziomie UE. Sandbox nie jest strefą bez prawa. Powinien umożliwiać testowanie pod nadzorem, z ustalonym celem, zakresem danych, kryterium wyjścia i ochroną osób, których dotyczy system.

Dla zespołu technicznego dobre zgłoszenie do sandboxa powinno zawierać:

opis modelu, wersji i dostawcy;
mapę przepływu danych oraz podstawę ich wykorzystania;
klasyfikację ryzyka i scenariusze nadużycia;
plan ewaluacji, red teamingu i nadzoru człowieka;
sposób obsługi incydentu i wyłączenia systemu;
kryteria przejścia z testu do produkcji.

Brak takiej dokumentacji utrudnia zarówno rozmowę z regulatorem, jak i bezpieczne wdrożenie.

Nowe zakazy materiałów intymnych i CSAM

AI Omnibus dodaje do katalogu zakazanych praktyk przepisy dotyczące systemów generujących lub manipulujących niekonsensualnym materiałem intymnym oraz materiałem seksualnego wykorzystywania dzieci, w tym materiałem syntetycznym. Zgodnie ze zmienionym harmonogramem nowe elementy art. 5 mają być stosowane od 2 grudnia 2026 roku.

Pełny tekst jest bardziej precyzyjny niż skrót „zakaz nudification apps”. Po stronie dostawcy zakaz obejmuje systemy przeznaczone do takiego celu oraz przypadki, w których generowanie jest rozsądnie przewidywalnym i powtarzalnym rezultatem, a dostawca nie wdrożył rozsądnych, adekwatnych zabezpieczeń. Rozporządzenie wymienia jako przykłady między innymi czyszczenie danych, refusal training, bezpieczny projekt promptów, kontrolę wyjścia, klasyfikację treści, ograniczenia użycia, wykrywanie nadużyć i notice-and-action.

Po stronie deployera zakazane ma być używanie systemu w celu wytworzenia takiego materiału, w tym obchodzenie zabezpieczeń. Tekst zawiera też rozróżnienia dotyczące zgody, zastosowań medycznych, realistycznego przedstawienia i manipulacji istniejącym materiałem. To obszar, w którym ocena prawna konkretnego produktu jest konieczna.

Technicznie dostawca powinien móc wykazać nie tylko obecność filtra, lecz jego skuteczność wobec znanych i rozsądnie przewidywalnych prób obejścia. Potrzebne są testy red-team, rejestrowanie nadużyć zgodne z prawem ochrony danych, proces zgłoszeń oraz aktualizacja zabezpieczeń po wykryciu bypassu.

Dane szczególnej kategorii i wykrywanie biasu

Nowelizacja rozszerza podstawę umożliwiającą — w ściśle określonych warunkach i z zabezpieczeniami — przetwarzanie szczególnych kategorii danych osobowych w celu wykrywania i korygowania biasu. Nie jest to ogólne pozwolenie na gromadzenie większej liczby danych.

Zespół powinien udokumentować konieczność, minimalizację, dostęp, retencję, rozdzielenie zbiorów i metodę oceny. Dane użyte do audytu fairness nie powinny automatycznie trafiać do cech modelu produkcyjnego. Potrzebna jest kontrola, czy proces korygowania biasu nie tworzy nowego naruszenia prywatności lub innej dyskryminacji.

W praktyce przydatne są pseudonimizacja, środowisko izolowane, kontrola eksportu, statystyki minimalnej liczebności i przegląd wyników przez interdyscyplinarny zespół.

Znakowanie treści syntetycznych

Rozporządzenie doprecyzowuje okres przejściowy dla dostawców systemów generujących syntetyczny tekst, obraz, audio lub wideo. Systemy wprowadzone na rynek przed 2 sierpnia 2026 roku mają podjąć kroki w celu zgodności z art. 50 ust. 2 do 2 grudnia 2026 roku.

Firma powinna potraktować znakowanie jako cały łańcuch, nie pojedynczy watermark:

metadane muszą przetrwać typowe operacje eksportu i publikacji;
mechanizm powinien być maszynowo czytelny;
log generacji powinien pozwalać zbadać nadużycie;
interfejs musi informować użytkownika o ograniczeniach;
integracje i pośrednicy nie powinny usuwać oznaczenia;
test powinien obejmować kompresję, kadrowanie, transkodowanie i ponowną publikację.

Jeżeli znacznik łatwo znika po pierwszym przetworzeniu, formalna obecność funkcji nie zapewnia realnej identyfikowalności.

Rejestracja, nadzór i nowe kody technologiczne

Komisja wskazuje uproszczenie rejestracji systemów uznanych za wyłączone z kategorii wysokiego ryzyka. Firma nadal potrzebuje dowodu, dlaczego zastosowała wyłączenie. Krótka etykieta „not high-risk” bez oceny celu, użytkowników i skutków jest trudna do obrony podczas kontroli.

AI Office otrzymuje szersze kompetencje wobec wybranych systemów, w tym rozwiązań opartych na modelach ogólnego przeznaczenia i osadzonych w dużych platformach lub wyszukiwarkach. Dla dostawców oznacza to większe znaczenie spójnego pakietu dowodowego: model card, opis danych, wyniki ewaluacji, incydenty, ograniczenia i proces post-market monitoring.

Nowy załącznik XIV wprowadza kody dla zakresu notyfikacji jednostek oceniających zgodność. Wśród kodów technologicznych znalazły się generatywna AI i systemy oparte na GPAI, a także oddzielna kategoria emerging AI obejmująca Agentic AI. Sam kod nie klasyfikuje automatycznie systemu jako high-risk; porządkuje zakres kompetencji jednostek i pokazuje, że systemy agentowe są traktowane jako odrębny problem oceny.

Co powinna zrobić firma w Polsce

Najlepszym rezultatem 27 lipca nie jest przesunięcie wszystkich zadań na 2027 rok, lecz aktualizacja rejestru i roadmapy. Minimum obejmuje:

Inwentaryzację wszystkich modeli, agentów i funkcji AI, również kupowanych w SaaS.
Mapowanie roli prawnej dla każdego zastosowania i umowy z dostawcą.
Ponowną klasyfikację ryzyka według zmienionego tekstu i aktualnych załączników.
Aktualizację osi czasu z terminami 2 grudnia 2026, 2 grudnia 2027 i 2 sierpnia 2028.
Plan dowodowy dla danych, ewaluacji, logów, nadzoru i cyberbezpieczeństwa.
Przegląd generowania treści pod kątem zabezpieczeń, zgody, CSAM i niekonsensualnych materiałów intymnych.
Test oznaczeń syntetycznych w pełnym pipeline publikacji.
Przegląd umów dotyczących zmiany modelu, incydentów, audytu i usuwania danych.
Mechanizm post-market monitoring oparty na realnych metrykach, nie wyłącznie rocznym checkboxie.
Ścieżkę wycofania, która pozwala zatrzymać funkcję AI bez zatrzymania podstawowego procesu firmy.

Wcześniejszy przewodnik po obowiązkach AI Act w 2026 roku pozostaje użytecznym opisem ról i kontroli, ale jego harmonogram należy czytać razem z dzisiejszym, obowiązującym tekstem AI Omnibus.

Cyberbezpieczeństwo pozostaje wymaganiem projektowym

Przesunięty termin nie zmienia faktu, że system AI może zostać zaatakowany przed datą stosowania obowiązków. Prompt injection, zatrucie RAG, przejęcie tokenu agenta, wyciek danych i manipulacja modelem są ryzykiem operacyjnym już teraz.

Program zgodności powinien korzystać z tych samych dowodów co program bezpieczeństwa: threat modelu, testów penetracyjnych, logów, zarządzania podatnościami, kontroli dostępu i ćwiczeń incydentowych. Dokumentacja stworzona wyłącznie dla audytora szybko rozchodzi się z produkcją.

Przy systemach agentowych szczególnie ważne są osobne tożsamości, minimalne uprawnienia narzędzi, limity działania i zatwierdzenie akcji wysokiego wpływu. Kategoria Agentic AI w nowym załączniku pokazuje kierunek regulacyjny, ale techniczna odpowiedzialność pozostaje po stronie organizacji, która daje agentowi dostęp.

Wniosek

AI Omnibus wszedł w życie 27 lipca 2026 roku i realnie zmienia plan wdrożenia AI Act. Daje więcej czasu dla części systemów wysokiego ryzyka i proporcjonalne wsparcie mniejszym organizacjom, ale jednocześnie dodaje nowe zakazy, doprecyzowuje nadzór oraz wymaga przygotowania do terminów przypadających już 2 grudnia 2026 roku.

Firma nie powinna mylić odroczenia z anulowaniem. Największą przewagę daje wykorzystanie dodatkowego czasu na dowody techniczne: rejestr systemów, ewaluację, kontrolę danych, bezpieczeństwo agentów, monitoring i plan wycofania. Tych elementów nie da się wiarygodnie dopisać tydzień przed oceną.

Breachroad pomaga połączyć wymagania AI Act z threat modelingiem, testami bezpieczeństwa AI i przeglądem architektury.

Źródła pierwotne: Komisja Europejska — AI Omnibus enters into force, EUR-Lex — Rozporządzenie (UE) 2026/1744, AI Act Service Desk — harmonogram wdrożenia.