Do pierwszej sensownej rozmowy o wdrożeniu nie potrzebujesz idealnych procedur, kompletnego diagramu ani zakupionych z góry narzędzi.
Potrzebujesz czegoś prostszego:
- jednego rzeczywistego procesu;
- kilku przykładów wejścia i oczekiwanego wyniku;
- listy wyjątków;
- osoby, która zna codzienną pracę;
- osoby, która może podjąć decyzję;
- informacji o używanych systemach.
To wystarczy, żeby ocenić zakres i zaprojektować pierwszy test. Dostępy, sekrety i dane ludzi powinny pojawiać się dopiero wtedy, gdy wiadomo, po co są potrzebne i jak ograniczyć ich zakres.
Minimum na pierwszą rozmowę
Przygotuj odpowiedzi na sześć pytań:
- Co uruchamia proces?
- Jaki wynik powinien powstać?
- Kto wykonuje pracę dzisiaj?
- Jakie systemy bierze udział w procesie?
- Co najczęściej idzie inaczej niż w typowym przypadku?
- Kto decyduje, gdy reguły są niejasne?
Nie muszą być zapisane językiem technicznym. Najlepszym materiałem jest często przejście przez jeden prawdziwy przypadek od początku do końca.
Pokaż proces takim, jaki jest
Nie przygotowuj „wersji idealnej” tylko po to, by wyglądała profesjonalnie. Automatyzacja ma działać z rzeczywistym sposobem pracy albo pomóc go świadomie zmienić.
Zbierz:
- typowy przypadek;
- przypadek z brakującą informacją;
- przypadek pilny;
- przypadek odrzucony;
- przykład poprawki;
- sytuację, w której potrzebna była decyzja przełożonego.
Przy każdym zapisz:
- skąd przyszło wejście;
- co zrobiła pierwsza osoba;
- jakie informacje sprawdziła;
- co wpisała do systemu;
- komu przekazała wynik;
- po czym wiedziała, że sprawa jest zakończona.
To ujawnia reguły i wyjątki bez tworzenia wielkiej dokumentacji procesowej.
Przygotuj paczkę testową bez danych ludzi
W pierwszych testach zwykle nie są potrzebne prawdziwe dane klientów. Można przygotować bezpieczne próbki zachowujące strukturę materiału.
Paczka testowa może zawierać:
- przykładowy formularz z fikcyjnymi danymi;
- zanonimizowaną wiadomość;
- dokument z usuniętymi nazwami, adresami i identyfikatorami;
- oczekiwany rekord w CRM;
- zatwierdzony wzór odpowiedzi;
- przykład, który system powinien odrzucić.
Nie wystarczy usunąć samego imienia, jeśli pozostałe informacje pozwalają rozpoznać osobę. Jeżeli proces dotyczy danych wrażliwych albo regulowanej branży, wymagania trzeba ustalić osobno dla konkretnego przypadku. Ta checklista nie zastępuje analizy prawnej ani bezpieczeństwa.
Zrób listę systemów i właścicieli kont
Nie potrzebujesz jeszcze wszystkich danych logowania. Potrzebujesz mapy zależności.
| System | Do czego służy w procesie | Właściciel konta | Potrzebny odczyt czy zapis? | Jest środowisko testowe? |
|---|---|---|---|---|
Sprawdź także:
- czy system ma API;
- kto może utworzyć konto techniczne;
- czy istnieją limity lub dodatkowe opłaty za integrację;
- jak odebrać dostęp po zakończeniu prac;
- gdzie jest źródło prawdy, gdy dwa systemy zawierają inne dane.
Nazwij wyjątki, których automat nie może zgadywać
Typowy przypadek jest zwykle łatwy. O jakości wdrożenia decydują sytuacje, w których brakuje informacji albo reguły są sprzeczne.
Przygotuj listę:
- brak wymaganej informacji;
- dwa rekordy dotyczące tej samej sprawy;
- nieznany format dokumentu;
- klient prosi o odstępstwo;
- system zewnętrzny nie odpowiada;
- wynik AI jest niejednoznaczny;
- działanie mogłoby utworzyć zobowiązanie;
- sprawa dotyczy danych, których system nie powinien przetwarzać.
Do każdego wyjątku przypisz decyzję: zatrzymaj, poproś o dane, przekaż człowiekowi, ponów albo odrzuć.
OpenAI wskazuje, że instrukcje agenta powinny definiować jasne działania i uwzględniać przypadki brzegowe. NIST podkreśla z kolei potrzebę określenia kontekstu użycia, ryzyk i procesów nadzoru człowieka.
Nadawaj uprawnienia etapami
Najbezpieczniejsza kolejność to:
- poznanie procesu bez dostępu do systemu;
- materiały testowe;
- minimalny odczyt potrzebny do weryfikacji integracji;
- zapis w środowisku testowym;
- ograniczony zapis produkcyjny dopiero po odbiorze i zgodzie.
Nie przekazuj „na wszelki wypadek” konta administratora, pełnego eksportu klientów ani prywatnego klucza w zwykłej wiadomości. Sposób przekazania sekretów i zakres uprawnień powinien być częścią uzgodnionego planu technicznego.
Wyznacz dwie osoby, nie jedną
W małej firmie jedna osoba może pełnić obie role, ale warto je rozdzielić na poziomie odpowiedzialności.
Właściciel decyzji
Rozstrzyga:
- zakres;
- wyjątki;
- priorytety;
- akceptowalny poziom ryzyka;
- zgodę na uruchomienie.
Użytkownik procesu
Sprawdza:
- czy odwzorowano rzeczywistą pracę;
- czy wynik jest użyteczny;
- czy nie pominięto częstych wyjątków;
- czy ręczny fallback jest wykonalny;
- czy instrukcja operacyjna jest zrozumiała.
Brak którejkolwiek z tych perspektyw wydłuża odbiór. Osoba decyzyjna nie zawsze zna codzienne szczegóły, a użytkownik nie zawsze może zatwierdzić zmianę zakresu.
Ustal dowód sukcesu przed budową
„Ma działać szybciej” jest zbyt nieprecyzyjne. Wybierz obserwowalny wynik.
Na przykład:
- poprawny rekord trafia do właściwego systemu;
- brak danych zatrzymuje proces i tworzy zadanie dla człowieka;
- ponowienie nie tworzy duplikatu;
- użytkownik widzi status oraz przyczynę błędu;
- wiadomość zewnętrzna nie wychodzi bez zatwierdzenia;
- każda akcja ma zapisany ślad wykonania.
Jeśli projekt używa AI, dołóż przykłady odpowiedzi poprawnej, błędnej i wymagającej przekazania człowiekowi. Nie oceniaj wyłącznie tego, czy tekst „brzmi dobrze”.
Checklista: konieczne, pomocne, później
Konieczne na start
- [ ] jeden rzeczywisty proces;
- [ ] kilka przykładów;
- [ ] oczekiwany wynik;
- [ ] lista systemów;
- [ ] najczęstsze wyjątki;
- [ ] osoba do decyzji;
- [ ] osoba do testów;
- [ ] informacja o działaniach, których system nie może wykonać sam.
Pomocne przed prototypem
- [ ] zanonimizowana paczka testowa;
- [ ] lista właścicieli kont;
- [ ] źródło prawdy dla danych;
- [ ] kryteria odbioru;
- [ ] sposób ręcznego dokończenia sprawy;
- [ ] miejsce zgłaszania błędów.
Potrzebne później
- [ ] minimalne konta techniczne;
- [ ] uprawnienia do środowiska testowego;
- [ ] monitoring i powiadomienia;
- [ ] instrukcja operacyjna;
- [ ] plan odebrania dostępów;
- [ ] decyzja o uruchomieniu produkcyjnym.
Czego nie trzeba robić przed discovery
Nie musisz:
- kupować narzędzia przed wyborem architektury;
- tworzyć kompletnego podręcznika procesu;
- porządkować wszystkich danych w firmie;
- automatyzować całego działu;
- udostępniać produkcji przed testem;
- znać nazw technologii potrzebnych do rozwiązania.
Pierwszy etap ma ustalić, co jest problemem, gdzie znajduje się wartość i jaki najwęższy test da wiarygodną odpowiedź.
FAQ: najczęstsze pytania
Czy proces musi być wcześniej uporządkowany?
Nie idealnie. Musi być możliwy do pokazania na prawdziwych przykładach. Jeśli każda osoba wykonuje go inaczej, pierwszym wynikiem może być uzgodnienie wspólnej ścieżki, a nie od razu automatyzacja.
Czy trzeba dać wykonawcy dostęp do wszystkich systemów?
Nie. Dostęp powinien wynikać z zakresu i być minimalny na danym etapie. Najpierw można pracować na opisach oraz danych testowych.
Kto powinien testować rozwiązanie?
Osoba znająca codzienną pracę oraz osoba mogąca zatwierdzić reguły i wyjątki. To mogą być dwie role jednej osoby, ale odpowiedzialności muszą być jawne.
Jakie dane przygotować dla asystenta AI?
Zatwierdzone instrukcje, przykłady poprawnych odpowiedzi, źródła wiedzy, przypadki brzegowe oraz reguły przekazania sprawy człowiekowi. Nie zaczynaj od wrzucenia wszystkich firmowych plików do jednego miejsca.
Jaki jest najlepszy pierwszy krok?
Wybierz jeden prawdziwy przypadek i przejdź go od wejścia do wyniku. Zwykle już wtedy widać brakujące decyzje, źródła danych i ryzyka.
Jeśli przygotujesz jedną paczkę testową oraz listę wyjątków, rozmowa o wdrożeniu będzie znacznie konkretniejsza. Nie trzeba wcześniej kupować narzędzi ani przekazywać dostępów w ciemno.
Jeśli nie masz jeszcze wybranego procesu, zobacz najpierw od czego zacząć automatyzację w firmie oraz listę pięciu procesów, które warto przeanalizować. Gdy proces jest już wybrany, ta checklista przygotuje materiał do rozmowy o automatyzacji albo asystencie AI.
Źródła
- OpenAI: A practical guide to building agents: instrukcje, jasne działania, edge cases, guardrails i narzędzia; sprawdzone 21.08.2026.
- NIST: AI Risk Management Framework Core: kontekst użycia, zarządzanie ryzykiem i procesy nadzoru człowieka; sprawdzone 21.08.2026.