AI w pracy handlowca B2B: research, przygotowanie, analiza i follow-up z kontrolą źródeł

Przedmiotem J02 nie jest cała transformacja AI działu handlowego. Taki zakres łączy research, komunikację, CRM, coaching, prognozowanie, kwalifikację, automatyzację i ład, a więc zadania o różnych źródłach, ryzykach i prawach decyzyjnych.

Obiekt kontrolowany brzmi:

Przykładowym obiektem może być:

• briefing o jednym koncie z publicznych źródeł;
• wersja robocza pytań discovery na podstawie wybranych materiałów;
• uporządkowanie jawnych notatek po spotkaniu;
• ekstrakcja kilku pól z konkretnego dokumentu;
• robocze porównanie dwóch wersji oferty;
• wersja robocza follow-upu oparta wyłącznie na potwierdzonych ustaleniach;
• tłumaczenie robocze wiadomości przed przeglądem eksperta;
• wyszukiwanie w kontrolowanej bazie wiedzy;
• przygotowanie wariantów argumentacji do wyboru przez handlowca.

Minimalny zapis projektowy powinien zawierać:

use_case_id:
task_exact_wording:
business_purpose:
user_role:
decision_or_work_supported:
decision_owner:
allowed_sources:
prohibited_sources:
model_service:
model_version:
prompt_version:
retrieval_scope:
tool_permissions:
output_schema:
source_locator_requirement:
uncertainty_rule:
human_reviewer:
acceptance_criteria:
logging:
retention:
monitoring:
incident_route:
revalidation_triggers:
withdrawal_path:
limitations:
status:

Przypadek użycia nie staje się bezpieczny dlatego, że jest „tylko pomocą”. Wersja robocza może zawierać poufne dane, nieuprawnione źródła albo niedozwoloną inferencję. Z kolei dobrze ograniczone wyszukiwanie lub porządkowanie notatek może być użyteczne, choć nie podejmuje żadnej decyzji.

Najważniejsza granica brzmi:

Hasło „zwiększyć produktywność dzięki AI” nie mówi, co system ma robić. Może oznaczać krótszy research, mniej ręcznego przepisywania, szybsze przygotowanie maila, lepsze wyszukiwanie wiedzy albo automatyczne tworzenie aktywności. Każdy z tych przypadków ma inną jednostkę pracy, źródła, błędy, obciążenie przeglądem i potencjalny wpływ na klienta.

Szeroki cel tworzy trzy błędy.

Pierwszy to dryf zakresu. Przypadek użycia zaczyna od wersji roboczej, po czym otrzymuje dostęp do CRM, maila, kalendarza i narzędzi wykonawczych. Granica między sugestią a działaniem zanika.

Drugi to skrót pomiarowy. Organizacja mierzy liczbę wygenerowanych treści albo zaoszczędzone minuty, ale nie liczy korekt, twierdzeń bez pokrycia w źródle, błędów źródłowych, czasu przeglądu i kosztu incydentów. Szybszy wynik może zwiększać całkowity koszt procesu.

Trzeci to pozorny mandat. Rekomendacja modelu zaczyna być traktowana jak formalna ocena, ponieważ pojawia się w systemie, jest opisana procentem lub wygląda profesjonalnie. Techniczna prezentacja maskuje brak uprawnienia.

Badania nad współpracą człowiek–AI nie uzasadniają założenia, że połączenie człowieka z modelem zawsze przewyższa najlepszy komponent. Efekt zależy od typu zadania, jakości systemu, możliwości weryfikacji i sposobu podziału pracy.⁹ Literatura dotycząca nadmiernego polegania wskazuje dodatkowo, że może ono osłabiać krytyczną ocenę, prowadzić do utraty kompetencji i utrwalać błędny wynik.¹⁰

Dlatego wartość J02 nie jest definiowana jedną miarą produktywności. Przypadek użycia powinien wykazać, że:

• poprawia określone zadanie;
• zachowuje źródła;
• nie zwiększa ryzyka w innym miejscu;
• pozwala na realny przegląd;
• ma akceptowalne obciążenie;
• nie rozszerza się poza zamierzone użycie;
• może zostać zatrzymany i wycofany.

Taksonomia podstawowa UAI-0–UAI-12 nie ocenia „poziomu AI” organizacji. Określa status konkretnego przypadku użycia:

Dozwolone klasy obejmują research, przygotowanie pytań, porządkowanie notatek, wersje robocze, ekstrakcję danych, tłumaczenia robocze, wyszukiwanie i porównanie dokumentów. Nie oznacza to, że każdy konkretny przypadek jest automatycznie dozwolony. Status zależy od źródeł, danych, środowiska, celu, użytkownika i granicy działania.

Niedozwolonym skrótem jest natomiast przejście:

WSPARCIE WERSJI ROBOCZEJ
→
WYSYŁKA AUTOMATYCZNA

albo:

STRESZCZENIE
→
POTWIERDZONE ZOBOWIĄZANIE KLIENTA

bez osobnego przeglądu automatyzacji, mandatu i dowodów.

Model składa się z dziesięciu pól architektury:

1. WAI-1 — zadanie, cel, użytkownik i użycia zakazane;
2. WAI-2 — zbiór źródeł, uprawnienia i klasyfikacja;
3. WAI-3 — model, usługa, wersja i rola dostawcy;
4. WAI-4 — prompt, kontekst, wyszukiwanie kontekstu i uprawnienia narzędzi;
5. WAI-5 — schemat wyniku, cytowania i niepewność;
6. WAI-6 — przegląd przez człowieka, mandat i korekta;
7. WAI-7 — testowanie, red team i kryteria akceptacji;
8. WAI-8 — logowanie, ochrona danych, bezpieczeństwo i retencja;
9. WAI-9 — monitoring, incydent i informacja zwrotna;
10. WAI-10 — ponowna walidacja, wygaszenie i wycofanie.

