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

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

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

บทสรุป: ในยุคที่การใช้งานเครื่องมือ Generative AI ที่ไม่ได้รับอนุญาตแพร่หลายไปทั่ว องค์กรที่ไม่มีแนวปฏิบัติ (Guideline) ย่อมตกอยู่ในความเสี่ยงต่อการรั่วไหลของข้อมูลโดยไม่มีการป้องกัน

การแพร่หลายของ Generative AI ส่งผลให้เกิด "Shadow AI" ซึ่งเป็นกรณีที่พนักงานตัดสินใจนำ LLM มาใช้ในการทำงานด้วยตนเองเพิ่มขึ้นอย่างรวดเร็ว ในหัวข้อ H3 ถัดไป เราจะเจาะลึกถึงสถานการณ์ความเสี่ยงที่เกิดขึ้นจริงและเหตุผลว่าทำไมจึงจำเป็นต้องมีแนวปฏิบัติ (Guideline)

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

Shadow AI คือคำเรียกโดยรวมของเครื่องมือ AI ที่พนักงานนำมาใช้ในการทำงานโดยไม่ผ่านการอนุมัติจากฝ่าย IT หรือฝ่ายบริหาร กรณีที่เป็นตัวอย่างชัดเจนคือ การนำข้อมูลลูกค้าหรือเนื้อหาในสัญญาของบริษัทไปวางในบริการ LLM แบบฟรี หรือการป้อนบันทึกการประชุมที่มีความลับสูงลงในระบบ Cloud AI ที่สมัครด้วยบัญชีส่วนตัว

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

ในประกาศเตือนภัยที่คณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (Personal Information Protection Commission) เผยแพร่เมื่อเดือนมิถุนายน 2023 ได้ระบุไว้ว่า การป้อนข้อมูลส่วนบุคคลลงในบริการ Generative AI อาจเข้าข่ายการส่งข้อมูลให้บุคคลที่สามตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล

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

การแพร่หลายของการใช้งาน Generative AI โดยที่ยังไม่มีการจัดทำแนวทางปฏิบัติ (Guidelines) ที่ชัดเจน จะทำให้องค์กรต้องเผชิญกับความเสี่ยงหลัก 3 ประการ ดังนี้:

① การส่งข้อมูลลับออกสู่ภายนอกโดยไม่ตั้งใจ มีการรายงานกรณีที่พนักงานคัดลอกข้อมูลลับทางธุรกิจลงในคำสั่ง (Prompt) โดยตรง บริการ LLM แบบคลาวด์ส่วนใหญ่มักตั้งค่าเริ่มต้นให้ใช้ข้อมูลที่ป้อนเข้าสู่ระบบเพื่อนำไปปรับปรุงโมเดล ซึ่งอาจนำไปสู่ความเสี่ยงที่ข้อมูลลับจะรั่วไหลออกสู่ภายนอกโดยไม่ตั้งใจ หากข้อมูลที่ป้อนเข้ามีข้อมูลส่วนบุคคล อาจนำไปสู่ความรับผิดชอบทางกฎหมาย ดังที่ระบุไว้ใน GDPR หรือประกาศแจ้งเตือนจากคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลของญี่ปุ่นที่เผยแพร่เมื่อเดือนมิถุนายน 2023

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

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

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

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

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

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

วิธีการสำรวจหลักในการทำสต็อก

• การตรวจสอบ Network Log: สกัดประวัติการเข้าใช้งานบริการ Generative AI จาก Log ของ Proxy หรือ Firewall โดยการจำกัดขอบเขตไปที่โดเมนของบริการหลัก เช่น ChatGPT, Copilot, Gemini จะช่วยให้การทำงานมีประสิทธิภาพมากขึ้น
• การทำแบบสอบถาม: ให้แต่ละแผนกตอบข้อมูลเกี่ยวกับ "ชื่อเครื่องมือ AI ที่ใช้ในการทำงาน, วัตถุประสงค์ และความถี่" การใช้รูปแบบนิรนามมักจะช่วยเพิ่มอัตราการรายงานการใช้งานอย่างไม่เป็นทางการได้
• การใช้เครื่องมือจัดการ SaaS: หากมีการนำโซลูชันการจัดการ SaaS มาใช้แล้ว สามารถสกัดหมวดหมู่ AI ออกจากรายการแอปพลิเคชันได้โดยตรง

