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:
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:
Zmapuj use case’y – wypisz konkretne zastosowania Twojego systemu (co dokładnie robi u klienta, w jakim procesie biznesowym).
Przypisz im „kolor ryzyka” – czerwony (podejrzenie zakazu), pomarańczowy (może być wysokie ryzyko), żółty (przejrzystość), zielony (niskie).
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”.
Źródło: Pexels | Autor: Markus Winkler
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.
Rejestracja i „compliance UX”: jak nie zabić się papierologią
Systemy wysokiego ryzyka trzeba będzie rejestrować w unijnym rejestrze. Będzie to wymagało spójnej paczki informacji o systemie. W praktyce mądrze jest budować „compliance UX” od razu w narzędziach, z których i tak korzystacie:
w repozytorium kodu – krótkie pliki opisujące, który serwis odpowiada za jaką funkcję AI,
w Notion / Confluence – szablony opisów modeli, eksperymentów, testów, decyzji o zmianach,
w narzędziach MLOps – automatyczne zbieranie metadanych o treningach i deploymentach.
To zmniejsza ból przy pierwszym „prawdziwym” audycie zewnętrznym – wiele odpowiedzi będzie już w systemie, a nie w głowie senior developera.
Dane treningowe i testowe: jak posprzątać i opisać dane
Mapa danych: skąd co pochodzi i do czego jest używane
Dobrym punktem startu jest prosta mapa danych. Nie chodzi o akademicki diagram, tylko przejrzystą listę:
jakie zbiory danych istnieją (np. „zgłoszenia supportowe 2019–2022”, „historia transakcji demo”),
skąd pochodzą (klienci, dane publiczne, dane kupione, syntetyczne),
Źródła danych a zgody, licencje i „łańcuch dostaw”
Kiedy już wiadomo, jakie zbiory istnieją, trzeba zadać sobie mniej wygodne pytanie: czy w ogóle wolno ich używać w tym celu. AI Act mocno akcentuje tzw. łańcuch dostaw danych – czyli kto, komu, na jakich warunkach dane przekazał i do czego miały służyć.
Przydatne jest krótkie „metryczkowanie” każdego zbioru danych. Przy każdym wpisie na mapie danych dopisz kilka kluczowych pól:
podstawa prawna użycia (np. zgoda użytkownika, uzasadniony interes, licencja komercyjna),
zakres dopuszczalnego użycia – czy można trenować modele, czy tylko analizować zagregowane statystyki,
ograniczenia terytorialne (np. dane spoza EOG, transfery do USA),
czy w zbiorze są dane wrażliwe (zdrowotne, poglądy, biometria itd.),
czy istnieją umowy z dostawcami danych i co mówią o trenowaniu AI.
W małym startupie taka metryczka może mieć formę prostego arkusza w Notionie czy Google Sheets. Ważne, by dało się na jej podstawie szybko odpowiedzieć inwestorowi lub audytorowi: „tak, ten model był trenowany wyłącznie na danych, do których mamy prawa”.
Częsty problem: dane z „darmowych” źródeł. Jeśli ktoś kiedyś skleił dataset z internetu (fora, blogi, Githuby), to trzeba sprawdzić, czy licencje tych źródeł faktycznie dopuszczają komercyjne trenowanie AI. AI Act nie zastępuje prawa autorskiego – raczej sprawia, że pytanie o prawa do danych pojawi się częściej i w bardziej formalnej formie.
Anonimizacja, pseudonimizacja i minimalizacja danych
Przy danych osobowych AI Act i RODO spotykają się w jednym punkcie: im mniej danych identyfikujących człowieka, tym lepiej. Z perspektywy produktu chodzi nie tylko o „usunięcie PESELu”, ale o to, by model nie pamiętał niepotrzebnych szczegółów o konkretnych osobach.
W praktyce sensowne podejście to kombinacja trzech technik:
minimalizacja – trening tylko na tych polach, które faktycznie poprawiają jakość modelu; jeśli kod pocztowy nic nie wnosi, to po co go przetwarzać,
pseudonimizacja – zastąpienie identyfikatorów (e-mail, numer klienta) losowymi identyfikatorami technicznymi,
anonimizacja próbek – tam, gdzie to możliwe, całkowite usunięcie informacji pozwalających na identyfikację osoby, a nie tylko schowanie ich za ID.
Dobrym nawykiem jest eksperyment: zrób dwie wersje treningu – z pełnym zestawem pól i z odchudzonym, bez oczywiście zbędnych danych osobowych. Jeśli różnica w jakości predykcji jest symboliczna, zachowaj prostszy, „lżejszy” wariant. Podczas audytu pokazujesz wtedy nie tylko, że zgodnie z prawem ograniczyłeś dane, ale też że przetestowałeś wpływ tego ograniczenia na jakość.
Różnorodność danych i testy pod kątem uprzedzeń
AI Act oczekuje, że systemy – szczególnie wysokiego ryzyka – będą testowane pod kątem biasu, czyli nierównego traktowania różnych grup. Z perspektywy startupu najważniejsze jest zadanie: „czy mój model nie psuje się dramatycznie dla jakiejś grupy użytkowników?”.
Nie trzeba od razu budować pełnego laboratorium etycznego. Wystarczy prosty, ale systematyczny workflow:
zidentyfikuj kluczowe grupy w danych (np. różne segmenty klientów, kraje, typy firm),
policz podstawowe metryki jakości (np. dokładność, precision/recall) osobno dla tych grup,
zapisz wyniki i decyzję: „akceptujemy różnicę” albo „musimy dobrać dane / poprawić model”.
Jeżeli przetwarzasz dane osobowe z cechami wrażliwymi (np. płeć, wiek, niepełnosprawność), sytuacja robi się delikatna. Czasem nie możesz legalnie mieć tych cech w danych, a jednocześnie musisz ocenić, czy system tych grup nie dyskryminuje. Wtedy pomocą są audyty z wykorzystaniem danych syntetycznych albo symulacje budowane na testowych kontach/wnioskach, które odzwierciedlają różne scenariusze, ale nie opisują realnych osób.
„Datasheety” i karty danych: opis zamiast magii
Żeby nie kończyć z chaosem w stylu „tu jest folder z CSV-kami, powodzenia”, przydają się karty danych (często nazywane datasheetami). To prosty dokument opisujący zbiór danych i sposób jego przygotowania.
Taka karta danych może mieć formę kilku sekcji:
Opis celu – do czego ten zbiór jest używany (np. trening modelu scoringowego, testy regresji, walidacja QA).
Zakres – okno czasowe, liczba rekordów, główne typy pól.
Źródła i przetwarzanie – skąd dane pochodzą, jakie transformacje zastosowano (czyszczenie, agregacja, anonimizacja).
Jakość i ograniczenia – znane problemy, brakujące pola, zidentyfikowane skrzywienia (np. nadreprezentacja jednego kraju).
Odpowiedzialni – kto utrzymuje zbiór, kiedy był ostatnio aktualizowany, gdzie zgłaszać błędy.
W startupie to może być dosłownie jedna strona w Notionie do każdego istotnego zbioru. Kluczowe jest to, że jeśli jutro dołączy nowy ML engineer albo zewnętrzny audytor, nie musi zgadywać, co jest w środku.
Strategia wersjonowania danych i powtarzalne eksperymenty
AI Act kładzie nacisk na powtarzalność – jeśli model podejmie błędną decyzję, trzeba umieć odtworzyć, jak został nauczony. W praktyce oznacza to, że tak samo jak wersjonujesz kod, powinieneś wersjonować dane treningowe i konfigurację treningów.
Nie chodzi o to, by nigdy niczego nie usuwać. Bardziej o to, żeby móc odpowiedzieć na pytania typu: „na jakich danych trenowaliśmy model 1.3.5 i czym różniły się one od 1.3.4?”.
Pomagają w tym proste praktyki:
oznaczanie snapshotów zbiorów – np. datą i krótkim opisem („train_set_2024-05_clean_v2”),
zapisywanie w repozytorium lub narzędziu MLOps metryk i parametrów każdego treningu (hyperparametry, zestaw feature’ów, link do datasheetu),
utrzymywanie minimalnego zestawu testów regresyjnych – stały zbiór próbek, na którym porównujesz zachowanie kolejnych wersji modelu.
Przy incydencie (np. klient kwestionuje decyzję systemu) możesz wtedy zrekonstruować: „ten wynik wygenerował model v1.3.5, trenowany na zbiorze X, o takich parametrach; tu są testy, które pokazywały jego zachowanie przed wdrożeniem”. Dla regulatora i dużego klienta taka ścieżka jest znacznie bardziej przekonująca niż ogólne „model poprawiliśmy, proszę nam zaufać”.
Testy scenariuszowe zamiast samych metryk
Klasyczne metryki typu accuracy czy F1 nie pokazują pełnego obrazu ryzyka. AI Act zachęca do testów scenariuszowych – czyli sprawdzania, co system zrobi w konkretnych, biznesowo ważnych sytuacjach.
Dobrym sposobem jest zdefiniowanie kilkunastu–kilkudziesięciu scenariuszy, które naprawdę bolą, gdy pójdą źle. Przykładowo:
„Klient z dobrą historią płatniczą, ale niestandardowym źródłem dochodu” – jak model kredytuje ten przypadek?
„Pracownik zgłasza mobbing w nietypowych słowach” – system moderacji to wychwyci czy zignoruje?
„Zdjęcie dokumentu słabej jakości, ale czytelne dla człowieka” – czy system uznaje je za ważne, czy odrzuca?
Te scenariusze można zapisać jako testy regresyjne i włączać do pipeline’u CI/CD. Każda nowa wersja modelu musi je „zaliczyć”, inaczej nie trafia na produkcję. Takie testy są też świetnym materiałem dowodowym podczas audytu: pokazujesz, że nie tylko liczysz metryki, ale symulujesz realne, krytyczne przypadki.
Dokumentacja techniczna i rejestry: jak ugryźć „papierologię”
Jak wygląda „pakiet dokumentacyjny” systemu AI
AI Act przewiduje dość konkretne oczekiwania wobec dokumentacji technicznej. Nie trzeba ich jednak spełniać jednym, gigantycznym plikiem PDF. Z praktycznego punktu widzenia lepiej myśleć o „pakiecie dokumentacyjnym”, który składa się z kilku logicznych części.
Typowe elementy takiego pakietu to:
opis systemu – co robi, dla kogo, w jakim kontekście biznesowym działa,
architektura techniczna – schemat usług, komponentów AI, zależności i punktów integracji,
specyfikacja modelu – typ modelu, użyte algorytmy, główne cechy wejściowe, sposób trenowania,
opis danych – powiązane datasheety, sposób przygotowania danych treningowych i testowych,
wyniki oceny ryzyka – główne scenariusze ryzyka i podjęte środki zaradcze,
plan monitoringu – jakie metryki są śledzone po wdrożeniu, jak wygląda proces reagowania na incydenty.
W startupie większość z tych informacji i tak istnieje – w ticketach Jiry, dokumentach produktowych, diagramach w Miro. Sztuka polega na tym, by je zebrać i domknąć luki, a nie wymyślać wszystko od zera.
Jedno źródło prawdy: jak nie utopić się w wersjach
Największym wrogiem sensownej dokumentacji nie jest brak treści, ale brak porządku. Dwie wersje tego samego diagramu, trzy różne opisy modelu, pięć nieaktualnych tabel w Excelu – to przepis na porażkę przy pierwszym większym audycie lub due diligence.
Bez wielkiej biurokracji można wprowadzić kilka zasad:
wskazać jedno narzędzie jako „źródło prawdy” dla dokumentacji (np. Notion / Confluence) i konsekwentnie tam trzymać kluczowe opisy,
oznaczać dokumenty wersjami i datą aktualizacji („AI-System-Scoring-v1.2 – updated 2026-05-10”),
utrzymywać krótką, centralną stronę „Index systemu AI” z linkami do: architektury, karty modelu, datasheetów, procedur ryzyka.
Dzięki temu, gdy ktoś z zewnątrz poprosi o „dokumentację systemu AI”, wysyłasz jeden link do indeksu, a nie paczkę luźnych plików. To robi ogromną różnicę w odbiorze – nawet jeśli same dokumenty nie są jeszcze w wersji „enterprise grade”.
Karta systemu AI: wizytówka dla audytora i klienta
Przydatnym wynalazkiem jest karta systemu AI (czasem nazywana system card). To krótki, maksymalnie 2–3 stronicowy opis konkretnego systemu, napisany ludzkim językiem, ale zawierający też techniczne szczegóły.
Taka karta może zawierać m.in.:
cel biznesowy – co system ma osiągać i w jakich procesach jest używany,
główne funkcje AI – na jakich krokach procesu pojawia się model,
klasa ryzyka wg AI Act – z krótkim uzasadnieniem,
zakres danych wejściowych – typy danych, źródła, zakres czasowy,
limity i znane ograniczenia – kiedy system nie powinien być stosowany,
kontakt i odpowiedzialności – kto odpowiada za model, produkt, infrastrukturę.
Z punktu widzenia sprzedaży i customer success taka karta to kapitalne narzędzie: można ją dołączyć do ofert, odpowiedzi na RFP czy przetargi. Z punktu widzenia AI Act stanowi natomiast czytelny punkt wyjścia do głębszej dokumentacji.
Rejestr modeli i wersji: co działa na produkcji, a co w labie
Nawet w niedużym startupie po roku–dwóch pracy zaczyna się gromadzić niezła kolekcja modeli: wersje A/B, prototypy, backupy. Bez prostego rejestru łatwo o sytuację, w której nikt do końca nie wie, jaka wersja modelu faktycznie podejmuje decyzje u klientów.
Rejestr modeli nie musi być skomplikowany. W wielu zespołach wystarczy tabela z kolumnami:
nazwa systemu (powiązana z kartą systemu AI),
id i wersja modelu (np. fraud_model_v1.4.2),
status (produkcyjny, w testach, wycofany),
okres użycia w produkcji (od–do),
link do dokumentacji (opis treningu, datasheety, wyniki testów),
Najczęściej zadawane pytania (FAQ)
Czy mój mały startup w ogóle podlega AI Act?
Niemal na pewno tak, jeśli w produkcie pojawia się jakakolwiek automatyczna analiza danych, uczenie maszynowe, zaawansowana statystyka czy system reguł podejmujący decyzje lub rekomendacje. AI Act nie rozróżnia „małego” i „dużego” w sensie obowiązywania przepisów – liczy się to, co Twój system robi i jaki ma wpływ na ludzi.
Ulgi dla MŚP dotyczą głównie formy (wsparcie, piaskownice regulacyjne, proporcjonalne podejście do procedur), a nie samego faktu bycia objętym regulacją. Jednoosobowy SaaS do preselekcji CV może mieć takie same obowiązki jak globalny gracz, jeśli wpływa na decyzje rekrutacyjne.
Jak sprawdzić, czy mój produkt jest „systemem AI” w rozumieniu AI Act?
Najprostszy test: czy Twój system sam generuje wynik na podstawie danych (decyzję, klasyfikację, rekomendację, prognozę, treść), a człowiek nie klika za każdym razem „jeśli A, zrób B”? Jeśli wykorzystujesz model ML, zaawansowaną statystykę lub złożony silnik reguł, prawdopodobnie wchodzisz w definicję systemu AI.
Klasyczny CRM z prostymi if/else i stałymi progami nie będzie systemem AI. Ale już moduł, który przewiduje churn klientów, punktuje kandydatów do pracy albo ustala ranking ofert na bazie wielu sygnałów, w większości przypadków tak. Granica nie zależy od nazwy technologii w marketingu, tylko od faktycznego sposobu działania.
Czy użycie zewnętrznego API (np. modelu językowego w chmurze) zwalnia mnie z obowiązków AI Act?
Nie. Jeśli oferujesz własną funkcję biznesową opartą na zewnętrznym modelu (np. API do analizy zgłoszeń klientów, które pod spodem korzysta z LLM), w świetle AI Act wciąż jesteś dostawcą systemu AI. To Ty definiujesz, jak model jest używany, jaki ma interfejs, ograniczenia i do jakich decyzji prowadzi.
To oznacza własne obowiązki: dokumentację Twojego systemu, ocenę ryzyka, przejrzyste oznaczenie funkcji AI, mechanizmy nadzoru człowieka. Dostawca modelu bazowego ma swoje wymogi, ale nie „przejmuje” tych, które dotyczą Twojej końcowej aplikacji.
Jakie obowiązki ma typowy SaaS z modułem AI o niskim ryzyku?
Dla zastosowań niskiego ryzyka kluczowe są przejrzystość i podstawowa „higiena” techniczna. Użytkownik powinien wiedzieć, kiedy w produkcie działa AI, mieć możliwość wyłączenia lub obejścia modułu oraz rozumieć, jakiego typu wynik dostaje (np. sugestia, a nie ostateczna decyzja).
Z technicznego punktu widzenia przydaje się minimum: opis danych i modeli, logowanie kluczowych decyzji, prosta dokumentacja architektury, informacje o ograniczeniach systemu. To ułatwia zarówno spełnienie wymogów AI Act, jak i późniejsze wyjaśnianie błędów klientom lub regulatorowi.
Kiedy realnie muszę mieć wszystko zgodne z AI Act w startupie?
Harmonogram jest rozłożony na etapy. Najpierw, w ciągu kilku miesięcy, zaczynają obowiązywać zakazy najbardziej ryzykownych praktyk (np. niektóre formy social scoringu). Kluczowe obowiązki dla systemów wysokiego ryzyka wchodzą zwykle w okolicy 12–24 miesięcy od wejścia w życie regulacji.
Z perspektywy startupu lepiej założyć, że okno na spokojne wdrożenie to kilkanaście miesięcy. Jeśli dopiero wtedy zaczniesz tworzyć dokumentację i procesy dla istniejącego już systemu, praca będzie znacznie trudniejsza niż wbudowanie wymogów od początku w rozwój produktu.
Czym różni się „zwykłe oprogramowanie” od systemu AI według AI Act?
„Zwykłe oprogramowanie” działa według prostych, z góry ustalonych reguł: jeśli spełniony jest warunek, wykonaj akcję. System AI uczy się wzorców z danych lub wykorzystuje bardzo złożone reguły tak, że nawet twórcy nie są w stanie łatwo przewidzieć każdego wyniku.
Przykład: prosty skrypt, który po 30 dniach od nieopłaconej faktury wysyła przypomnienie, nie jest AI. Natomiast model, który ocenia prawdopodobieństwo, że klient zapłaci w terminie na podstawie historii zachowań i na tej podstawie dobiera strategię kontaktu, jest typowym systemem AI w rozumieniu AI Act.
Czy wielkość firmy wpływa na moje obowiązki w AI Act?
Podstawowe obowiązki wynikają z poziomu ryzyka zastosowania, nie z liczby pracowników. System HR do oceny kandydatów będzie wysokiego ryzyka niezależnie od tego, czy tworzy go korporacja, czy dwuosobowy startup, więc wymogi co do jakości danych, nadzoru człowieka czy dokumentacji są podobne.
Różnica polega na tym, że MŚP mogą liczyć na wsparcie: piaskownice regulacyjne, materiały wyjaśniające, czasem lżejsze procedury przy zachowaniu tego samego poziomu bezpieczeństwa. To raczej „ułatwienie dojścia do celu”, a nie zwolnienie z samego celu.