Kroki nie są poziomami dojrzałości. Nie sumuje się ich do wyniku punktowego. Przypadek użycia może mieć dobrze zaprojektowany prompt i jednocześnie nie przejść bramy źródeł. Może mieć świetne wyniki testów i nadal być niedopuszczalny z powodu wnioskowania o cechach osoby. Może również zostać zatwierdzony w pilocie, lecz później wymagać zawieszenia po zmianie modelu.

WAI działa jako pętla. Informacja z monitoringu może cofnąć przypadek użycia do testów. Incydent może wycofać źródło. Zmiana dostawcy może wymusić ponowne zaprojektowanie retencji. Nowe użycie może wymagać ponownego przejścia od WAI-1.

Dozwolonym wynikiem nie jest wyłącznie ACTIVE. Równie prawidłowe są:

• NO AI
• DRAFT ONLY
• DISCOVERY ONLY
• HOLD
• SPECIALIST REVIEW
• SUSPEND
• RETIRE
• WITHDRAW

Taka architektura chroni organizację przed przekonaniem, że każdy problem powinien zakończyć się wdrożeniem.

Dobry przypadek użycia można opisać bez nazwy modelu. Zdanie powinno określać pracę, wejścia, wynik i granicę działania.

Zamiast:

AI ma pomagać handlowcom w przygotowaniu do spotkań.

lepiej zapisać:

Dla handlowca enterprise AI przygotowuje wersję roboczą briefingu o jednym koncie
na podstawie wskazanych publicznych źródeł i autoryzowanych pól CRM.
Wynik rozdziela fakty, hipotezy, pytania i niewiadome.
Nie kwalifikuje konta, nie ocenia osób i nie aktualizuje CRM.

Minimalna karta WAI-1 obejmuje:

• dokładne brzmienie zadania;
• użytkownika;
• cel biznesowy;
• decyzję albo pracę wspieraną;
• właściciela decyzji;
• dozwolony wynik;
• dozwolone działanie;
• zakazane użycia;
• osoby i klientów, których przypadek użycia może dotyczyć;
• linię bazową bez AI;
• oczekiwaną wartość;
• datę przeglądu.

Lista zakazanych użyć jest istotna, ponieważ systemy generatywne łatwo przenoszą się między zadaniami. Narzędzie stworzone do podsumowania może zostać użyte do oceny zaangażowania. Research może zmienić się w nieprzejrzystą kwalifikację. Logi mogą stać się monitoringiem pracownika.

J02 domyślnie zatrzymuje:

• seller score;
• automatyczną ocenę wyników pracy;
• inferencję emocji, osobowości, uczciwości, motywacji lub lojalności;
• tworzenie formalnych ustaleń pracowniczych;
• autonomiczne potwierdzanie zobowiązań klienta;
• wysyłkę do klienta bez właściwego punktu kontrolnego;
• rozszerzenie celu bez przeglądu użycia wtórnego.

AI Act i materiały Komisji wymagają oceny systemu przez zamierzony cel, a nie przez marketingową nazwę funkcji. Zakres praktyk zakazanych i klasyfikacji trzeba ponownie sprawdzać przed konkretnym wdrożeniem.^11121314

Wynik nie może być bardziej wiarygodny niż architektura źródeł, z których korzysta. Rejestr źródeł powinien zawierać:

source_id:
source_type:
owner:
locator:
authority:
license_or_rights:
data_classification:
personal_data:
sensitive_data:
confidentiality:
freshness:
review_date:
allowed_use:
prohibited_use:
withdrawal_path:

Źródła mogą obejmować:

• publiczne dokumenty pierwotne;
• publiczne źródła wtórne;
• autoryzowane rekordy CRM;
• materiały klienta;
• notatki ze spotkania;
• autoryzowane transkrypcje;
• kontrolowaną bazę wiedzy;
• dokumenty poufne w zatwierdzonym środowisku.

Każde źródło powinno otrzymać status: allowed, limited, review required, stale, conflicting, prohibited albo withdrawn.

Publiczna dostępność nie oznacza automatycznie dowolnego prawa do użycia. Materiał może być chroniony, nieaktualny albo opublikowany w innym celu. Rekord CRM może zawierać wartość bez wskazania źródła. Transkrypcja może zostać zebrana dla dokumentacji spotkania, lecz nie dla analizy cech uczestników. Dane osobowe wymagają oceny celu, minimalizacji, przejrzystości, retencji i praw osób.¹⁵¹⁶

Zbiór źródeł powinien pozwalać na odpowiedź:

• z którego dokładnie dokumentu pochodzi twierdzenie;
• w jakiej wersji i dacie;
• kto jest właścicielem;
• czy źródło jest aktualne;
• czy wolno użyć go w tym celu;
• co zrobić po wycofaniu lub korekcie;
• jakie wyniki w dole strumienia korzystały z tego źródła.

Bez tego „AI research” staje się niekontrolowanym połączeniem wyszukiwania, pamięci modelu i domysłów.

Przypadek użycia nie korzysta z abstrakcyjnego „AI”. Korzysta z konkretnej usługi, modelu, konfiguracji, API, wbudowanej funkcji lub rozwiązania utrzymywanego we własnej infrastrukturze.

Zapis modelu i usługi powinien wskazać:

• nazwę usługi i modelu;
• wersję albo sposób aktualizacji;
• tryb konsumencki, firmowy, API lub własna infrastruktura;
• podmiot kontraktowy;
• role dotyczące danych;
• podprzetwarzających;
• lokalizację danych i transfery;
• użycie danych do treningu;
• retencję promptów, plików i wyników;
• logi administracyjne;
• bezpieczeństwo;
• eksport danych i konfiguracji;
• sposób informowania o zmianach;
• wycofanie wersji i wyjście z usługi.

