Bago magpadala o magbura ang AI agent, maglagay muna ng approval gate

Maglagay ng approval gate sa tool call bago magpadala ng mensahe, bumili, magbago ng mahalagang record o magbura ng data ang AI agent. Sa gabay ng n8n sa human review, humihinto ang workflow para ipakita sa reviewer ang tool at mga parameter nito; ang approval ang nagpapahintulot sa tool na tumakbo, habang ang pagtanggi ay nagkakansela sa aksiyon.

Para sa sariling workflow, itali ang pasya sa isang partikular na tawag at sa mga detalyeng talagang nakita ng reviewer. Karaniwang maaaring magpatuloy ang awtorisadong pagbasa at paggawa ng pansamantalang draft nang walang hiwalay na approval. Ipatupad ang gate sa puntong ang draft ay magiging ipinadalang mensahe, bayarin, pagbabago sa pinal na record o pagbura.

Aling mga tool ang dapat ihinto?

Gamitin ang risk tier bilang panimulang patakaran, pagkatapos ay tingnan ang aktuwal na epekto ng bawat konektadong tool. Maaaring magmukhang simpleng pag-save ang isang tawag ngunit magpalit pala ng shared record o magpasimula ng isa pang aksiyon. Ang pangalan ng tool lamang ay hindi sapat na batayan.

• Read: Karaniwang walang approval para sa pagbasa ng datos na pinahihintulutan na ng workflow. Panatilihin ang access control sa personal o sensitibong impormasyon; hindi nagbibigay ng bagong pahintulot sa data ang pasya ng reviewer.
• Draft: Karaniwang walang approval kung pansamantala ang output at wala itong pinapalitang pinal na bersiyon. Kung ang pag-save ng draft ay sumusulat sa shared record o nagpapagana ng kasunod na aksiyon, ituring ito bilang modify.
• Send: Humingi ng approval bago ang email, chat message, publikasyon o iba pang komunikasyong makakarating sa labas. Ihiwalay ang pagbuo ng nilalaman sa tool na talagang nagpapadala nito.
• Modify: Ipa-review ang pagbabago sa customer record, pahintulot, presyo o production configuration. Para sa mas mababang panganib na pag-edit, maaaring gawing kondisyon ang uri ng field, saklaw ng mga record o antas ng pahintulot na babaguhin.
• Purchase: Humingi ng approval sa tool na makalilikha ng order o bayarin. Kailangang makita ang item o serbisyo, kabuuang halaga, currency, nagbebenta at account na sisingilin.
• Delete: Humingi ng approval bago burahin o kanselahin ang mga record, lalo na kung maramihan ang target. Ipakita kung ano mismo ang mawawala at kung may kasamang kaugnay na data.

Kung may ligtas at sensitibong gamit ang iisang tool, suriin ang mga parameter ng bawat tawag. Halimbawa, magkaiba ang epekto ng pag-update ng pansamantalang tala at pagpapalit ng pangunahing email address sa customer record. Itakda rin kung sino ang may karapatang mag-apruba sa bawat uri ng epekto, sa halip na ipadala ang lahat ng kahilingan sa iisang tao.

Ano ang kailangang makita ng reviewer?

Ipakita ang epekto ng eksaktong tool call, hindi lamang ang pangalan nito o buod na isinulat ng agent. Sa pagpapadala, isama ang sender account, tatanggap, paksa, buong mensahe at mga attachment. Sa pagbura, isama ang target na record ID, uri at dami ng mga record, pati ang saklaw ng kaugnay na data. Sa pagbili, kailangang malinaw kung ano ang bibilhin at kung aling account ang magkakaroon ng bayarin.

Ganito maaaring ayusin ang isang halimbawang approval payload para sa email. Mga pangalan ng field ang nasa ibaba; ang mga halaga ay kukunin sa nakabinbing tawag bago ito ipakita sa taong magpapasya.

• request_id at tool_call_id: mga identifier na mag-uugnay sa pasya at sa partikular na nakabinbing tawag; action: send_email.
• sender at recipient: eksaktong account na magpapadala at address na tatanggap.
• subject, body at attachments: buong nilalamang maaabot ng tatanggap, kasama ang pangalan at aktuwal na bersiyon ng bawat attachment.
• context: kahilingan ng user at mga record na naging batayan ng draft, ayon sa pahintulot ng reviewer.
• decision at expiry: approve o deny, at oras na mawawalan ng bisa ang kahilingan ayon sa patakaran ng workflow.

