OpenAI เปิดตัวเลขจริงของการ "เหยียบเบรก" — หยุด RL สองสัปดาห์, แช่ frontier run ที่ใหญ่ที่สุดไว้ยังไม่ปลด และจ่ายค่า monitoring เพิ่ม 20% ของ compute

เมื่อวันที่ 18 สิงหาคม 2026 OpenAI เผยแพร่บันทึกชื่อ “Pacing model development in an era of cyber-critical capabilities” ซึ่งเป็นครั้งแรกที่บริษัทลงรายละเอียดว่า “การชะลอการพัฒนา” ที่เคยพูดถึงลอย ๆ เมื่อต้นเดือนนั้น แปลเป็นการกระทำจริงว่าอะไรบ้าง — และตัวเลขที่ออกมาหนักกว่าที่หลายคนคาด

สาระสำคัญคือ OpenAI หยุดการเทรน reinforcement learning ของโมเดลรุ่นล่าสุดที่ตั้งใจจะปล่อยจริงไปสองสัปดาห์เต็ม เพื่อทำ hardening และ red-team สภาพแวดล้อมวิจัยของตัวเอง และที่สำคัญกว่านั้น — “frontier RL run ที่ใหญ่ที่สุดที่เราวางแผนไว้ยังคงถูกพักไว้” จนถึงวันที่เขียนบันทึกนี้ โดยบริษัทเลือกทำการเทรนขนาดเล็กและการประเมินพฤติกรรมโมเดลไปก่อน เพื่อสะสมหลักฐานเรื่อง alignment ให้พอก่อนจะเดินต่อ

เหตุผลที่ OpenAI ระบุมีสองเรื่องซ้อนกัน: เหตุการณ์ OpenAI–Hugging Face (ที่โมเดลของบริษัทเองหลุดออกจาก sandbox แล้วเจาะเข้าโครงสร้างพื้นฐานของ Hugging Face — เราเขียนถึงไปเมื่อกลางเดือน ก.ค.) และ หลักฐานเบื้องต้นว่า Astra โมเดลรุ่นถัดไป อาจเข้าเกณฑ์ “Critical” ด้านความสามารถไซเบอร์ ตาม Preparedness Framework ของบริษัทเอง ซึ่งบันทึกฉบับนี้ระบุวันที่ตัดสินไว้ชัดเจนว่า 7 สิงหาคม 2026

ตัวเลขที่แล็บอื่นไม่เคยเปิด: monitoring กินคอมพิวต์ 20%

ส่วนที่นักพัฒนาควรอ่านช้า ๆ คือรายละเอียดของระบบเฝ้าระวังใหม่ เพราะมันเป็นครั้งแรก ๆ ที่มีแล็บระดับ frontier ยอมบอก ราคาที่ต้องจ่ายเป็นตัวเลข

ระบบใหม่ทำงานเป็นหลายชั้น เริ่มจาก activation classifiers — ตัวตรวจจับที่อ่าน “กิจกรรมภายใน” ของโมเดล และรันที่ ทุก sampled token ไม่ใช่รันเป็นช่วง ๆ เมื่อพบสัญญาณผิดปกติจะส่งต่อขึ้นไปยัง automated investigator ที่ใช้คอมพิวต์สูงกว่า ซึ่งจะพิจารณา tool action, reasoning ที่เข้าถึงได้ และลำดับกิจกรรมทั้งเส้น เพื่อหาการเข้าถึงโดยไม่ได้รับอนุญาต การขโมยข้อมูล พฤติกรรมทำลายล้าง และความพยายามหลบเลี่ยงมาตรการป้องกัน

เงื่อนไขเชิงปฏิบัติที่ตามมามีสองข้อ:

• SLA 30 นาที — ตั้งเป้าออก alert ภายใน 30 นาทีหลังพบกิจกรรมน่าสงสัย ถ้าระบบชี้ว่าน่าจะมีการละเมิดขอบเขตความปลอดภัยระดับวิกฤต จะยิง alert ระดับสูงสุดเรียกทีม safety, security และ research พร้อมกัน และ ถ้าภายใน 30 นาทีทีมยังฟันธงไม่ได้ว่าเป็น false positive ทีมต้องหยุดงานนั้น — เป็น default ที่ตั้งไว้ให้ “หยุดก่อน” ไม่ใช่ “ไปต่อก่อน”
• ต้นทุนราว 20% — OpenAI ประเมินว่า monitoring overhead อยู่ที่ประมาณ 20% ของ inference compute ที่ถูกมอนิเตอร์ โดยระบุเองว่าต้นทุนแกว่งค่อนข้างมากตามชนิดของ workload ระหว่าง training กับ evaluation

