AI Governance สำหรับทีมเล็ก: ไม่ต้องมีเอกสารร้อยหน้า แต่ต้องมีขอบเขต

เวลาพูดถึง AI governance หลายคนจะนึกถึงเอกสาร policy ยาว ๆ ตาราง risk assessment หลายหน้า คณะกรรมการหลายชุด และขั้นตอนอนุมัติที่ดูเหมาะกับองค์กรใหญ่ แต่ในชีวิตจริง ทีมเล็กจำนวนมากไม่ได้มีเวลาหรือคนพอจะเริ่มแบบนั้นครับ

ในขณะเดียวกัน ทีมเล็กก็ใช้ AI กันไปแล้ว ไม่ว่าจะใช้ช่วยเขียนอีเมล สรุปประชุม ร่าง proposal ตรวจ code ช่วยคิด content หรือจัดระเบียบ note ปัญหาจึงไม่ใช่ว่า "ควรใช้ AI ไหม" แต่คือ "จะใช้ AI อย่างไรโดยไม่ปล่อยให้ข้อมูล ลูกค้า และคุณภาพงานไหลออกนอกการควบคุม"

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

สาระตั้งต้นจากแหล่งข้อมูล

ก่อนเขียนเป็นแนวทาง ผมสรุปแก่นจากแหล่งอ้างอิงและประสบการณ์ใช้งานจริงไว้ก่อน:

1. NIST AI Risk Management Framework เน้นว่า AI risk management ต้องมีการ govern, map, measure และ manage ซึ่งแปลเป็นภาษาทีมเล็กได้ว่าต้องรู้ว่าใช้ AI ทำอะไร เสี่ยงตรงไหน วัดอย่างไร และจัดการอย่างไร
2. NIST Generative AI Profile ขยายความเสี่ยงของ generative AI เช่น output ที่ผิดแต่ดูน่าเชื่อถือ ความเสี่ยงเรื่องข้อมูล และการใช้งานเกินบริบท
3. CISA AI Data Security ชี้ว่าความปลอดภัยของข้อมูลเป็นเรื่องสำคัญตลอดวงจรของ AI ตั้งแต่ข้อมูลที่ใช้พัฒนาไปจนถึงข้อมูลที่ใส่เข้าไปตอนใช้งาน
4. OWASP Top 10 for LLM Applications 2025 ระบุความเสี่ยงอย่าง Sensitive Information Disclosure และ Excessive Agency ซึ่งเกี่ยวกับการรั่วไหลของข้อมูลและการให้สิทธิ์ AI มากเกินจำเป็น
5. สำหรับทีมเล็ก สิ่งเหล่านี้ควรถูกแปลงเป็น rule ที่สั้นพอให้จำได้และใช้ตัดสินใจได้ทันที ไม่ใช่แค่ภาษาสวย ๆ ในเอกสาร

Governance ไม่ใช่การห้าม แต่คือการทำให้ตัดสินใจง่ายขึ้น

ถ้า policy เริ่มจากคำว่า "ห้ามใช้ AI" โดยไม่มีทางเลือกอื่น งานจริงมักจะไม่หยุดครับ คนที่ต้องส่งงานให้ทันก็จะหาทางใช้ต่อผ่าน account ส่วนตัว มือถือ หรือเครื่องมือที่ทีมมองไม่เห็น กลายเป็น Shadow AI ที่ควบคุมยากกว่าเดิม

AI governance ที่ดีสำหรับทีมเล็กควรทำให้คนตัดสินใจง่ายขึ้น ไม่ใช่ทำให้ทุกคนกลัวจนไม่กล้าถาม ตัวอย่างคำถามที่ policy ควรตอบได้คือ:

1. งานนี้ใช้ AI ได้ทันทีหรือไม่
2. ข้อมูลที่กำลังจะใส่เข้า AI มีข้อมูลลูกค้า ข้อมูลส่วนบุคคล หรือข้อมูลลับหรือเปล่า
3. เครื่องมือนี้เป็นเครื่องมือที่ทีมอนุญาตแล้วหรือยัง
4. Output จาก AI จะถูกใช้เป็น draft ภายใน หรือส่งออกไปหาลูกค้า
5. ถ้าอยากใช้เครื่องมือใหม่ ต้องขอใคร และจะได้คำตอบภายในกี่วัน

ถ้า policy ตอบคำถามเหล่านี้ได้ คนจะไม่ต้องเดาเองบ่อย ๆ และเจ้าของธุรกิจก็ไม่ต้องอนุมัติทุกเรื่องแบบ case-by-case จนเหนื่อย

