Odpowiedź AI może wydawać się precyzyjna, a mimo to nie nadawać się do użycia w systemie. To, że klasyfikuje zgłoszenie jako pilne, sugeruje uzupełnienie pola lub zaleca uruchomienie przepływu, nie oznacza, że ma uprawnienia, wystarczający kontekst ani że spełnia reguły biznesowe. Ryzyko pojawia się, gdy tekstową lub ustrukturyzowaną sugestię przekształca się w wykonywalne polecenie bez niezależnych barier.
Aby walidować ustrukturyzowane wyniki AI w PHP, warto traktować model jako komponent przygotowujący propozycje, a nie jako podmiot uprawniony do modyfikowania rekordów, przypisywania osób odpowiedzialnych, wysyłania komunikacji lub uruchamiania procesów. Aplikacja zachowuje prawo do decyzji, stosuje własne reguły i rejestruje, dlaczego propozycja została zaakceptowana, poprawiona lub odrzucona.
Pozornie przekonujący wynik nie jest prawidłową instrukcją
Modele mogą zwracać poprawny składniowo JSON, a mimo to zawierać nieistniejący priorytet, identyfikator nieodpowiadający klientowi, niemożliwą datę lub działanie, o które użytkownik nie może wnioskować. Mogą również uzupełniać dane nieobecne w wejściu, błędnie interpretować dwuznaczność lub stosować stary format po zmianie kontraktu.
Granica operacyjna musi być wyraźna: AI może zaproponować działanie i wyjaśnić, jakich danych użyła; system decyduje, czy propozycja staje się szkicem, wymaga przeglądu czy może zostać wykonana w bardzo ściśle ograniczonych warunkach. Ten podział chroni zarówno integralność danych, jak i odpowiedzialność za decyzję.
Dobrym punktem wyjścia jest klasyfikacja każdego działania według wpływu:
- Niski wpływ: oznaczenie szkicu etykietą, zasugerowanie kategorii lub wyodrębnienie niekrytycznych pól.
- Średni wpływ: utworzenie oczekującego zadania, zaproponowanie osoby odpowiedzialnej lub przygotowanie odpowiedzi do przeglądu.
- Wysoki wpływ: zmiana statusów umownych, przydzielenie nieodwracalnej pracy, modyfikacja kwot, usuwanie danych, komunikacja zewnętrzna lub aktywowanie wrażliwych procesów.
Dopuszczalna autonomia nie zależy od tego, czy AI deklaruje wysoką pewność. Zależy od odwracalności, kosztu błędu, weryfikowalnej jakości danych oraz istnienia kontroli poza modelem.
Zdefiniuj kontrakt propozycji przed integracją modelu
Kontrakt wyjściowy określa, co komponent AI może proponować, a co pozostaje poza jego zakresem. Powinien być niewielki, typowany i wersjonowany. Zamiast prosić „zdecyduj, co zrobić z tym zgłoszeniem”, określ zamkniętą listę działań i pola niezbędne dla każdego z nich.
{
"version": "1",
"action": "create_task_draft",
"category": "billing",
"priority": "normal",
"summary": "Sprawdź rozbieżność na fakturze",
"sourceReferences": ["message:123"],
"confidence": 0.82
}Lista działań powinna używać kontrolowanych wartości, na przykład create_task_draft, request_more_information lub no_action. Nie należy akceptować nazw metod, zapytań, fragmentów kodu, dowolnych odbiorców ani instrukcji typu „zaktualizuj zamówienie”. Aplikacja tłumaczy dozwolone działanie na konkretną operację wewnętrzną.
Pola, stany i dowody
Poza typami i dozwolonymi wartościami kontrakt powinien wskazywać, które pola są obowiązkowe, jakie kombinacje są niezgodne oraz jakie dowody musi dostarczyć propozycja. Kategoria może być prawidłowa, lecz wymagać co najmniej jednego odwołania do wiadomości lub dokumentu źródłowego. Pewność, jeśli jest zbierana, jest daną pomocniczą do porządkowania przeglądów; nie zastępuje walidacji.
Wersjonowanie schematu pozwala bezpiecznie odrzucać wyniki pochodzące z wycofanych kontraktów. Jeśli modyfikacja dodaje obowiązkowe pole lub usuwa działanie, adapter musi rozpoznać wersję i unikać domyślnych interpretacji.
Zastosuj cztery bariery przed każdym skutkiem
Walidacja powinna odbywać się w oddzielnych warstwach. Błąd w jednej warstwie nie jest kompensowany przez pozornie rozsądną odpowiedź w innej.
- Format: sprawdź, czy odpowiedź można zdekodować, czy spełnia oczekiwany schemat, nie zawiera nieoczekiwanych krytycznych pól oraz czy każda wartość ma prawidłowy typ. Nieprawidłowy JSON, nieznana wartość wyliczeniowa lub brak obowiązkowego pola są odrzucane.
- Domena: zweryfikuj reguły właściwe dla aplikacji. Na przykład czy kategoria istnieje, czy priorytet ma zastosowanie do typu zgłoszenia, czy wskazane konto jest aktywne oraz czy referencja źródłowa należy do przetwarzanego kontekstu.
- Autoryzacja: sprawdź, co może zrobić podmiot, który uruchomił przepływ, oraz jakich uprawnień wymaga operacja. AI nie dziedziczy nieograniczonych przywilejów ani nie decyduje o zakresie dostępu. Serwer stosuje tożsamość, tenant i obowiązujące polityki.
- Warunki operacyjne: sprawdź współbieżność, bieżące stany, limity, zależności i idempotencję. Prawidłowa propozycja może nie być wykonalna, jeśli sprawa została już zamknięta, inny proces zmienił rekord lub przekroczono próg obciążenia.
Walidacja semantyczna musi odwoływać się do wewnętrznych źródeł prawdy. Nie wystarczy, że model zwróci poprawnie sformowany identyfikator: repozytorium lub usługa domenowa musi zweryfikować jego istnienie, przynależność i stan. Unikaj sytuacji, w której odpowiedź modelu przenosi dane autoryzacyjne, które aplikacja może samodzielnie ustalić.
Architektura PHP: oddzielne propozycja, decyzja i wykonanie
Architektura łatwa w utrzymaniu rozdziela odpowiedzialności. Adapter AI przygotowuje żądanie, stosuje limity rozmiaru i uzyskuje wynik; nie zapisuje danych w biznesowej bazie danych. DTO reprezentuje już sparsowaną propozycję. Walidator domenowy przekształca tę propozycję w decyzję z jawnymi błędami. Na koniec autoryzowany wykonawca stosuje wyłącznie zatwierdzone decyzje.
final class ActionProposal {
public function __construct(
public string $action,
public string $category,
public string $priority,
public array $sourceReferences,
) {}
}
$proposal = $aiAdapter->propose($input);
$validation = $domainValidator->validate($proposal, $context);
if (!$validation->isApproved()) {
$auditLog->recordRejected($proposal, $validation->reasons());
return $validation;
}
return $decisionService->route($validation->approvedProposal(), $context);Usługa decyzyjna może utworzyć szkic, umieścić go w kolejce do przeglądu lub zażądać zatwierdzenia przez człowieka. Końcowy wykonawca powinien otrzymywać wewnętrzny obiekt decyzji, a nie surową odpowiedź ani JSON AI. Zapobiega to temu, by przypadkowe rozszerzenie kontraktu stało się nową zdolnością operacyjną.
Stosuj transakcje dla powiązanych zmian, klucze idempotencji dla ponownych prób oraz mechanizmy kontroli współbieżności, gdy kilka osób lub procesów może działać na tej samej sprawie. Rozróżniaj również wdrożenie od aktywacji: kod może być wdrożony bez udostępniania przepływu rzeczywistym użytkownikom. Stopniowa aktywacja pozwala obserwować odrzucenia, czasy i poprawki przed rozszerzeniem zakresu.
Wybierz przegląd przez człowieka, ograniczoną automatyzację lub odrzucenie
Przegląd przez człowieka jest odpowiedni, gdy występuje istotna dwuznaczność, dane wrażliwe, skutki zewnętrzne, wyjątki od polityk lub wysokie koszty korekty. Interfejs przeglądu powinien pokazywać propozycję, dozwolone dowody źródłowe, spełnione reguły i powody alertu, nie przedstawiając rekomendacji jako faktu.
Ograniczona automatyzacja może być uzasadniona w przypadku odwracalnych i ograniczonych operacji: utworzenia nieprzypisanego szkicu, zastosowania tymczasowej etykiety lub skierowania zgłoszenia do ogólnej kolejki. Musi mieć limity częstotliwości, możliwość cofnięcia i późniejszy nadzór. Jeśli brakuje danych, występuje konflikt między regułami lub działanie jest poza listą dozwolonych, bezpiecznym zachowaniem jest odrzucenie lub eskalacja, a nie improwizacja.
Przed użyciem AI oceń alternatywę deterministyczną. Jeśli dane wejściowe podążają za stabilnymi wzorcami, reguły, prowadzone formularze, listy wyboru lub konwencjonalny klasyfikator mogą być tańsze, bardziej audytowalne i przewidywalne. Gdy używana jest AI, zdefiniuj przypadek użycia, reprezentatywny zestaw ewaluacyjny, progi operacyjne, koszt dla wolumenu oraz tryb degradacji na wypadek awarii dostawcy lub przekroczenia oczekiwanego czasu.
Przykład: przekształcenie zgłoszenia w szkic zadania
Załóżmy, że przychodzące zgłoszenie wspomina o rozbieżności na fakturze. AI może zaproponować kategorię billing, normalny priorytet oraz podsumowanie zadania. Walidator sprawdza, czy wiadomość należy do bieżącego tenanta, czy kategoria jest włączona oraz czy nie istnieje już otwarta sprawa z tą samą referencją. Jeśli wszystko jest poprawne, system tworzy szkic bez przypisywania osoby odpowiedzialnej ani zmiany statusu faktury.
Operator przegląda szkic, potwierdza lub koryguje kategorię i decyduje o przypisaniu zgodnie z bieżącym obciążeniem i uprawnieniami. To rozróżnienie zapobiega temu, by pozornie przekonująca inferencja dotycząca osoby odpowiedzialnej lub kwoty stała się błędną modyfikacją. Jeśli kontrakt wymaga numeru faktury, a nie występuje on w wiadomości, propozycja powinna zażądać dodatkowych informacji, a nie go wymyślać.
Śledzalność, prywatność i testy przed rozszerzeniem przepływu
Rejestruj identyfikator korelacji, wersję kontraktu, skrót lub referencję zminimalizowanych danych wejściowych, znormalizowaną propozycję, wyniki każdej walidacji, ostateczną decyzję, podmiot zatwierdzający, jeśli istnieje, oraz powód odrzucenia. Rejestr powinien być przydatny do badania incydentów bez duplikowania niepotrzebnych danych osobowych lub treści wrażliwych. Stosuj retencję, ograniczony dostęp i techniki minimalizacji odpowiednie do ryzyka procesu.
Testuj przepływ na reprezentatywnych przypadkach i przypadkach adwersarialnych: niekompletnych wejściach, sprzecznych instrukcjach, wymyślonych wartościach, referencjach z innego tenanta, współbieżnych zmianach stanu, odpowiedziach w starym formacie, opóźnieniach i niedostępności usługi AI. Kryteria akceptacji powinny mierzyć, czy nieautoryzowane operacje są blokowane, czy szkice można odzyskać, czy odrzucenia są zrozumiałe oraz czy system utrzymuje działającą alternatywę w razie awarii.
Bezpieczne działanie nie polega na tym, by model zawsze odpowiadał. Polega na zapewnieniu, że gdy odpowie błędnie, będzie odpowiadał zbyt długo lub nie odpowie, aplikacja PHP zachowa kontrolę i nie wywoła skutków, których nie potrafi uzasadnić.
