AI Support Bot ไม่ควรเป็น DevOps Console: ทำไม AI หน้าบ้านต้องแยกจากระบบหลังบ้าน

หลายธุรกิจเริ่มใช้ AI support bot จากโจทย์ง่าย ๆ:

ตอบลูกค้าให้เร็วขึ้น ลดงานแอดมิน และช่วยให้ลูกค้าได้คำตอบโดยไม่ต้องรอคน

ตอนเริ่มต้น มันมักปลอดภัยพอสมควร เพราะ bot รู้แค่ FAQ, product guide, ราคา, วิธีใช้งาน, ขั้นตอนสมัคร, วิธีติดต่อ support

แต่พอทีมเริ่มเห็นว่า AI ช่วยได้จริง ความต้องการจะค่อย ๆ ขยับ:

• ให้ AI เช็ค order ได้ไหม
• ให้ AI เช็คสิทธิ์เรียนได้ไหม
• ให้ AI update CRM ได้ไหม
• ให้ AI ดูสถานะระบบได้ไหม
• ให้ AI เช็ค log ได้ไหม
• ให้ AI restart service ได้ไหม
• ให้ AI สร้าง coupon หรือส่ง broadcast ได้ไหม

คำถามเหล่านี้ไม่ผิดครับ

แต่ถ้าเอาทุกอย่างไปใส่ใน bot ตัวเดียวที่คุยกับลูกค้าอยู่ เราจะได้ปัญหาใหญ่แบบเงียบ ๆ:

AI support bot เริ่มกลายเป็น DevOps console

และนั่นเป็น design smell ที่ควรแก้ตั้งแต่สถาปัตยกรรม ไม่ใช่แค่แก้ prompt

1) ปัญหาไม่ใช่ AI โง่ แต่คือ AI รู้เกินหน้าที่

เวลาคนพูดเรื่อง AI support bot เรามักโฟกัสว่า “มันตอบถูกไหม”

แต่ในโลกที่ AI เริ่มใช้ tools ได้ คำถามที่สำคัญกว่าอาจเป็น:

มันมีสิทธิ์ทำอะไรได้บ้าง

ถ้า bot ตอบ FAQ ผิด ความเสียหายคือความเข้าใจผิด

แต่ถ้า bot มี tool ที่แตะ CRM, ระบบจ่ายเงิน, LINE broadcast, server log, deploy command หรือ customer export ความเสียหายไม่ใช่แค่คำตอบผิดแล้ว

มันอาจกลายเป็น:

• ลูกค้าเห็นข้อมูลที่ไม่ควรเห็น
• bot เผย internal status หรือ incident detail ออกไป
• prompt injection หลอกให้ bot เรียก tool ผิด
• admin debug phrase หลุดใน public chat แล้วกลายเป็นคำสั่งจริง
• support ticket กลายเป็นช่องทางเข้าหลังบ้าน
• bot ทำ external action เช่น ส่ง email, broadcast, refund, revoke access โดยไม่ผ่าน approval ที่ถูกต้อง

นี่คือเหตุผลที่ OWASP AI Agent Security Cheat Sheet เน้นเรื่อง tool security, least privilege, human approval สำหรับ high-impact actions, audit trail และการแยก toolset ตาม trust level

พูดแบบภาษาธุรกิจ: AI support bot ไม่ควรมี key เข้าห้องเครื่องเพียงเพราะมันคุยกับลูกค้าเก่ง

2) Prompt ไม่ใช่กำแพงที่แข็งพอ

หลายทีมแก้ด้วย system prompt เช่น:

“ห้ามตอบเรื่อง internal ops” “ห้ามเปิดเผยข้อมูลระบบ” “ห้ามรันคำสั่งที่อันตราย”

ช่วยได้ระดับหนึ่ง แต่ไม่ควรเป็นกำแพงหลัก

เพราะ prompt เป็น instruction แต่ boundary ที่แท้จริงควรถูก enforce ที่ระบบ:

• bot ไม่มี tool นั้นตั้งแต่แรก
• bot ไม่มี credential นั้นตั้งแต่แรก
• bot เห็นเฉพาะข้อมูลที่บทบาทนี้ควรเห็น
• bot อยู่ใน channel scope ที่ถูกต้อง
• action เสี่ยงต้องผ่าน policy gateway
• approval ต้องผูกกับ exact action และ exact parameter
• log ต้องตามกลับได้

