ถอดรหัส TH-AI Passport ในมุมมอง Dev: ทำไมต้องสร้างใหม่ เมื่อ AI โลกมีพร้อมอยู่แล้ว? | 9mza

ในฐานะคนที่ทำงานสาย Tech การที่เห็นภาครัฐพยายามผลักดันเทคโนโลยี AI ให้คนไทยได้เข้าถึง นัยหนึ่งมันฟังดูสวยหรูน่ายินดีครับ แต่ในฐานะ Developer ที่มองผ่านแว่น Software Architecture, Scalability และ Budget Management (เงินภาษีพวกเราทั้งนั้น!) เมื่อเห็นโครงการ TH-AI Passport กับตัวเลขงบประมาณระดับพันล้านบาท คำถามแรกที่เด้งขึ้นมาในหัวทันทีคือ “เรากำลังตั้งโจทย์ถูกข้อ หรือแค่อยากหาเรื่องตั้งงบทำแพลตฟอร์มใหม่กันแน่?”

วันนี้เลยอยากมาชวนคุยในมุม Dev แบบตรงไปตรงมา ย่อยภาษาเทคนิคให้คนทั่วไปอ่านเข้าใจง่ายๆ ถึงข้อสังเกตและข้อกังขาเชิงสถาปัตยกรรมระบบของโครงการนี้ครับ

1. Reinventing the Wheel: จะสร้างล้อใหม่ทำไม ในเมื่อมีรถไฮเปอร์คาร์ให้ขับอยู่แล้ว?

ความพร้อมของ Global AI Models

ทุกวันนี้ Global AI Models อย่าง ChatGPT (OpenAI), Gemini (Google) หรือ Claude (Anthropic) พัฒนาไปไกลระดับเปลี่ยนโลกแล้ว ทั้งเรื่องระบบความปลอดภัย (Guardrails) และมาตรฐานความเป็นส่วนตัวระดับสากล เขาลงทุนวิจัยและดูแล Infra กันเป็นแสนล้านดอลลาร์ แต่ภาครัฐไทยกลับคิดจะสร้าง “กล่องกลาง” ขึ้นมาคั่นกลางใหม่เสียอย่างนั้น

Data Privacy & Attack Vector: กล่องกลาง หรือ กล่องความเสี่ยง?

ถ้าเปรียบเทียบให้เห็นภาพง่ายๆ การสร้าง Middleman หรือ API Gateway Platform ขึ้นมารับ-ส่ง Request (API Routing) มันเหมือนการเอารับจดหมายจากประชาชน ไปผ่านห้องตรวจของรัฐก่อนแล้วค่อยส่งต่อให้ AI โลก

ในทาง Security ยิ่งคุณสร้างชั้น Middleware มากขึ้น เท่ากับคุณกำลังเพิ่มจุดโจมตี หรือ Attack Vector ให้แฮกเกอร์โดยไม่จำเป็น แถมยังมีคำถามใหญ่ตามกฎหมาย PDPA (Personal Data Protection Act) ว่า “ข้อมูลคำถาม คำตอบ หรือ Prompts ของประชาชนที่วิ่งผ่านกล่องกลางนี้ ถูกดักฟัง (Logging), จัดเก็บ หรือแอบเอาไปทำอะไรต่อหรือเปล่า?” แล้วถ้าวันหนึ่งระบบกลางนี้ทำข้อมูลหลุด ใครจะเป็นคนรับผิดชอบ?

2. Enterprise Licensing & ช่องโหว่การกระจายสิทธิ์: ทางง่ายๆ ไม่ทำ ชอบทำทางยาก?

ทำไมไม่ใช้ B2B / Educational Tier?

บริษัท Big Tech แทบทุกค่ายมีแผน Enterprise หรือ Education Subscription ในราคาพิเศษแบบ Volume Licensing อยู่แล้ว ถ้าภาครัฐอยากช่วยประชาชนจริงๆ สิ่งที่ควรทำคือการรับบทเป็น Facilitator (ผู้ประสานงาน) เดินไปเจรจาซื้อ Pro Account แบบยกแพ็ก แล้วแจกสิทธิ์ให้ นักเรียน นักศึกษา และประชาชนผ่านอีเมลสถาบันการศึกษา (เช่น Domain .ac.th) ตรงๆ ไปเลย!

