Ład AI i danych w sprzedaży: przypadek użycia, ryzyko, kontrola i wycofanie

Polityka jest potrzebna, ale nie opisuje faktycznego działania systemu. Może zakazać używania danych poufnych, a jednocześnie nie wskazywać, że rozszerzenie przeglądarki przesyła fragmenty CRM do zewnętrznego podmiotu przetwarzającego. Może wymagać przeglądu przez człowieka, lecz nie określać, czy osoba dokonująca przeglądu widzi źródła, ma czas na ocenę i może zatrzymać skutek. Może nakazywać rejestrowanie systemów, ale nie rozróżniać tego samego produktu używanego do researchu, tworzenia oferty, kwalifikacji leadu i oceny pracownika.

Jednostką ładu nie powinien być sam dostawca ani nazwa aplikacji. Jeden produkt może obsługiwać wiele przypadków użycia o różnych danych, osobach, skutkach i obowiązkach. Z kolei jeden przypadek użycia może obejmować kilka modeli, integracji, baz danych i podmiotów w łańcuchu dostaw. Inwentarz musi więc rejestrować konkretny sposób użycia, a nie tylko zakupiony produkt.⁴⁵

Dobry rekord inwentarza odpowiada co najmniej na pytania:

• jaki problem ma zostać rozwiązany;
• jaki jest dokładny cel i zakres;
• kto używa systemu, a kto ponosi skutek;
• jakie dane wchodzą, jakie wyniki wychodzą i gdzie są zapisywane;
• kto jest właścicielem biznesowym, właścicielem danych i właścicielem systemowym;
• kto może autoryzować, zatrzymać i wycofać przypadek użycia;
• jakie role prawne i kontraktowe występują w łańcuchu dostaw;
• jakie ograniczenia, zakazy, testy i warunki obowiązują;
• co uruchamia ponowną ocenę;
• gdzie pozostaną wyniki po wygaszeniu.

Inwentarz nie jest zatwierdzeniem. Jego funkcją jest uczynienie obiektu widocznym i audytowalnym. Dopiero wtedy można sensownie ustalać klasyfikację, wymagania, testy i mandat. Modele zarządzania ryzykiem, takie jak NIST AI RMF, również zaczynają od ładu, kontekstu i mapowania zastosowania, a nie od jednego wyniku liczbowego.⁶

Kontrolowany obiekt J06 ma postać:

Przypadek użycia powinien dać się opisać jednym zdaniem zawierającym użytkownika, zadanie, wejście, wynik i skutek. „AI w sprzedaży” jest zbyt szerokie. „Tworzenie wersji roboczej podsumowania spotkania z cytatami z zatwierdzonej transkrypcji, bez automatycznego zapisu do CRM” jest obiektem możliwym do zaprojektowania i przetestowania.

Granica obejmuje także wyłączenia. Jeżeli system może generować wersję roboczą wiadomości, rekord powinien wyraźnie zabraniać autonomicznej wysyłki, obietnic handlowych i aktualizacji prognozy. Jeżeli model wspiera research, nie powinien cicho przechodzić do profilowania, punktacji albo decyzji kadrowych. Zmiana zamierzonego celu jest zmianą istotną, a nie zwykłym rozszerzeniem funkcji.

Wcześniejsze moduły projektu ustanawiają potrzebne granice. Architektura technologii sprzedaży określa role systemów, dostęp, obserwowalność i wyjście.⁷ CRM jako system decyzji rozdziela rekord, źródło, przepływ pracy, korektę i użycie wtórne.⁸ AI w pracy handlowca projektuje jedno zadanie wspierane przez AI, a Karta Przypadku Użycia AI w Pracy Handlowca porządkuje jego lokalne źródła, wynik i przegląd.⁹ J06 nie zastępuje tych modeli. Utrzymuje nadrzędny rekord ładu i cykl życia zastosowania.

Nie każdy algorytm, przepływ pracy ani system raportowy jest systemem AI w rozumieniu właściwego prawa. Jednocześnie etykieta „nie używamy AI, tylko reguł” nie kończy ładu danych, bezpieczeństwa, ochrony danych, spraw pracowniczych albo wpływu na klienta. Organizacja musi opisać funkcję i zamierzony cel, a następnie zastosować właściwe reżimy — nie odwrotnie.

Komisja Europejska opublikowała niewiążące wytyczne dotyczące definicji systemu AI, aby ułatwić stosowanie pierwszych przepisów AI Act. Wytyczne pomagają analizować cechy systemu, lecz nie zastępują oceny konkretnego rozwiązania, integracji i celu.⁵ AI Act stosuje się etapowo i zawiera wyjątki oraz zróżnicowane daty. Zakazane praktyki i obowiązki AI literacy zaczęły obowiązywać wcześniej, obowiązki dla dostawców GPAI od 2 sierpnia 2025 r., a obowiązki przejrzystości z art. 50 mają być stosowane od 2 sierpnia 2026 r. Część terminów dotyczących systemów wysokiego ryzyka może przypadać później, dlatego przed publikacją lub wdrożeniem trzeba sprawdzić aktualny tekst i oficjalne materiały.^410111213

Klasyfikacja powinna rozdzielać co najmniej cztery pytania:

1. Czy obiekt spełnia właściwą definicję systemu AI?
2. Jaka jest rola organizacji i innych podmiotów w łańcuchu?
3. Czy dokładny zamierzony cel wchodzi do szczególnej kategorii lub zakazu?
4. Jakie inne przepisy i zobowiązania stosują się niezależnie od AI Act?

RODO, prawo pracy, tajemnica przedsiębiorstwa, umowy, Data Act, cyberbezpieczeństwo i przepisy sektorowe mogą mieć zastosowanie również wtedy, gdy system nie jest AI albo nie jest systemem wysokiego ryzyka.^14151617

Model GAD porządkuje cykl życia, ale nie jest drabiną dojrzałości. Przypadek użycia może przejść z testów do pilota, wrócić do przeprojektowania, zostać zatrzymany po incydencie albo zakończyć się decyzją NO AI. Każdy krok ma własny obiekt, dowody i właściciela:

1. GAD-1 — Inwentarz, właściciel, cel i zakres. Co dokładnie istnieje i po co?
2. GAD-2 — Rola systemu, dostawca, podmiot stosujący i łańcuch dostaw. Kto robi co, gdzie działa system i jak się zmienia?
3. GAD-3 — Kategorie danych, źródło, podstawa prawna i uprawnienia. Jakie dane są używane i na jakich warunkach?
4. GAD-4 — Klasyfikacja ryzyka, osoby dotknięte i wpływ. Kto może ponieść skutek i jakiego rodzaju?
5. GAD-5 — Wymagania, użycia zakazane i cele kontrolne. Co musi być spełnione, a czego nie wolno robić?
6. GAD-6 — Testy, ocena, red team i dokumentacja. Jakie dowody potwierdzają lub obalają przydatność do użycia?
7. GAD-7 — Nadzór człowieka, możliwość zakwestionowania i autoryzacja. Kto może ocenić, odrzucić, poprawić i autoryzować?
8. GAD-8 — Monitoring, dzienniki, incydent i powiadomienia. Jak wykrywać degradację, błąd i użycie poza zakresem?
9. GAD-9 — Zmiana, dryf, aktualizacja dostawcy i ponowna walidacja. Która zmiana unieważnia wcześniejsze założenia?
10. GAD-10 — Wygaszenie, usunięcie, wycofanie i propagacja. Jak zatrzymać nowe użycie i skorygować skutki w dole strumienia?

Pętla powinna być wersjonowana. Zmiana celu, modelu albo danych tworzy nową wersję rekordu i może zmienić status. Nieudane testy, wyjątki oraz wygasłe decyzje pozostają widoczne; ich usunięcie niszczyłoby ślad audytowy. ISO/IEC 42001 i ISO/IEC 23894 wspierają systemowe podejście do ról, ryzyka, kontroli, monitorowania i ciągłego doskonalenia, lecz nie nadają automatycznie zgodności konkretnemu przypadkowi użycia.¹⁸¹⁹

GAD-1 tworzy minimalny rekord identyfikujący przypadek użycia. Powinien zawierać problem, dokładny cel, użytkowników, osoby dotknięte, oczekiwany wynik, zakres geograficzny i procesowy, wyłączenia, właścicieli, zależności, status oraz datę kolejnego przeglądu.

Cel musi być wystarczająco wąski, aby można było sprawdzić niezbędność i proporcjonalność. „Zwiększenie skuteczności sprzedaży” nie wystarcza. „Przygotowanie roboczej wersji briefingu przed spotkaniem z pięciu zatwierdzonych źródeł” daje się porównać z alternatywą ręczną i ocenić przez wsparcie źródłowe, czas, błędy oraz obciążenie osoby dokonującej przeglądu.

Właściciel biznesowy odpowiada za problem, oczekiwany wynik i użycie wyniku. Nie powinien jednocześnie samodzielnie potwierdzać podstawy prawnej, bezpieczeństwa albo zgodności w sprawach pracowniczych, jeżeli nie ma odpowiedniej kompetencji i mandatu. Ład nie centralizuje wszystkich decyzji w jednym komitecie; kieruje je do właściwych właścicieli i osób dokonujących przeglądu.

Przykład syntetyczny 1 — podsumowanie spotkania zapisuje fikcyjne zobowiązania. Asystent generuje notatkę, a integracja aktualizuje CRM i prognozę. Inwentarz ujawnia, że pierwotnym celem miała być wersja robocza dla handlowca, lecz realny zakres obejmuje autonomiczny zapis i skutek analityczny. Osoba dokonująca przeglądu ma trzy sekundy na kliknięcie. Wynik: rozdzielenie wersji roboczej od zapisu, status HOLD, test wierności źródłowej oraz realny punkt kontrolny. Płynny wynik nie jest dowodem po stronie klienta.⁹

Dobrze zdefiniowany GAD-1 może zakończyć się decyzją NON_AI_ALTERNATIVE. Jeżeli problemem jest brak standardu notatki, prosty formularz może być lepszy niż model generatywny. Ład ma prawo redukować technologię, nie tylko ją zatwierdzać.

Nazwa handlowa nie określa roli prawnej ani operacyjnej. Organizacja może być podmiotem stosującym standardową usługę, ale po zmianie zamierzonego celu, integracji, dostrojeniu, rebrandingu albo udostępnieniu systemu innym podmiotom analiza może się zmienić. Trzeba opisać fakty, a nie etykiety z umowy marketingowej.⁴⁵

Mapa łańcucha dostaw powinna obejmować:

• produkt, model, wersję i konfigurację;
• dostawcę, integratora i resellerów;
• role dostawcy i podmiotu stosującego oraz ich ograniczenia;
• role administratora i podmiotu przetwarzającego, podprzetwarzających i transfery;
• hosting, lokalizację danych, logi i dostęp wsparcia;
• mechanizm aktualizacji modelu, API i polityk;
• okres wypowiedzenia dla zmian istotnych;
• dowody audytowe, ścieżkę incydentu i ścieżkę wyjścia;
• możliwość eksportu konfiguracji, danych, logów i historii decyzji.

Zapewnienie dostawcy jest wejściem, nie lokalnym zatwierdzeniem. Certyfikat może dotyczyć systemu zarządzania, określonego środowiska albo daty audytu i nie dowodzi, że lokalny przypadek użycia, dane oraz integracje są właściwe. Dobrowolny Code of Practice dla GPAI może wspierać dostawców modeli w realizacji ich obowiązków, ale nie zastępuje oceny podmiotu stosującego ani lokalnych testów.²⁰

Przykład syntetyczny 2 — wzbogacanie danych bez pochodzenia. Zespół sprzedaży importuje prywatne adresy i stanowiska z usługi wzbogacania danych. Dostawca nie ujawnia śladu źródłowego, transferów ani skutecznej ścieżki usunięcia. Dział zakupów zaakceptował cenę i SLA, lecz przypadek użycia nie ma potwierdzonych uprawnień. Wynik: VENDOR_AND_PROCUREMENT_HOLD, analiza ról, umów, źródeł i usunięcia danych przed jakimkolwiek aktywnym użyciem.

Łańcuch dostaw jest dynamiczny. Zmiana subprocesora, regionu hostingu albo modelu bazowego może uruchomić ponowną walidację, nawet jeżeli nazwa produktu się nie zmieniła.

