AI Act wchodzi w kolejny etap stosowania. Od 2 sierpnia 2026 r. zaczęły być stosowane m.in. nowe wymagania dotyczące transparentności określonych systemów AI i treści generowanych lub modyfikowanych przez sztuczną inteligencję. Jednocześnie część terminów dotyczących systemów wysokiego ryzyka została przesunięta.

Dla firm wykorzystujących AI oznacza to jednak coś więcej niż konieczność przeczytania kolejnej regulacji. Jeżeli chatbot obsługuje klientów, model generuje treści, AI jest zintegrowane z istniejącą aplikacją albo agent wykonuje działania poprzez firmowe API, wymagania regulacyjne mogą przełożyć się na konkretne decyzje dotyczące UX, architektury, danych, integracji, testowania, monitoringu czy kontroli dostępu.
Najważniejszy wniosek dla CIO i CTO: AI Act nie jest wyłącznie tematem dla Legal i Compliance. Gdy wymagania regulacyjne trzeba wdrożyć w produkcyjnym rozwiązaniu, stają się również zadaniem dla architektury, developmentu, Data, UX/UI, QA, DevOps i zespołów odpowiedzialnych za utrzymanie systemu.
Stan prawny: 10.08.2026
Artykuł przedstawia technologiczną perspektywę przygotowania systemów AI i nie stanowi porady prawnej. Klasyfikację systemu oraz interpretację konkretnych obowiązków regulacyjnych należy potwierdzić z zespołem prawnym lub compliance.
AI Act 2026: co właściwie wydarzyło się 2 sierpnia?
AI Act od początku był wdrażany etapami. Dlatego stwierdzenie, że „AI Act zaczął obowiązywać 2 sierpnia 2026 r.”, jest zbyt dużym uproszczeniem.
Część przepisów stosowana była już wcześniej. Od 2 lutego 2025 r. stosowane są m.in. określone zakazy dotyczące niedopuszczalnych praktyk AI oraz wymagania związane z kompetencjami w zakresie sztucznej inteligencji.
2 sierpnia 2026 r. rozpoczęto natomiast stosowanie m.in. obowiązków transparentności wynikających z art. 50 AI Act. Komisja Europejska opublikowała również wytyczne dotyczące ich wdrażania.
Obowiązki transparentności dotyczą m.in.:
- informowania osoby, że prowadzi interakcję z systemem AI, jeżeli nie jest to dla niej oczywiste,
- technicznego oznaczania przez dostawców określonych treści generowanych lub modyfikowanych przez AI,
- ujawniania wykorzystania AI przy deepfake’ach,
- określonych przypadków publikowania tekstów wygenerowanych przez AI w celu informowania społeczeństwa o sprawach interesu publicznego,
- informowania osób poddawanych działaniu określonych systemów rozpoznawania emocji lub kategoryzacji biometrycznej.
Nie oznacza to jednak, że wszystkie wymagania AI Act zaczęły być stosowane jednocześnie.
A co z systemami AI wysokiego ryzyka?
Harmonogram stosowania części wymagań dotyczących systemów AI wysokiego ryzyka został przesunięty. Przepisy dotyczące systemów wysokiego ryzyka wymienionych w załączniku III AI Act mają być stosowane od 2 grudnia 2027 r. Obejmują one m.in. określone zastosowania AI w edukacji, zatrudnieniu, dostępie do podstawowych usług, wymiarze sprawiedliwości, migracji oraz niektórych działaniach organów publicznych.
W przypadku systemów AI wysokiego ryzyka będących elementami produktów objętych unijnymi przepisami dotyczącymi bezpieczeństwa termin rozpoczęcia stosowania odpowiednich wymagań został przesunięty na 2 sierpnia 2028 r.
AI Act – najważniejsze terminy
- 2 lutego 2025 r. – zaczęły być stosowane m.in. zakazy dotyczące określonych praktyk AI oraz wymagania związane z AI literacy.
- 2 sierpnia 2026 r. – zaczęły być stosowane m.in. obowiązki transparentności wynikające z art. 50 AI Act.
- 2 grudnia 2027 r. – termin rozpoczęcia stosowania przepisów dotyczących systemów AI wysokiego ryzyka wymienionych w załączniku III.
- 2 sierpnia 2028 r. – termin dla określonych systemów AI wysokiego ryzyka będących elementami produktów objętych unijnymi przepisami dotyczącymi bezpieczeństwa.
Praktyczny wniosek: późniejszy termin stosowania części obowiązków high-risk daje więcej czasu na przygotowanie, ale nie eliminuje potrzeby wcześniejszej inwentaryzacji systemów, klasyfikacji, gap analysis i zaplanowania zmian technicznych. Dostosowanie środowiska może wymagać zmian w architekturze, danych, dokumentacji, umowach z dostawcami, procesach developmentu, QA oraz monitoringu.
Aktualny harmonogram można zweryfikować w oficjalnych materiałach Ministerstwa Cyfryzacji oraz na oficjalnej osi czasu AI Act Service Desk.
A co zmienia się w Polsce?
Ustawa z 3 lipca 2026 r. o systemach sztucznej inteligencji została ogłoszona w Dzienniku Ustaw 27 lipca 2026 r. Zgodnie z jej art. 127 zasadniczo wchodzi w życie po upływie 14 dni od ogłoszenia, czyli 11 sierpnia 2026 r. Część przepisów ma odrębne terminy wejścia w życie.
Ustawa tworzy krajowe ramy nadzoru nad rynkiem AI, w tym Komisję Rozwoju i Bezpieczeństwa Sztucznej Inteligencji. Dla organizacji działających w Polsce sierpień 2026 r. jest więc dobrym momentem nie tylko na aktualizację dokumentacji prawnej, lecz również na techniczny przegląd sposobu, w jaki AI działa w organizacji.
Treść polskiej ustawy można zweryfikować bezpośrednio w Dzienniku Ustaw.
AI Act: jesteśmy dostawcą czy podmiotem stosującym AI?
Jedno z pierwszych pytań nie powinno brzmieć: „Jakie wymagania spełnia nasz model?”. Najpierw trzeba określić rolę organizacji wobec konkretnego systemu AI.
01 Tworzymy własny system AISprawdźmy, czy w danym scenariuszu organizacja pełni rolę dostawcy systemu. | 02 Korzystamy z systemu dostawcySprawdźmy obowiązki podmiotu stosującego oraz odpowiedzialność dostawcy rozwiązania. | 03 Modyfikujemy rozwiązanieJeżeli zmienia się system, jego przeznaczenie lub sposób użycia, warto ponownie zweryfikować rolę organizacji. |
AI Act rozróżnia m.in. dostawcę (provider) oraz podmiot stosujący (deployer). Dostawca to w uproszczeniu podmiot rozwijający system AI lub zlecający jego rozwój i wprowadzający go do obrotu lub oddający do użytku pod własną nazwą lub znakiem. Podmiot stosujący wykorzystuje natomiast system AI, nad którym sprawuje kontrolę, w ramach swojej działalności. Oficjalne definicje tych ról znajdują się w art. 3 AI Act.
Nie warto więc zakładać, że korzystanie z zewnętrznego modelu automatycznie oznacza brak odpowiedzialności po stronie organizacji. Z drugiej strony samo wykorzystanie API zewnętrznego modelu nie oznacza automatycznie, że firma staje się dostawcą.
Ważne: rolę należy określić dla konkretnego systemu, sposobu wdrożenia i wykorzystania. Przypadki graniczne należy potwierdzić z zespołem Legal lub Compliance.
Co AI Act oznacza dla istniejącej aplikacji lub systemu?
Regulację można analizować artykuł po artykule. Z perspektywy CIO lub CTO bardziej użyteczne jest jednak pytanie: które elementy naszego systemu trzeba sprawdzić?
Poniższa tabela nie jest checklistą zgodności prawnej. Pokazuje obszary technologiczne, które warto zweryfikować, kiedy wymagania regulacyjne mają zostać zaimplementowane w rzeczywistym produkcie.
| Obszar | Pytanie CIO/CTO | Co sprawdzić technicznie? |
|---|---|---|
| Interakcja z AI | Czy użytkownik wie, że komunikuje się z AI? | UI, UX, miejsce i moment disclosure, accessibility. |
| Generowanie treści | Czy potrafimy zachować informację o pochodzeniu outputu? | Metadata, machine-readable marking, content provenance, integracja z providerem. |
| Integracje | Gdzie AI może inicjować działania? | API, permissions, tool access, zakres uprawnień. |
| Dane | Z jakich danych korzysta system? | Źródła, access control, lineage, dane osobowe. |
| QA | Jak sprawdzamy zachowanie systemu? | Scenariusze testowe, regresja, AI evaluation, testy integracyjne. |
| Monitoring | Czy widzimy zachowanie systemu po wdrożeniu? | Observability, alerting, versioning, logowanie. |
| Human oversight | W którym miejscu człowiek może przejąć proces? | Workflow, escalation, approval, override. |
| Vendor management | Co zapewnia dostawca modelu lub systemu? | Dokumentacja, mechanizmy oznaczania, API capabilities, zasady aktualizacji. |
Wymóg regulacyjny ≠ konkretne narzędzie techniczne. AI Act nie nakazuje po prostu „wdrożyć observability” albo wykorzystać określonego frameworka QA. System musi jednak umożliwiać organizacji realizację wymagań właściwych dla danego use case’u.
Firma wdraża chatbot AI do obsługi klienta. Co trzeba sprawdzić?
Chatbot dobrze pokazuje różnicę między prostą integracją z modelem a rozwiązaniem gotowym do działania w środowisku enterprise.
Model → API → aplikacja → dane → użytkownik
Zgodnie z art. 50 AI Act, systemy AI przeznaczone do bezpośredniej interakcji z osobami powinny być projektowane tak, aby użytkownik został poinformowany, że komunikuje się z AI, chyba że jest to oczywiste z punktu widzenia odpowiednio poinformowanej, uważnej i rozsądnej osoby, z uwzględnieniem okoliczności i kontekstu użycia.
Informacja powinna zostać przekazana jasno i w sposób możliwy do odróżnienia od pozostałych komunikatów, najpóźniej przy pierwszej interakcji lub ekspozycji, z uwzględnieniem odpowiednich wymagań dostępności.
Z perspektywy produktu pytanie nie brzmi więc tylko:
„Czy dodaliśmy informację, że użytkownik rozmawia z AI?”
Trzeba również sprawdzić, jak transparentność wpływa na UX, accessibility, integracje, dane, kontrolę dostępu, QA, monitoring i możliwość przekazania sprawy człowiekowi.
| Obszar | Co warto sprawdzić? |
|---|---|
| UX/UI | Gdzie i kiedy pojawia się informacja o AI? Czy jest czytelna bez utrudniania wykonania zadania? |
| Accessibility | Czy informacja jest dostępna również dla użytkowników korzystających z technologii asystujących? |
| Integracje | Czy chatbot tylko odpowiada, czy również wykonuje działania w CRM, ERP lub innych systemach? |
| Permissions | Do jakich funkcji i danych ma dostęp agent lub model? |
| Dane | Czy system korzysta z CRM, historii klienta, dokumentacji lub danych osobowych? |
| QA | Co dzieje się przy błędnej odpowiedzi, nietypowym poleceniu lub próbie obejścia zasad? |
| Monitoring | Czy możemy wykryć pogorszenie jakości odpowiedzi lub problemy ze źródłami danych? |
| Human handover | Kiedy proces powinien przejąć człowiek i jak wygląda eskalacja? |
AI-generated content: problem nie kończy się na etykiecie
Drugi scenariusz dotyczy systemów generujących treści. Art. 50 AI Act przewiduje określone obowiązki transparentności związane m.in. z treściami syntetycznymi oraz generowanymi lub modyfikowanymi przez AI.
W przypadku dostawców systemów generujących syntetyczny tekst, obraz, audio lub wideo regulacja przewiduje, z określonymi wyjątkami, mechanizmy pozwalające na oznaczanie outputu w formacie nadającym się do odczytu maszynowego i wykrycie, że materiał został wygenerowany lub zmodyfikowany przez AI.
Z punktu widzenia zespołu technologicznego pojawia się jednak dodatkowe pytanie:
Czy informacja o pochodzeniu treści przetrwa cały pipeline przetwarzania?
Wyobraźmy sobie aplikację, która:
|
01 Generuje materiał przez model AI |
02 Pobiera go przez API |
03 Przetwarza lub konwertuje |
|
04 Zapisuje w DAM |
05 Przekazuje do CMS |
06 Publikuje w wielu kanałach |
Sam fakt, że provider modelu dostarcza odpowiedni mechanizm oznaczenia, nie oznacza automatycznie, że downstream pipeline zachowa tę informację.
Warto sprawdzić:
- jakie informacje otrzymujemy od dostawcy,
- czy API przekazuje potrzebne dane,
- co dzieje się z metadanymi po transformacji pliku,
- czy CMS lub DAM zachowuje provenance,
- czy konwersja albo optymalizacja nie usuwa istotnych informacji,
- czy możemy odtworzyć ścieżkę powstania konkretnego materiału.
Nie jest to uniwersalny katalog obowiązków wynikających z art. 50. To pytania architektoniczne i operacyjne, które pozwalają sprawdzić, czy własna infrastruktura nie powoduje utraty mechanizmów wykorzystywanych do realizacji konkretnych wymagań.
AI Act – techniczna checklista readiness dla CIO i CTO
Przegląd AI Act warto rozpocząć nie od analizy pojedynczych modeli, lecz od inwentaryzacji wykorzystania AI w całej organizacji.
- Czy wiemy, gdzie w organizacji działa AI?
- Czy dla każdego systemu określiliśmy rolę organizacji?
- Czy system komunikuje się bezpośrednio z użytkownikiem?
- Czy generuje lub modyfikuje tekst, obraz, audio albo wideo?
- Czy wiemy, jakie mechanizmy transparentności zapewnia dostawca?
- Czy system ma zaprojektowaną ścieżkę human override lub escalation?
- Czy możemy odtworzyć wersję modelu, konfiguracji, promptów i źródeł danych?
- Czy QA obejmuje zachowanie komponentów wykorzystujących AI?
- Czy monitoring umożliwia wykrywanie awarii, anomalii lub pogorszenia jakości?
- Czy zmiana modelu, providera, promptów lub integracji przechodzi kontrolowany release?
Ważne rozróżnienie: nie wszystkie powyższe elementy są obowiązkami wynikającymi bezpośrednio z art. 50 AI Act. Część to praktyki engineeringowe i governance, które pomagają organizacji zachować kontrolę nad systemem oraz technicznie realizować wymagania właściwe dla konkretnego use case’u.
Dlatego właściwa kolejność powinna wyglądać następująco:
System → rola organizacji → zastosowanie → właściwe wymagania → techniczny sposób realizacji
Dlaczego AI Act jest również problemem architektonicznym?
Regulacja sama w sobie nie wdroży transparentności ani kontroli nad systemem. Jeżeli określone wymaganie ma działać w produkcyjnym rozwiązaniu, często trzeba przełożyć je na kod, konfigurację, architekturę albo proces technologiczny.
| Potrzeba | Możliwy element techniczny |
|---|---|
| Transparentność wobec użytkownika | UI / UX / accessibility |
| Kontrola dostępu | Permissions / authorization / API |
| Pochodzenie contentu | Metadata / provenance |
| Kontrola człowieka | Workflow / approval / escalation |
| Analiza działania systemu | Logging / observability / monitoring |
| Kontrolowana aktualizacja AI | Versioning / CI/CD / release management |
| Weryfikacja zachowania | QA / AI evaluation / regression testing |
AI Act w środowisku enterprise wymaga współpracy:
Legal / Compliance + Security + Architecture + Development + Data + QA + DevOps + Product.
Dopiero wtedy organizacja może odpowiedzieć na dwa różne pytania:
- Czy wiemy, jakie wymagania dotyczą naszego rozwiązania?
- Czy system jest technicznie przygotowany, aby je realizować?
Mamy system AI już na produkcji. Co zrobić teraz?
Nie każdy działający system trzeba przebudować od zera. Lepszym podejściem jest przejście przez uporządkowany proces analizy i dostosowania.
| Etap | Co robimy? | Rezultat |
|---|---|---|
| 1. Inventory | Identyfikujemy systemy i funkcje wykorzystujące AI. | Mapa wykorzystania AI. |
| 2. Classify | Określamy przeznaczenie systemu, role, dane, użytkowników i działania. | Informacje potrzebne do klasyfikacji prawnej i technicznej. |
| 3. Gap analysis | Porównujemy wymagania z rzeczywistą architekturą i procesami. | Lista luk. |
| 4. Remediation | Projektujemy potrzebne zmiany w UI, API, danych, workflow i infrastrukturze. | Plan dostosowania systemu. |
| 5. Test | Testujemy rozwiązanie end-to-end. | Zweryfikowane zachowanie rozwiązania. |
| 6. Deploy | Wdrażamy zmiany w kontrolowanym procesie. | Produkcja z kontrolą wersji i zmian. |
| 7. Monitor | Monitorujemy model, integracje, dane i zachowanie systemu. | Ciągła kontrola rozwiązania. |
AI readiness nie jest jednorazowym projektem. Modele, API, dane, prompty i integrowane systemy zmieniają się po wdrożeniu. Dlatego governance, QA i monitoring powinny być elementem lifecycle’u rozwiązania.
Jak Edge One Solutions może wesprzeć techniczne przygotowanie systemu AI?
W Edge One Solutions patrzymy na wymagania związane z AI przede wszystkim z perspektywy technologicznej. Nie zastępujemy zespołów Legal i Compliance. Pomagamy natomiast odpowiedzieć na kolejne pytanie:
Co trzeba zmienić technologicznie, kiedy już wiemy, jakie wymagania ma spełnić rozwiązanie?
W zależności od architektury i przypadku użycia może to oznaczać zmianę aplikacji, rozwój integracji, uporządkowanie warstwy danych, przebudowę UX/UI, rozszerzenie testów, wdrożenie observability albo zmianę sposobu utrzymania systemu.
AI & DataArchitektura rozwiązania, przygotowanie danych oraz integracja komponentów AI z istniejącym środowiskiem. | Custom Development & IntegrationsZmiany w aplikacjach, API, procesach biznesowych i integracjach enterprise. |
UX/UI & QAProjektowanie transparentnej interakcji oraz testowanie zachowania systemu wykorzystującego AI. | DevOps & Managed ServicesVersioning, controlled release, monitoring, observability i utrzymanie rozwiązania po produkcji. |
Jeżeli organizacja dopiero ocenia swoją gotowość do wykorzystania AI, zobacz również naszą checklistę AI readiness oraz materiał dotyczący odpowiedzialnej sztucznej inteligencji w biznesie.
Czy Twój system AI jest technicznie gotowy na nowe wymagania?
Jeżeli wiesz już, jakie wymagania dotyczą Twojego rozwiązania, ale nie wiesz, jak przełożyć je na architekturę, integracje, UX, testy lub monitoring, możemy pomóc ocenić obecne środowisko i zaplanować potrzebne zmiany.
