Case Study: Local AI Triage Chatbot สำหรับคลินิกไทย ภายใต้ PDPA

สรุปสั้น: Case study สมมติเพื่อแสดงแนวคิดเท่านั้น — คลินิกขนาดเล็กในไทยต้องการ AI triage chatbot แต่ส่งข้อมูลอาการของผู้ป่วยไป cloud API ไม่ได้ตาม PDPA การติดตั้ง Qwen3.6-35B local บน GPU 24 GB ใบเดียว (~180,000 บาทฮาร์ดแวร์ + ~30,000 บาทติดตั้ง) ทำให้ทุกคำในบทสนทนาของผู้ป่วยอยู่ใน LAN ของคลินิก โดยยังได้ triage assistant ที่ใช้งานได้จริงทั้งภาษาไทยและอังกฤษ

ข้อเท็จจริงสำคัญ

• นี่คือ scenario สมมติเพื่อแสดงแนวคิด ไม่ใช่ client engagement จริง คลินิกที่อธิบายในนี้ไม่มีอยู่จริง
• PDPA ไทยจัดข้อมูลอาการผู้ป่วยเป็น sensitive personal data — การโอนข้ามประเทศไป cloud ต้องมี explicit consent และ adequate protection ซึ่ง consumer AI API ทำให้ไม่ได้
• Local AI workstation ใบเดียว: GPU 24 GB + Qwen3.6-35B-A3B รันที่ ~138 tokens/sec สำหรับคลินิก 5 หมอ
• Hardware + ติดตั้งครั้งเดียว: ประมาณ 210,000-310,000 บาท; ค่าใช้จ่ายต่อเนื่องต่ำ (ค่าไฟ ~1,000 บาท/เดือน + optional quarterly support)
• เทียบกับ cloud API equivalent: ถูกกว่า 50-70% ใน 3 ปี และ ถูก PDPA จริง
• Ladder โมเดลแนะนำ: Qwen3.6-35B-A3B default, fallback dense Qwen3-32B สำหรับ prompt ที่ยากกว่า (ศัพท์แพทย์เฉพาะทาง)

ทำไมถึงเขียน case study ชิ้นนี้

เราประกาศความโปร่งใสด้าน editorial ดังนั้นขอพูดตรง ๆ ตั้งแต่ต้น: นี่ไม่ใช่ client engagement จริง ยังไม่มีคลินิกไทยไหนจ้างเรา เราเขียนชิ้นนี้เป็น illustrative case — เพื่อแสดงว่าเราคิดอย่างไรกับ PDPA-sensitive scenario ที่พบบ่อย — ก่อนที่จะมีรายชื่อ engagement จริงให้อ้างอิง เมื่อมี case study จริงที่ได้รับ consent จากลูกค้า เราจะระบุชัดเจนและเผยแพร่แยก

ทำไมถึงต้องเขียน case สมมติด้วย? เพราะ “จริง ๆ แล้วการติดตั้ง local AI สำหรับ healthcare ในไทยหน้าตาเป็นแบบไหน?” คือคำถามที่ลูกค้าผู้สนใจจะถามก่อนจ้างใคร การมี capability list คลุม ๆ บนหน้า consulting ตอบไม่ได้ การเดินผ่าน scenario เป็นรูปธรรมตอบได้ — แม้ scenario นั้นจะเป็น composite ไม่ใช่ประวัติศาสตร์จริง

Scenario (สมมติ)

คลินิกหลายสาขาในกรุงเทพ 5 หมอ มีคนไข้วันละประมาณ 60 คน ผู้บริหารขอให้สำรวจ AI-assisted triage — chatbot ที่ถามอาการ ประวัติครอบครัว และยาที่ทานอยู่แบบ structured ก่อนผู้ป่วยพบพยาบาล IT lead ของคลินิกไปงาน AI vendor conference กลับมาพร้อม quote จาก 3 แพลตฟอร์ม cloud-based Compliance officer ปฏิเสธทั้ง 3 หลังคุยกับทนายความ 20 นาที จุดที่ติดคือ: ทุก quote มีการส่งข้อมูลอาการออกจากประเทศไทย ซึ่งภายใต้ PDPA ต้องมี explicit consent ต่อผู้ป่วยแต่ละรายสำหรับการโอนข้ามประเทศ หรือ demonstrated adequate-protection arrangement ทั้งสองอย่างไม่สามารถทำให้ practical สำหรับ use case ประจำ

