INTRO

Zaczyna się niewinnie. Klient wysyła wiadomość: "Chcielibyśmy wykorzystać AI w projekcie. Podobno teraz wszystko można zrobić szybciej i taniej". Brzmi rozsądnie. Ty też lubisz szybciej i taniej, szczególnie kiedy dotyczy to wystawiania faktur, a nie liczby godzin potrzebnych na wykonanie zlecenia. Pytasz więc, do czego konkretnie sztuczna inteligencja ma zostać wykorzystana. Klient odpowiada: "No, do wszystkiego, do czego się da". W tym momencie zapala się pierwsza lampka ostrzegawcza. Druga zapala się, kiedy słyszysz, że wyniki mają być oczywiście bezbłędne. Trzecia, gdy okazuje się, że klient zamierza przesłać poufne dokumenty i oczekuje, że po zakończeniu projektu nikt nie będzie miał do nich dostępu. Czwarta już się nie zapala, bo instalacja elektryczna zdrowego rozsądku właśnie odmówiła współpracy.

Sztuczna inteligencja potrafi być znakomitym pomocnikiem. Może przyspieszać przygotowywanie szkiców, porządkowanie informacji, analizę materiałów, tworzenie wariantów treści czy wykonywanie powtarzalnych czynności. Nie oznacza to jednak, że wraz z uruchomieniem narzędzia wszystkie obowiązki człowieka przechodzą na serwer znajdujący się gdzieś w nieokreślonej części świata. AI nie podpisuje z klientem umowy, nie odbiera telefonu z reklamacją i nie tłumaczy zirytowanemu zarządowi, dlaczego w raporcie pojawiły się liczby, których nikt nigdy nie obliczył. Potrafi natomiast przedstawić błędną odpowiedź z taką pewnością siebie, z jaką niektórzy konsultanci przedstawiają fakturę za pięć minut rozmowy.

Problem zaczyna się wtedy, kiedy strony zlecenia używają tego samego słowa, ale rozumieją przez nie zupełnie inne rzeczy. Dla klienta "wykorzystanie AI" może oznaczać niższą cenę i błyskawiczny rezultat. Dla wykonawcy oznacza możliwość usprawnienia wybranych etapów pracy. Dla osoby odpowiedzialnej za bezpieczeństwo informacji oznacza pytania o poufność, dostęp, przechowywanie i dalsze wykorzystanie danych. Dla działu prawnego może oznaczać konieczność sprawdzenia umowy, praw do materiałów i warunków korzystania z konkretnego rozwiązania. Wszyscy siedzą przy jednym stole, wszyscy przytakują, a każdy uczestniczy w innym spotkaniu. Gdyby rozdano im protokoły, powstałyby cztery wersje rzeczywistości. I żadna nie zawierałaby rubryki "kto sprawdzi wynik przed publikacją".

Właśnie dlatego rozmowa o AI powinna zaczynać się wcześniej niż rozmowa o wyborze narzędzia. Najpierw trzeba ustalić, jaki rezultat ma powstać, co wolno przekazać systemowi, które czynności można wspomagać automatycznie i kto podejmuje ostateczne decyzje. Dopiero później warto zastanawiać się, jaki model, aplikacja czy automatyzacja najlepiej pasuje do zadania. Odwrotna kolejność przypomina kupowanie maszyny produkcyjnej przed ustaleniem, co właściwie zamierzamy produkować. Owszem, maszyna może robić imponujące wrażenie. Szczególnie kiedy kosztuje dużo i ma podświetlane przyciski. Nadal jednak nie odpowiada na pytanie, czy produkt końcowy nadaje się do użycia.

Wyobraź sobie zlecenie przygotowania raportu na podstawie danych sprzedażowych. Klient chce wykorzystać AI, żeby ograniczyć czas pracy. To całkiem sensowny pomysł, dopóki obie strony rozumieją, co rzeczywiście zostanie zautomatyzowane. Czy narzędzie ma uporządkować dostarczone dane? Zaproponować strukturę raportu? Wskazać potencjalne zależności? A może samodzielnie przygotować wnioski, które zostaną przedstawione kierownictwu? Każdy z tych wariantów wymaga innej kontroli. Jeżeli źródłowe dane zawierają informacje poufne, dochodzi jeszcze kwestia sposobu ich przetwarzania. Bez tych ustaleń wykonawca może dostarczyć estetyczny dokument, klient może uznać go za wiarygodny, a błąd w podstawowych obliczeniach spokojnie przejść przez cały proces. W końcu wykres wygląda profesjonalnie. A profesjonalnie wyglądający błąd bywa szczególnie przekonujący.

