เมื่อประเทศไทยกำลังดึงดูดการลงทุน Data Center, Cloud และ AI Infrastructure ขนาดใหญ่ คำถามสำคัญไม่ได้มีเพียงว่า Server หรือ GPU ตั้งอยู่ในประเทศไทยหรือไม่ แต่ต้องถามต่อว่า

ใครเป็นผู้ใช้ Compute เหล่านั้นจริง ใครเป็นผู้สั่งงาน CPU/GPU งานนั้นเกิดจากประเทศใด และประเทศไทยสามารถตรวจสอบย้อนกลับได้มากน้อยเพียงใด

หนึ่งในเครื่องมือที่สามารถนำมาใช้เป็นแกนกลางของระบบตรวจสอบนี้คือ Identity and Access Management หรือ IAM

อย่างไรก็ตาม IAM แบบดั้งเดิมที่เน้นเพียง Username, Password และสิทธิการเข้าถึง ยังไม่เพียงพอสำหรับโลกของ AI Data Center

ประเทศไทยควรยกระดับ IAM ไปสู่แนวคิด Identity–Workload–Compute–Location Traceability

กล่าวคือ ต้องสามารถเชื่อมโยงตั้งแต่ “ใครเป็นผู้เช่า” ไปจนถึง “ใครสั่งงาน Workload ใด ใช้ GPU ตัวไหน อยู่ที่ Data Center ใด และใช้ทรัพยากรไปเท่าใด”

IAM ไม่ได้ตอบเพียงว่า “ใคร Login”

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

ผู้ใช้อาจเชื่อมต่อผ่าน VPN, Proxy, CDN, Private Circuit หรือใช้ Service Account และ Automation สั่ง GPU โดยไม่มีมนุษย์ Login อยู่ในขณะนั้น

ดังนั้น เป้าหมายของมาตรฐานไม่ควรเป็นการพยายามตอบเพียงว่า “IP นี้มาจากประเทศอะไร?”

แต่ต้องตอบคำถามอย่างน้อย 7 ข้อ

1. นิติบุคคลใดเป็นผู้เช่าทรัพยากร
   2. บุคคลหรือระบบใดเป็นผู้ยืนยันตัวตน
   3. ใครเป็นผู้อนุมัติหรือส่งคำสั่งสร้าง Workload
   4. Workload ใดถูกสร้างขึ้น
   5. Workload นั้นรันบน CPU/GPU ตัวใดและอยู่ใน Data Center ใด
   6. ใช้ทรัพยากรจำนวนเท่าใด
   7. คำสั่งมีต้นทางจากประเทศไทยหรือต่างประเทศด้วยระดับความเชื่อมั่นเท่าใด

ดร.มนตรี วิบูลยรัต

ความสัมพันธ์หลักจึงควรเป็น Tenant → Identity → Session → API Request → Workload → Compute Resource → Metering

“ผู้ใช้ที่แท้จริง” ไม่ได้มีเพียงคนเดียว

ในระบบ Cloud และ AI Infrastructure คำว่า User ต้องถูกแยกออกเป็นหลายประเภท

ระดับแรกคือ Accountable Entity หรือนิติบุคคลที่รับผิดชอบต่อการใช้ทรัพยากร เช่น บริษัทไทย บริษัทต่างชาติ มหาวิทยาลัย หรือหน่วยงานรัฐ

ระดับที่สองคือ Initiating Principal ซึ่งอาจเป็นมนุษย์หรือ Service Account ที่ส่งคำสั่งใช้งาน Compute

ระดับที่สามคือ Beneficiary หรือ End User ซึ่งเป็นผู้ใช้หรือกิจกรรมทางเศรษฐกิจที่ได้รับประโยชน์จากการประมวลผล

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

มาตรฐาน IAM ต้องครอบคลุมทั้งคนและเครื่องจักร

ระบบ AI สมัยใหม่ไม่ได้ถูกใช้งานโดยมนุษย์โดยตรงทั้งหมด

GPU Job จำนวนมากถูกสร้างผ่าน API, MLOps Pipeline, CI/CD หรือ Autonomous Agent ดังนั้นมาตรฐานต้องจัดการ Identity อย่างน้อย 6 ประเภท ได้แก่

• Tenant Identity - บริษัทหรือหน่วยงานผู้เช่า


• Human Identity - Administrator, Developer, Researcher


• Service Account - ระบบ Automation, AI Platform หรือ Pipeline


