Prompt, który działa raz, nie jest firmowym skillem

W firmie najłatwiej pomylić dobry prompt z gotowym sposobem pracy. Ktoś wkleja instrukcję do ChatGPT, dostaje sensowny wynik, poprawia dwa zdania i wrzuca prompt na Teamsy z dopiskiem: "używajcie do raportów".

Przez pierwsze dwa dni wygląda to dobrze. Jedna osoba dostaje lepszy szkic maila. Druga szybciej robi podsumowanie spotkania. Trzecia wrzuca do AI materiał z inną strukturą, dostaje pewnie brzmiący wynik i nikt już nie wie, czy to nadal ten sam proces, czy tylko ładniej opisana improwizacja.

Przy takim pomyśle trzeba rozstrzygnąć prostą rzecz: na jakim poziomie ten prompt ma zostać. Prywatna pomoc jednej osoby? Wspólna notatka dla zespołu? Udokumentowany skill? A może narzędzie z formularzem, blokadami i zapisem decyzji? Skill rozumiem tu praktycznie: instrukcję do jednego zadania, z opisanym wejściem, zakazanymi danymi, oczekiwanym wynikiem, testami, sprawdzeniem wyniku i warunkiem zatrzymania. Bez tego prompt może dalej pomagać, ale nie powinien udawać firmowego standardu.

Jeden przykład testowy pokazuje różnicę

Weźmy prompt do klasyfikacji maili ze wspólnej skrzynki. W prostym teście pojawia się taki mail: "Proszę o duplikat faktury za czerwiec. Przy okazji zgłaszam, że ostatnia usługa nie działała zgodnie z ustaleniami i chcę to wyjaśnić przed kolejnym zamówieniem".

Prywatny prompt może zwrócić kategorię "faktura", bo widzi najbardziej konkretną prośbę. Wynik wygląda sensownie, ale gubi drugą część maila: reklamację albo ryzyko utraty klienta. Skutek biznesowy jest prosty. Księgowość wysyła duplikat faktury, a nikt nie przejmuje tematu jakości usługi. Klient czeka, handlowiec nie dostaje sygnału, a firma myśli, że AI pomogła obsłużyć wiadomość.

W firmowym skillu decyzja STOP powinna być zapisana z góry. Reguła może brzmieć: jeżeli mail pasuje do dwóch kategorii albo zawiera reklamację, instrukcja ma zwrócić STOP zamiast zwykłej klasyfikacji. Wtedy sprawa trafia do osoby wyznaczonej do sprawdzania takich wyjątków albo do właściciela procesu. Minimalny ślad w arkuszu wygląda tak:

Taki przykład robi więcej niż deklaracja "prompt działa". Pokazuje błąd, osobę zatwierdzającą, próg jakości i ślad decyzji. Jeżeli nie da się rozpisać jednego takiego przebiegu, prompt jest jeszcze za miękki na firmowy standard.

Jeden dobry wynik to jeszcze anegdota

Prompt zaczyna się od zdania. Skill zaczyna się od zachowania, które da się sprawdzić.

Różnica wychodzi przy pierwszym słabym wejściu. Jeśli prompt ma streścić raport, co robi przy brakującej dacie? Jeśli ma klasyfikować maile od klientów, co robi z wiadomością, która pasuje do dwóch kategorii? Jeśli ma zrobić notatkę decyzyjną, co robi, gdy w materiale są dane, których nie wolno wkleić do AI? W każdym z tych miejsc skill powinien zwrócić wynik, decyzję STOP albo skierować sprawę do człowieka.

OpenAI w dokumentacji evali, czyli testów zachowania modelu, pokazuje prosty przykład klasyfikacji zgłoszeń IT. Ważniejszy od samego narzędzia jest mechanizm: opisać zadanie, uruchomić je na wejściach testowych i porównać wynik modelu z oczekiwanym zachowaniem. Jeden sensowny wynik nie daje powtarzalności. Daje ją dopiero zestaw przypadków.

W małej firmie nie trzeba od razu stawiać platformy do takich testów. Na start wystarczy kartka, arkusz albo plik z pięcioma przypadkami: poprawnym, z brakującymi danymi, z danymi zakazanymi, niejednoznacznym i spoza zakresu. Jeżeli skill obsługuje kilka typów dokumentów, kilka ról albo akcje w systemach, zestaw testów musi rosnąć razem z ryzykiem. Jeśli prompt nie przechodzi przez taki pierwszy zestaw, nie jest jeszcze skillem dla zespołu.