วิธีการจัดระเบียบผลการสำรวจ

ข้อมูลที่รวบรวมได้จากการสำรวจจะถูกนำมาทำรายการตามหัวข้อดังต่อไปนี้

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

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

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

• เจ้าของ (Owner) (CISO หรือผู้รับผิดชอบด้านการขับเคลื่อน DX): มีอำนาจตัดสินใจและอนุมัติขั้นสุดท้ายสำหรับนโยบายโดยรวม
• ฝ่ายกฎหมายและกำกับดูแล (Legal & Compliance): ตรวจสอบความสอดคล้องกับ GDPR และกฎหมายคุ้มครองข้อมูลส่วนบุคคล
• ฝ่ายไอที (Information Systems): รับผิดชอบการประเมินทางเทคนิคของเครื่องมือ การจัดการบันทึกข้อมูล (Log) และการควบคุมการเข้าถึง
• ตัวแทนหน่วยงานธุรกิจ (Business Unit Representative): สะท้อนความต้องการจากหน้างานและสนับสนุนการออกแบบกฎที่สามารถนำไปใช้ได้จริง

การจัดระเบียบว่า "ใครเป็นผู้ตัดสินใจอะไร ใครเป็นผู้ปฏิบัติ และใครเป็นผู้รายงาน" ในแต่ละบทบาทด้วย RACI Matrix (Responsible / Accountable / Consulted / Informed) จะช่วยลดความเข้าใจที่คลาดเคลื่อนในขั้นตอนการทำงานภายหลังได้

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

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

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

「เครื่องมือนี้สรุปแล้วใช้ได้หรือไม่ได้กันแน่ แล้วต้องไปถามใครดี」——ทันทีที่พนักงานหน้างานเกิดความรู้สึกเช่นนี้ ความเชื่อมั่นที่มีต่อแนวทางปฏิบัติ (Guideline) ก็จะหมดไป การตีเส้นแบ่งที่ไม่ชัดเจนคือบ่อเกิดสำคัญที่ทำให้เกิด Shadow AI

ดังนั้น วิธีที่มีประสิทธิภาพคือการจัดการโดยแบ่งเครื่องมือ AI ออกเป็น 3 ระดับ ดังนี้:

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

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

③ เครื่องมือต้องห้าม (Prohibited) เครื่องมือที่มีความเป็นไปได้ว่าข้อมูลจะถูกนำไปใช้ในการเรียนรู้ (Training) หรือเครื่องมือที่ไม่ทราบพื้นที่การประมวลผลข้อมูลจะถูกจัดอยู่ในหมวดนี้ การเปิดเผยรายการเหตุผลที่ห้ามใช้จะช่วยให้หน้างานเข้าใจและยอมรับได้ง่ายขึ้นว่า "ทำไมถึงใช้ไม่ได้"

เพื่อให้การแบ่งระดับใช้งานได้จริง มีประเด็นสำคัญ 3 ข้อดังนี้:

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

การกำหนดระดับความลับเป็น 3 ระดับดังต่อไปนี้ จะช่วยให้การปฏิบัติงานจริงทำได้ง่ายขึ้น:

• ระดับ 1 (ข้อมูลสาธารณะ): เนื้อหาทางการตลาดที่เผยแพร่สู่ภายนอกแล้ว, เอกสารข้อมูลผลิตภัณฑ์ ฯลฯ อนุญาตให้ป้อนข้อมูลเข้าสู่ LLM แบบคลาวด์ภายนอกได้
• ระดับ 2 (ข้อมูลภายในองค์กร): คู่มือภายใน, รายงานการประชุม, ข้อมูลทางการเงินที่ยังไม่เปิดเผย ฯลฯ อนุญาตให้ใช้ได้เฉพาะในแผนสำหรับองค์กรที่ได้รับการอนุมัติหรือสภาพแวดล้อมแบบ On-premise เท่านั้น
• ระดับ 3 (ข้อมูลลับ/ข้อมูลส่วนบุคคล): ข้อมูลส่วนบุคคลของลูกค้า, สัญญา, ข้อมูลการประเมินผลบุคลากร ฯลฯ โดยหลักการแล้วห้ามป้อนเข้าสู่ AI และจำเป็นต้องผ่านกระบวนการทำให้เป็นข้อมูลนิรนาม (Anonymization) หรือการปกปิดข้อมูล (Masking) เท่านั้น

ในประกาศเตือนภัยที่เผยแพร่โดยคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (Personal Information Protection Commission) เมื่อเดือนมิถุนายน 2023 ก็ได้มีการเรียกร้องให้ใช้ความระมัดระวังในการป้อนข้อมูลส่วนบุคคลเข้าสู่บริการ Generative AI หากมีการทำธุรกรรมกับยุโรปซึ่งอยู่ภายใต้บังคับของ GDPR จำเป็นต้องมีข้อจำกัดที่เข้มงวดยิ่งขึ้น

ในการกำหนดกฎระเบียบการใช้งาน โปรดระบุประเด็นต่อไปนี้ให้ชัดเจนเป็นลายลักษณ์อักษร:

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

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

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

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

ในแบบฟอร์มประเมิน (Check sheet) ควรมีหัวข้อพิจารณาขั้นต่ำดังต่อไปนี้:

การจัดการข้อมูล (Data Handling)

• ข้อมูลที่ป้อนเข้าจะถูกส่งไปยังเซิร์ฟเวอร์ของผู้ให้บริการหรือไม่
• สามารถเลือกปฏิเสธ (Opt-out) การนำข้อมูลไปใช้ในการเรียนรู้ (Training data) ได้หรือไม่
• กรณีการใช้งานทางธุรกิจเกี่ยวข้องกับการป้อนข้อมูลส่วนบุคคลหรือข้อมูลที่เป็นความลับหรือไม่

ความปลอดภัยและการปฏิบัติตามกฎระเบียบ (Security & Compliance)

• ได้รับการรับรองจากบุคคลที่สาม เช่น SOC 2 Type II หรือ ISO 27001 หรือไม่
• ความสอดคล้องกับ GDPR และ "ข้อควรระวังในการใช้บริการ Generative AI" (มิถุนายน 2023) ที่ออกโดยคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PPC)
• สามารถทำข้อตกลงการประมวลผลข้อมูล (DPA) ตามสัญญาได้หรือไม่

ความน่าเชื่อถือของผู้ให้บริการ (Vendor Reliability)

• ความเสี่ยงด้านขนาดของบริษัทและความต่อเนื่องของบริการ
• หน้าที่ในการแจ้งเตือนเมื่อเกิดเหตุการณ์ไม่พึงประสงค์ (Incident) และการมีอยู่ของ SLA

ความเหมาะสมในการใช้งาน (Business Suitability)

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

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

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

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

รายการที่ควรระบุในเทมเพลต มีดังนี้:

• ข้อมูลผู้ยื่นคำร้อง: ชื่อ-นามสกุล, แผนกที่สังกัด, วันที่คาดว่าจะเริ่มใช้งาน
• ภาพรวมของเครื่องมือ: ชื่อบริการ, ผู้ให้บริการ, วัตถุประสงค์การใช้งาน, งานที่เกี่ยวข้อง
• ระดับความลับของข้อมูลที่ป้อน: ระบุตามการจำแนกประเภทที่กำหนดไว้ในส่วนก่อนหน้า (เปิดเผยต่อสาธารณะ / ภายในบริษัทเท่านั้น / เป็นความลับ)
• ผลการประเมินความเสี่ยง: คะแนนจากแบบประเมินและเกณฑ์การตัดสิน
• ผู้อนุมัติ: โดยพื้นฐานควรแบ่งเป็น 2 ขั้นตอน คือ การอนุมัติขั้นต้น (หัวหน้างานโดยตรง) → การอนุมัติขั้นที่สอง (แผนกสารสนเทศหรือผู้รับผิดชอบด้านความปลอดภัย)

