Krótka odpowiedź

AI Act nie oznacza zakazu korzystania z ChatGPT, Copilota, generatorów treści ani automatyzacji opartych na modelach językowych. Nie oznacza też, że każda firma musi przeprowadzić formalną certyfikację każdego narzędzia AI. Rozporządzenie wprowadza model oparty na ryzyku: obowiązki zależą od tego, co system robi, na kogo wpływa, w jakim kontekście jest używany oraz jaką rolę pełni firma.

Najważniejsza zmiana jest organizacyjna. AI przestaje być wyłącznie funkcją techniczną lub eksperymentem zespołu. Przy tworzeniu, zakupie i udostępnianiu rozwiązania trzeba świadomie określić jego przeznaczenie, właściciela, dane, użytkowników, ograniczenia i sposób nadzoru. W praktyce elementy zgodności powinny wejść do procesu wytwarzania oprogramowania tak samo jak bezpieczeństwo, ochrona danych i testy jakości.

Firma, która tylko używa gotowego narzędzia, ma zwykle mniej obowiązków niż podmiot budujący system i udostępniający go pod własną marką. Nadal odpowiada jednak za własny sposób użycia: za dane wprowadzane przez pracowników, wybór zastosowania, dostęp użytkowników, kontrolę wyniku oraz konsekwencje decyzji podejmowanych z pomocą AI.

Ten materiał opisuje praktyczne skutki regulacji dla przedsiębiorstw. Nie zastępuje analizy prawnej konkretnego systemu, zwłaszcza w obszarach zatrudnienia, finansów, edukacji, ochrony zdrowia, usług publicznych lub biometrii.

Co faktycznie zmienia się w 2026 roku

AI Act jest stosowany etapami. Obowiązek podejmowania działań na rzecz odpowiednich kompetencji personelu w zakresie AI obowiązuje już od 2 lutego 2025 roku. Od 2 sierpnia 2026 roku zaczyna być stosowana większość pozostałych przepisów, w tym obowiązki przejrzystości dotyczące określonych systemów oraz mechanizmy nadzoru i egzekwowania.

Po zmianach przyjętych w 2026 roku terminy dla systemów wysokiego ryzyka zostały przesunięte. Wymagania dla samodzielnych systemów wysokiego ryzyka z załącznika III mają być stosowane od 2 grudnia 2027 roku, a dla systemów wysokiego ryzyka będących częścią regulowanych produktów od 2 sierpnia 2028 roku. Aktualne daty publikuje oficjalny harmonogram Komisji Europejskiej. Zmiany opisuje również Ministerstwo Cyfryzacji.

Przesunięcie części terminów nie jest jednak powodem, aby odłożyć przygotowania. Inwentaryzacja systemów, polityka użycia, kompetencje zespołu, przejrzystość i bezpieczne przetwarzanie danych są potrzebne już teraz. Co więcej, system projektowany w 2026 roku może pozostawać w użyciu w chwili, gdy zaczną obowiązywać dalsze wymagania. Dodawanie dokumentacji, logów i nadzoru po zakończeniu projektu jest zwykle droższe niż uwzględnienie ich w architekturze od początku.

Najpierw ustal rolę firmy

W AI Act odpowiedzialność nie wynika wyłącznie z tego, kto napisał kod. Ważne jest, kto rozwija system, pod czyją nazwą jest on udostępniany, kto określa jego przeznaczenie i kto wykorzystuje go w praktyce. Artykuł 3 AI Act rozróżnia między innymi dostawcę, podmiot stosujący, importera i dystrybutora.

Sytuacja Typowa rola firmy Praktyczne znaczenie
Pracownicy korzystają z gotowego asystenta AI do szkiców i podsumowań Podmiot stosujący Firma odpowiada za zasady użycia, dane, dostęp, kompetencje i kontrolę wyniku
Firma buduje własny system na API zewnętrznego modelu i uruchamia go pod swoją nazwą Możliwa rola dostawcy systemu, a także podmiotu stosującego Trzeba ocenić cały system, nie tylko bazowy model i deklaracje jego producenta
Software house tworzy rozwiązanie publikowane pod marką klienta Rola zależy od umowy i sposobu wprowadzenia systemu do użytku Podział odpowiedzialności, dokumentacji i utrzymania powinien być ustalony przed wdrożeniem
Firma udostępnia na rynku UE system dostawcy spoza Unii Możliwa rola importera lub dystrybutora Pojawiają się obowiązki związane z łańcuchem dostaw i weryfikacją systemu
Firma znacząco modyfikuje system wysokiego ryzyka albo zmienia jego przeznaczenie Może stać się dostawcą Zmiana funkcji biznesowej może zmienić również kwalifikację prawną