Deklaracja „dane nie są używane do treningu” nie zamyka przeglądu. Nadal pozostają pytania o logi, dostęp wsparcia, retencję, podprzetwarzających, lokalizację danych, incydenty i przenoszalność.

Wersja modelu jest istotna dla reprodukowalności. Gdy dostawca aktualizuje model dynamicznie, organizacja może nie kontrolować dokładnego momentu zmiany. Wtedy potrzebne są monitoring, test regresji i możliwość przejścia do CHANGE_PENDING lub REVALIDATION_REQUIRED.

Model cards i podobna dokumentacja pomagają opisać zamierzone zastosowania, ograniczenia i kontekst oceny, lecz nie zastępują testów konkretnego przypadku użycia.¹⁷ Certyfikat dostawcy również nie dowodzi, że wybrane źródła, prompt i przegląd przez człowieka są adekwatne dla procesu sprzedażowego.

Prompt jest częścią konfiguracji produkcyjnej. Jego zmiana może wpływać na:

• typ generowanych twierdzeń;
• sposób korzystania ze źródeł;
• widoczność niepewności;
• skłonność do odpowiadania mimo braków;
• zakres wywołań narzędzi;
• format wyniku;
• ryzyko ujawnienia.

Konfiguracja powinna obejmować:

configuration_version:
system_instruction:
user_template:
context_fields:
retrieval_collections:
retrieval_filters:
source_priority:
untrusted_content_handling:
tool_permissions:
write_scope:
external_action_checkpoint:
secrets_excluded:
prompt_injection_controls:
fallback:

Najważniejsze rozdzielenie brzmi:

Strona internetowa, dokument klienta, mail lub rekord mogą zawierać tekst wyglądający jak instrukcja dla modelu. System powinien traktować go jako dane, nie polecenie zmieniające reguły działania.

Wstrzyknięcie promptu, ujawnienie informacji wrażliwych i nadmierna samodzielność systemu należą do podstawowych klas zagrożeń aplikacji LLM.¹⁸¹⁹²⁰ Kontrola nie kończy się na filtrze tekstowym. Obejmuje separację kontekstu, ograniczenie uprawnień, listę dozwolonych narzędzi, walidację argumentów, punkty kontrolne, logi i możliwość zatrzymania.

Zasada najmniejszych uprawnień powinna działać progresywnie:

BEZ NARZĘDZIA
→ TYLKO ODCZYT
→ OGRANICZONY ZAPIS
→ DZIAŁANIE ZEWNĘTRZNE Z PUNKTEM KONTROLNYM

Dostęp do całego CRM, skrzynki i dysku „dla wygody” tworzy nieproporcjonalny zasięg szkody. Uprawnienia narzędzi powinny odpowiadać jednemu zadaniu, jednemu obiektowi i jednemu zakresowi.

Kontrakt wyniku mówi, co model może zwrócić i w jakim statusie. Dla researchu użyteczna może być struktura:

facts:
  - claim:
    source_locator:
    source_date:
hypotheses:
  - statement:
    evidence_for:
    evidence_against:
questions:
unknowns:
limitations:
recommended_human_check:

Taki format rozdziela cztery odmienne obiekty:

• fakt wsparty źródłem;
• hipotezę wymagającą rozmowy lub dalszego researchu;
• pytanie;
• niewiadoma.

Model nie powinien wypełniać luk płynnym tekstem. Jeżeli dowody są niewystarczające, prawidłowym wynikiem jest:

• NIEWYSTARCZAJĄCY DOWÓD
• SPRZECZNE ŹRÓDŁA
• ŹRÓDŁO NIEAKTUALNE
• BRAK AUTORYZACJI
• NIEWIADOMA

Cytowanie wymaga dwóch testów. Pierwszy sprawdza, czy link lub wskazanie źródła istnieje. Drugi — czy źródło faktycznie wspiera dokładne twierdzenie. System może podać prawdziwy dokument, który nie zawiera wskazanej informacji. Może też połączyć dwa fragmenty w wniosek, którego żaden autor nie sformułował.

Badania nad RAG nadal wskazują na ryzyko konfabulacji i potrzebę osobnej oceny wierności wobec źródła oraz niepewności.⁷ Pochodzenie danych powinno łączyć źródło, czynność, model i osobę dokonującą przeglądu, tak aby można było odtworzyć, skąd wziął się konkretny wynik.⁶

„Człowiek w pętli” jest często używany jako ogólne zabezpieczenie. W praktyce osoba dokonująca przeglądu może nie mieć dostępu do źródeł, nie znać domeny, nie mieć czasu, nie wiedzieć, że wynik pochodzi z AI albo nie mieć prawa do jego odrzucenia.

Realny przegląd wymaga:

Karta przeglądu powinna określać:

• rolę osoby dokonującej przeglądu;
• zakres przeglądu;
• kryteria;
• widoczne źródła;
• widoczne ograniczenia;
• mandat;
• dozwolone tryby zatwierdzenia;
• tryby odrzucenia;
• sposób rejestracji nadpisania;
• właściciela korekty;
• dowód zamknięcia.

Przegląd powinien być proporcjonalny do skutku. Wersja robocza wewnętrznej listy pytań może wymagać lżejszego punktu kontrolnego niż wiadomość cenowa do klienta. Zapis w systemie zapisu wymaga innego przeglądu niż prywatna notatka robocza.

Skłonność do ufania automatowi pojawia się wtedy, gdy użytkownik przyjmuje wynik dlatego, że system jest szybki, wygląda obiektywnie albo ma etykietę „insight wygenerowany przez AI”. Ryzyko rośnie, gdy ręczna weryfikacja jest kosztowna, a zatwierdzenie tanie.

