เมื่อ SAP ปรับนโยบาย API ในเดือนเมษายน 2026 สิ่งที่องค์กรควรจับตาไม่ใช่คำถามง่าย ๆ ว่าเครื่องมือจากผู้ให้บริการภายนอกยังต่อ SAP ได้หรือไม่ แต่คือ SAP กำลังตีกรอบการใช้ API กับข้อมูลและกระบวนการหลักของ ERP ให้แคบลง โดยให้อยู่ใน API ที่เผยแพร่แล้ว เอกสารผลิตภัณฑ์ สถาปัตยกรรมที่ SAP รับรอง บริการข้อมูล หรือเส้นทางเฉพาะบริการที่กำหนดไว้ ^[1][7][10]

สำหรับองค์กรที่กำลังนำ AI agent หรือเอเจนต์ AI มาเชื่อมกับ SAP ผลกระทบจึงไม่ได้อยู่แค่ทีม AI แต่ลามไปถึง PoC, data platform, RPA, iPaaS, ETL และ workflow อัตโนมัติที่พัฒนาขึ้นเอง ^[1][13] คำถามสำคัญกลายเป็นว่า agent ตัวใดเรียก API อะไร ผ่านเส้นทางใด ใช้ข้อมูลมากแค่ไหน และมีหลักฐานหรือไม่ว่าอยู่ในขอบเขตที่ SAP รองรับ

ขอบเขตใหม่ของ API อยู่ตรงไหน

CIO.com รายงานว่า SAP ระบุชัดว่า เฉพาะอินเทอร์เฟซที่อยู่ใน SAP Business Accelerator Hub หรืออยู่ในเอกสารผลิตภัณฑ์ที่เกี่ยวข้องเท่านั้น จึงจะถือเป็น API ที่เผยแพร่แล้ว ^[7] ส่วน The Register รายงานว่านโยบายใหม่กำหนดให้ผู้ใช้สร้างหรือใช้งาน API ได้ภายในขอบเขตของ

SAP-endorsed architectures, data services, or service-specific pathways

[2]

[10]

ความหมายในทางปฏิบัติคือ องค์กรไม่ควรสมมติอีกต่อไปว่า endpoint หรือ function module ใด ๆ ที่เรียกได้ จะเหมาะกับการใช้งานระยะยาวเสมอ นโยบายยังระบุชุด API Controls เช่น ข้อจำกัดการใช้งานเชิงฟังก์ชันและเทคนิค โควตา ตารางเลิกใช้งาน โควตาข้อมูลเข้าออก ข้อจำกัดและเงื่อนไขของการดึงหรือทำสำเนาข้อมูลจำนวนมาก รวมถึงข้อกำหนดด้านความปลอดภัยหรือเทคนิคอื่น ๆ ^[9]

SAPinsider ระบุว่า API ที่ไม่อยู่ในเอกสารยังถูกใช้อย่างแพร่หลาย แต่หลังการปรับนโยบาย จะตกอยู่นอกขอบเขตการรองรับมากขึ้น เพิ่มความเสี่ยงด้านการเชื่อมต่อและการปฏิบัติการระยะยาว ^[1] ดังนั้น นี่ไม่ใช่แค่ข้อกำหนดเกี่ยวกับ AI หนึ่งข้อ แต่เป็นโจทย์ใหญ่ของการกำกับดูแลการเชื่อมต่อ ERP ว่า API ใดเผยแพร่แล้ว การใช้งานแบบใดรองรับ การดึงข้อมูลต้องมีเงื่อนไขใด และระบบอัตโนมัติใดต้องเดินผ่านเส้นทางที่ SAP รับรอง ^[7][9][13]

ทำไม AI agent ภายนอกจึงถูกจับตามองเป็นพิเศษ

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

