Procedura

Human‑in‑the‑Loop: zatwierdzanie narzędzi i treści wysokiego ryzyka

Klasyczna kontrola: jeśli decyzja ma koszt lub ryzyko, potrzebuje autoryzacji. Ten rozdział pokazuje, jak ująć to w Engine: tryby wykonania, bramki, audyt i regresje.


HITL: kontrola tam, gdzie koszt błędu jest wysoki

Human‑in‑the‑Loop nie jest „hamulcem”. To mechanizm bezpieczeństwa i jakości, uruchamiany tylko wtedy, gdy model wchodzi w obszar wysokiego ryzyka: decyzje prawne, finansowe, operacje nieodwracalne, ujawnienie danych lub działania na kontach użytkowników.

Klasyfikacja ryzyka (prosty model)

  • Low: informacyjne odpowiedzi bez narzędzi i bez danych wrażliwych.
  • Medium: użycie narzędzia „read-only”, brak PII, brak skutków trwałych.
  • High: write actions, finanse, legal, PII, eskalacje uprawnień.
Klasyczna zasada: HITL powinien mieć SLA. Bez SLA HITL zamienia się w „kolejkę bez końca” i degraduje doświadczenie użytkownika.

Wzorzec zatwierdzania

  1. Propozycja: model generuje plan/zmianę i uzasadnienie + cytowania.
  2. Podgląd skutków: co dokładnie zrobi narzędzie (diff / preview).
  3. Zatwierdzenie: osoba odpowiedzialna (RACI) akceptuje, odrzuca albo modyfikuje.
  4. Wykonanie: narzędzie działa z tokenem czasowym i pełnym audytem.

Artefakty audytowe

  • request_id, trace_id, user_id (z redakcją danych),
  • policy_version, tool_contract_version,
  • decyzja (approve/deny) i powód,
  • wynik wykonania + ewentualna kompensacja/rollback.
W skrócie
  • AUTO‑EXECUTE vs APPROVAL vs BLOCK
  • reguły bramek i odpowiedzialność
  • audyt decyzji człowieka
  • symulator doboru trybu

Po co Human‑in‑the‑Loop

Tam, gdzie LLM steruje narzędziami (Function Calling), dotyka danych wrażliwych lub generuje treści o skutkach prawnych, klasyczne „dajmy modelowi więcej instrukcji” nie wystarcza. Potrzebny jest mechanizm zatwierdzania — taki, który da się audytować.

Zasada tradycyjna
Jeśli decyzja jest kosztowna, nieodwracalna lub prawnie ryzykowna — nie wykonuje się jej „na słowo”. W Luage to samo dotyczy modelu.

Trzy tryby pracy

  • AUTO‑EXECUTE — model wykonuje, ale pełny trace jest obowiązkowy.
  • REQUIRE APPROVAL — model proponuje plan i parametry; człowiek zatwierdza wykonanie.
  • BLOCK / ESCALATE — automatyczne wykonanie zablokowane; decyzja idzie do właściciela procesu.

Symulator bramek zatwierdzania

Poniżej jest prosty symulator. W praktyce „poziom ryzyka” jest wyliczany z kontekstu: dziedziny, typu danych, narzędzia i charakteru żądania. Tu pokazujemy mechanikę.

Rys. 1. Dobór bramek i trybu wykonania na podstawie poziomu ryzyka.
Poziom ryzyka
0 = niskie (auto), 100 = wysokie (blok/eskalacja)
Score:
Uzasadnienie
Aktywne bramki

    Wdrożenie w Engine

    • Tool Gateway: każda akcja idzie przez jeden punkt egzekucji (walidacja, uprawnienia, limity).
    • Tryb zatwierdzania: Engine publikuje „propozycję wykonania” (plan) i czeka na akceptację.
    • Audyt: decyzja człowieka jest artefaktem (ticket / podpis / identyfikator osoby).
    • Regresje: przypadki wysokiego ryzyka są w golden secie, z testami „nie wolno wykonać”.

    Checklista operacyjna

    • Czy znamy właściciela procesu (RACI) dla każdej klasy zatwierdzeń?
    • Czy mamy limity czasu, kosztu i zasięgu narzędzi (scope clamp)?
    • Czy logujemy trace + parametry narzędzi?
    • Czy wyjątki są w rejestrze (kto, dlaczego, na jak długo)?