สิ่งที่ทำให้ Claude มีประโยชน์กับงานจริงขององค์กร ไม่ใช่ตัวโมเดล แต่คือสิ่งที่มันต่อถึง เมื่อ Claude อ่านไดรฟ์ของบริษัทได้ ดึงข้อมูลจากระบบภายในได้ และทำงานกับเครื่องมือที่ทีมใช้อยู่ได้ ประโยชน์เพิ่มขึ้นทันที และความเสี่ยงก็เปลี่ยนจาก "พนักงานพิมพ์อะไรลงไป" เป็น "เราอนุญาตให้มันเข้าถึงอะไรบ้าง" บทความนี้อธิบายว่า connectors กับ MCP ต่างกันอย่างไร ผู้ดูแลคุมอะไรได้ และควรอนุมัติตามลำดับไหน
connectors กับ MCP ต่างกันอย่างไร
Connectors คือการเชื่อม Claude กับบริการที่ทีมใช้อยู่ เช่น ที่เก็บไฟล์ อีเมล และแชตขององค์กร ผู้ใช้เป็นคนอนุญาตด้วยบัญชีของตัวเอง สิ่งที่ Claude เห็นจึงเท่ากับสิ่งที่คนนั้นเห็น
MCP คือมาตรฐานกลางสำหรับต่อ Claude เข้ากับเครื่องมือและข้อมูลอะไรก็ได้ รวมถึงระบบภายในที่องค์กรเขียนขึ้นเอง มองง่าย ๆ คือ connectors เป็นของสำเร็จรูปสำหรับบริการยอดนิยม ส่วน MCP คือช่องทางเปิดที่ทีมเทคนิคต่อเองได้ ทั้งสองอย่างให้ผลเหมือนกันในมุมความเสี่ยง คือเป็นการมอบสิทธิ์เข้าถึงข้อมูลจริง
ผู้ดูแลคุมอะไรได้
ระดับบัญชีองค์กร ตั้งแต่แผน Team ขึ้นไป ผู้ดูแลมีเครื่องมือควบคุม connectors ทั้งแบบที่เชื่อมจากระยะไกลและแบบที่รันบนเครื่อง จึงกำหนดได้ว่าทั้งองค์กรต่อกับอะไรได้บ้าง ไม่ใช่ปล่อยให้พนักงานแต่ละคนตัดสินใจเอง และบนแผน Enterprise ยังจำกัดเป็นรายกลุ่มได้ด้วยว่าทีมไหนใช้ตัวไหนได้ (รายละเอียดความต่างของแผน)
ระดับ Claude Code ผู้ดูแลกำหนดผ่านนโยบายที่บังคับทุกเครื่องได้ว่า อนุญาตเซิร์ฟเวอร์ตัวไหน ห้ามตัวไหน หรือจะล็อกให้ใช้ได้เฉพาะชุดที่องค์กรเตรียมไว้เท่านั้น รวมถึงกระจายชุดเซิร์ฟเวอร์กลางให้ทุกคนพร้อมใช้โดยไม่ต้องตั้งเอง นอกจากนี้ยังจำกัดแหล่งปลั๊กอินและปิดการโหลดส่วนเสริมชั่วคราวผ่านบรรทัดคำสั่งได้ (วิธีวาง managed settings)
ข้อสำคัญคือ ถ้าไม่ตั้งอะไรเลย ค่าเริ่มต้นคือความสะดวก ไม่ใช่ความปลอดภัย นักพัฒนาต่อเซิร์ฟเวอร์อะไรก็ได้ที่หาเจอบนอินเทอร์เน็ต ซึ่งเป็นช่องทางที่โค้ดและข้อมูลภายในออกนอกองค์กรได้โดยไม่มีใครเห็น
ความเสี่ยงเฉพาะของการต่อระบบ
สิทธิ์ที่กว้างเกินจำเป็น การต่อบัญชีอีเมลหรือไดรฟ์ทั้งก้อนคือการให้สิทธิ์ที่กว้างมาก ควรใช้บัญชีหรือโฟลเดอร์ที่มีขอบเขตชัดเจนแทนบัญชีหลักของพนักงาน
คำสั่งแฝงในข้อมูลที่ดึงมา เมื่อ Claude อ่านเนื้อหาจากระบบภายนอก เนื้อหานั้นอาจมีคำสั่งซ่อนอยู่เพื่อให้ทำสิ่งที่เจ้าของไม่ได้สั่ง ยิ่งต่อระบบมาก ยิ่งต้องมีคนยืนยันก่อนทำงานที่มีผลจริง (อ่านเรื่อง prompt injection)
เซิร์ฟเวอร์จากแหล่งที่ไม่รู้จัก เซิร์ฟเวอร์ MCP คือโค้ดที่รันด้วยสิทธิ์ของผู้ใช้ การติดตั้งจากแหล่งที่ไม่ได้ตรวจสอบเทียบเท่ากับติดตั้งซอฟต์แวร์ที่ไม่ผ่านฝ่าย IT
มองไม่เห็นว่าใครต่ออะไรไว้ ถ้าไม่มีทะเบียนกลาง องค์กรจะไม่รู้ว่าข้อมูลไหลออกทางไหนบ้าง ซึ่งเป็นปัญหาเดียวกับ shadow AI ในรูปแบบใหม่
ลำดับการอนุมัติที่แนะนำ
- เริ่มจากอ่านอย่างเดียว อนุมัติการเชื่อมที่อ่านข้อมูลได้แต่เขียนไม่ได้ก่อนเสมอ ความเสียหายจากการอ่านผิดน้อยกว่าการเขียนผิดมาก
- ทีละหนึ่งระบบ ทีละหนึ่งทีม ให้เห็นรูปแบบการใช้งานจริงก่อนขยาย
- งานที่เขียน ส่ง หรือลบ ต้องมีคนยืนยัน อย่างน้อยในช่วงหกเดือนแรก
- ทำทะเบียนกลาง ว่ามีเซิร์ฟเวอร์และการเชื่อมต่ออะไรอนุมัติแล้วบ้าง ใครเป็นเจ้าของ และทบทวนเมื่อไร
- ทบทวนทุกไตรมาส ปิดสิ่งที่ไม่มีใครใช้แล้ว เพราะการเชื่อมต่อที่ลืมไว้คือความเสี่ยงที่ไม่มีใครดูแล
ใครควรเป็นเจ้าของเรื่องนี้
ฝ่าย IT และผู้ดูแลความปลอดภัยเป็นเจ้าของการอนุมัติและทะเบียน ส่วนหัวหน้าทีมที่ขอใช้เป็นเจ้าของเหตุผลทางธุรกิจว่าทำไมต้องต่อระบบนั้น การให้ฝ่ายใดฝ่ายหนึ่งตัดสินใจลำพังมักจบด้วยการอนุมัติทุกอย่างหรือไม่อนุมัติอะไรเลย ซึ่งแย่ทั้งคู่
อ่านต่อ
บทความนี้อยู่ในคลัสเตอร์Claude ในองค์กร อ่านคู่กับเช็กลิสต์ก่อน IT และ Security อนุมัติและการวาง managed settings ของ Claude Code ถ้าทีมเทคนิคต้องต่อระบบภายในเอง เราสอนเรื่องนี้ในหลักสูตร MCP & AI Tool Integration และเรื่องการให้ AI ตอบจากเอกสารภายในอยู่ที่บทความ RAG