Startup w świecie regulacji AI Act: co trzeba zmienić w produkcie, procesach i dokumentacji

Krótki obraz gry: czym jest AI Act i dlaczego dotyczy także mikro‑startupów

Intuicja: co właściwie reguluje AI Act

AI Act to unijne rozporządzenie regulujące systemy sztucznej inteligencji, a nie tylko pojedyncze, spektakularne narzędzia jak generatywne chatboty. Obejmuje wszystko, co w mniej lub bardziej automatyczny sposób uczy się na danych albo stosuje złożone reguły, aby podejmować decyzje, rekomendacje lub prognozy. Od prostych modeli scoringowych po złożone systemy generatywne – jeśli używasz modeli uczenia maszynowego, logiki, statystyki lub kombinacji tych technik, AI Act prawdopodobnie cię dotyczy.

Regulacja ma dwa główne cele: z jednej strony ochrona praw podstawowych (np. brak dyskryminacji, prawo do wyjaśnienia decyzji), z drugiej – utrzymanie innowacyjności, szczególnie w Europie. Dlatego zamiast zakazać wszystkiego, AI Act wprowadza system klas ryzyka i dopasowane do nich obowiązki. To, co zrobisz w produkcie i procesach, zależy od tego, w którą kategorię wpada twoje zastosowanie.

Dla startupu kluczowe jest zrozumienie, że AI Act nie jest tylko „papierologią dla korporacji”. Nawet prosty SaaS z modułem rekomendującym treści czy scoringiem klienta może zostać zakwalifikowany jako system AI – a wtedy trzeba zadbać o przejrzystość, dokumentację i kilka nowych elementów w architekturze produktu.

Jakie typy podmiotów obejmuje regulacja i gdzie ląduje typowy startup

AI Act nie mówi ogólnie o „firmach IT”, tylko o czterech rolach związanych z systemami AI. Jedna firma może pełnić kilka z nich jednocześnie:

• Dostawca (provider) – ten, kto tworzy lub rozwija system AI i wprowadza go na rynek UE (np. oferuje jako SaaS, sprzedaje licencję, open source z pewnymi elementami komercji).
• Użytkownik (deployer) – podmiot, który używa systemu AI w swojej działalności zawodowej, np. dział HR korzystający z narzędzia do preselekcji CV.
• Importer – sprowadza system AI spoza UE na rynek europejski, często rola dla firm dystrybuujących narzędzia dostawców z USA czy Azji.
• Dystrybutor – dalej rozpowszechnia system AI w łańcuchu dostaw (reseller, marketplace, integrator).

Typowy startup produktowy z Europy, który buduje własny system AI i sprzedaje go jako aplikację lub API, jest przede wszystkim dostawcą. Jeśli ten sam startup wdraża swój system w wewnętrznych procesach (np. używa własnego narzędzia do rekrutacji we własnej firmie), jest też użytkownikiem.

Drugi częsty scenariusz: startup buduje rozwiązanie biznesowe, które w środku korzysta z zewnętrznego API AI (np. model językowy w chmurze). W oczach AI Act taki startup nadal jest dostawcą „swojego” systemu AI, ponieważ oferuje konkretną funkcję użytkownikowi końcowemu – nawet jeśli model leży na serwerach kogoś innego. To oznacza obowiązki dotyczące dokumentacji, przejrzystości i oceny ryzyka po stronie startupu, nie tylko dostawcy modelu.

Wielkość firmy a obowiązki: ulgi dla MŚP kontra realia

AI Act wprowadza pewne ułatwienia dla MŚP, startupów i scale-upów, np. zachęty finansowe, wsparcie przez regulatory sandboxes (piaskownice regulacyjne), a w niektórych przypadkach złagodzone wymagania proceduralne. Nie ma jednak zasady „jesteś mały, więc cię to nie dotyczy”.

Kluczowe jest ryzyko zastosowania, a nie liczba pracowników. Jednoosobowy startup tworzący system oceny kandydatów do pracy z użyciem AI wchodzi w kategorię wysokiego ryzyka tak samo jak międzynarodowa korporacja. Różnica polega głównie na tym, że:

• możesz liczyć na pewne wsparcie regulatora (np. guidance, piaskownice, materiały dla MŚP),
• przepisy czasem dopuszczają proporcjonalne podejście, czyli mniej formalnych rytuałów, ale nie mniej realnych zabezpieczeń.

Dlatego myślenie: „ogarnę regulacje później, jak będę większy” jest krótkowzroczne. Jeśli produkt celuje w obszar wysokiego ryzyka (np. HR, zdrowie, edukacja), od początku trzeba wbudować wymogi AI Act w architekturę, dane i procesy.

Oś czasu: kiedy AI Act zacznie „gryźć” startupy

AI Act został przyjęty na poziomie UE i wchodzi w życie w kilku etapach. Szczegóły kalendarza są techniczne, ale z perspektywy startupu warto mieć w głowie uproszczoną oś:

• 0–6 miesięcy od wejścia w życie – zaczynają obowiązywać zakazy najbardziej kontrowersyjnych praktyk (np. niektóre formy social scoringu, manipulacji podprogowej).
• 12–24 miesiące – wchodzą kluczowe obowiązki dla systemów wysokiego ryzyka, m.in. wymogi dokumentacyjne, oceny ryzyka, nadzoru człowieka, rejestracji w unijnym rejestrze systemów wysokiego ryzyka.
• ok. 24 miesiące i dalej – przepisy stają się pełnoskalowe, w tym mechanizmy nadzoru, kontroli i sankcji.

Dla startupu to oznacza, że okno na spokojne wdrożenie zmian istnieje, ale nie jest ogromne. Budowanie dokumentacji „po fakcie”, gdy system jest już wdrożony u klientów, jest dużo trudniejsze niż rozwijanie produktu z wbudowanymi standardami AI Act.

Przykład: mały SaaS z modułem AI jako „dostawca systemu AI”

Wyobraźmy sobie trzyosobowy zespół, który tworzy SaaS do analizy zgłoszeń klientów. W tle działa model klasyfikujący zgłoszenia (np. reklamacja, pytanie, prośba o ofertę) i podpowiadający odpowiedzi. Produkt jest sprzedawany firmom z całej UE.

Taki startup jest dostawcą systemu AI, ponieważ:

• utrzymuje i rozwija model (nawet jeśli posługuje się zewnętrznym API),
• definiuje sposób jego użycia (scenariusze, interfejs, ograniczenia),
• wprowadza rozwiązanie na rynek, fakturuje klientów, zapewnia wsparcie.

Nawet jeśli zastosowanie wygląda na „niskiego ryzyka”, startup musi zadbać o przejrzyste oznaczenie funkcji AI, minimalną dokumentację techniczną, podstawowe logowanie decyzji i tryb wyłączenia AI. A jeśli system zostanie użyty w sektorze wysokiego ryzyka (np. obsługa zgłoszeń pacjentów, wstępna klasyfikacja wniosków kredytowych), wymagania rosną wykładniczo.

Pierwszy krok: czy Twój produkt jest „systemem AI” w rozumieniu AI Act

Definicja systemu AI po ludzku

AI Act posługuje się dość szeroką definicją systemu AI. W uproszczeniu: to system oparty na technikach obliczeniowych (w tym uczeniu maszynowym, logice, statystyce, modelach regułowych), który generuje wyniki wpływające na środowisko – decyzje, klasyfikacje, rekomendacje, przewidywania, treści – w sposób częściowo autonomiczny.

Kluczowe elementy definicji to:

• przetwarzanie danych wejściowych według złożonych reguł lub wyuczonych modeli,
• pewien poziom autonomii (system sam dobiera wynik na podstawie danych, a nie tylko wykonuje sekwencję deterministycznych kroków),
• możliwość wpływu na ludzi lub procesy (np. decyzja o odrzuceniu wniosku, wybór oferty, klasyfikacja treści).

