GCC AI Policy: What Gulf ERP Buyers Must Do Now

A Gulf logistics company renews its SAP contract in September. Buried in the new addendum is a clause permitting the vendor's AI models to process purchase-order data "for service improvement." Nobody in the procurement team flags it. Six months later, a Saudi PDPL audit asks where that data went. This is the practical shape of GCC AI policy risk — not a theoretical governance problem, but a specific contract moment that most operators will miss.

What the GCC AI policy actually says — and what it doesn't

In July 2026, the GCC steering committee accepted a policy recommended by its AI working group: the project will decline any "legally significant contributions which include LLM-generated content or are derived from LLM-generated content." ^[1] The threshold for "legally significant" is borrowed from the GNU Project maintainer guidelines — approximately 15 lines of code or text. ^[1]

Two things this policy does not do: it does not forbid using LLMs for research, analysis, bug discovery, or patch review; and it explicitly carves out AI-generated test cases at maintainer discretion. ^[1]

That context matters. The GCC steering committee policy governs open-source compiler contributions — it is not a commercial ERP regulation. But it is a leading indicator. When the region's foundational technical bodies start drawing enforceable lines at 15 lines of AI-generated text, the broader regulatory direction becomes legible. The question for Gulf operators is not "does this apply to my SAP instance today?" The question is: "what comes next, and is my vendor stack ready for it?"

The existing commercial framework is already live and already has teeth. The UAE AI Charter, Saudi Arabia's Personal Data Protection Law (PDPL), and Qatar's NCSA guidelines each impose overlapping obligations on enterprises deploying AI in the region. ^[2] A single ERP deployment spanning Dubai and Riyadh can sit under all three simultaneously.

Which systems are in scope: ERP, agents, and automation platforms

Governance conversations in the GCC tend to get framed as "AI projects" — a new chatbot, a demand-forecasting module, a generative summary tool. That framing lets the real risk surface hide in plain sight.

The systems that matter are the ones already running: the ERP core processing purchase orders and payroll, the RPA bots reconciling bank statements at 2 a.m., the workflow automation connecting WhatsApp approvals to inventory updates. These are not future AI projects. They are present operational infrastructure, and in many GCC businesses they have accumulated AI-adjacent capabilities through vendor updates that nobody formally approved.

According to research cited in regional governance analyses, 84% of GCC organisations had adopted AI in at least one business function by 2025. ^[2] More than 60% of those same organisations cite cybersecurity as a top AI risk, and over 50% cite compliance. ^[2] The gap between adoption rate and governance maturity is exactly where enterprise exposure accumulates.

Three categories of system deserve specific attention before any ERP renewal:

1. ERP core with embedded AI features — SAP Joule, Microsoft Copilot for Dynamics 365, Odoo's AI modules. Each vendor has updated these features through standard maintenance cycles, meaning capabilities may have expanded without a formal deployment decision. See our detailed comparison at Odoo vs SAP: Which ERP's AI Features Actually Work for GCC Operations?
2. Agentic automation layers — workflow tools sitting above or beside the ERP (n8n, Power Automate, custom Python pipelines). These often process business-critical data under contract terms written before agentic AI existed.
3. LLM integrations connecting to operational data — any system where a language model reads or writes to ERP records, whether that's a procurement assistant, a document parser, or a customer-facing chatbot pulling live inventory.

If your organisation cannot produce a current map of which AI capabilities are active in each category, that gap is the policy risk — not the policy document itself.

Three decisions Gulf operators need to make before their next software renewal

Compliance language in vendor contracts is set at renewal. Once signed, most data-processing addenda are effectively locked for the contract term. These are the three architecture and procurement decisions that need to happen before the signature:

1. Data residency and model training opt-outs. The Saudi PDPL imposes restrictions on cross-border personal data transfers. ^[2] Most enterprise ERP vendors offer data-residency options, but they are not always the default, and they often cost more. Equally important: determine whether your vendor's AI models train on your operational data, and whether there is a documented opt-out. This is a contract term, not a settings toggle.

2. Accountability chain documentation. GCC AI governance frameworks ask a consistent question: who is accountable when AI output is wrong? ^[2] For an ERP deployment, that means documenting which decisions the AI is making autonomously (routing, flagging, drafting) versus which it is informing. A procurement agent that auto-generates a purchase order and routes it for approval is making a decision. If the approval chain is perfunctory, the agent is effectively deciding. That accountability gap needs to be closed before renewal, not during a post-incident audit.

