ทีมพัฒนาใช้ AI ร่วมกัน: ตั้งกติกาทีม (AI Policy)

เมื่อคนในทีมเริ่มใช้ AI กันเอง สิ่งที่ตามมามักไม่ใช่ปัญหาเทคนิค แต่เป็นความไม่ตรงกัน คนหนึ่งใช้เครื่องมือ A อีกคนใช้เครื่องมือ B ด้วยบัญชีส่วนตัว บางคนแปะไฟล์ config ที่มีรหัสผ่านเข้าแชต บางคนส่ง PR ที่ AI เขียนทั้งก้อนโดยไม่ได้อ่าน ส่วนคนรีวิวก็ไม่รู้ว่าควรรีวิวละเอียดแค่ไหน บทความนี้จะพาตั้ง "กติกาทีม" หรือ AI Policy แบบสั้นที่คนอ่านจบจริง พร้อมตัวอย่าง policy หนึ่งหน้าที่นำไปปรับใช้ได้ทันที

ทำไมต้องมีกติกา และทำไมต้องสั้น

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

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

เรื่องที่ 1: เครื่องมือที่อนุญาต

กำหนดให้ชัดว่าเครื่องมือไหนใช้ได้กับงานแบบไหน แนวคิดที่ใช้ได้ดีคือแบ่งตามความอ่อนไหวของงาน

การระบุชื่อเครื่องมือให้ทำไว้ในเอกสารแนบหรือหน้า wiki ที่แก้ได้ง่าย เพราะเครื่องมือเปลี่ยนเร็ว ส่วนตัว policy ให้เขียนเป็นหลักการ

เรื่องที่ 2: ข้อมูลที่ห้ามส่ง

นี่คือส่วนที่สำคัญที่สุด และต้องเขียนเป็นรายการที่ชัดเจน ไม่ใช่แค่ "ระวังข้อมูลสำคัญ" ตัวอย่างรายการห้ามส่งเข้า AI ภายนอกทุกกรณี

• รหัสผ่าน API key token private key และไฟล์ .env ทุกชนิด
• ข้อมูลส่วนบุคคลของลูกค้าหรือผู้ใช้จริง เช่น ชื่อ เบอร์โทร เลขบัตรประชาชน ข้อมูลจาก production database
• ข้อมูลอ่อนไหว เช่น ข้อมูลสุขภาพ ข้อมูลการเงินรายบุคคล
• เอกสารที่มีชั้นความลับ สัญญา หรือข้อมูลที่ลูกค้าห้ามเปิดเผยตาม NDA
• โค้ดของลูกค้าที่สัญญาไม่อนุญาตให้ใช้เครื่องมือภายนอก

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

เรื่องที่ 3 และ 4: การรีวิวและการระบุว่าใช้ AI

หลักการที่ควรเขียนไว้บรรทัดแรกของหัวข้อนี้คือ "คนที่เปิด PR เป็นเจ้าของโค้ดทุกบรรทัด ไม่ว่าใครหรืออะไรเป็นคนพิมพ์" ประโยคเดียวนี้ตัดข้อโต้แย้งประเภท "AI เขียนนะ ไม่ใช่ผม" ไปได้ทั้งหมด

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

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

เรื่องที่ 5: เมื่อเกิดเหตุ

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

ตัวอย่าง AI Policy หนึ่งหน้า

ตัวอย่างนี้ปรับจากทีมพัฒนาเว็บขนาดเล็กถึงกลาง นำไปแก้ชื่อทีมและรายละเอียดให้เข้ากับองค์กรของคุณ และให้ฝ่ายที่ดูแลความปลอดภัยและกฎหมายตรวจก่อนประกาศใช้

# AI Policy ของทีม Web Platform (ฉบับที่ 1)
ทบทวนทุก 3 เดือน | ผู้ดูแล: หัวหน้าทีม | คำถาม: ช่อง #dev-ai

## หลักการ
- AI เป็นผู้ช่วย ไม่ใช่ผู้รับผิดชอบ คนเปิด PR เป็นเจ้าของโค้ดทุกบรรทัด
- ใช้ได้เต็มที่ภายใต้กติกานี้ ถ้าไม่แน่ใจ ถามก่อนใช้

## 1. เครื่องมือ
- งานของบริษัท/ลูกค้า: ใช้เฉพาะเครื่องมือในรายการที่อนุมัติ (ดู wiki: AI Tools) ด้วยบัญชีองค์กร
- งานที่มีข้อมูลอ่อนไหว: ใช้โมเดลภายในเท่านั้น
- บัญชีส่วนตัว: ใช้เรียนรู้ได้ ห้ามใส่โค้ด/ข้อมูล/เอกสารของบริษัท
- Agent ที่รันคำสั่งได้: รันใน dev/sandbox เท่านั้น ห้ามให้เข้าถึง production