Nie trzeba budować własnej sieci neuronowej od zera, aby podpadać pod tę definicję. Nawet prostsze techniki (np. regresja logistyczna, drzewa decyzyjne, systemy eksperckie) mogą być traktowane jako AI, jeśli ich wynik służy do podejmowania lub wspierania decyzji.

Granica: zwykłe oprogramowanie vs system AI – przykłady

Dla wielu zespołów najtrudniejsze jest odróżnienie „zwykłego softu” od systemu AI. Kilka intuicyjnych przykładów pomaga poukładać temat:

• Prosty if/else w kodzie: jeżeli klient nie zapłacił faktury przez 30 dni, wyślij przypomnienie. To nie jest AI – to deterministyczna logika biznesowa.
• System regułowy z setkami warunków (np. silnik reguł do scoringu wniosków kredytowych), który powstał ręcznie, ale jest bardzo złożony: może zostać podciągnięty pod system AI, bo działa podobnie jak model decyzyjny i ma realny wpływ na ludzi.
• Model predykcyjny prognozujący churn klientów na podstawie historii interakcji – to klasyczne zastosowanie AI/ML.
• Personalizowany ranking treści (np. w sklepie internetowym) oparty o uczenie maszynowe lub algorytmy rekomendacyjne – także system AI.
• Silnik reguł w grze, który decyduje, kiedy pojawia się przeciwnik, bez wpływu na rzeczywiste prawa i obowiązki gracza w świecie „offline” – w praktyce raczej poza zakresem AI Act (brak istotnego skutku dla praw podstawowych).

Regulacja jest celowo szeroka, bo technologicznie granica między „zaawansowanym softem” a „AI” bywa płynna. Dla startupu bezpiecznym założeniem jest: jeśli system uczy się na danych albo zastępuje ludzką ocenę w obszarach istotnych dla ludzi, traktuj go jak AI.

Komponent AI od zewnętrznego dostawcy – czy to Twój system?

Bardzo dużo startupów buduje swoje produkty, korzystając z zewnętrznych modeli (API dużych modeli językowych, gotowych modeli wizji komputerowej, usług chmurowych z AI). Częste pytanie brzmi: „czy skoro model nie jest nasz, to czy my w ogóle jesteśmy dostawcą systemu AI?”

AI Act patrzy nie na to, kto hostuje model, ale na to, kto wprowadza na rynek konkretne zastosowanie. Jeśli:

• projektujesz produkt dla użytkownika końcowego,
• określasz scenariusze użycia, instrukcje, ograniczenia,
• decydujesz, jakie dane zasilają model i jak interpretować jego wyniki,
• sprzedajesz, integrujesz i wspierasz rozwiązanie,

to w praktyce pełnisz rolę dostawcy systemu AI w rozumieniu AI Act, nawet jeśli „serce” modelu pochodzi z chmury. W takiej sytuacji:

• masz obowiązek zadbać o przejrzystość (np. poinformować, że wynik pochodzi od systemu AI),
• musisz upewnić się, że dostawca modelu zapewnia odpowiednie gwarancje (umowy, opisy modeli, dokumentacja),
• potrzebujesz własnej dokumentacji zastosowania: jakie dane wysyłasz, jak filtrujesz wyniki, jaką kontrolę ma człowiek.

Jak rozrysować architekturę produktu, żeby zobaczyć warstwę AI

Abstrakcyjne rozważania łatwo gubią się w gąszczu kodu i feature’ów. Pomaga prosta, techniczno-biznesowa mapa systemu. Wystarczy biała tablica lub prosty diagram w Miro/Whimsical:

• po jednej stronie źródła danych (formularze, bazy danych, API klientów),
• w środku główne komponenty backendowe (mikroserwisy, moduły),
• osobno każda interakcja z modelem lub systemem regułowym (nawet jeśli to tylko jedno wywołanie API),
• po drugiej stronie interfejs użytkownika i inne systemy, które korzystają z wyników.

Warto oznaczyć innym kolorem wszystko, co:

• przetwarza dane w celu klasyfikacji/predykcji,
• rekomenduje działania lub decyzje,
• generuje treści (tekst, obraz, dźwięk) w imieniu użytkownika,
• automatycznie steruje procesem na podstawie danych (np. akceptacja/odrzucenie wniosku bez udziału człowieka).