จุดนี้คือความต่างระหว่าง integration แบบเดิมกับ agentic AI แบบเดิมมักเป็นกระบวนการที่กำหนดไว้ล่วงหน้า เช่น ระบบหนึ่งเรียก API หนึ่งตัวตามกฎตายตัวเพื่อทำงานหนึ่งอย่าง แต่ AI agent อาจตัดสินใจเป็นขั้น ๆ ตามเป้าหมาย เช่น ตรวจข้อมูลผู้ขาย ดูสต็อก สร้างข้อเสนอจัดซื้อ แล้วส่งต่อเพื่ออนุมัติหรืออัปเดตข้อมูล หาก agent เป็นผู้เลือกและเรียงลำดับการเรียก SAP API หลายครั้งเอง ก็อาจเข้าข่ายพื้นที่ที่นโยบายกล่าวถึง ส่วนจะสอดคล้องหรือไม่ต้องดู API ที่ใช้ สถาปัตยกรรม บริการข้อมูล และการรับรองจาก SAP เป็นกรณีไป ^[5][10]

ข้อจำกัดชุดเดียวกันยังครอบคลุม scraping, harvesting รวมถึงการดึงหรือทำสำเนาข้อมูลอย่างเป็นระบบหรือในปริมาณมาก ^[5][10] ดังนั้นผลกระทบไม่ได้จำกัดเฉพาะ agent ที่เขียนข้อมูลกลับเข้า SAP เท่านั้น การอ่านข้อมูล SAP จำนวนมากเพื่อส่งไปยัง AI platform, lakehouse หรือ orchestration layer ภายนอกก็ต้องถูกตรวจสอบใหม่เช่นกัน ^[9][13]

ผลต่อการสร้างนวัตกรรม: PoC ยังทำได้ แต่จะไม่เร็วแบบเดิม

สำหรับทีม innovation, SI และ ISV ความเปลี่ยนแปลงใหญ่คือก่อนทดลองจะมีด่าน governance เพิ่มขึ้น เดิมทีทีมอาจเชื่อม AI agent เข้ากับ ERP เพื่อทดสอบงานอย่างการกระทบยอดอัตโนมัติ ผู้ช่วยจัดซื้อ วิเคราะห์สินค้าคงคลัง หรือ workflow บริการลูกค้าได้ค่อนข้างเร็ว แต่นโยบายใหม่นี้ทำให้ต้องตรวจให้ชัดก่อนว่า API อยู่ใน SAP Business Accelerator Hub หรือเอกสารผลิตภัณฑ์หรือไม่ สถาปัตยกรรมเป็นเส้นทางที่ SAP รับรองหรือไม่ ปริมาณการใช้งานชนโควตาหรือข้อจำกัดการดึงข้อมูลจำนวนมากหรือไม่ และ agent จะวางแผนการเรียก API หลายขั้นตอนเองหรือไม่ ^[5][7][9]

นั่นไม่ได้แปลว่า AI PoC ต้องหยุดทั้งหมด แต่ PoC จะมีลักษณะเหมือนโครงการ integration จริงมากขึ้น ต้องมีบัญชีรายการ API การออกแบบสิทธิ์ การประเมินปริมาณใช้งาน การตรวจเส้นทางข้อมูล และหลักฐานด้าน compliance ที่ชัดเจน ERP Today ระบุว่านโยบายนี้ทำให้เรื่องเชิงเทคนิคของการเชื่อมต่อกลายเป็นประเด็นสถาปัตยกรรม ERP ที่กว้างกว่าเดิม เพราะ integration เดิมอาจพึ่งพาอินเทอร์เฟซที่ไม่ได้อยู่ในเอกสาร ขณะที่แอป AI รุ่นใหม่ต้องการเข้าถึงข้อมูลและ workflow ธุรกรรมขององค์กรอย่างมีการควบคุม ^[13]

ความไม่แน่นอนเองก็ทำให้การทดลองช้าลง The Register รายงานว่า DSAG ซึ่งเป็นกลุ่มผู้ใช้ SAP ในประเทศที่ใช้ภาษาเยอรมัน วิจารณ์ว่านโยบายสร้างความไม่แน่นอน และรายงานเดียวกันระบุว่าผู้วิจารณ์มองว่ารายการอินเทอร์เฟซที่ SAP รับรองอาจยังไม่ถูกจัดการหรืออัปเดตดีพอ ^[2]