• Workload Identity - VM, Container, Kubernetes Pod


• Device Identity - Laptop, Gateway หรือ Bastion Host


• Compute Identity - Server, CPU, GPU หรือ GPU Partition

หากระบบบันทึกเพียงว่า “gpu-user ส่งงาน” แต่ไม่รู้ว่าใครเป็นเจ้าของบัญชีดังกล่าว ก็แทบไม่มีประโยชน์ต่อการตรวจสอบเชิงนโยบาย

ต้องเริ่มจาก Tenant Identity Registry

Cloud หรือ GPU Operator ควรสร้าง Tenant ID ที่ไม่ซ้ำกันสำหรับลูกค้านิติบุคคลแต่ละราย

ข้อมูลขั้นต่ำควรประกอบด้วย ชื่อนิติบุคคล ประเทศที่จดทะเบียน เลขทะเบียนนิติบุคคล เลขประจำตัวผู้เสียภาษี บริษัทแม่ ผู้รับประโยชน์ที่แท้จริง ผู้มีอำนาจลงนาม Technical Contact, Security Contact, Billing Country ตลอดจนวัตถุประสงค์การใช้ CPU/GPU เช่น TH-DC01-TENANT-0001287 อาจหมายถึง Tenant หมายเลข 1,287 ของ Data Center แห่งหนึ่งในประเทศไทย

อย่างไรก็ตาม ต้องเน้นว่า บริษัทจดทะเบียนในไทย หรือใช้ Billing Address ในไทย ไม่ได้พิสูจน์ว่า Compute ถูกใช้โดยผู้ใช้ในประเทศไทย

Tenant Registry เป็นเพียงหลักฐานชั้นแรก

IAM Federation ต้องใช้มาตรฐานสากล

ในระดับเทคนิค Cloud Operator ควรรองรับมาตรฐาน Identity Federation ที่เป็นที่ยอมรับ เช่น OpenID Connect, OAuth, SAML และ SCIM

บัญชีที่มีสิทธิสูงควรใช้ Multi-Factor Authentication โดยเฉพาะ Phishing-resistant MFA เช่น FIDO2/WebAuthn หรือ Certificate-based Authentication

ส่วน Machine Identity สามารถใช้ Mutual TLS หรือกลไก Workload Identity เช่น SPIFFE/SPIRE หรือเทคโนโลยีเทียบเท่า

หลักการสำคัญคือ Identifier ต้องเสถียรและตรวจสอบย้อนกลับได้

ตัวอย่าง OpenID Connect ไม่ควรใช้ Email Address เป็น Primary Key เพราะ Email สามารถเปลี่ยนหรือถูกนำกลับมาใช้ใหม่ได้

ควรใช้คู่ข้อมูล เช่น Issuer + Subject เพื่อระบุ Identity อย่างชัดเจน ต้องกำหนดระดับความน่าเชื่อถือของ Identity ไม่ใช่ทุก Login มีความน่าเชื่อถือเท่ากัน

แนวคิดจาก NIST Digital Identity Guidelines สามารถนำมาประยุกต์ใช้เพื่อแบ่งระดับความเชื่อมั่นของการยืนยันตัวตนและ Authentication

บัญชีทั่วไปอาจใช้ MFA ระดับมาตรฐาน

แต่ผู้ใช้ที่มีสิทธิสร้าง GPU Cluster ขนาดใหญ่ ย้าย Workload ข้ามประเทศ เปลี่ยน IAM Policy สร้าง Service Account หรือ Export Model Weight ควรใช้ Authentication ที่เข้มงวดกว่า

โดยเฉพาะบัญชี Privileged ควรใช้ Hardware-backed Credential และ Phishing-resistant Authentication เป็นมาตรฐาน

ในอนาคตประเทศไทยอาจกำหนดว่า Compute Privilege สูง ต้องคู่กับ Identity Assurance สูง

ทุก GPU Job ต้องมี Trace ID

ส่วนสำคัญที่สุดของมาตรฐานคือ ทุกคำสั่งที่ทำให้เกิดการใช้ Compute ต้องมี Trace ID ที่สามารถติดตามข้ามระบบได้

เส้นทางอาจเป็น Login → IAM Session → Cloud API Gateway → GPU Scheduler → Kubernetes/VM Orchestrator → GPU Node → Metering → Billing

ทุกระบบควรมีตัวระบุร่วมกัน เช่น

