ใช้ Claude Code กับข้อมูลลับขององค์กรได้ไหม? ความปลอดภัยและ PDPA ฉบับคนการเงิน

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

ทำไมคนการเงินต้องถามเรื่องนี้ก่อนใคร

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

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

ข้อมูลที่คุณพิมพ์เข้าไป มันไปไหน

ก่อนจะวางกฎ ต้องเข้าใจ flow ก่อน Claude Code เป็น agent ที่รันบนเครื่องคุณ แต่ "สมอง" ที่คิดคำตอบคือโมเดลที่อยู่บนคลาวด์ของผู้ให้บริการ — แปลว่าเนื้อหาที่มันต้องใช้ตอบ (ไฟล์ที่คุณให้มันอ่าน คำสั่งที่คุณพิมพ์) จะถูกส่งออกไปประมวลผล นี่คือจุดที่ต้องเข้าใจให้ชัด

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

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

PDPA กับข้อมูลลูกค้า: เส้นที่ห้ามข้าม

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

• อย่าป้อนข้อมูลที่ระบุตัวตนลูกค้าได้ เข้าเครื่องมือใด ๆ ก่อนได้รับอนุมัติชัดเจนจากฝ่ายที่ดูแล
• ถ้าจำเป็นต้องใช้ข้อมูลรูปแบบจริง ให้ทำงานกับข้อมูลที่ mask / de-identify แล้ว — ตัดส่วนที่ระบุตัวตนออกก่อน
• เรื่องนี้ไม่ใช่การตัดสินใจของคุณคนเดียว คุยกับฝ่าย compliance / DPO และทำตามกระบวนการอนุมัติของเครื่องมือ

นี่คือวินัยเดียวกับที่ผมเน้นในคู่มือเริ่มต้น Claude Code สำหรับคนสายการเงิน — ความเก่งในการใช้ AI อย่างมืออาชีพ วัดกันที่ตรงนี้ ไม่ใช่ที่ความเร็ว

5 วิธีใช้ Claude Code กับงานการเงินอย่างปลอดภัย

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

1. ให้มันเขียนสคริปต์ ไม่ใช่ป้อนข้อมูลจริง — ออกแบบตัวประมวลผลด้วยข้อมูลปลอม แล้วค่อยเอาไปรันกับข้อมูลจริง ในเครื่องที่ได้รับอนุมัติ
2. ฝึกมือด้วย sample / synthetic data ที่หน้าตาเหมือนของจริงแต่ไม่ใช่ข้อมูลลูกค้าจริง
3. mask ก่อนเสมอ ถ้าต้องให้มันเห็นโครงสร้างข้อมูล — แทนค่าที่ระบุตัวตนด้วยรหัสสุ่ม
4. แยกชั้นความลับ — เอกสารสาธารณะ คู่มือ โค้ด ใช้ได้สบาย ส่วนข้อมูลลูกค้าเก็บไว้อีกชั้นที่ไม่ส่งออก
5. อ่านและทำตามนโยบายเครื่องมือขององค์กร — ถ้ายังไม่มี ให้ชวนตั้งก่อนใช้เป็นวงกว้าง

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

เริ่มยังไงให้ปลอดภัยตั้งแต่วันแรก

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

ถ้าอยากเริ่มแบบมีโครงที่คิดเรื่องความปลอดภัยมาให้แล้ว ผมรวมแนวทางที่ผมใช้กับงานสายการเงินไว้ในคอร์ส Claude Code — ก็อป workspace ผมไปปรับ โดยที่หลักเรื่องข้อมูลลับและ PDPA ถูกวางเป็นนิสัยตั้งแต่ต้น ไม่ใช่มาคิดทีหลังตอนเกิดเรื่อง