Vendor Lock-in

Vendor lock-in คือสภาพที่องค์กรผูกติดอยู่กับผู้ให้บริการรายเดียวจนย้ายไปใช้เจ้าอื่นไม่ได้ หรือย้ายได้แต่ต้องแบกต้นทุนสูงจนไม่คุ้ม เป็นศัพท์เก่าแก่ในวงการไอทีที่ใช้ก่อนยุค AI มานานแล้ว ครอบคลุมตั้งแต่ระบบคลาวด์ ซอฟต์แวร์องค์กร ไปจนถึงของใช้ในชีวิตประจำวันอย่างตลับหมึกเครื่องพิมพ์หรือแบตเตอรี่เครื่องมือไฟฟ้าที่ออกแบบให้ใช้ได้กับยี่ห้อเดียวเท่านั้น สิ่งที่ทำให้คำนี้ถูกพูดถึงหนักขึ้นในยุค AI คือองค์กรกำลังผูกระบบงานสำคัญเข้ากับผู้ให้บริการ AI รายใดรายหนึ่งในจังหวะที่เร็วมาก และผูกลึกถึงระดับ prompt ข้อมูล และ workflow พร้อมกัน

กลไกที่ทำให้ AI ล็อกอินแน่นเป็นพิเศษมีอยู่หลายชั้นซ้อนกัน ชั้นแรกคือ prompt และ workflow ที่ทีมงานใช้เวลาเป็นเดือนจูนให้เข้ากับพฤติกรรมเฉพาะของ llm ตัวใดตัวหนึ่ง เช่น ระบบผู้ช่วยงานอย่าง chatgpt-enterprise microsoft-copilot หรือ gemini พอสลับไปโมเดลอื่นคำสั่งชุดเดิมอาจตอบไม่เหมือนเดิม ต้องรื้อทดสอบใหม่ทั้งชุด ชั้นที่สองคือข้อมูล: หลายองค์กรแปลงเอกสารภายในเป็น embedding แล้วเก็บไว้ในระบบของผู้ให้บริการรายนั้นเพื่อใช้ทำ rag เช่นบนแพลตฟอร์มอย่าง azure-openai amazon-bedrock หรือ vertex-ai ย้ายค่ายทีต้องแปลงข้อมูลใหม่ทั้งหมด ชั้นที่สามคือ agent และระบบอัตโนมัติที่สร้างผูกกับเครื่องมือของค่ายหนึ่งโดยเฉพาะ ย้ายไปแพลตฟอร์มอื่นต้องสร้างใหม่เกือบทั้งหมด บวกกับชั้นสัญญาระยะยาวที่ต้องอ่านเงื่อนไขการปรับราคาและการต่ออายุอัตโนมัติให้ละเอียดก่อนเซ็น วงการตอบโต้เรื่องนี้ด้วยมาตรฐานเปิดอย่าง mcp ที่ Anthropic เปิดเป็น open standard ตั้งแต่เดือนพฤศจิกายน 2024 และ OpenAI ซึ่งเป็นคู่แข่งโดยตรงก็ประกาศรองรับตามเมื่อ 26 มีนาคม 2025 ต่อมา Anthropic บริจาค MCP ให้ Agentic AI Foundation ภายใต้ Linux Foundation เมื่อ 9 ธันวาคม 2025 เพื่อให้การกำกับดูแลเป็นกลางไม่ขึ้นกับผู้ให้บริการรายใดรายหนึ่ง ผลคือชั้นการต่อ agent เข้ากับเครื่องมือภายนอกย้ายค่ายง่ายขึ้นมาก แต่ MCP แก้ได้เฉพาะชั้นการเชื่อมต่อเครื่องมือ ไม่ได้ทำให้ prompt ที่จูนไว้กับโมเดลหนึ่งย้ายไปอีกโมเดลแล้วได้ผลเท่าเดิม แนวทางที่มักถูกแนะนำเพื่อลดความเสี่ยงคือวาง abstraction layer คั่นกลางระหว่างระบบงานกับผู้ให้บริการ AI และสร้างชุด evals ของตัวเองไว้เทียบผลลัพธ์ข้ามโมเดล ข้อจำกัดที่ต้องรู้ล่วงหน้าคือ abstraction layer มักเหลือให้ใช้เฉพาะความสามารถร่วมที่ทุกเจ้ามีเหมือนกัน ฟีเจอร์เด่นเฉพาะเจ้าจะถูกตัดทิ้งไปด้วย และไม่ได้แก้ lock-in ที่ระดับ prompt และกันโมเดลแบบ open weights อย่าง llama ที่ดาวน์โหลด weights จากเว็บทางการของ Meta มารันเองได้ผ่านโปรแกรมอย่าง ollama ไว้เป็นทางเลือกสำรอง โดยต้องเข้าใจว่า open weights ไม่เท่ากับ open source Llama แจกภายใต้ Llama Community License ที่มีเงื่อนไขติดมา เช่น ผลิตภัณฑ์ที่มีผู้ใช้เกิน 700 ล้านคนต่อเดือนต้องไปขอ license แยกจาก Meta และ Open Source Initiative ยืนยันว่า license ชุดนี้ไม่ผ่านนิยาม open source การถือ weights ไว้เองจึงลดการพึ่งพา API ของค่ายหนึ่งได้จริง แต่ไม่ได้แปลว่าใช้ได้อิสระทุกกรณี ด้านกฎหมายมีกรอบที่ช่วยได้ แต่ช่วยเฉพาะบางพื้นที่ Data Act ของสหภาพยุโรปมีผลบังคับใช้ตั้งแต่ 11 มกราคม 2024 และเริ่มปฏิบัติจริง 12 กันยายน 2025 บังคับให้ผู้ให้บริการ data processing service (คลาวด์แบบ IaaS · PaaS · SaaS) ต้องเปิดทางให้ลูกค้าย้ายออกได้ง่ายขึ้น กติกาเรื่องค่าธรรมเนียมคือจนถึง 12 มกราคม 2027 เก็บค่าธรรมเนียมการย้ายได้ไม่เกินต้นทุนจริงที่เชื่อมโยงกับการย้ายโดยตรง และตั้งแต่ 12 มกราคม 2027 เป็นต้นไปห้ามเก็บค่าธรรมเนียมการย้ายทั้งหมด ซึ่งนิยามในกฎหมายนับรวมค่า egress ที่เก็บจากการย้ายด้วย มีสามข้อที่ต้องอ่านให้ครบก่อนเอาไปอ้าง หนึ่ง กฎนี้ผูกกับที่ตั้งของลูกค้า คือใช้กับผู้ให้บริการที่ให้บริการแก่ลูกค้าในสหภาพยุโรปไม่ว่าผู้ให้บริการจะตั้งอยู่ประเทศไหน สัญญาที่นิติบุคคลไทยเซ็นเพื่อใช้งานในไทยจึงไม่ได้รับความคุ้มครองนี้โดยอัตโนมัติ สอง ข้อห้ามครอบเฉพาะค่าธรรมเนียมที่เกิดจากการย้าย ค่าบริการปกติและค่าปรับยกเลิกก่อนกำหนดไม่นับ และกรณีใช้งานคู่ขนานหลายคลาวด์โดยไม่ได้ย้ายออก ผู้ให้บริการยังเก็บค่า egress ได้เท่าต้นทุนจริง สาม บริการที่สร้างเฉพาะให้ลูกค้ารายเดียวและบริการรุ่นทดสอบที่ไม่ใช่ production ได้รับยกเว้นจากข้อห้ามนี้ ส่วนบริการ AI จะนับเป็น data processing service หรือไม่ยังเป็นประเด็นตีความที่ยังไม่มีแนวจากหน่วยงานกำกับ ขึ้นกับว่าซื้อใช้ได้ทันทีแบบ self-service หรือต้องปรับแต่งเฉพาะรายมาก