การทำแบบนี้ตัด Overhead Cost ค่าบริหารจัดการ ค่าเซิร์ฟเวอร์ และค่าตั้งทีมสร้างแพลตฟอร์มซ้ำซ้อนออกไปได้มหาศาล… แต่นั่นแหละครับ ทำแบบง่ายๆ ตรงๆ งบมันคงไม่สะพัดพอใช่ไหมครับ?

โควตา และความเสี่ยงเรื่อง “ระบบตั๋วช้างทางเทคโนโลยี”

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

3. ฝันร้ายของ System Architecture: Scalability & Friction

คอขวด (Bottleneck) มหาศาลระดับ Infrastructure

การออกแบบให้ประชาชนทั้งประเทศ (Concurrent Users) ต้องวิ่งผ่าน API Gateway กลาง ของรัฐเพียงจุดเดียว เป็นสถาปัตยกรรมที่ชวนปวดหัวที่สุดสำหรับ Systems Engineer นอกจากรัฐจะต้องแบกรับค่า Compute & Bandwidth มหาศาลแล้ว ปัญหาเรื่อง Latency (ความอืด) และ Rate Limit (การจำกัดจำนวนคำขอ) จากฝั่ง Global Provider จะกลายเป็นคอขวดที่ทำให้ระบบล่ม (Crash) แทบจะทันทีที่มีคนแห่เข้ามาใช้งาน อ่านเพิ่มเติมเกี่ยวกับ สถาปัตยกรรมเว็บที่ดีและการทำ SEO ที่ยั่งยืน

User Friction: ยืนยันตัวตนจนหมดอารมณ์ใช้

ในเชิง UX/UI การบังคับให้ประชาชนต้องผ่านกระบวนการ KYC / KYC-Lite ยืนยันตัวตนหลายขั้นตอนผ่านแอปภาครัฐ กดสแกนหน้า ยืนยัน OTP ก่อนจะกดข้ามไปใช้ AI ได้ ถือเป็นการสร้าง User Friction มหาศาล ผลลัพธ์สุดท้ายคือคนจะถอนตัว (Drop-off Rate สูงลิ่ว) และ Active Users จะต่ำกว่าเป้าแบบไม่ต้องสืบ

[ผู้ใช้งาน] ---> (KYC สแกนหน้าหลายขั้นตอน) ---> [TH-AI Gateway กลาง] ---> (ติด Bottleneck / ล่ม) ---> [Global AI]
                                                     │
                                        (เสี่ยงหลุด / เสียเวลา / งบบานปลาย)

สรุป: รัฐบาลควรเป็น “ผู้สนับสนุน (Facilitator)” ไม่ใช่ “ผู้สร้าง (Creator)”

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

ทางออกที่คุ้มค่าภาษีประชาชนที่สุด คือการใช้บทบาท Facilitator ไปเจรจาซื้อสิทธิ์ Enterprise Pro จากเจ้าของโมเดลระดับโลก แล้วกระจายสิทธิ์ตรงให้นักเรียน นักศึกษา และประชาชน ได้ใช้อย่างโปร่งใส ปลอดภัย และ Scale ได้จริง โดยไม่ต้องทิ้งภาระ “ระบบกล่องกลาง” ไว้เป็นขยะเทคโนโลยี (Digital Waste) และภาระงบประมาณซ่อมบำรุงในอนาคต

หมายเหตุ: บทความนี้เขียนขึ้นจากมุมมองด้านการพัฒนาซอฟต์แวร์และสถาปัตยกรรมระบบ เพื่อเป็นวิทยาทานแก่มวลชน โดยไม่มีวัตถุประสงค์ในการหารายได้ มุ่งหวังให้เป็น Digital Footprint ที่ช่วยสร้างภูมิคุ้มกันและมุมมองทางเทคโนโลยีให้แก่ผู้ใช้งานในยุคดิจิทัล โดยผู้เขียน นายเอ็มซ่ามากส์ (AEMDEVWEB)