Bila orang dengar "AI agent yang boleh buat kerja sendiri," ada dua reaksi yang common. Yang pertama: teruja — bayangkan berapa banyak masa yang boleh jimat. Yang kedua: bimbang — kalau AI buat keputusan salah, siapa yang bertanggungjawab?
Kedua-dua reaksi tu valid. Dan kedua-duanya perlu diaddress dalam architecture, bukan diabaikan.
Human-in-the-Loop adalah jawapan engineering kepada soalan governance: di mana dalam workflow ini manusia kena sign off, dan di mana AI boleh proceed sendiri? Ia bukan soalan tentang kepercayaan kepada AI secara general. Ia soalan tentang risk profile setiap tindakan spesifik dalam workflow spesifik korang.
Spectrum autonomi — dari fully human ke fully autonomous
Bukan semua "AI involvement" sama. Ada spectrum yang panjang, dan most business deployments yang bertanggungjawab duduk di tengah-tengah — bukan di hujung kanan.
Ramai vendor AI akan pitch korang dengan vision "fully autonomous" sebagai end-goal. Ini commercially attractive narrative, tapi ia misleading untuk context business sebenar. Fully autonomous adalah appropriate untuk sesetengah workflows — tapi ia perlu di-earn melalui track record, bukan assumed dari awal.
Dua soalan untuk determine mana checkpoint perlu ada
Framework mudah yang kami guna bila design HITL untuk client:
Soalan 1: Kalau AI buat keputusan salah di sini, boleh ke ia di-undo? Kalau jawapannya "ya, dengan mudah" — autonomi lebih tinggi boleh diterima. Kalau jawapannya "susah" atau "tidak" — manusia perlu dalam loop. Hantar email kepada pelanggan yang salah? Susah undo reputasi. Update inventory count dalam system? Boleh reverse. Commit kepada kontrak procurement kerajaan? Definitely kena ada human sign-off.
Soalan 2: Siapa yang bertanggungjawab kalau ini salah? Dalam konteks Malaysia, ini bukan soalan abstract. Kalau ada dispute dengan pelanggan, regulatory inquiry, atau audit — siapa yang sign off pada decision ini? AI agent bukan legal entity. Kalau ada consequence yang boleh affect business secara legally atau financially, manusia yang ada authority kena ada dalam approval chain.
The rubber-stamp problem: HITL yang poorly designed adalah lebih berbahaya dari tiada HITL, sebab ia bagi false sense of security. Kalau approval interface korang design dengan cara yang push humans to approve quickly tanpa benar-benar review — notification yang datang terlalu kerap, preview yang terlalu sedikit maklumat, approval button yang terlalu prominent — staff akan rubber-stamp. Korang dapat blame-shifting bukan oversight.
Jenis-jenis checkpoint dalam HITL design
Checkpoint bukan monolithic. Ada beberapa jenis yang serve different purposes, dan campuran yang betul bergantung pada workflow korang.
Best practice adalah design workflow yang guna kombinasi: autonomous execution untuk routine tasks dengan complete audit trail, escalation triggers untuk exceptions, dan mandatory pre-action approval untuk genuinely consequential decisions. Jangan letak approval gate atas semua benda — ia akan create approval fatigue dan defeat the purpose.
Macam mana IRIS implement HITL dalam procurement
Procurement government adalah domain yang ada consequence yang sangat real — financial, reputational, dan legally. Salah buat, ia boleh affect standing korang dalam ePerolehan, atau worse, expose korang kepada dispute. Ini cara kami design HITL dalam IRIS:
Level 1 — Aggressiveness default (autonomous dengan guardrails)
Ini default launch setting. IRIS akan buat banyak kerja autonomously — scrape tender data, run compliance checks, pull contact intelligence, draft internal briefings. Tapi semua yang involve external communication atau commitment kena ada human approval dulu.
Contoh konkrit: Bila IRIS identify tender yang korang qualified untuk, dia akan prepare full briefing — tender summary, compliance analysis, win probability, contact officer details, suggested approach — dan present kepada person-in-charge untuk decision sama ada nak pursue. IRIS tak decide nak pursue; manusia decide.
Approval gates yang mandatory dalam IRIS
- Pursuit decision — IRIS present, manusia approve sama ada nak commit resources kepada tender
- External communication — sebarang email atau contact kepada officer kerajaan kena approved oleh staff yang authorized sebelum hantar
- Bid submission package — final document set kena reviewed dan signed off oleh authorized personnel sebelum submission
- Pricing commitment — sebarang figure yang akan masuk dalam tender bid kena human verification
Autonomous actions dalam IRIS (no approval needed)
- Scraping dan indexing tender listings dari ePerolehan
- Running compliance pre-checks (flagging issues, bukan clearing them)
- Drafting internal documents (proposal drafts, analysis reports) untuk human review
- Tracking deadlines dan sending internal reminders
- Updating pursuit status dalam internal dashboard
Kenapa Level 1 dan bukannya full autonomy dari awal? Bukan sebab IRIS tak capable secara teknikal untuk buat lebih. Ia sebab trust perlu di-build melalui track record. Setiap tender yang pursue, setiap output yang dihasilkan — semua tu adalah data point untuk calibrate mana IRIS boleh diberi lebih autonomi. Full autonomy untuk external communication mungkin appropriate selepas 50 tender cycles dengan zero errors. Sebelum tu, tidak.
Design prinsip untuk HITL yang sebenarnya berkesan
Ini bukan just engineering concern. Ia involve workflow design, staff training, dan UI/UX consideration yang ramai overlook.
Bagi context yang cukup dalam approval interface
Bila agent request approval, interface kena tunjukkan: apa yang dicadangkan, kenapa ia dicadangkan (reasoning), apa alternative options yang ada, dan apa consequence kalau approve atau reject. Kalau staff hanya nampak "Approve / Reject" tanpa context yang adequate, dorang tak boleh make informed decision — dorang hanya boleh guess atau rubber-stamp.
Calibrate notification frequency
Approval fatigue adalah real phenomenon. Kalau staff dapat 50 approval requests sehari, dorang akan stop reading dengan careful. Design automation supaya volume approval request adalah manageable — gunakan autonomous execution dengan post-hoc audit untuk low-stakes items, bukan require approval untuk semuanya.
Buat rejection mudah dan non-punitive
Kalau staff rasa "takut nak reject" sebab sistem design dia awkward, atau sebab ada expectation untuk approve — HITL jadi theater. Rejection path kena sama senang dengan approval path. Dan sistem kena learn dari rejection: kenapa ia direject, dan macam mana agent boleh improve next time.
Log semua benda, regardless of autonomy level
Sama ada human approve atau agent execute autonomously — log full decision chain: apa yang dipertimbangkan, apa yang diputuskan, masa, siapa yang involved. Ini bukan optional. Untuk procurement, untuk healthcare, untuk finance — audit trail adalah keperluan asas.
Satu perkara yang vendor AI selalu tak cakap
Ada narrative yang popular dalam AI sales: "AI akan replace repetitive work so your team can focus on higher-value activities." Ini partly true, tapi ia incomplete dalam cara yang penting.
Bila AI handle volume, setiap item yang sampai kepada manusia untuk review adalah yang lebih complex, lebih ambiguous, atau lebih high-stakes — sebab yang straightforward dah di-handle autonomously. Human workload dalam HITL system adalah more cognitively demanding per item, walaupun volume rendah.
Ini bukan argument against AI automation. Ia argument untuk invest dalam training staff untuk kerja dengan AI system dengan berkesan — faham output yang dihasilkan, tahu apa soalan perlu ditanya sebelum approve, recognize bila AI reasoning ada flaw yang subtle.
AI yang bagus dengan human yang tak prepared untuk review outputnya dengan kritis adalah combination yang berbahaya. Kedua-duanya kena di-develop serentak.
Macam mana build trust untuk expand autonomy over time
HITL bukan static design. Ia boleh dan patut evolve berdasarkan track record. Ini adalah framework untuk evaluate bila korang ready nak reduce checkpoints dalam specific area:
| Signal | Apa ia bermakna | Appropriate response |
|---|---|---|
| Approval rate >95% untuk jenis action tertentu selama 3 bulan | Humans consistently agree dengan agent recommendation — low value add dari checkpoint | Evaluate sama ada checkpoint boleh di-remove atau dijadikan async audit sahaja |
| Staff selalu approve tanpa membaca (masa review <5 saat) | Approval fatigue atau rubber-stamping — HITL dah jadi theater | Redesign — either reduce volume, atau improve interface supaya review lebih meaningful |
| Rejection rate tinggi untuk jenis action tertentu | Agent tak perform dengan baik dalam domain ni | Investigate root cause — data problem, prompt problem, atau scope yang salah defined |
| Zero errors dalam autonomous actions selama 6 bulan | Track record yang establish trust untuk expand autonomy | Cautiously expand scope autonomous action — document decision dan set review milestone |
| Satu error yang significant dalam autonomous action | Trust perlu di-rebuild | Reintroduce checkpoint, investigate, fix root cause sebelum expand semula |
Takeaway
HITL bukan reluctance untuk embrace AI. Ia adalah engineering maturity — tahu mana autonomi appropriate dan mana ia premature. Business yang deploy AI agent dengan thoughtful HITL design akan build trust lebih cepat, catch errors sebelum jadi costly, dan secara sistematis expand autonomy berdasarkan evidence — bukan berdasarkan hype.
Business yang deploy fully autonomous dari awal, tanpa checkpoint yang designed dengan baik, adalah satu atau dua errors away dari reverting to full manual semula — dan akan bawa sekali dengan dia skepticism terhadap AI yang susah nak recover.
Artikel seterusnya akan shift ke comparative analysis: n8n vs Kestra vs LangGraph — tools yang korang boleh guna untuk build agent workflows, dan macam mana pilih yang sesuai untuk scale dan technical capability team korang.