Regulacje AI w Polsce kształtuje przede wszystkim Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 — AI Act[1], które weszło w życie 1 sierpnia 2024 r. i obowiązuje bezpośrednio we wszystkich państwach członkowskich bez osobnej implementacji krajowej. Harmonogram jest etapowy: pierwsze zakazy stosowania zabronionych praktyk AI zaczęły obowiązywać 2 lutego 2025 r., a główne wymogi dla systemów wysokiego ryzyka wchodzą w życie 2 sierpnia 2026 r. Równolegle obowiązuje RODO[2] — każdy system AI przetwarzający dane osobowe podlega obu rozporządzeniom jednocześnie.
Każda firma powinna zacząć od analizy ryzyka, zanim wybierze architekturę modelu i zdecyduje o zakresie danych. To nie jest zwykłe wdrożenie IT – tutaj trzeba równolegle ocenić wpływ systemu na decyzje, jakość danych oraz możliwość wyjaśnienia działania. Harmonogram projektu zmienia się już przed pierwszym treningiem modelu. Taki poródek pozwala uniknąć kosztownych poprawek na późniejszym etapie:
- Najpierw określ rolę swojej organizacji: czy jesteś dostawcą (opracowujesz lub zlecasz opracowanie modelu), wdrażającym (stosujesz system we własnej działalności) czy importerem lub dystrybutorem – każda rola niesie inne obowiązki z art. 16 i 26 AI Act[1].
- Ustal, czy system ma rekomendować, klasyfikować, przewidywać, czy może automatycznie sterować – od tego zależy klasyfikacja ryzyka i zakres obowiązków.
- Sprawdź, czy rozwiązanie operuje na danych osobowych i czy wymaga zgodności z RODO – ochrona danych od początku (privacy by design, art. 25 RODO[2]).
- Oceń ryzyko dla ludzi, procesu i odpowiedzialności prawnej, zanim model trafi na produkcję. Systemy z Załącznika III AI Act[1] są automatycznie uznawane za systemy wysokiego ryzyka.
- Zaprojektuj nadzór człowieka, rejestrację działań i procedury reagowania na błędy modelu zgodnie z art. 14 AI Act[1].
- Połącz wymagania prawne z testami technicznymi – dokumentacja techniczna (art. 11 AI Act[1]) powinna powstawać równolegle z produktem, nie po jego uruchomieniu.
Dobre wdrożenie integruje automatyzację ze zgodnością prawną, nie zostawiając poprawek na ostatnią chwilę.
Jak regulacje AI w Polsce wpływają na rozwój automatyzacji
Regulacje AI w Polsce przesuwają ciężar z szybkiego prototypowania na projektowanie odpowiedzialności – szczególnie w 2025–2026 r., gdy kolejne etapy AI Act wchodzą w życie. Firmy wdrażające uczenie maszynowe muszą już na etapie startu projektu łączyć architekturę techniczną z oceną ryzyka, ochroną danych, nadzorem człowieka i dokumentacją.
Harmonogram AI Act – kiedy co obowiązuje
AI Act nie wszedł w całości jednego dnia. Rozporządzenie 2024/1689 stosuje się stopniowo (art. 113)[1] – firmy mają czas na dostosowanie, ale też konkretne terminy, których przekroczenie grozi sankcjami:
| Data | Co wchodzi w życie | Kluczowe przepisy |
|---|---|---|
| 1 sierpnia 2024 r. | AI Act wchodzi w życie | Wejście w życie rozporządzenia 2024/1689 |
| 2 lutego 2025 r. | Zakaz zabronionych praktyk AI | Art. 5 – zakazy bezwzględne (m.in. scoring społeczny, manipulacja podprogowa, rozpoznawanie emocji w miejscu pracy, biometryczna klasyfikacja cech wrażliwych) |
| 2 sierpnia 2025 r. | Zasady dot. modeli AI ogólnego przeznaczenia (GPAI), zarządzanie i kary | Rozdział V (GPAI), Rozdział XII (kary – art. 99), wyznaczenie organów krajowych (art. 70) |
| 2 sierpnia 2026 r. | Główne obowiązki dla systemów wysokiego ryzyka | Rozdział III – dokumentacja techniczna (art. 11), logi (art. 12), nadzór człowieka (art. 14), zarządzanie ryzykiem (art. 9), ocena zgodności (art. 43) |
| 2 sierpnia 2027 r. | Systemy AI wbudowane w produkty sektorowe (Załącznik I) | Rozszerzone stosowanie dla AI w produktach regulowanych odrębnymi przepisami (maszyny, urządzenia medyczne, wyroby budowlane itd.) |
Urząd Ochrony Danych Osobowych (UODO)[3] pozostaje organem właściwym dla naruszeń w zakresie przetwarzania danych osobowych przez systemy AI. Europejski Urząd ds. Sztucznej Inteligencji (EU AI Office)[4] koordynuje stosowanie AI Act na poziomie unijnym i publikuje wytyczne dla podmiotów wdrażających.
Role w AI Act: dostawca, wdrażający, importer, dystrybutor
AI Act definiuje w art. 3[1] cztery kluczowe role, które decydują o zakresie obowiązków. Błąd w określeniu własnej roli to jeden z najczęstszych problemów na starcie projektu:
| Rola | Definicja (art. 3 AI Act) | Główne obowiązki | Kluczowe artykuły |
|---|---|---|---|
| Dostawca (provider) | Podmiot opracowujący lub zlecający opracowanie systemu AI i wprowadzający go do obrotu pod własną nazwą lub znakiem towarowym | Dokumentacja techniczna, system zarządzania ryzykiem, ocena zgodności, rejestracja w EU AI Database, oznakowanie CE dla systemów wysokiego ryzyka | Art. 16, art. 11, art. 43 |
| Wdrażający (deployer) | Podmiot stosujący system AI pod własną odpowiedzialnością w ramach działalności zawodowej lub gospodarczej | Zgodne z przeznaczeniem użycie systemu, zapewnienie nadzoru człowieka, ocena skutków dla praw podstawowych (podmioty publiczne), przechowywanie logów przez min. 6 miesięcy | Art. 26, art. 14, art. 27 |
| Importer | Podmiot mający siedzibę w UE, który wprowadza do obrotu system AI z kraju trzeciego | Weryfikacja zgodności z AI Act przed wprowadzeniem na rynek, sprawdzenie dokumentacji i oznakowania | Art. 23 |
| Dystrybutor | Podmiot udostępniający system AI na rynku UE (bez modyfikacji) | Weryfikacja oznakowania CE i aktualności dokumentacji przed dystrybucją | Art. 24 |
Ważne: wdrażający może przejąć obowiązki dostawcy, jeśli istotnie modyfikuje system AI lub stosuje go poza przeznaczeniem określonym przez dostawcę (art. 25 AI Act[1]). To szczególnie istotne przy dostosowywaniu gotowych modeli do własnych procesów produkcyjnych lub integracji z systemami ERP.
Zakazy bezwzględne – art. 5 AI Act
Od 2 lutego 2025 r. obowiązuje najważniejszy zakaz AI Act: lista praktyk całkowicie niedopuszczalnych[1]. Naruszenie któregokolwiek z nich grozi najsurowszą karą w całym rozporządzeniu. W środowisku przemysłowym i IoT szczególnie istotne są:
- Rozpoznawanie emocji w miejscu pracy i instytucjach edukacyjnych – zakaz dotyczy systemów wykrywających stan emocjonalny pracowników (np. kamer analizujących wyraz twarzy przy stanowiskach produkcyjnych), poza wąsko zdefiniowanymi wyjątkami bezpieczeństwa i medycznymi.
- Biometryczna klasyfikacja cech wrażliwych – zakaz stosowania AI do wnioskowania o rasie, przekonaniach politycznych, religii, orientacji seksualnej lub statusie związkowym pracowników na podstawie danych biometrycznych.
- Manipulacja podprogowa – zakaz systemów, które poprzez techniki podprogowe wpływają na zachowanie osoby w sposób dla niej nieświadomy, powodując lub mogąc powodować krzywdę.
- Scoring społeczny przez władze publiczne – zakaz klasyfikowania lub oceniania osób fizycznych przez organy publiczne na podstawie zachowań społecznych lub cech osobowych w sposób prowadzący do krzywdzącego lub dyskryminacyjnego traktowania.
- Masowe tworzenie baz danych twarzy – zakaz budowania lub rozbudowywania baz danych rozpoznawania twarzy z nieukierunkowanego scrapingu wizerunków z internetu lub kamer CCTV.
Sankcje – ile kosztuje nieprzestrzeganie AI Act
AI Act przewiduje trzypoziomowy system kar (art. 99)[1]. Wymiar sankcji zależy od rodzaju naruszenia:
| Rodzaj naruszenia | Maksymalna kara | Podstawa prawna |
|---|---|---|
| Naruszenie zakazów z art. 5 (zabronione praktyki AI) | 35 mln EUR lub 7% globalnego rocznego obrotu (wyższa z kwot) | Art. 99 ust. 3 |
| Naruszenie innych obowiązków AI Act (np. dokumentacja, logi, wymogi dla systemów wysokiego ryzyka) | 15 mln EUR lub 3% globalnego rocznego obrotu (wyższa z kwot) | Art. 99 ust. 4 |
| Przekazanie nieprawidłowych informacji organom nadzorczym lub jednostkom notyfikowanym | 7,5 mln EUR lub 1,5% globalnego rocznego obrotu (wyższa z kwot) | Art. 99 ust. 5 |
MŚP i startupy korzystają z korzystniejszej zasady obliczania kary: według art. 99 ust. 6 AI Act[1] kara nie może przekroczyć niższej z dwóch wartości (kwotowej lub procentowej). Dla mniejszych firm oznacza to realnie niższe maksimum sankcji. Dodatkowe ułatwienia dla MŚP opisuje art. 55 AI Act – patrz sekcja FAQ.
Jak AI Act zmienia moment decyzji o wdrożeniu
AI Act przesuwa w Polsce punkt startowy automatyzacji. Teraz ocena funkcji systemu następuje jeszcze przed zakupem modelu czy urządzenia. Dla producentów, integratorów i zespołów IoT to oznacza wcześniejsze pytania o konsekwencje błędów modelu, a nie tylko o skuteczność.
Środek ciężkości projektu przesuwa się: najpierw zespół ustala, czy system tylko wspiera operatora, czy ma realny wpływ na jakość produktu, bezpieczeństwo albo dostępność usługi. Dopiero później dobiera dane, interfejs i procedurę odbioru. Jeśli automatyzacja wchodzi w obszar wysokiego ryzyka (Załącznik III AI Act[1] wymienia m.in. systemy stosowane w zatrudnieniu i zarządzaniu pracownikami), dokumentacja i testy muszą być częścią definicji produktu, nie dodatkiem.
Zmienia się też sposób zakupu technologii. Zamawiający pyta już nie tylko o trafność modelu, ale także o aktualizacje, wersjonowanie i możliwość odtworzenia decyzji po błędzie. W przeciwieństwie do klasycznej automatyki opartej na sztywnych regułach, model uczący się może zmieniać wyniki pod wpływem danych – wymaga więc osobnego trybu odbioru i kontroli wersji.
Różnice między typami automatyzacji najlepiej widać w poniższym zestawieniu:
| Scenariusz automatyzacji | Główne pytanie regulacyjne | Etap projektu pod największą presją | Najczęstsza decyzja projektowa |
|---|---|---|---|
| Automatyka regułowa | Czy proces jest bezpieczny i przewidywalny? | Uruchomienie i serwis | Utrzymanie reguł oraz procedur awaryjnych |
| Aplikacja AI wspierająca decyzję | Czy użytkownik rozumie rekomendację modelu? (art. 13 AI Act – transparentność[1]) | Interfejs i akceptacja wyniku | Dodanie wyjaśnienia oraz ścieżki odrzucenia rekomendacji |
| System wizyjny na linii produkcyjnej | Czy błąd modelu wpływa na jakość, bezpieczeństwo lub prawa pracownika? (Załącznik III pkt 4 AI Act – zatrudnienie[1]) | Walidacja danych i odbiór produkcyjny | Ustalenie progu pewności oraz kontroli ręcznej wyjątków |
| Urządzenie IoT z modelem lokalnym | Gdzie powstają dane i kto kontroluje aktualizację modelu? | Architektura urządzenia i cykl serwisowy | Przetwarzanie na brzegu sieci (edge AI) oraz kontrola wersji modelu |
Wynik? Im bliżej model stoi codziennych decyzji operacyjnych, tym wcześniej regulacje wpływają na projekt, umowę i odbiór techniczny. AI Act zmienia więc nie samą technologię, lecz kolejność działań w całym wdrożeniu.
Dlaczego RODO wpływa na architekturę modeli i urządzeń
RODO zaczyna mieć znaczenie, gdy model przetwarza dane osobowe pracowników, klientów lub użytkowników urządzeń. Dla deweloperów aplikacji AI i systemów IoT architektura danych staje się elementem zgodności prawnej, nie tylko optymalizacją kosztów.
Kluczowa zasada wynika z art. 25 ust. 1 RODO[2], który nakłada obowiązek privacy by design:
Uwzględniając stan wiedzy technicznej, koszt wdrażania oraz charakter, zakres, kontekst i cele przetwarzania oraz ryzyko naruszenia praw lub wolności osób fizycznych […] administrator […] wdraża odpowiednie środki techniczne i organizacyjne, takie jak pseudonimizacja, zaprojektowane w celu skutecznego wprowadzenia w życie zasad ochrony danych, takich jak minimalizacja danych.
Najsilniej widać to przy projektowaniu źródeł danych. Trzeba rozdzielić dane niezbędne do działania modelu od tych, które nie są potrzebne biznesowo. Jeśli kamera przemysłowa rejestruje twarz operatora, identyfikator pracownika czy stanowisko, zakres przetwarzania należy ograniczyć już na poziomie kadru, retencji i dostępu. Dane biometryczne pracownika (twarz, linie papilarne) stanowią kategorię szczególną w rozumieniu art. 9 RODO[2] i wymagają wyraźnej podstawy prawnej – w praktyce przemysłowej najczęściej wyraźnej zgody lub przepisu prawa.
RODO wpływa również na wybór miejsca przetwarzania. W wielu wdrożeniach lepiej sprawdza się lokalne przetwarzanie w urządzeniu niż stały transfer obrazu lub dźwięku do chmury – ruch danych jest mniejszy, łatwiej kontrolować cel przetwarzania. Warto też sprawdzić, czy przetwarzanie danych biometrycznych wymaga Oceny Skutków dla Ochrony Danych (DPIA) na podstawie art. 35 RODO[2] – w wielu przypadkach przemysłowych ta ocena jest obowiązkowa i musi poprzedzać uruchomienie systemu.
Ochrona danych przestaje być osobnym dokumentem – staje się częścią projektu architektury. Zakres danych, miejsce przetwarzania i retencja decydują o tym, czy automatyzacja będzie bezpieczna w utrzymaniu i odporna na kontrolę UODO.
Jak obowiązek nadzoru człowieka zmienia proces automatyzacji
Art. 14 AI Act[1] wymaga, by systemy AI wysokiego ryzyka były projektowane w sposób umożliwiający skuteczny nadzór człowieka podczas całego okresu użytkowania. Wymóg ten wpływa bezpośrednio na interface, alarmy i tryby awaryjne – zanim system trafi na produkcję.
Zespół ustala, które decyzje model podejmuje sam, które tylko rekomenduje, a które wymagają zatwierdzenia. Granica ta wpływa na interfejs, alarmy, czasy reakcji i tryb awaryjny. Jeśli model odrzuca wyrób, blokuje paczkę lub zmienia parametry pracy urządzenia, operator musi widzieć podstawę decyzji i mieć możliwość przerwania sekwencji. Bez tego automatyzacja przyspiesza reakcję, ale zwiększa ryzyko błędnej eskalacji i utrudnia wyjaśnienie incydentu po fakcie.
Różnice są wyraźne. Panel pokazujący rekomendację i pozwalający ją zatwierdzić to co innego niż system, który sam zatrzymuje linię. W praktyce chodzi o proste pytanie: kto podejmuje decyzję końcową i jak ją odtworzyć? Wdrożenia opisują to jako human in the loop.
To wpływa na szkolenie personelu. Operator nie może dostać tylko komunikatu „zgodne” lub „niezgodne”, gdy decyzja jest poważna. System powinien pokazać poziom pewności, źródło alertu lub fragment obrazu, który uruchomił klasyfikację. W porównaniu z tradycyjnym czujnikiem progowym model uczący się wymaga szerszego opisu sytuacji, bo działa na wzorcach, a nie prostych granicach.
Nadzór człowieka może początkowo spowolnić wdrożenie, ale później ogranicza koszt błędów i sporów o odpowiedzialność.
Po co automatyzacji logi, dokumentacja i ślad zmian
Dokumentacja techniczna (art. 11 AI Act[1]) i automatyczne rejestrowanie zdarzeń (art. 12 AI Act[1]) to od 2 sierpnia 2026 r. obowiązki prawne, a nie jedynie dobre praktyki. Każdy model wysokiego ryzyka musi zostawiać ślad wersji, danych wejściowych, wyniku oraz osoby zatwierdzającej zmianę. Wdrażający zobowiązany jest przechowywać logi przez co najmniej 6 miesięcy po zakończeniu każdego użycia systemu.
Bez takiego śladu trudno wyjaśnić, dlaczego system zachował się inaczej po aktualizacji – szczególnie gdy model działa w urządzeniu przez wiele miesięcy bez interwencji. Zespół musi powiązać wersję modelu z wersją oprogramowania, warunkami testów, zakresem danych i procedurą przywrócenia wcześniejszej wersji. Tylko wtedy audyt ma sens.
W klasycznych programach regułowych zmiany w kodzie łatwo prześledzić. W modelu uczącym się różnice bywają ukryte w danych treningowych, ustawieniach czy sposobie walidacji. Dlatego logging – rejestrowanie zdarzeń – to nie tylko formalność, ale narzędzie operacyjne konieczne do wyjaśnienia incydentu przed organem nadzorczym.
To wpływa na relacje z dostawcami. Firma kupująca model od partnera zewnętrznego potrzebuje zapisanych ustaleń o aktualizacjach, odpowiedzialności za błędy, dostępie do logów i trybie zgłaszania incydentów. Bez tego automatyzacja może działać poprawnie technicznie, ale firma nie odzyska kontroli po wdrożeniu ani nie udowodni zgodności po kontroli.
Jak regulacje zmieniają design systemów w fabrykach i IoT
System wizyjny do kontroli jakości najlepiej pokazuje, jak prawo wpływa na design automatyzacji w fabryce. Konkretny przykład: producent opakowań szklanych wdraża kamery nad linią formowania, by automatycznie wykrywać wady – pęknięcia, braki nadruku, odchylenia wymiarów. System AI analizuje obraz z prędkością kilkudziesięciu klatek na sekundę i klasyfikuje wyrób jako zgodny lub niezgodny. Jak wpływają na taki projekt regulacje?
- Zakres danych a RODO: jeśli kamera rejestruje wyłącznie wyrób bez możliwości identyfikacji operatora, system nie przetwarza danych osobowych. Jeśli jednak linia obejmuje twarz lub stanowisko pracownika, wchodzi w zakres danych biometrycznych (art. 9 RODO[2]), co wymaga DPIA i wyraźnej podstawy prawnej.
- Wpływ na decyzję a art. 22 RODO: automatyczne zatrzymanie linii lub odrzucenie partii to decyzja o istotnych skutkach operacyjnych. Jeśli wynik systemu wpływa na ocenę pracownika, art. 22 RODO[2] (zautomatyzowane podejmowanie decyzji) wymaga zapewnienia możliwości sprzeciwu i wyjaśnienia.
- Klasyfikacja ryzyka AI: system wizyjny używany do oceny pracowników lub ich zarządzania może podpadać pod Załącznik III pkt 4 AI Act[1] (systemy wysokiego ryzyka w obszarze zatrudnienia), co uruchamia pełen zestaw obowiązków dokumentacyjnych.
- Nadzór człowieka: wynik klasyfikacji „niezgodny” powinien trafiać do operatora z poziomem pewności i wizualizacją obszaru wady – nie tylko jako binarny sygnał zatrzymania linii.
- Edge AI zamiast chmury: inferencja na kamerze brzegowej (przetwarzanie w urządzeniu) zamiast przesyłania surowego strumienia wideo do chmury redukuje ryzyko wycieku danych i ogranicza zakres przetwarzania wymagający uzasadnienia.
IoT stawia podobne wyzwania w innym miejscu. Gdy inteligentne urządzenie decyduje lokalnie, zespół ma krótszą ścieżkę danych i lepszą kontrolę nad łącznością. Jeśli urządzenie przesyła cały strumień do chmury, rośnie zależność od dostawcy, retencji i polityki aktualizacji modelu. W porównaniu z prostym czujnikiem i sterownikiem, AI w urządzeniu wymaga silniejszego powiązania elektroniki, oprogramowania, procedur prawnych i ścieżki serwisowej.
Firmy, które włączają zgodność już w projektowaniu, częściej budują systemy gotowe do skalowania, nie tylko jednorazowe pilotaże. Regulacje nie blokują automatyzacji – wymuszają taki design, w którym model, człowiek i dokumentacja tworzą jeden sprawny system.
Regulacje AI w Polsce przesuwają kolejność decyzji w automatyzacji: najpierw odpowiedzialność, dane i nadzór, potem model i wdrożenie.
FAQ – Najczęściej zadawane pytania
Czy mała firma korzystająca z gotowego modelu AI też odpowiada za zgodność?
Odpowiedzialność wdrażającego nie znika, nawet jeśli firma kupuje gotowy model od zewnętrznego dostawcy. Mała organizacja – działając jako wdrażający w rozumieniu art. 26 AI Act[1] – odpowiada za sposób użycia, konfigurację, zakres danych i konsekwencje decyzji podejmowanych przez system. Jednocześnie art. 55 AI Act[1] nakłada na Komisję Europejską i państwa członkowskie obowiązek udostępniania MŚP i startupom piaskownic regulacyjnych (regulatory sandboxes), bezpłatnych wytycznych i szkoleń oraz obniżonego pułapu kar.
Kiedy dane z fabryki stają się danymi osobowymi?
Dane osobowe pojawiają się, gdy obraz, dźwięk, identyfikator lub log pozwala powiązać zdarzenie z konkretną osobą. Materiał z kamery skierowanej wyłącznie na produkt niesie mniejsze ryzyko niż nagranie obejmujące operatora i jego stanowisko. Dane biometryczne pracownika (twarz, odcisk palca, skan tęczówki) stanowią kategorię szczególną z art. 9 RODO[2] i wymagają wyraźnej podstawy prawnej – co do zasady wyraźnej zgody lub szczególnego przepisu prawa. W praktyce liczy się możliwość identyfikacji, nie sama nazwa pliku czy urządzenia zbierającego dane.
Czy model open source ułatwia zgodność z prawem?
Model open source ułatwia analizę działania, ale nie gwarantuje zgodności z prawem. Otwarty kod pozwala sprawdzić wersję, zależności i sposób aktualizacji, jednak firma nadal odpowiada za dane wejściowe, testy, bezpieczeństwo wdrożenia i nadzór nad użyciem. W porównaniu z modelem zamkniętym rośnie przejrzystość techniczna, ale obowiązki organizacyjne z AI Act – w tym dokumentacja techniczna (art. 11) i logi (art. 12) dla systemów wysokiego ryzyka[1] – pozostają bez zmian.
Co powinno znaleźć się w umowie z dostawcą AI?
Umowa wdrożeniowa powinna jasno rozdzielać odpowiedzialność za dane, aktualizacje modelu, usuwanie błędów i obsługę incydentów. Ważne jest określenie, kto prowadzi testy odbiorowe, kto zatwierdza zmiany wersji i kto udostępnia ślad działań potrzebny do wyjaśnienia sporu. Art. 25 AI Act[1] precyzuje, kiedy wdrażający przejmuje obowiązki dostawcy – warto opisać ten zakres wprost w umowie. Przy AI sama gwarancja serwisowa nie wystarcza – model może zmieniać zachowanie po aktualizacji bez widocznej zmiany w interfejsie.
Czy można trenować model na danych historycznych z produkcji?
Dane historyczne można wykorzystać do treningu tylko wtedy, gdy cel użycia, podstawa przetwarzania i zakres informacji są zgodne z nowym zastosowaniem. Zasada ograniczenia celu z art. 5 ust. 1 lit. b RODO[2] oznacza, że dane zbierane do jednego celu (np. nadzoru bezpieczeństwa) nie mogą być automatycznie użyte do trenowania modelu oceniającego jakość lub wydajność pracownika. Surowe nagrania z hali niosą większe ryzyko niż zanonimizowane cechy produktu, błędu lub procesu. Jeśli firma nie umie oddzielić informacji o produkcie od informacji o pracowniku, trening modelu trzeba przeprojektować przed wdrożeniem.
Jak postępować po aktualizacji modelu w działającym systemie?
Aktualizacja modelu powinna przechodzić kontrolowaną ścieżkę zmiany, nie zwykłą publikację nowej wersji. Zespół musi sprawdzić wpływ aktualizacji na wyniki, wyjątki procesowe, integracje i możliwość powrotu do wcześniejszej konfiguracji. Dla systemów wysokiego ryzyka art. 9 AI Act[1] wymaga, by system zarządzania ryzykiem działał przez cały cykl życia modelu – aktualizacja to nowy etap tego cyklu wymagający ponownej walidacji, a nie zwykła poprawka oprogramowania.
Czy dział zakupów powinien oceniać AI inaczej niż zwykłe oprogramowanie?
Zakup systemu AI wymaga szerszej oceny niż wybór zwykłego oprogramowania. Należy sprawdzić, czy dostawca posiada dokumentację techniczną i deklarację zgodności wymaganą art. 16 AI Act[1], jak również origin danych treningowych, tryb uczenia i zasady aktualizacji. Dział zakupów powinien zapytać o rolę dostawcy po wdrożeniu, dostęp do logów i ograniczenia odpowiedzialności. Dla systemów wysokiego ryzyka dostawca zobowiązany jest do wpisu w unijnej bazie danych AI (EU AI Database)[4] – brak wpisu to sygnał ostrzegawczy.
Jakie ułatwienia przewiduje AI Act dla małych i średnich przedsiębiorstw?
Art. 55 AI Act[1] zobowiązuje Komisję Europejską i państwa członkowskie do stworzenia piaskownic regulacyjnych (regulatory sandboxes), w których MŚP i startupy mogą testować systemy AI pod nadzorem organu nadzorczego przed wejściem na rynek. Piaskownice zapewniają priorytetowy dostęp, uproszczone wytyczne i bezpłatne doradztwo. Jednocześnie art. 99 ust. 6 AI Act[1] ustanawia korzystniejszy model obliczania kar dla MŚP. Europejski Urząd ds. AI (EU AI Office)[4] publikuje narzędzia i wzorcową dokumentację dedykowaną mniejszym podmiotom.
Źródła
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 z dnia 13 czerwca 2024 r. w sprawie ustanowienia zharmonizowanych przepisów dotyczących sztucznej inteligencji (Akt w sprawie sztucznej inteligencji — AI Act) — EUR-Lex
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych (RODO/GDPR) — EUR-Lex
- Urząd Ochrony Danych Osobowych (UODO) — polski organ nadzorczy ds. ochrony danych osobowych
- European AI Office (Europejski Urząd ds. Sztucznej Inteligencji) — Komisja Europejska
- Europejska Rada Ochrony Danych (EDPB/EROD) — wytyczne dot. zautomatyzowanego podejmowania decyzji i profilowania (w tym w kontekście systemów AI)
Portal sfau.pl pomaga entuzjastom technologii i profesjonalistom w śledzeniu trendów w sztucznej inteligencji, automatyzacji, designie i Internecie rzeczy. Redakcję tworzą specjaliści technologii informacyjnych i inżynierowie systemów. Więcej o naszej redakcji