Komunikat o przesunięciu AI Act dotyczy systemów wysokiego ryzyka. Obowiązki przejrzystości z art. 50 weszły w pierwotnym terminie, 2 sierpnia 2026, i to one, a nie odległe daty z 2027 roku, są dziś pracą do wykonania w produkcie.
dfzoo AI Institute wdraża obowiązki przejrzystości z art. 50 rozporządzenia (UE) 2024/1689 w produktach cyfrowych i w procesach publikacji treści. Obowiązki te stosuje się od 2 sierpnia 2026 i nie objęło ich przesunięcie terminów, które rozporządzenie (UE) 2026/1744 wprowadziło dla systemów wysokiego ryzyka z załącznika III oraz dla systemów AI w produktach regulowanych. Przekładamy trzy obowiązki na czynności inżynierskie: poinformowanie użytkownika, że rozmawia z systemem AI, maszynowo odczytywalne oznaczanie treści generowanych oraz widoczne oznaczanie materiałów zmienionych i deepfake'ów. Oznaczenia weryfikujemy na końcu ścieżki publikacji, nie w narzędziu, i zostawiamy test, który powtarza tę weryfikację przy każdym wdrożeniu. Wykładnię przepisu podpisuje radca prawny.
Rozporządzenie (UE) 2026/1744, znane jako omnibus cyfrowy, obowiązuje od 27 lipca 2026 i przesunęło terminy zgodności dla systemów wysokiego ryzyka. Obowiązków przejrzystości z art. 50 nie przesunęło.
| Obowiązek | Termin pierwotny | Stan po zmianie |
|---|---|---|
| Kompetencje w zakresie AI (art. 4) | 2 lutego 2025 | Bez zmian, obowiązuje |
| Obowiązki przejrzystości (art. 50) | 2 sierpnia 2026 | Bez zmian, obowiązuje |
| Systemy wysokiego ryzyka z załącznika III | 2 sierpnia 2026 | Przesunięte na 2 grudnia 2027 |
| Systemy AI w produktach regulowanych (załącznik I) | 2 sierpnia 2027 | Przesunięte na 2 sierpnia 2028 |
Art. 50 opisuje wynik, a nie implementację. Poniżej to, co z niego wynika dla produktu, w podziale na miejsce w interfejsie, sposób wykonania i sposób sprawdzenia.
| Obowiązek | Gdzie to widać w produkcie | Jak to wykonać | Jak to sprawdzić |
|---|---|---|---|
| Poinformowanie, że rozmówcą jest system AI | Pierwsza wiadomość w rozmowie i trwała etykieta w nagłówku okna, na każdym wejściu: widget, kanał głosowy, poczta, integracja u partnera | Komunikat w warstwie interfejsu, nie w regulaminie; treść jasna i zrozumiała dla osoby, która nie zna waszego produktu | Przejście przez wszystkie punkty wejścia ze zrzutem ekranu z każdego z nich |
| Maszynowo odczytywalne oznaczenie treści generowanej | Plik, który wychodzi z waszego systemu, i ten sam plik pobrany z produkcyjnego adresu | Content Credentials w standardzie C2PA albo metadane w polach XMP i IPTC, plus wpis w rejestrze wygenerowanych zasobów | Pobranie opublikowanego zasobu i odczyt oznaczenia czytnikiem, a nie sprawdzenie pliku w narzędziu |
| Widoczne oznaczenie materiału zmienionego i deepfake'a | Miejsce publikacji: strona, materiał wideo, post, kreacja reklamowa | Oznaczenie czytelne dla człowieka w samym materiale albo bezpośrednio przy nim, niezależne od metadanych | Przegląd opublikowanych materiałów kanał po kanale, z listą i datą |
To pytanie wraca na każdym wdrożeniu i nie ma na nie jednej odpowiedzi, bo część kanałów nie pozwala podmienić opublikowanego zasobu bez utraty adresu. Porządek pracy, który się sprawdza: najpierw inwentaryzacja, potem priorytety, na końcu decyzja zapisana tam, gdzie da się ją później odnaleźć.
Content Credentials i metadane XMP przeżywają eksport z narzędzia, ale kasuje je pierwszy element ścieżki publikacji, który przepuszcza plik przez konwersję: sieć dostarczania treści przerabiająca obrazy na WebP, kompresja w systemie zarządzania treścią albo upload na platformę społecznościową. Zespół widzi poprawnie oznaczony plik w repozytorium i uznaje temat za zamknięty, choć na produkcji oznaczenia już nie ma.
Sprawdzamy oznaczenie na końcu ścieżki, czyli na zasobie pobranym z produkcyjnego adresu, a nie na pliku w narzędziu. Zostawiamy test, który to powtarza przy każdym wdrożeniu i zgłasza brak. Tam, gdzie kanał kasuje metadane i nie da się tego zmienić, dokładamy oznaczenie widoczne dla człowieka i zapisujemy tę decyzję w rejestrze zasobów.
Informacja o tym, że użytkownik rozmawia z asystentem, trafia do polityki prywatności albo do dymku pod ikoną, bo zespół nie chce psuć pierwszego wrażenia. Wymóg mówi o informacji jasnej i zrozumiałej, podanej przy interakcji, więc miejsce publikacji tej informacji jest istotą sprawy, a nie szczegółem. Do tego najczęściej brakuje jej na tym wejściu, o którym nikt nie pamięta: w integracji u partnera, w kanale głosowym albo w automatycznej odpowiedzi na pocztę.
Umieszczamy komunikat w pierwszej wiadomości i jako trwałą etykietę w nagłówku rozmowy, a potem przechodzimy wszystkie wejścia do systemu, łącznie z tymi u partnerów. Każde wejście dostaje status i zrzut ekranu. Lista wejść zostaje u was, więc przy dodaniu nowego kanału wiadomo, co trzeba sprawdzić.
Zespół dokłada podpis w rogu obrazu i traktuje to jako spełnienie wymogu maszynowej odczytywalności. Napis przycina pierwszy kadr wideo albo miniatura w kanale społecznościowym, a maszynowo nikt go nie odczyta. W drugą stronę działa to tak samo: metadane w pliku nie są oznaczeniem widocznym dla człowieka, więc same nie wystarczą tam, gdzie wymagane jest oznaczenie widoczne.
Rozdzielamy dwa wymogi i realizujemy oba, każdy właściwą techniką: oznaczenie widoczne dla człowieka i oznaczenie odczytywalne maszynowo. Dla każdego typu treści, czyli obrazu, wideo, dźwięku i tekstu, spisujemy, co dokładnie ma się pojawić i gdzie. Wynik sprawdzamy czytnikiem C2PA i przeglądem wizualnym, osobno.
Dokumentacja dostawcy modelu mówi o znaku wodnym albo o Content Credentials, więc temat schodzi z listy. Tymczasem oznaczenie bywa zależne od wersji modelu, od trybu wywołania i od tego, którą końcówką API się posługujecie, a wasza integracja mogła powstać przed tą funkcją albo ją omijać. Deklaracja żyje w dokumentacji dostawcy, nie w waszym artefakcie.
Bierzemy próbki z waszej realnej integracji, per model i per tryb wywołania, i sprawdzamy, co faktycznie wychodzi. Różnice wobec dokumentacji zapisujemy z datą i wersją modelu i eskalujemy do dostawcy. To, czego dostawca nie dodaje, oznaczamy po waszej stronie, zamiast czekać na jego wydanie.
Nagłówek o przesunięciu AI Act dotyczy systemów wysokiego ryzyka, ale w planie pracy ląduje jako jedno zdanie: mamy czas do 2027 roku. Obowiązki przejrzystości weszły w terminie i dotyczą produktów, które są na rynku teraz. Plan powstaje na podstawie nagłówka, nie na podstawie tabeli terminów, a różnicę widać dopiero wtedy, gdy ktoś z zewnątrz zapyta o konkretną funkcję.
Dajemy tabelę terminów z podstawami prawnymi i mapujemy ją na wasze systemy: dla każdego z nich wprost piszemy, co obowiązuje teraz, a co dopiero będzie obowiązywać. Zestawienie mieści się na jednej stronie, więc da się je pokazać zarządowi bez tłumaczenia rozporządzenia. Aktualizujemy je przy każdej zmianie stanu prawnego.
Przechodzimy wszystkie wejścia do rozmowy z systemem oraz wszystkie kanały publikacji treści generowanych. Wynikiem jest lista ze statusem, a nie opinia.
Ustalamy, co ma stanąć w interfejsie i jak oznaczane są poszczególne typy treści, a potem wdrażamy zmiany razem z waszym zespołem.
Sprawdzamy oznaczenia na zasobach pobranych z produkcyjnych adresów, kanał po kanale, i zostawiamy test, który powtarza to przy każdym wdrożeniu.
Oddajemy specyfikację, rejestr i test. Wracamy przy podmianie modelu albo dostawcy, bo to moment, w którym oznaczenia najczęściej cicho znikają.
Art. 4 AI Act obowiązuje od 2 lutego 2025 i nie został przesunięty. Mapowanie ról na wymagany poziom kompetencji, program szkolenia per rola i artefakty, którymi udokumentujesz obowiązek.
Ustawa z 3 lipca 2026 (Dz.U. 2026 poz. 1003) weszła w życie 11 sierpnia 2026, a przepisy o kontroli i karach 28 października 2026. Jak zbudować rejestr systemów AI, który się obroni.
Inwentaryzacja systemów AI, klasyfikacja ryzyka i dokumentacja techniczna wymagana przez AI Act.
Niezależna ocena tego, jak dobrze wdrożone już rozwiązanie AI faktycznie wykonuje swoją pracę.
Certyfikacja przed wydaniem: observability, runbooki, ścieżki wycofania zmian, sygnały dyżuru.
Jesteśmy zespołem inżynierskim, nie kancelarią. Opisujemy tu, jak wykonać obowiązek w produkcie i jak sprawdzić, że działa, a nie jak brzmi jego wykładnia dla waszego przypadku. Granice zakresu, w szczególności przy tekstach publikowanych i przy wyjątkach z art. 50, rozstrzyga radca prawny: wasz albo nasz partner prawny. Daty i numery aktów podajemy razem ze źródłami.
Powiedz nam, na jakim etapie jesteście z obowiązkami przejrzystości z art. 50. Odpowiadamy w jeden dzień roboczy.