Authority Architecture สำหรับ Agentic Banking: ชั้นธรรมาภิบาลบน Gemini Enterprise Agent Platform

ธนาคารกำลังนำ 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 และ endpoint ที่ได้รับอนุมัติทั่วทั้งองค์กร
• Agent Identity และ Agent Gateway เอเจนต์ทุกตัวได้รับอัตลักษณ์ของตนเอง คือ SPIFFE ID ที่ใช้สำหรับการยืนยันตัวตน การควบคุมการเข้าถึง และการตรวจสอบย้อนหลัง ทราฟฟิกทั้งหมดของเอเจนต์วิ่งผ่านเกตเวย์ซึ่งเป็นจุดบังคับใช้นโยบาย และเกตเวย์สามารถมอบการอนุมัติสิทธิ์ต่อให้ Identity-Aware Proxy, Model Armor, เอนจินนโยบาย Semantic Governance หรือบริการอนุมัติสิทธิ์ที่สร้างขึ้นเอง
• IAM Unified Access Policies และนโยบาย Semantic Governance การเข้าถึงถูกปฏิเสธโดยค่าเริ่มต้น เว้นแต่มีนโยบาย IAM อนุญาตไว้ ส่วนนโยบาย Semantic Governance ซึ่งยังอยู่ในสถานะ preview จะตรวจการเรียกเครื่องมือแต่ละครั้งเทียบกับข้อจำกัดที่เขียนเป็นภาษาอังกฤษธรรมดาและเทียบกับเจตนาของผู้ใช้ แล้วอนุญาตหรือปฏิเสธ
• Model Armor การสังเกตการณ์ และการตรวจสอบย้อนหลัง การตรวจสอบเนื้อหาทั้งขาเข้าและขาออก ข้อมูล telemetry ของเกตเวย์ผ่าน Cloud Trace การตรวจจับความผิดปกติ และบันทึกสำหรับการตรวจสอบและการเฝ้าระวัง

กล่าวโดยสรุป แพลตฟอร์มตอบคำถามที่แม่นยำและสำคัญข้อหนึ่ง คือ เอเจนต์ตัวนี้เข้าถึงและเรียกใช้บริการนี้ได้หรือไม่ อย่างปลอดภัยและตรวจสอบได้ ส่วน 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 Unified Access Policies และการอนุมัติสิทธิ์ที่เกตเวย์ ส่วนลำดับชั้นการตัดสินใจ สายการมอบอำนาจ และเกณฑ์การส่งเรื่องขึ้น เป็นหน้าที่ของธนาคารที่ต้องออกแบบเอง
• 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) แหล่งที่มาของการมอบอำนาจ ขีดจำกัดที่เครื่องอ่านได้ และ เส้นทางการส่งเรื่องขึ้น พร้อมเจ้าของที่ระบุชื่อได้ผู้ต้องรับผิดชอบ สี่สิ่งนี้รวมกันเป็น Authority Envelope ของการตัดสินใจนั้น ซึ่งเป็นแนวปฏิบัติข้อแรกในสี่ข้อของ Decision Accounting

การจัดระดับที่ใช้ได้จริงสำหรับธนาคาร

• 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 Unified Access Policies ตรึงขอบเขตอำนาจชั้นหยาบ ว่าอัตลักษณ์นั้นเรียกใช้เครื่องมือและบริการใดได้บ้างตั้งแต่ต้น การเข้าถึงถูกปฏิเสธเว้นแต่มีนโยบายอนุญาต เอเจนต์ปรับวงเงินจึงเรียกใช้ได้เฉพาะเครื่องมือปรับวงเงินเท่านั้น และเงื่อนไขยังบีบให้แคบลงได้อีกจนถึงระดับเครื่องมือแต่ละตัว IAM ตอบว่าการกระทำใด เอื้อมถึงได้ มันคือวงแหวนชั้นนอกของ Structured Decision Design

