เมื่อ SAP อัปเดต API Policy ในเดือนเมษายน 2026 คำถามว่า AI agent ของบุคคลที่สามจะต่อเข้าระบบ SAP ได้หรือไม่ ไม่ใช่เรื่องสายเชื่อมต่อหรือ token ทางเทคนิคเพียงอย่างเดียวอีกต่อไป แต่กลายเป็นเรื่องสถาปัตยกรรมองค์กร สิทธิตามสัญญา และธรรมาภิบาลข้อมูลไปพร้อมกัน ^[5][6][10]

ตัวนโยบายของ SAP ระบุว่ามีไว้เพื่ออธิบาย API availability และ API limits พร้อมวาง controls เพื่อปกป้อง solution health และ security ส่งเสริมการเข้าถึงอย่างเป็นธรรม และป้องกันการใช้ API ในทางที่ผิด ^[9] จุดที่ทำให้เกิดแรงสะเทือนคือข้อเกี่ยวกับ AI โดยบทวิเคราะห์และสื่อภายนอกระบุว่า Section 2.2.2 ของ API Policy v4/2026 มุ่งไปที่ระบบ semi-autonomous หรือ generative AI ที่สามารถวางแผน เลือก หรือเรียก API เป็นลำดับได้เอง และห้ามการโต้ตอบหรือการอินทิเกรตลักษณะนี้ เว้นแต่จะผ่านสถาปัตยกรรม บริการข้อมูล หรือช่องทางเฉพาะบริการที่ SAP รับรอง ^[6][8][10]

พูดให้สั้นลง: AI agent ภายนอกไม่ควรตั้งสมมติฐานอีกต่อไปว่าสามารถใช้ SAP API เป็นชั้นปฏิบัติการอิสระ แล้วจัดเรียงขั้นตอนอ่าน เขียน อนุมัติ หรือปรับข้อมูลในระบบหลักได้เองตามใจ ^[6][8][10]

เส้นแบ่งสำคัญ: AI แนะนำ หรือ AI ลงมือใน SAP

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

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

ขอบเขตใหม่ที่องค์กรต้องอ่านให้ชัด

1. Third-party AI agent ต้องมีเส้นทางที่ SAP รับรอง

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

ดังนั้น ความจริงที่ว่าเชื่อมต่อ API ได้ในเชิงเทคนิค ไม่ได้แปลว่าใช้ได้ในเชิงนโยบายโดยอัตโนมัติ คำถามสำคัญจึงเปลี่ยนเป็น โซลูชันนั้นอยู่ใน SAP-endorsed architecture, data service หรือ service-specific pathway ที่ SAP ระบุไว้หรือไม่ ^[10]

2. API ที่เผยแพร่และมีเอกสารกำกับกลายเป็นขั้นต่ำ

SAPInsider ระบุว่าการอัปเดตครั้งนี้ทำให้การเข้าถึงระบบถูกจำกัดไปสู่ published, documented APIs มากขึ้น ขณะที่ API ที่ไม่มีเอกสารกำกับจะอยู่นอกขอบเขตการสนับสนุน และเพิ่มความเสี่ยงต่อการอินทิเกรตและการปฏิบัติการระยะยาว ^[5] นโยบายของ SAP เองนิยาม Published APIs ว่ารวมถึง API ที่เผยแพร่บน SAP Business Accelerator Hub หรือ API Hub และ API ที่ถูกระบุไว้ในเอกสารเฉพาะของผลิตภัณฑ์ ^[9]

สำหรับองค์กรที่เคยพึ่งพา connector รุ่นเก่า อินเทอร์เฟซเฉพาะกิจ หรือ API ที่ไม่ได้อยู่ในเอกสารทางการ เรื่องนี้แปลว่าต้องกลับมาตรวจคลังการเชื่อมต่อเดิมอย่างจริงจัง แม้บางอินทิเกรตจะยังทำงานได้วันนี้ แต่ความไม่แน่นอนด้าน support, compliance และการอัปเกรดในอนาคตจะสูงขึ้น ^[5][9]

