Brave Leo ยกระดับ AI ส่วนตัว เพิ่มเข้ารหัส E2E และตรวจสอบการประมวลผลได้
Leo เพิ่มเกราะความเป็นส่วนตัวให้บทสนทนา AI
Brave ประกาศเมื่อวันที่ 15 ตุลาคม 2026 ว่า Leo ผู้ช่วย AI ภายในเบราว์เซอร์ เพิ่มการเข้ารหัสแบบต้นทางถึงปลายทาง หรือ End-to-End Encryption ควบคู่กับ Oblivious HTTP และการประมวลผลข้อมูลลับที่ตรวจสอบได้ โดยเปิดให้ใช้งานกับโมเดล GLM 5.3 Flash ผ่าน Brave รุ่น Release, Beta และ Nightly ตามประกาศของบริษัท ([brave.com](https://brave.com/blog/browser-ai-e2ee/?utm_source=openai))
หัวใจของอัปเดตคือการเข้ารหัสคำถามตั้งแต่บนอุปกรณ์ผู้ใช้ ก่อนส่งไปประมวลผลใน Trusted Execution Environment หรือ TEE ของ NEAR AI ซึ่งเป็นพื้นที่ที่ฮาร์ดแวร์ช่วยแยกและปกป้องข้อมูลระหว่างใช้งาน Brave ระบุว่าระบบนี้ออกแบบให้ทั้งบริษัทและผู้ดูแลโครงสร้างพื้นฐานไม่สามารถอ่านเนื้อหาการสนทนาได้ โดยขอบเขตการปกป้องดังกล่าวผูกกับเส้นทางประมวลผลที่รองรับ ไม่ควรเหมารวมถึงทุกโมเดลใน Leo ([brave.com](https://brave.com/blog/browser-ai-e2ee/?utm_source=openai))
เข้ารหัสข้อความ แยก IP และตรวจสอบก่อนส่งข้อมูล
Oblivious HTTP หรือ OHTTP ช่วยแยกผู้ที่เห็นที่อยู่ IP ออกจากผู้ที่ประมวลผลคำถาม โดย Brave ทำหน้าที่ส่งต่อข้อความที่เข้ารหัสแล้ว จึงเห็น IP ของผู้ใช้แต่ไม่เห็นเนื้อหา ส่วนระบบปลายทางใน TEE ถอดรหัสเพื่อประมวลผลได้ แต่ไม่ได้รับ IP ของผู้ใช้โดยตรง กลไกนี้จึงช่วยลดการเชื่อมโยงตัวตนกับเนื้อหาที่ถาม AI ([brave.com](https://brave.com/blog/browser-ai-e2ee/?utm_source=openai))
อีกชั้นคือ attestation หรือหลักฐานรับรองจากฮาร์ดแวร์ ระบบตรวจสอบของ Brave จะตรวจความถูกต้องของสภาพแวดล้อมและกุญแจเข้ารหัสก่อนอนุญาตให้ส่งคำถาม อย่างไรก็ตาม ปัจจุบันเบราว์เซอร์ยังพึ่งพาเซิร์ฟเวอร์ของ Brave ในขั้นตอนตรวจสอบนี้ ส่วนการตรวจหลักฐานโดยตรงภายในเบราว์เซอร์เป็นแผนพัฒนาต่อไป จึงยังมีองค์ประกอบในห่วงโซ่ความเชื่อถือที่ผู้ใช้ต้องพิจารณา ([brave.com](https://brave.com/blog/browser-ai-e2ee/?utm_source=openai))
มุมมองสำหรับนักพัฒนาและผู้ประกอบการไทย
ในมุมบรรณาธิการ ข่าวนี้ชี้ให้เห็นแนวทางเลือกบริการ AI ที่ควรมองลึกไปถึงช่วงประมวลผลข้อมูล นอกเหนือจากการเข้ารหัสระหว่างรับส่ง จุดที่น่าศึกษาจาก Leo คือการใช้ฮาร์ดแวร์ปกป้องข้อมูลร่วมกับหลักฐานตรวจสอบ และการเปิดเผยซอร์สโค้ดของส่วนประกอบในเส้นทางรับส่งข้อมูล ซึ่งช่วยให้การประเมินความเป็นส่วนตัวมีรายละเอียดที่ตรวจสอบได้มากขึ้น ([brave.com](https://brave.com/blog/browser-ai-e2ee/?utm_source=openai))
สำหรับทีมไทยที่กำลังพัฒนาแชตบอตภายในองค์กรหรือระบบวิเคราะห์เอกสาร ควรนำแนวคิดนี้ไปตั้งคำถามกับผู้ให้บริการว่า ใครเข้าถึงข้อความได้ ข้อมูลถูกถอดรหัสที่ใด และมีหลักฐานอะไรยืนยันสภาพแวดล้อมที่รันจริง จากนั้นเริ่มทดสอบด้วยข้อมูลจำลอง พร้อมประเมินคุณภาพภาษาไทย ความเร็ว และต้นทุนตามงานจริง การมี TEE ควรเป็นหนึ่งในเกณฑ์ออกแบบระบบ ควบคู่กับการจำกัดข้อมูลที่ส่งและการกำหนดสิทธิ์เข้าถึง
ทดลอง AI ให้ตรงงาน พร้อมตรวจเงื่อนไขข้อมูล
หากต้องการต่อยอดสู่การทดลองโมเดลผ่าน Tora API สามารถเริ่มสำรวจได้ที่ Tora Playground และตรวจสอบรุ่นที่เปิดให้บริการพร้อมค่าใช้จ่ายที่ หน้าราคา โดยใช้ชื่ออย่าง Claude 3.7, GPT-4o หรือ DeepSeek R1 เป็นจุดเริ่มต้นในการค้นหาและเปรียบเทียบ ส่วนงานสร้างวิดีโอสามารถดูตัวเลือกอย่าง Seedance ได้ที่ เครื่องมือ Text-to-Video ทั้งนี้ควรตรวจสอบรายการที่รองรับและเงื่อนไขข้อมูลของแต่ละบริการก่อนใช้งานจริง
ความโปร่งใสและแหล่งข้อมูลอ้างอิง
บทความนี้ได้รับการสังเคราะห์และตรวจสอบข้อเท็จจริงตามหลัก Tora Editorial Standards โดยอ้างอิงจากเอกสารทางการของผู้พัฒนา
เริ่มใช้งานโมเดล AI ผ่าน Tora API Gateway
รองรับมาตรฐาน OpenAI Compatible พร้อมระบบ Route Engine สลับ upstream อัตโนมัติเมื่อเกิด Rate Limit