3. ตรวจขีดจำกัดการตัดสินใจที่ Agent Gateway และส่งข้อยกเว้นให้มนุษย์ IAM กำกับว่าการกระทำใดเอื้อมถึงได้ ขณะที่ขีดจำกัดเชิง ธุรกิจ เช่น มูลค่าของธุรกรรม อยู่สูงขึ้นไปอีกหนึ่งชั้น ให้ทุกการกระทำวิ่งผ่าน Agent Gateway ไปยังบริการอนุมัติสิทธิ์ที่สร้างขึ้นเองซึ่งอ่านตัวคำขอโดยตรง การอนุมัติสินเชื่อ 50,000 ปอนด์ให้ลูกค้าความเสี่ยงต่ำผ่านได้ แต่เอเจนต์ตัวเดียวกันที่พยายามอนุมัติ 500,000 ปอนด์ หรือการตัดสินใจ Tier C ใด ๆ จะถูกบล็อก และเอเจนต์ได้รับแจ้งเหตุผล บทบาทของแพลตฟอร์มจบลงตรงนั้น แพลตฟอร์มอนุญาตหรือบล็อกได้ แต่ไม่มีขั้นตอนที่พักการตัดสินใจไว้ให้บุคคลที่ระบุชื่ออนุมัติ ขั้นตอนนั้นเป็นของชั้นการตัดสินใจ การตัดสินใจที่ถูกบล็อกจะไปยังด่านที่เจ้าหน้าที่สินเชื่ออนุมัติ แก้ไข หรือปฏิเสธ แล้วลงนาม จากนั้นการตัดสินใจที่ลงนามแล้วจะถูกส่งต่อให้ระบบของธนาคารเองดำเนินการภายใต้อำนาจของเจ้าหน้าที่ผู้นั้น ไม่ใช่อำนาจของเอเจนต์ ใน Decision Accounting นี่คือ The Seal เอเจนต์เตรียมการตัดสินใจ บุคคลที่ระบุชื่อเป็นผู้ตัดสินใจ และบันทึกแสดงทั้งสองอย่าง

4. ผูกการกระทำเข้ากับเจตนาด้วย Semantic Governance ใช้ นโยบาย Semantic Governance ตรวจสอบว่าการกระทำของเอเจนต์สอดคล้องกับอาณัติด้านการปล่อยสินเชื่อ ระดับความเสี่ยงที่ยอมรับได้ และกติกาการปฏิบัติต่อลูกค้า เพื่อจับกรณีที่การกระทำ ได้รับอนุญาต จาก IAM แต่ ไม่สอดคล้อง กับเจตนา นี่คือ Aligned Action ในภาคปฏิบัติ และเป็นชั้นที่ระดับอำนาจทั้งสามมีชีวิตขึ้นมาจริง นโยบายรายระดับพร้อมตัวอย่างการตั้งค่าอยู่ด้านล่าง

5. ตรวจสอบและบันทึก ใช้ Model Armor เป็นรั้วกั้นด้านเนื้อหาทั้งขาเข้าและขาออก และใช้บันทึกกับ trace ของแพลตฟอร์มเป็นข้อมูลดิบ จากนั้นเพิ่มตัวการตัดสินใจไว้ด้านบน สำหรับทุกการกระทำใน Tier B และ Tier C ให้มี Decision Record ที่บันทึกข้อมูลนำเข้า เหตุผล ทางเลือกที่พิจารณา อำนาจที่ใช้ในการกระทำนั้น และผู้อนุมัติ โดยรันไทม์เป็นผู้เขียน ไม่ใช่เอเจนต์ เพื่อให้การตัดสินใจนั้นปกป้องได้ต่อหน้าหน่วยงานกำกับ ไม่ใช่เพียงสังเกตเห็นได้โดย SRE

6. ปิดวงจรสู่ความรับผิดชอบ ป้อนบันทึกเข้าสู่เมทริกซ์ความรับผิดชอบที่แมปทุกการตัดสินใจไปยังมนุษย์เจ้าของที่ระบุชื่อได้และเส้นทางการส่งเรื่องขึ้น นั่นคือ Auditable Impact และคือความแตกต่างระหว่าง "เรามีบันทึก" กับ "เราแสดงได้ว่าใครเป็นผู้รับผิดชอบเมื่อเอเจนต์ทำพลาด"