• Tenant ID


• Principal ID


• Session ID


• Request ID


• Workload ID


• Resource ID


• Trace ID


• Delegation Chain

เมื่อเกิด GPU Job หนึ่งงาน ผู้ตรวจสอบจึงสามารถย้อนกลับได้ว่า

• งานนี้เป็นของ Tenant ใด


• ใครเป็นผู้ส่งคำสั่ง


• ใช้ Token ใด


• เกิดจาก Session ใด


• รันบน GPU ตัวใด


• ใช้ไปกี่ชั่วโมง


• และถูกคิดเงินให้กับใคร

นี่คือหัวใจของ Compute Traceability

Service Account คือจุดเสี่ยงสำคัญที่สุด

ปัจจุบัน Workload จำนวนมากไม่ได้ถูกสร้างโดยมนุษย์ แต่ถูกสร้างผ่าน Service Account

หาก Service Account ไม่มี Human Owner ระบบจะเกิดช่องว่างทันทีดังนั้น Service Account ทุกบัญชีควรมีอย่างน้อย

• Human Owner


• Business Owner


• Tenant ID


• Purpose


• Allowed Workload Type


• Allowed Region


• Allowed GPU Pool


• วันหมดอายุ


• Credential Rotation Policy


• ผู้อนุมัติ


• ระบบต้นทางที่ได้รับอนุญาต


• Delegation Chain

โครงสร้างควรสามารถย้อนกลับได้ว่า Human Owner → Service Account → Pipeline → Workload

บัญชีร่วม เช่น “admin”, “gpu-user” หรือ “research-team” ที่ไม่สามารถระบุความรับผิดชอบรายบุคคลได้ ควรถูกจำกัดอย่างมาก

แล้วจะรู้ได้อย่างไรว่าผู้สั่งงานอยู่ในไทย?

คำตอบคือ ต้องใช้หลักฐานหลายแหล่ง

Source IP และ ASN ให้ข้อมูลเกี่ยวกับจุดเชื่อมต่อกับ Internet แต่ VPN และ Proxy สามารถบิดเบือนได้

Corporate Gateway ช่วยระบุเครือข่ายองค์กร แต่ผู้ใช้จริงอาจ Remote เข้ามาจากต่างประเทศ

Device Certificate ช่วยยืนยันอุปกรณ์ แต่เครื่องอาจถูกควบคุมจากระยะไกล

Billing Country ช่วยยืนยันที่ตั้งทางธุรกิจ แต่ไม่ใช่ตำแหน่งของผู้ใช้ขณะสั่งงาน

ดังนั้นประเทศไทยไม่ควรใช้ IP Geolocation เป็นหลักฐานเพียงอย่างเดียว

ควรสร้าง Location Confidence Score

ตัวอย่างเช่น

• Dedicated Circuit ในไทย


• Managed Device และ Device Certificate


• Source IP และ ASN ประเทศไทย


• IdP Authentication จากประเทศไทย


• Tenant/Billing Country ประเทศไทย


• Enterprise Gateway ประเทศไทย


• ประวัติการใช้งานที่สอดคล้องกัน

จากนั้นหักคะแนนเมื่อพบ Public VPN, Tor, Anonymous Proxy, Impossible Travel หรือข้อมูลตำแหน่งขัดแย้งกัน

ผลลัพธ์อาจจัดเป็น

• Thailand - High Confidence


• Thailand - Medium Confidence


• Uncertain


• Foreign/Unverified

วิธีนี้มีเหตุผลมากกว่าการกำหนดแบบ Binary ว่า “ไทยหรือไม่ไทย” จาก IP เพียงค่าเดียว ใช้แนวคิด Zero Trust ในการควบคุม Compute มาตรฐานควรเชื่อม IAM กับ Policy Engine

ทุกคำสั่งสำคัญสามารถพิจารณาจาก

• Identity


• Tenant


• Device Posture


• Authentication Strength


• Source Evidence


• Requested GPU


• Compute Region


• Data Classification


• Time และ Risk

จากนั้น Policy Engine จึงตัดสินใจว่าจะอนุญาตหรือไม่

ตัวอย่างเช่น การสร้าง GPU Cluster ในประเทศไทยอาจอนุญาตเมื่อ Tenant ผ่าน KYB ผู้ใช้ผ่าน Phishing-resistant MFA อุปกรณ์มี Certificate ที่เชื่อถือได้ Role มีสิทธิที่เหมาะสม Service Account มี Human Owner และไม่มีสัญญาณผิดปกติ