Nie chodzi o to, żeby przed każdym użyciem sztucznej inteligencji organizować posiedzenie komisji, przygotowywać trzydzieści siedem załączników i żądać podpisu osoby odpowiedzialnej za ekspres do kawy. Chodzi o proporcje. Prosty projekt może wymagać krótkiego, jednoznacznego ustalenia zasad. Zlecenie obejmujące dane wrażliwe, ważne decyzje biznesowe lub materiały przeznaczone do publicznego wykorzystania może potrzebować dokładniejszych zabezpieczeń. Stopień kontroli powinien odpowiadać rzeczywistemu ryzyku. Nadmierna biurokracja potrafi skutecznie zabić korzyści z automatyzacji, ale całkowity brak zasad zamienia współpracę w eksperyment, którego wyniki poznaje się dopiero podczas reklamacji.

Jest jeszcze kwestia odpowiedzialności, szczególnie niewygodna dla osób wierzących, że technologia rozwiązuje również problemy organizacyjne. W praktyce trzeba odróżnić odpowiedzialność za wykonanie uzgodnionej pracy, dostarczenie prawidłowych materiałów wejściowych, sprawdzenie rezultatów oraz zatwierdzenie ich wykorzystania. Te obowiązki mogą należeć do różnych osób, zależnie od zakresu zlecenia i przyjętych ustaleń. Samo wpisanie w umowie "wykorzystano AI" nie rozstrzyga sprawy. Podobnie zdanie "za błędy odpowiada sztuczna inteligencja" nie tworzy magicznego podmiotu gotowego pokryć straty. Gdyby chatboty posiadały własne działy reklamacji i budżety odszkodowawcze, świat biznesu wyglądałby interesująco. Na razie jednak warto rozmawiać z ludźmi, którzy rzeczywiście podejmują decyzje i zawierają umowy.

To nie jest książka przeciwko AI. Wręcz przeciwnie. Jej celem jest pokazanie, jak korzystać z tej technologii bez budowania współpracy na niedopowiedzeniach. Entuzjazm klienta nie jest problemem. Problemem jest entuzjazm połączony z przekonaniem, że skoro narzędzie potrafi wygenerować odpowiedź, to automatycznie gwarantuje jej poprawność. Równie niebezpieczna bywa przesadna pewność wykonawcy, który obiecuje rezultaty, zanim sprawdzi ograniczenia rozwiązania. Rozsądna współpraca nie wymaga ani straszenia technologią, ani przedstawiania jej jako elektronicznego cudotwórcy. Wymaga umiejętności zadawania właściwych pytań, ustalania granic i uczciwego opisywania możliwości.

Nauczysz się rozpoznawać niejasne oczekiwania, oddzielać obietnice marketingowe od rzeczywistych funkcji narzędzi oraz prowadzić rozmowę o zakresie użycia AI w sposób, który nie zamienia negocjacji w przesłuchanie. Przyjrzymy się temu, jak ustalać zasady korzystania z danych, co powinno podlegać weryfikacji, jak dokumentować istotne decyzje i jak reagować, kiedy klient zmienia oczekiwania w połowie realizacji. Ważne będzie również odróżnianie kontroli sensownej od pozornej. Człowiek, który bez czytania klika "zatwierdź", nie staje się skutecznym mechanizmem bezpieczeństwa tylko dlatego, że w procedurze nazwano go weryfikatorem.

