AI Act
Poznaj unijny Akt o Sztucznej Inteligencji – pierwsze na świecie kompleksowe rozporządzenie dotyczące AI. Dowiedz się, jak klasyfikuje systemy AI według poziomu...
10 min czytania
AI Act
EU Regulation
+4
Wprowadzenie
Dwa ogłoszenia z pierwszego tygodnia sierpnia 2026 roku wskazują na tę samą zmianę, ale z przeciwnych kierunków. 2 sierpnia przepisy Aktu o AI UE dotyczące przejrzystości stały się egzekwowalnym prawem, wymagając od każdego, kto wdraża chatbota, generator treści lub system rozpoznawania emocji, wyraźnego ujawnienia tego faktu pod groźbą grzywny do 15 milionów euro. Kilka dni później Google Cloud udostępnił ogólnie swój system Agent Identity — natywną warstwę uprawnień, która śledzi dokładnie, do czego agent AI ma dostęp, i rejestruje wszystko, co robi. Jeden to regulator wymuszający ujawnianie informacji. Drugi to platforma chmurowa sprzedająca odpowiedzialność jako funkcję. Oba zbiegają się w tym samym wniosku: agent AI, którego nikt nie może zidentyfikować, audytować ani pociągnąć do odpowiedzialności, nie jest gotowy do produkcji — niezależnie od tego, czy orzeknie to sąd.
Co zmieniło się 2 sierpnia
Obowiązki dotyczące przejrzystości wynikające z art. 50 Aktu o AI UE stały się powszechnie stosowane i egzekwowalne przez krajowe organy w całej UE 2 sierpnia 2026 roku. W praktyce obejmuje to cztery kwestie. Dostawcy muszą zapewnić, że ludzie są „wyraźnie informowani, że mają do czynienia z systemem AI, chyba że jest to oczywiste z kontekstu" — zasada ujawniania chatbotów. Dostawcy systemów generujących syntetyczne audio, obrazy, wideo lub tekst muszą oznaczać te wyniki w formacie czytelnym maszynowo i wykrywalnym. Każdy, kto wdraża system produkujący deepfake’i przedstawiające prawdziwe osoby, miejsca lub wydarzenia, musi to ujawnić. A podmioty wdrażające systemy rozpoznawania emocji lub kategoryzacji biometrycznej muszą informować osoby im poddawane i pozostawać w granicach unijnego prawa ochrony danych.
Żadne z tych wymogów nie jest nowe koncepcyjnie — Akt o AI został podpisany lata wcześniej. To, co zmieniło się 2 sierpnia, to fakt, że te konkretne obowiązki przestały być przyszłą datą na mapie drogowej zgodności i stały się czymś, co krajowe organy regulacyjne mogą dziś faktycznie egzekwować.
Gotowy na rozwój swojej firmy?
Rozpocznij bezpłatny okres próbny już dziś i zobacz rezultaty w ciągu kilku dni.
Co zostało przesunięte na 2027 i 2028 rok
Nie wszystko w Akcie zostało wdrożone zgodnie z harmonogramem. Poprzez Digital Omnibus on AI, podpisany 8 lipca 2026 roku, UE przesunęła w czasie wymogi dotyczące systemów wysokiego ryzyka. Samodzielne systemy objęte załącznikiem III — takie jak narzędzia do selekcji kandydatów do pracy, edukacja, egzekwowanie prawa, infrastruktura krytyczna — mają teraz czas do 2 grudnia 2027 roku. AI wbudowane w już regulowane produkty objęte załącznikiem I, takie jak wyroby medyczne czy windy, ma czas do 2 sierpnia 2028 roku.
To przesunięcie warto precyzyjnie zrozumieć, ponieważ łatwo je odczytać jako „Akt o AI został opóźniony". Tak nie jest. Lista praktyk zakazanych i obowiązki dotyczące ogólnych modeli AI pozostają bez zmian. Przesunięte zostały wyłącznie wymogi dotyczące klasyfikacji systemów wysokiego ryzyka — najcięższy obowiązek compliance, dla najwęższego wycinka systemów. Jeśli Twój agent rozmawia z użytkownikami lub generuje treści, jesteś w części prawa, która już obowiązuje.
Dlaczego przepisy o przejrzystości mają znaczenie
Wymóg przejrzystości brzmi skromnie w porównaniu z „systemem wysokiego ryzyka", ale to właśnie ta zasada będzie pierwszą, z którą zetknie się większość twórców agentów AI. Agent obsługi klienta, przepływ pracy generujący treści, asystent głosowy — wszystkie to systemy, które rozmawiają z ludźmi, co oznacza, że art. 50 ma zastosowanie niezależnie od tego, czy kiedykolwiek zostałyby sklasyfikowane jako wysokiego ryzyka. Prawidłowe wdrożenie nie jest skomplikowane: jasno powiedz, że użytkownik rozmawia z AI, oznaczaj wygenerowane treści i prowadź rejestry potwierdzające, że to zrobiłeś. Błędy w tym obszarze sprawiają, że raportowanie zgodności przestaje być papierkową robotą, a staje się ekspozycją prawną z realną kwotą.
Dołącz do naszego newslettera
Otrzymuj najnowsze wskazówki, trendy i oferty za darmo.
Google udostępnia Agent Identity
Odpowiedź Google Cloud na ten sam podstawowy problem nadeszła z zupełnie innego kierunku: infrastruktury, a nie prawa. Firma udostępniła ogólnie swoją platformę Gemini Enterprise Agent Platform z zestawem nowych prymitywów zarządzania agentami — Agent Memory Bank, Agent Runtime, Agent Gateway, Agent Registry, Agent Evaluation, a przede wszystkim Agent Identity.
Agent Identity to natywny typ poświadczeń IAM zbudowany na otwartych standardach, zaprojektowany specjalnie dla systemów autonomicznych, a nie zaadaptowany z kont użytkowników ludzkich. Wymusza dostęp z najmniejszymi uprawnieniami poprzez wiązanie uprawnień bezpośrednio ze środowiskiem wykonawczym agenta, co zamyka powszechną ścieżkę ataku, w której skradziony token agenta mógłby zostać użyty gdzie indziej. Generuje niezaprzeczalne dzienniki każdego działania agenta. I automatycznie zarządza cyklem życia poświadczeń, więc wycofany agent nie pozostawia uśpionego, zapomnianego zestawu uprawnień czekającego na niewłaściwe wykorzystanie.
Co faktycznie robi Agent Identity
Praktyczny efekt jest taki, że pytanie „który agent to zrobił i czy miał na to pozwolenie?" zyskuje definitywną odpowiedź, zamiast być domysłem rekonstruowanym z dzienników aplikacji po fakcie. Ma to znaczenie tym większe, im bardziej agenci przechodzą od odpowiadania na pytania do podejmowania działań — rezerwowania rzeczy, edytowania rekordów, przesyłania pieniędzy, usuwania plików. Podejście do bezpieczeństwa LLM, które martwi się tylko wstrzykiwaniem promptów do samego modelu, pomija całą tę powierzchnię: faktyczne uprawnienia agenta i to, co z nimi zrobił.
To również miejsce, w którym te dwa ogłoszenia łączą się bardziej, niż mogłoby się wydawać. Art. 50 pyta „czy ujawniłeś, że to AI?". Agent Identity odpowiada na pokrewne, ale odmienne pytanie: „czy możesz udowodnić, co dokładnie ten konkretny agent zrobił, z jakimi uprawnieniami i na czyje upoważnienie?". System, który potrafi czysto odpowiedzieć na drugie pytanie, znacznie łatwiej radzi sobie z pierwszym.
Dwie różne ścieżki, ten sam cel
Warto wprost nazwać ten wzorzec, ponieważ będzie się powtarzał. Regulatorzy zbiegają się w kierunku ujawniania informacji i odpowiedzialności z perspektywy ryzyka prawnego. Platformy chmurowe zbiegają się w kierunku tożsamości i uprawnień z perspektywy bezpieczeństwa i niezawodności. Frameworki dla agentów AI traktowały tożsamość jako kwestię drugorzędną — klucz API w zmiennej środowiskowej, współdzielony przez wszystkich agentów w infrastrukturze. Ten model nie wytrzymuje zderzenia ani z kontrolą regulacyjną, ani z prawdziwym incydentem bezpieczeństwa — i właśnie dlatego oba kierunki wskazują teraz to samo rozwiązanie: wiedzieć, który agent zrobił co, z jakim dostępem i móc to udowodnić.
Zespoły, które już eksperymentowały z przykładami agentów AI z życia wziętego — botami obsługi klienta, asystentami badawczymi, agentami kodującymi — odczują tę zmianę jako pierwsze, po prostu dlatego, że mają więcej agentów w produkcji generujących więcej działań do rozliczenia. To ten sam wzorzec, który widzieliśmy, gdy Claude Cowork i jego konkurenci przesunęli agentów z czatu jednosesyjnego do trwałych, wielodniowych zadań: więcej autonomii zawsze pojawia się krok przed narzędziami do jej zarządzania.
Budowanie agentów podlegających zarządzaniu od pierwszego dnia
Dostosowywanie śladów audytu do floty agentów, która nigdy nie była zaprojektowana do ich generowania, to żmudny projekt — każde działanie trzeba rekonstruować z logów, które akurat istniały, a w połowie przypadków one nie istnieją. Tańszą ścieżką jest budowanie na narzędziach, gdzie każdy krok agenta jest widoczny i możliwy do prześledzenia od samego początku, tak samo jak zarządzanie danymi traktuje pochodzenie danych jako kwestię pierwszorzędną, a nie coś, co dodaje się po incydencie.
To również miejsce, w którym tempo rozwoju podstawowych modeli ma znaczenie. Najnowsze wydania, takie jak framework Orchard od Microsoftu, oraz szersze przesunięcie w kierunku wyspecjalizowanych, audytowalnych agentów (zamiast jednego ogromnego modelu ogólnego przeznaczenia robiącego wszystko) sprawiają, że budowanie agentów, których zakres — a więc i uprawnienia — jest z założenia wąski i dobrze zdefiniowany, staje się bardziej praktyczne. Agent o wąskim zakresie jest z natury łatwiejszy do zarządzania niż ten, który teoretycznie może zrobić wszystko.
Podejście FlowHunt podąża tą samą logiką: jako platforma dla agentów AI, każda automatyzacja to widoczny przepływ, a nie czarna skrzynka, więc gdy pojawia się pytanie o zgodność — co ten agent zrobił, dlaczego i na jakim upoważnieniu — odpowiedź już czeka w przepływie pracy, zamiast być rekonstruowana przez zespół pod presją terminu.
Podsumowanie
Przepisy Aktu o AI UE dotyczące przejrzystości i system Agent Identity od Google nie koordynowały się ze sobą i rozwiązują nominalnie różne problemy — jeden to zgodność prawna, drugi to infrastruktura chmurowa. Ale pojawiły się w tym samym tygodniu, wskazując na tę samą podstawową prawdę: gdy agenci AI podejmują coraz bardziej autonomiczną i doniosłą pracę, stwierdzenie „tak naprawdę nie wiemy, co zrobił" przestaje być akceptowalną odpowiedzią, niezależnie od tego, czy pytającym jest regulator, czy własny zespół ds. bezpieczeństwa. Zespoły, które traktują tożsamość, ujawnianie informacji i audytowalność jako podstawowe wymagania już teraz — a nie funkcje do dodania później — będą tymi, które zarówno w kwestiach zgodności, jak i incydentów produkcyjnych odczują znacznie mniej bólu, gdy te się pojawią.
