PDPA กับ AI: ส่งข้อมูลลูกค้าเข้า AI ได้แค่ไหน

คำถามที่ได้ยินบ่อยมากในทีมพัฒนาช่วงนี้คือ "เอาข้อมูลลูกค้าไปให้ AI ช่วยวิเคราะห์ได้ไหม" เช่น อยากให้ AI สรุปข้อร้องเรียนจากลูกค้า จัดหมวดตั๋ว support หรือช่วย debug โดยแปะ record จากฐานข้อมูลจริงเข้าไปใน prompt คำตอบสั้น ๆ คือ "ได้ในบางกรณี แต่ต้องคิดก่อนส่ง" บทความนี้จะอธิบายแนวคิดสำคัญของ พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล (PDPA) ในมุมที่นักพัฒนาต้องรู้เมื่อใช้ AI พร้อมเทคนิคปิดบังข้อมูลก่อนส่ง และเช็กลิสต์ที่เอาไปคุยกับฝ่ายกฎหมายได้

หมายเหตุสำคัญ: บทความนี้เป็นข้อมูลทั่วไปจากมุมมองนักพัฒนา ไม่ใช่คำแนะนำทางกฎหมาย รายละเอียดของแต่ละองค์กรและแต่ละกรณีต่างกันมาก ก่อนตัดสินใจส่งข้อมูลส่วนบุคคลเข้าบริการ AI ควรปรึกษาเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO) หรือนักกฎหมายขององค์กร และติดตามประกาศล่าสุดจากสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลที่ www.pdpc.or.th

ข้อมูลส่วนบุคคลกับข้อมูลอ่อนไหว ต่างกันอย่างไร

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

ข้อมูลอ่อนไหว (sensitive data) คือข้อมูลส่วนบุคคลกลุ่มที่กฎหมายคุ้มครองเข้มกว่า เพราะถ้ารั่วหรือถูกใช้ผิดอาจทำให้เจ้าของข้อมูลถูกเลือกปฏิบัติหรือเสียหายร้ายแรง ตัวอย่างเช่น ข้อมูลสุขภาพ ความพิการ เชื้อชาติ ความเชื่อทางศาสนาหรือการเมือง ประวัติอาชญากรรม ข้อมูลพันธุกรรม และข้อมูลชีวภาพอย่างลายนิ้วมือหรือข้อมูลใบหน้าที่ใช้ยืนยันตัวตน โดยทั่วไปการประมวลผลข้อมูลกลุ่มนี้ต้องมีเงื่อนไขที่เข้มกว่า เช่น ต้องได้ความยินยอมโดยชัดแจ้ง เว้นแต่เข้าข้อยกเว้นเฉพาะ

ในทางปฏิบัติ ให้ทีมแบ่งข้อมูลในระบบเป็นสามระดับง่าย ๆ

ฐานทางกฎหมาย: เราเก็บข้อมูลมาเพื่ออะไร

PDPA ไม่ได้ห้ามประมวลผลข้อมูลส่วนบุคคล แต่ทุกการประมวลผลต้องมี ฐานทางกฎหมาย (lawful basis) รองรับ ฐานที่พบบ่อยได้แก่ ความยินยอม การปฏิบัติตามสัญญากับเจ้าของข้อมูล การปฏิบัติตามกฎหมาย ประโยชน์โดยชอบด้วยกฎหมาย (legitimate interest) และการป้องกันอันตรายต่อชีวิตร่างกาย

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

ผู้ให้บริการ AI คือ "ผู้ประมวลผลข้อมูล"

PDPA แยกบทบาทสองแบบ ผู้ควบคุมข้อมูลส่วนบุคคล (data controller) คือผู้ตัดสินใจว่าจะเก็บข้อมูลอะไร ใช้ทำอะไร ซึ่งก็คือบริษัทของเรา ส่วน ผู้ประมวลผลข้อมูลส่วนบุคคล (data processor) คือผู้ที่ประมวลผลตามคำสั่งของผู้ควบคุม เมื่อเราส่งข้อมูลลูกค้าไปให้บริการ AI ผ่าน API ผู้ให้บริการนั้นมักอยู่ในบทบาทผู้ประมวลผลแทนเรา

