Skip to main content
AI & Technology

GitHub Copilot เริ่มใช้ค่าเริ่มต้นใหม่ บริษัทควรตรวจสิทธิ์ AI ตรงไหน

GitHub เริ่มทยอยบังคับใช้นโยบายค่าเริ่มต้นของฟีเจอร์ Copilot วันที่ 22 ถึง 26 ตุลาคม 2569 ชวนทีมไอทีตรวจค่าระดับ enterprise และ organization ก่อนตัดสินว่าใครใช้ AI ทำอะไรได้

23 ต.ค. 20269 นาทีGitHub Changelog and GitHub Docs
GitHub CopilotAI GovernanceMCPSoftware DevelopmentAccess Control
AI-generated illustration ภาพประกอบการเลือกนโยบายส่วนกลาง แฟ้มสองหน่วยงานที่ตั้งค่าต่างกัน และเอกสารทบทวนสิทธิ์
AI-generated illustration ภาพประกอบเชิงแนวคิดสร้างใหม่สำหรับบทความนี้ ไม่ใช่หน้าจอ GitHub หรือระบบของลูกค้า

ถ้าทีมพัฒนาบอกว่า "เราไม่ได้เปิดฟีเจอร์ AI เพิ่ม" ผู้จัดการยังควรถามต่อว่า ค่าที่ยังไม่ได้กำหนดและจะรับผลจากนโยบายส่วนกลางคืออะไร เพราะการไม่เคยเลือกเปิดหรือปิด อาจให้ผลต่างจากการเลือกปิดไว้อย่างชัดเจน

GitHub ประกาศเมื่อวันที่ 22 ตุลาคม 2569 ว่าเริ่มทยอยบังคับใช้นโยบายค่าเริ่มต้นสำหรับฟีเจอร์ GitHub Copilot ที่พร้อมใช้งานทั่วไป หรือ generally available (GA) บนแผน Copilot Business และ Copilot Enterprise ไปจนถึงวันที่ 26 ตุลาคม นโยบายอาจเริ่มมีผลกับแต่ละ enterprise และ organization ในคนละเวลา ตาม ประกาศเริ่มบังคับใช้นโยบายของ GitHub

สำหรับธุรกิจ งานที่ควรทำคือขอรายการค่าตั้งที่ใช้จริงพร้อมผู้รับผิดชอบ แล้วตัดสินว่าฟีเจอร์ใดเปิดได้ ฟีเจอร์ใดต้องรอทบทวน บทความนี้ตรวจแหล่งข้อมูล ณ วันที่ 23 ตุลาคม 2569 และเสนอแนวทางทำงานผ่านสถานการณ์สมมติ ไม่ใช่รายงานผลติดตั้งของ Enersys หรือลูกค้า

ค่าเริ่มต้นเปลี่ยนอะไร และไม่ควรตีความเกินตรงไหน

เมื่อรอบทยอยบังคับใช้มาถึง ฟีเจอร์ GA ที่เข้าเกณฑ์และยังมีสถานะ Unconfigured จะได้รับค่าตามนโยบายส่วนกลางที่เลือกไว้ GitHub ระบุว่าการกำหนดค่าให้ฟีเจอร์ GA ที่ยังไม่ได้ตั้งค่าในรอบนี้เกิดขึ้นครั้งเดียว การเปลี่ยนค่าเริ่มต้นในภายหลังจะไม่ย้อนเปลี่ยนค่าของฟีเจอร์ที่ตั้งไว้แล้ว หากต้องแก้ฟีเจอร์เหล่านั้น ผู้ดูแลต้องตรวจและเปลี่ยนเป็นรายรายการ พฤติกรรมที่ GitHub ระบุในประกาศวันที่ 22 ตุลาคม

ค่าที่ผู้ดูแลเลือกเปิดหรือปิดไว้อย่างชัดเจนจะคงเดิม ส่วนฟีเจอร์ preview ยังต้องเลือกเข้าร่วม หากเคยเลือกใช้ preview แล้ว เมื่อฟีเจอร์เปลี่ยนสถานะเป็น GA ค่าที่เลือกไว้ก็ยังคงเดิม ถ้ายังไม่ได้เลือกค่าไว้ ฟีเจอร์นั้นจะใช้ค่าตามนโยบายเริ่มต้นเมื่อเข้าเกณฑ์ ข้อเท็จจริงชุดนี้จึงไม่รองรับคำกล่าวว่า "Copilot เปิดทุกอย่างให้ทุกบริษัทแล้ว" และไม่ใช่หลักฐานว่าบริษัทใดมีข้อมูลรั่วไหล