Nie otrzymasz za to uniwersalnej klauzuli, która w każdych okolicznościach zwolni wykonawcę z odpowiedzialności. Takie rozwiązanie byłoby wygodne, ale zbyt piękne, żeby traktować je poważnie. Konkretne obowiązki zależą między innymi od umowy, rodzaju danych, sposobu wykorzystania rezultatu i właściwych przepisów. W sprawach wymagających oceny prawnej lub specjalistycznej kontroli bezpieczeństwa potrzebna może być pomoc odpowiednich ekspertów. Dobre zasady współpracy pomagają ograniczać nieporozumienia i ryzyko, lecz nie zastępują prawa ani profesjonalnej oceny sytuacji. Za to pozwalają uniknąć wielu sporów, które zaczynają się od niewinnego "myślałem, że to oczywiste".

Najważniejsza zmiana dotyczy sposobu myślenia o samym zleceniu. AI nie jest osobnym uczestnikiem negocjacji, któremu można przypisać wszystkie niewygodne obowiązki. Jest elementem procesu zaprojektowanego i nadzorowanego przez ludzi. Dobry proces określa, jakie zadanie wykonuje narzędzie, na jakich materiałach pracuje, jakie ograniczenia trzeba respektować oraz po czym poznamy, że wynik nadaje się do zaakceptowania. To znacznie mniej efektowne niż obietnica rewolucji w trzy kliknięcia. Ma jednak pewną przewagę: kiedy pojawia się problem, wiadomo, od czego zacząć jego rozwiązanie, zamiast organizować zbiorowe poszukiwania winnego w historii promptów.

Jeżeli więc klient oznajmi, że chce AI, nie musisz odpowiadać ani bezwarunkowym "oczywiście", ani przerażonym "absolutnie nie". Możesz zapytać, czego konkretnie oczekuje, jakie dane chce wykorzystać i jak będzie oceniał rezultat. Te pytania nie zabijają innowacji. Dają jej warunki, w których może naprawdę przynieść korzyść. Bo najlepsze zlecenie z wykorzystaniem sztucznej inteligencji nie jest tym, w którym człowiek znika z procesu. Jest tym, w którym wszyscy wiedzą, co robi technologia, co robią ludzie i kto odpowiada za ustalone obowiązki.

A jeśli ktoś nadal upiera się, że za wszystkie błędy powinien odpowiadać chatbot, można poprosić go o dane do faktury wystawionej na tego chatbota. Reakcja zwykle pomaga przywrócić rozmowie właściwy kierunek.

Rozdział 1 - Klient chce AI. Tylko co właściwie chce kupić?

"Chcemy, żeby w tym projekcie było AI". To zdanie potrafi rozpocząć rozmowę biznesową z podobną precyzją jak zamówienie samochodu, który ma być "nowoczesny i fajny". Niby wiadomo, o co chodzi, ale spróbuj na tej podstawie ustalić wyposażenie, cenę i termin dostawy. Dla jednego klienta AI oznacza chatbota odpowiadającego na pytania. Dla drugiego automatyczne przygotowywanie dokumentów. Trzeci wyobraża sobie system, który sam analizuje dane, podejmuje decyzje i jeszcze uprzejmie informuje pracowników, że mogą iść wcześniej do domu. Wykonawca słyszy natomiast nazwę technologii i próbuje zgadnąć, jaki produkt powinien dostarczyć. Jeżeli obie strony nie zatrzymają się na chwilę przy znaczeniu tego jednego słowa, projekt może rozpocząć się w atmosferze pełnego porozumienia, które istnieje wyłącznie dlatego, że nikt jeszcze nie zadał konkretnego pytania.

Współpraca z klientem zaczyna się od ustalenia potrzeby, a nie od wyboru technologii. Brzmi banalnie, dopóki ktoś nie pokazuje prezentacji, na której wielkimi literami napisano "AI TRANSFORMATION", a pod spodem znajduje się osiem ikon robotów i ani jedno mierzalne zadanie. Prawdziwa potrzeba zwykle jest znacznie prostsza. Klient chce skrócić czas przygotowywania ofert, szybciej odpowiadać na powtarzające się zapytania, uporządkować dokumentację albo ograniczyć ręczne przepisywanie informacji. To są problemy, które można opisać, zmierzyć i przeanalizować. AI jest jedną z możliwych dróg ich rozwiązania. Czasem bardzo dobrą, czasem przeciętną, a niekiedy zupełnie niepotrzebną. Jeśli zadanie polega na przeniesieniu pięciu wartości z jednego pola formularza do drugiego, być może wystarczy zwykła automatyzacja. Angażowanie do tego rozbudowanego modelu językowego przypomina zatrudnianie orkiestry symfonicznej do odtworzenia dźwięku domofonu.