Co zmienia się, gdy prompt dostaje zespół

Prywatny prompt działa w głowie autora. Autor pamięta, co miał na myśli, jakie dane można wkleić i kiedy wynik jest podejrzany. Zespół tego kontekstu nie ma.

Kiedy prompt trafia do kilku osób, dochodzi pięć nowych źródeł błędu: inne wejścia, inny język użytkownika, inne rozumienie zadania, presja czasu i brak wspólnej definicji dobrego wyniku. Wtedy nie wystarczy "u mnie działa". Trzeba opisać, co znaczy "działa".

Skill powinien odpowiadać na pytania, które zwykle siedzą w głowie jednej osoby:

Ta tabela przenosi zasady z głowy autora promptu do miejsca, które widzi zespół. Jeśli ktoś chce wkleić cały wątek mailowy, sprawdza pole "Wejście". Jeśli wynik ma niską pewność albo dotyczy faktury, trafia do wskazanej osoby. Sama instrukcja w ChatGPT tego nie wymusza. Człowiek nadal pilnuje zasad. Dopiero formularz, aplikacja pośrednia albo narzędzie może zablokować niedozwolone dane przed wysłaniem do modelu albo zatrzymać wynik przed użyciem.

Minimalny kontrakt skilla

Kontrakt skilla to krótki opis zachowania, które zespół ma powtarzać: co wolno wkleić, co ma wyjść, kiedy ma paść decyzja STOP i kto sprawdza wynik.

Najmniejszy sensowny kontrakt ma siedem części: nazwę zadania, dozwolone dane, zakazane dane, oczekiwany wynik, warunek zatrzymania, testy po każdej zmianie i osobę odpowiedzialną za wersję.

Do tego dochodzi zmiana wersji. Ktoś może zaproponować poprawkę promptu, ale właściciel procesu zatwierdza nową wersję dopiero po przejściu testów i krótkiej informacji dla zespołu, co się zmieniło.

Wystarczy jeden wiersz historii zmian:

Bez tego "poprawiliśmy prompt" zostaje rozmową, nie kontrolowaną zmianą sposobu pracy.

To brzmi banalnie, dopóki firma nie ma pierwszego błędu. Prompt do streszczania spotkań zaczyna dopisywać decyzje, których nikt nie podjął. Prompt do ofert miesza dane z dwóch klientów. Prompt do statusów projektowych podaje pewny ton przy niepełnym materiale. Każdy z tych błędów wygląda jak problem modelu, ale często zaczyna się wcześniej: w zadaniu bez granic.

NIST AI Risk Management Framework pomaga patrzeć na ryzyko przez prostą zasadę: ryzyko oceniasz pod konkretne użycie, dane i konsekwencje błędu. W małej firmie nie musi to oznaczać programu nadzoru nad AI. Może zacząć się od karty dla jednego promptu: tu są dane, tu jest ryzyko, tu człowiek sprawdza wynik. Sama karta nie daje bezpieczeństwa. Daje dopiero warunki, które człowiek albo narzędzie może egzekwować.

Testy mają złapać nudne awarie

Najgorszy test promptu to ponowne uruchomienie go na tym samym przykładzie, który przed chwilą zadziałał.

OpenAI w przewodniku o ewaluacjach przypomina, że generatywna AI jest zmienna. Model może dawać różne odpowiedzi dla tego samego wejścia, a klasyczne podejście do testowania oprogramowania nie pokrywa całego problemu. Dla osoby, która ma używać takiego promptu w pracy zespołu, wniosek jest prosty: trzeba sprawdzić zachowanie na kilku typach wejścia, zamiast oceniać, czy ostatni wynik "brzmiał dobrze".

Minimalny zestaw testów dla firmowego skilla może wyglądać tak:

W praktyce to minimalny hamulec ręczny przed wysłaniem promptu do ludzi, którzy będą używać go w pośpiechu.

Jeśli skill ma kilka kroków albo narzędzia, testy muszą iść krok dalej. Dokumentacja OpenAI o ocenie przebiegów agentowych opisuje trace, czyli ślad przebiegu: wywołania modelu, użycie narzędzi, bramki zasad i przekazania zadania między częściami systemu. Jedna linia takiego śladu może wyglądać tak: wejście maila -> klasyfikacja modelu -> bramka zasad wykrywa reklamację -> człowiek zatwierdza przekierowanie -> log zapisuje wersję promptu i decyzję. Dla prostego promptu nie trzeba tego komplikować. Dla skilla, który wybiera narzędzie, tworzy draft, klasyfikuje ryzyko i prosi o zatwierdzenie, sam finalny tekst nie mówi już, gdzie powstał błąd.