ข้อควรระวังในการดำเนินงาน ที่สำคัญมี 3 ประการ ดังนี้:

1. กำหนดระยะเวลาการอนุมัติ: การระบุระยะเวลาที่ชัดเจน เช่น ต้องอนุมัติขั้นต้นภายใน 5 วันทำการ และอนุมัติขั้นสุดท้ายภายใน 10 วันทำการหลังจากยื่นคำร้อง จะช่วยป้องกันสถานการณ์ที่ «หน้างานเริ่มใช้งานอย่างไม่เป็นทางการในระหว่างรอการอนุมัติ»
2. การตรวจสอบการใช้งานต่อเนื่องเป็นระยะ: แม้จะเป็นเครื่องมือที่เคยได้รับอนุมัติแล้ว ควรมีการประเมินซ้ำทุก 6 เดือนถึง 1 ปี เพื่อตรวจสอบการเปลี่ยนแปลงข้อมูลจำเพาะของบริการและสถานการณ์การเกิดเหตุการณ์ด้านความปลอดภัย (Security Incident)
3. ปิดช่องโหว่สำหรับการใช้งานฉุกเฉิน: เพื่อป้องกันการ «ทดลองใช้งานไปก่อน» ควรมีหลักการห้ามทดลองใช้งานก่อนได้รับอนุมัติอย่างเป็นทางการ และหากจำเป็นต้องมีการตรวจสอบจริง ๆ ให้กำหนดกฎเกณฑ์ให้ใช้งานได้เฉพาะในสภาพแวดล้อม Sandbox ภายใต้การดูแลของแผนกสารสนเทศเท่านั้น

บทสรุป: แนวทางปฏิบัติจะมีประสิทธิผลก็ต่อเมื่อขั้นตอนการรับมือเหตุการณ์เบื้องต้นและการจัดการบันทึกข้อมูล (Log) ทำงานควบคู่กัน

เมื่อเกิดเหตุการณ์ข้อมูลรั่วไหลที่มีสาเหตุมาจาก AI หากขั้นตอนการรับมือไม่มีความชัดเจน จะทำให้ความเสียหายขยายวงกว้างได้ง่าย ในส่วนนี้จะอธิบายถึงการออกแบบขั้นตอนการรับมือเหตุการณ์เบื้องต้น (Initial Response Flow) และวงจรการดำเนินงานของบันทึกการตรวจสอบ (Audit Log)

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

ขอแนะนำให้ดำเนินการตอบสนองเบื้องต้นตาม 4 ขั้นตอน ดังนี้:

• การตรวจจับและตรวจสอบขั้นต้น (0-30 นาที): ตรวจสอบเอาต์พุตที่น่าสงสัย บันทึกการส่งข้อมูล และความผิดปกติในการเข้าถึง จากนั้นให้ระงับการเข้าถึงเครื่องมือ AI ที่เกี่ยวข้องชั่วคราว โดยผู้รับผิดชอบไม่ควรตัดสินใจเพียงลำพัง แต่ต้องรีบแจ้งหัวหน้างานโดยตรงและฝ่ายความปลอดภัยทันที
• การระบุขอบเขตผลกระทบ (30 นาที - 2 ชั่วโมง): บันทึกว่าข้อมูลใด ถูกป้อนเข้าสู่เครื่องมือใด และเมื่อใด ซึ่งในเอกสาร "ข้อควรระวังเกี่ยวกับการใช้บริการ Generative AI" (มิถุนายน 2023) ที่เผยแพร่โดยคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (Personal Information Protection Commission) ก็ได้แนะนำให้มีการตรวจสอบสถานะการป้อนข้อมูลส่วนบุคคลด้วยเช่นกัน
• การจำกัดความเสียหายและการเก็บรักษาหลักฐาน (2-4 ชั่วโมง): เก็บรักษาบันทึก (Log) ของเซสชันที่เกี่ยวข้อง และยกเลิกการเชื่อมต่อ API หรือปิดใช้งานบัญชีของเครื่องมือดังกล่าว โดยต้องบันทึกไฟล์ Log ที่เป็นหลักฐานไว้ในสื่อบันทึกข้อมูลอื่นเพื่อป้องกันไม่ให้ถูกลบหรือเขียนทับ
• การรายงานและแจ้งเตือน (4 ชั่วโมงขึ้นไป): รายงานต่อผู้บริหาร ฝ่ายกฎหมาย และหน่วยงานกำกับดูแลตามความจำเป็น โดยปฏิบัติตามระเบียบของบริษัท ทั้งนี้ ต้องระวังด้วยว่าหากเข้าข่าย GDPR จะมีข้อกำหนดบังคับให้ต้องแจ้งต่อหน่วยงานที่เกี่ยวข้องภายใน 72 ชั่วโมง

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