Dane nie stają się dozwolone dlatego, że są publiczne, dostępne przez API albo obecne w CRM. Każde wejście potrzebuje źródła, właściciela, kategorii, zamierzonego użycia, podstawy lub uprawnienia, jakości, aktualności, wrażliwości, transferu, retencji i warunku wycofania.

RODO wymaga między innymi ograniczenia celu, minimalizacji danych, przejrzystości, bezpieczeństwa i rozliczalności. Nie daje jednej uniwersalnej podstawy prawnej dla „AI”. EDPB w Opinii 28/2024 podkreśla, że anonimowość modelu i możliwość oparcia przetwarzania na uzasadnionym interesie wymagają analizy konkretnego modelu i okoliczności; nie można ich zakładać z samego oświadczenia dostawcy.¹⁴²¹

Rejestr danych powinien rozdzielać:

• dane osobowe, poufne, handlowe i objęte IP;
• dane klientów, prospektów, pracowników i partnerów;
• dane źródłowe, dane pochodne, embeddingi, logi i wyniki;
• dane syntetyczne i zdeidentyfikowane wraz z ograniczeniami;
• dane używane do budowy, testów, wnioskowania i monitoringu;
• pierwotny cel oraz każde wtórne użycie;
• retencję operacyjną, wstrzymanie na potrzeby audytu i ścieżkę usunięcia.

Przykład syntetyczny 3 — punktacja leadów z danych behawioralnych. Marketing łączy wizyty, otwarcia wiadomości, wzbogacanie danych i dane demograficzne w jeden wynik punktowy. Nie wiadomo, które źródła są dozwolone, jak długo dane są przechowywane i czy wynik zmienia cenę lub priorytet obsługi. Wynik: DATA_PERMISSION_HOLD, rozdzielenie sygnału od intencji klienta oraz ocena osób dotkniętych i możliwości zakwestionowania. Wynik punktowy nie jest zobowiązaniem klienta.

Data Act może wpływać na dostęp, udostępnianie danych i zmianę dostawcy usług w zakresie właściwym dla konkretnego podmiotu i produktu, ale nie stanowi ogólnej licencji na użycie dowolnych danych.¹⁵

Ocena skutków powinna zaczynać się od osób i skutków, nie od jednej liczby. Jedna kategoria „średnie ryzyko” może ukrywać nieporównywalne problemy: ujawnienie tajemnicy, dyskryminujący priorytet obsługi, błędną ofertę, ograniczenie praw pracownika, utratę możliwości zakwestionowania albo propagację fałszywego wyniku do setek rekordów.

Rekord powinien opisać:

• osoby dotknięte i role;
• prawa, interesy i oczekiwania kontekstowe;
• rodzaje szkód: materialne, relacyjne, prawne, bezpieczeństwa i operacyjne;
• prawdopodobną skalę i częstotliwość;
• odwracalność skutku;
• możliwość wykrycia i zakwestionowania;
• nierówne efekty dla relewantnych grup;
• propagację do systemów i decyzji w dole strumienia;
• niewiadome pozostałe oraz wymagane przeglądy specjalistyczne.

Nie należy sumować tych wymiarów do globalnego wyniku punktowego zgodności. Wynik liczbowy może być używany w konkretnym, zwalidowanym modelu, ale nie zastępuje opisu mechanizmu szkody i reguły działania. NIST AI RMF i NIST Generative AI Profile wspierają kontekstowe mapowanie, pomiar oraz zarządzanie ryzykiem, nie automatyczny werdykt.⁶²²

Przykład syntetyczny 4 — wnioskowanie o emocjach handlowców. Dostawca oferuje miary emocji, szczerości i zaangażowania z nagrań rozmów. Manager chce użyć ich w formalnej ocenie pracowniczej. Przypadek użycia dotyczy monitorowania na poziomie osoby, wnioskowania o cechach oraz decyzji kadrowych. Wynik: PROHIBITED_OR_NOT_AUTHORIZED_STOP, odrębny przegląd prawny, ochrony danych, kadrowy i pracowniczy oraz zakaz traktowania wyniku jako dowodu dotyczącego osoby.²³¹⁷

DPIA, gdy jest wymagana, jest procesem identyfikowania i ograniczania wysokiego ryzyka dla osób, a nie formularzem potwierdzającym zgodność. Wzorzec pomaga utrzymać strukturę, lecz nie przesądza wyniku ani dopuszczalności ryzyka pozostałego.²⁴

GAD-5 przekłada klasyfikację oraz wpływ na wymagania operacyjne. Nie wystarczy zapisać „system ma być zgodny, bezpieczny i rzetelny”. Każde wymaganie powinno mieć właściciela, dowód, kryterium akceptacji, datę przeglądu i warunek zatrzymania.

Najpierw należy wyodrębnić użycia zakazane. Zakaz może wynikać z prawa, umowy, polityki, braku mandatu albo świadomej decyzji projektowej. Wytyczne Komisji dotyczące zakazanych praktyk AI pomagają interpretować kategorie i przykłady, ale nie pozwalają na automatyczne rozszerzanie ich poza dokładne fakty.²⁵ Jeżeli przypadek użycia wchodzi w obszar zakazany albo organizacja nie ma mandatu do skutku, właściwym wynikiem jest STOP, nie „więcej kontroli”.

Dla zastosowań dopuszczalnych wymagania mogą obejmować:

• minimalne źródła i ich aktualność;
• ograniczenie celu i populacji;
• zabronione wyniki i działania;
• przegląd przez człowieka oraz rozdzielenie obowiązków;
• przejrzystość wobec użytkownika lub osoby dotkniętej;
• kontrolę dostępu, sekrety, izolację i dzienniki;
• ochronę danych, minimalizację, retencję i usunięcie;
• dokładność, wierność źródłową, odporność i powstrzymanie się;
• dostępność i równoważną ścieżkę bez AI;
• incydent, korektę, powiadomienie i odwołanie;
• powiadomienie dostawcy, przenoszalność i wyjście;
• wygaśnięcie oraz wyzwalacze zmiany istotnej.