คลินิกติดต่อเราเพื่อหาทางเลือก on-premise

ทำไมเรื่องนี้สำคัญต่อ healthcare ไทยในปี 2026

ข้อมูลผู้ป่วยในไทยอยู่ใต้ Personal Data Protection Act B.E. 2562 โดย Section 26 จัดข้อมูลด้านสุขภาพเป็น sensitive personal data และ Section 28 จำกัดการโอนข้ามประเทศไปยัง jurisdiction ที่มีการคุ้มครอง “adequate” — มาตรฐานที่ทั้ง US และ jurisdiction ส่วนใหญ่ใน APAC ยังไม่ได้รับการรับรอง ในทางปฏิบัติ องค์กร healthcare ที่ route ข้อมูลผ่าน cloud API ของ OpenAI, Anthropic หรือ Google ทำงานอยู่ใน legal grey zone ที่ต้นทุนจะปรากฏก็ต่อเมื่อเกิดเรื่อง (data breach, regulator inquiry, คำร้องจากผู้ป่วย)

Local deployment หลบคำถามเรื่องการโอนทั้งหมด ถ้าทั้งโมเดลและข้อมูลอยู่บน workstation ใน server room ของคลินิก = ไม่มีการโอนข้ามประเทศเกิดขึ้น = ไม่ต้องวิเคราะห์เรื่อง consent หรือ adequate protection สำหรับ flow นี้

เงื่อนไขที่เราจะทำงานภายใน

• Data residency: ไม่มีคำพูดผู้ป่วย, คำอธิบายอาการ, หรือ chat transcript ออกจาก LAN ของคลินิก
• เพดานงบ: คลินิกเล็ก capex ประจำ project IT ใหญ่ส่วนใหญ่ 200,000-300,000 บาท
• ภาษา: ผู้ป่วยส่วนใหญ่พูดไทย expat บางคนพูดอังกฤษ ระบบต้องจัดการทั้งสองได้โดยไม่ต้อง round-trip ผ่าน translation service
• Latency: ผู้ป่วยคาดหวัง ack ภายใน ~3 วินาทีหลังกดส่ง ประโยค triage มี 5-10 turn = รวมใช้เวลา ≤ 90 วินาที
• ความเป็นจริงของการใช้งาน: IT ของคลินิกมักเป็น 1 คนที่ดูแลทุกอย่างอื่นด้วย สิ่งที่เราติดตั้งต้องเสถียรโดยไม่ต้อง maintain รายสัปดาห์

สิ่งที่เราจะเสนอ

ฮาร์ดแวร์: workstation ใบเดียว GPU consumer 24 GB (RTX 5090 หรือเทียบเท่า), RAM 64 GB, SSD NVMe 2 TB, พ่วง UPS, วางใน server closet ที่มีอยู่ Hardware capex ประมาณ 180,000-250,000 บาทขึ้นอยู่กับ chassis และ support contract

Software stack:

• Ollama เสิร์ฟ Qwen3.6-35B-A3B-Q4 เป็น default, Qwen3-32B dense standby สำหรับ ~10% ของ prompt ที่ Qwen3.6 baseline ทำได้ไม่ดี
• Open WebUI เป็น chat front-end ของผู้ป่วย (rebrand ตามสไตล์คลินิก)
• Python wrapper บาง ๆ ที่ enforce triage flow — คำถาม structured พร้อม validation, ไม่ให้ free-form deviation — แทนที่จะยื่น blank canvas ให้โมเดล
• PostgreSQL local เข้ารหัสสำหรับ chat transcripts (patient ID, timestamp, triage outcome) เก็บ 90 วันตาม policy คลินิก
• Tailscale หรือเทียบเท่าสำหรับ remote admin โดยไม่เปิด port ออก internet

ข้อจำกัดโมเดล: system prompt ห้ามโมเดลวินิจฉัย ให้แนะนำพบหมอเสมอ route prompt ที่เป็น red flag (เจ็บหน้าอก, อาการทาง neurological, เลือดออกมาก) ไปที่ human escalation ทันที — นี่คือ triage assistant ไม่ใช่ diagnostic assistant