To są kandydaci na elementy „AI” w sensie AI Act. Z takiej mapy łatwiej potem wyprowadzić klasyfikację ryzyka i plan zmian w produkcie.

Mini‑check: szybki test „tak/nie”, czy wchodzisz pod definicję

Krótka lista pytań, które można przejść na spotkaniu produktowym albo w ramach wewnętrznego audytu:

• Czy jakikolwiek fragment systemu uczył się na danych (np. trenowaliście model, fine-tuning, użyliście AutoML)?
• Czy system samodzielnie klasyfikuje ludzi, dokumenty, obrazy, transakcje?
• Czy system rekomenduje decyzje (np. „odrzuć wniosek”, „zaproponuj tę ofertę”) na podstawie wzorców w danych, a nie tylko prostych progów typu „jeśli > X to…”?

Kolejne pytania, które „domykają” definicję

Do poprzedniej listy warto dodać jeszcze kilka pytań kontrolnych, które często wyłapują ukryte komponenty AI:

• Czy system generuje treści (maile, podsumowania, opisy produktów, odpowiedzi na czacie) w oparciu o model językowy lub inne techniki AI?
• Czy jakiekolwiek decyzje biznesowe są zautomatyzowane na podstawie wyniku modelu (np. przyznanie rabatu, kolejka priorytetowa, automatyczne zamykanie zgłoszeń)?
• Czy system dostosowuje swoje zachowanie do użytkownika lub kontekstu dzięki uczeniu na historii (np. „uczący się” system rekomendacji)?
• Czy klient końcowy może podjąć decyzję wyłącznie na podstawie wyniku modelu, bez weryfikacji człowieka (np. „AI mówi: odrzuć, więc odrzucamy”)?

Jeżeli kilka odpowiedzi brzmi „tak”, bezpieczniej jest założyć, że produkt wchodzi w zakres definicji systemu AI i przejść dalej do klasyfikacji ryzyka.

Klasyfikacja ryzyka: od zakazanych praktyk po „niskie ryzyko”

Intuicja: nie każdy system AI jest traktowany tak samo

AI Act nie wrzuca wszystkiego do jednego worka. Logika jest prosta: im większy potencjalny wpływ na ludzi, tym wyższe wymagania. W efekcie powstaje czteropoziomowa drabinka:

• praktyki zakazane – rzeczy, których robić po prostu nie wolno,
• systemy wysokiego ryzyka – dozwolone, ale pod bardzo konkretnymi warunkami,
• AI z obowiązkami przejrzystości – głównie „lżejsze” zastosowania, ale trzeba je oznaczać,
• niskie ryzyko – większość „zwykłych” zastosowań, gdzie presja regulacyjna jest najmniejsza, choć pewne standardy i tak są oczekiwane.

Startup nie musi znać na pamięć całego aktu, ale powinien umieć uczciwie odpowiedzieć: w którym koszyku leży nasz produkt? Od tego zależy zakres zmian w kodzie, procesach i dokumentacji.

Zakazane praktyki: czerwone światło już na poziomie pomysłu

Pierwszy filtr jest brutalny, ale uczciwy: czy nasz pomysł nie podpada pod coś, czego nie wolno robić w ogóle? Chodzi m.in. o:

• manipulację podprogową lub wykorzystującą słabości konkretnych grup (np. dzieci, osoby starsze) w celu istotnego zniekształcenia zachowania,
• social scoring obywateli przez instytucje publiczne – ocenianie „jakości” człowieka na podstawie zachowań, które nie są bezpośrednio powiązane z daną decyzją,
• rozpoznawanie emocji w miejscu pracy lub w szkołach (z wąskimi wyjątkami),
• niektóre zastosowania biometrii na żywo w przestrzeni publicznej do celów egzekwowania prawa.

