Najgorsza instrukcja dla agenta brzmi: „bądź pomocny i zrób to dobrze”. Nie mówi, co ma powstać, z czego korzystać, kiedy przestać i kiedy zawołać człowieka. Agent może zgadnąć, ale nie masz sposobu ocenić wyniku. Zamiast procedury powstaje kolejna odpowiedź, która wygląda rozsądnie.
SOP, czyli standardowa procedura operacyjna, powinno opisywać pracę tak, żeby dało się ją odebrać. Nie musi mieć trzydziestu stron. Dla prostego zadania wystarczy jedna strona z celu, źródeł, dozwolonych działań, formatu, błędów i akceptacji. Poniżej masz strukturę, którą możesz przepisać na własny proces.
Cel z rezultatem i ograniczeniem
Zacznij od oczekiwanego rezultatu: „Przygotuj projekt odpowiedzi na pytanie klienta na podstawie wskazanego rejestru”. Dodaj, czego agent nie robi: „Nie wysyła wiadomości, nie zmienia terminów, nie korzysta z innych źródeł”. Cel ma być sprawdzalny, nie inspirujący.
Wskaż odbiorcę i format. Dla pracownika będzie to tabela, dla klienta krótka wiadomość, dla systemu JSON. Format nie jest kosmetyką. Decyduje, czy wynik można użyć bez dodatkowej pracy.
Zapisz warunek zakończenia: gotowy dokument w folderze roboczym, konkretna liczba pozycji, brak otwartych pytań lub eskalacja. „Zrób ile się da” nie jest warunkiem.
Źródło prawdy i dostęp
Wskaż dokumenty, pola i statusy, które obowiązują. Jeżeli terminy są w rejestrze zamówień, nie może brać ich z maila. Jeżeli oferta jest zatwierdzona, robocza wersja nie może jej zastąpić. Źródło powinno być jednoznaczne.
Rozdziel odczyt, zapis i wysyłkę. Instrukcja „może przygotować szkic” nie oznacza „może publikować”. Wypisz dozwolone operacje i zakres: konkretny folder, projekt, typ rekordu, okres. Brak zakresu jest zaproszeniem do przeszukiwania wszystkiego.
Dodaj zasadę braku: jeśli źródła nie ma, agent nie zgaduje. Ma oznaczyć brak i przekazać pytanie. To jedna z najprostszych poprawek jakości.
Sekwencja pracy, nie wielka ściana tekstu
Rozpisz kroki w kolejności: pobierz zadanie, sprawdź źródło, wykonaj analizę, przygotuj wynik, sprawdź zasady, przekaż do akceptacji. Każdy krok powinien mieć wejście i wynik. Agent nie musi zgadywać momentu kontroli.
Unikaj instrukcji mieszających wszystko w jednym akapicie. Krótkie punkty ułatwiają testowanie i wskazanie miejsca błędu. Jeżeli proces ma decyzję warunkową, zapisz ją wprost: „Jeżeli brakuje terminu, nie proponuj daty. Oznacz pole jako puste”.
Nie komplikuj procesu na zapas. Anthropic zaleca zaczynanie od najprostszej konstrukcji i zwiększanie złożoności dopiero przy mierzalnym efekcie. Trzy dobre kroki są lepsze niż dwanaście, których nikt nie kontroluje.
Format odpowiedzi i przykład
Dodaj jeden poprawny przykład zamiast kolejnego opisu jakości. Pokaż pola, długość i sposób cytowania. Przykład powinien zawierać trudniejszy przypadek, nie tylko idealny. Dzięki temu widać, jak postępować przy braku danych.
Jeżeli format jest techniczny, określ typy i wymagane pola. JSON bez schema jest listą życzeń. Jeżeli tekst jest dla klienta, podaj ton i ograniczenia. Nie każdy wynik ma być podsumowaniem.
Przygotuj też kontrprzykład: czego agent nie powinien zrobić. To nie jest negatywna motywacja, tylko jasna granica. Czasem jeden zły przykład uczy więcej niż akapit zakazów.
Błędy i wyjątki
Wypisz oczekiwane problemy: brak źródła, sprzeczne wersje, zły format, brak uprawnień, błąd narzędzia, nieznany wynik operacji. Dla każdego wskaż zachowanie: pytanie, ponowienie, zatrzymanie albo eskalacja. Nie używaj ogólnego „spróbuj ponownie”.
Rozróżnij odmowę dostępu od nieznanego wyniku. W pierwszym przypadku nie próbuj obejść. W drugim sprawdź stan przed kolejną próbą, żeby nie stworzyć duplikatu. To ważne przy publikacji i wysyłce.
Dodaj przypadek niezaufanej treści. Dokument może zawierać instrukcje dla modelu, ale nie zmienia zasad SOP. Agent ma go potraktować jako dane i zgłosić konflikt przy próbie zmiany uprawnień.
Akceptacja, którą widać
Zapisz, co człowiek widzi przed decyzją: treść, źródło, adresat, skutek, zmiana i ewentualny koszt. Nie wystarczy komunikat „agent chce wykonać akcję”. Akceptacja ma być konkretna i możliwa do odrzucenia.
Rozdziel przygotowanie od zatwierdzenia. Człowiek może edytować wynik, ale wtedy proces powinien zapisać, co zmienił. Jeżeli wymagane jest drugie zatwierdzenie po edycji, opisz je. Nie zgaduj, że drobna zmiana jest drobna.
Dla operacji odwracalnych i powtarzalnych możesz później zmniejszyć kontrolę w limitach. Dla wysokiego ryzyka zostaw akceptację każdej operacji. Skutek decyduje, nie długość pracy agenta.
Logi i odpowiedzialność
Zapisuj zadanie, źródła, wersję instrukcji, wybrane operacje, wynik i akceptację. Log ma odtworzyć zdarzenie, nie gromadzić pełne dane. Dodaj identyfikator wersji modelu i integracji, jeżeli wpływa na rezultat.
Wskaż właściciela procesu i osobę, która zatrzymuje pracę. Agent nie jest właścicielem odpowiedzialności. Jeżeli coś pójdzie nie tak, wszyscy wiedzą, kto decyduje o następnym kroku.
Przyda się rejestr decyzji zgodny z Aeneia Signal o rejestrze decyzji projektowych. Zmiana SOP powinna mieć powód i datę, nie tylko nową nazwę pliku „final_prompt_v7”.
Zatrzymanie i wycofanie
Zapisz warunki stop: niebezpieczna instrukcja, przekroczenie zakresu, brak źródła, powtarzający błąd, koszt powyżej limitu, żądanie użytkownika. Zatrzymanie ma oznaczać odwołanie uprawnień, nie tylko wiadomość „przestań”.
Opisz, co dzieje się z wynikiem częściowym. Czy zostaje w folderze roboczym? Czy trafia do właściciela? Czy cofasz operację? Nie zostawiaj półproduktu, który ktoś przypadkowo przyjmie za gotowy.
Przećwicz zatrzymanie. Jeżeli przycisk działa tylko w prezentacji, nie masz przycisku stop.
Test przed uruchomieniem
Przygotuj przypadek poprawny, brak źródła, sprzeczne źródła, brak uprawnień, błąd narzędzia i instrukcję w dokumencie. Zapisz oczekiwane zachowanie dla każdego. Sprawdź format i skutek, nie tylko tekst odpowiedzi.
Po każdej zmianie SOP powtórz przypadki krytyczne. Nie zmieniaj procedury na produkcji bez wersji i odbioru. Jeżeli wynik się pogarsza, wróć do poprzedniej wersji.
Przydatny jest odpowiedzialny workflow agentów AI. Przy przeglądzie uprawnień i procesu Aeneia Audit pomaga znaleźć luki przed uruchomieniem.
Jednostronicowa wersja SOP
Na górze wpisz cel i rezultat. Niżej źródło i dozwolone działania. Dodaj format, przykład, błędy, akceptację i stop. Zostaw właściciela i datę. To cała podstawa.
Przykład SOP dla odpowiedzi na pytanie klienta
Cel: przygotować projekt odpowiedzi na pytanie o status zamówienia z rejestru. Źródło: tabela zamówień, pole status i data, bez wiadomości prywatnych. Dozwolone: odczyt jednego rekordu i zapis nowego szkicu w folderze roboczym. Zabronione: zmiana statusu, wysyłka, kontakt z klientem.
Kroki: znajdź rekord, sprawdź datę aktualizacji, wypisz status i źródło, przygotuj dwie wersje tekstu. Jeżeli brakuje rekordu, napisz „nie znaleziono” i nie zgaduj statusu. Jeżeli statusy są sprzeczne, pokaż konflikt i przekaż właścicielowi.
Akceptacja: człowiek widzi rekord, odpowiedź i źródło. Dopiero po zatwierdzeniu może otworzyć wiadomość. Log zawiera identyfikator zadania, wersję SOP i decyzję, nie pełne dane klienta. Stop: instrukcja zewnętrzna, brak uprawnień, koszt lub błąd narzędzia.
Dlaczego przykład działa lepiej niż dodatkowe zasady
Ta wersja jest krótka, ale odpowiada na najczęstsze pytania: skąd dane, co wolno, jaki wynik, kiedy stop i kto zatwierdza. Nie trzeba dopisywać „działaj profesjonalnie”. Każdy punkt można sprawdzić w teście. Jeżeli agent robi coś innego, wiesz, która linia została złamana.
Możesz zmienić tylko źródło i rezultat, żeby użyć tej samej struktury dla faktur, raportów albo wersji dokumentów. Nie kopiuj jednak całego SOP bez oceny ryzyka. Faktura ma inne skutki niż podsumowanie, a publikacja inne niż odpowiedź.
Zachowaj jeden przykład dobry i jeden zły. Przy złym pokaż, że odpowiedź „wszystko gotowe” jest niedozwolona bez statusu. To pomaga zespołowi rozumieć ograniczenie bez czytania teorii.
Właściciel procedury odpowiada za zmianę
W SOP wpisz jedną osobę lub rolę, która zatwierdza nową wersję. Autor automatyzacji nie powinien sam decydować o rozszerzeniu uprawnień tylko dlatego, że umie je włączyć. Właściciel procesu rozumie skutek i akceptuje ryzyko, technik opisuje możliwości oraz testy.
Przy zmianie źródła, odbiorcy albo akcji przygotuj krótką kartę: co było, co będzie, jakie testy trzeba powtórzyć i kiedy można wrócić. Drobna korekta przykładu nie wymaga pełnego przeglądu bezpieczeństwa, ale dodanie wysyłki już tak. Zakres odbioru zależy od skutku zmiany.
Jeżeli właściciel odchodzi, procedura przechodzi na nową osobę przed rozszerzeniem pracy. Osierocony SOP z aktywnym tokenem to automatyzacja bez odpowiedzialnego człowieka. Rejestr powinien przypominać o przeglądzie i braku właściciela.
Instrukcja dla agenta i dla człowieka mają wspólne źródło
Nie utrzymuj jednej wersji w prompcie, drugiej w dokumencie dla zespołu i trzeciej w mailu. Wybierz jeden obowiązujący SOP, z którego system pobiera aktualne zasady. Ludzie powinni widzieć ten sam zakres działań, kryteria odbioru i warunki stop.
Jeżeli format techniczny wymaga osobnej wersji, dodaj automatyczny test zgodności najważniejszych pól: źródło, dozwolone akcje, format i ograniczenia. Różnica ma zatrzymać wdrożenie. Długi komentarz o tym, że „dokumentacja jest aktualizowana na bieżąco”, nie zastępuje kontroli.
Podczas szkolenia pokaż rzeczywisty SOP i wykonaj jeden przypadek. Zespół powinien umieć wskazać, gdzie szukać aktualnej wersji i jak zgłosić błąd. Procedura, której nikt nie potrafi znaleźć, nie istnieje operacyjnie.
Odbiór przypadku brzegowego w pięciu pytaniach
Po każdym teście zapytaj: czy agent użył właściwego źródła, czy wykonał tylko dozwolone akcje, czy wynik ma wymagany format, czy człowiek dostał potrzebny kontekst i czy da się odtworzyć decyzję. Jedno „nie” wskazuje konkretny punkt poprawki.
Dla przypadku bez źródła oczekiwanym wynikiem nie jest dowolna grzeczna odpowiedź. Agent powinien zatrzymać się i przekazać brak. Dla błędu narzędzia sprawdź, czy ponowienie nie tworzy duplikatu. Dla instrukcji zewnętrznej oceń rzeczywiste operacje, nie tylko deklarację odmowy; szczegółowy scenariusz znajdziesz w teście prompt injection w dokumentach.
Zapisz przykład dobry i zły obok SOP. Krótki komentarz „tutaj brak źródła, więc nie wysyłamy” uczy więcej niż kolejny ogólny zakaz. Jeżeli nowa wersja przechodzi przypadki poprawne, ale nie brzegowe, nadal jest wersją roboczą.
Jak prowadzić wersje instrukcji
Zapisz numer, datę, właściciela i powód zmiany. Nie edytuj produkcyjnego SOP w locie. Najpierw test na kopii i mały zakres. Jeżeli nowa wersja działa gorzej, przywróć poprzednią i zanotuj przyczynę.
Po każdej zmianie integracji sprawdź, czy procedura nadal odpowiada możliwościom. Nowa funkcja nie musi być włączona do procesu. Zasada minimalizmu ogranicza ryzyko i liczbę testów potrzebnych do bezpiecznej pracy.
Przejrzyj SOP z osobą, która wykonuje zadanie ręcznie. Może wskazać brakujący wyjątek i zły format. Procedura ma odzwierciedlać pracę, a nie idealną wizję projektanta. Dobry SOP żyje w praktyce.
Dobry SOP nie jest długi. Jest jednoznaczny. Agent wie, co zrobić, człowiek wie, co odebrać, a każdy błąd ma przewidzianą ścieżkę. „Bądź pomocny” może zostać jako życzenie na wstępie, ale nigdy jako cała procedura.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