ผลในทางปฏิบัติคือ บริษัทยังต้องรับผิดชอบข้อมูลนั้นอยู่ และควรมีข้อตกลงกับผู้ประมวลผล (มักเรียกว่า Data Processing Agreement หรือ DPA) ที่กำหนดว่าเขาจะใช้ข้อมูลเฉพาะตามที่เราสั่ง มีมาตรการรักษาความปลอดภัย และแจ้งเหตุเมื่อข้อมูลรั่ว สิ่งที่ควรตรวจในเงื่อนไขของผู้ให้บริการ AI ได้แก่

• ข้อมูลที่ส่งผ่าน API ถูกนำไปฝึกโมเดลหรือไม่ และปิดได้หรือไม่
• เก็บข้อมูล (retention) ไว้นานแค่ไหน ใครเข้าถึงได้
• มีเอกสาร DPA ให้ลงนามหรือยอมรับหรือไม่
• ข้อมูลถูกประมวลผลและจัดเก็บที่ประเทศไหน
• บัญชีแบบใช้ส่วนตัวกับบัญชีองค์กรมีเงื่อนไขต่างกันหรือไม่

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

การส่งข้อมูลไปต่างประเทศ

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

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

ปิดบังข้อมูลก่อนส่ง: masking และ pseudonymisation

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

• Masking แทนที่ข้อมูลด้วยค่าที่ไม่มีความหมาย เช่น [EMAIL] หรือ [PHONE] ย้อนกลับไม่ได้ เหมาะกับงานวิเคราะห์ที่ไม่ต้องการตัวตน
• Pseudonymisation แทนที่ด้วย token เช่น [CUSTOMER_1] และเก็บตาราง mapping ไว้ฝั่งเรา เมื่อ AI ตอบกลับมาค่อยแทนค่ากลับ เหมาะกับงานร่างข้อความที่ต้องใส่ชื่อจริงตอนท้าย

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

<?php
declare(strict_types=1);

final class PiiRedactor
{
    /** @var array<string, string> token => ค่าจริง (เก็บฝั่งเราเท่านั้น) */
    private array $map = [];
    private int $seq = 0;

    private const PATTERNS = [
        'EMAIL'  => '/[A-Za-z0-9._%+\-]+@[A-Za-z0-9.\-]+\.[A-Za-z]{2,}/u',
        // เลขประจำตัวประชาชน 13 หลัก มีหรือไม่มีขีดคั่น
        'THAI_ID' => '/\b\d[\- ]?\d{4}[\- ]?\d{5}[\- ]?\d{2}[\- ]?\d\b/u',
        // เบอร์มือถือ/เบอร์บ้านรูปแบบไทยทั่วไป
        'PHONE'  => '/\b0\d{1,2}[\- ]?\d{3}[\- ]?\d{3,4}\b/u',
    ];

    public function redact(string $text): string
    {
        foreach (self::PATTERNS as $type => $regex) {
            $text = preg_replace_callback($regex, function (array $m) use ($type): string {
                $token = sprintf('[%s_%d]', $type, ++$this->seq);
                $this->map[$token] = $m[0];
                return $token;
            }, $text) ?? $text;
        }
        return $text;
    }

    /** ใช้เมื่อจำเป็นต้องคืนค่าจริงในผลลัพธ์ที่แสดงให้เจ้าหน้าที่ภายในเท่านั้น */
    public function restore(string $text): string
    {
        return strtr($text, $this->map);
    }
}

$r = new PiiRedactor();
$safe = $r->redact('คุณสมชาย โทร 081-234-5678 อีเมล somchai@example.com แจ้งว่าสินค้าเสีย');
// คุณสมชาย โทร [PHONE_2] อีเมล [EMAIL_1] แจ้งว่าสินค้าเสีย
echo $safe, PHP_EOL;