Pierwsze nieporozumienie pojawia się więc między tym, czego klient potrzebuje, a tym, o co prosi. Weźmy fikcyjny przykład właścicielki firmy obsługującej nieruchomości. Chce wdrożyć AI do komunikacji z najemcami, ponieważ pracownicy codziennie odpowiadają na dziesiątki podobnych wiadomości. Na pierwszym spotkaniu mówi, że potrzebuje inteligentnego asystenta. Kiedy wykonawca zaczyna zadawać pytania, okazuje się, że w rzeczywistości wystarczyłoby przygotowywanie propozycji odpowiedzi na podstawie zatwierdzonej bazy informacji. Pracownik miałby je sprawdzać i wysyłać. To rozwiązanie znacznie różni się od systemu, który samodzielnie interpretuje reklamacje, obiecuje terminy napraw i podejmuje zobowiązania w imieniu firmy. Oba można nazwać "asystentem AI". Różnica w ryzyku jest jednak mniej więcej taka jak między osobą przygotowującą projekt pisma a osobą podpisującą umowy bez pytania przełożonego.

Dlatego warto rozpocząć rozmowę od zwyczajnego pytania: "Co dokładnie ma się zmienić po zakończeniu projektu?". Nie pytaj od razu o preferowany model, liczbę automatyzacji ani aplikację, którą klient zobaczył na konferencji. Poproś o opis obecnego procesu. Kto wykonuje zadanie? Ile czasu zajmuje? Jakie materiały wykorzystuje? Co najczęściej powoduje opóźnienia? Po czym klient poznaje, że praca została wykonana prawidłowo? Takie pytania pomagają odróżnić problem od pomysłu na jego rozwiązanie. Bywają też zaskakująco niewygodne, ponieważ wymagają znajomości własnej organizacji. Znacznie łatwiej powiedzieć "potrzebujemy sztucznej inteligencji" niż przyznać, że trzy działy przechowują te same dane w różnych plikach, z których każdy nosi nazwę "final_ostateczny_poprawiony".

Kiedy potrzeba zostaje nazwana, pojawia się drugie ważne rozróżnienie: AI może pomagać wykonawcy albo stanowić część rozwiązania dostarczanego klientowi. To nie są identyczne sytuacje. Grafik może wykorzystać narzędzie generatywne do poszukiwania wstępnych koncepcji, a następnie samodzielnie opracować finalny projekt. Analityk może wspomagać się AI przy przygotowywaniu kodu, który później sprawdzi i uruchomi. W takich przypadkach technologia uczestniczy w procesie wykonania usługi. Inaczej wygląda zlecenie, którego rezultatem jest działający system AI przeznaczony do dalszego użytkowania przez klienta. Wtedy przedmiotem odbioru może być nie tylko pojedynczy materiał, ale również zachowanie rozwiązania w określonych warunkach, jego ograniczenia i sposób obsługi. Zapis "wykorzystanie AI w projekcie" nie wyjaśnia, o którym wariancie rozmawiamy.

Istnieje także różnica między przygotowywaniem sugestii a automatycznym wykonywaniem działań. Model proponujący treść odpowiedzi działa inaczej niż system, który wysyła tę odpowiedź bez zatwierdzenia. Narzędzie identyfikujące możliwe niezgodności w dokumentach ma inną rolę niż rozwiązanie, które samo odrzuca dokumenty i powiadamia zainteresowanych o negatywnej decyzji. Z perspektywy prezentacji sprzedażowej oba rozwiązania mogą wyglądać równie nowocześnie. Z perspektywy organizacji mają zupełnie inne konsekwencje. Im większa samodzielność systemu, tym staranniej należy ustalić, jakie czynności wolno mu wykonywać, kiedy powinien przekazać sprawę człowiekowi i co stanie się w przypadku nieprawidłowego działania. Nie trzeba od razu budować procedury przypominającej kontrolę startu rakiety kosmicznej. Trzeba jednak wiedzieć, czy nasza rakieta ma wyświetlać sugestię lotu, czy rzeczywiście wystartować.