OWASP LLM Prompt Injection Prevention Cheat Sheet เตือนชัดว่า external content เช่น user message, web page, document, email และ tool output ต้องถือเป็น untrusted input

ในงาน support นี่สำคัญมาก เพราะ support bot อยู่ใกล้ untrusted input ตลอดเวลา

ลูกค้าพิมพ์อะไรเข้ามาก็ได้ แนบ screenshot อะไรก็ได้ ส่ง email/ticket ที่มีข้อความแปลก ๆ มาก็ได้ copy prompt injection จากเว็บมาก็ได้

ถ้า bot หน้าบ้านอ่าน input เหล่านี้ และในเวลาเดียวกันมี tool หลังบ้านที่แรงเกินไป นั่นคือการเอาข้อมูลที่ไม่น่าเชื่อถือไปวางติดกับปุ่มควบคุมระบบ

ไม่ควรออกแบบแบบนั้น

3) แยก Public Support กับ Internal Ops เป็นคนละ lane

ผมชอบคิดเรื่องนี้เป็น 2 lane

Lane 1: Public Support

นี่คือ AI ที่ลูกค้าคุยด้วย

หน้าที่ของมันคือช่วยลูกค้าในขอบเขตที่ปลอดภัย:

• ตอบ FAQ
• อธิบาย product
• แนะนำวิธีสมัครหรือใช้งาน
• ช่วย troubleshoot ขั้นพื้นฐาน
• เช็คสถานะทั่วไปแบบไม่เปิดเผยข้อมูล sensitive
• รับเรื่องและส่งต่อทีม support
• สรุปปัญหาให้คนรับช่วงต่อ

Tool ของ lane นี้ควรเป็น read-only หรือ low-risk เป็นหลัก เช่น:

• search knowledge base
• fetch public product catalog
• check entitlement แบบ scoped และไม่โชว์ข้อมูลเกินจำเป็น
• create support ticket
• escalate to human

สิ่งที่ lane นี้ไม่ควรมี:

• shell/terminal
• server logs
• deploy/restart command
• unrestricted CRM export
• payment admin action
• LINE/Facebook broadcast action
• API key หรือ secret
• internal incident notes
• system prompt/debug details

ถ้าลูกค้าถามเกินขอบเขต bot ควรตอบแบบสุภาพและส่งต่อ ไม่ใช่พยายามทำให้ได้ทุกอย่าง

Lane 2: Internal Ops

นี่คือ AI สำหรับทีมภายใน

มันอาจช่วยเรื่อง:

• ดู status
• อ่าน log ที่จำเป็น
• เปิด incident checklist
• สรุป error ให้ทีม dev
• สร้าง task ให้ทีม support
• รัน diagnostic read-only
• เตรียม patch หรือ rollback plan
• update CRM ตาม approval
• ช่วย admin ตรวจ config

แต่ lane นี้ต้องมีเงื่อนไขหนักกว่า:

• ผู้ใช้ต้อง authenticate
• role ต้องตรงกับ action
• tool ต้อง scoped
• write/destructive/external action ต้อง approval
• approval ต้องแสดง preview ชัดเจน
• ต้องมี audit log
• ต้องมี rollback path
• secret ไม่ควรเข้า context ตรง ๆ
• ข้อมูลลูกค้าต้องถูก redact ตามความจำเป็น

สรุปคือ Internal Ops AI อาจเก่งกว่า Public Support AI ได้ แต่ต้องอยู่ในห้องที่มีกุญแจ มี log และมีคนรับผิดชอบ

4) สิ่งที่ Microsoft ทำใน Copilot Studio สะท้อนทิศทางนี้

Microsoft Copilot Studio มี data policies สำหรับ agents ที่ admin ใช้ควบคุมได้ เช่น:

• บังคับ authentication
• block knowledge sources บางประเภท
• block connectors ที่ใช้เป็น tools
• block HTTP requests
• block skills
• block event triggers
• block การ publish ไปบาง channel

ผมไม่ได้ยกมาเพื่อบอกว่าทุกคนต้องใช้ Copilot Studio