สังเกตว่าชื่อ "สมชาย" ยังหลุดไป เพราะ regex จับชื่อคนภาษาไทยได้ยากมาก นี่คือข้อจำกัดจริงของการ redact ด้วย pattern วิธีที่ได้ผลกว่าคือ เลือกเฉพาะ field ที่จำเป็น ตั้งแต่ตอน query เช่น ส่งแค่ข้อความร้องเรียนกับหมวดสินค้า ไม่ส่งชื่อ ที่อยู่ หรือรหัสลูกค้าเลย แล้วใช้ redactor เป็นชั้นป้องกันเสริมสำหรับข้อความอิสระที่ผู้ใช้พิมพ์มา

-- ดึงเฉพาะสิ่งที่งานต้องใช้ ไม่ใช่ SELECT *
SELECT t.id, t.category, t.message
FROM support_ticket t
WHERE t.created_at >= now() - interval '7 days';

เช็กลิสต์ก่อนเปิดฟีเจอร์ที่ส่งข้อมูลเข้า AI

1. ระบุว่าจะส่ง field อะไรบ้าง และตัดทุก field ที่งานไม่จำเป็นต้องใช้
2. มีข้อมูลอ่อนไหวปนอยู่หรือไม่ ถ้ามี หยุดและปรึกษา DPO
3. วัตถุประสงค์นี้อยู่ใน privacy notice และมีฐานกฎหมายรองรับหรือไม่
4. ใช้บัญชีองค์กรที่มีข้อตกลงด้านข้อมูล ไม่ใช่บัญชีส่วนตัว
5. รู้ว่าข้อมูลไปประมวลผลที่ประเทศไหน และฝ่ายกฎหมายรับทราบ
6. ไม่ log prompt ที่มีข้อมูลส่วนบุคคลเต็ม ๆ ไว้ในระบบของเราเองด้วย
7. บันทึกกิจกรรมการประมวลผลนี้ไว้ในเอกสารขององค์กร (Record of Processing Activities)

ข้อ 6 มักถูกลืม หลายทีมระวังฝั่งผู้ให้บริการ แต่กลับเก็บ prompt และ response ทั้งก้อนไว้ใน log ของตัวเองแบบไม่มีกำหนดลบ ซึ่งก็คือการสร้างแหล่งข้อมูลส่วนบุคคลใหม่ที่ไม่มีใครดูแล

สรุป

• ข้อมูลที่ระบุตัวคนได้ทั้งทางตรงและทางอ้อมคือข้อมูลส่วนบุคคล ส่วนข้อมูลอ่อนไหวต้องระวังเป็นพิเศษและโดยหลักไม่ควรส่งเข้า AI ภายนอก
• ทุกการประมวลผลต้องมีฐานกฎหมายและอยู่ในวัตถุประสงค์ที่แจ้งไว้ ผู้ให้บริการ AI มักอยู่ในบทบาทผู้ประมวลผลที่ควรมีข้อตกลงรองรับ
• การส่งข้อมูลไปต่างประเทศมีหลักเกณฑ์เฉพาะ วิธีลดความเสี่ยงที่ดีที่สุดคือไม่ส่งข้อมูลส่วนบุคคลออกไปตั้งแต่แรก
• เลือก field ให้น้อยที่สุด แล้วค่อยใช้ masking หรือ pseudonymisation เป็นชั้นเสริม
• บทความนี้ไม่ใช่คำแนะนำทางกฎหมาย ให้ปรึกษา DPO หรือนักกฎหมายก่อนตัดสินใจจริง

ลองทำ

เลือกฟีเจอร์หนึ่งในระบบของคุณที่อยากใช้ AI ช่วย เช่น สรุปตั๋ว support แล้วเขียนตารางสามคอลัมน์ "field ที่มี / จำเป็นไหม / ระดับข้อมูล" ให้ครบทุก field จากนั้นนำ PiiRedactor ไปทดสอบกับข้อความตัวอย่าง 20 รายการ (ใช้ข้อมูลสมมติ ไม่ใช่ข้อมูลจริง) จดว่ามีอะไรหลุดบ้าง แล้วนำผลทั้งหมดไปคุยกับ DPO หรือหัวหน้าทีมว่าฟีเจอร์นี้ควรเดินหน้าแบบไหน