Streszczenie AI
Polskie firmy przechodzą od „testowania” sztucznej inteligencji do systemowego wdrażania, a ponad 70 % z nich już podejmuje działania z ram AI Act. Główne bariery to niepewność regulacyjna i pracochłonność zmian w procesach, co sprawia, że coraz częściej wybierają lokalne lub prywatne chmury oraz architekturę RAG, by zachować kontrolę danych. W praktyce kluczowe jest równoległe zarządzanie ryzykiem AI, zgodnością z RODO i przygotowanie pełnego rejestru modeli, co pozwoli błyskawicznie odpowiedzieć na nadchodzące wymogi prawne.
Spis treści:
Polskie firmy wchodzą w etap, w którym wdrażanie sztucznej inteligencji nie jest już wyłącznie eksperymentem technologicznym. Coraz większe znaczenie mają zarządzanie ryzykiem, bezpieczeństwo danych, zgodność z AI Act oraz architektura pozwalająca kontrolować sposób przetwarzania informacji. Dane z trzeciej edycji badania EY pokazują, że ponad 70% średnich i dużych firm w Polsce podjęło działania związane z dostosowaniem do AI Act, a równolegle rośnie zainteresowanie modelami, które można uruchamiać lokalnie lub w kontrolowanym środowisku chmurowym.
Kluczowe liczby z badania
Trzecia edycja badania EY „Jak polskie firmy wdrażają AI” została przeprowadzona w ostatnim kwartale 2025 roku na grupie 499 polskich przedsiębiorstw. 45% badanych firm reprezentowało sektor produkcji, 33% usługi, a 22% handel. 56% respondentów stanowiły firmy średniej wielkości, a 44% duże organizacje.
Badanie wykazało, że 31% firm rozpoczęło proces wdrażania wymagań AI Act, a kolejne 40% było w trakcie prac. Łącznie oznacza to, że ponad 70% organizacji podejmowało działania dostosowawcze. W porównaniu z poprzednią edycją udział firm, które rozpoczęły wdrożenie, zwiększył się z 29% do 31%, natomiast udział organizacji będących w trakcie prac wzrósł z 29% do 40%. Łączna zmiana wyniosła 13 punktów procentowych rok do roku.
Zmniejszył się jednocześnie odsetek firm, które miały dostosowanie do AI Act dopiero w planach — z 17% do 8%. 16% organizacji podjęło próbę wdrożenia, lecz później wstrzymało prace. Tylko 3% badanych uznało, że AI Act ich nie dotyczy.
Najważniejsze bariery nie ograniczają się do samej regulacji. 32% przedsiębiorstw wskazało ograniczenia i niepewność regulacyjną jako przeszkodę we wdrażaniu AI. 34% oceniło, że pełne dostosowanie będzie pracochłonne i wymusi zmiany w procesach wewnętrznych oraz biznesowych, a 23% przewidywało konieczność skorzystania z pomocy zewnętrznych ekspertów. EY wskazuje, że przed problemami compliance firmy częściej wymieniały obawy dotyczące bezpieczeństwa oraz trudności technologiczne.
Najbardziej zaawansowane branże
AI jest wdrażana przede wszystkim w obszarze IT. Znacznie rzadziej trafia do działów compliance oraz procesów prawno-proceduralnych — takie działania podjęło tylko 8% badanych firm, choć oznacza to wzrost o 3 punkty procentowe względem poprzedniego roku. Dysproporcja pokazuje, że wiele organizacji rozwija zastosowania AI szybciej niż mechanizmy zarządzania ryzykiem, kontroli i odpowiedzialności.
Sektory regulowane, w tym finanse, ubezpieczenia, produkcja, energetyka i ochrona zdrowia, mają szczególne powody, aby analizować wdrożenia lokalne oraz rozwiązania typu private cloud. W tych branżach istotna jest kontrola nad danymi, możliwością audytu, retencją informacji i integracją z systemami źródłowymi. Nie oznacza to jednak, że infrastruktura on-premise jest zawsze bezpieczniejsza lub automatycznie zgodna z prawem. O poziomie ochrony decydują również konfiguracja, zarządzanie dostępem, aktualizacje, monitoring, procedury reagowania i kompetencje zespołu.
W branżach o wysokiej wrażliwości danych lokalny model może ograniczyć ekspozycję informacji poza organizację, ale nie zastępuje klasyfikacji ryzyka, nadzoru człowieka ani kontroli bezpieczeństwa.
Lokalne wdrożenie może być uzasadnione przy analizie dokumentów, klasyfikacji zgłoszeń, kontroli jakości, wyszukiwaniu wiedzy w repozytoriach firmowych i automatyzacji procesów wewnętrznych. W przypadku decyzji dotyczących ludzi, kredytów, ubezpieczeń, zatrudnienia lub dostępu do usług podstawowych najpierw trzeba jednak ustalić, czy system nie należy do kategorii wysokiego ryzyka.
Aktualny harmonogram AI Act
Najważniejsza zmiana względem pierwotnej wersji artykułu wynika z wejścia w życie pakietu AI Omnibus 27 lipca 2026 roku. Nie można już pisać, że wszystkie główne obowiązki dotyczące systemów wysokiego ryzyka zaczną obowiązywać w sierpniu 2026 roku. Harmonogram jest etapowy, a część terminów została przesunięta.
Termin | Najważniejsze zastosowanie |
|---|---|
| 2 lutego 2025 | Zakazy określonych praktyk AI oraz obowiązek zapewnienia kompetencji AI. |
| 2 sierpnia 2025 | Obowiązki dotyczące modeli ogólnego przeznaczenia, czyli GPAI. |
| 2 sierpnia 2026 | Stosowanie pozostałych przepisów w zakresie przewidzianym przez AI Act, rozpoczęcie uprawnień egzekucyjnych AI Office i organów krajowych oraz stosowanie obowiązków przejrzystości z art. 50. |
| 2 grudnia 2027 | Obowiązki dla systemów wysokiego ryzyka w określonych obszarach, między innymi zatrudnieniu, edukacji, usługach podstawowych, biometrii i infrastrukturze krytycznej. |
| 2 sierpnia 2028 | Obowiązki dla systemów wysokiego ryzyka wbudowanych w produkty objęte unijnymi przepisami bezpieczeństwa produktów. |
Przesunięcie terminu nie oznacza, że firmy mogą wstrzymać prace. Od 2 sierpnia 2026 roku działają mechanizmy nadzoru i egzekwowania AI Act, obowiązują przepisy dotyczące GPAI oraz wymogi przejrzystości. Organizacje powinny więc traktować okres przejściowy jako czas na przygotowanie inwentaryzacji, klasyfikacji systemów, dokumentacji, testów i procedur nadzoru.
Najczęstsze błędy compliance
Najpoważniejszym błędem jest traktowanie AI jak zwykłego narzędzia IT. Organizacja powinna wiedzieć, jakie systemy i modele są używane, przez które działy, na jakich danych, z jakim dostawcą oraz w jakim celu. Potrzebna jest klasyfikacja zastosowań według poziomu ryzyka, a także polityka określająca odpowiedzialność, zasady zatwierdzania i sposób monitorowania systemów.
Drugim błędem jest przesyłanie danych wrażliwych do zewnętrznych API bez wcześniejszej analizy podstawy prawnej, umowy z dostawcą, lokalizacji przetwarzania, retencji i wykorzystania danych do dalszego trenowania modeli. Dotyczy to między innymi danych kandydatów, ocen pracowniczych, informacji medycznych, danych finansowych i tajemnicy przedsiębiorstwa. Sam fakt, że usługa jest popularna lub oferuje tryb biznesowy, nie zwalnia firmy z obowiązków wynikających z RODO, przepisów sektorowych i zasad bezpieczeństwa.
Trzeci błąd to przekonanie, że lokalne uruchomienie modelu automatycznie rozwiązuje problem zgodności. Lokalizacja infrastruktury nie zmienia celu zastosowania systemu. Jeżeli model służy na przykład do selekcji kandydatów, oceny pracowników, oceny zdolności kredytowej lub ustalania ceny ubezpieczenia na życie albo zdrowotnego, system może podlegać szczególnym wymaganiom AI Act niezależnie od tego, czy działa na serwerze firmy, w prywatnej chmurze czy u zewnętrznego dostawcy.
Warto także pamiętać o zakazanych praktykach. AI Act zakazuje między innymi określonych form manipulacji, social scoringu, niektórych zastosowań biometrii, rozpoznawania emocji w miejscu pracy i szkołach oraz wybranych zastosowań predykcji przestępstw. Po zmianach wprowadzonych przez AI Omnibus zakaz obejmuje również systemy generujące niekonsensualne treści seksualne lub materiały przedstawiające seksualne wykorzystywanie dzieci; ten element zaczyna obowiązywać w grudniu 2026 roku.
RODO i AI Act razem
AI Act i RODO działają równolegle. AI Act koncentruje się na ryzykach związanych z systemem AI, a RODO reguluje przetwarzanie danych osobowych. Jedno rozporządzenie nie zastępuje drugiego, dlatego wdrożenie systemu może wymagać jednocześnie analizy ryzyka AI, oceny skutków dla ochrony danych, ustalenia podstawy prawnej, kontroli dostępu i procedur realizacji praw osób.
W systemach wysokiego ryzyka rejestrowanie zdarzeń służy identyfikowalności działania systemu. Logi powinny pozwalać odtworzyć istotne zdarzenia, ale nie powinny przechowywać większej ilości danych osobowych, niż jest to konieczne. Organizacja musi więc ustalić zakres logowania, pseudonimizację, okres retencji, uprawnienia dostępu oraz procedurę reagowania na incydenty.
Artykuł 27 AI Act przewiduje ocenę wpływu na prawa podstawowe, czyli FRIA, dla określonych wdrażających systemy wysokiego ryzyka. Obowiązek ten dotyczy między innymi organów publicznych, podmiotów świadczących usługi publiczne oraz wszystkich wdrażających systemy do oceny zdolności kredytowej osób fizycznych lub oceny ryzyka i ustalania cen ubezpieczeń na życie i zdrowie. FRIA uzupełnia, a nie zastępuje ocenę skutków dla ochrony danych na podstawie art. 35 RODO.
| Obszar | Wymóg lub ryzyko | Znaczenie dla lokalnego AI |
|---|---|---|
| AI Act | Klasyfikacja ryzyka, przejrzystość, nadzór, dokumentacja i rejestrowanie zdarzeń | Łatwiejsza kontrola infrastruktury, logów i integracji, ale obowiązki nadal pozostają po stronie właściwego podmiotu |
| RODO | Minimalizacja danych, podstawa prawna, ograniczenie retencji i bezpieczeństwo przetwarzania | Możliwość zaprojektowania pseudonimizacji i retencji zgodnie z politykami organizacji |
| FRIA | Ocena wpływu systemu wysokiego ryzyka na prawa podstawowe określonych grup osób | Łatwiejsze zebranie dowodów, logów i informacji o procesie, ale lokalny hosting nie znosi obowiązku oceny |
| Cyberbezpieczeństwo | Odporność, kontrola dostępu, aktualizacje, monitoring i reagowanie na incydenty | Pełna odpowiedzialność za zabezpieczenia pozostaje po stronie organizacji zarządzającej środowiskiem |
Lokalne modele w praktyce
Lokalny model open source może ograniczyć zależność od publicznego API, ułatwić kontrolę nad przepływem danych i zapewnić większą przewidywalność architektury. Nie oznacza to jednak, że rozwiązanie jest bezkosztowe. Firma musi zapewnić sprzęt, aktualizacje, monitoring, ochronę przed wyciekiem danych, kontrolę wersji modelu, testy jakości oraz procedury reagowania na błędne lub szkodliwe odpowiedzi.
Wybór konkretnego modelu powinien uwzględniać nie tylko jego nazwę, lecz także licencję, warunki użycia, możliwość komercyjnego wdrożenia, wymagania sprzętowe, wyniki testów dla języka polskiego i ryzyka związane z dostawcą. Modele określane jako open source mogą w praktyce różnić się zakresem dostępności kodu, wag, danych treningowych i dokumentacji.
Najlepszymi kandydatami do lokalnego wdrożenia są zadania o jasno zdefiniowanym zakresie, na przykład wyszukiwanie informacji w wewnętrznej bazie wiedzy, klasyfikacja dokumentów, ekstrakcja danych z faktur, analiza procedur lub obsługa zgłoszeń pracowników. Warto stosować architekturę RAG, w której model korzysta z kontrolowanego repozytorium dokumentów, a nie z niezweryfikowanej wiedzy generowanej bez kontekstu.
Przed uruchomieniem produkcyjnym należy wykonać testy dokładności, halucynacji, odporności na prompt injection, wycieku danych i nieuprawnionego dostępu. Trzeba również określić, kiedy odpowiedź modelu wymaga zatwierdzenia przez człowieka oraz jak użytkownik może zgłosić błąd lub zakwestionować wynik.
Praktyczny plan dla firmy
Najbardziej użyteczne podejście nie polega na wyborze między chmurą a serwerem lokalnym, lecz na dopasowaniu architektury do ryzyka konkretnego zastosowania. Firma może wdrożyć następujący proces:
- utworzyć rejestr wszystkich modeli, usług i funkcji AI używanych przez pracowników oraz aplikacje biznesowe;
- opisać cel każdego zastosowania, rodzaj danych, grupy osób dotkniętych działaniem systemu i poziom kontroli człowieka;
- zaklasyfikować zastosowania według AI Act i odseparować przypadki zakazane, wysokiego ryzyka, podlegające przejrzystości oraz niskiego ryzyka;
- wykonać analizę RODO, bezpieczeństwa i ryzyka dostawcy, a w wymaganych przypadkach przygotować FRIA;
- ustalić, które dane mogą być przetwarzane przez zewnętrzne API, a które powinny pozostać w środowisku lokalnym lub prywatnej chmurze;
- wdrożyć logowanie, kontrolę dostępu, retencję, testy okresowe, obsługę incydentów i proces wycofania modelu;
- szkolić pracowników z bezpiecznego i zgodnego z prawem korzystania z AI oraz dokumentować zakres tych działań.
Wnioski dla firm
Raport EY trafnie pokazuje, że polskie przedsiębiorstwa rozpoczęły szerokie przygotowania do AI Act, ale przedstawiony wcześniej harmonogram wymaga korekty. Po wejściu w życie AI Omnibus główne obowiązki dla systemów wysokiego ryzyka w określonych obszarach mają zastosowanie od 2 grudnia 2027 roku, a dla systemów wysokiego ryzyka wbudowanych w produkty — od 2 sierpnia 2028 roku. Jednocześnie od 2 sierpnia 2026 roku obowiązują lub są egzekwowane inne elementy regulacji, w tym przepisy o przejrzystości, zasady dotyczące GPAI oraz uprawnienia organów nadzorczych.
Lokalne modele open source mogą być ważnym elementem strategii bezpieczeństwa i suwerenności danych, ale nie stanowią samodzielnej strategii compliance. Organizacja powinna połączyć wybór architektury z inwentaryzacją systemów, klasyfikacją ryzyka, RODO, cyberbezpieczeństwem, dokumentacją i nadzorem człowieka.
Najbardziej racjonalna strategia to rozdzielenie przypadków użycia. Zadania o niskiej wrażliwości mogą korzystać z odpowiednio skonfigurowanych usług zewnętrznych, natomiast dane poufne, procesy krytyczne i zastosowania wymagające pełnej kontroli można kierować do środowiska lokalnego lub prywatnej chmury. Takie podejście nie eliminuje obowiązków prawnych, ale pozwala lepiej zarządzać ich realizacją i przygotować organizację na kolejne etapy egzekwowania AI Act.