เมื่ออ่านรวมกัน แพลตฟอร์มให้อัตลักษณ์ การเข้าถึง การตรวจสอบความสอดคล้อง ราวกันตก และบันทึก ส่วน Authority Architecture ให้ระดับการตัดสินใจ สายการมอบอำนาจ เกณฑ์การส่งเรื่องขึ้น และแผนผังความรับผิดชอบ ซึ่งบอกเครื่องมือพื้นฐานเหล่านั้นว่าต้องบังคับใช้อะไร ทั้งสองเกื้อกูลกัน แพลตฟอร์มบังคับใช้และบันทึก Authority Architecture ตัดสินว่าอะไรถูกบังคับใช้และถูกบันทึก

นโยบาย Semantic Governance สำหรับแต่ละระดับอำนาจ

นโยบาย Semantic Governance คือกฎภาษาธรรมชาติที่เอนจินนโยบายของแพลตฟอร์มประเมินด้วย LLM ผู้ตัดสินก่อนที่การเรียกเครื่องมือจะทำงาน ฟีเจอร์นี้ยังอยู่ในสถานะ preview และคืนคำวินิจฉัยหนึ่งในสองแบบ คือ ALLOW หรือ DENY การเรียกที่ถูกปฏิเสธจะกลับไปหาเอเจนต์พร้อมเหตุผล หรือพร้อมข้อความคงที่ที่คุณตั้งไว้สำหรับลูกค้า คำวินิจฉัยสองแบบเพียงพอสำหรับสามระดับ ตราบใดที่ขั้นตอนของมนุษย์อยู่ในชั้นการตัดสินใจ ALLOW คืออำนาจของเอเจนต์เอง DENY คือเส้นขอบเขต และการปฏิเสธคือจุดเริ่มต้นของการส่งเรื่องขึ้น การเขียนอาณัติเป็นภาษาอังกฤษธรรมดายังทำให้เจ้าหน้าที่บริหารความเสี่ยงอ่านเข้าใจได้

นโยบายหนึ่งฉบับกำหนดขอบเขตได้เฉพาะเอเจนต์ตัวหนึ่งหรือเครื่องมือชุดหนึ่ง ต่อไปนี้คือหน้าตาของมันสำหรับเอเจนต์ 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 ทำหน้าที่ปรับวงเงินบัตรเครดิตภายในกรอบนโยบาย เอเจนต์ทำงานเองภายในขอบเขตตายตัว เมื่อถึงเส้นขอบ การเรียกจะถูกปฏิเสธ และการปฏิเสธนั้นคือการเริ่มส่งเรื่องขึ้น ไม่ใช่การปิดคำขอ

"อนุญาตการเพิ่มวงเงินสินเชื่อไม่เกินร้อยละ 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. Deny any increase above 20 percent, any increase for customers in risk tier high, and any change where the new limit would exceed GBP 25000: these need a credit officer approval. Deny any limit change on accounts flagged for fraud, in collections, or under a hardship arrangement." \
  --agent-response-denial-message="This limit change needs approval from a credit officer."

ตัวอย่างเอเจนต์: Payment Release Agent โครงเดียวกัน การตัดสินใจต่างกัน ALLOW ภายในช่วงมูลค่า DENY เมื่อเกินช่วงนั้นโดยมีการอนุมัติแบบสองชั้นเป็นขั้นต่อไป และ DENY เสมอสำหรับคู่ค้าที่ถูกคว่ำบาตร

"อนุญาตการปล่อยการชำระเงินขาออกไม่เกิน 50,000 ปอนด์ไปยังผู้รับเงินที่ผ่านการยืนยันมาก่อนแล้ว ปฏิเสธการชำระเงินเกิน 50,000 ปอนด์ และการชำระเงินไปยังผู้รับเงินรายใดที่เพิ่มเข้ามาภายใน 24 ชั่วโมงล่าสุด เพราะกรณีเหล่านี้ต้องได้รับการอนุมัติแบบสองชั้น ปฏิเสธการชำระเงินทุกรายการไปยังนิติบุคคลที่ถูกคว่ำบาตรหรือไปยังประเทศที่อยู่ในบัญชีต้องห้ามของธนาคาร"