AI literacy należy projektować kontekstowo. Obowiązek nie sprowadza się do szkolenia z promptów. Osoba używająca systemu powinna rozumieć jego rolę, ograniczenia, właściwe źródła, ryzyko automation bias, zasady eskalacji oraz skutki błędnego użycia.¹¹

Przykład syntetyczny 5 — autonomiczny follow-up z terminem wdrożenia. Przepływ pracy wysyła klientowi datę uruchomienia po zmianie etapu. Integracja ma techniczne prawo wysyłki, ale nikt nie ma mandatu biznesowego do zobowiązania. Wynik: brama zatrzymania dla działań wobec klienta, wymagany zatwierdzający, kontrakt wyniku i ograniczenie automatyzacji do wersji roboczej. Automatyzacja sprzedaży B2B oraz Canvas Automatyzacji opisują wyzwalacz, warunki wstępne, działanie i wycofanie zmiany; J06 dodaje klasyfikację, autoryzację oraz ład na poziomie cyklu życia.²⁶

Plan testów powinien odpowiadać dokładnemu przypadkowi użycia. Punkt odniesienia dostawcy może być informacją o modelu, lecz nie dowodzi jakości dla języka polskiego, lokalnych dokumentów, konkretnego promptu, integracji, populacji i skutku. Testy powinny porównywać rozwiązanie z ręczną linią bazową lub prostszą alternatywą.

Minimalny pakiet obejmuje:

1. Linia bazowa. Jak zadanie jest wykonywane bez systemu i jakie ma błędy, czas oraz koszt?
2. Zbiór danych i uprawnienia. Jakie próbki są używane, z jakiego okresu i na jakiej podstawie?
3. Przypadki typowe. Czy system wykonuje typowe zadanie zgodnie z kontraktem wyniku?
4. Przypadki brzegowe. Jak działa przy brakach, konfliktach, innych językach i nietypowych formatach?
5. Wierność źródłowa. Czy twierdzenia są wspierane przez właściwe źródła?
6. Odporność i bezpieczeństwo. Jak reaguje na prompt injection, treści z nieufnych źródeł, powtórzenie żądania i manipulację?
7. Przegląd podgrup i wpływu. Czy relewantne grupy otrzymują nierówne lub nieuzasadnione wyniki?
8. Czynnik ludzki. Czy osoba dokonująca przeglądu rozumie wynik i potrafi wykryć błąd?
9. Wycofanie zmiany i wycofanie użycia. Czy organizacja umie zatrzymać system i odnaleźć jego skutki?
10. Warunki zatrzymania. Który wynik blokuje pilot albo wdrożenie?

NIST Generative AI Profile wskazuje ryzyka charakterystyczne dla AI generatywnej, a ENISA proponuje wielowarstwowe podejście do cyberbezpieczeństwa systemów AI. NIST SP 800-218A rozszerza bezpieczne wytwarzanie oprogramowania o praktyki związane z AI i łańcuchem dostaw.²²²⁷²⁸

Przykład syntetyczny 6 — prognoza z leakage. Model wykorzystuje pole uzupełniane po dacie snapshotu. Historyczna dokładność jest wysoka, ale model korzysta z informacji niedostępnej w momencie decyzji. Wynik: nieudana akceptacja, backtest czasowy, przeliczenie raportów oraz HOLD. Analityka pipeline i forecasting pokazuje, dlaczego aktualny widok nie jest zbiorem informacji as-of.²⁹

Nieudany test nie powinien znikać po poprawieniu promptu. Rekord ma zachować wersję, konfigurację, wynik, ograniczenie i działanie korygujące. Dokumentacja nie jest dowodem kontroli, jeżeli nie można odtworzyć, co faktycznie przetestowano.

„Human in the loop” nie opisuje jakości kontroli. Człowiek może być formalnie obecny, a jednocześnie nie mieć czasu, źródeł, kompetencji ani prawa odrzucenia. Realny nadzór wymaga zaprojektowania pracy osoby dokonującej przeglądu, nie tylko dodania przycisku.

Osoba dokonująca przeglądu powinna:

• widzieć źródło, wersję, niepewność i ograniczenia;
• znać dozwolony oraz zabroniony skutek;
• mieć wystarczający czas i zasoby wykonawcze;
• móc wybrać REJECT, HOLD, CORRECT, ESCALATE lub NO ACTION;
• rozumieć, kiedy potrzebny jest przegląd specjalistyczny;
• mieć mandat biznesowy albo przekazać decyzję właściwemu właścicielowi;
• pozostawić uzasadnienie i ślad dowodowy;
• móc uruchomić korektę oraz ścieżkę odwołania.

RODO przewiduje szczególne zasady dotyczące decyzji automatycznych i profilowania, a wytyczne EDPB podkreślają znaczenie zabezpieczeń oraz realnej interwencji człowieka. Dokładny zakres zastosowania zależy od procesu, skutków i aktualnego prawa.¹⁴³⁰

Autoryzacja powinna być ograniczona do zakresu, modelu, konfiguracji, populacji, regionu, okresu i warunków. Decyzja „zatwierdzona” bez wygaśnięcia oraz wyzwalaczy zmiany tworzy pozorną trwałość. Autoryzacja produkcyjna jest osobnym aktem od kompletności dokumentacji.

Przykład syntetyczny 7 — zatwierdzenie w trzy sekundy. System proponuje zmianę etapu i prognozy, a handlowiec ma kliknąć „zatwierdź”. Nie widzi transkrypcji ani zdań wspierających rekomendację. Miara zatwierdzeń jest następnie używana jako miara produktywności. Wynik: zatrzymanie odhaczania, przebudowa interfejsu, dowody źródłowe, odrębny cel dla logów i zakaz wyniku punktowego na poziomie osoby.

RevOps w praktyce i Mapa Interfejsów RevOps rozdzielają przypisanie, akceptację i mandat w przepływie przychodowym. J06 stosuje tę samą zasadę do autoryzacji przypadku użycia.³¹

Test przed uruchomieniem nie wystarcza. Model, dane, użytkownicy, proces i środowisko zagrożeń zmieniają się. Monitoring powinien wykrywać nie tylko dostępność, lecz także spadek wsparcia źródłowego, zmianę rozkładu, wzrost nadpisań, użycie poza zakresem, automation bias, nieautoryzowane integracje, zdarzenia bezpieczeństwa i rosnące obciążenie osoby dokonującej przeglądu.