เริ่มจากขอบเขตข้อมูลก่อนเครื่องมือ

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

ข้อมูลที่ควรมีขอบเขตชัดเจน ได้แก่:

1. ข้อมูลส่วนบุคคลของลูกค้า พนักงาน หรือ partner
2. สัญญา ราคา margin ใบเสนอราคา และข้อมูลทางการเงิน
3. source code, secret, token, configuration และ architecture ภายใน
4. incident note, vulnerability detail, log และ ticket ที่ยังไม่ได้ลบข้อมูลอ่อนไหว
5. meeting transcript ที่มีชื่อคน แผนธุรกิจ หรือข้อมูลภายใต้ NDA

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

ตรงนี้ไม่จำเป็นต้องมี data classification ซับซ้อนในวันแรก แค่แบ่งเป็น 3 ระดับก็พอเริ่มได้:

1. Public: ข้อมูลที่เผยแพร่ได้ ใช้ AI ได้ค่อนข้างอิสระ
2. Internal: ข้อมูลภายในทีม ใช้ได้กับเครื่องมือที่ทีมอนุญาตและต้องไม่ใส่รายละเอียดลับ
3. Restricted: ข้อมูลลูกค้า สัญญา credential code สำคัญ หรือ incident detail ต้องขออนุมัติก่อนหรือห้ามใช้กับ AI ภายนอก

Policy หน้าเดียวควรมีอะไรบ้าง

ถ้าจะเริ่มให้ practical ผมแนะนำให้ทำ AI policy หน้าเดียวก่อน เนื้อหาไม่ต้องสวย แต่ต้องตอบโจทย์งานจริง โดยควรมีอย่างน้อย 6 ส่วน

1. Use case ที่ใช้ได้

เขียนให้ชัดว่างานแบบไหนใช้ AI ได้ เช่น brainstorm outline, ร่างอีเมลทั่วไป, สรุปเอกสาร public, ช่วยจัด structure report, แปลง note เป็น checklist หรือช่วยอธิบาย error message ที่ไม่มีข้อมูลระบบจริง

2. ข้อมูลที่ห้ามใส่

ระบุเป็นภาษาตรง ๆ เช่นห้ามใส่ข้อมูลลูกค้าที่ระบุตัวบุคคลได้ ห้ามใส่ secret หรือ token ห้าม upload สัญญาที่ยังไม่ได้ redact และห้ามส่ง source code หรือ log ที่มีข้อมูล production โดยไม่ตรวจ

3. เครื่องมือที่อนุญาต

ทีมควรมี approved tool list สั้น ๆ อาจเริ่มจาก 1-2 ตัวที่ผูกกับบัญชีทีม มี MFA และมีคนดูแล account ได้ ไม่ควรปล่อยให้ทุกคนใช้ account ส่วนตัวกระจัดกระจายกับเครื่องมือหลายตัวโดยไม่มี owner

4. จุดที่ต้องมีคนตรวจ

Output จาก AI ที่จะส่งลูกค้า เปลี่ยนระบบจริง ตอบประเด็น legal/security หรือกลายเป็น commitment ทางธุรกิจ ต้องมีคนตรวจเสมอ AI ช่วยร่างได้ แต่ไม่ควรเป็นคนอนุมัติสุดท้าย

5. Owner ของความเสี่ยง

แต่ละ use case ควรมีคนรับผิดชอบ เช่นเจ้าของงาน เจ้าของข้อมูล หรือคนดูแลระบบ ถ้าไม่มี owner เวลามีปัญหาจะไม่มีใครรู้ว่าต้องตัดสินใจอย่างไร

6. Exception path

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

Connector และ agent ต้องเข้มกว่า chatbot

การ copy ข้อความไปถาม chatbot มีความเสี่ยงเรื่องข้อมูลอยู่แล้ว แต่ AI tool ที่เชื่อมกับ connector หรือ agent ต้องเข้มกว่า เพราะมันอาจอ่าน Drive, email, calendar, ticket, repository หรือทำ action แทนคนได้

ในมุมนี้ หลัก least privilege ใช้ได้ตรงมาก ให้ AI เห็นเท่าที่จำเป็น ทำเท่าที่จำเป็น และเริ่มจาก read-only ก่อนเสมอ ถ้าต้องให้ทำ action จริง เช่นส่งอีเมล แก้ ticket หรือ update เอกสาร ควรมี human approval ก่อน

ตัวอย่างสิ่งที่ควรตรวจ:

1. Browser extension ขอสิทธิ์อ่านทุกหน้าเว็บหรือไม่
2. AI note taker เข้าประชุมทุกห้องโดยอัตโนมัติหรือไม่
3. Connector ขออ่านทั้ง Drive ทั้งที่ต้องใช้แค่ folder เดียวหรือไม่
4. Agent ใช้ service account ที่สิทธิ์กว้างเกินงานหรือไม่
5. มี log ให้ย้อนดูไหมว่า AI ทำอะไรหรือเข้าถึงข้อมูลใด

ถ้าอยากปูพื้นเรื่อง least privilege และการไม่เชื่อระบบโดยอัตโนมัติ อ่าน เปลี่ยนผ่านสู่ยุค Zero Trust: แนวคิดพื้นฐานที่ควรเข้าใจ และตัวอย่างการใช้ในชีวิตจริง เพราะหลักคิดนี้เอามาใช้กับ AI connector ได้ดีมาก

Checklist เริ่มต้น 14 วัน

ถ้าทีมยังไม่มีอะไรเลย ผมจะเริ่มแบบนี้:

1. สำรวจว่าในทีมใช้ AI tool อะไรอยู่จริง โดยบอกให้ชัดว่าไม่ได้เริ่มจากการจับผิด
2. เลือก approved tool หลัก 1-2 ตัว และเปิด MFA ให้เรียบร้อย
3. เขียนรายการข้อมูลที่ห้ามใส่ AI ภายนอก
4. ทำตัวอย่าง 5 use case ที่ใช้ได้ และ 5 use case ที่ต้องขออนุมัติก่อน
5. ตรวจ browser extension และ connector ที่ขอสิทธิ์กว้างผิดปกติ
6. กำหนดว่างานส่งลูกค้า งาน security งาน legal และงาน production ต้องมี human review
7. เปิดช่องทางขอ exception ที่ตอบเร็ว
8. นัด review หลังใช้งาน 2 สัปดาห์ เพื่อดูว่ากติกาติดขัดตรงไหน

สิ่งสำคัญคืออย่าทำ policy แล้วปล่อยทิ้งไว้ ทีมเล็กมีข้อดีคือปรับเร็วได้ ถ้ากติกาข้อไหนทำให้งานติดโดยไม่ลดความเสี่ยงจริง ก็ควรแก้ให้ตรงกับ workflow มากขึ้น

สรุป

AI governance สำหรับทีมเล็กไม่ใช่การเอา framework ใหญ่ ๆ มาย่อให้เหลือเอกสารสั้นลง แต่คือการแปลงหลักคิดเรื่องความเสี่ยงให้กลายเป็นขอบเขตที่คนใช้ได้จริงในงานประจำวัน

เริ่มจากข้อมูลก่อน แล้วค่อยตามด้วยเครื่องมือ จุดตรวจ owner และ exception path ถ้าทีมตอบได้ว่างานนี้ใช้ AI ได้ไหม ข้อมูลนี้ใส่ได้หรือเปล่า เครื่องมือนี้ใครดูแล และ output นี้ต้องมีคนตรวจไหม ก็ถือว่าเริ่มมี governance ที่มีประโยชน์แล้ว

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

อ่านต่อที่เกี่ยวข้อง

• ถ้าอยากเข้าใจความเสี่ยงจากการใช้ AI นอกกรอบทีม อ่าน ภัยเงียบจาก Shadow AI: เมื่อพนักงานใช้เครื่องมือ AI โดยที่ฝ่าย IT ไม่รู้ตัว
• ถ้าอยากวาง AI เป็นส่วนหนึ่งของ workflow ที่มีคนตรวจ อ่าน เมื่อ AI กลายเป็นเพื่อนร่วมงาน: วิธีใช้ให้เพิ่มคุณภาพ ไม่ใช่แค่เพิ่มความเร็ว
• ถ้าต้องการพื้นฐานเรื่องการลดสิทธิ์เกินจำเป็น อ่าน เปลี่ยนผ่านสู่ยุค Zero Trust: แนวคิดพื้นฐานที่ควรเข้าใจ และตัวอย่างการใช้ในชีวิตจริง

แหล่งอ้างอิง

• NIST: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• NIST: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
• CISA: AI Data Security - Best Practices for Securing Data Used to Train & Operate AI Systems
• OWASP Top 10 for LLM Applications 2025
• OWASP LLM02:2025 Sensitive Information Disclosure
• OWASP LLM06:2025 Excessive Agency