# สร้าง Custom Corporate AI และ Agent ใครรับผิดเมื่อตอบผิด

> ที่มา: https://phygital.co.th/insights/custom-corporate-ai-autonomous-agents-agency · เผยแพร่ 21 กันยายน 2564 · อ่าน 14 นาที · โดย PARANATH PANARATANA

องค์กรรับผิดต่อคำตอบของ AI ที่ติดตั้งเอง และ Agent ที่ลงมือทำได้ต้องแยกสิทธิ์ตามว่าการกระทำย้อนกลับได้หรือไม่ เกณฑ์ออกแบบจาก PHYGITAL AGENCY

## Key Takeaways

- **องค์กรรับผิดต่อคำตอบของ AI ที่ติดตั้งไว้เอง** — คณะตุลาการระงับข้อพิพาททางแพ่งของบริติชโคลัมเบียปฏิเสธข้ออ้างของสายการบินว่าแชทบอทเป็นนิติบุคคลแยกต่างหาก และสั่งให้ชดใช้ส่วนต่างค่าตั๋วในคดีปี 2567
- **Agent ที่ลงมือทำได้ต้องแยกสิทธิ์ตามว่าการกระทำย้อนกลับได้หรือไม่** — รายการความเสี่ยงของ OWASP สำหรับแอปพลิเคชัน LLM ฉบับ 2025 ระบุต้นเหตุไว้สามข้อ คือฟังก์ชัน สิทธิ์ และความเป็นอิสระที่มากเกินจำเป็น
- **AI ควรเห็นเอกสารได้เท่ากับคนที่ถาม ไม่ใช่เท่ากับทั้งองค์กร** — ระบบที่อ่านเอกสารทุกฉบับแล้วตอบทุกคนเหมือนกันทำให้เอกสารลับรั่วผ่านคำตอบได้

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

Custom Corporate AI คือระบบ AI ที่ตอบคำถามจากเอกสารขององค์กรเอง เช่น คู่มือสินค้า นโยบายการคืนเงิน หรือระเบียบภายใน ส่วน Autonomous Agent คือระบบที่ไปไกลกว่าการตอบ คือลงมือทำงานต่อได้เอง เช่น ร่างอีเมล เปิดคำสั่งซื้อ หรือนัดหมาย สองอย่างนี้ต่างกันตรงจุดที่ความผิดพลาดเกิดขึ้น ระบบแรกผิดที่ถ้อยคำ ระบบที่สองผิดที่การกระทำ งานออกแบบระบบกลุ่มนี้ที่ บริษัท ฟิจิทัล เอเจนซี จำกัด (PHYGITAL AGENCY) รับจากองค์กรทั่วประเทศ ทำจากทีมพัฒนาในเชียงใหม่ผ่านการประชุมทางไกลเป็นหลัก และเริ่มจากคำถามนี้ก่อนการเขียนโค้ดบรรทัดแรก

## องค์กรรับผิดต่อคำตอบของ AI ที่ตัวเองติดตั้ง

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