Dobre miary mają reguły działania. KPI nowoczesnej sprzedaży przypomina, że miara nie jest prawdą, cel nie jest kontrolą, a czerwony status nie jest ustaleniem na temat osoby.²³ Monitoring przypadku użycia może obejmować:

• odsetek wyników bez właściwego źródła;
• miarę niepowodzeń według typu błędu;
• nadpisania i powody odrzuceń;
• użycia poza zatwierdzoną populacją;
• nieaktualne lub wycofane źródła;
• incydenty dostępu i prompt injection;
• czas oraz obciążenie realnego przeglądu;
• opóźnienie korekty i wycofania;
• wersje modelu i konfiguracji widoczne w przebiegach.

Logowanie musi być proporcjonalne. Pełne prompty mogą zawierać dane osobowe, poufne i tajemnice. Retencja, dostęp i wtórne użycie logów wymagają osobnego celu. Brak incydentów nie dowodzi braku ryzyka; może oznaczać, że system nie ma właściwej detekcji.

Przykład syntetyczny 8 — prompt injection ujawnia fragment umowy. Chatbot pobiera dokument spoza uprawnień użytkownika po instrukcji osadzonej w źródle. Wynik: ograniczenie skutków incydentu, odcięcie wyszukiwania kontekstu, analiza kontroli dostępu, przeszukanie w dole strumienia, przegląd powiadomień i przeprojektowanie bezpieczeństwa. Model ENISA pomaga uporządkować warstwy kontroli, ale nie zastępuje lokalnego modelu zagrożeń.²⁸

Ścieżka incydentu powinna obejmować triage, ograniczenie skutków, zachowanie dowodów, ocenę prawną, ochrony danych i bezpieczeństwa, decyzję o powiadomieniu, korektę, odpowiedź wobec osoby dotkniętej i dowód zamknięcia.

Zatwierdzenie jest ważne tylko dla recordu, który został oceniony. Zmiana istotna może dotyczyć:

• celu lub skutku decyzji;
• modelu, wersji, promptu albo wyszukiwania kontekstu;
• źródeł danych, populacji i języka;
• wyniku, działania lub integracji;
• dostawcy, podprzetwarzającego, regionu i warunków umowy;
• dostępu do modelu, logów i retencji;
• prawa, wytycznych, standardu lub przepisu sektorowego;
• środowiska zagrożeń i nowych sposobów nadużycia;
• barier ochronnych albo nadzoru człowieka;
• skali użycia i osób dotkniętych.

Każdy wyzwalacz potrzebuje właściciela i ścieżki. Niewielka techniczna aktualizacja może być istotna, jeżeli zmienia wynik lub możliwość zakwestionowania. Z kolei korekta biblioteki bez wpływu na zachowanie może wymagać uproszczonego przeglądu. Reguła powinna wynikać z polityki zmian, nie z intuicji dostawcy.

Przykład syntetyczny 9 — cicha zmiana modelu. SaaS przełącza model bazowy. W ofertach rośnie liczba niepopartych twierdzeń, mimo że API i nazwa produktu pozostają bez zmian. Wynik: VENDOR_UPDATE_HOLD, wycofanie zmiany do poprzedniej wersji albo zatrzymanie, ponowne testy i aktualizacja rekordu autoryzacji.

AI Act i oficjalne materiały wdrożeniowe nadal ewoluują. 4 lipca 2026 r. obowiązki przejrzystości z art. 50 nie były jeszcze stosowane; mają być stosowane od 2 sierpnia 2026 r. Oficjalne materiały wskazują również późniejsze możliwe terminy dla części systemów wysokiego ryzyka. Dlatego twierdzenie prawne i zatwierdzenie powinny mieć datę przeglądu, wskazanie źródła oraz wyzwalacz ponownej walidacji, a nie ogólną etykietę „zgodne z AI Act”.^4101213

Wygaszenie zatrzymuje planowane nowe użycie. Nie usuwa automatycznie danych, wyników, embeddingów, eksportów, raportów, rekomendacji i decyzji, które już powstały. Wycofanie obejmuje identyfikację oraz korektę istotnych skutków w dole strumienia.

Plan wyjścia powinien odpowiedzieć:

• kiedy wyłączane są nowe runy;
• komu odbierany jest dostęp;
• które integracje, klucze i harmonogramy są zatrzymywane;
• jakie dane podlegają usunięciu, retencji albo wstrzymaniu prawnemu;
• gdzie znajdują się wyniki i dane pochodne;
• które raporty, alerty, modele i decyzje użyły wyniku;
• kto wymaga korekty lub powiadomienia;
• jak oznaczyć historię bez jej fałszowania;
• jaki dowód potwierdza zakończenie wycofania.

Przykład syntetyczny 10 — wygaszenie bez wycofania. Narzędzie zostaje wyłączone, lecz wygenerowane wyniki punktowe pozostają w CRM, playbookach i decyzjach premiowych. Wynik: WITHDRAWAL_INCOMPLETE do czasu identyfikacji rekordów zależnych, korekty użyć formalnych i zamknięcia mapy propagacji.

Usunięcie danych nie zawsze jest jedyną prawidłową operacją. Część rekordów może podlegać retencji z powodów prawnych, bezpieczeństwa lub rozliczalności. Wtedy potrzebne są ograniczenie dostępu, oznaczenie statusu, zakaz dalszego użycia i wygaśnięcie. Wygaszenie, usunięcie, korekta i wycofanie są odrębnymi działaniami.

Taksonomia SAG opisuje stan jednego przypadku użycia:

• SAG-0 UNKNOWN — nie wiadomo, czy przypadek użycia istnieje albo działa;
• SAG-1 UNREGISTERED — użycie bez kompletnego recordu;
• SAG-2 INVENTORIED — zapisano minimalny zakres i właściciela;
• SAG-3 CLASSIFICATION_PENDING — trwa analiza ról, prawa, danych i impactu;
• SAG-4 REQUIREMENTS_DEFINED — zapisano wymagania i użycia zakazane;
• SAG-5 TESTING — prowadzone są testy oraz red-team;
• SAG-6 PILOT_AUTHORIZED — ograniczony pilot ma jawną autoryzację;
• SAG-7 ACTIVE_LIMITED_SCOPE — aktywne użycie w zawężonym zakresie;
• SAG-8 ACTIVE_WITH_MONITORING — aktywne użycie z monitoringiem i ścieżką incydentu;
• SAG-9 SPECIALIST_REVIEW — potrzebna jest właściwa ekspertyza;
• SAG-10 HOLD — nowe użycie jest zatrzymane;
• SAG-11 INCIDENT_CONTAINMENT — trwa ograniczanie szkody i analiza;
• SAG-12 RETIRED — zakończono nowe użycie planowo;
• SAG-13 WITHDRAWN — zakończono wycofanie wraz z dowodami.

Nie wolno układać tych statusów jako rankingu „od złego do najlepszego”. WITHDRAWN może być poprawniejszym stanem niż ACTIVE_WITH_MONITORING. Przypadek użycia może przechodzić wstecz, a SPECIALIST_REVIEW nie jest porażką. Sumowanie statusów w wyniku punktowym portfolio maskowałoby różnice w zakresie, skutkach i brakach.

Widok portfolio powinien pokazywać liczbę przypadków użycia według statusu, właściciela, daty przeglądu, działań przeterminowanych i nierozwiązanych bram. Nie powinien rankować zespołów przez tempo zatwierdzeń ani liczbę aktywnych systemów. Więcej AI nie oznacza większej dojrzałości.

Ład powinien pytać nie tylko „czy możemy?”, ale również „czy musimy?” i „czy prostszy sposób wystarczy?”. Niezbędność ogranicza zakres danych, automatyzacji i skutków. Alternatywa bez AI może być szybsza, bardziej przewidywalna i łatwiejsza do wycofania.

Przy ocenie celu warto zapisać:

• obserwowalny problem i linię bazową;
• decyzję lub działanie wspierane przez system;
• oczekiwany wynik i sposób pomiaru;
• użytkownika i osoby dotknięte;
• minimalny zakres danych;
• alternatywę procesową, regułową lub ręczną;
• koszt błędu, korekty i przeglądu;
• przypadki, w których system powinien się powstrzymać;
• zabronione rozszerzenia celu.

Dryf celu często zaczyna się niewinnie. Asystent spotkań początkowo tworzy prywatną notatkę, później podsumowanie trafia do CRM, następnie zasila coaching, a w końcu formalną ocenę pracowniczą. Każdy krok zmienia affected persons, authority, retencję i możliwe szkody. Nie wolno traktować tego jako jednego ciągłego przypadku użycia.

J06 łączy się tu z modelem architektury zaczynającej się od decyzji: najpierw obiekt, decyzja i właściciel, później system. To samo założenie obowiązuje w J00–J05 i chroni przed tool-first design.⁷³¹

Jedna osoba może pełnić kilka ról w małej organizacji, ale rekord powinien je rozdzielać logicznie:

• Właściciel biznesowy odpowiada za problem, zamierzone użycie, wynik i operacyjne stosowanie wyniku.
• Właściciel danych odpowiada za źródło, jakość, dostęp, ograniczenia, retencję i wycofanie danych.
• Właściciel systemowy odpowiada za konfigurację, integracje, dostęp, monitoring, incydent i wyjście techniczne.
• Właściciel akceptacji ryzyka ma mandat do podjęcia ograniczonej decyzji o ryzyku pozostałym w swoim zakresie.
• Osoby dokonujące przeglądu specjalistycznego oceniają kwestie prawne, ochrony danych, bezpieczeństwa, pracownicze, własności intelektualnej, dostępności lub ryzyka modelu.
• Operator lub osoba dokonująca przeglądu wykonuje codzienny human checkpoint i korektę.

Rozdzielenie obowiązków ogranicza konflikt interesów. Zespół, który chce szybko uruchomić przypadek użycia, nie powinien samodzielnie potwierdzać wszystkich wymagań i zamykać własnych nieudanych testów. Z drugiej strony centralny komitet nie powinien przejmować decyzji biznesowych, których nie rozumie.

Rola managera sprzedaży pokazuje, że mandat, zasoby wykonawcze, eskalacja i formalne użycie kadrowe wymagają odrębnych rutyn i zapisów.²³ Ład przypadku użycia powinien działać podobnie: właściwa decyzja trafia do właściwego właściciela, z dowodem i return condition.

Klasyfikacja danych powinna opisywać nie tylko ich treść, lecz również pochodzenie, cel, warunki i możliwe skutki. Ten sam adres e-mail może być publicznie widoczny, przekazany w relacji handlowej, kupiony od dostawcy, wywnioskowany albo skopiowany z prywatnego źródła. Każda ścieżka ma inne oczekiwania, dowody i ograniczenia.

Praktyczny rejestr powinien zawierać:

Publiczna dostępność nie usuwa praw autorskich, tajemnic, warunków serwisu, zasad ochrony danych ani oczekiwań kontekstowych. Syntetyczność również nie powinna być deklaracją bez dowodu: dane syntetyczne mogą zachowywać wzorce albo ujawniać informacje o źródłowym zbiorze.

W modelach i bazach wiedzy ważne jest rozdzielenie wejścia od wyniku. Wynik AI nie jest nowym źródłem faktu. Jeżeli twierdzenie trafia do CRM, oferty lub decyzji, powinno prowadzić do właściwego dokumentu, rekordu albo wypowiedzi. Obecność cytowania nie wystarcza — źródło musi wspierać dokładne twierdzenie.⁸⁹

Ocena powinna tworzyć mapę decyzji, nie estetyczną mapę ciepła. Dwa przypadki użycia z tym samym kolorem mogą wymagać całkowicie innych kontroli. Model podsumowania spotkań może mieć wysokie ryzyko poufności i średni koszt błędu, a punktacja ofert może mieć mniejszy zakres danych, lecz silny wpływ na dostęp do warunków handlowych.

Zamiast jednego wyniku punktowego warto prowadzić oddzielne wymiary:

• dotkliwość możliwego skutku;
• skalę i liczbę osób dotkniętych;
• częstotliwość oraz ekspozycję;
• odwracalność i koszt korekty;
• wykrywalność przed istotnym skutkiem;
• możliwość zakwestionowania i dostępną ścieżkę odwołania;
• propagację do systemów i decyzji w dole strumienia;
• nierówność lub efekty w podgrupach;
• zależność od dostawcy, modelu i źródła;
• niewiadome pozostałe po zastosowaniu kontroli.

Wynik oceny powinien uruchamiać regułę działania: specjalistyczny przegląd, dodatkowy test, ograniczenie zakresu, ręczne przejęcie, pilot, wstrzymanie albo zatrzymanie. „Ryzyko zaakceptowane” bez właściciela, uzasadnienia, wygaśnięcia i warunków jest etykietą, nie decyzją.

W kontekście spraw pracowniczych i analityki na poziomie osoby trzeba szczególnie oddzielić obserwację procesu od ustalenia na temat osoby. Telemetria powstała do bezpieczeństwa lub wsparcia nie może cicho stać się podstawą oceny, sankcji albo wynagrodzenia. Potrzebne są odrębny cel, przegląd prawny i pracowniczy, przejrzystość, dostęp oraz możliwość zakwestionowania.²³¹⁷

Brama zatrzymania działa przed testem produkcyjnym i przed zakupami, jeżeli dokładny sposób użycia jest zabroniony lub organizacja nie ma mandatu. Nie należy „pilotować na małej grupie” zastosowania, którego nie wolno wykonywać. Testy mogą służyć do analizy bezpieczeństwa w kontrolowanym środowisku, ale nie legalizuje skutku wobec klienta lub pracownika.

Użycie ograniczone jest możliwe, gdy zakres da się ograniczyć w sposób egzekwowalny. Przykłady:

• wersja robocza bez autonomicznej wysyłki;
• research z dozwolonych źródeł bez zapisu do systemu decyzji;
• model opisowy bez działania na poziomie osoby;
• pilot na danych syntetycznych lub odpowiednio przygotowanych;
• rekomendacja bez automatycznego zobowiązania;
• wyszukiwanie kontekstu z ograniczonego repozytorium i kontrola dostępu;
• monitoring agregatowy bez wtórnego formalnego użycia kadrowego.

Ograniczenie musi być techniczne i proceduralne. Sam zapis „użytkownik nie powinien” nie wystarcza, jeżeli system nadal pozwala na nieodwracalny skutek. Kontrole mogą obejmować blokadę wysyłki, integrację tylko do odczytu, filtry zakresu, rozdzielenie środowisk, dostęp oparty na rolach, wygaśnięcie zatwierdzenia i alerty audytowe.

Właściwym wynikiem może być NO AI, gdy problem da się rozwiązać prostszym przepływem pracy, albo DRAFT_ONLY, gdy mandat do działania pozostaje u człowieka. Ład nie ma premiować aktywacji technologii. Ma utrzymywać zgodność między celem, kontrolą i rzeczywistym zachowaniem.

Gold set nie powinien być zbiorem łatwych przykładów przygotowanych do demonstracji. Musi reprezentować przypadki typowe, przypadki brzegowe, wyjątki i sytuacje o wysokim koszcie błędu. Powinien mieć wskazanie źródła, oczekiwany wynik, ograniczenie i uzasadnienie, a jego użycie musi być dozwolone.

Dla AI generatywnej warto rozdzielić co najmniej:

• wierność faktom i źródłom;
• kompletność wobec wymaganych elementów;
• niepoparte twierdzenia i zmyślone cytowania;
• wrażliwość na prompt i język;
• odporność wobec braków i konfliktów;
• prompt injection i nadużycie narzędzi;
• wyciek danych oraz granicę dostępu;
• powstrzymanie się przy niewystarczającym dowodzie;
• wykrywalność błędu przez człowieka;
• skutki uboczne w dole strumienia.

Dla modeli punktacyjnych lub prognostycznych potrzebne są populacja, snapshot, linia bazowa, walidacja czasowa, kalibracja, braki danych i dryf. Dokładność bez właściwego zbioru informacji może być artefaktem leakage. Dla systemów regułowych testuje się również kolejność, duplikaty, ponowienia, idempotencję i uzgadnianie.²⁶²⁹

Kryteria akceptacji nie powinny być wyłącznie średnią. Krytyczne niepowodzenie może blokować wdrożenie mimo dobrego wyniku agregatowego. Testy trzeba wersjonować razem z modelem, promptem, źródłami, konfiguracją i datą. Jeżeli tych elementów nie da się odtworzyć, wynik nie wspiera autoryzacji.

Nadzór ma trzy warstwy:

1. Ex ante — człowiek uczestniczy w definiowaniu celu, kontroli i warunków zatrzymania.
2. W trakcie działania — osoba dokonująca przeglądu ocenia konkretny wynik przed istotnym skutkiem.
3. Ex post — organizacja analizuje błędy, nadpisania, incydenty i wartość przeglądu.

Odhaczanie pojawia się, gdy interfejs pokazuje jedynie rekomendację bez źródła, wymusza szybkie kliknięcie, penalizuje odrzucenie albo automatycznie wykonuje skutek przed przeglądem. Taki punkt kontrolny może zwiększać ryzyko, ponieważ tworzy pozór odpowiedzialności człowieka bez realnej możliwości kontroli.

Projekt powinien uwzględniać zasoby wykonawcze. Osoba dokonująca przeglądu, która ma ocenić setki wyników dziennie, może nie być realną barierą. Wtedy trzeba ograniczyć wolumen, zwiększyć próbkowanie, poprawić powstrzymywanie się, przenieść skutek na wersję roboczą albo wycofać przypadek użycia. Rytm pracy managera sprzedaży rozdziela aktualizację statusu, coaching, prognozę i formalny przegląd; podobnie nadzór powinien mieć jeden cel i właściwy dowód.²³

Możliwość zakwestionowania wymaga, by użytkownik lub osoba dotknięta mogli zakwestionować wynik. Ścieżka korekty powinna aktualizować nie tylko ekran, lecz również rekord źródłowy, zbiory danych w dole strumienia i decyzje. Jeżeli system nie potrafi obsłużyć sensownego sprzeciwu, zakres powinien zostać ograniczony.