Wytyczne dotyczące automatycznego podejmowania decyzji i profilowania podkreślają znaczenie rzeczywistego udziału człowieka, a nie formalnego potwierdzenia.⁸ Badania human–AI pokazują, że efekty zależą od jakości komponentów i projektu współpracy, nie od samego dodania osoby dokonującej przeglądu.⁹

Korekta musi zachować:

• poprzedni wynik;
• nowy wynik;
• powód;
• źródło;
• osobę dokonującą przeglądu;
• czas;
• znane miejsca w dole strumienia;
• decyzję o wycofaniu.

Przypadek użycia należy porównać z linią bazową bez AI. Linia bazowa może oznaczać:

• aktualny czas wykonania;
• liczbę i typ błędów;
• jakość źródeł;
• koszt przeglądu;
• odsetek korekt;
• odsetek przypadków, w których zadanie jest porzucane;
• jakość wyniku ocenianą według jawnego kryterium.

Zbiór wzorcowy nie powinien zawierać wyłącznie prostych przypadków. Potrzebne są:

• przypadki reprezentatywne;
• przypadki brzegowe;
• sprzeczne źródła;
• brak źródeł;
• źródło nieaktualne;
• wielojęzyczność;
• dokumenty długie i niejednoznaczne;
• wstrzyknięcie promptu;
• poufne dane;
• próba nadużycia narzędzia;
• przypadki wymagające unknown;
• przypadki wymagające Zatrzymanie.

Zestaw testów powinien mierzyć co najmniej:

• wierność wobec źródła;
• kompletność cytowań;
• pokrycie twierdzenia cytowaniem;
• twierdzenia bez pokrycia w źródle;
• poprawność klasyfikacji fakt/inferencja/pytanie;
• obsługę odpowiedzi „niewiadoma”;
• bezpieczeństwo;
• ochronę danych;
• obciążenie przeglądem przez człowieka;
• nadpisania i korekty;
• opóźnienie;
• dostępność;
• regresję po zmianie.

NIST AI RMF, profil GenAI i playbook dostarczają struktury govern–map–measure–manage, lecz nie definiują progu jakości konkretnego briefingu sprzedażowego.⁴⁵²¹ Kryteria trzeba ustalić dla własnego zadania.

Przykładowy warunek zatrzymania:

Jeżeli wynik zawiera zobowiązanie klienta bez pokrycia w źródle
albo wskazanie źródła nie wspiera twierdzenia,
przypadek użycia nie przechodzi do pilota niezależnie od oszczędności czasu.

Logowanie jest potrzebne do diagnozy, testów, korekt i incydentów. Nie oznacza to jednak, że należy przechowywać pełne prompty, załączniki i wyniki bezterminowo.

Zapis kontrolny powinien odpowiedzieć:

• po co istnieje log;
• jakie zdarzenia są rejestrowane;
• czy treść promptu jest zapisywana;
• czy wynik jest zapisywany;
• czy dane są redagowane;
• kto ma dostęp;
• jak długo trwa retencja;
• jak działa usuwanie;
• kiedy zachowuje się dowód incydentu;
• czy log może dotyczyć aktywności pracownika;
• jakie informacje są ujawniane użytkownikowi lub klientowi.

Uwzględnianie ochrony danych w fazie projektowania wymaga ograniczenia celu, minimalizacji, prawidłowości, bezpieczeństwa i kontroli cyklu życia.¹⁵¹⁶ Przypadek użycia oparty na danych osobowych może wymagać dodatkowej oceny podstawy, praw osób, transferów i oceny skutków.

Log bezpieczeństwa nie powinien cicho zmieniać celu na ocenę pracownika. Jeżeli historia promptów lub liczba zapytań ma być używana do porównywania ludzi, powstaje nowe zamierzone użycie wymagające przeglądu prawa pracy, relacji pracowniczych, proporcjonalności, przejrzystości i ładu.

Bezpieczeństwo obejmuje:

• tożsamość i dostęp;
• sekrety;
• izolację danych;
• uprawnienia narzędzi;
• wstrzyknięcie promptu;
• wyprowadzenie danych;
• łańcuch dostaw;
• reagowanie na incydenty;
• kopie zapasowe i odtwarzanie;
• zmianę dostawcy.

ISO/IEC 42001 może wspierać system zarządzania AI, lecz odwołanie do normy nie zastępuje kontroli konkretnego promptu, źródła i narzędzia.²²²³

Przypadek użycia po wdrożeniu może zmienić się bez formalnej decyzji. Użytkownicy zaczynają wklejać inne dane. Prompt zostaje lokalnie zmodyfikowany. Baza wiedzy przestaje być aktualizowana. Dostawca zmienia model. Osoby dokonujące przeglądu coraz szybciej klikają „zatwierdź”. Wersja robocza zaczyna być kopiowana bez sprawdzenia.

Monitoring powinien obejmować:

• dryf jakości;
• dryf źródeł;
• zmianę modelu;
• dryf promptu;
• dryf użycia;
• miarę nadpisań;
• miarę korekt;
• obciążenie przeglądem;
• twierdzenia bez pokrycia w źródle;
• skargi klientów;
• alerty bezpieczeństwa;
• incydenty;
• rozszerzenie użycia wtórnego;
• sygnały utraty kompetencji i utraty umiejętności pracy ze źródłami.

Nie każda miara powinna być celem. Wzrost liczby nadpisań może oznaczać gorszy model, ale może też świadczyć o lepszej jakości przeglądu. Spadek czasu przeglądu może oznaczać prostszy wynik albo narastające nadmierne poleganie. Interpretacja wymaga kontekstu zgodnego z architekturą miar I07.

Pętla incydentu:

WYKRYJ
→ OGRANICZ SKUTKI
→ ZIDENTYFIKUJ OBJĘTE WYNIKI
→ POPRAW
→ PROPAGUJ KOREKTĘ
→ POWIADOM, JEŻELI WYMAGANE
→ PRZETESTUJ PONOWNIE
→ WZNÓW / ZAWIEŚ / WYCOFAJ

Incydentem może być:

• ujawnienie poufnego dokumentu;
• zapis błędnej wartości do CRM;
• wysyłka nieautoryzowanej wiadomości;
• masowe twierdzenie bez pokrycia w źródle;
• wstrzyknięcie promptu;
• działanie narzędzia poza zakresem;
• wykorzystanie logów do niezatwierdzonego monitoringu;
• użycie modelu poza zatwierdzonym językiem lub populacją.

Korekta lokalna nie wystarcza, jeżeli wynik trafił dalej.

Przypadek użycia wymaga ponownej walidacji, gdy zmienia się którykolwiek element mający znaczenie dla wyników lub ryzyka:

• model;
• wersja;
• prompt systemowy;
• wyszukiwanie kontekstu;
• źródło;
• prawa do źródła;
• zamierzone użycie;
• kategoria danych;
• uprawnienie narzędzia;
• język;
• grupa użytkowników;
• warunki dostawcy;
• komunikat bezpieczeństwa;
• prawo albo wytyczne;
• kryterium akceptacji;
• historia incydentów.

Cykl życia może wyglądać następująco:

DISCOVERY
→ DESIGN
→ REVIEW
→ TESTING
→ PILOT
→ LIMITED ACTIVE
→ ACTIVE
→ CHANGE PENDING
→ REVALIDATION REQUIRED
→ DEGRADED / SUSPENDED
→ SUPERSEDED / RETIRED
→ WITHDRAWN
→ ARCHIVED / DELETED

Wygaszenie oznacza planowe zakończenie przypadku użycia. Wycofanie oznacza, że określony wynik, źródło, model albo decyzja nie mogą być dalej używane i trzeba odnaleźć zależności w dole strumienia.

Rejestr wycofań powinien wskazać:

withdrawal_id:
trigger:
affected_source_or_model:
affected_outputs:
affected_records:
affected_messages:
affected_decisions:
owners:
containment:
correction:
notification:
retest:
closure_evidence:

To rozróżnienie ma znaczenie w sprzedaży. Błędny briefing może jedynie wymagać korekty notatki. Błędne zobowiązanie klienta wpisane do CRM może wpłynąć na prognozę, zatwierdzenie ceny, plan zasobów i komunikację z klientem.

Research jest jednym z najbardziej naturalnych zastosowań AI. Model może wyszukać informacje, porównać dokumenty i przygotować roboczą syntezę. Wartość pojawia się jednak dopiero wtedy, gdy wynik rozdziela:

• fakty;
• źródła;
• daty;
• hipotezy;
• pytania;
• niewiadome;
• ograniczenia.

Przykład syntetyczny 1 — publiczny research accountu

Handlowiec przygotowuje się do rozmowy z producentem przemysłowym. Zbiór źródeł obejmuje stronę firmy, raport roczny, komunikaty prasowe i publiczny rejestr. AI przygotowuje briefing, ale nie korzysta z losowych wpisów bez właściciela ani z pamięci modelu jako źródła.

Dozwolony wynik:

FAKT:
Spółka ogłosiła inwestycję X w dniu Y.
ŹRÓDŁO:
link + data publikacji.

HIPOTEZA:
Inwestycja może zwiększyć zapotrzebowanie na Z.
DOWODY ZA:
...
DOWODY PRZECIW:
...

PYTANIE:
Jak nowy projekt wpłynie na obecny proces zakupowy?

NIEWIADOMA:
Nie znaleziono potwierdzonej informacji o harmonogramie.

Przykład syntetyczny 2 — sprzeczne źródła

Jedno źródło mówi o uruchomieniu zakładu w Q3, drugie o opóźnieniu. Model nie powinien wybierać wersji pasującej do narracji. Prawidłowy status to CONFLICTING_SOURCES z pytaniem do klienta.

Research nie powinien tworzyć profili osób na podstawie języka postów, zdjęć albo stylu komunikacji. Nie należy również przedstawiać hipotezy o problemie biznesowym jako zdiagnozowanej potrzeby.

AI może pomóc w przygotowaniu pytań, jeżeli zna:

• cel rozmowy;
• rolę rozmówcy;
• dostępne fakty;
• znane niewiadome;
• ograniczenia;
• metodę sprzedaży;
• zakazane założenia.

Przykład syntetyczny 3 — pytania discovery z CRM i strony klienta

CRM zawiera opis „problem z wydajnością”, lecz pole nie ma wskazania źródła i zostało zapisane osiem miesięcy wcześniej. Strona klienta informuje o nowej inwestycji. AI powinno oznaczyć pole CRM jako nieaktualne i bez pokrycia w źródle, a następnie zaproponować pytania weryfikujące, zamiast budować diagnozę.

Dozwolony wynik:

• pytanie o aktualny stan;
• pytanie o wpływ inwestycji;
• pytanie o obecny proces;
• pytanie o kryteria decyzji;
• pytanie o interesariuszy;
• lista założeń wymagających potwierdzenia.

Niedozwolony wynik:

Klient ma problem z wydajnością i pilnie potrzebuje naszego rozwiązania.

AI może również tworzyć warianty pytań dla roli technicznej, finansowej lub operacyjnej. Nie powinno jednak udawać znajomości motywacji rozmówcy.

Dobre przygotowanie nie polega na maksymalizacji liczby pytań. Polega na poprawie jakości hipotez i gotowości do ich odrzucenia.

Podsumowanie spotkania może oszczędzać czas, ale wymaga kontrolowanego źródła i jawnego statusu.

