คำตอบสั้น: อย่าให้ AI เป็นประตูที่เปิดเข้าทุกระบบ
การเชื่อม AI กับ ERP, CRM และระบบภายในให้ปลอดภัย ควรให้ AI เรียกเฉพาะ “ความสามารถทางธุรกิจ” ที่กำหนดขอบเขตไว้ ผ่านจุดเชื่อมต่อที่องค์กรควบคุมได้ โดยให้ระบบต้นทางเป็นผู้ตรวจสิทธิ์และบังคับกฎธุรกิจเสมอ
ลำดับพื้นฐานควรเป็นดังนี้:
- ผู้ใช้ยืนยันตัวตนด้วยบัญชีองค์กร
- AI เรียกเฉพาะงานที่ได้รับอนุญาต เช่น ตรวจสต็อกหรืออ่านข้อมูลลูกค้า
- ERP, CRM หรือ API ธุรกิจตรวจสิทธิ์ของผู้ใช้อีกครั้ง
- ระบบส่งกลับเฉพาะข้อมูลที่จำเป็นต่อคำถามนั้น
- หากเป็นการแก้ไขข้อมูลหรือทำธุรกรรม ผู้ใช้ต้องตรวจสอบและยืนยันก่อน
เป้าหมายไม่ใช่การรับรองว่าจะไม่มีข้อมูลรั่วไหลเลย แต่คือการลดโอกาสเกิดเหตุ จำกัดขอบเขตความเสียหาย และทำให้องค์กรตรวจสอบ เพิกถอนสิทธิ์ หรือหยุดการเชื่อมต่อได้ทันเวลา
ให้ AI ใช้ความสามารถทางธุรกิจ ไม่ใช่ฐานข้อมูลทั้งก้อน
AI ไม่ควรได้รับรหัสผ่านฐานข้อมูล สิทธิ์ผู้ดูแลระบบ หรือช่องทางเรียกคำสั่งแบบเปิดกว้าง หากงานคือการตรวจสต็อก ระบบควรเปิดความสามารถแบบ checkInventory ที่รับรหัสสินค้าและคลังที่อนุญาต แทนการเปิดให้ AI เขียน SQL ได้เอง
ตัวอย่างความสามารถที่กำหนดขอบเขตได้ชัดเจน ได้แก่:
- สรุปข้อมูลลูกค้าที่พนักงานคนนั้นมีสิทธิ์ดู
- ตรวจจำนวนสินค้าในคลังที่ได้รับอนุญาต
- ค้นเงื่อนไขจากเอกสารที่ผู้ใช้เข้าถึงได้
- สร้างใบเสนอราคาในสถานะร่างเพื่อรอการตรวจสอบ
ERP และ CRM ยังคงเป็นระบบหลักที่เก็บข้อมูลจริงและบังคับกฎ เช่น ใครเห็นลูกค้ารายใด ใครเปลี่ยนราคาได้ หรือวงเงินเท่าใดต้องผ่านการอนุมัติ กฎสำคัญจึงไม่ควรถูกซ่อนไว้ใน Prompt เพราะข้อความสั่งงานไม่ใช่ขอบเขตความปลอดภัยที่เชื่อถือได้
- ผู้ใช้ส่งคำขอด้วยบัญชีองค์กรของตนเอง
- ทำได้
- ระบุสิ่งที่ต้องการ และยืนยันรายการก่อนทำจริง
- ทำไม่ได้
- ขยายสิทธิ์ของตนเองผ่านการพิมพ์คำสั่ง
- AI Assistantตีความคำขอ แล้วเลือกเรียก Tool ที่เปิดไว้
- ทำได้
- ร้องขอความสามารถ และเรียบเรียงผลลัพธ์เป็นบทสรุปหรือร่าง
- ทำไม่ได้
- ถือรหัสผ่านฐานข้อมูล เขียน SQL เอง หรือรับรองสิทธิ์ตัวเอง
เส้นขอบเขตความเชื่อถือ — สิ่งที่อยู่เหนือเส้นนี้ถูกโน้มน้าวด้วยข้อความได้
ชั้นเชื่อมต่อยืนยันตัวตน ตรวจ Scope จำกัดอัตรา และบันทึก Audit Log- ทำได้
- ปฏิเสธคำเรียกที่เกินขอบเขต และตัดข้อมูลที่ไม่จำเป็นออก
- ทำไม่ได้
- เชื่อว่าคำขอถูกต้องเพียงเพราะ AI เป็นผู้ส่งมา
- ERP · CRM · เอกสารภายในเก็บข้อมูลจริงและบังคับกฎธุรกิจเป็นด่านสุดท้าย
- ทำได้
- ตรวจซ้ำว่าผู้ใช้คนนั้นเห็นข้อมูลนั้นได้จริง
- ทำไม่ได้
- ถูกข้ามด้วยข้อความใน Prompt
MCP ช่วยจัดมาตรฐานการเชื่อมต่อ แต่ไม่ได้ทำให้ระบบปลอดภัยเอง
Model Context Protocol (MCP) เป็นมาตรฐานเปิดสำหรับเชื่อมแอปพลิเคชันที่ใช้โมเดลภาษาเข้ากับข้อมูลและเครื่องมือภายนอก โดยจัดรูปแบบการค้นพบและเรียกใช้ Resources, Prompts และ Tools ให้สอดคล้องกัน
MCP มีประโยชน์เมื่อองค์กรต้องการให้ AI Client หลายตัวใช้ความสามารถชุดเดียวกัน หรือต้องการแยกชั้นเชื่อมระบบออกจากแพลตฟอร์ม AI แต่ MCP ไม่ใช่ข้อบังคับและไม่ได้มาแทน API ทุกกรณี
| สถานการณ์ | แนวทางที่อาจเหมาะกว่า |
|---|---|
| ใช้ AI ระบบเดียวและมี Connector ที่ควบคุมได้อยู่แล้ว | ใช้ Connector ของแพลตฟอร์ม |
| งานมีรูปแบบชัดเจนและเชื่อม API เพียงไม่กี่รายการ | ใช้ REST API หรือ OpenAPI โดยตรง |
| ต้องการให้หลาย AI Client ใช้เครื่องมือชุดเดียวกัน | พิจารณา MCP |
| ระบบเดิมยังไม่มี API ที่ตรวจสิทธิ์และบังคับกฎธุรกิจได้ | ออกแบบ Business API ก่อน แล้วจึงเลือกวิธีเชื่อมต่อ |
ข้อสำคัญคือ MCP กำหนดวิธีสื่อสาร แต่ไม่สามารถบังคับหลักความปลอดภัยทั้งหมดในระดับโปรโตคอลได้ เอกสารข้อกำหนดจึงยังให้ผู้พัฒนาสร้างขั้นตอนยินยอม การอนุญาต การควบคุมการเข้าถึง และการคุ้มครองข้อมูลให้เหมาะกับระบบของตน
แยกการยืนยันตัวตน สิทธิ์ของแอป และสิทธิ์ระดับข้อมูล
คำว่า “มี OAuth แล้ว” ยังไม่ตอบว่าผู้ใช้ควรเห็นลูกค้าหรือเอกสารรายการใด การควบคุมควรแยกอย่างน้อยสามคำถาม:
| คำถาม | กลไกที่เกี่ยวข้อง | ตัวอย่าง |
|---|---|---|
| ผู้ใช้คนนี้คือใคร | ระบบยืนยันตัวตน เช่น OpenID Connect | ยืนยันว่าเป็นพนักงานฝ่ายขาย |
| แอปพลิเคชัน AI เรียกงานประเภทใดได้ | OAuth 2.0 และ Scope | อ่านข้อมูลลูกค้าหรือตรวจสต็อก |
| ผู้ใช้เห็นข้อมูลรายการใดได้จริง | สิทธิ์ใน ERP, CRM หรือ Business API | เห็นเฉพาะลูกค้าที่ตนรับผิดชอบ |
OAuth 2.0 ช่วยให้แอปพลิเคชันได้รับสิทธิ์แบบจำกัดโดยไม่ต้องรับรหัสผ่านของผู้ใช้ ขณะที่ OpenID Connect เพิ่มชั้นยืนยันตัวตนบน OAuth 2.0 แต่ระบบต้นทางยังต้องตรวจสิทธิ์ระดับลูกค้า สาขา แผนก คลัง หรือประเภทเอกสารทุกครั้ง
หากใช้ MCP Server เป็นตัวกลาง ไม่ควรส่ง Access Token เดิมต่อไปยังระบบปลายทางโดยไม่ตรวจ Audience และไม่แยก Credential สำหรับแต่ละ Resource Server เอกสาร MCP Security Best Practices ระบุว่า Token Passthrough เป็น Anti-pattern เพราะทำลายขอบเขตความไว้ใจและทำให้การตรวจสอบย้อนหลังคลุมเครือ
หลักควบคุมที่ควรมีตลอดเส้นทางข้อมูล
ไม่มีจำนวนชั้นที่ตายตัว องค์กรควรเลือกการควบคุมตามความอ่อนไหวของข้อมูล ผลกระทบของการทำรายการ และความสามารถของระบบเดิม
1. ส่งข้อมูลเท่าที่จำเป็น
หากงานคือสรุปสถานะลูกค้า ระบบอาจไม่จำเป็นต้องส่งเลขประจำตัวประชาชน เลขบัญชีธนาคาร ต้นทุนภายใน หรือประวัติทั้งหมดไปพร้อมกัน ชั้นเชื่อมต่อควรเลือกเฉพาะ Field ที่จำเป็น ปกปิดข้อมูลอ่อนไหว จำกัดจำนวนรายการ และกำหนดเวลาหมดอายุของผลลัพธ์ตามความเหมาะสม
การลดข้อมูลตั้งแต่ต้นทางน่าเชื่อถือกว่าการส่งทุกอย่างให้โมเดลแล้วหวังว่า Prompt จะห้ามไม่ให้เปิดเผย
2. ทำงานในบริบทของผู้ใช้จริง
หลีกเลี่ยงบัญชีกลางที่เห็นข้อมูลทั้งองค์กร AI ควรทำงานด้วยตัวตนหรือสิทธิ์ที่เชื่อมโยงกลับไปยังผู้ใช้ได้ เพื่อให้ระบบต้นทางตัดสินสิทธิ์และ Log ได้ถูกต้อง
หากจำเป็นต้องใช้ Service Account ควรจำกัดสิทธิ์ของบัญชีนั้น เพิ่มกฎระดับผู้ใช้ใน Business API และบันทึกให้ทราบว่าคำสั่งเริ่มต้นจากใคร การมีชื่อผู้ใช้ใน Log อย่างเดียวไม่ทดแทนการตรวจสิทธิ์ก่อนทำงาน
3. รักษาสิทธิ์ของเอกสารเมื่อใช้ RAG
Retrieval-augmented generation (RAG) ช่วยค้นเนื้อหาจากเอกสารหรือฐานความรู้ก่อนส่งบริบทให้โมเดล แต่การสร้าง Search Index ใหม่หมายความว่าองค์กรต้องออกแบบการรักษาสิทธิ์ของเอกสารต้นทางอย่างชัดเจน
Index ควรเก็บข้อมูลสิทธิ์หรือกลุ่มผู้ใช้ และกรองผลลัพธ์ก่อนส่งเนื้อหาให้โมเดล ไม่ใช่ค้นทุกอย่างแล้วค่อยให้ Prompt ตัดสินใจ เอกสารที่ค้นพบก็ควรถูกมองว่าเป็น Input ที่ไม่น่าเชื่อถือ เพราะอาจมีข้อความที่พยายามชักนำให้ AI เปิดเผยข้อมูลหรือเรียกเครื่องมืออื่น
อ่านภาพรวมความแตกต่างระหว่าง RAG, Fine-tuning และการสร้าง Index ได้จาก Microsoft Foundry: RAG and indexes
4. แยกสิทธิ์อ่าน สร้างร่าง และทำรายการจริง
ความเสี่ยงของการอ่านข้อมูลต่างจากการเปลี่ยนแปลงข้อมูลมาก องค์กรจึงไม่ควรรวมทุกอย่างไว้ในสิทธิ์เดียว
| ระดับการทำงาน | ตัวอย่าง | แนวทางควบคุม |
|---|---|---|
| อ่าน | ตรวจสต็อก สรุปประวัติลูกค้า | จำกัดข้อมูลตามสิทธิ์และบันทึกการใช้งาน |
| สร้างร่าง | ร่างใบเสนอราคา อีเมล หรือใบขอซื้อ | ให้ผู้ใช้ตรวจสอบก่อนบันทึกหรือส่ง |
| ทำรายการจริง | ส่งใบเสนอราคา เปลี่ยนราคา ออกใบสั่งซื้อ | ตรวจสิทธิ์ซ้ำ แสดงรายละเอียด และให้ผู้ใช้ยืนยัน |
| ผลกระทบสูง | อนุมัติเครดิต จ่ายเงิน เปลี่ยนบัญชีธนาคาร | ใช้ผู้มีอำนาจอนุมัติและการควบคุมเพิ่มเติม |
OWASP LLM06: Excessive Agency แนะนำให้จำกัดความสามารถและสิทธิ์ของส่วนเชื่อมต่อ บังคับนโยบายที่ระบบปลายทาง และให้มนุษย์อนุมัติก่อนการกระทำที่มีผลกระทบสูง
5. ตรวจนโยบายข้อมูลของทุกบริการที่อยู่ในเส้นทาง
คำว่า Enterprise AI ไม่ได้หมายถึงเงื่อนไขเดียวกันทุกผลิตภัณฑ์ ก่อนใช้ข้อมูลจริง ควรตรวจอย่างน้อยว่า Prompt, Response และไฟล์แนบถูกนำไปฝึกโมเดลหรือไม่ เก็บไว้นานเพียงใด ประมวลผลที่ใด ใครเข้าถึงประวัติได้ และบริการเสริมแต่ละตัวอยู่ภายใต้เงื่อนไขใด
ตัวอย่างเช่น เอกสารของ Microsoft Copilot ระบุเรื่องข้อมูล ความเป็นส่วนตัว และความปลอดภัย ว่า Prompt, Response และข้อมูลที่เข้าถึงผ่าน Microsoft Graph ไม่ถูกนำไปฝึก Foundation LLM และ Copilot แสดงข้อมูลองค์กรตามสิทธิ์ของผู้ใช้ อย่างไรก็ตาม ประวัติการโต้ตอบยังถูกจัดเก็บตามข้อผูกพันของ Microsoft 365 และผู้ดูแลสามารถกำกับผ่าน Microsoft Purview ได้
สิทธิ์เดิมที่กว้างเกินไปยังคงเป็นปัญหา AI อาจทำให้ผู้ใช้ค้นพบข้อมูลที่ตนมีสิทธิ์อยู่แล้วได้ง่ายขึ้น Microsoft จึงมีแนวทางให้ ตรวจและจัดระเบียบสิทธิ์ก่อนขยายการใช้งาน Copilot และหากเชื่อม Agent, MCP Server หรือบริการภายนอก ต้องตรวจ Privacy Statement, Terms และ Permission ของส่วนนั้นแยกต่างหาก
6. ตรวจสอบย้อนหลังและหยุดระบบได้
องค์กรควรตอบได้ว่าใครสั่งงาน AI เรียกความสามารถใด ติดต่อระบบไหน ใช้ข้อมูลประเภทใด ใครอนุมัติ และผลลัพธ์สำเร็จหรือไม่ แต่ Log เองก็เป็นข้อมูลสำคัญ จึงไม่ควรบันทึก Access Token, Secret หรือข้อมูลส่วนบุคคลทั้งหมดโดยอัตโนมัติ
ควรกำหนดการปกปิดข้อมูล ระยะเวลาเก็บรักษา และสิทธิ์ในการอ่าน Log พร้อมวิธีเพิกถอนสิทธิ์ ปิด Tool จำกัดอัตราการเรียก และแจ้งเตือนเมื่อเกิดพฤติกรรมผิดปกติ เช่น ดึงข้อมูลจำนวนมากหรือพยายามข้ามขอบเขตแผนกซ้ำ ๆ
ตัวอย่าง: AI ผู้ช่วยฝ่ายขายที่เชื่อม CRM และ ERP
สมมติพนักงานฝ่ายขายขอให้ AI สรุปประวัติลูกค้า ยอดค้างชำระ สินค้าที่ซื้อบ่อย และสต็อกปัจจุบัน พร้อมเตรียมร่างใบเสนอราคา กระบวนการที่ควบคุมได้ควรเป็นดังนี้:
- พนักงานเข้าสู่ระบบด้วยบัญชีองค์กร
- AI ขอเรียก Tool สำหรับอ่านข้อมูลลูกค้าและตรวจสต็อก
- ชั้นเชื่อมต่อตรวจว่า Tool และ Scope นี้ได้รับอนุญาต
- CRM และ ERP ตรวจต่อว่าผู้ใช้เห็นลูกค้า คลัง และข้อมูลแต่ละประเภทได้หรือไม่
- ระบบส่งกลับเฉพาะข้อมูลที่จำเป็น จากนั้น AI จัดทำบทสรุปและใบเสนอราคาในสถานะร่าง
- พนักงานตรวจราคา เงื่อนไข และรายการสินค้า ก่อนส่งเข้าสู่ขั้นตอนอนุมัติเดิมของบริษัท
- พนักงานเข้าสู่ระบบด้วยบัญชีองค์กรผู้บังคับกฎ: Identity Providerสถานะข้อมูลจริง: ยังไม่เขียน
- AI ขอเรียก Tool อ่านลูกค้าและตรวจสต็อกผู้บังคับกฎ: AI Assistantสถานะข้อมูลจริง: ยังไม่เขียน
- ตรวจว่า Tool และ Scope นี้ได้รับอนุญาตผู้บังคับกฎ: ชั้นเชื่อมต่อสถานะข้อมูลจริง: ยังไม่เขียน
- ตรวจซ้ำว่าผู้ใช้เห็นลูกค้าและคลังนั้นได้ผู้บังคับกฎ: ERP · CRMสถานะข้อมูลจริง: ยังไม่เขียน
- AI สรุปข้อมูลและสร้างใบเสนอราคาสถานะร่างผู้บังคับกฎ: AI Assistantสถานะข้อมูลจริง: ร่าง
จุดยืนยัน — ก่อนบรรทัดนี้ยกเลิกได้โดยไม่มีผลกับข้อมูลจริง
พนักงานตรวจราคาและเงื่อนไข แล้วส่งเข้าอนุมัติเดิมผู้บังคับกฎ: พนักงาน + Workflow อนุมัติสถานะข้อมูลจริง: เขียนแล้ว
ในกระบวนการนี้ โมเดลไม่ต้องเห็นรหัสผ่านหรือสิทธิ์ผู้ดูแลระบบ ไม่ได้เข้าถึงฐานข้อมูลทั้งหมด และไม่สามารถข้ามกฎการอนุมัติเพียงเพราะมีข้อความสั่งให้ทำ
เริ่มโครงการจาก Use Case ที่เล็กและตรวจสอบได้
องค์กรไม่จำเป็นต้องเชื่อมทุกระบบพร้อมกัน จุดเริ่มต้นที่ควบคุมง่ายกว่าคือหนึ่งกรณีใช้งาน หนึ่งกลุ่มผู้ใช้ และข้อมูลเท่าที่จำเป็น เช่น ให้ฝ่ายขายอ่านข้อมูลลูกค้าที่ตนรับผิดชอบและตรวจสต็อกแบบ Read-only
ลำดับการทำงานที่แนะนำคือ:
- เลือกงานที่มีคุณค่าชัดเจนและความเสี่ยงไม่สูง
- ระบุข้อมูลที่จำเป็น เจ้าของข้อมูล และสิทธิ์ของผู้ใช้
- เลือก Connector, API หรือ MCP จากลักษณะงานและระบบเดิม
- ทดสอบคำตอบผิด การขอข้อมูลเกินสิทธิ์ Prompt Injection และคำสั่งที่พยายามข้ามกฎ
- ตรวจคุณภาพคำตอบ สิทธิ์ และ Audit Trail ก่อนเพิ่มความสามารถสร้างร่าง
- เพิ่มการทำรายการจริงเฉพาะเมื่อมีขั้นตอนยืนยันและแผนรับมือเหตุผิดปกติ
องค์กรสามารถใช้ NIST AI Risk Management Framework เป็นกรอบช่วยกำกับ ทำความเข้าใจ วัด และจัดการความเสี่ยงตลอดวงจรชีวิต โดยกรอบนี้ไม่ได้บังคับว่าต้องใช้ MCP หรือสถาปัตยกรรมรูปแบบใด
Checklist ก่อนเชื่อม AI กับข้อมูลจริง
- มี Use Case เจ้าของกระบวนการ และผลลัพธ์ที่ต้องการชัดเจนหรือไม่
- ระบุแล้วหรือยังว่า AI ต้องเห็นข้อมูลใด และข้อมูลใดไม่ควรส่งออกมา
- ERP, CRM และระบบเอกสารมีสิทธิ์ผู้ใช้ที่ถูกต้องหรือยัง
- เลือก Connector, API หรือ MCP จากความเหมาะสมของงานหรือไม่
- แต่ละ Tool มีขอบเขตแคบและตรวจสิทธิ์ซ้ำที่ระบบต้นทางหรือไม่
- หากใช้ RAG มีการรักษาและกรองสิทธิ์ของเอกสารก่อนส่งให้โมเดลหรือไม่
- แยกสิทธิ์อ่าน สร้างร่าง และทำรายการจริงออกจากกันหรือไม่
- งานที่มีผลกระทบสูงมีผู้ใช้หรือผู้มีอำนาจยืนยันก่อนหรือไม่
- ตรวจนโยบายการฝึกโมเดล การเก็บข้อมูล พื้นที่ประมวลผล และบริการภายนอกครบหรือยัง
- มี Audit Trail, Alert และวิธีเพิกถอนสิทธิ์หรือปิดการเชื่อมต่อเมื่อเกิดเหตุหรือไม่
คำถามที่พบบ่อย
MCP จำเป็นสำหรับการเชื่อม AI กับ ERP และ CRM หรือไม่
ไม่จำเป็นทุกกรณี หากมี Connector หรือ API ที่เหมาะกับงานอยู่แล้ว วิธีเหล่านั้นอาจเรียบง่ายกว่า MCP เหมาะเมื่อองค์กรต้องการมาตรฐานกลางสำหรับให้ AI Client หลายตัวใช้ข้อมูลหรือความสามารถชุดเดียวกัน
MCP ทำให้การเชื่อมต่อปลอดภัยโดยอัตโนมัติหรือไม่
ไม่ MCP ช่วยกำหนดรูปแบบการเชื่อมต่อ แต่ระบบยังต้องตรวจตัวตน จำกัดสิทธิ์ ตรวจ Input และบังคับกฎธุรกิจเอง ความปลอดภัยขึ้นอยู่กับการออกแบบทั้งเส้นทาง ไม่ใช่ชื่อโปรโตคอล
OAuth 2.0 ป้องกันข้อมูลรั่วไหลได้ทั้งหมดหรือไม่
ไม่ OAuth 2.0 ช่วยจำกัดว่าแอปพลิเคชันเรียก Resource หรือความสามารถใดได้ แต่ไม่ได้ตัดสินโดยลำพังว่าผู้ใช้ควรเห็นลูกค้าหรือเอกสารรายการใด สิทธิ์ระดับข้อมูลยังต้องถูกตรวจโดย ERP, CRM หรือ Business API
ควรเริ่มจากกรณีใช้งานแบบใด
เริ่มจากงานอ่านข้อมูลหรือสร้างร่างที่มีขอบเขตชัดเจน วัดผลได้ และยังมีคนตรวจสอบ เช่น สรุปข้อมูลลูกค้า ตรวจสต็อก หรือร่างใบเสนอราคา ก่อนเพิ่มสิทธิ์ทำรายการที่มีผลต่อธุรกิจจริง
สรุป
การเชื่อม AI กับ ERP, CRM และระบบภายในอย่างปลอดภัยไม่ได้ขึ้นอยู่กับ MCP, OAuth 2.0 หรือบริการ Enterprise AI เพียงตัวเดียว MCP ช่วยทำให้การเชื่อมต่อเป็นมาตรฐาน OAuth 2.0 ช่วยจำกัดสิทธิ์ของแอป และระบบต้นทางยังต้องตัดสินว่าผู้ใช้เข้าถึงข้อมูลใดและทำรายการใดได้จริง
ก่อนเริ่มโครงการ ให้ตอบสี่คำถามให้ชัด: AI เห็นข้อมูลอะไร ทำงานในนามของใคร ทำอะไรได้ และองค์กรตรวจสอบหรือหยุดการทำงานได้อย่างไร หากระบบเดิมยังไม่มี API ที่บังคับกฎเหล่านี้ได้ การออกแบบชั้นเชื่อมต่อและ ระบบซอฟต์แวร์เฉพาะทาง ให้พร้อมควรมาก่อนการเลือกโมเดลหรือโปรโตคอล