3. Audit rights over vendor AI models. Enterprise software agreements rarely grant customers meaningful audit rights over the AI models embedded in their licensed software. Before renewal, ask specifically: can you inspect the training data lineage for any AI feature that touches your business data? Can you request documentation of model updates? If the vendor cannot answer both questions, build that requirement into the contract or build the risk into your residual exposure register.

How the policy shifts the ERP vendor evaluation checklist

If you are evaluating ERP options for a Saudi Arabia or UAE deployment — whether greenfield, migration, or renewal — the traditional checklist (localisation, Arabic-language support, Zakat/VAT compliance, integration ecosystem) is necessary but no longer sufficient.

Add these five items:

• AI feature disclosure: Does the vendor publish a current list of active AI capabilities in the version you are licensing? Updates should not arrive silently through maintenance patches.
• Data processing addendum specificity: Does the DPA address AI model training separately from standard data processing? Generic DPAs predate generative AI and often do not cover it.
• Regional compliance attestations: Does the vendor hold or actively pursue attestations relevant to Saudi PDPL and UAE data residency requirements — not just ISO 27001, which says nothing about AI governance?
• Agent scope controls: If the ERP includes agentic features (auto-drafting, autonomous routing, proactive recommendations), can you scope, disable, or audit those features independently of the core license?
• Incident response for AI failures: What is the vendor's SLA when an AI feature produces a consequential error? "Contact support" is not an answer for a system processing GCC payroll or customs documentation.

For a deeper look at how this checklist applies to SAP's current product direction, Is AI FOMO Pushing You Into SAP RISE Too Early? is worth reading before your next vendor conversation.

The policy creates an architecture question, not just a compliance task

There is a temptation to route GCC AI policy requirements to the IT compliance team and move on. That routing produces a checkbox, not a decision. The architecture question the policy actually forces is: at what points in your operational workflow is AI generating output that enters a business process, and who bears accountability for that output?

That question cannot be answered by IT alone. It requires procurement (who owns the vendor contract terms), operations (which processes are AI-touching), legal (what the accountability exposure is under PDPL), and — in most GCC businesses — a founder or CEO who can actually sign off on a changed risk posture.

The 15-line threshold in the GCC compiler policy is a useful concrete anchor. ^[1] It is worth asking internally: is there any AI-generated text or logic in your ERP workflow that exceeds 15 lines and lacks documented provenance? In our experience, the honest answer for most operators is: probably yes, and we don't know exactly where.

For operators who have accumulated automation debt — workflow tools bolted onto ERP systems over several years, often with minimal documentation — the silent failure risk is compounding. When Automation Reports Success and Your Business Fails covers why those systems deserve the same scrutiny as a new AI deployment.

Tarsyn's view: use this moment to audit before you automate

The GCC AI policy cycle is not moving slowly. Three overlapping regulatory frameworks are already live. ^[2] A technical standards body just published an enforceable contributions policy. ^[1] The next cycle will be more specific, not less.

Most Gulf operators will process this as background noise until a renewal, an audit, or an incident forces the question. That is the wrong sequence.

The right sequence: before your next ERP renewal in Saudi Arabia or the UAE, run a readiness audit that maps active AI capabilities, documents accountability chains, and reviews vendor contract terms against current regional requirements. That audit should take two to four weeks, not six months, and it should happen before the vendor relationship is up for renegotiation — not after.

We are direct about what we find when we run these audits. Sometimes the answer is: your current vendor stack is fine, tighten three contract clauses and document two accountability decisions. Sometimes the answer is: you have seventeen automation touchpoints that nobody has reviewed since 2022, and three of them are making consequential decisions without a human in the loop. Either answer is better than the answer that arrives during a PDPL enforcement inquiry.

Our ERP AI Readiness Audit for GCC Operators outlines what a structured review actually covers. If you want to run one with us, the starting point is tarsyn.ai/Audit.

The policy is not the obligation. The obligation was already there. The policy just made it harder to claim you didn't see it coming.

---

By Mohammed Z, Tarsyn — Abu Dhabi & Khobar