การปฏิเสธ ณ เส้นขอบเขตคือจุดเริ่มต้นของเส้นทางการส่งเรื่องขึ้นของ 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 ปฏิบัติต่ออำนาจในฐานะวาระระดับคณะกรรมการโดยตัวของมันเอง เคียงข้างกลยุทธ์ ผลประกอบการทางการเงิน และความเสี่ยง ไม่ใช่รายละเอียดทางเทคนิคที่มอบหมายให้ทีมแพลตฟอร์ม

สิ่งที่หน่วยงานกำกับธนาคารเรียกร้องในเดือนตุลาคม 2026

หน่วยงานกำกับสองแห่งขยับในเดือนเดียวกัน และทั้งสองแห่งบรรยายสถาปัตยกรรมนี้ เมื่อวันที่ 7 ตุลาคม Monetary Authority of Singapore ได้ออก Guidelines on AI Risk Management ฉบับสมบูรณ์ ซึ่งใช้กับสถาบันการเงินทุกแห่งและ AI ทุกรูปแบบที่สถาบันใช้ รวมถึงระบบที่ทำงานอย่างอิสระและใช้เครื่องมือ คณะกรรมการเป็นเจ้าของระดับความเสี่ยงที่ยอมรับได้ด้าน AI สถาบันต้องจัดทำบัญชีการใช้ AI และประเมินความมีนัยสำคัญของแต่ละกรณีการใช้งาน และสถาบันยังคงต้องรับผิดชอบต่อ AI ที่บุคคลที่สามจัดหาให้ ซึ่งก็คือสถานะของเอเจนต์ธนาคารบน Gemini Enterprise Agent Platform แพลตฟอร์มเป็นของ Google แต่ความรับผิดชอบเป็นของธนาคาร แนวปฏิบัตินี้มีผลบังคับใช้วันที่ 7 ตุลาคม 2027

เมื่อวันที่ 19 ตุลาคม FCA ได้เผยแพร่ การทบทวนแนวปฏิบัติที่ดีและไม่ดีด้าน AI บริษัทที่มีกรณีการใช้งานแบบ agentic ลงทะเบียนเอเจนต์ไว้ในบัญชีส่วนกลางที่แสดงว่าใครเป็นเจ้าของเอเจนต์แต่ละตัว และเอเจนต์เข้าถึงระบบและข้อมูลใดได้บ้าง ซึ่งก็คือบัญชีอำนาจในขั้นที่ 1 ข้างต้น ในวันเดียวกัน FCA ระบุว่า จะสร้างกรอบที่เชื่อถือได้สำหรับการเงินแบบ agentic ครอบคลุม "agent identity, delegated authority, accountability and execution" อัตลักษณ์คือสิ่งที่แพลตฟอร์มมอบให้ ส่วนอำนาจที่ได้รับมอบและความรับผิดชอบคือเรื่องที่บทความนี้ว่าด้วย

ในสหภาพยุโรป AI Act ถือว่า AI ที่ใช้ประเมินความน่าเชื่อถือทางเครดิตของบุคคลเป็นระบบความเสี่ยงสูง โดยพันธกรณีมีผลตั้งแต่วันที่ 2 ธันวาคม 2027 Credit Decision Agent ใน Tier C ข้างต้นคือระบบประเภทนั้น และการออกแบบให้เสนอแนะเท่านั้นโดยให้บุคคลที่ระบุชื่อเป็นผู้ตัดสินใจขั้นสุดท้าย คือการกำกับดูแลโดยมนุษย์แบบที่ Act กำหนดให้ระบบเช่นนี้ต้องมี

เมื่อเอเจนต์เป็นของลูกค้า