Przykład syntetyczny 4 — autoryzowana transkrypcja

Organizacja ma wymagany przegląd celu, nagrania, transkrypcji i retencji. AI tworzy wersję roboczą:

• tematów;
• pytań klienta;
• otwartych kwestii;
• proponowanych działań do wykonania;
• cytowanych deklaracji.

Model nie powinien samodzielnie zmieniać „rozważymy termin” w „klient potwierdził termin”.

Przykład syntetyczny 5 — ekstrakcja pól z oferty

System wyciąga walutę, datę ważności, wersję i zakres. Każde pole ma wskazanie źródła i poziom pewności. Wartości wymagające interpretacji trafiają do przeglądu.

Granica J01 pozostaje aktywna:

Przed zapisem do CRM potrzebne są:

• właściwy typ rekordu;
• znaczenie pól;
• źródło;
• znacznik czasu;
• właściciel;
• ścieżka korekty;
• punkt kontrolny człowieka.

CRM jako system decyzji definiuje te wymagania, a Karta Rekordu i Przepływu Pracy CRM pozwala je zaprojektować operacyjnie.

Wiadomość do klienta ma skutek zewnętrzny. Może tworzyć zobowiązanie, ujawniać warunki, zmieniać oczekiwania albo wpływać na relację. Dlatego CUSTOMER_FACING_DRAFT jest odrębnym statusem.

Przykład syntetyczny 6 — follow-up po spotkaniu

AI otrzymuje zatwierdzone notatki i listę potwierdzonych ustaleń. Wynik zawiera:

• podziękowanie;
• faktycznie uzgodnione punkty;
• jawne działania do wykonania;
• właścicieli;
• daty wyłącznie wtedy, gdy zostały potwierdzone;
• pytania wymagające doprecyzowania.

Przegląd powinien sprawdzić:

• zgodność z ustaleniami;
• brak nowych zobowiązań;
• brak niedozwolonych danych;
• ton;
• poprawność techniczną;
• właściwego adresata;
• załączniki i linki.

Automatyczna wysyłka nie jest autoryzowana przez sam fakt, że wersja robocza przeszła test językowy. Gdy przypadek użycia ma wykonywać zewnętrzną akcję, potrzebna jest również architektura J03: warunki wstępne, idempotencja, wyjątek, wycofanie zmiany i sprzeciw.

Przykład syntetyczny 7 — warianty argumentacji

AI może wygenerować trzy sposoby przedstawienia wartości. Handlowiec wybiera wersję, sprawdza twierdzenia i dostosowuje ją do rozmowy. Wynik nie powinien tworzyć fałszywych studiów przypadku ani danych ROI.

Tłumaczenie robocze może być bezpieczniejszym przypadkiem użycia niż autonomia, ale nadal ma ograniczenia.

Przykład syntetyczny 8 — odpowiedź techniczna

Inżynier sprzedaży przygotowuje odpowiedź po polsku. AI tłumaczy ją na język klienta. Przegląd dwujęzyczny i dziedzinowy sprawdza:

• terminologię;
• jednostki;
• warunki;
• modalność;
• zakres gwarancji;
• sformułowania mogące tworzyć zobowiązanie.

Model nie jest autorytatywnym źródłem wiedzy technicznej. Tłumaczenie nie powinno „ulepszać” treści przez dodawanie brakujących parametrów.

Przykład syntetyczny 9 — porównanie wersji oferty

AI wskazuje różnice między wersją A i B. Każda różnica ma wskazanie źródła. System nie ocenia samodzielnie, która wersja jest prawnie wiążąca.

Przykład syntetyczny 10 — poufny cennik w publicznej usłudze

Handlowiec wkleja cennik, marże i politykę rabatową do publicznej usługi konsumenckiej. Prawidłowym wynikiem jest HOLD_DATA_OR_SECURITY, przegląd ujawnienia i korekta procesu. Wysoka jakość tłumaczenia nie kompensuje niedopuszczalnego środowiska.

AI może analizować tekst, ton, tempo, historię działań i metadane. Z tego nie wynika, że organizacja powinna inferować:

• emocje;
• osobowość;
• szczerość;
• motywację;
• zaangażowanie;
• lojalność;
• potencjał;
• intencję odejścia;
• „jakość człowieka”.

Takie wyniki są problematyczne metodologicznie, organizacyjnie i prawnie. Mogą być przedstawiane z pozorną precyzją, mimo braku wiarygodnych danych referencyjnych. W środowisku pracy tworzą asymetrię i ryzyko niejawnego profilowania.

J02 nie autoryzuje:

• seller score;
• rankingów opartych na promptach i aktywności;
• automatycznych rekomendacji premii, awansu lub sankcji;
• oceny coachingu na podstawie niejawnych notatek AI;
• zamiany telemetrii wsparcia w monitorowanie wyników pracy.

Granice kompetencji, obserwacji i coachingu są zdefiniowane w materiale o kompetencjach handlowca oraz materiale o coachingu opartym na obserwacji. AI nie zastępuje obserwowalnego kryterium ani procesu formalnego.

Materiały dotyczące praktyk zakazanych i systemów używanych w kontekście zatrudnienia wymagają aktualnego, konkretnego przeglądu zamierzonego celu.¹¹¹³

Miary powinny wspierać określoną decyzję o utrzymaniu, zmianie, ograniczeniu albo wycofaniu przypadku użycia.

Mały portfel może obejmować:

Wynik zadania

• czas do pierwszej użytecznej wersji roboczej;
• odsetek przypadków zakończonych użytecznym wynikiem;
• odsetek przypadków zwróconych jako unknown;
• poprawa dostępności wiedzy.

Jakość

