W prompcie pojawia się zdanie: „Nigdy nie wysyłaj wiadomości bez zgody człowieka”. Obok niego przycisk uruchamiający wysyłkę działa bez zgody. Zespół czuje się zabezpieczony, bo instrukcja jest napisana wielkimi literami. System wie tylko tyle, że dostał kolejny token.
Prompt opisuje oczekiwane zachowanie modelu. Reguła kodu ogranicza zachowanie aplikacji. To nie są konkurencyjne podejścia; odpowiadają za inne warstwy. Kłopot zaczyna się, gdy próbujemy zastąpić jedną drugą.
Rozpoznaj rodzaj decyzji
Zacznij od pytania, czy wynik wymaga interpretacji, czy jednoznacznego warunku. Dobór słów, streszczenie i propozycja kategorii należą do pierwszej grupy. Sprawdzenie salda, uprawnienia, wymaganego pola i limitu do drugiej.
Model może ocenić, czy wiadomość brzmi rzeczowo. Nie powinien sam decydować, że użytkownik ma rolę administratora. Aplikacja zna token i zakres dostępu. Przeniesienie tej decyzji do języka naturalnego dodaje niepewność tam, gdzie masz już wiarygodne źródło.
Zapisz tabelę: decyzja, źródło, możliwy błąd, właściciel, warstwa kontroli. Jeżeli źródłem jest reguła prawna lub stan systemu, zwykle potrzebujesz kodu i odbioru człowieka. Jeżeli źródłem jest nieustrukturyzowany opis, model może przygotować propozycję.
Do tabeli dopisz także zachowanie po awarii źródła, na przykład wstrzymanie wysyłki, gdy system nie potwierdzi aktualnej zgody.
Prompt jest dobrym miejscem na zadanie
Opisz cel, kontekst, dostępne źródła, format i sposób postępowania przy braku danych. To pomaga modelowi wykonać pracę językową. Nie wymagaj jednak od niego egzekwowania całej polityki firmy przez samą instrukcję.
Dobry przykład: „Użyj wyłącznie dostarczonego fragmentu; jeżeli nie zawiera terminu, zwróć null”. To jasna reguła ekstrakcji. Nadal dodajesz walidację, bo model może pomylić źródło albo źle odczytać pole. Prompt ogranicza prawdopodobieństwo, nie daje matematycznej gwarancji.
Unikaj wielkich bloków przypominających regulamin. Gdy instrukcja zawiera czterdzieści wyjątków, trudno sprawdzić ich wzajemny wpływ. Część należy przenieść do reguł procesu, część do danych źródłowych, a resztę uprosić. Model nie potrzebuje czytać historii wszystkich incydentów zespołu przed streszczeniem maila.
Kod odpowiada za granice działania
Limity kosztu, liczba prób, dozwolone adresy, zakres API i blokada publikacji powinny być wymuszane poza modelem. Nawet najlepiej napisana prośba „nie przekraczaj budżetu” nie zatrzyma żądania, które już zostało wysłane.
To samo dotyczy uprawnień. Jeżeli agent ma tylko czytać dokumenty, nadaj mu konto bez zapisu. Instrukcja „nie edytuj” nie zabezpiecza przed błędem integracji ani złośliwą treścią dokumentu. Zasady bezpieczeństwa agentów AI pokazują tę różnicę na poziomie całego procesu.
Przy działaniach nieodwracalnych dodaj jawny odbiór. System powinien pokazać dokładny skutek: odbiorcę, treść, kwotę, zasób i wersję. Przycisk „zgadzam się z rekomendacją AI” jest za mały, jeśli człowiek nie widzi, z czym właściwie się zgadza.
Reguła biznesowa potrzebuje źródła
„Duży klient” nie jest regułą, dopóki nie zdefiniujesz progu i okresu. „Pilne zgłoszenie” wymaga kryteriów. Model może zaproponować klasyfikację z tekstu, ale decyzja o progu powinna być zapisana w procesie i przetestowana.
Nie przenoś każdej niejasnej zasady do kodu tylko dla pozoru pewności. Czasem trzeba najpierw porozmawiać z właścicielem i ustalić definicję. Kod z błędnym progiem działa konsekwentnie, czyli konsekwentnie źle. AI przynajmniej potrafi oznaczyć niejednoznaczność, jeśli dasz jej taką możliwość.
Przy zmianie reguły zachowaj datę i wersję. Raporty z poprzedniego okresu mogą używać starej definicji. Bez tego porównanie skutku przypomina mierzenie dwóch pokoi różnymi linijkami i dyskutowanie o architekturze.
Cztery warstwy jednego procesu
Pierwsza warstwa to dane: dokument, formularz, konfiguracja. Druga to model, który interpretuje i przygotowuje propozycję. Trzecia to aplikacja sprawdzająca strukturę, reguły i uprawnienia. Czwarta to człowiek odpowiedzialny za decyzje wymagające kontekstu lub akceptacji ryzyka.
Taki podział pozwala lokalizować błędy. Jeżeli źródło jest stare, nie poprawiasz promptu. Jeżeli model wybiera złą kategorię, dodajesz przypadek testowy. Jeżeli aplikacja wysyła bez zgody, zmieniasz kod. Jeden przycisk „ulepsz AI” nie rozwiązuje czterech różnych problemów.
W dokumentacji zapisz wejście i wyjście każdej warstwy. Wtedy nowa osoba widzi, gdzie powstaje decyzja. Bez tego cały proces wygląda jak czarne pudełko z logo modelu i nadzieją.
Przykład: eskalacja zgłoszenia
Model odczytuje treść i proponuje kategorię „reklamacja”. Aplikacja sprawdza, czy pole należy do zatwierdzonej listy i czy zgłoszenie zawiera wymagany identyfikator. Reguła kieruje sprawę do właściciela. Człowiek akceptuje odpowiedź przed wysłaniem.
Można by zapisać w prompcie: „Jeżeli klient jest niezadowolony, eskaluj”. To zostawia zbyt wiele pytań. Co oznacza niezadowolenie, do kogo trafia sprawa i czy każdy negatywny komentarz jest reklamacją? Reguła procesu powinna używać konkretnych warunków, a model tylko dostarczać dane wejściowe.
Test obejmuje zgłoszenie neutralne, negatywne bez reklamacji, reklamację bez emocji i próbę wymuszenia wysyłki w treści. Dopiero zestaw pokazuje, czy granice działają.
Przykład: generowanie opisu produktu
Prompt mówi, aby używać atrybutów i nie dodawać nowych właściwości. Aplikacja porównuje pola z katalogiem i sprawdza zakresy. Człowiek odbiera twierdzenia o bezpieczeństwie lub zgodności. Model przygotowuje język, nie źródło faktów.
Jeżeli chcesz zablokować publikację opisu bez ceny, zrób to w kodzie. Prośba „pamiętaj o cenie” może pomóc, ale nie zastępuje walidacji. Przy opisach warto połączyć ten proces z zasadami z artykułu o specyfikacji produktu i AI.
Nie każde zdanie da się sprawdzić automatycznie. Styl i naturalność wymagają odbioru. Dlatego proces nie kończy się na zielonym teście pól; kończy się na tekście, który jest prawdziwy i użyteczny.
Kiedy reguła powinna wrócić do promptu
Czasem kod jest zbyt sztywny dla zadania językowego. Próba opisania każdego tonu i wyjątku stylistycznego w setkach warunków kończy się systemem, którego nikt nie rozumie. Tutaj lepsze są przykłady, rubryka i przegląd.
Jeżeli reguła brzmi „odpowiedź powinna być życzliwa”, nie zamieniaj jej od razu na listę zakazanych słów. Zdefiniuj zachowanie i przypadki. Może chodzi o brak oceniania użytkownika, konkretny krok i zwykły język. Model może przygotować wariant, człowiek ocenić sens.
Nie przenoś jednak decyzji prawnych z powrotem do modelu dlatego, że kod jest niewygodny. Wybór warstwy zależy od ryzyka i źródła, nie od tego, co szybciej się napisze przed piątkowym demo.
Testuj granice, nie tylko średni wynik
Przygotuj przypadek, w którym model daje poprawną propozycję, ale aplikacja powinna ją zablokować z powodu uprawnień. Dodaj przypadek, w którym model się myli, a reguła biznesowa wychwytuje błąd. Na końcu sytuację wymagającą człowieka.
Sprawdź próby obejścia: polecenie w dokumencie, nieznana kategoria, wartość poza zakresem, ponowienie żądania i konflikt źródeł. Test ma potwierdzić zachowanie całej aplikacji, nie tylko odpowiedź modelu na piękne wejście.
Po zmianie promptu nie musisz powtarzać wszystkich testów kodu, ale musisz uruchomić przypadki zależne od jego danych wyjściowych. Po zmianie uprawnień testujesz działania, nie styl odpowiedzi. To może ograniczyć pracę, jeśli mapa zależności jest poprawna i testy obejmują istotne przypadki. Nie daje jednak takiej samej pewności co pełna regresja.
Odbiór architektury w małym zespole
Weź jeden proces i zaznacz wszystkie zdania zaczynające się od „model nie może”. Przy każdym zapytaj, co technicznie temu zapobiega. Jeżeli odpowiedź brzmi „napisaliśmy to w prompcie”, masz kandydata do reguły lub ograniczenia uprawnień.
Potem znajdź warunki kodu dotyczące gustu, tonu i oceny kontekstu. Sprawdź, czy nie udają precyzji tam, gdzie potrzebna jest rubryka. Celem nie jest maksymalna liczba reguł. Celem jest właściwa odpowiedzialność.
Dokumentuj wyjątki bez tworzenia tylnych drzwi
Każdy proces ma przypadki nietypowe. Zapisz, kto może zatwierdzić wyjątek, na jak długo i z jakim śladem. Nie dodawaj do promptu zdania „w uzasadnionych sytuacjach możesz pominąć zasady”. To nie jest polityka, tylko zaproszenie do swobodnej interpretacji.
Jeżeli wyjątek pozwala na publikację bez standardowego pola, aplikacja powinna wymagać konkretnej roli i powodu. Człowiek widzi skutek, a system zapisuje decyzję. Model może przygotować opis sytuacji, ale nie zatwierdza własnego odstępstwa.
Po miesiącu przejrzyj wyjątki. Powtarzalny przypadek może wymagać zmiany reguły, a nie kolejnych ręcznych decyzji. Inny powinien zniknąć po naprawie źródła. Liczba obejść jest dobrym sygnałem, że architektura nie odpowiada na pracę zespołu.
Antywzorzec: testowanie samego modelu
Zespół uruchamia dwadzieścia promptów i ogłasza, że proces jest bezpieczny. Tymczasem produkcja dodaje inne narzędzia, inne uprawnienia i automatyczne ponowienia. Test modelu nie obejmuje tych warstw. Przy odbiorze trzeba uruchomić rzeczywistą ścieżkę z kontrolowanymi danymi.
Sprawdź szczególnie błąd po stronie integracji. Model może poprawnie odmówić działania, a aplikacja i tak wykona wcześniej przygotowane żądanie. Decyzja językowa i techniczna muszą być powiązane. Nie wystarczy przeczytać odpowiedź; trzeba zobaczyć skutek lub jego brak.
Dodaj przypadek awarii samego odbioru. Jeśli użytkownik zamknie okno przed zatwierdzeniem, nic nie powinno zostać wysłane. Jeśli kliknie dwa razy, operacja nie może się zduplikować. To są twarde reguły niezależne od jakości promptu.
Podobny test wykonaj przy zmianie danych między propozycją a akceptacją. Model przygotował wynik dla starej wersji, a człowiek zatwierdza już nową. Aplikacja powinna porównać identyfikator lub wersję źródła i wstrzymać operację. Instrukcja „sprawdź aktualność” w prompcie nie zastąpi kontroli wykonanej w momencie działania.
Takie przypadki pokazują, że granica nie jest tylko listą zakazów. Jest również powiązaniem decyzji z konkretnym stanem systemu. To jeden z powodów, dla których odbiór architektury musi obejmować czas i zmiany danych, a nie tylko statyczne odpowiedzi.
Najprostsza reguła decyzyjna
Zadaj trzy pytania: czy warunek da się sprawdzić jednoznacznie, jaki jest koszt naruszenia i czy model ma wiarygodne źródło decyzji. Jednoznaczny i krytyczny warunek należy do kodu oraz uprawnień. Interpretacja językowa może zostać przy modelu z odbiorem proporcjonalnym do ryzyka.
Nie używaj tej reguły jako automatu. Zapisz uzasadnienie przy procesie i omów je z osobą odpowiedzialną za skutek. Po zmianie źródła lub ryzyka wróć do decyzji. Granica między promptem a kodem jest częścią projektu, a nie ustawieniem raz na zawsze.
Aeneia Audit pomaga rozłożyć taki proces na dane, decyzje i właścicieli. Przy wdrożeniu agentów pomocny jest przewodnik Aeneia Signal o odpowiedzialnym workflow.
Granicę ustal przy konkretnym skutku. Dostęp i reguły zapisu wymagają kontroli w aplikacji; interpretację języka można przekazać modelowi. Przy zmianie ryzyka wróć do tego podziału razem z właścicielem procesu.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
