Stan na 11 sierpnia 2026 r. Artykuł 50 Aktu o sztucznej inteligencji UE (transparencja dla określonych systemów, które komunikują się z ludźmi, generują treści syntetyczne, przeprowadzają rozpoznawanie emocji lub biometryczną klasyfikację, albo publikują deepfake) obowiązuje od 2 sierpnia 2026 r. Komisja Europejska rozpoczęła egzekwowanie tych wymogów transparentności. To obecnie obowiązujące prawo dla kodu aplikacji, a nie przyszły termin.
Większość wymogów dotyczących systemów wysokiego ryzyka z Rozdziału III (Artykuły 8 do 15: zarządzanie ryzykiem, zarządzanie danymi, dokumentacja techniczna, prowadzenie dokumentacji, instrukcje dla wdrażających, nadzór człowieka oraz dokładność, odporność i cyberbezpieczeństwo) nie weszła w życie 2 sierpnia 2026 r. Rozporządzenie (UE) 2026/1744, Cyfrowy Omnibus dotyczący AI, zostało opublikowane w Dzienniku Urzędowym 24 lipca 2026 r. i weszło w życie 27 lipca 2026 r. Przenosi ono stosowanie tych obowiązków wysokiego ryzyka na 2 grudnia 2027 r. dla systemów zaklasyfikowanych jako wysokiego ryzyka na podstawie Artykułu 6(2) i Załącznika III (samodzielne systemy, takie jak narzędzia do zatrudnienia, usługi podstawowe i narzędzia dla organów ścigania) oraz na 2 sierpnia 2028 r. dla systemów zaklasyfikowanych na podstawie Artykułu 6(1) i Załącznika I (AI zintegrowane w produktach już regulowanych innymi przepisami, takich jak wyroby medyczne lub maszyny). Plany, które nadal traktują sierpień 2026 r. jako ostateczny termin dla systemów wysokiego ryzyka, opierają się na dacie, która została już przesunięta.
Ten przewodnik jest przeznaczony dla programistów. Nie klasyfikuje on Twojego produktu jako wysokiego ryzyka, nie przeprowadza oceny zgodności ani nie zastępuje porady prawnej. Określa kalendarz, obowiązki z Artykułu 50, które obecnie pojawiają się jako tekst UI i metadane w diff, oraz jak odczyt zgodności w pull request wykrywa typowy błąd: czyszczenie, które usuwa ujawnienie.
Co obowiązuje teraz (Artykuł 50)
Artykuł 50 określa cztery główne kategorie obowiązków transparentności, podzielone między dostawców (organizacja, która buduje system) i wdrażających (organizacja, która go używa), z wyjątkami, w tym określonymi zastosowaniami przez organy ścigania. Każdy z nich zwykle pojawia się w działającym kodzie, a nie tylko w dokumentacji. Art. 50(1): system zaprojektowany przez dostawcę do bezpośredniej interakcji z osobą musi poinformować tę osobę, że rozmawia z AI, chyba że byłoby to oczywiste dla przeciętnie poinformowanej osoby; czat, asystent głosowy lub bot wsparcia wymaga ujawnienia, które ktoś rzeczywiście zobaczy. Art. 50(2): dostawca, którego system generuje syntetyczny dźwięk, obrazy, wideo lub tekst, musi oznaczać takie wyjście w formacie czytelnym dla maszyn, wykrywalnym jako generowane przez AI. Dla systemów już obecnych na rynku przed 2 sierpnia 2026 r. oznaczenie czytelne dla maszyn zgodnie z Art. 50(2) jest zwykle opisywane z okresem przejściowym do 2 grudnia 2026 r.; sprawdź dokładny tekst przejściowy w Omnibusie i wytycznych Komisji dla swojej linii produktów, ponieważ inne obowiązki z Artykułu 50 nie mają tego okresu. Art. 50(3): wdrażający, który prowadzi rozpoznawanie emocji lub biometryczną klasyfikację osób, musi poinformować te osoby, że to robi. Art. 50(4): wdrażający, który publikuje deepfake, wciąż musi ujawnić, że treść została sztucznie wygenerowana lub zmieniona; w przypadku treści stanowiącej część oczywiście artystycznego, twórczego, satyrycznego, fikcyjnego lub analogicznego dzieła, obowiązek ujawnienia ogranicza się do zrobienia tego w sposób, który nie utrudnia wyświetlania lub odbioru dzieła, a nie do jego zwolnienia. Oddzielnie, tekst generowany lub zmieniany przez AI, opublikowany w celu poinformowania opinii publicznej na temat sprawy publicznej, wymaga takiego samego ujawnienia, chyba że treść przeszła recenzję lub kontrolę redakcyjną, a osoba lub organizacja ponosi odpowiedzialność redakcyjną za jej opublikowanie.
Każdy z tych obowiązków jest zwykle implementowany jako element UI, zapis metadanych lub łańcuch tekstowy, co sprawia, że każdy z nich jest dokładnie tym, co refaktoryzacja może usunąć, bez sygnalizowania tego jako zmiany związanej z zgodnością. Od sierpnia 2026 r. takie usunięcie nie jest "wcześniejsze"; to luka w transparentności, która już obowiązuje.
Przykład praktyczny: czyszczenie UI usuwa ujawnienie
Załóżmy, że czatbot wsparcia został dostarczony z stałym tekstem pod pierwszą wiadomością: „Rozmawiasz z asystentem AI.” Późniejszy pull request przebudowuje widget, aby uzyskać czystszy stan pierwszego otwarcia, i usuwa ten tekst razem z trzema innymi fragmentami tekstu wprowadzającego, które projektant oznaczył jako zbędne. Przeróbka nie jest zła sama w sobie: widget wygląda czystej, a pozostałe trzy linijki były rzeczywiście wypełniaczami. Ale ujawnienie z Art. 50(1) zostało zaimplementowane jako jedna z tych linii, więc jego usunięcie usunęło ujawnienie, a nie tylko zbędny tekst. Nic w diff nie wygląda niezwykle: przycięcie tekstu w komponencie czatu nie jest czymś, co skaner błędów, test QA lub przegląd projektowy jest zaprojektowany do wykrycia.
To właśnie sprawdza przegląd zgodności w pull request: gdy zmiana usuwa lub osłabia element powiązany z kontrolą, którą zespół śledzi, należy odnieść się do Art. 50(1) bezpośrednio w pull request, zamiast dowiadywać się o tym z reklamacji lub kontaktu egzekucyjnego po fakcie.
Systemy wysokiego ryzyka zostały odroczone, nie odwołane
Przeniesienie wymogów dotyczących samodzielnych systemów wysokiego ryzyka z Załącznika III na grudzień 2027 r. nie ułatwia odpowiedzi na podstawowe pytanie, czy system kwalifikuje się jako wysokiego ryzyka na podstawie Załącznika III, później niż teraz. Kontrole za Artykułami 8 do 15 mają tę samą formę problemu „zmian w diff”, który hub frameworków już śledzi: osłabione łagodzenie ryzyka, usunięta sprawdzenie zarządzania danymi, usunięty nadzór człowieka jako martwego kodu. Budowanie tych nawyków teraz jest tańsze niż odkrywanie luk pod presją czasu w 2027 r.
Dwie inne grupy terminów nie zostały zmienione przez ten omnibus i już obowiązują: zakazane praktyki i obowiązki dotyczące znajomości AI od 2 lutego 2025 r. oraz przepisy dotyczące modeli GPAI i obowiązki zarządzania od 2 sierpnia 2025 r. Jeszcze jedna zmiana warta uwagi z tego samego pakietu: nowy zakaz dotyczący dostawców systemów przeznaczonych do generowania lub manipulowania niekonsensualnymi intymnymi materiałami lub materiałami dotyczącymi wykorzystywania seksualnego dzieci, albo systemów, dla których takie wyjście jest rozumnie przewidywalne i powtarzalne bez istotnych modyfikacji technicznych i bez odpowiednich zabezpieczeń, a także wdrażających, którzy używają systemu w tym celu, dodany do listy zakazanych praktyk Aktu i obowiązujący od 2 grudnia 2026 r.
Rola heygrc i granica uczciwości
heygrc jest zaprojektowany do sprawdzania każdego pull request względem wybranych frameworków, w tym Aktu o sztucznej inteligencji UE, gdy jest włączony, i wskazuje artykuł, którego zmiana dotyczy (np. Art. 50(1) w przypadku usuniętego ujawnienia w czacie). Znalezisko to jest komentarzem do przeglądu z dołączonym zapisaniem, aby autor i recenzent mogli podjąć decyzję z pełną wiedzą. Nie certyfikuje zgodności z Aktem o AI, nie klasyfikuje statusu wysokiego ryzyka, nie przeprowadza oceny zgodności, nie składa powiadomień do organów nadzoru ani nie zastępuje doradztwa prawnego. Zielony przegląd heygrc nie jest zatwierdzeniem przez Komisję; to wcześniejszy, oparte na artykule sygnał, że zmiana dotyczy czegoś, na czym zależą te programy.
Jeśli Twój zespół już używa narzędzia do sprawdzania błędów lub jakości w tym samym pull request, zachowaj je. Te narzędzia sprawdzają, czy kod jest poprawny i bezpieczny. Pytania dotyczące Artykułu 50 dotyczą tego, czy osoba wie, że rozmawia z AI, lub czy treści syntetyczne są nadal oznaczone. Powyższe czyszczenie może być czyste, poprawnie napisane i dobrze przetestowane, a mimo to pozostawić niespełniony Art. 50(1). Uruchom obie warstwy; żadna nie zastępuje drugiej.