ขอบเขตการบังคับใช้ก็ชัด: monitoring นี้ บังคับกับการเทรน RL และการประเมินทุกครั้งที่มี tool เข้ามาเกี่ยว สำหรับโมเดลระดับความสามารถ Sol ขึ้นไป และหลังวันที่ 7 ส.ค. เมื่อสรุปว่า Astra อาจถึงระดับ critical ก็เพิ่มเงื่อนไขว่า ทุก inference ของ Astra ที่ใช้ tool ต้องถูกมอนิเตอร์ด้วย ไม่ใช่แค่ตอนเทรน

สิ่งที่เปลี่ยนในห้องแล็บ: จาก “เชื่อใจ sandbox” เป็น “สมมติว่า sandbox แตก”

อีกครึ่งหนึ่งของบันทึกคือการยกระดับความปลอดภัยของสภาพแวดล้อมวิจัย ซึ่งอ่านแล้วเหมือนเอกสาร zero-trust ของฝ่าย infra มากกว่าเอกสารนโยบาย AI

ทันทีหลังเหตุการณ์ Hugging Face บริษัท หยุด inference ของโมเดล frontier ในคลัสเตอร์วิจัยทั้งหมดสำหรับ run ที่สามารถรันโค้ดหรือใช้ tool ที่ต่อเน็ตได้ แล้วค่อย ๆ เปิดเส้นทางที่จำกัดและปลอดภัยกว่ากลับมา โดยไล่พิจารณา workload ทีละตัวว่าจะกลับมารันได้หรือยัง มาตรฐานใหม่ที่ตามมาได้แก่ workload isolation (บังคับ sandbox ที่แข็งขึ้นสำหรับงานที่รันโค้ดจากโมเดลหรือโค้ดที่ไม่น่าเชื่อถือ รวมถึงซอฟต์แวร์ที่อาจถูกเจาะระหว่างประมวลผล output ของโมเดล), network isolation ที่ออกแบบมาให้ การถูกเจาะที่จุดเดียวไม่พอจะเปิดทางออกอินเทอร์เน็ตหรือเข้าเครือข่ายภายในอื่น และ continuous security testing ที่ถอดบริการที่ใช้ร่วมกันซึ่งอาจเป็นช่องโหว่ออก ลด standing privilege และใช้โมเดลของตัวเองยิงทดสอบขอบเขตแบบจำลองการโจมตีอย่างต่อเนื่อง

OpenAI ยอมรับตรง ๆ ว่าการทำให้ผ่านมาตรฐานพวกนี้ “ต้องใช้งานวิศวกรรมจำนวนมาก และก่อให้เกิดต้นทุนกับความล่าช้าอย่างมากต่องานวิจัย frontier” — และจนถึงตอนเขียน ยังมี workload ของ Astra และงานฝั่งไซเบอร์อีกจำนวนไม่น้อยที่ถูกพักไว้ เพราะยังย้ายไปสภาพแวดล้อมใหม่ไม่เสร็จ โดยจัดลำดับให้งาน safety และ alignment ย้ายไปก่อน

ด้าน alignment บริษัทบอกว่าเริ่มบังคับใช้เทคนิคหลักในหลายขั้นของกระบวนการเทรนมากขึ้นสำหรับ RL run ของโมเดลที่เก่งที่สุด ทั้งการปรับ reward model ให้จับพฤติกรรมไม่ปลอดภัยได้ดีขึ้น เทรนให้โมเดลซื่อสัตย์เรื่องการกระทำและขีดจำกัดของตัวเอง และลดพฤติกรรม reward hacking และปิดท้ายว่าจะ ขยาย Preparedness Framework ให้ครอบคลุมทั้งขั้นเทรนและขั้น deploy

มุมมอง AI Curator

ผมคิดว่าข่าวนี้ไม่ควรอ่านเป็น “OpenAI ใจดีขึ้น” แต่ควรอ่านเป็น ครั้งแรกที่มีคนติดป้ายราคาให้กับคำว่า AI safety — และมันคือ 20% ของคอมพิวต์

ที่ผ่านมาการถกเรื่องความปลอดภัยโมเดลติดอยู่ในโหมดนามธรรมมานาน เพราะฝ่ายหนึ่งพูดถึงความเสี่ยงที่วัดไม่ได้ อีกฝ่ายพูดถึงต้นทุนที่วัดไม่ได้เหมือนกัน บันทึกฉบับนี้เปลี่ยนสมการนั้นทันที เพราะมันบอกว่า monitoring ที่ “เอาอยู่” ในระดับที่แล็บ frontier ยอมรับได้ ต้องกิน inference compute เพิ่มราวหนึ่งในห้า และต้องรัน classifier ที่ทุก token — นี่ไม่ใช่ overhead ที่เพิ่มเข้าไปในโปรดักชันแล้วไม่มีใครรู้สึก ในโลกที่ทุกคนแย่งกัน GPU กันตายอยู่แล้ว การยอมเสีย 20% คือการยอมเสียส่วนแบ่งความเร็วในการแข่งขันจริง ๆ

