AI สร้างระบบได้เร็ว แต่วันที่คนสร้างไม่อยู่ ใครดูแลธุรกิจต่อ?
ภาพหนึ่งที่ผมพบในการพูดคุยเรื่องการใช้ AI ในองค์กร คือพนักงานอยากลดงานซ้ำ ๆ จึงใช้เครื่องมือที่ตัวเองมีช่วยสร้างระบบเล็ก ๆ ขึ้นมา
วันแรกอาจมีแค่เขาใช้คนเดียว
แต่พอทำงานเร็วขึ้น คนอื่นก็เริ่มใช้ตาม
จนทั้งแผนกเปลี่ยนวิธีทำงานมาพึ่งระบบนั้น
สิ่งนี้มีคุณค่าครับ
ผมไม่ได้อยากให้ห้ามคนสร้างของที่ช่วยงาน
แต่มีคำถามที่องค์กรต้องตามให้ทัน:
ถ้าคนสร้างไม่อยู่แล้ว ระบบนี้จะอยู่ต่ออย่างไร?
งานดูเล็ก
ไม่ได้แปลว่าข้อมูลและผลกระทบเล็ก
บางงานอาจถูกมองว่าเป็นงาน Routine
จนไม่มีใครคิดเรื่องงบหรือการกำกับดูแล
แต่ควรแยก ความซับซ้อนของงาน
ออกจาก ความสำคัญของข้อมูล
งานกรอกตารางธรรมดา
ก็อาจเกี่ยวกับข้อมูลลูกค้า ราคา
หรือข้อมูลที่องค์กรไม่ต้องการเปิดเผย
และหากทุกคนต้องใช้ตารางนั้น
ก่อนทำงานขั้นต่อไป
การหยุดทำงานของระบบเล็ก ๆ
ก็อาจกลายเป็นปัญหาของทั้งทีม
ผมจึงไม่อยากให้ถามแค่ว่า
“ระบบนี้ใหญ่แค่ไหน”
แต่อยากให้ถามว่า
“ถ้ามันหยุดหนึ่งวัน
ใครจะทำงานต่อไม่ได้
และมีวิธีสำรองหรือไม่”
นี่เป็นเกณฑ์ที่ช่วยให้ผู้บริหารเห็นว่า
ควรจัดการระบบไหนก่อน
โดยไม่ต้องเข้าใจโค้ดทุกบรรทัด
บัญชีส่วนตัว
เป็นจุดเริ่มต้นของคำถาม
ไม่ใช่คำตัดสินทั้งหมด
เมื่อใช้บัญชี AI ส่วนตัวกับงานบริษัท
ควรถามว่า
- มีการนำข้อมูลอะไรเข้าไป
- ผู้ให้บริการเก็บและใช้ข้อมูลอย่างไร
- ตั้งค่าอะไรไว้
- และองค์กรอนุญาตหรือไม่
ไม่ควรเหมารวมว่า
AI ทุกบริการนำข้อมูลไปฝึกโมเดลเสมอ
หรือการใช้งานทุกกรณี
ผิดกฎหมายโดยอัตโนมัติ
ต้องตรวจทั้ง
เงื่อนไขบริการ การตั้งค่า ลักษณะข้อมูล นโยบายภายใน
และ หน้าที่ที่เกี่ยวข้องกับกรณีนั้น
การจัดการความเสี่ยงด้านข้อมูล
และการใช้งานตลอดวงจร
เป็นส่วนสำคัญของกรอบความเสี่ยง AI ของ NIST [3]
คำถามที่ผู้บริหารควรทำให้มีคำตอบ คือ
- ข้อมูลประเภทใด ใช้กับเครื่องมือใดได้
- ใครเป็นผู้อนุมัติ
- และเมื่อเกิดเหตุ ใครรับผิดชอบ
การซื้อบัญชีระดับองค์กร
อาจเป็นส่วนหนึ่งของทางเลือก
แต่ไม่ควรใช้แทน
การจัดกติกา สิทธิการเข้าถึง
และความเข้าใจของทีม
คำว่า “เป็นของบริษัท”
ต้องแยกจากคำว่า “เข้าถึงได้”
อีกประเด็นที่ไม่ควรรอให้คนลาออกก่อนค่อยคุย
คือเรื่อง สิทธิในผลงานและการส่งมอบ
อย่าสรุปเพียงว่า
ใครจ่ายค่า AI คนนั้นต้องเป็นเจ้าของทุกอย่าง
หรือทำงานในเวลาบริษัท
แล้วบริษัทเป็นเจ้าของโดยอัตโนมัติ
สิทธิอาจเกี่ยวข้องกับ
- กฎหมาย
- สัญญาจ้าง
- ข้อตกลง
- และลักษณะงาน
กรมทรัพย์สินทางปัญญาอธิบายว่า
กรณีงานที่สร้างในฐานะลูกจ้าง
มีหลักเฉพาะ
และข้อตกลงเป็นหนังสือมีความสำคัญ
จึงควรให้ผู้เชี่ยวชาญตรวจข้อกำหนดที่ใช้จริง
โดยเฉพาะผลงานที่มี AI เกี่ยวข้อง [5]
แต่แม้ตกลงสิทธิกันชัดแล้ว
ก็ยังมีโจทย์เรื่อง การเข้าถึง อยู่ดี
หากมีเพียงคนเดียวที่เข้า
โฮสติ้ง ฐานข้อมูล หรือที่เก็บโค้ดได้
องค์กรก็อาจดูแลระบบต่อไม่ได้
ในเวลาที่ต้องการ
สิทธิทางกฎหมาย
และ ความพร้อมทางปฏิบัติ
เป็นคนละเรื่องที่ต้องจัดการคู่กัน
ก่อนให้ทั้งแผนกพึ่งระบบ
ควรส่งต่อได้อย่างน้อยหนึ่งรอบ
แนวทางขั้นต่ำที่ผมแนะนำคือ
ทำรายการว่า
- ระบบนี้ใช้ทำอะไร
- เก็บข้อมูลอะไร
- และใครรับผิดชอบ
จากนั้นจัดให้
โค้ด การตั้งค่า บัญชีบริการ
และสิทธิที่จำเป็น
อยู่ในรูปแบบที่องค์กรดูแลต่อได้อย่างเหมาะสม
ไม่ใช่แชร์รหัสผ่านกันทุกคน
แต่กำหนดผู้มีสิทธิสำรอง
และวิธีกู้คืนบัญชีให้ชัด
การปกป้องโค้ด
และควบคุมการเข้าถึง
เป็นส่วนหนึ่งของแนวทาง
Secure Software Development Framework ของ NIST [4]
ควรมี
- วิธีสำรองและกู้ข้อมูล
- คู่มือเริ่มใช้งานหรือเปิดระบบใหม่
- และวิธีทำงานชั่วคราวเมื่อระบบมีปัญหา
ที่สำคัญคือ
ลองให้คนที่ไม่ได้สร้างระบบทำตามจริง
ข้อเสนอของผมคือ
ใช้การทดลองส่งต่อ
เป็นเครื่องตรวจความพร้อม
ไม่ใช่ถือว่ามีเอกสารครบแล้ว
แปลว่าคนอื่นทำได้แน่นอน
อย่ารอให้ระบบล่ม
จึงรู้ว่าความรู้ทั้งหมดอยู่กับคนเดียว
ทีมพัฒนามืออาชีพ
ยังต้องใช้เวลาในการส่งต่องาน
จากประสบการณ์ของผม
แม้มีขั้นตอนและเอกสาร
ก็ไม่ได้ทำให้การรับช่วงเป็นเรื่องอัตโนมัติ
ดังนั้น
ระบบที่พนักงานสร้างเอง
ไม่จำเป็นต้องมีเอกสารหนาเท่าโครงการใหญ่
แต่สิ่งสำคัญต้อง
- หาเจอ
- ทดสอบได้
- และมีคนรับผิดชอบจริง
ไม่ใช่รู้แค่ว่า
มีหน้าจอเปิดใช้งานได้ในวันนี้
ผู้บริหารไม่จำเป็นต้องเป็นนักพัฒนาครับ
แต่ควรรู้พอที่จะถามคำถามที่ถูก
หรือมีคนช่วยประเมินให้
ยิ่งระบบเริ่มเกี่ยวกับ
- เงิน
- ข้อมูลสำคัญ
- หรือการทำงานต่อเนื่องของหลายคน
ยิ่งควรเพิ่มระดับการตรวจสอบ
ก่อนขยายการใช้งาน
ใจความของผมคือ
AI ช่วยให้การสร้างระบบง่ายขึ้น
แต่การทำให้ระบบนั้นปลอดภัย
ดูแลต่อได้
และไม่ทำให้ธุรกิจหยุด
เมื่อคนหนึ่งไม่อยู่
ยังเป็นสิ่งที่ต้องจัดการ
เป้าหมายไม่ใช่หยุดนวัตกรรมของพนักงาน
แต่คือทำให้สิ่งที่เริ่มจาก
ความสามารถของคนหนึ่ง
กลายเป็นความสามารถที่องค์กร
พึ่งพาได้จริง