คนทำงานในองค์กรไทยมักเจอคำนี้ตอนที่ฝ่ายจัดซื้อต่อสัญญา AI กับเจ้าเดิมทุกปีทั้งที่ราคาปรับขึ้น หรือตอนทีมเทคนิคเสนอให้ "รอก่อน อย่าเพิ่งย้าย" เพราะรื้องานที่จูนไว้ทั้งหมดจะแพงกว่าราคาที่ประหยัดได้ สิ่งที่ควรระวังคือเงื่อนไขในสัญญา เช่น ระยะเวลาต้องแจ้งยกเลิกล่วงหน้า ค่าธรรมเนียมดึงข้อมูลออก และรูปแบบไฟล์ที่ข้อมูลหรือโมเดลที่ปรับแต่งไว้ถูกเก็บ ว่าเป็นฟอร์แมตเปิดที่ยกไปที่อื่นได้หรือผูกกับระบบเจ้าเดียวเท่านั้น อีกด้านที่มักถูกมองข้ามคือการกระจายไปใช้หลายผู้ให้บริการพร้อมกัน (multi-vendor) ก็ไม่ใช่ยาครอบจักรวาลที่ไม่มีต้นทุน เพราะทีมงานต้องดูแล evals เปรียบเทียบหลายระบบ ฝึกคนให้ใช้เป็นหลายเครื่องมือ และอาจเสียส่วนลดปริมาณที่จะได้จากการซื้อเจ้าเดียวในปริมาณมาก จึงต้องชั่งน้ำหนักระหว่างความเสี่ยงจากการผูกติดกับความยุ่งยากที่เพิ่มขึ้นจากการกระจายเสมอ ไม่มีสูตรเดียวที่ถูกสำหรับทุกองค์กร