ผลต่อการควบคุมข้อมูล: ไม่ใช่แค่ใครเป็นเจ้าของข้อมูล

ข้อถกเถียงนี้ไม่ได้หยุดอยู่ที่คำว่าใครเป็นเจ้าของข้อมูลลูกค้า แต่อยู่ที่ลูกค้าสามารถใช้ AI platform, data stack และเครื่องมือ automation ที่ตนเลือก เพื่อเข้าถึงข้อมูลและกระบวนการธุรกรรมใน SAP แบบตรง เรียลไทม์ และต่อเนื่องได้แค่ไหน The Register วางประเด็นว่าเครื่องมือ AI ภายนอกบางส่วนอาจถูกกันออกจากข้อมูล SAP ของลูกค้า ส่วน ERP Today มองเรื่องนี้ในระดับสถาปัตยกรรมของเส้นทาง integration การทำสำเนาข้อมูล และการเข้าถึงของ AI ^[10][13]

หากองค์กรต้องการซิงก์ข้อมูล SAP ไปยัง lakehouse, AI platform, agent orchestration layer หรือระบบ automation ภายนอก ต้องตรวจเป็นพิเศษเรื่องโควตาข้อมูลเข้าออก เงื่อนไขการดึงหรือทำสำเนาข้อมูลจำนวนมาก ขอบเขตของ API ที่เผยแพร่แล้ว และความจำเป็นต้องใช้เส้นทางที่ SAP รับรอง ^[7][9][10]

ข้อจำกัดลักษณะนี้อาจช่วยรวมการควบคุมเรื่องปริมาณใช้งาน ความปลอดภัย และ governance ให้อยู่ในกรอบเดียวกัน แต่ต้นทุนคืออิสระของสถาปัตยกรรม AI ข้ามแพลตฟอร์มอาจลดลง โดยเฉพาะ use case ที่ต้องอ่านหรือเขียนข้อมูลธุรกรรม SAP ในปริมาณมาก ^[9][13]

ผลต่อ vendor lock-in: ความเสี่ยงเพิ่ม แต่ไม่ใช่ปลายทางที่เลี่ยงไม่ได้

ความเสี่ยง vendor lock-in เกิดจากโจทย์ตรงไปตรงมา หาก AI agent ภายนอกไม่สามารถโต้ตอบกับ SAP API ได้อย่างอิสระ ลูกค้าย่อมมีแนวโน้มต้องพึ่งสถาปัตยกรรมที่ SAP รับรอง บริการข้อมูลทางการ หรือวิธีเชื่อมต่อที่ SAP ระบุชัดมากขึ้น The Register อธิบายข้อกำหนด AI นี้ว่าเป็นเหตุให้เกิดความกังวลเรื่อง lock-in เพราะอาจทำให้เครื่องมือ AI ภายนอกบางส่วนเข้าถึงข้อมูล SAP ของลูกค้าไม่ได้ ^[10]

ปฏิกิริยาของ DSAG ชี้ว่าลูกค้าไม่ได้กังวลเฉพาะรายละเอียดทางเทคนิค E3 Magazine รายงานว่า DSAG เห็นว่าการที่ SAP จำกัดการใช้งานที่ไม่อยู่ในเอกสาร การดึงข้อมูลจำนวนมากอย่างเป็นระบบ และการโต้ตอบกับระบบ generative AI อัตโนมัติจากผู้ให้บริการภายนอกอย่างเข้มงวด เป็นเรื่องที่ยอมรับไม่ได้ ^[11]