แต่ยกมาเพื่อชี้ pattern ว่า platform ฝั่ง enterprise กำลังไปทางเดียวกัน:

agent capability ต้องถูก govern ที่ระดับ policy ไม่ใช่ฝากไว้กับคำพูดใน prompt

ตัวอย่างเช่น ถ้า public bot ไม่ควรยิง HTTP request ออกไปไหน ก็ block HTTP connector

ถ้า bot ไม่ควรใช้ tool ที่เชื่อมกับระบบหลังบ้าน ก็ block connector นั้น

ถ้า bot ไม่ควรทำงานแบบ event trigger โดยไม่มีคนเริ่ม ก็ block trigger

นี่คือวิธีคิดที่ควรเอามาใช้ แม้เราจะ build ระบบเองบน stack อื่น

5) Trust boundary สำคัญกว่า model choice

หลายทีมเลือก model ก่อน แล้วค่อยคิด governance ทีหลัง

แต่สำหรับ customer-facing AI ผมคิดว่าควรกลับลำดับ:

1. ใครเป็นคนคุยกับ AI
2. คุยผ่าน channel ไหน
3. AI อยู่ในบทบาทอะไร
4. ข้อมูลไหนอ่านได้
5. tool ไหนเรียกได้
6. action ไหนต้อง approval
7. ถ้าพัง ใครเห็น log และ rollback ยังไง
8. ถ้าถูกโจมตี blast radius อยู่ตรงไหน

หลังจากนั้นค่อยเลือก model

เพราะ model ที่เก่งขึ้นจะทำให้ระบบดีขึ้นก็ต่อเมื่อ boundary ถูกออกแบบไว้ดีแล้ว

ถ้า boundary ผิด model ที่เก่งขึ้นอาจทำให้พังเร็วขึ้นด้วยซ้ำ

6) Pattern ที่ผมแนะนำ: Policy Gateway คั่นกลาง

ถ้าจะออกแบบจริง ผมไม่ให้ support bot เรียก tool สำคัญตรง ๆ

ควรมี policy gateway หรือ action broker คั่นกลาง

ทุกครั้งที่ AI จะทำ action ระบบควรตรวจอย่างน้อย:

• actor: ใครเป็นคนขอ
• channel: มาจาก public chat, internal chat, admin console หรือ cron
• role: ลูกค้า, support, admin, devops, owner
• action: read, write, send, delete, deploy, restart, export
• target: resource ไหน
• data class: public, customer, internal, secret, production
• risk level: low, medium, high, critical
• approval: มีไหม ผูกกับ parameter นี้จริงไหม หมดอายุหรือยัง
• audit: log พอไหม
• rollback: ถ้า action นี้ผิด แก้กลับได้ไหม

ถ้าเงื่อนไขไม่ครบ ให้ fail closed

ไม่ใช่ “ให้ AI ลองทำดูก่อน แล้วค่อยดูว่าพังไหม”

7) ตัวอย่าง rule แบบง่ายสำหรับ support bot

ลองตั้ง rule แบบนี้ก่อนก็ได้:

Allowed by default

• ตอบจาก public docs
• ตอบจาก FAQ ที่ approved แล้ว
• แนะนำวิธีใช้งานทั่วไป
• สร้าง support ticket
• ส่งต่อ human support
• เช็คสิทธิ์เรียนหรือ order แบบ scoped โดยแสดงเฉพาะผลที่ลูกค้าคนนั้นควรรู้

Requires internal auth

• ดูประวัติ support ทั้งหมดของลูกค้า
• update CRM field
• grant/revoke course access
• resend entitlement email
• generate coupon ให้ลูกค้า
• ดู payment/admin status แบบละเอียด

Requires approval

• ส่ง email จริง
• broadcast LINE/Facebook/email
• refund หรือ cancel subscription
• bulk update CRM
• เปลี่ยนสิทธิ์ course
• publish content
• deploy หรือ restart service

Never exposed to public support bot

• shell command
• raw server log
• API keys
• .env values
• production DB console
• internal incident note
• unrestricted export
• admin-only runbook ที่มีคำสั่งระบบ

แค่นี้ก็ลดความเสี่ยงได้มากแล้ว

