Authority Architecture สำหรับ Agentic Banking: ชั้นธรรมาภิบาลบน Gemini Enterprise Agent Platform
โดย NATARAJA Team
ธนาคารกำลังนำ agentic AI เข้าสู่จุดที่มีความสำคัญจริง ทั้งการตัดสินใจด้านสินเชื่อ การปล่อยการชำระเงิน การอายัดธุรกรรมต้องสงสัยทุจริต การคัดกรอง KYC และ AML การปรับวงเงิน และงานบริหารเงิน (treasury) ใน agentic banking (การธนาคารที่ขับเคลื่อนด้วย AI agent ที่ลงมือทำเอง) AI agent ไม่ได้เพียงให้คะแนนความเสี่ยง แต่ลงมือทำตามความเสี่ยงนั้นด้วย และจุดเปลี่ยนตรงนี้เองคือเส้นแบ่งที่ธรรมาภิบาลระดับโครงสร้างพื้นฐานสิ้นสุดลง และธรรมาภิบาลระดับการตัดสินใจเริ่มต้นขึ้น
Gemini Enterprise Agent Platform ของ Google มอบรากฐานธรรมาภิบาลที่แข็งแรงให้แก่ตัวเอเจนต์เอง ทั้งอัตลักษณ์ การเข้าถึง การตรวจสอบความสอดคล้อง และการตรวจสอบย้อนหลัง สิ่งที่วางซ้อนอยู่บนรากฐานนั้นอย่างเป็นธรรมชาติคือชั้นที่สอง นั่นคือ authority ของการตัดสินใจ เอเจนต์ตัวใดมีสิทธิ์ตัดสินใจเรื่องใดของธนาคาร ภายใต้ขีดจำกัดใด ภายใต้การมอบอำนาจของใคร และต้องรับผิดชอบต่อใคร ชั้นดังกล่าวคือหัวข้อของ Executive Authority Brief ว่าด้วย Authority Architecture และการนำชั้นนี้มาประกบกับแพลตฟอร์มคือสิ่งที่เปลี่ยนกองทัพเอเจนต์ธนาคารที่เก่งกาจให้กลายเป็นระบบที่ถูกกำกับดูแล
บทความนี้ทำสามสิ่ง หนึ่ง เปรียบเทียบ Gemini Enterprise Agent Govern กับ agentic AI framework ของ NATARAJA และกฎ 5 ข้อของ Sovereign Decision Making สอง อธิบายว่า Authority Architecture สำหรับ agentic banking หน้าตาเป็นอย่างไร และสาม แสดงตัวอย่างการนำ Authority Architecture ไปใช้งานจริง บน Gemini Enterprise Agent Govern
สิ่งที่ Gemini Enterprise Agent Govern มีให้
แพลตฟอร์มของ Google กำกับดูแลเอเจนต์ผ่านสี่เสาหลัก และทั้งสี่เสามีประโยชน์จริง
- Agent Registry แค็ตตาล็อกส่วนกลางสำหรับจัดเก็บ ค้นหา และกำกับดูแลเอเจนต์ เครื่องมือ และเซิร์ฟเวอร์ Model Context Protocol ทั่วทั้งองค์กร
- Agent Identity และ Agent Gateway เอเจนต์ทุกตัวได้รับอัตลักษณ์ของตนเอง และทราฟฟิกทั้งหมดวิ่งผ่านเกตเวย์เพื่อการเชื่อมต่อที่ยืนยันตัวตนและขับเคลื่อนด้วยนโยบาย พร้อมการมอบสิทธิ์อนุมัติผ่าน IAP, Model Armor หรือบริการอนุมัติสิทธิ์ที่สร้างขึ้นเอง
- นโยบาย IAM และเงื่อนไข IAM รวมถึงนโยบาย Semantic Governance การควบคุมการเข้าถึงแบบละเอียดว่าเอเจนต์เรียกใช้บริการใดได้บ้าง และชั้นเชิงความหมายที่ตรวจสอบว่าการกระทำของเอเจนต์สอดคล้องกับเจตนาของผู้ใช้และข้อจำกัดขององค์กร
- Model Armor และเส้นทางตรวจสอบย้อนหลัง การตรวจสอบเนื้อหาทั้งขาเข้าและขาออก รวมถึงบันทึกการเข้าถึงข้อมูลและบันทึกคำขอกับคำตอบสำหรับการตรวจสอบและการเฝ้าระวัง
กล่าวโดยสรุป แพลตฟอร์มตอบคำถามที่แม่นยำและสำคัญข้อหนึ่ง คือ เอเจนต์ตัวนี้เข้าถึงและเรียกใช้บริการนี้ได้หรือไม่ อย่างปลอดภัยและตรวจสอบได้ ส่วน Authority Architecture ตอบคำถามคู่ขนานที่บทความนี้ว่าด้วย นั่นคือ เอเจนต์ตัวนี้มีสิทธิ์ตัดสินใจเรื่องใดบ้าง
จากสิทธิ์การเข้าถึงสู่ decision authority
IAM ให้ สิทธิ์ในการเรียก API แก่เอเจนต์ ส่วน Authority Architecture ให้ อำนาจในการตัดสินใจทางการธนาคาร ทั้งสองเป็นชั้นที่เกื้อกูลกัน และการแยกสองชั้นนี้ให้ชัดคือสิ่งที่ทำให้ความรับผิดชอบยังคงชัดเจน
เอเจนต์สินเชื่ออาจมีสิทธิ์ IAM ในการเรียก approveCredit แต่คำถามด้านธรรมาภิบาลที่ธนาคารต้องตอบจริง ๆ คือ เอเจนต์อนุมัติได้ภายใต้อำนาจที่มอบหมายมาจากใคร วงเงินสูงสุดเท่าใด สำหรับลูกค้ากลุ่มความเสี่ยงระดับใด ต้องส่งเรื่องขึ้นอย่างไรเมื่อเข้าใกล้เส้นขอบเขต และมนุษย์คนใดที่ระบุชื่อได้เป็นเจ้าของผลลัพธ์หากเกิดความเสียหาย ทั้งหมดนี้ไม่ได้อยู่ใน IAM binding ใด ๆ แต่อยู่ใน Authority Architecture
นี่คือข้อโต้แย้งหลักของ agentic AI framework ธรรมาภิบาลต้องถูกออกแบบเข้าไปในตัวการตัดสินใจ ไม่ใช่เพียงในเส้นทางการเข้าถึง และมันแมปเข้ากับ กฎ 5 ข้อของ Sovereign Decision Making ได้อย่างลงตัว
- Structured Decision Design กำหนดขอบเขตอำนาจที่ชัดแจ้งและเครื่องอ่านได้ แพลตฟอร์ม บังคับใช้ ขอบเขตเหล่านั้นด้วยเงื่อนไข IAM และนโยบายอนุมัติสิทธิ์ที่เกตเวย์ ส่วนลำดับชั้นการตัดสินใจ สายการมอบอำนาจ และเกณฑ์การส่งเรื่องขึ้น เป็นหน้าที่ของธนาคารที่ต้องออกแบบเอง
- Integrated Data & Context กำกับดูแลข้อมูลนำเข้าที่การตัดสินใจตั้งอยู่ แพลตฟอร์มจัดหาการยึดโยงข้อมูลและบริบทให้ ส่วนกรอบการทำงานเป็นผู้ตัดสินว่าบริบทใดมีสถานะเป็นทางการสำหรับการตัดสินใจแต่ละเรื่อง
- Traceable Reasoning เรียกร้องร่องรอยที่ตรวจสอบได้ของข้อมูลนำเข้า การให้เหตุผล และทางเลือกที่พิจารณา บันทึกคำขอกับคำตอบคือชั้นฐานราก ส่วนการตามรอยเหตุผลในระดับการตัดสินใจวางซ้อนอยู่ด้านบน
- Aligned Action รักษาการลงมือทำให้สอดคล้องกับเจตนาและระดับความเสี่ยงที่ยอมรับได้ นโยบาย Semantic Governance เป็นเครื่องมือพื้นฐานที่แข็งแรงในจุดนี้ ส่วนกรอบการทำงานเป็นผู้นิยามว่า "สอดคล้อง" หมายความว่าอย่างไรสำหรับอาณัติทางการธนาคารแต่ละเรื่อง
- Auditable Impact ผูกผลลัพธ์กลับไปยังเจ้าของที่ต้องรับผิดชอบ เส้นทางตรวจสอบย้อนหลังเป็นข้อมูลป้อนให้ ส่วนแผนผังความรับผิดชอบเป็นหน้าที่ของธนาคารที่ต้องออกแบบ
แบบแผนนี้สอดคล้องกันตลอดสาย Gemini Enterprise Agent Govern คือระนาบของการบังคับใช้และการสังเกตการณ์ Authority Architecture คือระนาบธรรมาภิบาลการตัดสินใจที่บอกระนาบบังคับใช้ว่าต้องบังคับใช้อะไร
Authority Architecture สำหรับ agentic banking หน้าตาเป็นอย่างไร
Authority Architecture คือแผนผังที่ชัดแจ้งและถูกกำกับดูแลว่าใครมีสิทธิ์ตัดสินใจเรื่องใด สำหรับ agentic banking ให้สร้างมันขึ้นโดยยึดการตัดสินใจเป็นแกน ไม่ใช่ยึดแอปพลิเคชัน การตัดสินใจที่มีผลสืบเนื่องทุกเรื่องต้องได้รับสี่สิ่ง ได้แก่ ระดับอำนาจ (authority tier) แหล่งที่มาของการมอบอำนาจ ขีดจำกัดที่เครื่องอ่านได้ และ เส้นทางการส่งเรื่องขึ้น พร้อมเจ้าของที่ระบุชื่อได้ผู้ต้องรับผิดชอบ
การจัดระดับที่ใช้ได้จริงสำหรับธนาคาร
- Tier A: อัตโนมัติเต็มรูปแบบ ผลสืบเนื่องต่ำ ย้อนกลับได้ ปริมาณสูง เช่น การตรวจจับธุรกรรมซ้ำซ้อน การออกใบแจ้งยอด การติดธงทุจริตมูลค่าต่ำ เอเจนต์ลงมือทำเอง มนุษย์ทบทวนในภาพรวม
- Tier B: อัตโนมัติภายในขอบเขต เอเจนต์ลงมือทำภายในขีดจำกัดตายตัว และข้อยกเว้นทุกกรณีถูกส่งเรื่องขึ้น เช่น การปรับวงเงินสินเชื่อไม่เกินเกณฑ์ที่กำหนด การปล่อยการชำระเงินต่ำกว่ามูลค่าหนึ่ง การคัดกรอง KYC ซ้ำ และการระงับข้อพิพาทมาตรฐาน
- Tier C: เสนอแนะเท่านั้น ผลสืบเนื่องสูงหรือย้อนกลับไม่ได้ เช่น การอนุมัติสินเชื่อเกินเกณฑ์ การยุติความสัมพันธ์กับลูกค้า การยื่นรายงานธุรกรรมที่มีเหตุอันควรสงสัยตาม AML และการเคลื่อนย้ายเงินก้อนใหญ่ของฝ่ายบริหารเงิน เอเจนต์จัดเตรียมข้อเสนอแนะที่ตามรอยได้ มนุษย์ผู้รับผิดชอบเป็นผู้ตัดสิน
ประเด็นไม่ใช่การทำให้งานธนาคารช้าลง แต่คือการทำให้เส้นแบ่งระหว่างอำนาจอัตโนมัติกับอำนาจของมนุษย์ชัดแจ้ง ถูกบังคับใช้ และตรวจสอบได้ เพื่อว่าเมื่อเอเจนต์ลงมือทำ สายโซ่ที่ย้อนกลับไปยังผู้มอบอำนาจและเจ้าของผู้รับผิดชอบยังคงไม่ขาดตอน นี่คือสิ่งที่ Executive Authority Brief Control Note แปลงเป็นมาตรการควบคุมระดับคณะกรรมการที่บังคับใช้ได้จริง และระดับชั้นข้างต้นแท้จริงแล้วคือเส้นทาง สำหรับมุมมองข้ามอุตสาหกรรมว่า Executive Decision Platform พาการตัดสินใจจากโหมดช่วยเหลือไปสู่โหมดอัตโนมัติภายใต้ธรรมาภิบาลอย่างไร ดูคู่มือของเราว่าด้วยเส้นทางสู่การตัดสินใจอัตโนมัติ
ตัวอย่างการนำไปใช้บน Gemini Enterprise Agent Govern
ต่อไปนี้คือวิธีที่ Authority Architecture แมปลงบนแพลตฟอร์ม สถาปัตยกรรมคือการออกแบบ แพลตฟอร์มคือการบังคับใช้
1. ลงทะเบียนเอเจนต์พร้อมโปรไฟล์อำนาจ ใน Agent Registry ลงทะเบียนเอเจนต์ธนาคารแต่ละตัวพร้อมเมทาดาทาที่บันทึกระดับอำนาจของมัน ประเภทการตัดสินใจที่มันมีสิทธิ์ทำ ขีดจำกัดด้านมูลค่า เงื่อนไขความเสี่ยงของลูกค้าที่มันปฏิบัติงานภายใต้ บทบาทผู้มอบอำนาจ และปลายทางการส่งเรื่องขึ้นของมัน รีจิสทรีจึงกลายเป็นบัญชีอำนาจ (authority inventory) ของธนาคาร ไม่ใช่เพียงแค็ตตาล็อกเอเจนต์
2. ตั้งขอบเขตการเข้าถึงด้วย Agent Identity และ IAM มอบ Agent Identity ให้เอเจนต์แต่ละตัว จากนั้นใช้ นโยบาย IAM และเงื่อนไข IAM ตรึงขอบเขตอำนาจชั้นหยาบ ว่าอัตลักษณ์นั้นเรียกใช้เครื่องมือและบริการใดได้บ้างตั้งแต่ต้น เอเจนต์ปรับวงเงินเรียกใช้เครื่องมือปรับวงเงินได้ แต่เรียกเครื่องมือโอนเงินระหว่างธนาคารไม่ได้ และเงื่อนไขยังบีบการเข้าถึงให้แคบลงได้อีกตามทรัพยากร สภาพแวดล้อม หรือเวลา IAM ตอบว่าการกระทำใด เอื้อมถึงได้ มันคือวงแหวนชั้นนอกของ Structured Decision Design
3. บังคับใช้ขีดจำกัดการตัดสินใจและการส่งเรื่องขึ้นที่ Agent Gateway IAM กำกับว่าการกระทำใดเอื้อมถึงได้ ขณะที่ขีดจำกัดเชิง ธุรกิจ เช่น มูลค่าของธุรกรรม อยู่สูงขึ้นไปอีกหนึ่งชั้น ให้ทุกการกระทำวิ่งผ่าน Agent Gateway ไปยังบริการอนุมัติสิทธิ์ที่สร้างขึ้นเองซึ่งตรวจสอบตัวคำขอโดยตรง การอนุมัติสินเชื่อ 50,000 ปอนด์ให้ลูกค้าความเสี่ยงต่ำผ่านได้ แต่เอเจนต์ตัวเดียวกันที่พยายามอนุมัติ 500,000 ปอนด์ หรือการตัดสินใจ Tier C ใด ๆ จะถูกมอบต่อให้ผู้อนุมัติที่เป็นมนุษย์ผ่าน IAP ก่อนที่ธุรกรรมจะมีผล นี่คือจุดที่ขีดจำกัดด้านมูลค่าและระดับความเสี่ยงถูกตรวจสอบจริง และเป็นจุดที่การส่งเรื่องขึ้นแบบ human-in-the-loop ถูกสร้างขึ้นในรูปการมอบสิทธิ์อนุมัติ ไม่ใช่สิ่งที่คิดได้ทีหลัง
4. ผูกการกระทำเข้ากับเจตนาด้วย Semantic Governance ใช้ นโยบาย Semantic Governance ตรวจสอบว่าการกระทำของเอเจนต์สอดคล้องกับอาณัติด้านการปล่อยสินเชื่อ ระดับความเสี่ยงที่ยอมรับได้ และกติกาการปฏิบัติต่อลูกค้า เพื่อจับกรณีที่การกระทำ ได้รับอนุญาต จาก IAM แต่ ไม่สอดคล้อง กับเจตนา นี่คือ Aligned Action ในภาคปฏิบัติ และเป็นชั้นที่ระดับอำนาจทั้งสามมีชีวิตขึ้นมาจริง นโยบายรายระดับพร้อมตัวอย่างการตั้งค่าอยู่ด้านล่าง
5. ตรวจสอบและบันทึก ใช้ Model Armor เป็นราวกันตกด้านเนื้อหาทั้งขาเข้าและขาออก และใช้ เส้นทางตรวจสอบย้อนหลัง ของแพลตฟอร์มเป็นบันทึกดิบ จากนั้นวางการตามรอยระดับการตัดสินใจซ้อนขึ้นไป สำหรับทุกการกระทำใน Tier B และ Tier C ให้บันทึกข้อมูลนำเข้า การให้เหตุผล ทางเลือกที่พิจารณา และอำนาจที่การกระทำนั้นอาศัย เพื่อให้การตัดสินใจแก้ต่างต่อหน่วยงานกำกับดูแลได้ ไม่ใช่เพียงสังเกตการณ์ได้โดย SRE
6. ปิดวงจรสู่ความรับผิดชอบ ป้อนบันทึกเข้าสู่เมทริกซ์ความรับผิดชอบที่แมปทุกการตัดสินใจไปยังมนุษย์เจ้าของที่ระบุชื่อได้และเส้นทางการส่งเรื่องขึ้น นั่นคือ Auditable Impact และคือความแตกต่างระหว่าง "เรามีบันทึก" กับ "เราแสดงได้ว่าใครเป็นผู้รับผิดชอบเมื่อเอเจนต์ทำพลาด"
เมื่ออ่านรวมกัน แพลตฟอร์มให้อัตลักษณ์ การเข้าถึง การตรวจสอบความสอดคล้อง ราวกันตก และบันทึก ส่วน Authority Architecture ให้ระดับการตัดสินใจ สายการมอบอำนาจ เกณฑ์การส่งเรื่องขึ้น และแผนผังความรับผิดชอบ ซึ่งบอกเครื่องมือพื้นฐานเหล่านั้นว่าต้องบังคับใช้อะไร ทั้งสองเกื้อกูลกัน แพลตฟอร์มบังคับใช้และบันทึก Authority Architecture ตัดสินว่าอะไรถูกบังคับใช้และถูกบันทึก
นโยบาย Semantic Governance สำหรับแต่ละระดับอำนาจ
นโยบาย Semantic Governance คือกฎภาษาธรรมชาติที่เอนจินนโยบายของแพลตฟอร์มประเมินด้วย LLM ผู้ตัดสินก่อนที่การเรียกเครื่องมือจะทำงาน โดยคืนคำวินิจฉัยหนึ่งในสามแบบ ได้แก่ ALLOW, DENY หรือ PROMPT เพื่อขอการยืนยันจากมนุษย์ คำวินิจฉัยทั้งสามแมปเข้ากับระดับอำนาจทั้งสามแทบจะหนึ่งต่อหนึ่ง จึงทำให้ Semantic Governance เป็นที่ทางตามธรรมชาติสำหรับเขียนอาณัติของเอเจนต์ธนาคารด้วยถ้อยคำที่เจ้าหน้าที่บริหารความเสี่ยงอ่านเข้าใจได้
นโยบายหนึ่งฉบับกำหนดขอบเขตได้เฉพาะเอเจนต์ตัวหนึ่งหรือเครื่องมือชุดหนึ่ง และข้อจำกัดเขียนเป็นภาษาอังกฤษธรรมดาความยาวไม่เกิน 5,000 อักขระ ต่อไปนี้คือหน้าตาของมันสำหรับเอเจนต์ agentic banking จำนวนหนึ่ง ไล่ทีละระดับ
Tier A: เอเจนต์อัตโนมัติเต็มรูปแบบ
ตัวอย่างเอเจนต์: Statement and Notifications Agent ทำหน้าที่ออกใบแจ้งยอดและการแจ้งเตือนมูลค่าต่ำ อาณัติของมันกว้างแต่รัศมีความเสียหายแทบเป็นศูนย์ นโยบายจึงตรึงมันไว้ในเลนนั้นอย่างมั่นคง
"อนุญาตการออกใบแจ้งยอด สรุปยอดคงเหลือ และการแจ้งเตือนธุรกรรม สำหรับบัญชีใดก็ตามที่มีสถานะปกติ ปฏิเสธทุกการกระทำที่เคลื่อนย้ายเงิน เปลี่ยนวงเงินสินเชื่อ เปิดหรือปิดบัญชี หรือแก้ไขการจัดชั้นความเสี่ยงของลูกค้า"
gcloud beta ai semantic-governance-policies create stmt-agent-scope \
--agent=statement-notifications-agent \
--natural-language-constraint="Allow statement generation, balance summaries, and transaction notifications for any account in good standing. Deny any action that moves money, changes a credit limit, opens or closes an account, or alters a customer's risk classification."
นโยบาย Tier A ส่วนใหญ่คือ ALLOW ที่มีรั้ว DENY แข็ง ๆ ล้อมทุกสิ่งที่มีผลสืบเนื่อง เอเจนต์ไม่มีวันต้องส่งเรื่องขึ้น เพราะมันไม่มีทางเอื้อมถึงการตัดสินใจใดที่คู่ควรแก่การส่งเรื่องขึ้นได้เลย
Tier B: เอเจนต์อัตโนมัติภายในขอบเขต
ตัวอย่างเอเจนต์: Card Limit Agent ทำหน้าที่ปรับวงเงินบัตรเครดิตภายในกรอบนโยบาย จุดนี้เองที่ PROMPT พิสูจน์คุณค่าของมัน เอเจนต์ทำงานอัตโนมัติภายในขอบเขตตายตัว และส่งเรื่องขึ้นหามนุษย์เมื่อถึงเส้นขอบ
"อนุญาตการเพิ่มวงเงินสินเชื่อไม่เกินร้อยละ 20 ของวงเงินปัจจุบัน สำหรับลูกค้ากลุ่มความเสี่ยงต่ำหรือปานกลางที่ไม่มียอดค้างชำระใน 12 เดือนที่ผ่านมา ให้ขอการอนุมัติจากเจ้าหน้าที่สินเชื่อสำหรับการเพิ่มวงเงินเกินร้อยละ 20 สำหรับลูกค้ากลุ่มความเสี่ยงสูง หรือเมื่อวงเงินใหม่จะเกิน 25,000 ปอนด์ ปฏิเสธการเปลี่ยนวงเงินทุกกรณีบนบัญชีที่ถูกติดธงทุจริต อยู่ระหว่างติดตามหนี้ หรืออยู่ภายใต้มาตรการช่วยเหลือลูกหนี้"
gcloud beta ai semantic-governance-policies create card-limit-bounds \
--agent=card-limit-agent \
--natural-language-constraint="Allow credit-limit increases up to 20 percent of the current limit for customers in risk tier low or medium with no arrears in the last 12 months. Prompt for approval from a credit officer for any increase above 20 percent, for customers in risk tier high, or where the new limit would exceed GBP 25000. Deny any limit change on accounts flagged for fraud, in collections, or under a hardship arrangement."
ตัวอย่างเอเจนต์: Payment Release Agent โครงเดียวกัน การตัดสินใจต่างกัน ALLOW ภายในช่วงมูลค่า PROMPT เมื่อเกินช่วงนั้น DENY สำหรับคู่ค้าที่ถูกคว่ำบาตร
"อนุญาตการปล่อยการชำระเงินขาออกไม่เกิน 50,000 ปอนด์ไปยังผู้รับเงินที่ผ่านการยืนยันมาก่อนแล้ว ให้ขอการอนุมัติแบบสองชั้นสำหรับการชำระเงินเกิน 50,000 ปอนด์ หรือไปยังผู้รับเงินรายใดที่เพิ่มเข้ามาภายใน 24 ชั่วโมงล่าสุด ปฏิเสธการชำระเงินทุกรายการไปยังนิติบุคคลที่ถูกคว่ำบาตรหรือไปยังประเทศที่อยู่ในบัญชีต้องห้ามของธนาคาร"
คำวินิจฉัย PROMPT คือเส้นทางการส่งเรื่องขึ้นของ Authority Architecture ที่ถูกย่อไว้ในบรรทัดเดียว เอเจนต์ทำงานประจำวัน และมนุษย์ถูกดึงเข้ามา ณ เส้นขอบเขตพอดี ไม่ใช่กับทุกเรื่อง
Tier C: เอเจนต์เสนอแนะเท่านั้น
ตัวอย่างเอเจนต์: Credit Decision Agent ทำหน้าที่จัดเตรียมข้อเสนอแนะด้านสินเชื่อ หัวใจทั้งหมดของ Tier C คือเอเจนต์ต้องไม่เป็นผู้ลงนามการตัดสินใจ นโยบายจึงปฏิเสธการกระทำที่เป็นการลงนามอย่างเด็ดขาด และจำกัดเอเจนต์ไว้ที่การร่างเท่านั้น
"อนุญาตให้เอเจนต์ตัวนี้รวบรวมแฟ้มสินเชื่อ รันการตรวจสอบความสามารถในการชำระหนี้ และจัดเตรียมข้อเสนอแนะเป็นลายลักษณ์อักษร ปฏิเสธทุกการกระทำที่อนุมัติ ปฏิเสธคำขอ หรือเบิกจ่ายสินเชื่อ ทุกการตัดสินใจด้านสินเชื่อต้องลงนามโดยเจ้าหน้าที่สินเชื่อที่เป็นมนุษย์และระบุชื่อได้"
gcloud beta ai semantic-governance-policies create credit-recommend-only \
--agent=credit-decision-agent \
--natural-language-constraint="Allow this agent to assemble the credit file, run affordability checks, and prepare a written recommendation. Deny any action that approves, declines, or disburses a loan. Every credit decision must be committed by a named human credit officer."
ตัวอย่างเอเจนต์: AML Investigation Agent ทำหน้าที่ร่างรายงานธุรกรรมที่มีเหตุอันควรสงสัย การยื่นรายงานต่อหน่วยงานกำกับดูแลเป็นการกระทำของมนุษย์ เอเจนต์จึงมีสิทธิ์จัดเตรียมและเข้าคิว แต่ไม่มีวันยื่นเอง
"อนุญาตให้เอเจนต์ตัวนี้สืบสวนการแจ้งเตือน รวบรวมหลักฐาน และร่างรายงานธุรกรรมที่มีเหตุอันควรสงสัยเข้าสู่คิวทบทวนของฝ่ายกำกับการปฏิบัติงาน ปฏิเสธทุกการกระทำที่ยื่นรายงานต่อหน่วยงานกำกับดูแลหรือปิดการแจ้งเตือน การยื่นรายงานและการวินิจฉัยผลสงวนไว้สำหรับเจ้าหน้าที่กำกับการปฏิบัติงานที่ระบุชื่อได้"
นโยบาย Tier C กลับหัวค่าเริ่มต้นของ Tier A พื้นที่อัตโนมัติมีเพียงการจัดเตรียมเท่านั้น และทุกการกระทำที่มีผลสืบเนื่องเป็น deny-by-default โดยมีขั้นตอนลงนามของมนุษย์วางทับอยู่ นั่นคือสิ่งที่ทำให้คำถามว่าเป็นความผิดพลาดของผู้ปฏิบัติหรือความล้มเหลวของการออกแบบยังคงตอบได้ เพราะบันทึกแสดงว่าเอเจนต์เสนอแนะ และมนุษย์ที่ระบุชื่อได้เป็นผู้ตัดสิน
เหตุใดเรื่องนี้จึงอยู่ใน Semantic Governance ไม่ใช่ใน IAM อย่างเดียว
IAM และเกตเวย์บังคับใช้ว่าการกระทำหนึ่ง เอื้อมถึงได้หรือไม่ และ ภายในขีดจำกัดเชิงตัวเลขเท่าใด Semantic Governance เพิ่มชั้นที่อ่านได้เหมือนอาณัติ เพื่อจับการกระทำที่ถูกต้องตามเทคนิคแต่ไม่สอดคล้องกับเจตนา เช่น การชำระเงินที่อยู่ใต้ขีดจำกัดแต่กำลังมุ่งไปยังผู้รับเงินที่ไม่เข้ากับแบบแผนของลูกค้า การเขียนอาณัติเป็นภาษาอังกฤษธรรมดายังหมายความว่าผู้ที่ต้องรับผิดชอบต่อการตัดสินใจ ทั้งเจ้าหน้าที่สินเชื่อ เจ้าหน้าที่กำกับการปฏิบัติงาน และคณะกรรมการความเสี่ยง สามารถอ่านและลงนามรับรองถ้อยคำชุดเดียวกับที่เอนจินบังคับใช้ได้ตรงตัวอักษร นั่นคือ Aligned Action ที่อ่านออกได้ ไม่ใช่เพียงใช้งานได้
เหตุใดเรื่องนี้จึงสำคัญในภาคธนาคารยิ่งกว่าที่ใด
ภาคธนาคารคือจุดที่ช่องโหว่กัดลึกที่สุด เอเจนต์ที่ไม่สอดคล้องกับเจตนาไม่ได้เพียงผลิตผลลัพธ์ที่แย่ มันสามารถปล่อยสินเชื่อ ปล่อยการชำระเงิน หรือยื่นรายงานต่อหน่วยงานกำกับดูแลได้จริง
เมื่อการตัดสินใจแบบ agentic banking ก่อความเสียหาย คำถามแรกที่หน่วยงานกำกับดูแล คณะกรรมการ และศาลจะถาม คือคำถามที่ Executive Authority Brief ว่าด้วยอุบัติการณ์ AI ตั้งไว้ ความผิดพลาดของผู้ปฏิบัติ หรือความล้มเหลวของการออกแบบ หากไม่มี Authority Architecture ธนาคารตอบคำถามนี้ไม่ได้ เอเจนต์ลงมือทำก็จริง แต่ภายใต้อำนาจของใคร ภายในขีดจำกัดใด และอยู่ในหรืออยู่นอกอาณัติของมัน หากมีสถาปัตยกรรมนี้ คำตอบอยู่ในบันทึกแล้วตั้งแต่ต้น เอเจนต์ที่ถูกนิยาม ภายใต้อำนาจที่มอบหมาย อยู่ในหรืออยู่นอกขอบเขตที่ถูกบังคับใช้ ความแตกต่างข้อเดียวนี้คือสิ่งที่ชี้ขาดว่าความรับผิดชอบตกอยู่ที่ใด
แรงกดดันมีแต่จะทวีขึ้น Competitive Acceleration and Systemic Exposure บรรยายกับดักนี้ไว้ ธนาคารทุกแห่งรู้สึกว่าต้องขยาย agentic AI ให้เร็วกว่าคู่แข่ง และการแข่งขันนั้นสะสมความเสี่ยงเชิงระบบอย่างเงียบ ๆ ขณะที่อำนาจที่ไร้การกำกับดูแลแพร่กระจายไปทั่วทั้งองค์กร Authority Architecture คือวินัยที่ทำให้ธนาคารเคลื่อนที่ด้วยความเร็วเชิงแข่งขันได้โดยไม่ต้องขยายความเสี่ยงเชิงระบบตามไปด้วยในจังหวะเดียวกัน เพราะเอเจนต์ใหม่ทุกตัวสืบทอดขอบเขตที่ชัดแจ้งและถูกบังคับใช้ ไม่ใช่ขอบเขตโดยนัยที่ไร้ขีดจำกัด
นั่นคือเหตุผลเดียวกับที่ Executive Authority Brief ว่าด้วย Authority Architecture ปฏิบัติต่ออำนาจในฐานะวาระระดับคณะกรรมการโดยตัวของมันเอง เคียงข้างกลยุทธ์ ผลประกอบการทางการเงิน และความเสี่ยง ไม่ใช่รายละเอียดทางเทคนิคที่มอบหมายให้ทีมแพลตฟอร์ม
คำถามที่พบบ่อย
decision authority ใน agentic banking คืออะไร
decision authority (อำนาจการตัดสินใจ) คือสิทธิ์ที่ถูกกำกับดูแลของ AI agent ในการตัดสินใจทางการธนาคารเรื่องหนึ่งโดยเฉพาะ มันมีสิทธิ์ตัดสินใจเรื่องใด วงเงินสูงสุดเท่าใด ภายใต้การมอบอำนาจของใคร และรับผิดชอบต่อใคร สิ่งนี้แยกขาดจากสิทธิ์การเข้าถึง ธรรมาภิบาลระดับโครงสร้างพื้นฐาน (อัตลักษณ์ IAM การตรวจสอบย้อนหลัง) ควบคุมว่าเอเจนต์ เข้าถึง บริการได้หรือไม่ ส่วน decision authority ควบคุมว่า มันมีสิทธิ์ตัดสินใจเรื่องใด เมื่อเข้าถึงได้แล้ว ใน agentic banking ที่เอเจนต์ลงมือทำตามความเสี่ยงแทนที่จะเพียงให้คะแนน อำนาจนั้นต้องชัดแจ้ง ถูกบังคับใช้ในรันไทม์ และตามรอยกลับไปยังมนุษย์ผู้รับผิดชอบได้
สิทธิ์ IAM กับ decision authority ต่างกันอย่างไร
IAM ให้สิทธิ์เอเจนต์ในการเรียก API ส่วน decision authority ให้สิทธิ์ในการตัดสินใจทางธุรกิจ เอเจนต์สินเชื่ออาจมีสิทธิ์ IAM ในการเรียก approveCredit แต่คำถามด้านธรรมาภิบาล (วงเงินสูงสุดเท่าใด สำหรับลูกค้ากลุ่มความเสี่ยงใด ส่งเรื่องขึ้นอย่างไร และมนุษย์คนใดที่ระบุชื่อได้เป็นเจ้าของผลลัพธ์) อยู่ใน Authority Architecture ไม่ใช่ใน IAM binding ทั้งสองเป็นชั้นที่เกื้อกูลกัน และการแยกให้ชัดคือสิ่งที่ทำให้ความรับผิดชอบยังคงชัดเจน
AI agent ตัวใดมีสิทธิ์ตัดสินใจทางการธนาคารเรื่องใด
สิ่งนี้กำหนดโดยระดับอำนาจที่ผูกกับการตัดสินใจแต่ละเรื่อง ไม่ใช่ผูกกับแอปพลิเคชันแต่ละตัว การจัดระดับที่ใช้ได้จริงคือ Tier A (อัตโนมัติเต็มรูปแบบ) สำหรับการตัดสินใจผลสืบเนื่องต่ำ ย้อนกลับได้ ปริมาณสูง Tier B (อัตโนมัติภายในขอบเขต) ที่เอเจนต์ทำงานภายในขีดจำกัดตายตัวและส่งข้อยกเว้นขึ้นไป และ Tier C (เสนอแนะเท่านั้น) ที่เอเจนต์จัดเตรียมข้อเสนอแนะที่ตามรอยได้ และมนุษย์ที่ระบุชื่อได้เป็นผู้ลงนามการตัดสินใจ
Authority Architecture สำหรับ agentic banking คืออะไร
มันคือแผนผังที่ชัดแจ้งและถูกกำกับดูแลว่าใครมีสิทธิ์ตัดสินใจเรื่องใด การตัดสินใจที่มีผลสืบเนื่องทุกเรื่องได้รับระดับอำนาจ แหล่งที่มาของการมอบอำนาจ ขีดจำกัดที่เครื่องอ่านได้ และเส้นทางการส่งเรื่องขึ้นพร้อมเจ้าของที่ระบุชื่อได้ผู้ต้องรับผิดชอบ มันวางอยู่บนแพลตฟอร์มอย่าง Gemini Enterprise Agent Govern และบอกเครื่องมือบังคับใช้ของแพลตฟอร์มว่าต้องบังคับใช้อะไร
บทสรุป
Gemini Enterprise Agent Govern เป็นรากฐานที่แข็งแรง และธนาคารควรสร้างต่อยอดจากมัน แพลตฟอร์มกำกับดูแลเอเจนต์ ส่วน Authority Architecture กำกับดูแล การตัดสินใจ ที่เอเจนต์เหล่านั้นทำ เมื่อรวมกัน ทั้งสองเปลี่ยนอัตลักษณ์ การเข้าถึง และการตรวจสอบย้อนหลัง ให้กลายเป็นสิ่งที่คณะกรรมการ หน่วยงานกำกับดูแล และลูกค้าไว้วางใจได้ อำนาจที่ชัดแจ้ง ขีดจำกัดที่ถูกบังคับใช้ การส่งเรื่องขึ้นที่ทำงานจริง และความรับผิดชอบที่ไม่เคยหลุดจากมือมนุษย์
หากคุณต้องการแมปภูมิทัศน์ agentic banking ของคุณเองเทียบกับ Authority Architecture และดูว่าการลงทุน AI รายการใดกำลังยกระดับการตัดสินใจได้จริง เริ่มต้นด้วย AI Value Realisation Review หรือขอเข้าร่วมไพลอตภายใต้ธรรมาภิบาล และสำหรับข้อโต้แย้งฉบับเต็ม ชุด Executive Authority Brief คือจุดที่ทั้งหมดนี้เริ่มต้น