3. การดึงและคัดลอกข้อมูลจำนวนมากก็ถูกจับตามอง

ข้อใหม่ไม่ได้พูดถึงเฉพาะ AI agent ที่เรียก API หลายขั้นตอนเท่านั้น Fivetran และ The Register ระบุว่านโยบายยังครอบคลุม scraping, harvesting รวมถึงการดึงหรือจำลองข้อมูลแบบเป็นระบบหรือในปริมาณมาก เว้นแต่จะผ่านสถาปัตยกรรมและช่องทางที่ SAP ควบคุมหรือรับรอง ^[8][10]

ดังนั้น หากองค์กรต้องการคัดลอกข้อมูล SAP จำนวนมากไปยัง data lake, data warehouse หรือแพลตฟอร์ม AI นอก SAP การประเมินไม่ควรดูแค่ throughput ค่าใช้จ่าย หรือความง่ายของ pipeline แต่ต้องดู API policy สิทธิตามสัญญา API limits ข้อกำหนด audit และเส้นทางที่ SAP ยอมรับด้วย ^[8][9][10]

4. เส้นทางในระบบนิเวศ SAP จะดูปลอดภัยกว่าในสายตาทีมกำกับดูแล

เอกสารทางการของ SAP ระบุว่าองค์กรสามารถสร้าง AI agents บน SAP BTP และทำงานร่วมกับ Joule ซึ่งเป็น AI copilot ของ SAP รวมถึงใช้โครงสร้างพื้นฐาน AI บน SAP BTP ได้ ขณะเดียวกัน SAP Cloud SDK for AI ยังเชื่อมกับ agent framework ยอดนิยมผ่าน adapter เช่น LangChain ได้ด้วย ^[1] SAP ยังวาง SAP Knowledge Graph เป็นความสามารถที่ช่วยให้ Joule และ AI อื่น ๆ รวมถึง AI agents ตอบได้แม่นยำและเกี่ยวข้องมากขึ้น โดยอิงบริบทธุรกิจที่อยู่ในแอปพลิเคชัน SAP ^[4]

นี่ไม่ได้หมายความว่าโซลูชันของบุคคลที่สามทั้งหมดใช้ไม่ได้ แต่เมื่อเส้นแบ่งของนโยบายแคบลง เส้นทางที่เป็นทางการหรือได้รับการรับรองย่อมผ่านการพิจารณาของทีมสถาปัตยกรรม กฎหมาย ความเสี่ยง และความปลอดภัยได้ง่ายกว่า ^[1][4][10]

โปรเจกต์ AI แบบไหนได้รับผลกระทบมากที่สุด

กรณีใช้งาน	ระดับความเสี่ยงโดยประมาณ	เหตุผล
ใช้ข้อมูลที่ดึงอย่างถูกสิทธิ์ไปทำ BI รายงาน หรือวิเคราะห์แบบออฟไลน์	ต่ำถึงกลาง	หาก AI ไม่ได้จัดลำดับและเรียก SAP API โดยตรง ความเสี่ยงด้าน agentic AI จะต่ำกว่า แต่ถ้ามีการดึงหรือคัดลอกข้อมูลจำนวนมากยังต้องตรวจขอบเขตนโยบาย [8][10]
Chatbot ให้คำแนะนำ แล้วให้คนเข้า SAP ไปดำเนินการเอง	ต่ำ	ข้อหลักมุ่งไปที่ AI ที่วางแผน เลือก หรือเรียก API เป็นลำดับเอง กระบวนการที่มีคนยืนยันและลงมือใน SAP จึงต่างจาก agent ที่ปฏิบัติการโดยตรง [6][8]
AI ตรวจสต็อก แก้คำสั่งซื้อ เปิดใบสั่งซื้อ อนุมัติ หรืออัปเดต master data อัตโนมัติ	สูง	มักเกี่ยวข้องกับการเรียก API หลายขั้นตอน การเขียนกลับ และการเปลี่ยนสถานะทางธุรกิจ ซึ่งเข้าใกล้รูปแบบ agentic AI ที่นโยบายให้ความสำคัญ [6][8][10]
คัดลอกข้อมูล SAP จำนวนมากไปยังแพลตฟอร์มภายนอกเพื่อให้ AI ใช้งาน	สูง	นโยบายระบุถึง scraping, harvesting และการดึงหรือจำลองข้อมูลแบบเป็นระบบหรือขนาดใหญ่ [8][10]
connector รุ่นเก่าหรืออินทิเกรตเฉพาะกิจที่พึ่งพา API ไม่มีเอกสาร	กลางถึงสูง	SAPInsider ระบุว่า API ที่ไม่มีเอกสารอยู่นอกขอบเขต support ขณะที่นโยบาย SAP นิยาม Published APIs ผ่าน API Hub หรือเอกสารผลิตภัณฑ์ [5][9]

