นโยบาย API ใหม่ของ SAP: ทำไม AI agent ภายนอกจึงสั่งงาน SAP ได้ยากขึ้น

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

บทสรุป

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

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