## 2. ห้ามส่งเข้า AI ภายนอก
- secret ทุกชนิด (.env, API key, password, private key, token)
- ข้อมูลส่วนบุคคลจริงและข้อมูลจาก production
- เอกสารลับ/สัญญา/ข้อมูลภายใต้ NDA
- โค้ดลูกค้าที่สัญญาไม่อนุญาต (ดูรายชื่อโปรเจกต์ใน wiki)
ทางเลือก: ใช้ข้อมูลสมมติ, ปิดบังข้อมูล, ตัดเฉพาะโค้ดที่เกี่ยวข้อง

## 3. รีวิว
- ผู้เปิด PR ต้องอธิบายโค้ดได้ทุกส่วน และมีเทสต์สำหรับ logic ใหม่
- auth / สิทธิ์ / การเงิน / ข้อมูลส่วนบุคคล: ต้องมี senior รีวิว
- dependency ใหม่: ตรวจว่ามีอยู่จริง ดูแลอยู่ และไลเซนส์ใช้ได้
- PR ใหญ่เกินรีวิวในรอบเดียว: แบ่งก่อน

## 4. การระบุว่าใช้ AI
- ติ๊ก checkbox "ใช้ AI ช่วย" ใน PR template และระบุส่วนที่ใช้
- ข้อความ/เอกสารถึงลูกค้า: ทำตามแนวทางของแต่ละโปรเจกต์

## 5. เมื่อเกิดเหตุ
- ส่งข้อมูลต้องห้ามไปแล้ว: แจ้งหัวหน้าทีมภายในวันเดียวกัน
- secret หลุด: rotate ทันที
- ข้อมูลลูกค้าหลุด: แจ้ง DPO ตามขั้นตอนขององค์กร
- การรายงานด้วยตัวเองถือเป็นสิ่งที่ดี ไม่มีการลงโทษจากการรายงาน

ทำให้กติกาใช้ได้จริง

เอกสารที่ดีที่สุดก็ไร้ประโยชน์ถ้าไม่มีใครทำตาม เคล็ดลับที่ช่วยให้ policy มีชีวิต

• ร่างร่วมกัน ให้คนในทีมมีส่วนเสนอ จะได้กติกาที่ใช้ได้จริงและมีคนอยากทำตาม
• ให้ระบบช่วย เช่น เพิ่ม checkbox ใน PR template ตั้ง secret scanning ใน CI และใส่ .env ใน .gitignore ทุกโปรเจกต์
• สอนตอน onboard คนใหม่ควรได้อ่าน policy และเห็นตัวอย่างการใช้ AI ที่ดีในวันแรก ๆ
• ทบทวนเป็นรอบ นัดคุยสั้น ๆ ทุกไตรมาสว่าข้อไหนไม่เวิร์ก มีเครื่องมือใหม่ไหม มีเหตุอะไรเกิดขึ้นบ้าง

สรุป

• AI Policy มีไว้ให้ทีมใช้ AI ได้อย่างมั่นใจ ไม่ใช่เพื่อห้าม และควรสั้นพอที่คนอ่านจบ
• ครอบคลุมห้าเรื่อง: เครื่องมือที่อนุญาต ข้อมูลที่ห้ามส่ง การรีวิว การระบุว่าใช้ AI และขั้นตอนเมื่อเกิดเหตุ
• หลักสำคัญคือคนเปิด PR เป็นเจ้าของโค้ดทุกบรรทัด
• บอกทั้งสิ่งที่ห้ามและทางเลือกที่ทำได้ แล้วให้ระบบอย่าง PR template และ CI ช่วยบังคับใช้

ลองทำ

คัดลอกตัวอย่าง policy ด้านบนไปแก้ให้เข้ากับทีมของคุณ โดยจำกัดไม่เกินหนึ่งหน้า A4 แล้วนัดเพื่อนร่วมทีม 30 นาที ให้แต่ละคนเล่าหนึ่งสถานการณ์จริงที่เคยลังเลว่า "แบบนี้ส่งเข้า AI ได้ไหม" จากนั้นตรวจว่า policy ฉบับร่างตอบทุกสถานการณ์ได้หรือยัง ถ้ายังไม่ได้ ให้เพิ่มหรือแก้ข้อนั้นก่อนประกาศใช้