คำสั่งความเสี่ยงสูง เช่น ย้าย Workload ออกจากประเทศไทย ดาวน์โหลด Dataset ขนาดใหญ่ หรือ Export Model Weight อาจต้องใช้ Step-up Authentication เพิ่มเติม

ต้องผูก Workload ถึง GPU ตัวจริง

IAM เพียงอย่างเดียวบอกได้ว่าใครได้รับอนุญาต แต่ยังไม่พิสูจน์ว่า Workload รันบนเครื่องใดจริง จึงต้องเชื่อมต่อกับ Infrastructure Orchestrator และ Hardware Inventory

ความสัมพันธ์ควรย้อนกลับได้ตั้งแต่ Workload ID → Scheduler Job → Cluster → Node → Server Serial → CPU/GPU UUID → GPU Partition → Rack → Data Center Site → Compute Region

ในกรณี GPU ที่แบ่งเป็น MIG หรือ vGPU ต้องบันทึกถึง Logical Partition ไม่ใช่เพียงหมายเลขการ์ด

เทคโนโลยีอย่าง TPM, Secure Boot และ Remote Attestation สามารถช่วยยืนยันว่า Node ที่ให้บริการอยู่ในสถานะที่เชื่อถือได้และตรงกับ Inventory

แต่ต้องเข้าใจว่า Hardware Attestation ช่วยพิสูจน์ “เครื่องที่ Workload รันอยู่” ไม่ได้พิสูจน์ว่า “มนุษย์ผู้ใช้อยู่ที่ไหน” จาก Identity สู่ GPU-hours

เมื่อผูก Identity กับ Workload และ GPU ได้แล้ว ประเทศไทยจะสามารถวัด Compute Usage ได้อย่างเป็นระบบ

ตัวอย่างง่ายที่สุด หาก Workload ใช้ GPU 8 ตัว เป็นเวลา 10 ชั่วโมง เท่ากับ 80 GPU-hours แต่ในระบบ Shared GPU ควรแยกอย่างน้อยสองตัวเลข คือ Allocated GPU-hours - จำนวนทรัพยากรที่จองไว้

และ Consumed GPU-equivalent hours - ทรัพยากรที่ถูกใช้งานจริงหลังปรับตาม Utilization เพราะการจอง GPU ไว้เฉย ๆ ไม่ควรถูกตีความว่าเกิดกิจกรรมเศรษฐกิจเท่ากับ GPU ที่ประมวลผลเต็มกำลังจริง

จากข้อมูลดังกล่าวสามารถสร้างตัวชี้วัด เช่น Thai-Originated Compute Ratio เท่ากับสัดส่วน Compute-hours ที่มีหลักฐานว่าคำสั่งเกิดจากประเทศไทยต่อ Compute-hours ทั้งหมด

Audit Log ต้องใช้เป็นพยานหลักฐานได้

ถ้าจะใช้ IAM เป็นมาตรฐานกำกับ Data Center จริง Audit Log ต้องไม่สามารถแก้ย้อนหลังได้ง่ายควรมี

• เวลามาตรฐานเดียวกัน


• Secure Time Synchronization


• Append-only Storage


• Digital Signature


• Sequence Number


• Hash Chain หรือ Merkle Tree


• การสำรอง Log นอก Administrative Domain


• การแยกหน้าที่ผู้ดูแลระบบกับผู้ดูแล Log

ระบบควรเก็บ Log อย่างน้อยตั้งแต่ Identity Proofing, Authentication, Authorization, Token Issuance, API Gateway, Scheduler, Compute Metering และ Network/Region Migration

หาก Log ถูกลบหรือแก้ไข ต้องสามารถตรวจพบได้

ระบบต้องตรวจจับพฤติกรรมผิดปกติ

IAM Analytics และ SIEM ควรตรวจจับเหตุการณ์ เช่น

• บัญชีเดียว Login พร้อมกันจากหลายประเทศ


• Token เดียวถูกใช้จากหลาย ASN


• Login จากไทย แต่ API Call มาจากต่างประเทศ


• Service Account ถูกเรียกจากระบบที่ไม่ได้ลงทะเบียน


• สร้าง GPU Job จำนวนผิดปกติ


• ย้าย Workload ข้าม Region