Szczególnie istotna jest ostatnia sytuacja. Zgodnie z artykułem 25 podmiot może przejąć obowiązki dostawcy systemu wysokiego ryzyka, jeśli umieszcza na nim własną nazwę, dokonuje istotnej modyfikacji albo zmienia przeznaczenie w taki sposób, że system staje się systemem wysokiego ryzyka.

Dlatego samo zdanie „korzystamy tylko z API” nie rozstrzyga odpowiedzialności. API dostarcza model lub funkcję, ale firma może zbudować wokół niej kompletny system: ustala dane wejściowe, reguły, interfejs, użytkowników, integracje i działania wykonywane na podstawie odpowiedzi. Ocenie podlega rzeczywiste zastosowanie całego rozwiązania.

Jak AI Act zmienia proces wytwarzania rozwiązania

Najgorszym momentem na analizę zgodności jest tydzień przed produkcyjnym uruchomieniem. Wtedy przeznaczenie systemu, przepływ danych i architektura są już ustalone, a zmiana mechanizmu logowania, kontroli człowieka lub komunikatów dla użytkownika może wymagać przebudowy produktu.

1. Analiza zastosowania przed rozpoczęciem prac

Opis funkcji „chatbot AI” jest zbyt ogólny. Na początku projektu trzeba określić:

  • jaki problem system rozwiązuje i jaka jest jego zamierzona funkcja;
  • kto z niego korzysta i kogo dotyczą jego wyniki;
  • czy system tylko podpowiada, czy wpływa na decyzję;
  • jakie dane otrzymuje i z jakich źródeł korzysta;
  • czy wynik może wywołać skutek prawny, finansowy, zawodowy lub edukacyjny;
  • kto odpowiada za zatwierdzenie, odrzucenie i eskalację wyniku.

Ten opis staje się podstawą klasyfikacji ryzyka, dokumentacji, testów i instrukcji użytkowania. Powinien być wersjonowany razem z produktem. Jeżeli przeznaczenie systemu się zmienia, ocenę należy wykonać ponownie.

2. Klasyfikacja ryzyka i sprawdzenie zakazanych zastosowań

Nie każde AI jest systemem wysokiego ryzyka. Proste streszczanie wewnętrznych dokumentów, wyszukiwanie wiedzy czy przygotowywanie szkicu wiadomości zwykle ma inny profil niż system oceniający kandydatów, dostęp do edukacji albo uprawnienie do ważnej usługi.

System wysokiego ryzyka może wynikać z powiązania z regulowanym produktem albo z zastosowania wymienionego w załączniku III. Artykuł 6 przewiduje też wyjątki dla niektórych zadań proceduralnych, przygotowawczych lub wspierających wcześniejszą ocenę człowieka. Nie można więc poprawnie sklasyfikować systemu tylko na podstawie użytego modelu.

Osobnym krokiem jest sprawdzenie praktyk zakazanych. Dotyczy to między innymi określonych form manipulacji, scoringu społecznego oraz niektórych zastosowań biometrii i rozpoznawania emocji. Taki przegląd powinien odbyć się przed rozpoczęciem implementacji, a nie dopiero przy odbiorze.

3. Projektowanie nadzoru i bezpiecznych granic działania

Hasło „człowiek w pętli” nie wystarczy. Trzeba zaprojektować, co człowiek faktycznie widzi, jakie ma uprawnienia i czy może skutecznie zakwestionować wynik. Osoba zatwierdzająca powinna otrzymać kontekst, źródła i informację o ograniczeniach systemu, a nie tylko gotową rekomendację z przyciskiem „zaakceptuj”.