Kung may field na awtomatikong pinupunan ng konektadong serbisyo, isama ang pinal na halaga nito sa ipapakitang epekto. Kung hindi ito makita, maaaring mag-apruba ang reviewer ng ibang aksiyon kaysa sa talagang mangyayari. Limitahan ang sensitibong detalye sa awtorisadong reviewer; kung kailangan niyang makita ang isang nakatagong field upang makapagpasya, ilipat ang kahilingan sa taong may tamang access.

Paano i-pause at ipagpatuloy ang run?

Sa gabay ng OpenAI Agents SDK, maaaring itakda ang needsApproval sa tool bilang palaging kondisyon o function na sumusuri sa mga parameter. Kapag kailangan ng approval, hindi muna isinasagawa ang tool call: lumalabas ang nakabinbing item sa interruptions. Nilalagyan ito ng pasya sa pamamagitan ng approve o reject, saka ipinapasa ang parehong RunState upang magpatuloy ang run mula sa nahintong punto.

Sa approval interface na ginagamit sa browser o telepono, itago sa server ang buong paused state. Ipadala lamang sa reviewer ang mga detalyeng awtorisado siyang makita at ang identifier ng pending request. Kapag bumalik ang pasya, kilalanin ang reviewer, tiyakin ang kaniyang pahintulot sa tawag, at tanggapin lamang ang approve o deny para sa nakatabing request. Huwag tumanggap ng kapalit na tool arguments o buong run state mula sa interface.

Gawing atomiko ang pag-angkin at pagkonsumo sa pending request bago ipagpatuloy ang run, upang hindi makapagpasimula ng dalawang pagpapatuloy ang magkasabay o paulit-ulit na pag-submit. Kung ilang tawag ang nakabinbin, ipakita at pasyahan ang bawat isa nang hiwalay. Ang approval sa isang pagpapadala ay hindi dapat sumaklaw sa ibang mensahe o sa susunod pang tawag sa parehong tool.

Ano ang mangyayari sa approve at deny?

Sa approve path, ihambing ang pasya sa nakabinbing tawag at sa mga parameter na ipinakita. Kapag nagbago ang tatanggap, nilalaman, halaga o target record, gumawa ng bagong approval request. Magtakda rin ng bisa ng pasya: kung matagal nang naghihintay ang pagbili o pagbura, muling tiyakin ang presyo o listahan ng mga target bago isagawa ang aksiyon.

Sa deny path, huwag patakbuhin ang tinanggihang tawag. Maaaring ibalik sa agent ang dahilang ligtas ibahagi upang maipaliwanag nito sa user na hindi naisagawa ang aksiyon o makapaghanda ito ng bagong panukala. Dapat dumaan muli sa gate ang bagong panukala, pati ang pagtatangkang gumamit ng ibang tool na magdudulot ng kaparehong epekto.

Kung nagka-error matapos ang approval, alamin muna ang naging resulta sa konektadong serbisyo bago muling subukan. Maaaring natuloy ang pagpapadala o pagbili kahit hindi nakatanggap ng malinaw na tugon ang agent. Ang pagkonsumo sa pending request ay pumipigil sa muling paggamit ng parehong pasya; hindi nito mag-isang ginagarantiya na minsan lamang nangyari ang panlabas na aksiyon.

Anong bakas ang dapat manatili?

Itala para sa bawat gated call ang run ID, tool call ID, uri ng aksiyon, mga parameter at bersiyong nakita ng reviewer, oras ng paghiling, pagkakakilanlan ng nagpasya, pasya at oras nito. Idagdag ang kinalabasan pagkatapos ipagpatuloy ang run: naisagawa, tinanggihan, nabigo o hindi pa matiyak. Ihiwalay ang mga secret sa audit log at limitahan ang makakakita ng sensitibong nilalaman.

Ang pinakamahalagang ugnayan sa log ay ang pagitan ng ipinakita, inaprubahan at aktuwal na ipinadalang tool call. Kapag magkakaiba ang mga bersiyong iyon, hindi sapat ang nakatalang salitang “approved” upang ipaliwanag kung ano ang pinahintulutan ng tao.

Basahin din:

• Online job offer ba o bitag? Bayad muna ang pinakamalinaw na babala
• SEC-registered pero scam pa rin? Secondary license ang dapat hanapin
• Stripe o PayPal sa Pilipinas: availability muna bago fees