ผลต่อการสร้างนวัตกรรม: PoC ต้องผ่านคำถามด้านสถาปัตยกรรมเร็วขึ้น

ในมุมการกำกับดูแลแพลตฟอร์ม SAP มีเหตุผลที่จะจำกัด agent ภายนอกไม่ให้เรียก API ของ ERP หลักอย่างไม่มีขอบเขต โดยเฉพาะงานที่เกี่ยวกับการเขียนข้อมูล กระบวนการธุรกรรม และประสิทธิภาพของระบบ เพราะ SAP API Policy ระบุวัตถุประสงค์ของ controls ไว้ชัดเจนว่ารวมถึงการปกป้อง solution health, security, การเข้าถึงอย่างเป็นธรรม และการป้องกัน API misuse ^[9]

แต่ในมุมทีมพัฒนา ต้นทุนก่อนเริ่ม proof of concept จะสูงขึ้น เดิมทีการทดลองอาจเริ่มจากขอสิทธิ์ API สร้าง connector แล้วทดสอบ workflow ได้ค่อนข้างเร็ว แต่ถ้า AI จะตัดสินใจเองว่าควรทำอะไรต่อและเรียก API ข้ามหลายบริการ ทีมต้องยืนยันก่อนว่า use case นั้นอยู่ในสถาปัตยกรรม บริการข้อมูล หรือช่องทางเฉพาะบริการที่ SAP รับรองหรือไม่ ^[8][10]

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

ผลต่อการควบคุมข้อมูล: เข้าถึงข้อมูลได้ ไม่เท่ากับให้ AI ลงมือได้ทันที

นโยบายนี้ว่าด้วย API availability, API limits และ controls เป็นหลัก ไม่ใช่ประกาศเรื่องกรรมสิทธิ์ข้อมูลแบบครบถ้วน ^[9] แต่ในยุค agentic AI คำว่า control ไม่ได้หมายถึงแค่ว่าองค์กรดาวน์โหลดรายงานได้หรือไม่ หากยังหมายถึงว่าใครสามารถอ่าน เขียน จัดลำดับ และเรียก API แบบเรียลไทม์จนเปลี่ยนสถานะธุรกิจใน SAP ได้ ^[6][8][10]

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

อย่างไรก็ดี ควรระบุอย่างเป็นธรรมว่า บทวิเคราะห์ของ Kai Waehner อ้างถึงคำชี้แจงของ Christian Klein ซีอีโอ SAP ว่าเจตนาของนโยบายคือปกป้อง domain know-how ของ SAP และป้องกัน performance degradation ไม่ใช่การกีดกันลูกค้าจากข้อมูลของตัวเอง ^[6] สำหรับองค์กร ประเด็นสำคัญคือการแปลงคำอธิบายเหล่านี้ให้เป็นเงื่อนไขที่ตรวจสอบได้ในสัญญา API policy รายการสถาปัตยกรรมที่รับรอง และการอนุญาตราย use case ^[6][9][12]

Vendor lock-in อาจย้ายไปอยู่ที่ชั้น orchestration

