กฎข้อ 1 — ทุกตัวเลขต้องมาจากโค้ดที่รันจริง (execution-grounded) และกดรันซ้ำได้ (re-runnable)
เรื่องสำคัญที่สุดเลยคือ ตัวเลขสถิติที่ AI พิมพ์มาลอย ๆ โดยไม่มีโค้ดให้เราเห็น ให้ถือว่ายังเชื่อไม่ได้ ให้เชื่อเฉพาะตัวเลขที่มาจากโค้ดหรือ SQL ที่เราเห็นเองและสั่งรันซ้ำแล้วได้ผลเหมือนเดิม วิธีที่ดีคือตั้งกฎไว้ตั้งแต่แรกให้ AI แยกให้ชัดว่าตัวเลขไหน 'ยืนยันด้วยการรันโค้ดแล้ว' กับตัวเลขไหน 'ยังไม่ได้รันโค้ด' และให้มันบอกทุกครั้งที่ยังไม่ได้รัน
AI ตอบมั่นใจมาก แต่ผิดได้ — มันมั่วตัวเลขสถิติ (hallucinate) ขึ้นมาเองได้
AI สามารถแต่งตัวเลขสถิติที่ดูน่าเชื่อขึ้นมาเองได้ โอกาสที่จะมั่วมากหรือน้อยขึ้นอยู่กับชนิดงานและชุดข้อสอบที่ใช้วัด (benchmark) อย่างงานสรุปเนื้อหาที่อ้างอิงข้อมูลจริง โมเดลชั้นนำอาจมั่วต่ำกว่า 1% แต่พอเจอข้อสอบยาก ๆ อย่าง FaithJudge โมเดลตัวเดียวกันกลับมั่วพุ่งไปราว 7.6% และงานเฉพาะทางบางแบบวิ่งไปถึง 6-33% เลย งานวิจัยปี 2025 ยังพบว่าโมเดลมักใช้คำพูด 'มั่นใจกว่าเดิม' ตอนที่มันตอบผิดด้วยซ้ำ ฉะนั้นความมั่นใจของ AI ไม่ได้แปลว่าคำตอบถูก และงานวิจัยเชิงทฤษฎีปี 2025 ยังชี้ว่าการมั่วข้อมูล (hallucination) เป็นเรื่องที่ติดมากับตัวโครงสร้างของโมเดล ไม่ใช่บั๊กที่จะกำจัดออกได้หมด ทางป้องกันคือรันซ้ำด้วยโค้ดเสมอ และให้คนที่เป็นนักวิเคราะห์ข้อมูล (analyst) ตัวจริงเป็นคนรับผิดชอบการตีความ
กับดักทางสถิติ — ความสัมพันธ์ไม่เท่ากับสาเหตุ (correlation != causation), p-value, การปั่นผล (p-hacking)
ทั้ง AI และตัวเราเองก็ชอบทำผิดสถิติแบบคลาสสิกกันบ่อย ๆ เช่น ตีความค่า p-value ผิด (พูดทำนองว่า 'กำลังจะมีนัยสำคัญ' ซึ่งไม่มีอยู่จริง) มองว่าสองอย่างที่เกิดขึ้นพร้อมกัน (correlation) เป็นเหตุเป็นผลของกันและกัน (ทั้งที่ AI แค่จับความสัมพันธ์ที่อาจบังเอิญ ไม่ใช่ความเป็นเหตุเป็นผลจริง) ปั่นผลด้วยการสั่งวิเคราะห์ซ้ำ ๆ จนกว่าจะได้ผลถูกใจ (p-hacking) ละเลยเงื่อนไขที่การทดสอบต้องการ (เช่น ข้อมูลต้องกระจายแบบปกติ ข้อมูลต้องเป็นอิสระต่อกัน หรือกรณีทดสอบหลายคู่พร้อมกัน) และเลือกวิธีทดสอบ (test) ผิดชนิด วิธีป้องกันคือตั้งสมมติฐานให้ชัดก่อนลงมือวิเคราะห์ บังคับให้ AI บอกชื่อวิธีทดสอบพร้อมเงื่อนไข ให้บอกขนาดของผล (effect size) และช่วงความเชื่อมั่น (CI) ด้วย ไม่ใช่รายงานแค่ p-value และย้ำให้ชัดว่าความสัมพันธ์ไม่เท่ากับสาเหตุ (correlation ไม่เท่ากับ causation) มีเครื่องมือช่วยตรวจข้อผิดพลาดพวกนี้อยู่ เช่น Statcheck และ GRIM
เลือกเครื่องมือให้ถูกกับงาน — RAG ไม่ใช่เครื่องคิดเลข และ LLM ก็ไม่ใช่ตัวพยากรณ์ (forecaster) ที่จะใช้เดี่ยว ๆ ได้
ระบบดึงข้อมูลมาช่วยตอบ (RAG) ถูกออกแบบมาสำหรับข้อความ ไม่เหมาะกับตัวเลขหรือตาราง เพราะพอเอาตารางมาแปลงเป็นข้อความ โครงสร้างของตารางจะหายไป ทำให้จับค่าตัวเลขได้แย่ ตารางใหญ่ ๆ ก็ล้นพื้นที่ความจำที่โมเดลอ่านได้ในครั้งเดียว (context window) แถม RAG ยังทำงานพวกรวมยอด กรองข้อมูล หรือคำนวณแบบ SQL ได้ไม่น่าเชื่อถือ ถ้าอยากได้ตัวเลขจริง ให้ใช้ pandas หรือให้ AI แปลงคำถามเป็น SQL (text-to-SQL) แล้วเก็บ RAG ไว้ใช้ดึงเอกสาร นิยามศัพท์ หรืองานเก่า ๆ ดีกว่า ส่วนงานพยากรณ์ (forecasting) โมเดลทำนายข้อมูลตามเวลาที่ใช้ LLM หรือโมเดลพื้นฐานขนาดใหญ่ (foundation model) ควรเป็นแค่ตัวเสริม ไม่ใช่ตัวหลักที่ใช้เดี่ยว ๆ และมันจะแม่นน้อยลงเมื่อข้อมูลเก็บถี่ ต้องเอามาทดสอบกับข้อมูลของเราเองแบบที่ยังไม่เคยเห็นมาก่อน (zero-shot) ขอผลเป็นช่วง (prediction interval) และทดสอบย้อนหลังด้วยข้อมูลในอดีต (backtest) ซึ่งบ่อยครั้งโมเดลสถิติแบบดั้งเดิมก็ยังชนะอยู่ดี
ความเป็นส่วนตัว (privacy) กับระดับบริการ (tier) — อย่าเอาข้อมูลสำคัญไปอัปโหลดขึ้นบัญชีทั่วไป/ฟรี
ระดับบริการ (tier) ที่เราใช้ต่างกันสำคัญมาก อย่าง OpenAI โดยค่าเริ่มต้นจะไม่เอาข้อมูลไปฝึกโมเดลสำหรับบัญชีระดับองค์กร ธุรกิจ การศึกษา สุขภาพ ครู และแบบเชื่อมต่อผ่านโค้ด (Enterprise/Business/Edu/Healthcare/Teachers/API) เว้นแต่เราจะกดยินยอมเอง ส่วนรุ่นทั่วไปที่คนใช้กันทั่วไป (consumer) อาจเอาข้อมูลของเราไปฝึก เว้นแต่เราจะเข้าไปปิดเอง ด้านความปลอดภัย เขามีการเข้ารหัสข้อมูลตอนเก็บด้วยมาตรฐาน AES-256 และตอนส่งด้วย TLS 1.2+ มีสัญญาคุ้มครองข้อมูล (DPA) ที่รองรับกฎหมาย GDPR มีตัวเลือกไม่เก็บข้อมูลเลย (zero-data-retention) บนแบบเชื่อมต่อผ่านโค้ดสำหรับองค์กรที่เข้าเกณฑ์ และเลือกได้ว่าจะเก็บข้อมูลไว้ประเทศไหน สรุปกฎง่าย ๆ คือ รุ่นทั่วไป/ฟรี อาจเอาข้อมูลไปฝึกตั้งแต่แรก ส่วนแบบธุรกิจ/องค์กร/เชื่อมต่อผ่านโค้ด จะไม่เอาไปฝึกโดยค่าเริ่มต้นและมี DPA ให้ ฉะนั้นห้ามเอาข้อมูลที่มีข้อกำหนดควบคุม ข้อมูลลับ หรือข้อมูลส่วนบุคคล ไปอัปโหลดขึ้นบัญชีส่วนตัวหรือบัญชีฟรีเด็ดขาด ทางที่ปลอดภัยกว่าคือใช้ชั้นกำกับดูแลข้อมูล (governance layer เช่น Agentforce Trust Layer) และเครื่องมือที่รันในคลังข้อมูลของเราเอง (warehouse-native เช่น Cortex/Genie) ที่ข้อมูลไม่ต้องออกไปนอกแพลตฟอร์ม
กฎหมายที่เกี่ยวข้อง — PDPA ของไทย, GDPR, EU AI Act, NIST
การเอาข้อมูลส่วนบุคคลจากไทยไปใส่ในเครื่องมือ AI ต่างประเทศ ถือเป็นการส่งข้อมูลออกนอกประเทศ (cross-border transfer) ตามกฎหมายคุ้มครองข้อมูลส่วนบุคคลของไทย (PDPA) ซึ่งทำได้ 2 ช่องทาง คือ มาตรา 28 (เรียกว่าเส้นทางสีเขียว/Green Route ใช้ได้เมื่อประเทศปลายทางผ่านการรับรองว่ามีมาตรฐานคุ้มครองเพียงพอ หรือ adequacy) กับ มาตรา 29 (เส้นทางที่ต้องมีมาตรการป้องกัน/Safeguard Route ใช้สัญญามาตรฐานหรือกฎเกณฑ์ภายในกลุ่มบริษัท คือ SCCs/BCRs) ณ ปลายปี 2025 ยังไม่มีประเทศไหนผ่านการรับรอง จึงต้องใช้มาตรา 29 เป็นทางที่ปลอดภัย และเรามีหน้าที่ต้องแจ้งเหตุข้อมูลรั่วไหลภายใน 72 ชั่วโมง ส่วนระบบรับรองกฎเกณฑ์ภายในกลุ่มบริษัท (BCR) เปิดให้ยื่นแล้วเมื่อ 29 ก.ย. 2025 และเริ่มมีการบังคับใช้จริง (1 ส.ค. 2025 คณะกรรมการคุ้มครองข้อมูลส่วนบุคคล หรือ PDPC สั่งปรับ 8 รายการใน 5 คดี รวม 14.5 ล้านบาท ทำให้ยอดปรับสะสมเกิน 21 ล้านบาท) และยังกำหนดให้หน่วยงานรัฐทุกแห่งต้องมีเจ้าหน้าที่คุ้มครองข้อมูล (DPO) ด้วย (ประกาศ 9 ต.ค. 2025) ฝั่งกฎหมาย AI ของยุโรป (EU AI Act, Reg. (EU) 2024/1689) วันที่ 2 ก.พ. 2025 เริ่มห้ามการใช้งานที่ต้องห้ามและบังคับให้อบรมความรู้เรื่อง AI แก่พนักงาน, 2 ส.ค. 2025 เริ่มหน้าที่ของโมเดล AI เอนกประสงค์ (GPAI), 2 ส.ค. 2026 เริ่มบังคับกฎสำหรับงานที่มีความเสี่ยงสูงและ Article 50 โดยมีโทษสูงสุด 35 ล้านยูโร หรือ 7% ของรายได้รวมทั้งบริษัท (แต่ร่างกฎหมายรวม/omnibus อาจเลื่อนออกไป) นอกจากนี้ GDPR ยังกำกับดูแลตัวข้อมูลเองอีกชั้น ส่วนกรอบการจัดการความเสี่ยง AI ของ NIST (AI RMF 1.0 แบ่งเป็น GOVERN/MAP/MEASURE/MANAGE) และคู่มือเฉพาะสำหรับ AI สร้างสรรค์ (GenAI Profile NIST-AI-600-1 ออก 26 ก.ค. 2024 ระบุ 12 ความเสี่ยง) ก็เป็นรายการตรวจสอบ (checklist) แบบฟรีที่ดีที่สุดที่มีอยู่
การทำผลให้ซ้ำได้ (reproducibility) และความรับผิดชอบที่ต้องอยู่ที่คน
คำสั่งเดียวกัน (prompt) ที่เราพิมพ์ให้ AI อาจให้ผลไม่เหมือนเดิมในแต่ละครั้ง แถมยังมีเรื่องที่ AI แอบเปลี่ยนชนิดของข้อมูลเงียบ ๆ ทำแถวข้อมูลหายไป หรือไฟล์ถูกตัดไม่ครบ ฉะนั้นการดูแค่คำตอบในหน้าแชตอย่างเดียวจะทำซ้ำให้ได้ผลเดิมไม่ได้ ต้องล็อกโค้ดกับเวอร์ชันเอาไว้ กดรันซ้ำเพื่อยืนยัน ตรวจดูว่าจำนวนแถวครบไหมและข้อมูลถูกตัดหายหรือเปล่า และทำเอกสารอธิบายความหมายของข้อมูล (semantic model) ไว้ บรรทัดสุดท้ายที่ต้องจำคือ AI ช่วยเร่งงานให้เราได้ก็จริง แต่คนที่เป็นนักวิเคราะห์ (analyst) ต้องเป็นคนรับผิดชอบการตีความ ทุกตัวเลขต้องตรวจย้อนกลับไปหาที่มาได้ และต้องเลือกเครื่องมือให้ถูกกับงาน (ใช้ SQL/pandas สำหรับตัวเลข ส่วนงานพยากรณ์ให้ใช้โมเดลสถิติแบบดั้งเดิม บวกกับการขอผลเป็นช่วง และการทดสอบย้อนหลัง หรือ backtest)