AI Act — kiedy polskie MŚP staje się dostawcą high-risk AI system

High-risk to nie etykieta — to status prawny

W AI Act określenie „system wysokiego ryzyka” nie jest opinią, marketingiem ani wewnętrzną klasyfikacją dostawcy. To status prawny, który nakłada konkretne obowiązki — od dokumentacji technicznej, przez logging, po conformity assessment. I co ważniejsze: ten status nie zależy od tego, jak dostawca opisuje swój produkt. Zależy od przeznaczenia (intended purpose) systemu w rozumieniu art. 3 pkt 12 rozporządzenia.

Jeśli Twój produkt SaaS jest sprzedawany jako „AI screening kandydatów do pracy” — to system wysokiego ryzyka, niezależnie od tego, czy w opisie marketingowym używasz słowa „AI”, czy nie. To rozróżnienie ma znaczenie dla każdego polskiego MŚP, które buduje lub odsprzedaje rozwiązania z komponentem AI.

W tym artykule przechodzimy przez całą listę z Aneksu III, dopisujemy konkretne przykłady MŚP-owe i kończymy obowiązkami operacyjnymi z art. 8-22.

Dwie ścieżki klasyfikacji — art. 6

Art. 6 AI Act definiuje dwie drogi, którymi system AI trafia do kategorii wysokiego ryzyka:

Ścieżka A — produkt regulowany (art. 6 ust. 1): system AI jest komponentem bezpieczeństwa produktu objętego prawodawstwem harmonizacyjnym UE z Aneksu I (maszyny, wyroby medyczne, zabawki, lotnictwo, kolej, urządzenia ciśnieniowe i inne) i ten produkt podlega ocenie zgodności przez stronę trzecią.
Ścieżka B — obszar z Aneksu III (art. 6 ust. 2): system AI jest przeznaczony do wykorzystania w jednym z ośmiu obszarów wyliczonych w Aneksie III.

Większość polskich MŚP, jeśli wpadnie w high-risk, wpadnie przez ścieżkę B. Dlatego poniżej rozkładamy wszystkie osiem kategorii z Aneksu III.

Osiem kategorii Aneksu III

1. Biometria

Aneks III pkt 1 obejmuje systemy:

zdalnej identyfikacji biometrycznej (poza identyfikacją służącą wyłącznie do potwierdzenia tożsamości);
kategoryzacji biometrycznej według atrybutów lub cech wrażliwych;
rozpoznawania emocji.

Część tych zastosowań jest zakazana przez art. 5 — w szczególności biometryczna kategoryzacja po cechach wrażliwych (np. rasa, religia) oraz rozpoznawanie emocji w miejscu pracy i w edukacji. Pozostałe — np. rozpoznawanie emocji w call center poza UE wykorzystywane do oceny jakości obsługi — wchodzą w high-risk z pełnymi obowiązkami.

2. Krytyczna infrastruktura

Aneks III pkt 2 dotyczy systemów AI używanych jako komponenty bezpieczeństwa w zarządzaniu i działaniu krytycznej infrastruktury cyfrowej, ruchu drogowego oraz dostawami wody, gazu, ciepła i elektryczności.

Dla MŚP istotne staje się to wtedy, gdy firma dostarcza rozwiązanie SCADA z warstwą predykcyjną AI dla operatora sieci dystrybucyjnej. Sam algorytm prognozy zapotrzebowania na energię nie musi być high-risk — ale moduł, który steruje przełączeniem obciążenia, już tak.

3. Edukacja i szkolenie zawodowe

Aneks III pkt 3 wymienia systemy AI używane:

przy ustalaniu dostępu do instytucji edukacyjnych i kierowaniu osób do nich;
do oceniania wyników nauczania, w tym egzaminów;
do oceny poziomu nauczania, do którego osoba jest uprawniona;
do monitorowania i wykrywania niedozwolonych zachowań podczas testów.

Dla edu-tech MŚP w Polsce — proctoring online, AI-grading, recommendation engines kierujące uczniów do ścieżek nauczania — to bezpośrednie wskazanie. Sprzedaż tego rodzaju produktów do uczelni lub szkół po sierpniu 2026 wymaga pełnego stacku zgodności.

4. Zatrudnienie i HR

Aneks III pkt 4 obejmuje systemy AI używane:

do rekrutacji lub selekcji osób — w szczególności do publikowania ogłoszeń, analizy aplikacji, oceny kandydatów;
do podejmowania decyzji dotyczących warunków stosunku pracy, awansów, zakończenia stosunku pracy, alokacji zadań na podstawie zachowania pracownika oraz monitorowania i oceny wyników.

To kategoria, w którą polskie MŚP wpadają najczęściej — przez zakup gotowych narzędzi HR-tech z funkcją AI screeningu CV, AI-driven workforce planning lub algorytmów oceny wydajności. Sam HR-tech jako dostawca jest providerem high-risk; firma kupująca i wdrażająca staje się deployerem high-risk — z osobnym, ale węższym zestawem obowiązków (art. 26-27).

5. Dostęp do podstawowych usług publicznych i prywatnych

Aneks III pkt 5 wymienia:

ocenę uprawnień do świadczeń i usług publicznych;
ocenę zdolności kredytowej lub ustalanie scoringu kredytowego osób fizycznych (z wyłączeniem AI wykrywającego oszustwa finansowe);
ocenę ryzyka i pricing w ubezpieczeniach na życie i zdrowotnych;
klasyfikację i priorytetyzację zgłoszeń alarmowych (numery 112, pogotowie, straż).

Dla fintechów MŚP scoring kredytowy AI to bezpośrednie wskazanie. Dla insurtechów — pricing zdrowotny lub życiowy. Lit. b ma istotny wyjątek dla AI wykrywającego oszustwa finansowe — co warto rozróżnić od scoringu zdolności.

6. Ściganie prawa

Aneks III pkt 6 dotyczy systemów AI używanych przez organy ścigania — w tym do oceny ryzyka popełnienia przestępstwa przez konkretną osobę, jako wariograf, do oceny wiarygodności dowodów, do profilowania w trakcie wykrywania i ścigania przestępstw.

Polskie MŚP rzadko są dostawcami w tej kategorii — bo klientem są wyłącznie organy publiczne. Ale jeśli firma buduje rozwiązanie typu „risk scoring dla compliance officer w banku” przeznaczone do raportowania do GIIF — granica między art. 5 ust. 1 lit. d (zakaz oceny ryzyka popełnienia przestępstwa wyłącznie na profilowaniu) a pkt 6 (ściganie prawa) wymaga osobnej analizy.

7. Migracja, azyl i kontrola graniczna

Aneks III pkt 7 dotyczy systemów AI używanych przez organy publiczne w kontekście migracji, azylu i kontroli granicznej — w tym wariografy, ocena ryzyka migranta, weryfikacja autentyczności dokumentów podróży, badanie wniosków o azyl.

Dla większości polskich MŚP — obszar marginalny, chyba że firma dostarcza systemy verification dokumentów dla Straży Granicznej lub Urzędu ds. Cudzoziemców.

8. Sądownictwo i procesy demokratyczne

Aneks III pkt 8 obejmuje:

systemy AI wspierające organ sądowy w badaniu faktów i prawa oraz w stosowaniu prawa do konkretnego stanu faktycznego;
systemy AI przeznaczone do wpływania na wynik wyborów lub referendum, lub na zachowanie wyborcze osób fizycznych (z wyłączeniem narzędzi czysto organizacyjnych w kampanii).

Kategoria istotna dla legal-tech MŚP budujących AI legal research dla sądów lub kancelarii reprezentujących stronę przed sądem. Sam research dla kancelarii zazwyczaj poza zakresem — bo nie wspiera bezpośrednio sądu.

Trzy konkretne scenariusze MŚP w PL

HR-tech MŚP z AI screeningiem CV. Sprzedajesz SaaS, który analizuje CV i przypisuje kandydatom score zgodności z ofertą. To kategoria 4 Aneksu III. Jako provider podlegasz pełnemu pakietowi art. 8-22. Wymaga to risk management system (art. 9), data governance (art. 10) — w tym walidacji danych treningowych pod kątem stronniczości, dokumentacji technicznej zgodnej z Aneksem IV (art. 11), conformity assessment per art. 43 (dla większości high-risk z Aneksu III — wewnętrzny, bez notified body), CE marking, rejestracji w bazie UE per art. 71.

