Human-in-the-loop sustavi su arhitektura, ne checkbox

Većina timova ljudski review doda prekasno.

Prvo izgrade automatizaciju, zatim vide da sustav može napraviti nešto rizično, pa pri kraju dodaju approval gumb. To može proći u demou. U stvarnom workflowu obično pukne jer težak dio nije gumb. Težak dio je odluka što stroj smije napraviti prije nego čovjek vidi rezultat, koji state čovjek pregledava i što se događa nakon što čovjek kaže da, ne ili “promijeni ovo pa nastavi”.

Human-in-the-loop sustavi nisu UI detalj. Oni su workflow arhitektura.

IBM human-in-the-loop definira kao proces u kojem čovjek aktivno sudjeluje u radu, nadzoru ili donošenju odluka u automatiziranom ili AI sustavu. Ta definicija je korisna jer čovjeka ne svodi na gumeni pečat. Čovjek je dio granice sustava.

Taj dio mnogi AI automation projekti promaše.

Pogrešna verzija: odobrenje nakon štete

Slab human-in-the-loop dizajn izgleda ovako:

1. AI agent prikupi podatke.
2. Zaključi nešto iz tih podataka.
3. Zapiše promjenu u CRM, pošalje email, ažurira ticket ili pokrene API poziv.
4. Čovjek dobije obavijest da se nešto dogodilo.

To nije nadzor. To je račun.

Ako je akcija bila pogrešna, čovjek sada ima posao čišćenja. Mora poništiti zapis, objasniti grešku, vratiti povjerenje i provjeriti je li se isti problem dogodio drugdje. Workflow tehnički ima čovjeka u sebi, ali čovjek je nizvodno od side effecta.

Bolji dizajn stavlja čovjeka prije nepovratne ili skupe akcije.

Sustav i dalje može napraviti koristan posao prije te točke. Može prikupiti kontekst, klasificirati zahtjev, napisati draft odgovora, procijeniti rizik, predložiti sljedeću akciju i pokazati dokaze. Ali mora stati prije granice koju je bolno vraćati unatrag.

Pregledava se state, ne samo output

Revieweru nije dovoljan samo generirani odgovor.

Mora vidjeti state workflowa. Što je sustav pročitao? Koje zapise je spojio? Koji tool želi pozvati? Koje confidence signale ima? Što se promijenilo od prethodnog koraka? Što će se dogoditi ako reviewer odobri nastavak?

Kod agenata je to posebno važno jer je output samo vidljivi dio procesa. Rizik je često skriven u izboru toola, dohvaćenom kontekstu, implicitnoj pretpostavci ili krivom data matchu.

Dobar review ekran treba brzo odgovoriti na nekoliko pitanja:

1. Koja je predložena akcija?
2. Zašto je sustav predlaže?
3. Koje podatke je koristio?
4. Što će se promijeniti ako odobrim?
5. Mogu li urediti odluku prije nastavka?
6. Može li workflow čisto nastaviti nakon moje izmjene?

Ako reviewer ne može brzo odgovoriti na ta pitanja, sustav traži povjerenje koje još nije zaslužio.

Dobar human-in-the-loop dizajn ima stop točke

Najbolje review točke su eksplicitne granice u workflowu.

Zato su frameworkovi poput LangGrapha zanimljivi za production AI rad. LangGraph ima durable execution i podršku za interrupte. U praksi to znači da workflow može stati, spremiti state, čekati vanjski input i zatim nastaviti umjesto da krene ispočetka.

Taj oblik odgovara stvarnim poslovnim procesima. Customer support workflow može stati prije slanja osjetljivog odgovora. Finance workflow može stati prije izrade korekcije računa. Data workflow može stati kada je match zapisa nejasan. Content workflow može stati prije objave ili slanja klijentu.

Pattern je jednostavan:

1. Pripremi posao.
2. Stani na risk granici.
3. Pokaži čovjeku predloženu akciju i dokaze.
4. Prihvati odobrenje, odbijanje ili izmjene.
5. Nastavi iz istog statea.
6. Zapiši što se dogodilo.

Važna riječ je “nastavi”. Ako workflow ne može čisto nastaviti, approval korak je ručni handoff prerušen u automatizaciju.

Side effecti trebaju disciplinu

Ljudski review je mnogo lakši kada su side effecti izolirani.

Side effect je sve što mijenja vanjski svijet: slanje emaila, upis u bazu, otvaranje ticketa, naplata kartice, objava stranice ili API poziv koji mijenja remote sustav.

Production workflow treba ove akcije tretirati pažljivo:

1. Čitaj i pripremi prije odobrenja.
2. Mijenjaj sustave nakon odobrenja.
3. Ponavljajuće akcije učini idempotentnima gdje je moguće.
4. Spremi dovoljno statea za oporavak nakon pada.
5. Drži audit trail tko je što odobrio i kada.