Sprawdzenie nie jest korektą stylu

W wielu firmach sprawdzenie wyniku oznacza, że ktoś czyta odpowiedź AI i poprawia język. To za mało, jeśli wynik ma wejść do raportu, maila do klienta albo decyzji operacyjnej.

Zanim człowiek dostanie wynik AI do sprawdzenia, trzeba nazwać, co dokładnie ma ocenić: fakty, dane, zgodność z polityką, ton komunikacji albo decyzję, czy wynik może iść dalej. Bez tego AI pisze, człowiek poprawia język, a błąd merytoryczny zostaje w środku.

McKinsey w raporcie State of AI 2025 wskazuje, że organizacje osiągające lepsze wyniki z AI częściej mają zdefiniowane procesy określające, kiedy wynik modelu wymaga walidacji człowieka. Dla właściciela procesu wniosek jest prosty: zanim wynik AI trafi do klienta, raportu albo decyzji operacyjnej, trzeba ustalić, kto go sprawdza i co może go zatrzymać.

Dla firmowego skilla sprawdzenie wyniku można rozpisać prosto:

Najważniejsza decyzja w tej tabeli brzmi: "zablokuj". Skill musi mieć sytuacje, w których zwraca STOP zamiast pomagać dalej. Bez tego każda instrukcja prędzej czy później zacznie przepychać zadania, których nie powinna dotykać.

Kiedy nie robić z promptu skilla

Nie każdy prompt powinien zostać wspólną instrukcją.

Jeśli zadanie jest jednorazowe, zostaw prompt jako notatkę. Jeśli zadanie jest zbyt szerokie, zawęź je do jednego procesu. Jeśli nikt nie chce odpowiadać za aktualną wersję promptu i testy po zmianach, nie wysyłaj go zespołowi jako standardu. Jeśli nie da się ułożyć pięciu przypadków testowych, temat jest jeszcze za mglisty.

Najbardziej podejrzane są prompty, które obiecują obsłużyć "wszystkie raporty", "każdy mail od klienta" albo "dowolny dokument". Takie instrukcje wyglądają wygodnie, ale chowają kilka różnych zadań pod jedną nazwą. Potem firma nie wie, czy poprawić prompt, rozdzielić proces, dodać sprawdzenie wyniku, czy po prostu przestać używać tego rozwiązania.

Dobry pierwszy skill jest węższy. Na przykład: "klasyfikuj maile z jednego inboxa do czterech kategorii", "sprawdź, czy notatka po spotkaniu ma decyzję, właściciela i termin", "przerób surowy status projektu na format tygodniowego update'u". Jedno wejście. Jeden wynik. Jedna osoba odpowiedzialna za sprawdzenie.

Granica między poziomami jest dość prosta: prywatny prompt zostaje u autora, gdy pomaga w nieregularnym zadaniu. Wspólna notatka wystarcza, gdy kilka osób chce korzystać z tej samej instrukcji, ale wynik nie wpływa na klienta, pieniądze ani decyzję. Udokumentowany skill ma sens, gdy zadanie jest powtarzalne i wymaga granic danych, testów, osoby odpowiedzialnej za wersję oraz sprawdzenia. Narzędzie albo automatyczny proces jest potrzebny dopiero wtedy, gdy firma chce blokować wejścia, zapisywać ślad decyzji, pilnować uprawnień albo wymuszać zgodę człowieka przed kolejnym krokiem.

Decyzja na poniedziałek

Najprostszy podział wygląda tak:

Taki zakres da się zrobić przed pierwszym użyciem w zespole: wziąć jeden prompt, który już krąży w firmie, opisać dane wejściowe, wypisać pięć testów, ustawić warunek zatrzymania i wskazać osobę, która zatwierdza zmianę wersji.

Jeśli po tym prompt dalej wygląda sensownie, można z niego zrobić skill. Jeśli zaczyna się rozpadać pod prostymi pytaniami, dobrze, że rozpadł się na kartce, a nie w mailu do klienta.

Prompt dla właściciela procesu

Prompt dla osoby technicznej

Źródła

• OpenAI - Working with evals
• OpenAI - Evaluation best practices
• OpenAI - Evaluate agent workflows
• McKinsey - The state of AI in 2025
• NIST - AI Risk Management Framework