ระดับต่าง ๆ ข้างต้นกำกับเอเจนต์ของธนาคารเอง ในเดือนตุลาคม คำถามเดียวกันมาจากอีกฝั่ง ลูกค้าเริ่มมอบข้อมูลเข้าสู่ระบบให้เอเจนต์ AI ที่ทำธุรกรรมบนบัญชีของตน และ CBS News รายงาน ว่า JPMorgan จะไม่ยอมให้เอเจนต์ภายนอกรายใดก็ได้เข้ามา ขณะที่ Schwab ระบุว่าได้บล็อกเอเจนต์ที่ไม่ได้รับอนุญาตแล้ว เอเจนต์ของลูกค้าตั้งคำถามเดียวกับเอเจนต์ของธนาคาร คือมันทำงานภายใต้การมอบอำนาจของใคร ภายในขีดจำกัดใด และใครรับผิดชอบหากมันโอนเงินที่ลูกค้าไม่เคยตั้งใจจะโอน การบล็อกตอบคำถามนี้ได้ชั่วคราว คำตอบที่ยั่งยืนคือ 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 และบอกเครื่องมือบังคับใช้ของแพลตฟอร์มว่าต้องบังคับใช้อะไร

ธนาคารควรมีการควบคุมอะไรบ้างก่อนนำ AI agent แบบอัตโนมัติมาใช้

ห้าอย่าง ตามลำดับนี้ บัญชีรายชื่อเอเจนต์ทุกตัว พร้อมเจ้าของและสิ่งที่มันเข้าถึงได้ ระดับอำนาจสำหรับทุกการตัดสินใจที่เอเจนต์แต่ละตัวทำ พร้อมแหล่งที่มาของการมอบอำนาจและขีดจำกัดที่เครื่องอ่านได้ ขอบเขตการเข้าถึงที่ปฏิเสธโดยค่าเริ่มต้น เพื่อให้เอเจนต์เรียกได้เฉพาะเครื่องมือที่ระดับของมันต้องใช้ ด่านมนุษย์ที่ระบุชื่อสำหรับทุกการตัดสินใจที่เกินขีดจำกัดของเอเจนต์ ซึ่งการอนุมัติจะถูกลงนามแล้วดำเนินการภายใต้อำนาจของบุคคลนั้น และ Decision Record ที่รันไทม์เป็นผู้เขียน ไม่ใช่เอเจนต์ ซึ่งหน่วยงานกำกับอ่านได้ แพลตฟอร์มอย่าง Gemini Enterprise Agent Platform มอบอัตลักษณ์ การเข้าถึง และการบันทึก ส่วนระดับ ขีดจำกัด และด่านมนุษย์เป็นหน้าที่ของธนาคารที่ต้องออกแบบเอง

บทสรุป

Gemini Enterprise Agent Govern เป็นรากฐานที่แข็งแรง และธนาคารควรสร้างต่อยอดจากมัน แพลตฟอร์มกำกับดูแลเอเจนต์ ส่วน Authority Architecture กำกับดูแล การตัดสินใจ ที่เอเจนต์เหล่านั้นทำ เมื่อรวมกัน ทั้งสองเปลี่ยนอัตลักษณ์ การเข้าถึง และการตรวจสอบย้อนหลัง ให้กลายเป็นสิ่งที่คณะกรรมการ หน่วยงานกำกับดูแล และลูกค้าไว้วางใจได้ อำนาจที่ชัดแจ้ง ขีดจำกัดที่ถูกบังคับใช้ การส่งเรื่องขึ้นที่ทำงานจริง และความรับผิดชอบที่ไม่เคยหลุดจากมือมนุษย์

หากคุณต้องการแมปภูมิทัศน์ agentic banking ของคุณเองเทียบกับ Authority Architecture และดูว่าการลงทุน AI รายการใดกำลังยกระดับการตัดสินใจได้จริง เริ่มต้นด้วย AI Value Realisation Review หรือขอเข้าร่วมไพลอตภายใต้ธรรมาภิบาล และสำหรับข้อโต้แย้งฉบับเต็ม ชุด Executive Authority Brief คือจุดที่ทั้งหมดนี้เริ่มต้น