W systemie obsługi klienta AI może przygotować szkic, ale wysyłka odpowiedzi dotyczącej reklamacji lub indywidualnych warunków powinna wymagać akceptacji. W procesie rekrutacyjnym wynik AI nie powinien stawać się automatycznym odrzuceniem bez realnej, kompetentnej oceny człowieka.

Ważne są również techniczne granice: limity działań, role użytkowników, blokowanie danych wrażliwych, zasady eskalacji, możliwość zatrzymania systemu oraz rozdzielenie środowiska testowego i produkcyjnego.

4. Testy wykraczające poza poprawną odpowiedź

Tradycyjny test funkcjonalny sprawdza, czy po podaniu danych system zwraca oczekiwany wynik. W rozwiązaniu AI wynik może być zmienny, dlatego potrzebny jest szerszy zestaw testów:

  • jakość odpowiedzi na typowych i granicznych przypadkach;
  • zachowanie przy brakujących lub sprzecznych danych;
  • halucynacje i odpowiedzi bez oparcia w źródłach;
  • nierówne wyniki dla różnych grup użytkowników;
  • ujawnienie danych poufnych lub osobowych;
  • odporność na prompt injection i manipulację treścią dokumentów;
  • poprawność odmowy oraz przekazania sprawy człowiekowi;
  • działanie po zmianie modelu, promptu lub bazy wiedzy.

Testy powinny mieć kryteria akceptacji. Stwierdzenie, że system „zwykle odpowiada dobrze”, nie wystarczy do decyzji produkcyjnej.

5. Dokumentacja wydania i monitoring po uruchomieniu

W chwili wdrożenia firma powinna wiedzieć, jaka wersja modelu, promptów, źródeł i reguł została uruchomiona. Potrzebne są instrukcje dla użytkowników, znane ograniczenia, właściciel biznesowy, osoba odpowiedzialna technicznie oraz procedura obsługi błędów i incydentów.

Po uruchomieniu należy monitorować nie tylko dostępność usługi, ale też jakość wyników: odsetek zaakceptowanych odpowiedzi, liczbę korekt, nieudane wyszukania źródeł, eskalacje, skargi i nietypowe zachowania. Zmiana modelu przez dostawcę może wpłynąć na system nawet wtedy, gdy kod aplikacji się nie zmienił.

Gotowe narzędzie AI nie oznacza gotowej zgodności

Zakup znanego produktu SaaS zmniejsza zakres prac technicznych, ale nie przenosi całej odpowiedzialności na producenta. Dostawca odpowiada za własny system i informacje, które ma obowiązek przekazać. Firma wybiera jednak cel użycia, użytkowników, dane i proces, w którym pojawia się wynik.

Przed dopuszczeniem gotowego narzędzia warto sprawdzić:

  • czy dane klientów i pracowników mogą być używane do trenowania modeli;
  • gdzie dane są przetwarzane, jak długo są przechowywane i jak je usunąć;
  • czy dostępna jest umowa powierzenia danych i lista podwykonawców;
  • czy produkt oferuje konta organizacyjne, role, SSO i dzienniki aktywności;
  • czy administrator może ograniczyć funkcje i źródła danych;
  • czy dostawca informuje o zmianach modeli oraz warunków usługi;
  • czy można eksportować historię, obsługiwać incydenty i wykazać sposób użycia;
  • jakie ograniczenia i przeznaczenie opisano w dokumentacji produktu.

Potrzebna jest również prosta polityka dla pracowników. Powinna wyjaśniać, z jakich narzędzi wolno korzystać, jakich danych nie wolno wklejać, które wyniki wymagają weryfikacji i gdzie zgłosić błąd. Zakaz używania wszystkiego zazwyczaj spycha AI do niekontrolowanych, prywatnych kont. Lepszy jest zatwierdzony zestaw narzędzi i jasne reguły.

Wymóg kompetencji AI nie oznacza identycznego szkolenia dla całej organizacji. Artykuł 4 AI Act każe uwzględnić wiedzę, doświadczenie, kontekst użycia i osoby, na które system oddziałuje. Innego przygotowania potrzebuje pracownik tworzący szkice marketingowe, innego administrator integracji, a jeszcze innego osoba zatwierdzająca rekomendacje dotyczące kandydatów.

