Zakazane praktyki AI: praktyczny przewodnik dla zespolow SaaS

Zakazane praktyki AI to zastosowania AI, ktore zespol SaaS powinien zablokowac, zanim trafia do klienta, pracownika, workflow vendora albo procesu wewnetrznego. Article 5 EU AI Act obejmuje ograniczony zestaw praktyk uznanych za niedopuszczalne, w tym szkodliwa manipulacje, wykorzystywanie podatnosci, niektore formy social scoring, okreslone zastosowania predykcji ryzyka karnego, nieukierunkowane scrapowanie obrazow twarzy, rozpoznawanie emocji w pracy i edukacji, wrazliwa kategoryzacje biometryczna oraz zdalna identyfikacje biometryczna w czasie rzeczywistym w miejscach publicznych dla law enforcement, poza waskimi wyjatkami.

Praktyczna odpowiedz jest prosta: nie czekac, az prawnik sprawdzi gotowa funkcje. Zbudujcie screen przed launchem, ktory pyta, czy use case AI moze wpasc w zakazana kategorie, blokuje oczywiste przypadki, eskaluje watpliwe i zachowuje dowody decyzji. Powinien obejmowac funkcje produktu, narzedzia wewnetrzne, wbudowane systemy vendorow, integracje modeli i automatyzacje konfigurowalne przez klienta.

Dlaczego to ma znaczenie

Screening zakazanych praktyk jest pierwsza brama AI governance. Jesli use case jest zakazany, zespol nie powinien budowac wokol niego zwyklych kontroli. Wlasciwa reakcja to zatrzymac, przeprojektowac, zwezic albo eskalowac, zanim praca zostanie wpisana w roadmap albo zobowiazanie wobec klienta.

W SaaS AI czesto wchodzi po cichu: nudges w produkcie, scoring kont, HR analytics, narzedzia vendorow albo moduly biometryczne w platformach juz uzywanych przez firme. Mala zmiana w tickecie moze zmienic profil regulacyjny i etyczny uslugi.

Co sprawdzic

Przelozcie Article 5 na pytania operacyjne. Czy system uzywa ukrytych, manipulacyjnych albo mylacych technik, ktore moga istotnie wplynac na decyzje i spowodowac znaczna szkode? Czy wykorzystuje podatnosci wynikajace z wieku, niepelnosprawnosci albo sytuacji spolecznej lub ekonomicznej? Czy ocenia osoby miedzy kontekstami? Czy obejmuje social scoring, predykcje karna oparta wylacznie na profilingu, bazy rozpoznawania twarzy ze scrapingu, rozpoznawanie emocji w pracy lub edukacji, wrazliwa inferencje biometryczna albo zdalna identyfikacje biometryczna?

Nazwa modelu nie wystarczy. Licza sie cel, kontekst, dane, osoby dotkniete i efekt outputu.

Praktyczny workflow

Dodajcie pytania AI do product review, vendor review, security review, privacy review i zatwierdzania narzedzi wewnetrznych. Nie pytajcie tylko, czy cos jest zakazane. Pytajcie, co robi system, kogo dotyczy, jakich danych uzywa, czy wplywa na decyzje, czy przetwarza biometrie, czy rozpoznaje emocje i czy dotyczy pracy, edukacji, kredytu, uslug podstawowych, law enforcement albo bezpieczenstwa publicznego.

Jasne odpowiedzi "nie" moga przejsc do zwyklej klasyfikacji AI i risk review. Jasne odpowiedzi "tak" powinny zatrzymac prace, dopoki legal i compliance nie zatwierdza redesignu albo nie potwierdza, ze przypadek jest poza zakazem. Watpliwe odpowiedzi trafiaja do wskazanego reviewera.

Decyzja powinna obejmowac system, ownera, vendora, cel, osoby dotkniete, dane, geografie, role w AI Act, pytania Article 5, wniosek, uzasadnienie, wymagane zmiany, approvera i trigger ponownej review.

Dowody

Zachowajcie intake, opis produktu lub vendora, notatke data flow, analize osob dotknietych, screenshoty lub konfiguracje, decyzje, uzasadnienie, reviewera, date i dzialania redesignu. Przy vendorze zachowajcie dokumentacje AI, zobowiazania umowne i odpowiedzi o biometrii, emotion recognition, profilingu, treningu modeli i manipulacji uzytkownikami.

Dowody powinny tez pokazywac, kiedy decyzja zostanie otwarta ponownie: nowy cel, nowa grupa uzytkownikow, nowy rynek, nowe zrodla danych, zmiana human review, konfiguracja klienta albo nowe wytyczne.

Typowe bledy

Pierwszy blad to review zbyt pozno. Gdy funkcja jest prawie gotowa, design, umowa, messaging i engineering moga juz opierac sie na blednym zalozeniu. Drugi blad to sprawdzanie tylko funkcji customer-facing. Narzedzia wewnetrzne tez moga tworzyc ryzyko, gdy dotykaja pracownikow, kandydatow, szkolen, produktywnosci, fraudu, supportu lub security.

Nie polegajcie na etykietach vendorow typu insight, sentiment, safety czy personalization. Pytanie brzmi, co system faktycznie robi i jak wplywa na ludzi. Human in the loop moze pomoc, ale nie naprawia automatycznie zakazanej manipulacji ani wrazliwej inferencji biometrycznej.

FAQ

Jaki jest praktyczny cel?

Zidentyfikowac zastosowania AI, ktore trzeba zablokowac, przeprojektowac lub eskalowac, zanim wejda do produktu, workflow vendora albo procesu wewnetrznego.

Kiedy dotyczy to SaaS?

Gdy zespol buduje, kupuje, osadza, sprzedaje, konfiguruje lub uzywa AI, ktora moze dotykac kategorii Article 5.

Co udokumentowac najpierw?

Intake, decision record, wskazanego reviewera i launch gate polaczony z product, vendor, privacy, security i customer trust.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission guidelines on prohibited artificial intelligence practices.
• European Commission studies on Article 5 of the AI Act.