ก่อนหน้านี้ ประกาศวันที่ 24 กันยายน เปิดให้ผู้ดูแลเตรียมค่า แต่ยังไม่ให้ค่าดังกล่าวเปลี่ยนการเข้าถึงทันที ข่าววันที่ 22 ตุลาคมคือจุดเริ่มบังคับใช้จริง ส่วนหน้าคู่มือบางช่วงยังใช้ถ้อยคำเตรียมก่อนเริ่มรอบนี้ การอ่านประกาศล่าสุดควบคู่กับคู่มือจึงช่วยแยกวันเริ่มใช้จากวิธีตั้งค่าได้ชัดขึ้น

เริ่มตรวจที่ระดับ enterprise แล้วตามถึงแต่ละ organization

สำหรับการอ่านบทความนี้ ให้นึกถึง enterprise เป็นระดับบริหารส่วนกลางบน GitHub และ organization เป็นระดับหน่วยงานที่รับนโยบายหรือเลือกค่าตามสิทธิ์ที่ได้รับ ระดับเหล่านี้ไม่จำเป็นต้องตรงกับแผนกในผังบริษัท

ผู้ดูแลควรเปิด AI Controls เลือก Copilot แล้วตรวจ Default policy for new features พร้อมรายการฟีเจอร์ที่ยังไม่ได้กำหนดค่า อย่าใช้ภาพหน้าจอระดับส่วนกลางเพียงภาพเดียวเป็นคำตอบแทนทุกหน่วยงาน เพราะค่าที่ใช้จริงในแต่ละ organization ขึ้นกับว่า enterprise เปิดให้หน่วยงานเลือกเองหรือไม่ และหน่วยงานตั้งค่าไว้อย่างไร

คู่มือ default availability ของ GitHub ระบุว่านโยบายนี้เปิดใช้งานเป็นค่าเริ่มต้น และอธิบายสถานะระดับ enterprise ดังนี้ ชื่อที่ปรากฏในหน้าตั้งค่าอาจใช้ถ้อยคำย่อ ให้เก็บชื่อจริงพร้อมผลที่อ่านได้จากบัญชีของบริษัท

สถานะระดับ enterprise ผลต่อฟีเจอร์ GA ที่เข้าเกณฑ์และยังไม่ได้ตั้งค่า
Enabled everywhere เปิดให้ผู้ใช้ Copilot ภายใต้ขอบเขตนั้น และ organization ปิดเองไม่ได้
Disabled everywhere ปิดไว้ และ organization เปิดเองไม่ได้
Let organizations decide ให้แต่ละ organization เลือกค่าเอง ส่วนฟีเจอร์ที่ organization ยังไม่ได้เลือกจะใช้ค่าตั้งต้นของ organization นั้น

ตารางนี้อธิบายการตัดสินใจตามนโยบาย ไม่ได้ยืนยันว่าผู้ใช้ทุกคนเห็นฟีเจอร์ครบในทันที ผู้ตรวจต้องบันทึกแผนบริการ ระดับนโยบาย สถานะของฟีเจอร์ และสิ่งที่ผู้ใช้ในขอบเขตนั้นเข้าถึงได้จริง

ในกรณี Let organizations decide หน่วยงานพัฒนาระบบภายในกับหน่วยงานที่ดูแลโครงการลูกค้าอาจมีผลต่างกัน จึงควรมีรายการแยกตาม organization ไม่ใช่บันทึกเพียงว่า "บริษัทใช้ Copilot Business"

ต้องดู MCP และ code review ด้วยหรือไม่

