ISO/IEC 42001, the NIST AI RMF, the EU AI Act and GCC national guidance all assume one thing. You already know which AI systems you run, who owns them and what they do.
Most organisations do not. Build that register first, keep it simple, and let it tell you which framework you need.
Why it matters now
Three things shape AI governance for Gulf organisations in 2026.
The UAE announced a federal Artificial Intelligence and Data Authority on 14 June 2026. It consolidates the AI Office, the TDRA’s digital government sector and the UAE Data Office. Its published mandate includes setting standards for government platforms and monitoring compliance across federal entities. As of 1 September 2026, its detailed powers had not been published. A federal entity should be able to answer “what AI do we use?” before anyone asks.
In Saudi Arabia, SDAIA’s AI Adoption Framework (September 2024) asks government bodies to set up AI units and assess their maturity. By late 2024, 23 government bodies had AI offices. The first honest maturity question is the inventory.
In Europe, the Digital Omnibus was published in the Official Journal on 24 July 2026. It moved the Annex III high-risk obligations from 2 August 2026 to 2 December 2027. GCC groups with European operations gained time. They did not gain clarity. You still cannot classify a system you have not listed, and most of the Article 50 transparency duties applied from 2 August 2026.
There is a fourth reason, and it is inside your building. A PagerDuty survey published in June 2026 asked 1,250 office professionals at large companies in the US, UK, Australia and Japan about AI use. 66% had used AI tools against company policy. 88% had shared work information with public AI tools. The sample is not GCC, and no comparable Gulf survey was found, but the pattern is a reasonable warning. The inventory you think you have is smaller than the one you actually run.
What every framework asks for first
The frameworks differ in legal weight. They agree on what you must know about each system.
| Framework | What it expects you to know about each AI system | Where it says so |
|---|---|---|
| ISO/IEC 42001:2023 | The data, tooling, infrastructure and people each system depends on; its lifecycle stage; third-party AI you use | Annex A control groups A.4 (resources), A.6 (lifecycle), A.10 (third parties) |
| NIST AI RMF 1.0 | Intended purpose and deployment context; how humans oversee outputs; application scope; third-party components and their risks | MAP 1.1, 2.2, 3.3, 4.1 and 4.2 |
| EU AI Act (post-Omnibus) | Enough about purpose, users and affected people to classify risk and, for high-risk systems, document them | Risk classification and technical documentation duties; Annex III from 2 December 2027 |
| UAE AI Charter | Transparency, human oversight, and governance and accountability for AI you develop or use | Three of the Charter’s 12 principles |
| SDAIA Adoption Framework | Where AI sits in the organisation and how mature its management is | Phase one: AI units and maturity assessment |
Purpose, owner, affected people and oversight recur across the rows. Data and suppliers appear in the three detailed standards. One register serves all five.
This is not legal advice. The frameworks above are summarised to show the common pattern, not to tell you which obligations apply to you.
The minimum viable record
Start with what counts. Most first inventories list the obvious: the chatbot on the website and the model the data team built. They miss three categories.
- Embedded AI in software you already license. CRM lead scoring, HR screening, security tooling, document management. The vendor added AI in a release note nobody read.
- Generative AI assistants used by staff. Approved or not, in the browser or on a phone.
- Models inside delivered systems. A contractor built it, trained it and left. Your entity operates it.
A simple rule keeps the list honest. If a system makes or shapes a decision, generates content, or ranks people, it goes in. When unsure, include it. The US federal inventory guidance of August 2024 took a similarly broad view, flagging rights- and safety-impacting uses and keeping retired systems on the list.
Twelve fields are enough for a first pass. Keep them in a spreadsheet or the GRC tool you already have. Do not buy a platform to make a list.
| # | Field | Why it matters | Hypothetical example |
|---|---|---|---|
| 1 | ID | Stable reference across audits | AI-0017 |
| 2 | Name | What people call it | Complaints triage assistant |
| 3 | Business owner | Who answers for outcomes | Head of Customer Happiness |
| 4 | Technical owner | Who can change or switch it off | Applications lead |
| 5 | Purpose (one sentence) | The basis for every risk question | Sorts incoming complaints by urgency and routes them |
| 6 | Who it affects | Public, staff, customers, suppliers | Members of the public |
| 7 | Decision influence | Informs / assists / decides | Assists (a case officer confirms) |
| 8 | Data used | Including personal data, yes or no | Complaint text, contact details: yes |
| 9 | Source | Built / bought / embedded / public tool | Embedded in CRM |
| 10 | Vendor and model | For supplier controls and updates | CRM vendor, model version per release notes |
| 11 | Lifecycle stage | Idea / pilot / live / retired | Live since March 2026 |
| 12 | Last reviewed | Proves the record is maintained | 2026-10-15 |
The example row is hypothetical. It describes no real entity or product.
Fields 6, 7 and 8 do most of the work later. Together they tell you whether a system touches the public, makes decisions about people, or processes personal data. Those three answers drive risk classification under the EU AI Act, the NIST AI RMF and ISO/IEC 42001.
Retired systems stay in the register, marked as retired. An auditor will ask what you used to run.
How to find what is not on the list
In our estimate, a mid-sized entity can complete a first inventory in about four weeks if one person owns it. Run these five steps in parallel.
- Pull procurement and licence records. Search contracts and purchase orders for “AI”, “machine learning”, “model”, “automation” and vendor product names known to include AI features.
- Ask application owners with a ten-minute form. Five questions: what the system does, who it affects, whether it decides anything, what data it uses, and who the vendor is.
- Check sign-on and network logs for AI service domains. This finds the tools people use, not the ones they declare.
- Survey staff with an amnesty. The goal is visibility, not discipline. Say so in writing. The PagerDuty figures show what happens when staff expect penalties: they keep using the tools and stop telling you.
- Read vendor contracts for AI clauses. Some SaaS agreements now reserve the right to add AI features or use your data to improve models.
Merge the five lists. Expect the merged list to be considerably longer than your first guess.
What to do next
Once the register exists, the pattern in it tells you where to start.
- Mostly bought or embedded AI. Your risk sits with suppliers. Start with the ISO/IEC 42001 A.10 third-party controls and with contract clauses, not with certification.
- Systems that affect the public or make decisions about credit, hiring or benefits. Start with risk classification. The EU AI Act’s Annex III categories are a useful lens even outside the EU, because they name the use cases regulators everywhere worry about first.
- Mostly staff productivity tools. Start with an acceptable-use policy and AI literacy. Certification can wait.
A good inventory also makes the expensive steps cheaper. The ISO/IEC 42001 scope statement, the NIST MAP function and the EU AI Act classification all begin with the same question: what AI systems are in scope? With a register, that question is largely already answered.
Five actions, in order:
- Name an inventory owner this week. One person, with authority to ask every department.
- Adopt the twelve-field record. Resist adding fields until the first pass is complete.
- Run the five discovery steps with a four-week deadline.
- Tag each system on three questions: affects the public? processes personal data? makes a decision?
- Decide framework scope from what the tags show, not from what a vendor is selling.
MAAI offers inventory and risk-classification sprints for government and enterprise entities in the GCC, as the first step of our AI governance and assurance service. If you need to answer “what AI do we use?” with confidence, talk to us.
Sources
- Future of Privacy Forum, The AI Act implementation timeline: what changes under the AI Omnibus?, 28 July 2026 (updated 5 August 2026).
- Gibson Dunn, EU AI Act Omnibus Agreement — Postponed High-Risk Deadlines and Other Key Changes, 27 May 2026.
- Al Tamimi & Company, UAE Establishes New Federal Authority for AI and Data, 1 September 2026.
- UAE Government portal, The UAE Charter for the Development and Use of Artificial Intelligence, updated 3 July 2026.
- Al Riyadh Daily, SDAIA Launches AI Framework to Promote Ethical, Responsible Use, 1 December 2024.
- IEC Webstore, ISO/IEC 42001:2023, published 18 December 2023.
- SureCloud, ISO/IEC 42001 Annex A Controls Explained, 27 July 2026.
- NIST, NIST Risk Management Framework Aims to Improve Trustworthiness of Artificial Intelligence, 26 January 2023.
- Ankura, Implementing the NIST AI Risk Management Framework — Map, 1 April 2024.
- US CIO Council, 2024 Guidance for AI Use Case Inventories, 14 August 2024.
- PagerDuty, 66% of Office Professionals Have Used Unauthorized AI Tools at Work, 11 June 2026.
All sources accessed 3 November 2026. This article explains governance options; it is not legal advice.