Klient często nie potrafi precyzyjnie nazwać oczekiwanego poziomu automatyzacji. Nie oznacza to, że jest niekompetentny. Może doskonale znać swoją branżę i jednocześnie nie wiedzieć, jakie ograniczenia ma wybrane narzędzie. Właśnie po to zatrudnia wykonawcę, żeby pomógł mu przełożyć potrzebę na możliwe rozwiązanie. Problem powstaje dopiero wtedy, kiedy niewiedza zostaje ukryta pod warstwą pewnych deklaracji. Klient mówi "system powinien sam wiedzieć", a wykonawca odpowiada "oczywiście, zrobimy inteligentne rozwiązanie". Oboje czują się profesjonalnie. Niestety żadne z tych zdań nie mówi, skąd system ma czerpać wiedzę, co zrobić z brakującą informacją ani kiedy powinien odmówić udzielenia odpowiedzi.

Dobry wykonawca nie musi znać odpowiedzi na wszystkie pytania podczas pierwszego spotkania. Powinien natomiast umieć oddzielić to, co już wiadomo, od tego, co wymaga sprawdzenia. Jeżeli klient oczekuje automatycznego przetwarzania dokumentów, warto poprosić o kilka reprezentatywnych przykładów, o ile można je bezpiecznie udostępnić. Dopiero analiza rzeczywistych formatów, jakości i różnorodności materiałów pokaże, czy pomysł jest wykonalny w planowanym zakresie. Dziesięć elegancko przygotowanych plików demonstracyjnych może dać doskonały wynik. Jeden skan dokumentu sprzed piętnastu lat, zapisany pod kątem i ozdobiony pieczątką na najważniejszej liczbie, potrafi skutecznie przywrócić technologiczny entuzjazm do poziomu umożliwiającego racjonalną rozmowę.

W tym miejscu przydaje się prosty sposób uporządkowania oczekiwań. Poproś klienta, aby opisał jedno konkretne zdarzenie, które ma zostać obsłużone przez przyszłe rozwiązanie. Niech wskaże, co uruchamia proces, jakie informacje są dostępne, jaki rezultat powinien powstać i kto z niego skorzysta. Następnie przejdźcie przez sytuację, w której wszystko działa poprawnie, oraz taką, w której brakuje danych albo pojawia się nietypowy przypadek. Ta druga rozmowa bywa znacznie cenniejsza. Na pokazach technologicznych dokumenty są czytelne, pytania logiczne, a użytkownicy uprzejmi. W rzeczywistości ktoś wpisze w formularzu "pilne!!!", dołączy niewłaściwy załącznik i będzie oczekiwał odpowiedzi przed końcem zdania. System musi funkcjonować również w świecie, w którym ludzie zachowują się jak ludzie.

Warto też ustalić, kto naprawdę będzie korzystał z rezultatu. Osoba zamawiająca rozwiązanie nie zawsze jest jego przyszłym użytkownikiem. Dyrektor może oczekiwać raportu przygotowywanego jednym kliknięciem, podczas gdy analitycy wiedzą, że połowa danych wymaga wcześniejszego uzgodnienia. Właściciel firmy może chcieć automatyzacji obsługi klientów, ale pracownicy wiedzą, które pytania wymagają indywidualnej decyzji. Pominięcie użytkowników sprawia, że projekt odpowiada na wyobrażenie o procesie, a nie na rzeczywisty proces. Nie trzeba zapraszać całej organizacji na warsztaty trwające trzy dni. Czasem wystarczy rozmowa z dwiema osobami, które codziennie wykonują daną pracę. Ich wiedza może zaoszczędzić więcej pieniędzy niż kolejny miesiąc dopracowywania efektownego interfejsu.

