ฝ่ายปฏิบัติการอยากทำหน้าดูสถานะคำสั่งซื้อให้ฝ่ายขายเปิดได้เอง ทีมอาจสร้างเว็บได้เร็วขึ้น แต่คำถามที่ต้องตอบก่อนคือ ใครแก้หน้านี้ได้ ใครดูได้ และข้อมูลที่ดึงจากระบบหลังบ้านจะไปถึงใครบ้าง
ในบันทึกการอัปเดตวันที่ 15 ตุลาคม 2569 OpenAI ระบุว่าเครื่องมือผู้ดูแล ChatGPT Sites กำลังทยอยเปิดให้ ChatGPT Enterprise บาง workspace ที่เข้าเกณฑ์ ผู้ดูแลสามารถตรวจสิทธิ์สร้างและแชร์ Sites ก่อนเปิดให้สมาชิกใช้ และการเผยแพร่ให้คนทั่วไปเข้าถึงยังปิดเป็นค่าเริ่มต้นใน Enterprise ต้องเปิดสิทธิ์แยกต่างหาก ข่าวนี้จึงเป็นเรื่องการกำกับการใช้งานมากพอกับเรื่องการสร้างเว็บ
แยกสิทธิ์สร้าง แก้ และเผยแพร่
การที่พนักงานสร้าง Site ได้ ไม่ได้แปลว่า Site นั้นต้องเปิดสาธารณะ คู่มือผู้ดูแลของ OpenAI แยกสิทธิ์ระดับ workspace และ role สำหรับการสร้างและเผยแพร่ ส่วนเจ้าของ Site กำหนดผู้ชมได้ตามความสามารถที่เปิดใช้ เช่น สมาชิกใน workspace ผู้ใช้ที่เลือก หรือสาธารณะเมื่อได้รับอนุญาต
สิทธิ์แก้ไขก็ควรให้เท่าที่จำเป็น คู่มือระบุว่า editor สามารถบันทึกการเปลี่ยนแปลง และหลังเจ้าของเผยแพร่ครั้งแรกแล้ว สามารถเผยแพร่เวอร์ชันใหม่บน URL เดิมได้ อีกทั้งเข้าถึงฐานข้อมูลที่ Site ใช้และเผยแพร่โค้ดที่ใช้ secrets หรือ storage ของ Site ได้ จึงควรกำหนดเจ้าของเนื้อหาและผู้ทบทวนก่อนเพิ่ม editor ไม่ใช่ดูเพียงว่าใครช่วยจัดหน้าเว็บได้
สำหรับตัวอย่างหน้าคำสั่งซื้อ ทีมธุรกิจอาจเริ่มจากข้อมูลทดสอบและผู้ชมวงเล็ก ให้เจ้าของกระบวนการยืนยันความหมายของสถานะ ฝ่ายไอทียืนยันสิทธิ์เข้าถึง และกำหนดว่าใครรับผิดชอบเมื่อข้อมูลผิดหรือคนดูเปลี่ยนไป นี่เป็นแนวทางใช้งานที่เราเสนอ ไม่ใช่ขั้นตอนที่ OpenAI บังคับทุกองค์กร
เว็บที่เชื่อมระบบภายในยังต้องมีสิทธิ์ของระบบนั้น
OpenAI ระบุว่า tunnels กำลังทยอยเปิดให้ Enterprise บาง workspace เพื่อให้ Site ติดต่อบริการในเครือข่ายบริษัท เช่น API สินค้าคงคลัง โดยไม่ต้องเปิดบริการนั้นบนอินเทอร์เน็ต แต่คู่มือ tunnels เตือนว่าการเชื่อมต่อไม่ใช่ระบบยืนยันตัวตนแทนบริการต้นทาง และไม่ได้กำหนดเองว่าผู้ชม Site จะเห็นข้อมูลใดหรือสั่งการอะไรได้
ผู้ดูแลต้องอนุญาตการต่อ tunnel แยกจากการเผยแพร่ Site ที่ใช้ tunnel ให้สาธารณะ ถ้าจะเปิดสาธารณะ ยังต้องมีสิทธิ์เผยแพร่ทั่วไปและสิทธิ์เฉพาะสำหรับ Site ที่ใช้ tunnel ทั้งของเจ้าของและผู้เผยแพร่ตามข้อกำหนดของ OpenAI ความเป็นส่วนตัวของ API หลังบ้านจึงไม่เท่ากับความเป็นส่วนตัวของหน้าเว็บที่เรียก API นั้น
ก่อนต่อข้อมูลจริง ให้เจ้าของระบบระบุข้อมูลและคำสั่งที่ Site จำเป็นต้องใช้ จำกัดสิทธิ์ที่บริการต้นทาง แล้วทดลองด้วยข้อมูลที่ไม่อ่อนไหวว่าผู้ชมแต่ละแบบเห็นและทำอะไรได้ คู่มือ tunnels แนะนำการทดสอบลักษณะนี้ไว้โดยตรง หากเป็นข้อมูลลูกค้า ต้องผ่านการพิจารณาสิทธิ์และข้อกำหนดภายในองค์กรก่อน
ที่เก็บและประมวลผลอยู่คนละขอบเขต
อีกส่วนของการอัปเดตคือที่ตั้งข้อมูล OpenAI ระบุว่า Site ที่สร้างใหม่ ใน workspace ที่ตั้ง data residency เป็นสหรัฐฯ หรือสหภาพยุโรป จะใช้ภูมิภาคของ workspace สำหรับ storage และ hosting ที่รองรับ แต่ถ้าตั้ง data residency เป็นภูมิภาคอื่น การตั้งค่านั้นยังไม่ครอบคลุม storage และ hosting ของ Sites ส่วน Site เดิมไม่ได้ย้ายที่ตั้งให้อัตโนมัติ อ่านขอบเขตในคู่มือ Sites
Hosting ของ Site ก็เป็นคนละเรื่องกับ inference residency ซึ่งกำหนดตำแหน่งการประมวลผลโมเดลสำหรับงานที่เข้าเกณฑ์ เอกสาร data residency ของ OpenAI อธิบายว่าการเก็บข้อมูล การรันโมเดล และข้อมูลที่วิ่งผ่านบริการภายนอกมีขอบเขตต่างกัน องค์กรจึงไม่ควรเห็นชื่อภูมิภาคใน workspace แล้วสรุปว่า Site ทุกส่วนอยู่ในภูมิภาคนั้น หรือสรุปว่าเข้ากับ PDPA โดยอัตโนมัติ
ก่อนใช้ Site กับข้อมูลจริง ให้ผู้ดูแลยืนยันว่า workspace เข้าเกณฑ์ฟีเจอร์ใด ตรวจที่ตั้งของ Site ที่สร้างใหม่และ Site เดิม แยกเส้นทางข้อมูลที่ Site เก็บออกจากข้อมูลที่ระบบภายในหรือบริการเชื่อมต่อประมวลผล แล้วให้ฝ่ายที่รับผิดชอบความเป็นส่วนตัวประเมินตามข้อมูลและสัญญาที่ใช้จริง
ทีมที่อยากเริ่มใช้ Sites ไม่จำเป็นต้องเริ่มจากเว็บใหญ่ เลือกหน้าเดียวที่ช่วยงานประจำได้จริง เช่น สถานะงานที่ไม่มีข้อมูลอ่อนไหว ทดลองกับกลุ่มผู้ชมจำกัด และจดให้ชัดว่าใครสร้าง ใครแก้ ใครเปิดเผย ใครดูแลข้อมูลต้นทาง เมื่อขอบเขตเหล่านี้ชัด การขยายการใช้งานจะมีเหตุผลกว่าการเปิดสิทธิ์ให้ทุกคนพร้อมกัน
ภาพประกอบสร้างด้วย AI สำหรับบทความนี้ ไม่ใช่ภาพผลิตภัณฑ์หรือระบบของลูกค้าจริง