ทำไม Qwen3.6 เป็น default แทน Qwen3-32B: ความเร็ว ที่ 138 tokens/sec บน 35B-A3B MoE คำตอบ triage 120 tokens ทั่วไปสตรีมให้ผู้ป่วยใต้ 1 วินาที 32B dense แม่นกว่าใน edge case แต่ throughput ประมาณครึ่งเดียว — เหมาะเป็น fallback ไม่ใช่ default

ผลลัพธ์ที่คาดหวัง

ขอบอกตรง ๆ: เราอธิบายสิ่งที่ setup แบบนี้มอบให้ได้โดยปกติ ไม่ใช่ตัวเลขเฉพาะที่รับประกัน

• ลดเวลา intake: ผู้ป่วยทำ structured symptom intake เสร็จก่อนเจอพยาบาล ประหยัดเวลา consultation flow โดยเฉลี่ย 10-15 นาที
• มุมมองแรกของหมอ: structured summary ของอาการที่ผู้ป่วยรายงาน, ยาที่ทานอยู่, และ flag words รออยู่ให้หมอตอนเข้าห้อง
• ท่าทาง compliance: ป้องกันตัวได้ตาม PDPA โดยไม่ต้อง consent ต่อผู้ป่วยรายบุคคลสำหรับการโอน; compliance officer ของคลินิกชี้ไปที่ data-flow diagram แล้วพูดได้ว่า “ไม่มีอะไรออกจากตึก”
• ความเสถียร: uptime ระดับเดียวกับ clinic-server deployment อื่น (~99% พร้อมเงื่อนไขฤดูร้อนไทยที่ไฟดับบางครั้ง จึงมี UPS)

คำคัดค้านที่พบบ่อย

“ถ้าโมเดลให้คำแนะนำทางการแพทย์ที่อันตรายล่ะ?” เราไม่ให้ System prompt ห้ามวินิจฉัย และ direct red-flag cases ไป human escalation ทันที เราทำ adversarial test ก่อน deploy โดยมีเภสัชกรตรวจ: prompt red-flag หลายร้อย prompt ที่โมเดลต้องปฏิเสธการวินิจฉัย ถ้าเจอ fail = tune prompt แล้ว retest จนกว่าจะผ่าน

“เราไม่มีคน IT ดูแลเรื่องนี้” IT lead ของคลินิกทำสิ่งใหม่แค่อย่างเดียว: health check รายเดือน (อุณหภูมิ CPU, พื้นที่ disk, version sanity) อย่างอื่น log เข้า dashboard ที่เรา review ใน quarterly support call ถ้าต้อง update โมเดล เราจัดการ remote พร้อม approve จากคลินิก

“ถ้าวันหนึ่งคุณไม่อยู่ล่ะ?” ทุกอย่างที่เราติดตั้งเป็น open-weight และ open-source คลินิกเป็นเจ้าของฮาร์ดแวร์, model weights, และโค้ด vendor อื่นหรือคน internal รับช่วงต่อได้ เรา document ให้ชัดพอที่เป็นไปได้

Pattern นี้เหมาะกับใคร

• คลินิกเฉพาะทาง, ทันตกรรม, และ outpatient center ที่มี 3-15 หมอ และคนไข้น้อยกว่า 100 คนต่อวัน
• สำนักกฎหมายที่ต้องการ pattern เดียวกันสำหรับ contract review (front-end ต่าง infrastructure เดียวกัน)
• สำนักงานบัญชีที่จัดการคำถามเอกสารภาษีภายใต้เงื่อนไข PDPA

ไม่เหมาะกับ: โรงพยาบาลที่มีการใช้งานหลายพันคน (ต้องการ load balancing จริงจัง), เครือคลินิกระดับชาติ (ต้องการ centralized policy management), และใครก็ตามที่ไม่สามารถ commit เป็นเจ้าของฮาร์ดแวร์ระยะยาว

วิธีเริ่มต้น

ถ้าคุณกำลังพิจารณาทำแบบนี้ให้องค์กรจริง ขั้นถัดไปคือ free 30-minute scoping call ว่า pattern เหมาะไหม ส่งอีเมลถึง บรรณาธิการ พร้อมอธิบาย use case สั้น ๆ ตอบกลับภายใน 1 วันทำการ

ดู แพ็กเกจบริการ มี 3 แพ็กเกจมาตรฐาน scope เฉพาะทำได้ อ่าน มาตรฐานบรรณาธิการ ก่อนเพื่อรู้ว่าเราจะ/ไม่รับทำอะไร — น่าอ่านก่อน inquire