ผู้สอบบัญชีขอข้อมูล Excel ไปให้ AI ประมวลผล ข้อมูลหลุดไหม? แนวปฏิบัติ 7 ข้อ ปี 2569

ปี 2569 เปลี่ยนคำถามนี้จาก "ไม่มีใครถาม" เป็น "ต้องมีคำตอบ"

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

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

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

ก่อนตอบว่า "หลุด" — ต้องแยกให้ได้ก่อนว่าหลุดชั้นไหน

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

ในทางปฏิบัติ ชั้นที่ 2 และ 3 มักติดไปกับไฟล์ โดยไม่จำเป็นต่อการตรวจสอบ เพราะคำขอมักมาในรูป "ขอ GL ทั้งปี" แล้วฝ่ายบัญชีก็ export ทั้งตารางออกมาให้ตามคำขอ ซึ่งเป็นอาการเดียวกับที่เคยเขียนไว้ในบทความ แชร์ไฟล์ Excel กันไปมา — ข้อมูลรั่วโดยไม่รู้ตัว คือไฟล์ตัวเดียวกลายเป็นตัวพาข้อมูลที่ไม่ควรออกไปเลย

ใครรับผิดชอบอะไร: ผู้สอบบัญชีไม่ใช่ "ผู้ประมวลผลข้อมูล" ของเรา

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

ตามการตีความที่ใช้กันในยุโรปภายใต้ GDPR ผู้สอบบัญชีที่ตรวจสอบงบการเงินตามกฎหมายถือเป็น ผู้ควบคุมข้อมูลส่วนบุคคลอีกรายหนึ่ง (independent data controller) ไม่ใช่ผู้ประมวลผลข้อมูลของลูกค้า เหตุผลอยู่ที่หลักความเป็นอิสระของวิชาชีพ: ผู้สอบบัญชีเป็นผู้กำหนดเองว่าต้องใช้ข้อมูลอะไร ตรวจด้วยวิธีใด และเก็บ working paper ไว้นานเท่าไร ตามมาตรฐานการสอบบัญชีที่เขาต้องปฏิบัติ ไม่ใช่ทำตามคำสั่งของผู้ว่าจ้าง หากผู้ว่าจ้างสั่งได้ ความเป็นอิสระก็หมดไปในตัว สำหรับประเทศไทย โครงสร้าง PDPA เดินตามแนวเดียวกับ GDPR ในเรื่องบทบาทผู้ควบคุม/ผู้ประมวลผล แต่ต้องบอกตรง ๆ ว่า ยังไม่มีแนวคำวินิจฉัยของหน่วยงานไทยที่ชี้ชัดเฉพาะกรณีผู้สอบบัญชี เท่าที่ตรวจสอบถึงเดือนกันยายน 2569

ผลที่ตามมาในทางปฏิบัติมีสามข้อ และข้อที่สามคือข้อที่ใช้งานได้จริงที่สุด

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

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

ตัวแปรที่ตัดสินจริง ๆ ไม่ใช่ "ใช้ AI ไหม" แต่คือ "AI ชั้นไหน"

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

ประเด็นที่ลึกกว่านั้นและมักถูกมองข้าม คือความต่างระหว่าง "ไม่นำไปฝึกโมเดล" กับ "ไม่เก็บข้อมูล" ผู้ให้บริการอาจไม่นำข้อมูลของเราไปฝึกโมเดลเลย แต่ยังเก็บ log ไว้ระยะหนึ่งเพื่อวัตถุประสงค์ด้านความปลอดภัย ซึ่งเป็นคนละเรื่องกันและมีนัยต่อ PDPA ต่างกัน ระหว่างเดือนสิงหาคมถึงกันยายน 2569 ผู้ให้บริการรายใหญ่หลายรายปรับนโยบายส่วนนี้ ทั้งในทางเพิ่มการเก็บ log สำหรับโมเดลรุ่นสูงสุดเพื่อตรวจจับการใช้งานที่เป็นภัย และในทางเสนอทางเลือกไม่เก็บข้อมูลเลยให้ลูกค้าองค์กร แปลว่า คำตอบวันนี้กับคำตอบปีก่อนไม่เหมือนกัน และต้องถามใหม่เป็นรอบ ๆ เรื่องนี้เชื่อมกับหลักการที่เคยเขียนไว้ใน Claude Data Governance & Security สำหรับองค์กรไทย คือต้องอ่านนโยบายตามผลิตภัณฑ์และตามวันที่ ไม่ใช่ตามชื่อแบรนด์

แนวปฏิบัติ 7 ข้อ ที่ทำได้เองในรอบปิดงบถัดไป