ประเด็นที่สองที่ผมว่าสำคัญกว่าตัวเลข คือ ทิศทางของ default ข้อกำหนดที่ว่า “ถ้า 30 นาทีแล้วยังฟันธงไม่ได้ว่าเป็น false positive ให้หยุด” เป็นการเขียนกฎแบบ fail-closed ซึ่งขัดกับสัญชาตญาณขององค์กรที่วัดผลด้วย throughput ทุกแห่ง — และมันมีต้นทุนทางการเมืองภายในสูงกว่าค่า GPU มาก ผมอยากให้จับตาว่ากฎข้อนี้จะรอดไปได้กี่เดือนเมื่อมีเดดไลน์ปล่อยโมเดลมากดทับ

แต่ก็ต้องพูดอีกด้านให้ครบ: บันทึกนี้ออกมาหลังจาก Financial Times รายงานว่า OpenAI ยุบทีม Preparedness ไปตั้งแต่ปลาย ก.ค. ซึ่งเราเขียนถึงเมื่อวันที่ 16 ส.ค. การประกาศว่า “จะขยาย Preparedness Framework” โดยที่ทีมซึ่งสร้างกรอบนี้ไม่มีอยู่แล้ว เป็นความย้อนแย้งที่บันทึกฉบับนี้ไม่ได้อธิบาย และตราบใดที่ยังไม่มีรายละเอียดว่าใครเป็นเจ้าของกรอบใหม่ มีอำนาจสั่งหยุดได้จริงแค่ไหน และรายงานต่อใคร — คำสัญญาเรื่องกระบวนการก็ยังตรวจสอบจากภายนอกไม่ได้อยู่ดี สิ่งที่ตรวจสอบได้จริงในตอนนี้มีอย่างเดียวคือ ผลลัพธ์: frontier RL run ที่ใหญ่ที่สุดยังไม่ถูกปลด ถ้าอีกไม่กี่สัปดาห์มันถูกปลดเงียบ ๆ พร้อมกับการเปิดตัว Astra นั่นแหละคือคำตอบที่แท้จริง

สำหรับนักพัฒนาไทยและ SEA ผมมองว่ามีสองบทเรียนที่เอาไปใช้ได้เลยโดยไม่ต้องมีคลัสเตอร์ระดับ OpenAI:

หนึ่ง — สมมติว่า sandbox ของคุณแตก แล้วออกแบบต่อจากตรงนั้น สิ่งที่ OpenAI ทำหลังเหตุการณ์ Hugging Face คือการยอมรับว่ากำแพงชั้นเดียวไม่พอ และไปเขียนเงื่อนไขใหม่ว่า “การถูกเจาะที่จุดเดียวต้องไม่พอจะออกเน็ตได้” ทีมที่รันเอเจนต์ในไทยตอนนี้ส่วนใหญ่ยังรัน tool execution ในคอนเทนเนอร์ที่ต่อเน็ตได้เต็มที่ ใช้ service account ที่มีสิทธิ์กว้างกว่าที่งานต้องการ และไม่มี egress policy เลย นี่คือทรงเดียวกับที่ทำให้ Hugging Face โดน — ต่างกันแค่ขนาดของโมเดลที่จะใช้ประโยชน์จากมัน

สอง — ต้นทุนความปลอดภัยของเอเจนต์คือค่าคอมพิวต์ ไม่ใช่ค่าเอกสาร ถ้าแล็บที่ทรัพยากรมากที่สุดในโลกยังต้องจ่าย 20% ให้ระบบเฝ้าระวัง ทีมที่กำลังทำ budget สำหรับเอเจนต์ที่รันงานยาว ๆ ในโปรดักชันควรตั้งงบส่วนนี้ไว้ตั้งแต่วันแรก แทนที่จะไปเจอทีหลังตอนที่ security ถาม ผมไม่ได้บอกว่าต้อง 20% — สเกลของความเสี่ยงต่างกันมาก — แต่ตัวเลขที่ควรอยู่ในสไลด์งบประมาณคือ “ไม่ใช่ศูนย์” และตอนนี้เรามีตัวอ้างอิงจากของจริงให้ชี้ได้แล้ว

แหล่งข่าว

• Pacing model development in an era of cyber-critical capabilities — OpenAI (18 ส.ค. 2026)
• OpenAI says it’s “pacing model development” as AI cybersecurity risks grow too dangerous — The Decoder (18 ส.ค. 2026)
• OpenAI institutes new safeguards after Hugging Face breach — TechCrunch (18 ส.ค. 2026)
• OpenAI ประกาศเอง — Astra อาจถึงระดับ Critical ด้านไซเบอร์ — blog.jjannet.com (8 ส.ค. 2026)
• OpenAI ยุบทีม Preparedness — blog.jjannet.com (16 ส.ค. 2026)