Kolejną pułapką jest utożsamianie oczekiwanego rezultatu z oczekiwaną korzyścią. Klient mówi, że chce skrócić przygotowanie dokumentu z dwóch godzin do dziesięciu minut. Wykonawca może zaproponować automatyczne wygenerowanie pierwszej wersji w pięć minut. Tylko czy dokument rzeczywiście będzie gotowy do wykorzystania? Jeśli jego sprawdzenie i poprawienie zajmie kolejne dwie godziny, oszczędność istnieje głównie na slajdzie sprzedażowym. Dlatego należy rozmawiać o całym procesie, a nie wyłącznie o czasie działania narzędzia. Szybkość wygenerowania odpowiedzi nie jest tym samym co szybkość dostarczenia zaakceptowanego rezultatu. To rozróżnienie potrafi uratować zarówno budżet, jak i reputację wykonawcy.

Nie oznacza to jednak, że każdy projekt trzeba poprzedzić rozbudowanym badaniem. Zakres analizy powinien odpowiadać skali zamówienia. Przy niewielkim zleceniu wystarczy krótki opis celu, materiałów wejściowych, sposobu użycia AI i oczekiwanego wyniku. Przy większym przedsięwzięciu warto przeprowadzić ograniczony test na uzgodnionych przykładach. Taki test powinien odpowiadać na konkretne pytania, a nie tylko wywoływać zachwyt podczas demonstracji. Czy rozwiązanie radzi sobie z typowymi przypadkami? Jak zachowuje się przy brakujących informacjach? Jakie błędy wymagają szczególnej uwagi? Co będzie oceniane ręcznie? Wynik testu nie gwarantuje przyszłej bezbłędności, ale pozwala podejmować decyzje na podstawie obserwacji zamiast wiary w prezentację producenta.

Zdarza się również, że klient oczekuje rzeczy, których nie można rozsądnie połączyć. Chce pełnej automatyzacji, żadnego nadzoru, stuprocentowej poprawności, minimalnych kosztów i uruchomienia jeszcze przed końcem tygodnia. Każde z tych oczekiwań osobno może mieć sens jako kierunek pracy. Wszystkie razem tworzą życzenie, które powinno zostać skierowane raczej do złotej rybki niż do zespołu projektowego. Rolą wykonawcy jest pokazanie zależności między nimi. Większa automatyzacja może zwiększać znaczenie zabezpieczeń. Dokładniejsza weryfikacja wymaga czasu. Obsługa nietypowych przypadków komplikuje rozwiązanie. Klient nie musi otrzymywać wykładu o architekturze systemów. Powinien jednak rozumieć, z czego rezygnuje, wybierając konkretny wariant.

Ważną częścią rozpoznania potrzeb jest również ustalenie, czego projekt nie obejmuje. Brzmi mało atrakcyjnie, bo ograniczenia trudno sprzedać jako rewolucję. Tymczasem właśnie one pomagają uniknąć późniejszych sporów. Jeżeli zlecenie dotyczy przygotowywania propozycji odpowiedzi na podstawie wskazanej dokumentacji, nie powinno automatycznie oznaczać samodzielnego rozstrzygania reklamacji. Jeżeli system ma analizować określony rodzaj plików, obsługa wszystkich możliwych formatów nie pojawia się magicznie w cenie. Warto zapisać takie wyłączenia językiem zrozumiałym dla klienta. Zdanie "rozwiązanie nie podejmuje decyzji skutkujących zmianą zobowiązań wobec użytkowników" mówi znacznie więcej niż ogólne "funkcjonalności poza zakresem nie są objęte wdrożeniem".

Odrębną sprawą jest ustalenie kryterium sukcesu. Jeśli klient mówi "ma działać dobrze", trzeba dopytać, co oznacza "dobrze" w jego przypadku. Dla narzędzia wspomagającego tworzenie opisów produktów może to być zgodność z dostarczonymi informacjami, właściwy format i możliwość łatwej redakcji. Dla systemu wyszukującego fragmenty dokumentacji ważne będzie odnajdywanie właściwych źródeł i wskazywanie ich użytkownikowi. Dla rozwiązania wspierającego analizę danych istotne mogą być poprawność obliczeń, przejrzystość założeń i możliwość odtworzenia wyniku. Nie wszystkie cechy da się ocenić jedną liczbą. Czasem potrzebna jest ocena ekspercka, czasem zestaw przypadków testowych, a czasem kombinacja kilku sposobów kontroli. Najgorszym kryterium pozostaje "poznam, kiedy zobaczę", szczególnie gdy klient zamierza zobaczyć dopiero gotowy produkt.