Vendor lock-in ไม่จำเป็นต้องแปลว่าข้อมูลส่งออกไม่ได้เลย ในยุค AI agent การผูกติดกับผู้ขายอาจเกิดที่ชั้นการจัดกระบวนการ หรือ orchestration layer มากกว่า หากเส้นทางที่ปลอดภัยที่สุด โต้แย้งน้อยที่สุด และผ่าน compliance ง่ายที่สุด คือการวาง agent ไว้ใน SAP BTP, Joule, SAP AI Core หรือเส้นทางที่ใช้ SAP Knowledge Graph สถาปัตยกรรม AI ระยะยาวขององค์กรก็ย่อมพึ่งพาระบบนิเวศ SAP มากขึ้น ^[1][4][10]

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

องค์กรควรทำอะไรตอนนี้

1. แยก use case ให้ละเอียดก่อนเริ่มทำจริง ระบุให้ชัดว่าเป็น read-only, write-back, ต้องมีคนยืนยัน หรือ AI ทำหลายขั้นตอนเอง เพราะความเสี่ยงจะสูงขึ้นมากในสองกรณีหลัง ^[6][8][10]
2. ขอคำยืนยันเรื่องเส้นทางที่ SAP รับรอง ถาม SAP หรือ system integrator ว่าแต่ละ use case ทำผ่าน SAP-endorsed architecture, data service, service-specific pathway หรือสถาปัตยกรรมที่เกี่ยวกับ SAP BTP และ Joule ได้หรือไม่ ^[1][10]
3. ตรวจว่า API เป็น published และ documented จริงหรือไม่ หากอินทิเกรตเดิมพึ่งพา API ที่ไม่มีเอกสาร ต้องเตรียมแผน refactor และบริหารความเสี่ยงด้าน support เพราะ SAPInsider ระบุว่าความเสี่ยงระยะยาวของอินทิเกรตกลุ่มนี้สูงขึ้น ^[5][9]
4. เขียนสิทธิข้อมูลและความรับผิดชอบลงในสัญญาและเอกสาร governance โดยเฉพาะเรื่องการใช้ third-party AI การดึงและจำลองข้อมูล API limits audit ความรับผิดชอบเมื่อเกิด incident และขอบเขตความรับผิดเมื่อ AI เขียนกลับ SAP ^[8][9][10]
5. ติดตาม FAQ และการอัปเดตนโยบายของ SAP ต่อเนื่อง เอกสาร FAQ ของ SAP ระบุว่าจะตอบคำถามทั่วไปเกี่ยวกับ API Policy และอาจมีการอัปเดตเป็นระยะ องค์กรจึงไม่ควรพึ่งพาการตีความด้วยวาจาเพียงครั้งเดียว ^[12]

บทสรุป

สาระหลักของนโยบาย API ใหม่คือ third-party AI agent ไม่ควรถือว่าสามารถจัดลำดับและเรียก SAP API ได้อย่างเสรีอีกต่อไป สำหรับงานรายงาน การวิเคราะห์ออฟไลน์ หรือ chatbot ที่ให้คนยืนยันก่อนดำเนินการ ผลกระทบอาจจำกัดกว่า แต่สำหรับองค์กรที่ต้องการให้ AI ลงมือกับกระบวนการหลักของ SAP เขียนกลับ ERP หรือคัดลอกข้อมูลจำนวนมากไปยังแพลตฟอร์มภายนอก นี่คือจุดตรวจสำคัญทั้งด้านสถาปัตยกรรม สัญญา และธรรมาภิบาลข้อมูล ^[8][10]

ถ้าองค์กรลงทุนกับ SAP BTP, Joule และ SAP AI Core อยู่แล้ว นโยบายนี้อาจทำให้เส้นทางทางการชัดขึ้น ^[1][4] แต่ถ้าองค์กรต้องการสร้างชั้น AI agent แบบเปิดที่ทำงานข้าม ERP, CRM, ซัพพลายเชน และแพลตฟอร์มข้อมูล ควรยืนยันสถาปัตยกรรมที่ SAP รับรอง สิทธิการใช้ API และขอบเขตการดึงข้อมูลก่อนลงแรงพัฒนา เพื่อไม่ให้โครงการนวัตกรรมไปตั้งอยู่บนรูปแบบอินทิเกรตที่ภายหลังอาจเดินต่อไม่ได้ตามนโยบาย ^[5][10]