อย่างไรก็ดี lock-in ไม่ใช่ผลลัพธ์เดียวที่ต้องเกิดขึ้นจริง ผลกระทบจะขึ้นกับว่า SAP อธิบายเส้นทางที่รับรองได้ชัดแค่ไหน รักษารายการ API ที่เผยแพร่ให้ครบถ้วนและทันสมัยเพียงใด และเปิดพื้นที่ให้ third-party vendor สร้างนวัตกรรมภายใต้กติกาที่ตรวจสอบได้หรือไม่ ผู้วิจารณ์ได้ชี้แล้วว่าการจัดการและการอัปเดตรายการที่รับรองอาจเป็นจุดอ่อน ซึ่งเป็นคำถามสำคัญสำหรับทีมจัดซื้อและทีมสถาปัตยกรรมองค์กร ^[2][7]

สิ่งที่องค์กรควรทำตอนนี้

1. ทำบัญชีรายการ SAP integration ทั้งหมด ระบุให้ได้ว่าแต่ละจุดใช้ API ที่เผยแพร่แล้ว API ในเอกสารผลิตภัณฑ์ อินเทอร์เฟซที่ไม่อยู่ในเอกสาร การดึงข้อมูลจำนวนมาก การอ่านเขียนแบบเรียลไทม์ RPA, iPaaS หรือ workflow และ agent ภายนอก ^[1][7][13]

2. แยก use case ที่เป็น AI agent อย่างชัดเจน กระบวนการใดที่โมเดลหรือ agent วางแผน เลือก หรือดำเนินการเรียก SAP API หลายขั้นตอนเอง ควรถูกประเมินความเสี่ยงด้านนโยบายก่อนเริ่มหรือก่อนขยายใช้งาน ^[5][10]

3. ตรวจการดึงและทำสำเนาข้อมูล การ extraction, replication, scraping หรือ harvesting ในปริมาณมากอยู่ในขอบเขตข้อจำกัดที่ต้องระวัง สถาปัตยกรรม data lake, lakehouse, BI, AI training หรือ data sync เดิมจึงควรถูกทบทวนเรื่องโควตา เงื่อนไข และเส้นทางที่อนุญาต ^[5][9][10]

4. ขอคำยืนยันเป็นลายลักษณ์อักษรจาก SAP หรือ implementation partner สำหรับกรณีเสี่ยงสูง เช่น agentic AI การอัปเดตธุรกรรมอัตโนมัติ การ orchestrate ข้ามระบบ หรือการส่งออกข้อมูลจำนวนมาก ไม่ควรพึ่งความเข้าใจปากเปล่าเพียงอย่างเดียว คำวิจารณ์ของ DSAG เรื่องความไม่แน่นอนยิ่งทำให้ขอบเขตที่เขียนชัดมีความสำคัญ ^[2]

5. ออกแบบให้ยังมีทางเลือก แม้สุดท้ายจะเลือกใช้เส้นทางที่ SAP รับรอง ก็ควรแยกชั้น AI orchestration, data governance, สิทธิ์การเข้าถึง, audit log และกฎธุรกิจให้เป็นโมดูลเท่าที่ทำได้ เพื่อไม่ให้ตรรกะนวัตกรรมทั้งหมดถูกผูกไว้กับเส้นทางเดียว

บทสรุป

ผลกระทบที่แท้จริงของนโยบาย API ใหม่ของ SAP ปี 2026 ไม่ใช่การประกาศว่า AI ใช้ SAP ไม่ได้ แต่คือ AI agent ภายนอกไม่ควรสมมติอีกต่อไปว่าสามารถเรียบเรียงและเรียก SAP API ได้อย่างเสรี นโยบายนี้ยกระดับข้อกำหนดด้านความปลอดภัย การควบคุมปริมาณใช้งาน และ governance ขณะเดียวกันก็เพิ่มต้นทุน compliance ทำให้การทดลองอาจช้าลง และทำให้ความเสี่ยง vendor lock-in ชัดขึ้น ^[10][13]

ทางปฏิบัติในระยะสั้นคือ ทำบัญชี integration ให้ครบ ระบุ use case ที่เป็น AI agent ตรวจเส้นทาง SAP ที่รองรับ และออกแบบสถาปัตยกรรมใหม่ให้ยังรักษาทางเลือกข้ามแพลตฟอร์มไว้ได้มากที่สุด