Własna aplikacja oparta na API oznacza większą kontrolę i większą odpowiedzialność

Integracja modelu przez API pozwala kontrolować interfejs, źródła, uprawnienia, logi i moment wykonania działania. Dzięki temu łatwiej zbudować rozwiązanie dopasowane do procesu. Jednocześnie firma lub producent aplikacji nie może ograniczyć oceny do pytania, czy dostawca modelu deklaruje zgodność z AI Act.

To warstwa aplikacyjna decyduje, czy wynik jest tylko podpowiedzią, czy automatycznie zmienia status w CRM, wysyła wiadomość, klasyfikuje klienta albo odrzuca dokument. Zespół tworzący rozwiązanie powinien więc dokumentować nie tylko model, ale cały przepływ: dane wejściowe, źródła kontekstu, prompty, reguły, integracje, wynik i dalsze działania.

Umowa między zamawiającym a wykonawcą powinna jasno określać:

  • kto definiuje przeznaczenie i zatwierdza przypadki użycia;
  • kto dostarcza oraz weryfikuje dane i dokumenty;
  • kto wykonuje testy biznesowe i akceptuje poziom jakości;
  • kto utrzymuje logi, dokumentację i historię zmian;
  • kto monitoruje dostawcę modelu oraz reaguje na aktualizacje;
  • kto obsługuje incydenty i komunikację z użytkownikami;
  • co dzieje się po zakończeniu współpracy lub wycofaniu modelu.

Taki podział nie służy wyłącznie formalnej zgodności. Zapobiega sytuacji, w której system działa produkcyjnie, ale nikt nie jest właścicielem jego jakości i ryzyka.

Przejrzystość: kiedy trzeba powiedzieć o użyciu AI

Od 2 sierpnia 2026 roku zaczynają być stosowane obowiązki przejrzystości z artykułu 50 AI Act. Dostawca systemu przeznaczonego do bezpośredniej interakcji z człowiekiem powinien zaprojektować go tak, aby użytkownik wiedział, że rozmawia z AI, chyba że jest to oczywiste w danych okolicznościach.

Przepisy obejmują również techniczne oznaczanie określonych treści generowanych lub zmienianych przez AI, informowanie o działaniu systemów rozpoznawania emocji lub kategoryzacji biometrycznej oraz ujawnianie deepfake’ów. Dla tekstów publikowanych w celu informowania o sprawach interesu publicznego przewidziano obowiązek ujawnienia użycia AI, ale również wyjątek związany z kontrolą redakcyjną i odpowiedzialnością człowieka za publikację.

Nie oznacza to obowiązku dodawania etykiety „wygenerowano przez AI” do każdego wewnętrznego streszczenia czy roboczej wiadomości. Trzeba ocenić rodzaj treści, sposób publikacji i właściwy przepis. W produkcie warto jednak od początku przewidzieć miejsce na komunikat, metadane i informację o ograniczeniach. Dzięki temu obowiązek przejrzystości nie będzie później wymagał przebudowy interfejsu.

Pięć przykładów i ich realne konsekwencje

Asystent do wewnętrznych dokumentów

Najważniejsze są kontrola dostępu, aktualność źródeł, logowanie zapytań i zasada niewykorzystywania odpowiedzi bez weryfikacji tam, gdzie wpływ jest istotny. Zespół powinien wiedzieć, że płynna odpowiedź nie jest gwarancją poprawności.

Chatbot na stronie firmy

Użytkownik powinien otrzymać jasną informację, że rozmawia z AI. Potrzebna jest ścieżka przejścia do człowieka, ograniczenie zakresu odpowiedzi, zasady przetwarzania danych oraz testy zapytań prowadzących do nieuprawnionych obietnic lub ujawnienia informacji.

Selekcja kandydatów

Systemy wykorzystywane do rekrutacji mogą znaleźć się w obszarze wysokiego ryzyka. Potrzebne są szczególnie ostrożne zasady danych, nadzoru człowieka, jakości i niedyskryminacji. Gdy właściwe przepisy zaczną być stosowane, podmiot używający takiego systemu będzie musiał między innymi działać zgodnie z instrukcją, zapewnić kompetentny nadzór i monitorować pracę systemu. Zakres tych obowiązków opisuje artykuł 26.