[บทวิเคราะห์ของ Dentons Data ลงวันที่ 15 กุมภาพันธ์ 2567](https://www.dentonsdata.com/airline-ordered-to-compensate-a-b-c-man-because-its-chatbot-provided-inaccurate-information/) สรุปคดี Moffatt v. Air Canada (2024 BCCRT 149) ของคณะตุลาการระงับข้อพิพาททางแพ่งแห่งบริติชโคลัมเบีย แชทบอทของสายการบินบอกผู้โดยสารว่าขอค่าโดยสารอัตราพิเศษกรณีไว้ทุกข์ย้อนหลังได้ภายใน 90 วันนับจากวันออกตั๋ว ซึ่งไม่ตรงกับนโยบายจริง สายการบินโต้แย้งว่าแชทบอทเป็นนิติบุคคลแยกต่างหากที่รับผิดชอบการกระทำของตัวเอง คณะตุลาการปฏิเสธข้ออ้างนี้ โดยระบุว่าแชทบอทยังเป็นเพียงส่วนหนึ่งของเว็บไซต์ของสายการบิน และสายการบินต้องรับผิดชอบข้อมูลทั้งหมดบนเว็บไซต์ของตัวเอง ผลคือสายการบินต้องรับผิดฐานให้ข้อมูลผิดโดยประมาทเลินเล่อ และชดใช้ 650.88 ดอลลาร์แคนาดา พร้อมดอกเบี้ยและค่าธรรมเนียม

คดีนี้ตัดสินตามกฎหมายแคนาดา และยังไม่มีคำพิพากษาไทยในประเด็นเดียวกันให้อ้างอิงได้ สิ่งที่ใช้ได้ทันทีคือหลักคิดในการออกแบบ ถ้าองค์กรไม่พร้อมรับผิดต่อคำตอบประเภทใด ก็ไม่ควรให้ AI ตอบคำถามประเภทนั้นเองตั้งแต่แรก

### ใส่ข้อความว่า AI อาจตอบผิดไว้ใต้หน้าแชท พอหรือไม่

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

## คำตอบจากเอกสารองค์กรต้องบอกได้ว่ามาจากเอกสารฉบับไหน

ระบบที่ค้นเอกสารก่อนแล้วจึงเรียบเรียงคำตอบ หรือที่เรียกว่า RAG ลดโอกาสการแต่งคำตอบขึ้นเองได้ แต่ไม่ได้ทำให้หายไป ระบบยังอาจหยิบเอกสารผิดฉบับ ผสมข้อความจากสองฉบับที่ขัดกัน หรือเติมรายละเอียดที่ไม่มีในเอกสารเลย สิ่งที่ทำให้ตรวจได้คือทุกคำตอบต้องระบุว่าอ้างจากเอกสารฉบับไหน ส่วนไหน

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

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

### ทำไม AI ที่ค้นจากเอกสารแล้วยังตอบผิดได้

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

## สิทธิ์ของ Agent แยกตามว่าการกระทำย้อนกลับได้หรือไม่

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

[รายการความเสี่ยงอันดับต้นของแอปพลิเคชัน LLM ฉบับ 2025 ของ OWASP](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) ในหัวข้อ Excessive Agency อธิบายว่าเป็นช่องโหว่ที่ทำให้ระบบกระทำการที่สร้างความเสียหายจากผลลัพธ์ของโมเดลที่ผิดคาด กำกวม หรือถูกบิดเบือน ไม่ว่าสาเหตุจะมาจากอะไร และระบุต้นเหตุไว้สามข้อ คือฟังก์ชันมากเกินไป สิทธิ์มากเกินไป และความเป็นอิสระมากเกินไป แนวทางลดความเสี่ยงข้อหนึ่งคือให้มนุษย์อนุมัติการกระทำที่มีผลกระทบสูงก่อนระบบลงมือ

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

### Agent ที่ต้องรอคนอนุมัติทุกครั้ง ยังคุ้มที่จะทำไหม

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

## AI เห็นเอกสารได้เท่ากับคนที่ถาม

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

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

อีกเรื่องที่ต้องตัดสินคือเอกสารที่มีข้อมูลส่วนบุคคลของลูกค้าหรือพนักงาน การนำเอกสารกลุ่มนี้เข้าระบบ AI คือการใช้ข้อมูลเพื่อวัตถุประสงค์ใหม่ ซึ่งต้องตรวจกับวัตถุประสงค์ที่แจ้งไว้เดิม หลักการเดียวกับที่อธิบายไว้ใน[ที่ปรึกษาวางโครงสร้าง MarTech ย้ายข้อมูลออกได้แค่ไหน](https://phygital.co.th/insights/martech-architect-consultancy) เรื่องลำดับข้อมูลก่อนเครื่องมือ

### ข้อมูลที่ส่งเข้า AI จะถูกนำไปฝึกโมเดลสาธารณะไหม

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

## ชุดคำถามทดสอบก่อนเปิดใช้ และทุกครั้งที่เอกสารเปลี่ยน

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

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

### ชุดคำถามทดสอบควรมีกี่ข้อ

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

## ช่วงแรกหลังเปิดใช้ ฟิจิทัล เอเจนซี เฝ้าดูอะไรบ้าง

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

ทั้งสามกลุ่มถูกนำไปแก้ที่ต้นทาง คือเพิ่มหรือแก้เอกสาร ปรับเงื่อนไขของ Agent และเพิ่มคำถามเข้าชุดทดสอบ การแก้ที่ข้อความสั่งงานของ AI อย่างเดียวโดยไม่แก้เอกสารมักทำให้ปัญหาย้ายไปโผล่ที่คำถามอื่น งานส่งต่อบทสนทนาให้เจ้าหน้าที่ ซึ่งเป็นทางออกของคำถามที่ระบบตอบไม่ได้ อธิบายไว้ใน[รับเซ็ตระบบ Chatbot AI กับหน้าต่างเวลาที่แพลตฟอร์มกำหนด](https://phygital.co.th/insights/ai-chatbot-setup-agency)

### ใครในองค์กรควรเป็นเจ้าของระบบ AI หลังส่งมอบ

ควรแยกเจ้าของเป็นสองบทบาท บทบาทแรกคือเจ้าของเนื้อหา ซึ่งรับผิดชอบให้เอกสารถูกต้องและทันสมัย มักเป็นฝ่ายที่ดูแลนโยบายหรือสินค้านั้นอยู่แล้ว บทบาทที่สองคือเจ้าของระบบ ซึ่งดูแลสิทธิ์การเข้าถึง ชุดทดสอบ และการอนุมัติของ Agent การรวมสองบทบาทไว้ที่ฝ่ายไอทีฝ่ายเดียวทำให้เอกสารล้าสมัยโดยไม่มีใครรู้ เพราะฝ่ายไอทีไม่รู้ว่านโยบายเปลี่ยนเมื่อไร ระบบ AI ที่ต้องพูดแทนแบรนด์ต่อหน้าผู้ชมจำนวนมากพร้อมกัน เช่น ผู้นำเสนอเสมือนในการขายสด มีเงื่อนไขเรื่องการเปิดเผยตัวตนเพิ่มอีกชั้น อธิบายไว้ใน[สร้าง Virtual KOL และไลฟ์ขายของด้วย AI ต้องติดป้ายเมื่อไร](https://phygital.co.th/insights/virtual-kol-ai-live-commerce-agency)

## เขียนรายการสิ่งที่ Agent ห้ามทำ ก่อนรายการสิ่งที่ทำได้

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

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

## สรุป

องค์กรรับผิดต่อคำตอบของ AI ที่ติดตั้งไว้เอง คดี Moffatt v. Air Canada ปี 2567 ปฏิเสธข้ออ้างว่าแชทบอทเป็นนิติบุคคลแยกต่างหาก ระบบที่ตอบจากเอกสารจึงต้องอ้างเอกสารได้และตอบว่าไม่ทราบเมื่อไม่พบข้อมูล ส่วน Agent ที่ลงมือทำได้ต้องแยกสิทธิ์ตามความยากในการย้อนกลับ ตามแนวทางเรื่อง Excessive Agency ของ OWASP ฉบับ 2025 และ AI ต้องเห็นเอกสารได้เท่ากับคนที่ถามเท่านั้น

## คำถามที่พบบ่อย (FAQ)

### Custom Corporate AI ต่างจากแชทบอทแบบตั้งสคริปต์อย่างไร

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

### ต้องเตรียมเอกสารแบบไหนก่อนเริ่มโครงการ

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

### ใช้ AI ตอบลูกค้าทางแชทได้เลย หรือควรเริ่มใช้ภายในก่อน

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

### ถ้าลูกค้าพยายามหลอกให้ AI ทำสิ่งที่ไม่ควรทำ ป้องกันอย่างไร

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

### ต้นทุนของระบบ AI องค์กรมาจากส่วนไหนบ้าง

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

### ระบบ AI ที่ทำแล้วย้ายไปใช้โมเดลของผู้ให้บริการรายอื่นได้ไหม

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

### องค์กรอยู่ต่างจังหวัด ประชุมและทดสอบระบบกับทีมอย่างไร

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

## อยากให้ AI ตอบคำถามและทำงานแทนทีม แต่ยังไม่แน่ใจว่าควรให้สิทธิ์ถึงไหน

ให้ PHYGITAL AGENCY ออกแบบระบบ AI ขององค์กรคุณ ตั้งแต่การแยกคำถามที่ต้องตอบด้วยนโยบายตรงตัว การอ้างเอกสารในทุกคำตอบ การจำกัดสิทธิ์ตามผู้ถาม ไปจนถึงขั้นอนุมัติของ Agent สำหรับทุกการกระทำที่มีผลต่อคนนอกหรือต่อเงิน

- [นัดประชุมผ่าน Google Meet](https://calendar.app.google/DotQdE7Ca8LZG6Us5)
- [เพิ่มเพื่อนใน LINE](https://lin.ee/J8Qq8Do)