ตัวอย่างจากบทสนทนาจริง

ฝ่ายจัดซื้อ: "ทำไมต้องต่อสัญญากับผู้ให้บริการ AI เจ้าเดิมทุกปี เจ้าอื่นเสนอราคาถูกกว่าตั้งเยอะ ลองย้ายไม่ได้เหรอคะ"

ทีม IT: "ลองได้ครับ แต่ prompt กับ workflow ที่ทีมเราจูนมาเป็นปีมันผูกกับพฤติกรรมเฉพาะของโมเดลเจ้านี้ ข้อมูลที่แปลงเก็บไว้ให้ AI ค้นก็อยู่ในระบบของเขาด้วย ถ้าย้ายต้องรื้อทดสอบใหม่ทั้งหมด ต้นทุนย้ายรอบนี้อาจแพงกว่าค่าธรรมเนียมที่จะประหยัดได้ในปีแรกเลยครับ"

ระวังสับสนกับ

• model-provider : model provider คือคำเรียกบริษัทหรือบริการที่รันโมเดลให้เราเรียกใช้ เป็นคำกลางๆ ไม่มีความหมายเชิงลบในตัวเอง ส่วน vendor lock-in คือความเสี่ยงที่เกิดขึ้นเมื่อองค์กรผูกติดกับ model provider รายเดียวมากเกินไปจนย้ายไม่ได้ มี model provider ได้โดยไม่ต้องเกิด lock-in ถ้าออกแบบระบบให้ย้ายง่ายไว้ตั้งแต่ต้น
• shadow-ai : shadow AI คือการที่พนักงานแอบใช้เครื่องมือ AI นอกสายตาฝ่าย IT โดยไม่ผ่านการอนุมัติ เป็นความเสี่ยงเรื่องการควบคุมและความปลอดภัยของข้อมูล ส่วน vendor lock-in คือความเสี่ยงเรื่องต้นทุนการย้ายผู้ให้บริการที่องค์กรอนุมัติใช้งานอย่างเป็นทางการแล้ว คนละแกนปัญหา แต่เกิดพร้อมกันได้ เช่น พนักงานแอบใช้เครื่องมือหนึ่งจนทั้งทีมผูกติดกับมันโดยไม่รู้ตัว