Fintech MŚP z AI scoringiem kredytowym. Kategoria 5 lit. b. Pełen pakiet jak wyżej, z dodatkowymi wymogami sektorowymi (KNF, ESMA — przez powiązanie z dyrektywą o kredycie konsumenckim). Tu dochodzi pytanie, czy istniejące wymogi nadzorcze KNF wystarczą do oceny zgodności, czy konieczna jest osobna procedura AI Act.

Edu-tech MŚP z AI grading. Kategoria 3. Pełen pakiet — z dodatkowym ciężarem przy walidacji jakości danych treningowych (test bias na poziomie języka polskiego, regionów, profili szkół). Walidacja FRIA przez deployera (szkoła, uczelnia) z art. 27 staje się elementem cyklu sprzedaży B2B.

Obowiązki providera high-risk — co realnie trzeba zbudować

Art. 8-22 AI Act tworzą zwarty pakiet wymogów. Najważniejsze z perspektywy CTO MŚP:

System zarządzania ryzykiem (art. 9): ciągły proces — identyfikacja, estymacja, ewaluacja, mitygacja ryzyka przez cały cykl życia systemu. Nie jednorazowy dokument, ale żywy proces z odpowiedzialnościami i przeglądami.
Data governance (art. 10): zbiory treningowe, walidacyjne i testowe muszą spełniać kryteria jakości, reprezentatywności i — gdy to istotne — być wolne od błędów i kompletne. To ma bezpośredni wpływ na to, jak budujesz dataset i jak go dokumentujesz.
Dokumentacja techniczna (art. 11) + Aneks IV: kompletny opis systemu — architektura, dane, walidacja, monitoring, ryzyka. Aneks IV daje listę pól minimum.
Logging (art. 12): automatyczne logowanie zdarzeń przez cały cykl życia operacyjnego — z retencją proporcjonalną do przeznaczenia.
Transparentność wobec deployera (art. 13): instrukcje użycia, opis ograniczeń, wymagań dotyczących nadzoru człowieka.
Nadzór człowieka (art. 14): system musi być projektowany tak, by człowiek mógł efektywnie nadzorować jego działanie — z konkretnymi mechanizmami interwencji.
Dokładność, odporność, cyberbezpieczeństwo (art. 15): wymóg poziomu odpowiedniego do przeznaczenia — z odpornością na błędy, niespójności i ataki adversarialne.

Conformity assessment — art. 43

Większość systemów high-risk z Aneksu III przechodzi conformity assessment w trybie wewnętrznym — bez udziału notified body. Wyjątek dotyczy biometrii (pkt 1 Aneksu III), gdzie w pewnych konfiguracjach wymagany jest audyt strony trzeciej. Po pomyślnym assessment system otrzymuje CE marking i jest rejestrowany w unijnej bazie danych per art. 71.

Dla MŚP-providera oznacza to wewnętrzną procedurę, dokumentację i — w praktyce — zewnętrzne wsparcie prawno-techniczne na etapie pierwszego cyklu. Drugi cykl, dla kolejnej wersji produktu, jest znacznie tańszy operacyjnie.

Co zrobić w 2026 — trzy kroki

Krok 1: inwentaryzacja systemów AI. Lista wszystkich systemów AI w produkcji, w stacku zakupowym i w roadmapie. Per system: dostawca, przeznaczenie, dane wejściowe, dane wyjściowe, populacja końcowa.

Krok 2: klasyfikacja per Aneks III. Każdy system AI z listy mapowany do jednej z trzech kategorii — zakazany, high-risk (z numerem punktu Aneksu III), pozostałe. Klasyfikację warto przeprowadzić z prawnikiem — bo granice są precyzyjne, ale ich interpretacja w konkretnych przypadkach jest niebanalna.

Krok 3: plan compliance pod sierpień 2026. Dla każdego systemu high-risk — mapa luk: czego brakuje (dokumentacja, logging, FRIA u deployera, instrukcje), kto za co odpowiada, kiedy gotowe. Z buforem co najmniej trzech miesięcy przed terminem — bo conformity assessment to nie jednodniowe zadanie.

QA10 — gdzie to sprawdzamy

W ramach Engineering Lab przeprowadzamy klasyfikację stacku AI klienta według Aneksu III i Aneksu I oraz oceniamy gotowość dokumentacyjną — w tym warstwy data governance i logging — przed sierpniem 2026. Dla klientów, którzy są deployerami, robimy też FRIA per art. 27.