ต้องตรวจขอบเขตตามคู่มือด้วย นอกเหนือจากรายการบนหน้า Features & clients คู่มือรวม Copilot code review บนหน้า Agents และนโยบาย MCP servers in Copilot บนหน้า MCP ไว้ด้วย ส่วนข้อยกเว้นที่คู่มือระบุมีนโยบายจำกัดโมเดลตาม data residency หรือ FedRAMP บน GHE.com และ Store local sessions in the Cloud for Copilot CLI and VS Code ขอบเขตฟีเจอร์และข้อยกเว้น

MCP หรือ Model Context Protocol เป็นชื่อที่ทีมไอทีใช้กับการเชื่อม AI เข้ากับเครื่องมือและแหล่งข้อมูล สำหรับการตรวจรอบนี้ ต้องแยกการอนุญาตให้ใช้ MCP ใน Copilot ออกจากการติดตั้งเซิร์ฟเวอร์ตัวใดตัวหนึ่ง การเชื่อมบัญชี สิทธิ์ของบัญชี และเครื่องมือที่เปิดให้เรียก นโยบายหนึ่งรายการอยู่ในขอบเขตการปรับค่า ไม่ได้พิสูจน์ว่าเซิร์ฟเวอร์ใดติดตั้งหรือได้รับอนุญาตแล้ว

เช่นเดียวกับ code review การเปิดให้ใช้ความสามารถช่วยตรวจโค้ดไม่ควรถูกนับแทนการอนุมัติรวมโค้ดเข้าระบบจริง บริษัทควรระบุว่าใครต้องอ่านผลตรวจ ใครอนุมัติการเปลี่ยน และงานประเภทใดยังต้องให้คนตรวจตามกระบวนการเดิม

ตัวอย่างบริษัทที่มีสองหน่วยงาน ควรแบ่งงานอย่างไร

สมมติว่าบริษัทมี organization สำหรับระบบ ERP ภายใน และอีก organization สำหรับงานลูกค้า Enterprise owner มอบให้แต่ละหน่วยงานเลือกค่าฟีเจอร์เอง ทีม ERP ต้องการทดลองใช้เครื่องมือช่วยตรวจโค้ด ส่วนทีมโครงการลูกค้าต้องตรวจเงื่อนไขของโครงการก่อนใช้เครื่องมือเชื่อมข้อมูลภายนอก

คำตอบที่ผู้จัดการต้องการไม่จำเป็นต้องเลือกเปิดหรือปิดเหมือนกันทั้งบริษัท แต่ต้องระบุได้ว่าฟีเจอร์ใดอนุมัติให้ใช้กับงานอะไร และใครตัดสินใจ ตัวอย่างนี้เสนอให้แบ่งงานดังต่อไปนี้ โดยปรับตำแหน่งและผู้อนุมัติตามบริษัทจริง

ผู้รับผิดชอบในตัวอย่าง งานที่ตรวจและหลักฐานที่ส่งต่อ
Enterprise owner บันทึกค่าเริ่มต้นส่วนกลาง รายการที่กำหนดค่าเอง และรายการที่มอบให้ organization ตัดสินใจ พร้อมวันเวลา
Organization owner ตรวจฟีเจอร์ในขอบเขตตนเอง ระบุว่าแต่ละค่าเลือกเองหรือรับผลจากนโยบายระดับใด
หัวหน้าทีมพัฒนาและผู้ดูแลระบบ ทดสอบการเข้าถึงด้วยบัญชีที่ได้รับอนุญาต ในโครงการทดสอบที่ไม่มีข้อมูลจริงของลูกค้า เก็บผลที่เห็นและข้อจำกัด
ผู้รับผิดชอบข้อมูลและสัญญาโครงการ ตรวจชนิดข้อมูลที่ใช้ได้ การเชื่อมต่อที่เสนอ และเงื่อนไขของงานลูกค้าก่อนส่งเรื่องอนุมัติ
ผู้อนุมัติการใช้เครื่องมือของบริษัท ยืนยันขอบเขตที่เปิดได้ เหตุผล รายการที่ยังปิดไว้ ผู้ติดตาม และวันที่ทบทวน