Monitoring powinien łączyć sygnał z decyzją. Alert „wzrosła liczba nadpisań” nie wystarcza bez progu, segmentacji, właściciela i ścieżki. Wzrost może oznaczać dryf, zmianę procesu, błędne źródło, nową populację albo lepszą czujność osób dokonujących przeglądu. Interpretacja wymaga dowodów.

Playbook incydentu powinien rozdzielać:

WYKRYCIE
→ TRIAGE
→ OGRANICZENIE SKUTKÓW
→ ZABEZPIECZENIE DOWODÓW
→ OCENA SPECJALISTY
→ DECYZJA O POWIADOMIENIU
→ KOREKTA
→ WYSZUKANIE SKUTKÓW W DOLE STRUMIENIA
→ PONOWNA WALIDACJA ALBO WYCOFANIE
→ DOWÓD ZAMKNIĘCIA

Ograniczenie skutków powstrzymuje nowe szkody. Korekta naprawia istniejące rekordy, komunikaty i decyzje. Powiadomienie jest odrębną decyzją zależną od charakteru zdarzenia i prawa. Przeszukanie w dole strumienia ustala, gdzie wynik został użyty. Bez tej mapy organizacja może naprawić model i pozostawić materialny błąd w CRM, prognozach oraz komunikacji.

W organizacjach objętych NIS2 lub polską implementacją KSC mogą istnieć szczególne obowiązki zarządzania ryzykiem, łańcuchem dostaw i raportowania incydentów. Zakres podmiotowy oraz dokładne obowiązki wymagają aktualnego przeglądu.¹⁶

Ponowna walidacja nie powinna zależeć wyłącznie od kalendarza. Data przeglądu jest potrzebna, ale najważniejsze są wyzwalacze. Rekord powinien wygasać lub przechodzić do HOLD, gdy:

• zmienia się zamierzony cel;
• pojawia się nowa populacja albo geografia;
• dostawca zmienia model, warunki umowy, podprzetwarzającego lub hosting;
• źródło zostaje wycofane, zestarzałe albo zakwestionowane;
• zmienia się wynik, działanie albo integracja;
• monitoring przekracza próg;
• występuje incydent albo istotna skarga;
• zmieniają się przepisy, wytyczne lub wymagania sektorowe;
• osoba dokonująca przeglądu traci zasoby wykonawcze albo mandat;
• system nie przechodzi ponownego testu wycofania.

Zatwierdzenie powinno wskazywać wersję, zakres, datę startu, wygaśnięcie, warunki i ryzyko pozostałe. Nie należy tworzyć bezterminowej etykiety „approved vendor”, która automatycznie obejmuje wszystkie przyszłe funkcje.

W 2026 r. szczególnie ważna jest kontrola źródeł prawnych. Tekst AI Act, oficjalny harmonogram Komisji, wytyczne i instrumenty dobrowolne mają różny status. Projekt, konsultacja, wersja robocza kodeksu i finalny akt nie są wymienne. Każde twierdzenie powinno mieć wskazanie źródła i ograniczenie, a finalny przegląd prawny musi nastąpić przed 2 sierpnia 2026 r. oraz po każdej materialnej zmianie.⁴¹⁰¹³

Celem pierwszych 90 dni nie jest zatwierdzenie całego portfolio. Celem jest uzyskanie wiarygodnego inwentarza, zatrzymanie najbardziej niekontrolowanych użyć i uruchomienie powtarzalnego lifecycle dla kilku reprezentatywnych przypadków użycia.

Dni 1–15 — discovery i bramy zatrzymania

• wyznacz właściciela programu oraz ścieżki specjalistyczne;
• zbierz istniejące przypadki użycia, nie tylko zakupione narzędzia;
• oznacz użycia UNREGISTERED, na poziomie osoby, wobec klienta i na danych wrażliwych;
• zatrzymaj oczywiste zakazane lub nieautoryzowane zastosowania;
• wybierz 3–5 przypadków użycia reprezentujących różne klasy skutku.

Dni 16–30 — minimalny rekord i role

• uzupełnij GAD-1–GAD-3;
• zmapuj dostawcę, podmiot stosujący i podmioty przetwarzające;
• zidentyfikuj źródła, uprawnienia, retencję oraz warunki wycofania;
• ustal właścicieli: biznesowego, danych, systemowego i akceptacji ryzyka;
• utwórz listę niewiadomych oraz przeglądów specjalistycznych.

Dni 31–50 — wpływ i wymagania

• wykonaj przegląd osób dotkniętych oraz propagacji;
• zdefiniuj użycia zakazane i cele kontrolne;
• wybierz linię bazową bez AI;
• zapisz kryteria akceptacji i warunki zatrzymania;
• przygotuj ograniczony zakres pilota.

Dni 51–70 — testy i autoryzacja

• zbuduj gold set i przypadki brzegowe;
• wykonaj testy wierności źródłowej, bezpieczeństwa, odporności i czynnika ludzkiego;
• zachowaj nieudane testy;
• zaprojektuj realny nadzór i ścieżkę odwołania;
• podejmij ograniczoną decyzję: pilot, przeprojektowanie, wstrzymanie, zatrzymanie albo brak AI.

Dni 71–90 — monitoring, incydent i wycofanie

• uruchom miary z regułami działania;
• przetestuj ograniczanie skutków incydentu i przeszukanie w dole strumienia;
• zdefiniuj wyzwalacze zmiany istotnej oraz wygaśnięcie;
• przeprowadź ćwiczenie wygaszenia i wycofania;
• przygotuj przegląd portfolio bez globalnego wyniku punktowego.

Operacyjnym artefaktem tego procesu jest Rejestr Ładu AI i Danych. Narzędzie ma porządkować dowody, braki, decyzje i lifecycle; nie klasyfikuje automatycznie prawa ani nie udziela produkcyjnego zatwierdzenia.

Formularze, tabele, błędy i statusy muszą być dostępne z klawiatury, mieć semantyczne etykiety, reflow, widoczny focus, brak znaczenia opartego tylko na kolorze i równoważny eksport. WCAG 2.2 jest punktem odniesienia dla implementacji, lecz zgodność wymaga audytu gotowego UI, a nie samej specyfikacji.³²