Jeśli pivot produktu polega na „mierzeniu zaangażowania pracownika po minie z kamerki” albo „profilowaniu uczniów pod kątem posłuszeństwa”, to AI Act nie jest jedynym problemem – sam model biznesowy zahacza o strefę nie do obrony. Na tym etapie lepiej zmienić kierunek niż szukać kruczków.

Systemy wysokiego ryzyka: konkretne obszary, konkretne konsekwencje

Drugi poziom to wysokie ryzyko. Tutaj nie ma zakazu, ale wchodzą w grę najszersze obowiązki. AI Act wymienia konkretne obszary zastosowań, m.in.:

• systemy rekrutacyjne i HR (selekcja CV, ranking kandydatów, ocena pracowników),
• ocena zdolności kredytowej i inne decyzje w finansach, które wpływają na dostęp do usług,
• systemy w opiece zdrowotnej wspierające diagnozę, triage, priorytetyzację pacjentów,
• systemy wspierające organy publiczne: przyznawanie świadczeń, edukacja, migracja, sądownictwo,
• bezpieczeństwo produktów (np. komponent AI w maszynie, pojeździe, urządzeniu medycznym).

Jeżeli Twój produkt bezpośrednio realizuje jedną z takich funkcji, bardzo możliwe, że lądujesz w kategorii wysokiego ryzyka. Ważny niuans: czasem nie Ty jesteś formalnie „systemem wysokiego ryzyka”, tylko stajesz się dostawcą komponentu dla takiego systemu (np. moduł klasyfikacji dokumentów używany w banku).

AI z obowiązkami przejrzystości: chatboty, generatory treści i spółka

Niżej są systemy, które nie decydują wprost o czyimś kredycie czy leczeniu, ale mogą wprowadzać w błąd, jeśli użytkownik nie wie, że ma do czynienia z AI. Tu mieszczą się m.in.:

• chatboty i voiceboty, które udają człowieka lub zastępują obsługę klienta,
• generatory treści (tekst, obrazy, wideo), które mogą być mylone z materiałem stworzonym przez ludzi,
• systemy syntetycznego audio/wideo (deepfake), używane np. w marketingu czy rozrywce.

Dla takich zastosowań wymagania koncentrują się na wyraźnym oznaczeniu, że treść/rozmówca jest generowany przez AI, oraz na mechanizmach ograniczających oczywiste nadużycia (np. watermarking treści syntetycznych).

Niskie ryzyko: wciąż trzeba ogarnąć minimum higieny

Większość SaaS-ów B2B z modułami analitycznymi czy rekomendacyjnymi wyląduje w praktyce w kategorii niskiego ryzyka. To nie znaczy „rób co chcesz”, tylko raczej: państwo nie stoi nad Tobą z checklistą, ale klienci i tak zaczną o nią pytać.

W praktyce oznacza to m.in.:

• opisanie, co system robi i czego nie robi (granice odpowiedzialności AI),
• zapewnienie trybu ręcznego lub możliwości obejścia rekomendacji AI,
• zdroworozsądkowe logowanie decyzji i błędów, żeby dało się potem wytłumaczyć, co poszło nie tak.

Nawet przy niskim ryzyku to właśnie ta „higiena” odróżnia produkt, który przeżyje pierwsze audyty u korporacyjnych klientów, od takiego, który utknie na security review.

Jak przełożyć klasyfikację ryzyka na roadmapę produktu

Żeby nie utknąć w akademickich dyskusjach, przy planowaniu rozwoju produktu można użyć prostego podejścia w trzech krokach:

1. Zmapuj use case’y – wypisz konkretne zastosowania Twojego systemu (co dokładnie robi u klienta, w jakim procesie biznesowym).
2. Przypisz im „kolor ryzyka” – czerwony (podejrzenie zakazu), pomarańczowy (może być wysokie ryzyko), żółty (przejrzystość), zielony (niskie).
3. Dla każdego koloru zdefiniuj minimalny zestaw kontroli – co trzeba mieć w produkcie, procesach i papierach.

Takie tabelki świetnie działają na zarządy i inwestorów, bo zamieniają prawniczy żargon na konkretne tickboxy: „mamy / nie mamy / planujemy w Q3”.

