Shadow AI
Tools adopted by teams, and features enabled by default inside software you already bought. The most common finding in a first discovery exercise, and the reason an inventory has to be technical as well as declared.
What we solve
AI governance and AI GRC
Adoption is running well ahead of governance in most organisations across the Gulf. The first problem is almost never policy — it is that nobody can list the AI systems already in the estate.
- STANDARD
- ISO/IEC 42001 management system
- METHOD
- Discover, assess, control, monitor, evidence
- SHARED WITH
- Your ISMS and privacy control set
- ALSO SEE
- How we govern our own AI
You cannot govern what you cannot list
Most first discovery exercises find three to five times what the organisation expected.
Boards across the region are asking the same two questions this year: are we behind on AI, and are we exposed by it. Both are usually answered with a policy document, which is the wrong artefact. A policy written over an estate nobody has inventoried governs nothing.
The organisations that are furthest ahead did the unglamorous thing first. They found the AI already running — the tools a team adopted, the features a vendor switched on, the model someone built in a business unit — and only then decided what to permit, what to control and what to stop.
That is where we start, and it is why our first deliverable is an inventory rather than a framework.
How AI governance actually runs
Five stages, operating continuously rather than as an annual assessment. Each writes to the same control library and evidence base as your cyber and privacy programme.
What we are asked to fix
Eight exposures that show up repeatedly, in roughly this order.
Data leakage into models
Confidential, regulated or personal data entering a third-party model through a prompt, a plugin or an integration — often with no record that it happened.
Model risk and drift
Performance degrading quietly after go-live, or behaving differently on a population it was not evaluated against. The failure mode nobody is monitoring for.
Vendor model change
Your supplier swaps or updates the underlying model and your risk position changes without a change request being raised anywhere in your organisation.
Automated decisions affecting people
Credit, pricing, hiring, claims and access decisions carry privacy obligations, explainability expectations and a reversal path that has to exist.
Prompt injection and agent misuse
Where an AI system can act — call a tool, send a message, change a record — its blast radius is the permissions you gave it.
Intellectual property and provenance
Training data rights, output ownership and the contamination risk of generated content entering products or filings.
Accountability gaps
The question that ends most board discussions: when the model is wrong, who was accountable, and can you show what they approved?
The service
Advisory, implementation and managed operation — the same three modes as the rest of the practice.
- AI discovery and inventory
- A technical and declared inventory of every AI system in the estate — standalone tools, embedded vendor features, models built in-house and agents with permissions. Classified by use case, data, affected parties and decision impact. This is where every engagement starts, because a policy written over an unknown estate governs nothing.
- AI risk assessment and quantification
- Use-case impact assessment covering purpose, data, provenance, failure modes and oversight. Where the exposure is material, quantified in USD using the same Open FAIR method as the rest of the risk estate, so an AI risk can be compared with a cyber risk and a supplier risk.
- ISO/IEC 42001 management system
- Scope, policy, roles, objectives, risk and impact assessment process, Annex A controls, internal audit and management review — built to certify if you want to, and built to share evidence with your ISMS either way.
- AI governance operating model
- Who approves an AI use case, at what risk tier, on what evidence, and who can stop one. Committee structures, delegated authority, escalation thresholds and a decision record that holds up afterwards.
- Controls and technical guardrails
- Controls applied by risk tier — data handling, access, logging, human-in-the-loop thresholds, output review, retention and permissions for agentic systems. Mapped into the same control library as your cyber and privacy controls, so a single test satisfies several obligations.
- Privacy and AI together
- Lawful basis for training and inference, transparency notices, DPIAs for high-risk processing, automated decision-making rights and cross-border transfer of training data — run by the same privacy function rather than a parallel one.
- Third-party and model supply chain
- AI capability assessed inside supplier due diligence: model provenance, sub-processor chains, change notification, evaluation evidence and exit. Your exposure includes your vendor's model choices.
- Monitoring and assurance
- Drift, degradation, unexpected use and vendor change watched after go-live. Control testing, internal audit interface and board reporting on the AI estate alongside everything else.
- Capability and awareness
- Role-based programmes through the Falconry Academy — what a developer needs is not what a board needs, and neither is a generic e-learning module.
The regulatory picture, market by market
AI regulation in this region is moving from principles to expectations to enforceable requirements. Indicative; applicability is confirmed per client during scoping.
| Instrument | What it is | What it means operationally | Market |
|---|---|---|---|
| ISO/IEC 42001:2023 | AI management system | The certifiable standard. Policy, roles, objectives, risk assessment, controls and internal audit — structured so the AI management system shares evidence with your ISMS rather than duplicating it. | International |
| NIST AI Risk Management Framework | Govern, Map, Measure, Manage | The neutral spine we use when several regimes apply at once, and the one most technology teams already recognise. | International |
| SDAIA AI Ethics Principles and Generative AI guidelines | Saudi Arabia | Principles-based expectations on fairness, transparency, accountability and human oversight, with guidance on generative AI use in government and regulated entities. | KSA |
| NCA and sector expectations | Saudi Arabia | AI systems in scope carry the same cybersecurity control expectations as any other system — plus the data controls that govern what the model is trained and run on. | KSA |
| UAE AI Charter and national AI strategy | United Arab Emirates | Federal direction on responsible AI, alongside sector guidance and the AI governance expectations emerging from financial and health supervisors. | UAE |
| Financial supervisor expectations | GCC central banks | Model risk management, explainability, human oversight and outsourcing expectations where AI supports credit, fraud, AML or customer decisions. | GCC |
| EU AI Act | Extraterritorial reach | Applies to Gulf organisations placing AI systems on the EU market or whose output is used in the EU. Risk-tiered obligations with real deadlines and real penalties. | EU |
| UK approach and ICO guidance | United Kingdom | A regulator-led model rather than a single statute, with ICO guidance on AI and data protection doing most of the operational work. | UK |
| Privacy law, everywhere | PDPL and GDPR | Training data, inference data and automated decision-making are all personal data questions before they are AI questions. Lawful basis, transparency and the right not to be subject to solely automated decisions apply regardless of the model. | All markets |
A realistic first ninety days
Most organisations do not need a two-year programme. They need to know what they have, stop the two things that are genuinely dangerous, and put a governed door in front of everything new.
- Weeks 1–4 · Discovery
Technical and declared inventory of the AI estate. Classification by use case, data, affected parties and decision impact. The findings conversation is usually the moment the programme gets funded.
- Weeks 4–8 · Triage and immediate controls
The small number of use cases carrying real exposure get assessed and controlled first. Everything else is registered and permitted to continue under monitoring, because stopping all of it is neither necessary nor survivable politically.
- Weeks 6–12 · The governed door
An intake and approval path for new AI use cases, with risk tiers, evidence requirements and named approvers. From this point the estate stops growing ungoverned.
- Weeks 8–14 · Management system
ISO/IEC 42001 structures stood up on the controls now in place, sharing evidence with the ISMS. Certification readiness if you want it; a defensible position either way.
- Ongoing · Monitored and reported
Drift, vendor change and new adoption tracked. AI risk reported to the board in the same currency as every other risk.
Two positions worth stating plainly
We are asking you to trust our AI governance. It is reasonable to test it.
- We govern our own AI to the standard we sell. FalconryX runs under the same ISO 42001 structures we help clients build. Every agent produces a draft or a flag; a named person approves anything that takes effect. We publish what each agent can and cannot do. See the agents and their guardrails.
- We will tell you not to adopt something. Where a use case cannot be made safe at an acceptable cost, the advice is to stop, and we will put that in writing. A governance advisor who has never recommended against an AI use case has not been doing the assessment.
How AI governance fits a transformation programme · Quantifying AI exposure in USD