One AI governance programme that answers buyers in the EU, US and UAE

The situation

An AI software company sold to enterprises in Europe, the United States and the Gulf. Its products used large language models for summarisation, classification and agent-style automation. Every serious deal now came with a security questionnaire, an AI questionnaire and often a data protection review. The questions overlapped heavily but never matched exactly, so the CTO and a few senior engineers answered them by hand, deal after deal.

Meanwhile the rules kept moving. The EU AI Act's obligations were phasing in, then partly delayed; US buyers asked about SOC 2 and the NIST AI framework; Gulf buyers asked about data residency and local regulation. The company needed one answer, not three.

What had to be true

• One inventory of every AI system and feature, with owner, purpose, models, data and risk rating.
• One control set, mapped to each framework, rather than a programme per regulation.
• Evidence by design: logs, evaluations and approvals produced by the delivery pipeline, not gathered by hand.
• Proportionate: governance effort matched to risk, so low-risk features ship without ceremony.
• Owned by engineering and product, with legal and security as partners rather than gatekeepers.

Architecture

The data flow, end to end

The frameworks fit together better than their language suggests. The NIST AI Risk Management Framework organises AI risk work into govern, map, measure and manage functions⁴. ISO/IEC 42001 specifies a certifiable AI management system³. SOC 2 reports on controls against the trust services criteria for service organisations⁵. One control can satisfy all three when it is written once and mapped carefully, as discussed in ISO 42001 vs the NIST AI RMF and SOC 2 for AI startups.

The hard part: a moving regulatory timeline

The EU AI Act applies different obligations at different times¹. AI literacy duties already applied⁶, transparency obligations under Article 50 applied from 2 August 2026, and, as reported after the Digital Omnibus, stand-alone high-risk obligations moved to December 2027 with Annex I products following in August 2028². Building for a single deadline would have meant rework every time it moved.

• Obligations were attached to inventory entries by role and use case, not to a calendar, so a date change updated a field, not a plan.
• Controls that are valuable regardless of deadlines, such as inventory, evaluation, logging and human oversight, were built first.
• High-risk-specific controls were designed early but switched on per product as classification and timelines firmed up.
• Each EU AI Act question was tracked as provider or deployer, because the obligations differ.

The background is in the Digital Omnibus roadmap, when fine-tuning makes you a provider and, for Gulf buyers, the UAE's Federal Authority for AI and Data.

How it ran

Key decisions and trade-offs

What I'd do again, and differently

Again: start with the inventory and let engineering pipelines produce the evidence. Differently: involve sales engineering from the start. They see every questionnaire, and their list of repeated questions is the fastest way to prioritise which controls and evidence to build first.

If AI questionnaires are slowing your deals, my fractional CTO work covers governance programmes like this, or analyse your challenge and bring the result to a call.