Wymagania dla systemów wysokiego ryzyka: co to znaczy w produkcie i kodzie

Bezpieczeństwo i zarządzanie ryzykiem jako funkcja, nie projekt jednorazowy

Dla systemów wysokiego ryzyka AI Act wymaga systematycznego zarządzania ryzykiem. Nie chodzi o jednorazowy PDF przed premierą, ale o proces, który żyje razem z produktem. W kodzie i architekturze przekłada się to m.in. na:

• modularną architekturę – da się wymienić lub poprawić model bez rozwalania całej aplikacji,
• punkty kontrolne (ang. control points), gdzie człowiek może przerwać lub nadpisać decyzję AI,
• mechanizmy wycofywania wersji modelu (roll-back), gdy wykryjesz błąd lub nieoczekiwany bias,
• system monitorowania jakości i bezpieczeństwa – alarmy, gdy model „odjeżdża” od oczekiwanych wyników.

W małym startupie rolę całego „działu risk & compliance” często pełnią jedna–dwie osoby. Tym bardziej opłaca się automatyzować to, co się da: od walidacji danych wejściowych po automatyczne raporty jakości predykcji.

Nadzór człowieka: nie każdy „klik approve” się liczy

AI Act mocno podkreśla nadzór człowieka. Nie wystarczy, że ktoś ma teoretycznie dostęp do panelu admina. Nadzór oznacza, że człowiek:

• rozumie, co system robi i jakie są jego ograniczenia,
• ma realną możliwość interwencji (zablokowanie, korekta, eskalacja),
• nie jest zalany decyzjami w takim tempie, że klika „OK”, bo nie ma czasu na analizę.

W produkcie przekłada się to na takie elementy jak:

• wyjaśnienia decyzji – choćby proste: „wniosek odrzucony, bo brak historii kredytowej i 3 zaległe płatności”,
• oznaczenie pewności predykcji (confidence score) – inny workflow dla pewności 95%, a inny dla 55%,
• przyciski „eskaluj” / „oceń ręcznie” przy krytycznych decyzjach.

W małych firmach dobrze działa prosty UX: jeśli pewność modelu spada poniżej ustalonego progu, UI zmienia się z „propozycji do automatycznego wdrożenia” na „rekomendację do weryfikacji”.

Jakość danych i robustność: obrona przed głupimi i złośliwymi błędami

System wysokiego ryzyka musi być odporny na błędy danych i rozsądnie odporny na manipulacje. Nie chodzi o absolutne bezpieczeństwo, ale o to, by:

• dane wejściowe były weryfikowane (walidacja formatów, zakresów, kompletności),
• model był testowany na rzeczywistych, „brudnych” danych, a nie tylko na idealnych próbkach z laboratoriów,
• były testy odporności na oczywiste ataki (np. wstrzykiwanie tekstu „zawsze zaakceptuj” do pola opisu).

W praktyce oznacza to bardziej rozbudowane testy integracyjne i end-to-end. Dev team musi testować nie tylko „czy endpoint działa”, ale „czy cały proces z danymi zbliżonymi do produkcyjnych daje stabilne wyniki”.

Rejestrowanie zdarzeń (logging) jako czarna skrzynka samolotu

Przy wysokim ryzyku logi przestają być wyłącznie narzędziem dla devopsów. Stają się czarną skrzynką, która pozwala odtworzyć przebieg zdarzeń przy incydencie. W logach powinny znaleźć się m.in.:

• identyfikator modelu/wersji, która wygenerowała dany wynik,
• timestamp i kluczowe parametry wejściowe (lub ich skróty, jeśli dane są wrażliwe),
• wynik modelu (np. decyzja, prawdopodobieństwo),
• informacja, co zrobił człowiek – potwierdził, zmienił, zablokował.

To oczywiście trzeba zderzyć z RODO i bezpieczeństwem – nie wszystko da się logować wprost. Często stosuje się pseudonimizację (zastępowanie danych identyfikujących technicznymi identyfikatorami) oraz limitowanie czasu przechowywania logów