Czego AI Act nie zastępuje

Zgodność z AI Act nie oznacza automatycznej zgodności z RODO, prawem pracy, ochroną konsumentów, prawem autorskim ani przepisami sektorowymi. Te regulacje działają równolegle.

Jeżeli system przetwarza dane osobowe, nadal trzeba określić podstawę, cel, zakres i czas przetwarzania. Jeśli wspiera decyzje wobec pracowników lub klientów, znaczenie mogą mieć przepisy o zautomatyzowanym podejmowaniu decyzji, obowiązki informacyjne oraz możliwość zakwestionowania wyniku. Wklejenie tajemnicy przedsiębiorstwa do niezatwierdzonego narzędzia może natomiast być poważnym incydentem niezależnie od klasyfikacji systemu w AI Act.

Checklista przed uruchomieniem rozwiązania AI

  • Czy opisaliśmy konkretne przeznaczenie systemu?
  • Czy ustaliliśmy rolę firmy i dostawców w łańcuchu rozwiązania?
  • Czy sprawdziliśmy praktyki zakazane i potencjalne zastosowania wysokiego ryzyka?
  • Czy znamy źródła danych, zasady retencji i warunki dostawcy modelu?
  • Czy użytkownik wie, kiedy ma do czynienia z AI?
  • Czy nadzór człowieka jest realny, a nie tylko formalny?
  • Czy system potrafi odmówić, eskalować i bezpiecznie się zatrzymać?
  • Czy testy obejmują błędy, nierówne wyniki, dane poufne i manipulację wejściem?
  • Czy potrafimy wskazać wersję modelu, promptów i źródeł działającą w produkcji?
  • Czy mamy właściciela monitoringu, jakości i incydentów?
  • Czy pracownicy otrzymali instrukcję i szkolenie adekwatne do swojej roli?
  • Czy ponowimy ocenę po zmianie przeznaczenia, modelu lub zakresu integracji?

Jak podejść do wdrożenia bez nadmiernej biurokracji

Każdy element zgodności powinien wspierać konkretną decyzję projektową. Rejestr zastosowań ustala właścicieli, opis przeznaczenia wyznacza zakres testów, logi pomagają znaleźć błędy, a instrukcja określa granice zaufania.

W Sorix.tech rozpoczynamy projekt AI od procesu biznesowego, danych i wpływu na użytkownika. Następnie projektujemy kontrolę dostępu, źródła, nadzór człowieka, testy i monitoring. Zewnętrzny model traktujemy jako jeden z komponentów, a nie jako gwarancję jakości całego rozwiązania.

Takie podejście pozwala rozwijać AI etapami. Najpierw system podpowiada, później przygotowuje szkic, następnie wykonuje działanie po zatwierdzeniu, a dopiero w dobrze przetestowanych i niskiego ryzyka przypadkach działa automatycznie. Dzięki temu zgodność nie blokuje wdrożenia, lecz wyznacza bezpieczny sposób zwiększania jego zakresu.

Podsumowanie

AI Act zmienia przede wszystkim sposób zarządzania rozwiązaniami AI. Firma powinna wiedzieć, z jakich systemów korzysta, w jakim celu, na jakich danych, pod czyją odpowiedzialnością i z jakim wpływem na ludzi. Zakup gotowego narzędzia nie zwalnia z odpowiedzialności za jego użycie, a wykorzystanie zewnętrznego API nie wyklucza roli dostawcy własnego systemu.

W procesie wytwarzania oznacza to wcześniejszą klasyfikację zastosowania, projektowanie przejrzystości i nadzoru, szersze testy, dokumentowanie wersji oraz monitoring po uruchomieniu. W procesie zakupowym oznacza ocenę warunków dostawcy, danych, kontroli administracyjnych i możliwości audytu.

Nie każde zastosowanie AI jest systemem wysokiego ryzyka i nie każde wymaga formalnej oceny zgodności. Każde zawodowe zastosowanie powinno być jednak świadome, przypisane do właściciela i objęte regułami adekwatnymi do rzeczywistych konsekwencji. To nie tylko wymóg regulacyjny. To fundament rozwiązania, któremu firma i jej klienci mogą zaufać.

Oficjalne źródła