การออกแบบ Audit Log สามารถจัดระเบียบได้ง่ายโดยพิจารณาจาก 3 แกนหลัก คือ "อะไร (What) - ที่ไหน (Where) - นานเท่าไหร่ (How long)"

องค์ประกอบขั้นต่ำของ Log ที่ควรจัดเก็บมีดังนี้:

• Operation Log: ชื่อเครื่องมือ, ID ผู้ใช้งาน, วันเวลาที่ใช้งาน, Session ID
• Input Log: การจำแนกประเภทของ Prompt (พร้อมแท็กระดับความลับ)
• Output Log: ค่า Hash หรือสรุปเนื้อหาของข้อความที่สร้างขึ้น (การจัดเก็บข้อความฉบับเต็มให้พิจารณาตามปริมาณข้อมูล)
• Anomaly Detection Log: รายละเอียดของการดำเนินการที่ถูกตั้งค่าสถานะว่าละเมิดนโยบาย

ระยะเวลาในการจัดเก็บจะขึ้นอยู่กับระดับความลับของข้อมูลที่เกี่ยวข้อง สำหรับ Operation Log ที่เกี่ยวข้องกับข้อมูลส่วนบุคคลหรือความลับทางการค้า แนะนำให้จัดเก็บไว้อย่างน้อย 1 ปีขึ้นไป ในขณะที่ Operation Log สำหรับการใช้งานทั่วไปมักจะเพียงพอที่ 3-6 เดือน หากมีการบังคับใช้ GDPR หรือกฎหมายคุ้มครองข้อมูลส่วนบุคคล จำเป็นต้องระมัดระวังเรื่องระยะเวลาการจัดเก็บสูงสุดด้วยเช่นกัน

วงจรการตรวจสอบ (Review Cycle) ที่บริหารจัดการได้ง่ายควรมีโครงสร้างสองระดับ คือ การตรวจสอบตามปกติ (รายเดือน) และ การตรวจสอบตามเหตุการณ์ (เมื่อเกิด Incident) ในการตรวจสอบรายเดือน ให้ตรวจสอบแนวโน้มจำนวนของสถานะการตรวจพบความผิดปกติ และระบุสาเหตุหากมีการเกินเกณฑ์ที่กำหนดไว้ สำหรับกรณีที่เกิด Incident การกำหนดขั้นตอนการสำรองและวิเคราะห์ Log ของ Session ที่เกี่ยวข้องภายใน 72 ชั่วโมงไว้ล่วงหน้า จะช่วยป้องกันการตกหล่นในการรับมือได้

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

บทสรุป: แนวทางปฏิบัติ (Guidelines) จะใช้งานได้จริงก็ต่อเมื่อไม่ได้เป็นเพียงแค่การกำหนดขึ้นมาเท่านั้น แต่พนักงานทุกคนต้องเข้าใจและสามารถนำไปปฏิบัติได้จริงด้วย

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

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

ประเด็นสำคัญในการออกแบบสำหรับแต่ละตำแหน่งและสายงานมีดังนี้:

สำหรับพนักงานทั่วไป (End User)

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

สำหรับผู้จัดการและหัวหน้าทีม

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

สำหรับเจ้าหน้าที่ IT และความปลอดภัยของข้อมูล

• การประเมินคุณสมบัติทางเทคนิคของเครื่องมือ และการตรวจสอบ Data Flow เมื่อมีการเชื่อมต่อ API
• ขั้นตอนการปฏิบัติงานจริงสำหรับการจัดเก็บ Log และการตรวจสอบ (Audit)
• วิธีการใช้ Checklist สำหรับการตอบสนองเบื้องต้นเมื่อเกิดเหตุการณ์ไม่พึงประสงค์ (Incident)

สำหรับผู้บริหารและผู้มีอำนาจตัดสินใจ

• ขอบเขตผลกระทบของความเสี่ยงด้าน AI ต่อทั้งองค์กรและความรับผิดชอบในการบริหารจัดการ
• ภาพรวมของธรรมาภิบาล (Governance) ตามกรอบการทำงานสากล เช่น NIST AI RMF 1.0
• บทบาทในกระบวนการอนุมัติการปรับปรุงแนวทางปฏิบัติ

รูปแบบการฝึกอบรมที่เหมาะสมคือ e-learning ระยะสั้น (ประมาณ 15-20 นาที) สำหรับพนักงานทั่วไป และเวิร์กชอปแบบลงมือปฏิบัติจริง (Hands-on) สำหรับเจ้าหน้าที่ IT

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

ในการออกแบบการตรวจสอบความเข้าใจ ควรยึดหลัก 3 ประการดังนี้:

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

ช่วงเวลาในการจัดทดสอบก็มีความสำคัญเช่นกัน การทำแบบทดสอบเดิมซ้ำอีกครั้งหลังจากผ่านไป 3 เดือน ไม่ใช่แค่หลังจบการอบรมทันที จะช่วยให้ตรวจสอบความคงทนของความรู้ได้อย่างต่อเนื่อง หากคะแนนลดลง นั่นเป็นสัญญาณว่าจำเป็นต้องมีการแจ้งเตือนเป็นระยะ (ผ่านทางอีเมลหรือการแจ้งเตือนในทีม)

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

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

บทสรุป: ความล้มเหลวที่พบบ่อยในการกำหนดแนวทางปฏิบัติ (Guidelines) มักสรุปได้เป็น 2 รูปแบบ คือ "การจำกัดที่เข้มงวดเกินไป" และ "การทำแล้วทิ้งไว้เฉยๆ" ซึ่งทั้งสองกรณีล้วนนำไปสู่การที่หน้างานไม่ปฏิบัติตาม ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องรวมมาตรการป้องกันไว้ตั้งแต่ขั้นตอนการออกแบบ

รายละเอียดจะอธิบายไว้ในหัวข้อ H3 แต่ละส่วน

เรามักจะคิดกันว่า "ยิ่งตั้งนโยบายให้เข้มงวดเท่าไร ก็จะยิ่งปลอดภัยมากขึ้นเท่านั้น" แต่ในความเป็นจริงหน้างานอาจส่งผลในทางตรงกันข้าม

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

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

รูปแบบทั่วไปที่นโยบายเข้มงวดเกินไปจนส่งผลเสีย มีดังนี้:

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

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

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

แนวทางปฏิบัติ (Guidelines) ไม่ใช่สิ่งที่ทำเสร็จแล้วจบไป แต่เป็นสิ่งที่ต้องมีการอัปเดตอย่างต่อเนื่องเปรียบเสมือนสิ่งมีชีวิต เนื่องจากสภาพแวดล้อมมีการเปลี่ยนแปลงอยู่ตลอดเวลา ไม่ว่าจะเป็นการแก้ไขกฎหมายและข้อบังคับ การปรากฏตัวของเครื่องมือ AI ใหม่ๆ หรือการเกิดเหตุการณ์ไม่พึงประสงค์ภายในองค์กร

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