• wierność wobec źródła;
• pokrycie twierdzenia cytowaniem;
• miara twierdzeń bez pokrycia w źródle;
• miara korekt;
• kompletność względem schematu wyniku;
• odsetek pominiętych dowodów przeciwnych.

Przegląd przez człowieka

• czas przeglądu;
• odsetek nadpisań;
• typy korekt;
• przypadki zatwierdzenia mimo braku źródła;
• obciążenie osoby dokonującej przeglądu.

Ryzyko i kontrola

• ustalenia dotyczące wstrzyknięcia promptu;
• incydenty;
• dane niedozwolone w promptach;
• dryf użycia;
• zmiana modelu;
• opóźnienie wycofania.

Adopcja i uczenie się

• prawidłowe użycie statusów;
• umiejętność rozróżnienia źródła i wyniku;
• odsetek użytkowników stosujących unknown;
• liczba przypadków zatrzymanych przez bramę.

Nie należy sumować tych miar do jednego AI score. Wzrost szybkości nie powinien kompensować twierdzeń bez pokrycia w źródle. Niska miara nadpisań nie zawsze oznacza jakość. Może oznaczać słaby przegląd.

Czego nie uznawać za samodzielny dowód sukcesu

Liczba wygenerowanych treści nie mówi, czy treści były użyteczne, poprawne albo wysłane. Może rosnąć tylko dlatego, że generowanie stało się tanie.

Liczba użytkowników nie dowodzi prawidłowego użycia. Użytkownicy mogą korzystać z funkcji poza zatwierdzonym zakresem, wklejać niedozwolone dane albo pomijać przegląd źródeł.

Średni czas zadania nie ujawnia kosztu w dole strumienia. Krótsze przygotowanie briefingu może zostać skompensowane dłuższą korektą, błędną rozmową lub utratą zaufania klienta.

Ocena satysfakcji jest wartościowym sygnałem, lecz użytkownicy mogą preferować wynik pewny, długi i łatwy do skopiowania, nawet jeżeli jest gorzej ugruntowany.

Niski odsetek odmów modelu nie musi być dobry. Przypadek użycia powinien umieć zatrzymać się przy braku dowodów, sprzecznych źródłach i niedozwolonym zadaniu.

Wysoki odsetek zatwierdzeń może wynikać z dobrej jakości albo z ceremonialnego przeglądu. Trzeba analizować dostęp do źródeł, czas, korekty i różnice między osobami dokonującymi przeglądu.

Brak incydentów nie oznacza braku ryzyka. Organizacja może nie mieć detekcji, użytkownicy mogą nie zgłaszać błędów, a nieprawidłowy wynik może pozostać niewykryty.

Decyzje, które powinny wynikać z miar

Portfel miar ma prowadzić do jawnego wyniku:

• utrzymaj przypadek użycia bez zmiany;
• ogranicz zakres;
• zmień zbiór źródeł;
• zmień prompt lub schemat wyniku;
• zwiększ albo zmniejsz zakres przeglądu;
• popraw szkolenie i AI literacy;
• przeprowadź ponowny test;
• zawieś funkcję;
• wróć do manualnego procesu;
• wycofaj wyniki w dole strumienia.

Miara bez reguły działania staje się pulpitem obserwacyjnym. Z kolei reguła działania nie powinna działać automatycznie, gdy wynik wymaga interpretacji kontekstu. Na przykład wzrost miary korekt może wskazywać na pogorszenie modelu, ale może również wynikać z rozszerzenia użycia na trudniejszą populację. Przed zmianą trzeba sprawdzić obiekt, źródło, okno, użytkowników i wersję konfiguracji.

KPI nowoczesnej sprzedaży B2B i narzędzie do projektowania miar dostarczają właściwych reguł obiektu, populacji, źródła, okna, obchodzenia i reguły działania.

Plan 30/60/90 nie jest gwarancją wdrożenia. Jest sekwencją decyzji z możliwością zatrzymania.

Dni 1–30: rozpoznanie i projektowanie

• wybierz jedno zadanie;
• opisz linię bazową;
• wskaż użytkownika i właściciela decyzji;
• zapisz użycia zakazane;
• zbuduj rejestr źródeł;
• sprawdź prawa, ochronę danych i bezpieczeństwo;
• opisz model i dostawcę;
• zaprojektuj schemat wyniku;
• zdefiniuj przegląd przez człowieka;
• przygotuj zbiór wzorcowy;
• ustal kryteria zatrzymania.

Wynikiem może być NO AI, jeżeli proces jest zbyt niejasny albo zbiór źródeł niewystarczający.

Dni 31–60: testowanie i pilot

• wersjonuj prompt i wyszukiwanie kontekstu;
• ogranicz uprawnienia narzędzi;
• porównaj z linią bazową;
• przetestuj przypadki brzegowe, wrogiego użycia i wielojęzyczne;
• zmierz wierność wobec źródła;
• zmierz obciążenie;
• przeprowadź testy bezpieczeństwa i ochrony danych;
• uruchom mały pilot;
• zbieraj nadpisania i korekty;
• utrzymuj status TESTING_OR_PILOT.

Nie rozszerzaj pilota tylko dlatego, że użytkownicy lubią styl wyniku.

Dni 61–90: decyzja o ograniczonym użyciu

• przeanalizuj wyniki;
• sprawdź incydenty;
• sprawdź dryf użycia;
• zatwierdź albo zmień zbiór źródeł;
• zdefiniuj monitoring;
• zatwierdź wyzwalacze ponownej walidacji;
• przetestuj ścieżkę incydentu;
• przetestuj wycofanie;
• podejmij decyzję: skalowanie, przeprojektowanie, ograniczenie, wstrzymanie, zatrzymanie albo wygaszenie.

Skalowanie oznacza powtarzalność kontroli, nie tylko więcej licencji.