• GPU Usage สูงแต่ไม่มี Scheduler Event


• Billing ไม่ตรงกับ GPU Inventory


• Tenant ไทยมี Network Egress ไปต่างประเทศเกือบทั้งหมด


• บัญชีพนักงานที่ออกจากองค์กรแล้วยังใช้งานได้

สิ่งเหล่านี้ไม่ได้เป็นเพียงเรื่อง Cybersecurity แต่เป็นหลักฐานที่ช่วยให้รัฐประเมินความน่าเชื่อถือของข้อมูล Compute Usage ได้ด้วย

ต้องรักษาสมดุลระหว่างการตรวจสอบกับ Privacy

ข้อมูล IAM, IP Address, Device ID และพฤติกรรมการใช้งานสามารถเชื่อมโยงกลับไปยังบุคคลได้ ดังนั้นระบบต้องออกแบบตามหลัก Purpose Limitation, Data Minimization, Pseudonymization และ Role-based Access

หน่วยงานกำกับไม่จำเป็นต้องได้รับชื่อผู้ใช้ทุกคนตลอดเวลา ข้อมูลรายงานควรเป็น Aggregate เช่น

• Tenant Class


• Country Classification


• Assurance Level


• GPU-hours


• CPU-hours


• Compute Region


• Location Confidence


• Exception Count


• Independent Audit Status

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

BOI และ กสทช. ควรได้อะไรจากระบบนี้?

สำหรับ Data Center ที่ได้รับสิทธิประโยชน์จากรัฐหรือใช้ไฟฟ้าปริมาณสูง อาจกำหนดให้รายงานตัวชี้วัด เช่น

• Total GPU-hours


• Thai-originated GPU-hours


• Foreign-originated GPU-hours


• Unverified GPU-hours


• Service-account Ratio


• Orphan Service Accounts


• Privileged MFA Coverage


• Workload Traceability Coverage


• Cross-region Migration


• Log Integrity Failure

โดย KPI ที่สำคัญที่สุดอาจเป็น Traceability Coverage คือสัดส่วน GPU-hours ที่สามารถเชื่อมโยงได้ครบตั้งแต่ Tenant → Identity → Workload → GPU ต่อ GPU-hours ทั้งหมด

สำหรับ Data Center ที่ได้รับสิทธิประโยชน์จากรัฐ เป้าหมายควรเข้าใกล้ 100% เพราะ Workload ที่ไม่สามารถระบุได้ว่าเป็นของ Tenant ใด ใครเป็นผู้สั่ง และใช้ทรัพยากรใด ถือเป็น Blind Spot ที่ไม่ควรเกิดขึ้นในโครงสร้างพื้นฐาน AI ระดับประเทศ

จาก IAM สู่โครงสร้างพื้นฐานความเชื่อมั่นของ AI ประเทศไทย

ในอนาคต IAM ไม่ควรถูกใช้เพียงเพื่อตอบว่า “ใคร Login?” แต่ควรเป็นระบบที่เชื่อมโยง นิติบุคคล → ตัวตน → สิทธิ → คำสั่ง → Workload → CPU/GPU → เวลาใช้งาน → ตำแหน่ง Compute

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

อย่างไรก็ตาม ต้องย้ำว่า IAM พิสูจน์ “ผู้สั่งงานและบริบทการเข้าถึง” ได้ดีกว่าพิสูจน์ “ตำแหน่งของ End User”

หากต้องการรู้ว่าผู้ใช้ปลายทางของ AI Application อยู่ประเทศใด ยังจำเป็นต้องใช้ Application-level Evidence จาก Tenant ประกอบ ดังนั้น แนวทางที่เหมาะสมที่สุดสำหรับประเทศไทย ไม่ใช่การใช้ IAM เพื่อเฝ้าติดตามประชาชน

แต่คือการใช้ IAM เป็น Digital Chain of Custody ของ Compute เพื่อให้ทุก GPU-hour ที่ใช้ทรัพยากรไฟฟ้า น้ำ โครงข่าย และสิทธิประโยชน์ของประเทศไทย สามารถตรวจสอบย้อนกลับได้ว่า ใครใช้ ใช้เพื่ออะไร ใช้ที่ไหน และสร้างประโยชน์ทางเศรษฐกิจให้กับประเทศใด

นี่อาจกลายเป็นมาตรฐานสำคัญของการกำกับ AI Data Center ยุคใหม่ของประเทศไทย