ทั้งเจ็ดข้อนี้เรียงตามความคุ้มค่า ข้อ 1 ถึง 3 ใช้แรงน้อยแต่ลดความเสี่ยงได้มากที่สุด และไม่มีข้อไหนต้องรอให้ฝั่งผู้สอบบัญชีเปลี่ยนอะไรก่อน

1. เพิ่มข้อกำหนดเรื่อง AI ลงใน engagement letter หรือ NDA

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

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

2. ให้เท่าที่ต้องตรวจ ไม่ให้ทั้งฐานข้อมูล

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

3. แทนข้อมูลระบุตัวบุคคลด้วยรหัส (pseudonymisation)

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

4. เปลี่ยนจากส่งไฟล์ เป็นให้สิทธิ์เข้าดูแบบอ่านอย่างเดียว

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

5. ถ้ายังต้องส่งไฟล์ อย่าส่งเป็นไฟล์แนบในอีเมล

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

6. ทำบันทึกการเปิดเผยข้อมูล (disclosure log)

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

7. ถามคำถาม due diligence ห้าข้อ — และฟังว่าเขาตอบได้เร็วแค่ไหน

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

ถ้ามีเวลาจำกัด เริ่มจากอะไร

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

มุมของ ERP: ลดจำนวนไฟล์ที่ต้องออกจากองค์กรตั้งแต่ต้นทาง

ที่ Grand Linux Solution เราออกแบบ Saeree ERP ให้รองรับรูปแบบข้อ 4 ได้ตรง ๆ เพราะเป็นเรื่องเดียวกับที่องค์กรภาครัฐและรัฐวิสาหกิจต้องใช้อยู่แล้วเวลามีผู้ตรวจสอบเข้ามา ระบบกำหนดสิทธิ์ตามบทบาท (role-based access) ให้เปิดบัญชีผู้ใช้เฉพาะสำหรับผู้สอบบัญชี จำกัดเป็นอ่านอย่างเดียว เลือกโมดูลและช่วงเวลาที่เห็นได้ ตั้งวันเริ่มและวันสิ้นสุดสิทธิ์การใช้งานให้ปิดตัวเองเมื่อจบงาน และมีร่องรอยการใช้งาน (audit trail) ว่าใครเปิดรายงานอะไรเมื่อไร ผู้ดูแลระบบขององค์กรทำได้เองทั้งหมดโดยไม่ต้องรอผู้พัฒนา

ในส่วนของ AI เราวางตำแหน่งไว้ชัดเจนว่า ERP คือแหล่งข้อมูลจริง AI คือผู้ช่วยที่มาถาม ไม่ใช่ที่เก็บข้อมูล เมื่อเชื่อม AI เข้ากับ ERP ผ่าน MCP การเข้าถึงจะเกิดผ่านเครื่องมือที่กำหนดขอบเขตไว้ล่วงหน้า อยู่ใต้สิทธิ์เดียวกับผู้ใช้คนนั้น และถูกบันทึกร่องรอยเหมือนการเข้าใช้งานปกติ ต่างจากการ export ไฟล์ทั้งตารางแล้วอัปโหลดเข้าเครื่องมือภายนอก ซึ่งเป็นจุดที่การควบคุมขาดลง แนวคิดเบื้องหลังเรื่องนี้เขียนไว้ใน วิธีใช้ AI อย่างปลอดภัยในองค์กร — นโยบาย AI Governance ที่ต้องมี

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

สรุป

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

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

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

- สุรีระยา ลิ้มไพบูลย์ | Saeree ERP by Grand Linux Solution

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

• Financial Reporting Council (UK) — AI in Audit: Generative and Agentic AI Guidance (ประกาศ 30 มีนาคม 2569 / 2026)
• IESBA — Handbook of the International Code of Ethics for Professional Accountants (ฉบับปรับปรุงด้านเทคโนโลยี มีผล 15 ธันวาคม 2567 / 2024 — ย่อหน้า 114.1 A1 เรื่องการรักษาความลับตลอดวงจรข้อมูล)
• สภาวิชาชีพบัญชี ในพระบรมราชูปถัมภ์ — คู่มือประมวลจรรยาบรรณสำหรับผู้ประกอบวิชาชีพบัญชี
• Accountancy Europe — GDPR: implications for auditors (ผู้สอบบัญชีในฐานะผู้ควบคุมข้อมูลอิสระ)
• Crowe — Statutory Auditor as Personal Data Controller
• สรุปประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่องหลักเกณฑ์การแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล (กรอบเวลา 24 / 72 ชั่วโมง)
• Cyberhaven — Insider Threats in the Age of AI (สถิติการวางข้อมูลองค์กรลงในเครื่องมือ AI และสัดส่วนที่มาจากบัญชีส่วนตัว)
• The Register — Anthropic promises zero data retention, but customers must check it worked (2 กันยายน 2569 / 2026)

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