Karta Przypadku Użycia AI w Pracy Handlowca prowadzi jeden przypadek użycia przez WAI-1–WAI-10.

Narzędzie powinno zawierać tryby:

• szybki zakres przypadku użycia;
• pełne przejście WAI-1–WAI-10;
• przegląd źródeł i uprawnień;
• przegląd modelu, dostawcy i wersji;
• przegląd promptu, wyszukiwania kontekstu i narzędzi;
• przegląd wyniku, cytowań i niepewności;
• przegląd przeglądu przez człowieka i korekty;
• przegląd testowania i red teamu;
• zatrzymanie z powodu ochrony danych, bezpieczeństwa i logowania;
• monitoring, ponowna walidacja i wycofanie.

Rejestry obejmują:

• karta przypadku użycia;
• rejestr użyć zakazanych;
• rejestr źródeł;
• rekord modelu i usługi;
• rekord promptu i konfiguracji;
• mapa uprawnień narzędzi;
• kontrakt wyniku;
• karta przeglądu przez człowieka;
• plan testów i wyniki;
• rejestr incydentów;
• rejestr monitoringu;
• rejestr zmian;
• rejestr propagacji wycofania.

Narzędzie nie generuje punktacji ani rekomendacji „wdrażaj/nie wdrażaj” bez jawnych kryteriów. Jego dozwolone wyniki obejmują między innymi podział zakresu, tylko wersja robocza, usunięcie źródła, dodanie przeglądu, ponowny test, wstrzymanie, wstrzymanie i wycofanie.

W przypadku aktywnego monitoringu, użycia na poziomie osoby, danych poufnych, niejasnych praw, wstrzyknięcia promptu albo niedozwolonej inferencji narzędzie ma zwrócić zatrzymanie albo skierowanie do specjalisty.

J02 jest trzecim modułem Obszaru J — AI, technologia, dane i RevOps.

J00 — architektura technologii sprzedaży definiuje zdolności, przepływ pracy, aplikacje, integracje, dostęp, obserwowalność, dostawców i cykl życia. TOOL-J00 pozwala odwzorować tę architekturę.

J01 definiuje typy rekordów, stany, dowód, własność, korektę i granicę użycia wtórnego. J02 może korzystać z tych rekordów wyłącznie jako z kontrolowanych źródeł.

Granice wobec Obszaru I pozostają aktywne:

• I03 definiuje obserwowalne kompetencje;
• I04 definiuje coaching oparty na obserwacji;
• I07 definiuje miary;
• I08 definiuje rytm, mandat, przegląd i eskalację.

Rola managera sprzedaży jest szczególnie istotna, ponieważ osoba dokonująca przeglądu i właściciel decyzji muszą istnieć w realnym rytmie operacyjnym, a nie wyłącznie w formularzu AI.

J02 nie projektuje pełnej automatyzacji. J03 przejmie wyzwalacze, zapisy, działania zewnętrzne, wyjątki, idempotencję i wycofanie zmiany. J02 nie zarządza również całym portfolio AI. J06 przejmie spis, klasyfikację, ład, incydenty i wycofanie na poziomie organizacji.

Taka kolejność zapobiega automatyzowaniu wyniku, zanim wiadomo, czy zadanie, źródła, wynik i mandat są poprawnie zaprojektowane.

WAI-1–WAI-10, UAI-0–UAI-12, pozostałe taksonomie oraz 60 wyników są autorską syntezą operacyjną. Nie są:

• certyfikowanym systemem zarządzania;
• opinią prawną;
• DPIA ani FRIA;
• zwalidowaną skalą ryzyka;
• punktem odniesienia modelu;
• oceną bezpieczeństwa konkretnej aplikacji;
• gwarancją zgodności z AI Act, RODO albo Data Act;
• procedurą formalnego HR;
• dowodem, że AI poprawia wynik sprzedaży;
• licencją na autonomiczne działanie.

Architekturę zakresu i przekazań wyprowadzono z dokumentów nadrzędnych projektu, zamkniętych modułów J00–J01 oraz granic Obszaru I.^{24122532627282930}

Dynamiczne granice AI, ochrony danych, profilowania, przejrzystości i AI literacy oparto na prawie oraz oficjalnych materiałach, które muszą zostać ponownie sprawdzone dla konkretnego zamierzonego celu.^{11121314311581632}

Warstwa ładu, testowania i bezpieczeństwa korzysta z NIST AI RMF, profilu GenAI, playbooka, wytycznych bezpiecznego wytwarzania, OWASP i MITRE ATLAS.^4521181920 ISO/IEC 42001 oraz pakiet norm dotyczących ładu i oceny skutków są źródłami wymagań systemowych, nie deklaracją certyfikacji.²²²³

Pochodzenie danych i dokumentacja modelu wykorzystują W3C PROV-O oraz koncepcję model cards.⁶¹⁷ Badania nad współpracą człowiek–AI, wiernością wobec źródła w RAG i nadmiernym poleganiem wspierają potrzebę kontekstowego testowania, niepewności, realnego przeglądu i kontroli utraty kompetencji.⁹⁷¹⁰

Przed zastosowaniem tego materiału w konkretnym wdrożeniu należy ponownie zweryfikować:

• harmonogram i zakres AI Act po 2 sierpnia 2026 r.;
• późniejsze daty stosowania i wyjątki;
• aktualne wytyczne Komisji i EDPB;
• polskie prawo pracy i monitoring;
• Data Act;
• warunki dostawców;
• podprzetwarzających;
• lokalizację danych;
• wersje modeli;
• zachowanie API;
• komunikaty bezpieczeństwa;
• sposób retencji i użycia danych do treningu.

Finalny artykuł, TOOL-J02, formularze, diagramy i eksporty wymagają również audytu dostępności oraz testów w realnym środowisku.