8) NIST AI RMF มองเรื่องนี้เป็นวงจร ไม่ใช่ checklist ครั้งเดียว

ถ้าเอา NIST AI RMF มาแปลเป็นภาษาทีมทำงาน เรื่องนี้เข้ากับ 4 คำมาก:

• Govern: ใครมีสิทธิ์กำหนด policy และใครรับผิดชอบเมื่อ AI ทำ action
• Map: AI อยู่ใน context ไหน ลูกค้าคุยจากไหน ข้อมูลอะไรไหลผ่านระบบ
• Measure: วัดยังไงว่า bot ไม่ตอบเกินสิทธิ์ ไม่เรียก tool ผิด ไม่ leak ข้อมูล
• Manage: ถ้าเกิด incident จะหยุด แก้ rollback และปรับ policy ยังไง

นี่ทำให้เราไม่มอง AI support bot เป็นแค่ “prompt + model + knowledge base”

แต่มองเป็นระบบปฏิบัติการย่อยที่ต้องมี governance เหมือน software system อื่น

9) บทเรียนสำหรับธุรกิจไทย

ธุรกิจไทยจำนวนมากทำงานผ่าน LINE, Facebook inbox, website chat, email, Google Sheet, CRM เบา ๆ และ admin หลายคน

พอ AI เข้ามา สิ่งที่ดูน่าทำที่สุดคือเอา AI ไปอยู่หน้าบ้านก่อน เพราะเห็นผลเร็ว

แต่ถ้าไม่วาง boundary ตั้งแต่ต้น AI หน้าบ้านจะค่อย ๆ ดูด context หลังบ้านเข้าไปเรื่อย ๆ:

• วันนี้เพิ่ม FAQ
• พรุ่งนี้เพิ่ม order lookup
• สัปดาห์หน้าเพิ่ม CRM update
• เดือนหน้าเพิ่ม broadcast
• อีกหน่อยเพิ่ม server status

สุดท้าย bot ตัวเดียวกลายเป็นทั้งแอดมิน เซลส์ support ops devops และ owner proxy

ฟังดูประหยัดคน แต่จริง ๆ คือรวม blast radius ไว้ในจุดเดียว

ทางที่ปลอดภัยกว่าคือแยกบทบาท:

• AI support สำหรับลูกค้า
• AI ops สำหรับทีมภายใน
• AI admin สำหรับ owner หรือ authorized operator
• queue/approval สำหรับ action ที่เสี่ยง

แล้วให้แต่ละตัวมี memory, tool, channel และ permission ของตัวเอง

10) มุมมองของผม

AI support bot ที่ดีไม่ใช่ bot ที่ตอบได้ทุกเรื่อง

แต่คือ bot ที่รู้ว่าเรื่องไหนควรตอบ เรื่องไหนควรเงียบ เรื่องไหนควรถามเพิ่ม และเรื่องไหนควรส่งต่อคนที่มีสิทธิ์

สำหรับผม คำว่า “AI รู้พอดี” สำคัญกว่า “AI รู้เยอะ”

เพราะในงานลูกค้า ความไวสำคัญก็จริง แต่ความไว้ใจสำคัญกว่า

ถ้า support bot ตอบลูกค้าเร็วขึ้น แต่เปิดช่องให้ระบบหลังบ้านถูกแตะจาก public chat แบบอ้อม ๆ นั่นไม่ใช่ productivity

นั่นคือการเอาห้องเครื่องไปตั้งไว้หน้าร้าน

ธุรกิจที่อยากใช้ AI จริงจังควรเริ่มจากคำถามนี้ก่อน:

AI ตัวนี้อยู่ฝั่งไหนของกำแพง

ถ้าอยู่ฝั่งลูกค้า ให้มันเป็นผู้ช่วยลูกค้าที่ดี

ถ้าอยู่ฝั่ง ops ให้มันเป็นผู้ช่วยทีมที่มี guardrail, approval และ audit proof

อย่าเอาสองบทบาทนี้มาปนกันเพียงเพราะ model ตัวเดียวทำได้ทั้งคู่

AI ที่ทำได้ทุกอย่าง ไม่ได้แปลว่าควรได้สิทธิ์ทุกอย่าง