สำหรับทีม ERP อาจเริ่มประเมิน code review ด้วย pull request ทดสอบ ให้ผู้พัฒนาตรวจคำแนะนำกับโค้ดจริง และเก็บตัวอย่างข้อเสนอที่รับหรือปฏิเสธพร้อมเหตุผล เกณฑ์ผ่านควรสัมพันธ์กับงาน เช่น ผู้ตรวจอธิบายได้ว่าคำแนะนำแก้ปัญหาอะไร ไม่ใช่เพียงเห็นว่าปุ่มใช้งานปรากฏแล้ว

สำหรับงานลูกค้า หากยังตรวจการเชื่อมต่อ MCP ไม่จบ ผู้ดูแลอาจกำหนดปิดฟีเจอร์ที่เกี่ยวข้องอย่างชัดเจนระหว่างรออนุมัติ เมื่อจะทดลองใช้ ให้ระบุชื่อเซิร์ฟเวอร์ บัญชีที่เชื่อม ข้อมูลที่เข้าถึงได้ และการกระทำที่ยอมให้ทำ อนุมัติแค่ชื่อผลิตภัณฑ์ยังไม่พอสำหรับกำหนดสิทธิ์ในแต่ละงาน

ขั้นตอนข้างต้นเป็นข้อเสนอด้านการจัดงาน ไม่ใช่ข้อกำหนดที่ GitHub บังคับทุกบริษัท และไม่ได้ยืนยันว่าฟีเจอร์ใดผ่านเงื่อนไขของโครงการลูกค้าแล้ว

ถ้าผลหลังเปลี่ยนไม่ตรงที่อนุมัติ ต้องกลับไปแก้ตรงไหน

เก็บค่าก่อนเปลี่ยน ขอบเขตที่อนุมัติ และผู้ตัดสินใจไว้ก่อนทดสอบ หากผู้ใช้เข้าถึงความสามารถที่ยังไม่ผ่านการทบทวน หรือค่าที่ใช้จริงในสอง organization ไม่ตรงกับที่อนุมัติไว้ ให้ผู้ดูแลตรวจนโยบายของฟีเจอร์นั้นและระดับที่บังคับใช้ แล้วแก้ค่ารายรายการตามอำนาจที่มี

อย่าคาดว่าปิดค่าเริ่มต้นส่วนกลางเพียงครั้งเดียวแล้วฟีเจอร์ที่ได้รับค่าจากรอบนี้จะปิดตามทั้งหมด เพราะประกาศล่าสุดระบุว่าค่าที่ตั้งแล้วไม่เปลี่ยนตามการแก้ default ภายหลัง การกลับไปใช้ขอบเขตที่อนุมัติจึงต้องเริ่มจากตรวจค่าจริงของฟีเจอร์ที่เกี่ยวข้อง

ถ้าหน่วยงานถูกนโยบาย enterprise บังคับไว้ ให้ส่งเรื่องถึง enterprise owner พร้อมหลักฐาน แทนการให้ผู้ใช้หาวิธีหลบนโยบาย ระหว่างรอ ให้ใช้กระบวนการตรวจโค้ดหรือเครื่องมือที่บริษัทอนุมัติอยู่แล้ว และกำหนดคนรับงานต่อ เพื่อไม่ให้ทีมขาดทางทำงาน

หลังแก้ ให้ทดสอบด้วยบัญชีในขอบเขตเดิมอีกครั้ง เก็บผลหลังแก้และผลกระทบต่องาน การปิดฟีเจอร์เป็นการปรับสิทธิ์ไปข้างหน้า หากสงสัยว่ามีการส่งข้อมูลออกไปแล้ว ต้องตรวจเส้นทางข้อมูลและหลักฐานแยกต่างหาก การเปลี่ยนค่าตั้งไม่ใช่หลักฐานว่าข้อมูลเดิมถูกลบ

คำถามที่ควรตอบได้ก่อนปิดงานทบทวน

ไม่เคยตั้งค่า Copilot ต้องรีบปิดทั้งหมดหรือไม่

เริ่มจากตรวจค่าเริ่มต้นและฟีเจอร์ที่ยังไม่ได้เลือกใน enterprise และ organization ของตนเองก่อน บริษัทที่ต้องอนุมัติฟีเจอร์ใหม่เป็นรายกรณีควรกำหนดค่าให้ตรงกระบวนการนั้น แล้วตรวจรายการที่อาจได้รับค่าจากรอบทยอยบังคับใช้แล้ว

