Od 2 sierpnia 2026 r. Komisja Europejska może egzekwować unijny AI Act wobec dostawców modeli AI ogólnego przeznaczenia, a nałożenie kar staje się możliwe, zgodnie z wytycznymi Komisji i jej harmonogramem wdrażania [1] [5]. Kilka dni wcześniej, 27 lipca, wszedł w życie omnibus cyfrowy dotyczący AI, rozporządzenie zmieniające, które przesunęło terminy dla systemów wysokiego ryzyka na grudzień 2027 r. i sierpień 2028 r. [3]. Dla organizacji, która wdraża duży model językowy (LLM) od zewnętrznego dostawcy, obowiązki dostawcy modelu i własne obowiązki podmiotu wdrażającego to dwie odrębne kwestie.
Tło
Przepisy AI Act dotyczące modeli AI ogólnego przeznaczenia zaczęły obowiązywać 2 sierpnia 2025 r. Wytyczne Komisji wymieniają obowiązki dostawcy modelu: dokumentację techniczną dla organów i Urzędu ds. AI, informacje dla dalszych twórców o możliwościach i ograniczeniach modelu, politykę w zakresie praw autorskich, publiczne podsumowanie treści użytych do trenowania oraz przedstawiciela w UE w przypadku dostawców mających siedzibę poza Unią [1]. Wytyczne uznają model za model ogólnego przeznaczenia, gdy był trenowany z użyciem ponad 10^23 operacji zmiennoprzecinkowych i potrafi generować język, obrazy z tekstu lub wideo z tekstu, przy czym określają ten próg jako orientacyjny. W przypadku modeli trenowanych z użyciem ponad 10^25 operacji domniemywa się ryzyko systemowe [1].
Co opisują źródła
FAQ Komisji podaje trzy daty: 2 sierpnia 2025 r., gdy obowiązki zaczynają obowiązywać z początkowym okresem dostosowawczym dla sygnatariuszy kodeksu praktyk; 2 sierpnia 2026 r., gdy rozpoczyna się pełne egzekwowanie z możliwością nałożenia kar; oraz 2 sierpnia 2027 r., do kiedy muszą się dostosować modele wprowadzone do obrotu przed rozpoczęciem stosowania przepisów [1]. Harmonogram AI Act Service Desk Komisji stwierdza, że egzekwowanie wobec modeli AI ogólnego przeznaczenia i w zakresie obowiązków przejrzystości rozpoczyna się 2 sierpnia 2026 r. [5]. Analiza kancelarii prawnej opublikowana 24 lipca 2026 r. opisuje wcześniejsze rozwiązanie jako roczny okres karencji dla sygnatariuszy kodeksu praktyk w zakresie AI ogólnego przeznaczenia, kończący się 2 sierpnia 2026 r. [2].
Omnibus cyfrowy jest już przyjęty, a nie tylko zaproponowany. Analiza kancelarii prawnej i notatka badawcza Cloud Security Alliance podają, że rozporządzenie (UE) 2026/1744 zostało opublikowane w Dzienniku Urzędowym 24 lipca 2026 r. i weszło w życie 27 lipca 2026 r. [3] [4]. Przesuwa ono datę stosowania przepisów do samodzielnych systemów wysokiego ryzyka z załącznika III z 2 sierpnia 2026 r. na 2 grudnia 2027 r., a do AI wbudowanej w produkty objęte sektorowym prawem bezpieczeństwa (załącznik I) na 2 sierpnia 2028 r. [2] [3]. Strona z harmonogramem Komisji podaje te same daty [5]. Pozostałe obowiązki zachowują pierwotny harmonogram, w tym obowiązki dostawców AI ogólnego przeznaczenia, zakazane praktyki obowiązujące od 2 lutego 2025 r. oraz obowiązki przejrzystości z art. 50. Systemy wprowadzone do obrotu przed 2 sierpnia 2026 r. mają czas do 2 grudnia 2026 r. na spełnienie obowiązku oznaczania syntetycznych treści w formacie nadającym się do odczytu maszynowego [3] [4].
W odniesieniu do podmiotów wdrażających źródła wskazują obowiązki, które wykraczają poza dokumentację dostawcy modelu. Dostawcy muszą informować, że dana osoba wchodzi w interakcję z systemem AI, i oznaczać treści wygenerowane przez AI; podmioty wdrażające muszą ujawniać deepfake'i, rozpoznawanie emocji i kategoryzację biometryczną, a obowiązki te obejmują organizacje prowadzące firmowe chatboty i narzędzia generatywnej AI [2]. Omnibus złagodził ogólny obowiązek zapewnienia kompetencji w zakresie AI do wymogu podjęcia środków zamiast osiągnięcia określonego poziomu kompetencji, natomiast podmioty stosujące systemy wysokiego ryzyka zachowują wymóg kompetencji z art. 26 ust. 2 [3].
Dokumentacja bezpieczeństwa dostawców dzieli zadania w podobny sposób. Model Microsoftu dla generatywnej AI opisuje trzy warstwy: platformę AI, aplikację AI i użycie AI. Stwierdza, że odpowiedzialność spoczywa zasadniczo na stronie wykonującej dane zadanie, a podział zmienia się w zależności od wdrożenia w modelu oprogramowania jako usługi, platformy jako usługi lub infrastruktury jako usługi [6]. Odrębny model dla autonomicznych agentów dodaje orkiestrację, narzędzia i działania oraz pamięć. Klient zachowuje w nim odpowiedzialność za dane, tożsamości, zatwierdzanie przez człowieka działań o dużym wpływie i rozliczalność za dopuszczalne użycie w każdym typie wdrożenia, a w przypadku agenta zbudowanego na zarządzanej platformie także za jego instrukcje, dobór narzędzi i uprawnienia dla poszczególnych narzędzi [7]. Microsoft określa swoje wytyczne jako poglądowe, a nie jako wniosek prawny [6]. Wpis na blogu Cloud Security Alliance z 2023 r. proponował ten sam układ dla generatywnej AI, z dostawcą usługi AI i użytkownikiem usługi AI, przy czym użytkownik odpowiada za pochodzenie danych, bezpieczeństwo aplikacji i kontrolę promptów [8].
Znaczenie dla organizacji
Egzekwowanie przepisów wobec dostawców modeli nie przenosi obowiązków organizacji wdrażającej na dostawcę. Dokumentacja dostawcy i informacje dla dalszych twórców stanowią dane wejściowe do własnej oceny podmiotu wdrażającego, obejmującej jego prompty, dane, uprawnienia narzędzi i obsługę wyników. Przeanalizowane źródła nie rozstrzygają, kiedy podmiot wdrażający, który dostraja model lub istotnie go modyfikuje, sam staje się dostawcą; w konkretnym przypadku należy to sprawdzić w wytycznych Komisji.
Zalecenia
- Sporządź wykaz każdego używanego LLM i agenta, jego dostawcy oraz typu wdrożenia (oprogramowanie, platforma lub hosting własny), ponieważ od tego zależy podział obowiązków.
- Zapisz, które obowiązki dokumentacja dostawcy przypisuje klientowi, i traktuj dokumenty dostawcy jako wskazówki, a nie umowę czy poradę prawną.
- Sprawdź, czy obowiązki przejrzystości z art. 50 dotyczą chatbotów lub generowanych treści publikowanych przez organizację.
- W przypadku agentów przejrzyj uprawnienia narzędzi, etapy zatwierdzania przez człowieka i rejestrowanie zdarzeń, które model Microsoftu pozostawia klientowi.
- Zapoznaj się z kursem FireAI University o ramach bezpieczeństwa AI i red teamingu oraz wpisem na blogu o współdzielonej odpowiedzialności za LLM.
Związek z FireAI
FireAI to zapora sieciowa dla jednego komputera Mac, a nie produkt do zapewniania zgodności. Nie ocenia obowiązków wynikających z AI Act, nie klasyfikuje systemów AI i niczego nie certyfikuje. Może natomiast pokazać sieciową stronę narzędzia LLM na Macu. Reguły dla aplikacji pozwalają ograniczyć aplikację AI lub asystenta programowania do potrzebnych mu celów, monit przy pierwszym połączeniu pyta, zanim nowa aplikacja połączy się z nieznanym celem, mapa świata pokazuje, dokąd trafia ruch aplikacji, a alerty wysyłania sygnalizują nagłe duże wysyłanie danych do jednego kraju. Wyłącznik awaryjny zatrzymuje nowe połączenia. FireAI nie odczytuje promptów ani odpowiedzi modelu i nie widzi, co agent robi wewnątrz aplikacji.
Ograniczenia
Strony FAQ i harmonogramu Komisji nie miały widocznej daty publikacji, a strona Komisji nie podaje wysokości kar. Streszczenia kancelarii prawnej i notatki badawczej są zgodne co do dat omnibusu, ale na potrzeby tego materiału nie otwierano samego tekstu z Dziennika Urzędowego. Strony Microsoftu to wytyczne dostawcy dotyczące jego własnych usług, a wpis Cloud Security Alliance jest propozycją z 2023 r., więc żaden z tych dokumentów nie ma mocy prawnej. Żadne z przeanalizowanych źródeł nie wyjaśnia, jak organy krajowe lub Urząd ds. AI będą w praktyce korzystać ze swoich uprawnień.
Wypróbuj FireAI od HisnLabs za darmo przez 17 dni.