To nije birokracija. To je način da automatizacija ne postane hrpa side effecta koje nitko ne može objasniti.

LangGraph dokumentacija za durable execution ide u istom smjeru: dugotrajni workflowi trebaju persistence jer su pauze, retryji i greške normalni. Kada to prihvatite, ljudski review postaje prirodan dio runtimea, a ne odvojeni ručni proces.

Ne treba svaki korak čovjeka

Human-in-the-loop ne znači da čovjek mora stajati ispred svake akcije.

To bi bilo sporo, naporno i ljudi bi s vremenom počeli ignorirati review. Bolji pristup je risk-based routing.

Niskorizične akcije mogu ići automatski. Srednji rizik može tražiti review kada je confidence nizak ili podaci nedostaju. Visokorizične akcije trebaju uvijek stati na odobrenju. Neke akcije ne bi smjele biti potpuno automatizirane osim ako ih čovjek eksplicitno pokrene.

Jednostavna politika može izgledati ovako:

1. Automatski: enrichment, klasifikacija, sažimanje, detekcija duplikata.
2. Review kada postoji nesigurnost: customer replies, spajanje zapisa, promjene cijena, neuobičajeni refundi.
3. Uvijek odobri: pravni tekst, financijske promjene, brisanje računa, javna objava.
4. Nikad potpuno autonomno: odluke za koje organizacija ne želi delegirati odgovornost.

Točne granice ovise o poslu. Princip ne ovisi: autonomija treba rasti samo ondje gdje su reverzibilnost, confidence i odgovornost dovoljno jaki.

Reviewer mora imati autoritet

Postoji još jedna zamka: timovi dodaju ljudski review, ali čovjek ne može stvarno promijeniti ishod.

Reviewer koji može samo odobriti ili odbiti ponekad je dovoljan. Ali mnogi workflowi trebaju treću opciju: uredi i nastavi.

To može značiti promjenu generiranog emaila, odabir drugog customer recorda, korekciju kategorije, dodavanje konteksta koji nedostaje ili izbor drugog tool patha. Workflow tu izmjenu treba tretirati kao dio statea, ne kao komentar zalijepljen u side channel.

Tu ljudski review postaje stvarno koristan. Čovjek ne zaustavlja samo loš output. Čovjek poboljšava proces dok se on izvodi.

Što logirati

Human-in-the-loop sustav mora ostaviti trag.

Minimalno logirajte:

1. Predloženu akciju.
2. Dokaze prikazane revieweru.
3. Model ili automation korak koji je prijedlog proizveo.
4. Reviewerovu odluku.
5. Ljudske izmjene.
6. Završnu akciju.
7. Vrijeme i aktera.

To omogućuje debugging. Također olakšava poboljšavanje sustava jer možete vidjeti gdje ljudi stalno ispravljaju stroj. Ti correction patterni često su najbolji product feedback koji ćete dobiti.

Ako revieweri stalno mijenjaju isto polje, vjerojatno su prompt, retrieval, mapping ili business rule pogrešni. Ako revieweri sve odobravaju bez čitanja, review točka je na krivom mjestu ili UI ne pokazuje rizik dovoljno jasno.

Praktična arhitektura

Pouzdan human-in-the-loop workflow obično ima ove dijelove:

1. State store za trenutne workflow podatke.
2. Queue ili task listu za reviewe koji čekaju.
3. Policy sloj koji odlučuje kada sustav mora stati.
4. Review UI koji pokazuje akciju, dokaze i posljedice.
5. Resume mehanizam koji nastavlja iz spremljenog statea.
6. Audit log za odobrenja, izmjene i završne akcije.
7. Observability za greške, retryje i correction patterne.

To se može izgraditi u različitim stackovima. LangGraph je dobar fit za stateful AI workflowe. n8n, Make, Pipedream, Retool, Airtable, Slack i custom aplikacije također mogu imati svoje mjesto, ovisno o okruženju. Alat je manje važan od discipline oko granica.

Greška je misliti da je approval ekran cijeli sustav. Nije. To je samo vidljivi dio stateful workflowa.

Jednostavno pravilo

Stavite čovjeka prije skupe greške.

To pravilo hvata većinu loših dizajna. Ako workflow može prvo djelovati pa tek onda pitati, nemate smislen nadzor. Ako reviewer ne vidi dokaze, nemate smislen judgment. Ako sustav ne može nastaviti nakon reviewa, nemate workflow automatizaciju. Imate handoff.

Human-in-the-loop sustavi rade kada je čovjek dio arhitekture: state, policy, approval, recovery i audit trail.

Sve ostalo je samo approval gumb.

Reference: IBM: What is human in the loop?, LangGraph interrupts, LangGraph persistence and durable execution, NIST AI Risk Management Framework.