เริ่มกำกับ Generative AI ในองค์กรไทย: ตั้งเจ้าของก่อนซื้อเครื่องมือเพิ่ม

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

ความจำเป็นของกระบวนการนี้เห็นได้จาก ผลสำรวจองค์กรไทยของ NECTEC ซึ่งครอบคลุม 574 แห่ง: มิติธรรมาภิบาลได้คะแนนความพร้อม 28.9% ต่ำที่สุดในห้ามิติ เทียบกับมิติข้อมูลและโครงสร้างพื้นฐานที่ได้ 51.0%; 46.2% ยังไม่มีการประเมินความเสี่ยงหรือกำกับดูแล AI และในกลุ่มองค์กรที่ใช้ AI แล้ว 86.4% ยังระบุผลลัพธ์ได้ไม่ชัด เพราะไม่เคยวัดผลหรืออยู่ระหว่างเก็บข้อมูล ตัวเลขสำรวจครอบคลุม AI หลายประเภท ไม่ใช่อัตราความล้มเหลวของ Generative AI แต่ทำให้เห็นเหตุผลที่ต้องรู้ทั้งผู้รับผิดชอบ ความเสี่ยง และผลของงานก่อนขยายการใช้

ตั้งเจ้าของงานและอำนาจตัดสินใจ

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

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

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

• อนุมัติกรณีใช้งาน: เจ้าของกระบวนงานเป็น A ผู้จัดการงานเป็น R ผู้ดูแลข้อมูลและฝ่ายกฎหมายเป็น C ผู้ใช้เป็น I
• กำหนดข้อมูลและตั้งค่าบริการ: เจ้าของกระบวนงานเป็น A ฝ่ายเทคโนโลยีหรือข้อมูลเป็น R ฝ่ายกฎหมายเป็น C ผู้ตรวจผลลัพธ์เป็น I
• รับรองผลลัพธ์ก่อนเผยแพร่: เจ้าของกระบวนงานเป็น A ผู้เชี่ยวชาญเนื้อหาเป็น R ฝ่ายที่ดูแลผู้รับผลกระทบเป็น C ผู้จัดการงานเป็น I
• รับเหตุและสั่งพักการใช้: เจ้าของกระบวนงานเป็น A ผู้ประสานเหตุและผู้ดูแลระบบเป็น R ผู้ดูแลข้อมูลกับฝ่ายกฎหมายเป็น C ผู้ใช้ที่เกี่ยวข้องเป็น I

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

ทำทะเบียนแล้วจัดระดับความเสี่ยงตามวิธีใช้จริง

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

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

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

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

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

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

คุมข้อมูลก่อนป้อน และกำหนดจุดตรวจผลลัพธ์

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

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

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

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

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

วัดผลงานและเปิดทางรายงานเหตุ

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

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

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

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

แผนลงมือใน 30 วัน

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

1. วันที่ 1–7: ผู้บริหารตั้งผู้สนับสนุนและคณะทำงาน ระบุเจ้าของกับผู้แทนของงานที่ใช้อยู่ สำรวจบริการที่พนักงานนำมาใช้กับงานองค์กร เปิดทะเบียน และแยกงานที่มีการส่งผลลัพธ์ออกนอกองค์กร ผลส่งมอบคือรายชื่อผู้มีอำนาจอนุมัติและสั่งพัก พร้อมทะเบียนฉบับแรกที่ระบุข้อมูลกับผู้รับผลลัพธ์
2. วันที่ 8–14: เจ้าของงานกับผู้ดูแลข้อมูลจัดระดับความเสี่ยง กำหนดข้อมูลที่อนุญาตและข้อมูลที่ห้ามป้อน ตรวจเงื่อนไขของบริการที่ใช้จริง และเขียนจุดตรวจโดยมนุษย์ ผลส่งมอบคือเงื่อนไขอนุมัติแยกตามกรณีใช้งาน โดยงานที่ยังตอบเรื่องข้อมูลหรือผู้ตรวจไม่ได้ให้คงสถานะรอพิจารณา
3. วันที่ 15–21: ทดลองกับงานที่มีขอบเขตชัด ใช้คำถามที่สะท้อนงานจริงรวมทั้งกรณีที่คำตอบอาจผิด บันทึกเวลาทำงานและการแก้ร่างเทียบกับวิธีเดิม แล้วซ้อมแจ้งเหตุด้วยสถานการณ์สมมติ ผลส่งมอบคือหลักฐานการตรวจและรายการปัญหาที่เจ้าของงานต้องแก้ก่อนขยายการใช้
4. วันที่ 22–30: เจ้าของงานเสนอผลการทดลอง คณะทำงานตัดสินใจว่าจะอนุมัติแบบมีเงื่อนไข ปรับแล้วทดลองอีกครั้ง หรือพักงาน ประกาศนโยบายสั้นที่ระบุบริการที่ใช้ได้ ข้อมูลที่ห้ามป้อน ผู้ตรวจผลลัพธ์ และช่องรายงานเหตุ ผลส่งมอบคือสถานะอนุมัติในทะเบียนกับผู้รับผิดชอบติดตามผล

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