เปลี่ยนค่าเริ่มต้นแล้ว ถือว่าย้อนกลับครบหรือไม่

ยังสรุปเช่นนั้นไม่ได้ ตามประกาศวันที่ 22 ตุลาคม การเปลี่ยน default ภายหลังไม่แก้ฟีเจอร์ที่มีค่าแล้ว ผู้ดูแลต้องตรวจรายการที่ต้องการแก้และยืนยันผลอีกครั้ง

นโยบายนี้เลือกโมเดล AI ให้ผู้ใช้ด้วยหรือไม่

GitHub แยกนโยบายค่าเริ่มต้นของฟีเจอร์ออกจากนโยบายความพร้อมใช้งานของโมเดล และการอนุญาตโมเดลก็เป็นคนละเรื่องกับโมเดลที่เลือกในแต่ละเซสชัน หากบริษัทต้องตรวจโมเดลด้วย ให้ทำเป็นรายการแยก ไม่ถือว่าการทบทวนฟีเจอร์รอบนี้ครอบคลุมแล้ว คำอธิบายนโยบายทั้งสองประเภท

ผู้จัดการควรขอเอกสารอะไรจากทีม

ขอรายการ enterprise และ organization ที่ตรวจแล้ว ค่าจริงของฟีเจอร์สำคัญ ผู้อนุมัติและขอบเขตการใช้ ผลทดสอบ สิ่งที่ยังรอพิจารณา และวันที่ตรวจซ้ำ โดยเฉพาะหน่วยงานที่ยังไม่เห็นผลของรอบทยอยบังคับใช้ ณ วันที่ตรวจ เอกสารควรตอบได้ว่าความสามารถใดได้รับอนุญาตเพราะใครตัดสินใจ และมีหลักฐานใดยืนยันผล

อ่านต่อ

AI-generated illustration ภาพประกอบเชิงแนวคิดสร้างใหม่สำหรับบทความนี้ ไม่ใช่หน้าจอผลิตภัณฑ์หรือหลักฐานค่าตั้งจริง

เลือกอ่านประเด็นที่เกี่ยวข้องกับบทความนี้

AI ที่เขียนโค้ดได้ต้องมีขอบเขต: GitHub เปิด sandbox ให้ coding agent และ Google หยุดขาย Gemini Code Assist

สัปดาห์แรกของเดือนตุลาคม 2569 GitHub เปิดให้จำกัดสิ่งที่ AI coding agent เข้าถึงได้ในเครื่องนักพัฒนา และให้องค์กรคุมค่าใช้จ่ายการรีวิวโค้ดด้วย AI ส่วน Google หยุดขาย Gemini Code Assist รุ่น Standard และ Enterprise สรุปว่าธุรกิจที่จ้างหรือมีทีมพัฒนาซอฟต์แวร์ควรถามอะไร

อ่านบทความ

เมื่อ AI เปิดเว็บและกดแทนคนได้ จุดอนุมัติต้องอยู่ตรงไหน?

OpenAI เพิ่ม computer use ให้ Agents API เมื่อ 29 กันยายน 2026 แต่การอนุมัติให้ AI เข้าเว็บไซต์ไม่ได้แปลว่าอนุมัติทุกการกระทำ ธุรกิจจึงต้องแยกขอบเขตเว็บ การลงชื่อเข้าใช้ และการยืนยันก่อนเขียนข้อมูลหรือทำธุรกรรมให้ชัด

อ่านบทความ

ก่อนต่อ AI กับ Odoo 20 ต้องเลือกก่อนว่าจะให้มันทำอะไรได้

MCP server ของ Odoo 20 ทำให้ AI ภายนอกเรียกใช้เครื่องมือในฐานข้อมูลได้ การวางสิทธิ์จึงต้องเริ่มจาก tools ที่เปิดให้เห็นและ API key ของผู้ใช้ ไม่ใช่เริ่มจากคำสั่งที่อยากให้ AI ทำ

อ่านบทความ
ดูบทความทั้งหมดใน Insights

"Empowering Innovation,
Transforming Futures."

บอกเราว่างานส่วนไหนที่คุณต้องการปรับ