Przy uzgadnianiu oczekiwań pomocne jest zadanie pytania o konsekwencje błędu. Jeżeli narzędzie zaproponuje mniej udany tytuł wiadomości, problem będzie niewielki. Jeśli błędnie przypisze kwotę do faktury, wskaże niewłaściwy termin albo stworzy nieprawdziwe twierdzenie wykorzystane w oficjalnym dokumencie, skutki mogą być znacznie poważniejsze. To właśnie konsekwencje pomyłki powinny wpływać na sposób projektowania kontroli. Klient, który rozumie tę zależność, łatwiej zaakceptuje konieczność sprawdzania określonych rezultatów. Nie dlatego, że wykonawca próbuje zabezpieczyć się przed wszystkim, ale dlatego, że obie strony świadomie decydują, jakie ryzyko jest dopuszczalne.

Pod koniec rozmowy warto sprawdzić, czy uzgodnienia rzeczywiście oznaczają to samo dla obu stron. Można powiedzieć: "Rozumiem, że naszym zadaniem jest przygotowanie narzędzia proponującego odpowiedzi na podstawie zatwierdzonych materiałów. Pracownik będzie je sprawdzał przed wysłaniem. Automatyczna wysyłka i samodzielne podejmowanie decyzji nie wchodzą w zakres tego etapu. Czy tak rozumiesz zamówienie?". To nie jest biurokratyczna formułka. To próba ustalenia wspólnej wersji rzeczywistości, zanim pojawią się faktury, terminy i emocje. Jeśli klient odpowie "tak, ale myślałem, że będzie też samo wysyłać", właśnie udało się wykryć rozbieżność w najtańszym możliwym momencie.

Takie ustalenia dobrze potwierdzić na piśmie, nawet jeżeli współpraca jest niewielka. Krótkie podsumowanie może zawierać opis rezultatu, rolę AI, materiały wejściowe, zakres automatyzacji, sposób akceptacji i istotne wyłączenia. Nie zastępuje to wszystkich potrzebnych postanowień umownych, ale tworzy wspólny punkt odniesienia. Co szczególnie ważne, nie należy ukrywać niepewności. Jeżeli pewna funkcja wymaga sprawdzenia, zapisz, że jej wykonalność zostanie oceniona w uzgodnionym teście. Obietnica złożona przed takim sprawdzeniem nie staje się bardziej wiarygodna tylko dlatego, że została wypowiedziana spokojnym głosem i zilustrowana animacją.

Największą zaletą dobrze przeprowadzonej rozmowy nie jest stworzenie idealnej dokumentacji. Jest nią odkrycie, czy klient i wykonawca rzeczywiście zamierzają zrealizować ten sam projekt. Czasem okaże się, że AI jest właściwym rozwiązaniem. Czasem, że potrzebna jest prostsza automatyzacja. A czasem, że przed wdrożeniem trzeba uporządkować proces, który dotychczas działał wyłącznie dzięki pamięci jednej wyjątkowo cierpliwej osoby. Każdy z tych wyników jest wartościowy, ponieważ pozwala uniknąć inwestowania w rozwiązanie niewłaściwego problemu.

Klient nie musi przychodzić na spotkanie z gotową specyfikacją techniczną. Powinien natomiast wyjść z rozmowy ze świadomością, co zamawia, czego może oczekiwać i jakie decyzje pozostają po jego stronie. Wykonawca nie musi obiecywać technologicznych cudów, żeby pokazać profesjonalizm. Wystarczy, że potrafi zamienić ogólne "chcemy AI" w zestaw zrozumiałych ustaleń. To mniej widowiskowe niż pokaz robota, który układa kostkę Rubika podczas konferencji, ale zdecydowanie bardziej przydatne przy odbiorze zlecenia. Zwłaszcza kiedy nadchodzi moment, w którym ktoś pyta: "Dlaczego to nie robi jeszcze tamtej rzeczy?". Dobrze opisany zakres daje wtedy znacznie lepszą odpowiedź niż nerwowe przeszukiwanie historii spotkań.