ประเด็นสำคัญในการออกแบบรอบการปรับปรุงมีดังนี้:

• กำหนดช่วงเวลาการทบทวนตามรอบ: ควรมีการทบทวนอย่างน้อยปีละ 1 ครั้ง หรือดีที่สุดคือทุกครึ่งปี เนื่องจาก "แนวทางปฏิบัติสำหรับผู้ประกอบการ AI (ฉบับที่ 1.0)" (เมษายน 2024) ที่เผยแพร่โดยกระทรวงเศรษฐกิจ การค้า และอุตสาหกรรม (METI) และกระทรวงกิจการภายในและการสื่อสาร (MIC) ของญี่ปุ่น รวมถึง NIST AI RMF 1.0 ต่างก็มีการแก้ไขและอัปเดตอยู่เสมอ จึงควรผนวกการตรวจสอบแนวโน้มล่าสุดเข้าไว้ในการทบทวนตามรอบด้วย
• กำหนดการปรับปรุงกรณีพิเศษเมื่อมีเหตุจำเป็น (Trigger-based): ในกรณีที่เกิดเหตุการณ์ไม่พึงประสงค์, การนำเครื่องมือใหม่มาใช้ทั่วทั้งองค์กร, หรือมีการแก้ไขกฎหมายและข้อบังคับ ให้พิจารณาปรับปรุงทันทีโดยไม่ต้องรอรอบการทบทวนปกติ
• ทำให้ประวัติการแก้ไขสามารถตรวจสอบได้: บันทึกหมายเลขเวอร์ชันและเหตุผลในการเปลี่ยนแปลง เพื่อให้พนักงานทุกคนสามารถตรวจสอบความแตกต่างได้ตลอดเวลา
• รวบรวมข้อเสนอแนะจากหน้างาน: จัดตั้งช่องทางรับข้อเสนอแนะเพื่อการปรับปรุงจากผู้ปฏิบัติงานในทุกไตรมาส เพื่อตรวจสอบประสิทธิผลของแนวทางปฏิบัติอย่างต่อเนื่อง

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

Q1. ธุรกิจขนาดกลางและขนาดย่อม (SME) จำเป็นต้องมีแนวทางปฏิบัติหรือไม่?

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

Q2. ควรบูรณาการเข้ากับนโยบายความปลอดภัยของข้อมูลที่มีอยู่เดิมอย่างไร?

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

Q3. ควรจัดการอย่างไรหากมีการใช้เครื่องมือ AI ฟรีบนอุปกรณ์ส่วนตัว?

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

เมื่อย้อนกลับไปดูเนื้อหาที่อธิบายมาทั้งหมดในบทความนี้ จะเห็นได้ว่าการจัดทำแนวทางปฏิบัติ (Guidelines) ไม่ใช่ "การจำกัดการทำงาน" แต่เป็นการวางรากฐานเพื่อให้หน้างานสามารถใช้งาน AI ได้อย่างเต็มประสิทธิภาพด้วยความอุ่นใจ

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

"แนวทางปฏิบัติสำหรับผู้ประกอบการ AI (ฉบับที่ 1.0)" ที่กระทรวงเศรษฐกิจ การค้า และอุตสาหกรรม (METI) และกระทรวงกิจการภายในและการสื่อสาร (MIC) ของญี่ปุ่นได้เผยแพร่เมื่อเดือนเมษายน 2024 รวมถึงกรอบการทำงานระดับสากลอย่าง NIST AI RMF 1.0 ต่างก็ให้ความสำคัญกับความสมดุลระหว่างการบริหารจัดการความเสี่ยงและการส่งเสริมการใช้งานเป็นหัวใจหลัก ในการจัดทำแนวทางปฏิบัติของบริษัทตนเอง การนำเอกสารเหล่านี้มาเป็นเกณฑ์อ้างอิงและปรับปรุงให้เหมาะสมกับประเภทธุรกิจ ขนาดองค์กร และระดับความลับของข้อมูลถือเป็นแนวทางที่ปฏิบัติได้จริง

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