AI readiness checklist: five gates to pass before you commit build budget

AI strategy & adoption

Your board has said "do AI". The first money is usually spent on a model, a pilot team or a proof of concept, and that is the wrong order. Before any code, run five readiness gates: data accessibility, integration surface, infrastructure fit, governance ownership and executive alignment. Each has a pass or fail test you can apply in an afternoon. This is the checklist we run with clients in the UAE before anyone commits build budget, and it will tell you exactly what you are walking into.

Why readiness comes before use cases

The GCC has an adoption surplus and a value deficit. McKinsey's November 2025 survey of 139 senior executives and board directors across all six GCC countries found that 84% of organisations now use AI in at least one business function, up from 62% in 2023. But only 31% have scaled or fully deployed AI across the organisation, and just 11% qualify as "value realizers" (AI in at least one function, deployment at scale, and at least 5% of earnings attributed to AI). Meanwhile 89% plan to increase AI budgets next year.

So most organisations here are about to spend more money on something that has not yet worked at scale. The usual cause is not the model. It is that nobody checked whether the organisation could carry the project before it started. The MIT Sloan Management Review Middle East readiness study with Pure Storage (July 2025) puts numbers on that carrying-capacity problem: only 33% of organisations report that more than 30% of their data is accessible for AI use, integration complexity is the most cited obstacle at 67%, and outdated infrastructure follows at 56%.

A readiness assessment answers one question: what has to be true in this organisation before an AI system can produce reliable output in production? Everything below is written as a gate with a pass or fail test, because "somewhat ready" is how pilot graveyards get filled.

The five gates at a glance

Run the gates in order. A fail at any gate stops build budget and redirects it to fixing that gate.

One scoring rule: five passes means green light. Four means build one use case only. Three or fewer means no build budget at all, because you would be building on ground that cannot bear the weight.

Gate 1: data accessibility

Stored is not the same as queryable. Data sitting in a warehouse, a lakehouse table or an indexed document store is queryable. Data sitting in a shared drive as PDFs, in a retired ERP nobody can export from, or in three unlinked copies of the same customer list, is merely stored. Models cannot read what your engineering team cannot query.

The test. Name the three datasets your first use case needs. For each, ask: can a model read this today through SQL, an authenticated API or a search index, within one hour of engineering time? Measure the share of required records that clears that bar. Pass at 80% or above. Below 80%, the project will spend its first quarter as a data engineering project wearing an AI costume, and you should plan it as such honestly.

Example. A UAE insurer wants an assistant that drafts claim responses. It has 2.1 million claims since 2019. 61% sit in the core claims system behind a REST API. 39% are scanned paper forms on a network share with no index. That is a fail at 61%. The fix is real work with real numbers: roughly 820,000 scanned documents to OCR, classify and index before the assistant sees them. Do that as phase one and the model phase becomes straightforward.

Regional context matters here. The same MIT study found 72% of regional organisations prefer hybrid environments for AI workloads, which is usually an admission that data is split between what you can move and what you cannot. Identify the cannot-move category in week one.

Gate 2: integration surface

AI systems earn their keep by acting on your systems of record: creating the case, updating the policy, filing the ticket. Each action is an integration. Legacy integration debt becomes AI project debt at exactly the moment you can least afford it.

The test. List every system the use case reads from and writes to. For each, confirm four things: a documented API (machine-readable, not a PDF from 2014), authenticated access with a test environment, a named owner on the vendor or platform side, and published rate limits. Then count write-backs into systems of record. More than three write-backs without an API on the other end is a fail.

The OpenAPI Specification (current version 3.2.0, published 19 September 2025) is the practical standard here. It defines a language-agnostic description of an HTTP API that both people and tools can read. If a system can hand you an OpenAPI document, your team can generate a client and validate payloads in days rather than weeks. If it cannot, you are reverse-engineering someone's SOAP service.

openapi: 3.2.0
info:
  title: Claims Read API
  version: 1.0.0
paths:
  /claims/{claim_id}:
    get:
      operationId: getClaim
      parameters:
        - name: claim_id
          in: path
          required: true
          schema: { type: string, format: uuid }
      responses:
        "200":
          description: Claim record
          content:
            application/json:
              schema: { $ref: "#/components/schemas/Claim" }

Example. The insurer's core claims platform passes: modern REST API, OpenAPI document on request, sandbox environment on request. The 2011 document management system fails: nightly SFTP batch export only, no API, no named vendor owner. The right response is not to redesign the estate around the pilot. It is to scope the use case so the assistant reads claims from the core system and never touches the document system, while a thin integration layer is funded separately.

Gate 3: infrastructure fit

Infrastructure is not a preference question. It is a latency, residency and cost question, in that order.

The test. Write down three numbers before you speak to any vendor: the p95 response time your users will tolerate (for a staff-facing assistant, typically 2 to 3 seconds to first useful answer), the data residency rule that applies to the data (UAE and Saudi regulators and, just as often, your own customers, require in-country processing), and your load shape (steady 24/7 or spiky). Those three numbers usually eliminate two of the three lanes immediately.

For cost anchoring, take a standard training and serving node: an AWS EC2 p5.48xlarge carries 8 NVIDIA H100 SXM GPUs (80 GB each), 192 vCPUs and 2,048 GiB of RAM. In us-east-1 the on-demand list price is $55.04 per hour, about $6.88 per GPU-hour, or roughly $40,200 for a 730-hour month (AWS public price list). Spot capacity starts near $21.09 per hour in that region, which cuts the month to roughly $15,400, at the price of interruption. If your workload cannot tolerate interruption, spot is not a discount, it is a different product.

That arithmetic is why the load-shape question decides the lane. One node running flat out at $40,200 a month serving 200 requests a day is a scandal. The same node serving 20,000 requests a day at a 3-second p95 is sensible. Compute the per-request cost before the procurement meeting, not after.

Regional supply is moving fast in your favour: G42's Stargate UAE alliance (announced May 2025) and the HUMAIN and NVIDIA data centre build-out in Saudi Arabia are expanding in-region capacity, and 72% of regional organisations already prefer hybrid setups. In-region GPU options are a genuine choice now, not a compromise.

Example. The insurer's assistant must answer in 3 seconds p95, and the claims data cannot leave the UAE. A hosted API abroad fails residency. That leaves in-region GPU-as-a-service for the pilot and own hardware if demand becomes steady. The team sized a single 8-GPU node as the ceiling and wrote the cost into the business case at $6.88 per GPU-hour before choosing a provider.

Gate 4: governance ownership

Governance here means: who signs, how often, and on what record. Not legal compliance (that is a separate exercise), but the internal discipline that keeps a changing model inside the rules.

The test. Four things must exist in writing: a named role that signs off model and prompt changes before release, a review cycle of six months or less, a register listing every model, prompt template and data source in production with an owner and a version, and an escalation path for when output is wrong in front of a customer. Pass only if all four exist. "The AI committee reviews as needed" is a fail.

The regional benchmark has moved decisively. A Cohesity study conducted by YouGov, published ahead of GITEX 2025, surveyed 330 senior IT and business leaders in August 2025 and found 70% of UAE organisations now review AI compliance every six months or less, a shift away from annual checklist reviews. 66% maintained full compliance with UAE data regulations over the past year, and 62% now monitor compliance across third-party data providers directly. If your cycle is annual, you are now the outlier.

For structure, adopt the NIST AI Risk Management Framework (AI RMF 1.0, released 26 January 2023) and its Generative AI Profile NIST-AI-600-1 (released 26 July 2024). Both are free, mapped to other standards, and available in Arabic, which makes them usable in a GCC governance paper without translation work. Note that NIST has said AI RMF 1.0 is being revised under the White House AI Action Plan, so anchor your internal policy to the framework's structure, not to clause numbers.

Example. The insurer's risk function runs an annual model audit, the same cycle it uses for credit scorecards. The assistant will change prompts every few weeks. That fails gate 4 on cadence alone. The fix is small: a quarterly review, a one-page register, and the Chief Data Officer as named signatory.

Gate 5: executive alignment

Committees advise. Someone has to decide.

The test. Write down one person's name and two more facts: they hold budget authority over the use case, and the use case is tied to one KPI they already report to the board (cost to serve, claims cycle time, revenue per account). If the name is a team or a forum, the gate fails. McKinsey is blunt on this: AI strategy determined by the IT department rarely delivers value; it should be owned by the most senior executives. Their survey found only 31% of GCC organisations have scaled AI, and where AI talent is centralised and deployed into cross-functional squads, roughly 70% of organisations moved pilots into production, against about 30% where talent is decentralised.

Also check the follow-through gap. In the same survey, only 37% of organisations outside the value-realizer group had both a scalable architecture with MLOps and strong data fundamentals. In other words, leadership enthusiasm is nearly universal and technical follow-through is not. Your named owner has to own both.

Example. The insurer first proposed an "AI transformation steering group" of 11 members from six departments, meeting monthly, with a roadmap but no budget line. That is a fail. The fix: name the Chief Data Officer as accountable owner, attach the assistant to the claims cost-per-case KPI already in the board pack, and let the steering group advise.

Worked example: the pre-flight on an AI claims assistant

A Dubai insurer, 20 claims handlers, 2,000 claims a day, wants an assistant that drafts responses for handler review. Target: 3-second p95 answers, claims data stays in the UAE. Here is the pre-flight, with numbers.

Step 1: data. 2.1 million claims since 2019. 61% queryable via the core REST API, 39% as unindexed scans. Queryable share 61%, against an 80% bar. Fail.

Step 2: integration. Reads: core claims API (OpenAPI document available), customer master (API, rate-limited to 100 requests/minute). Writes: claims workflow (API available). One write-back, all three systems documented. Pass.

Step 3: infrastructure. 3-second p95 and UAE residency. Abroad-hosted API is out on residency. Pilot on in-region GPU capacity, ceiling one 8xH100 node at $6.88 per GPU-hour on demand. Pass.

Step 4: governance. Audit cycle annual, no prompt register, no named signatory for model changes. Fail.

Step 5: alignment. Chief Data Officer named with budget authority, KPI is cost per claim. Pass.

Score it:

gates = {
    "data_accessibility":   {"passed": False, "note": "61% of claims queryable, bar is 80%"},
    "integration_surface":  {"passed": True,  "note": "3 systems, all with APIs, 1 write-back"},
    "infrastructure_fit":   {"passed": True,  "note": "UAE residency, in-region GPU lane chosen"},
    "governance_ownership": {"passed": False, "note": "annual review, no prompt register"},
    "executive_alignment":  {"passed": True,  "note": "CDO named, budget authority, cost per claim KPI"},
}

failed = [k for k, v in gates.items() if not v["passed"]]
print(f"Score: {len(gates) - len(failed)}/{len(gates)} gates passed")
print("Blockers:", ", ".join(failed) or "none")
if failed:
    print("Decision: do not commit build budget. Fix blockers first.")

Output: 3 of 5 gates passed, blockers are data accessibility and governance. Three passes means no build budget.

The decision. Six weeks on the two blockers, no model work. Weeks 1 to 4: OCR and index the scanned backlog (roughly 820,000 documents), instrumenting queryable share weekly against the 80% bar. Weeks 5 to 6: write the prompt register, set the quarterly review, name the signatory. Then the build phase starts on ground that holds: all data queryable, three APIs, one write-back, a cost ceiling of $6.88 per GPU-hour for the pilot, and a named owner waiting for a working system. Had the team started with a model pilot instead, it would have burned a quarter discovering that two thirds of its knowledge was invisible to the model, while running up GPU or token spend against a corpus it could not feed.

What to do next

Do this before your next AI steering meeting, and do it in a week.

1. Pick the use case the board is asking for and write the five gates out with the tests above.
2. Spend one afternoon per gate with the people who actually own the systems, not with the use case champion. Record pass or fail with the number behind it.
3. Total the fails. If you have two or more, write the remediation as its own funded plan with dates and owners, and take that to the board instead of a build proposal. A credible remediation plan is how you keep the AI budget alive.
4. If you pass four or five gates, scope one production use case with a single KPI and a hard cost ceiling on compute.

This checklist is the short form of the readiness work we do at Azrty: mapping how the business runs, checking what the data and systems can actually carry, and telling you plainly where AI will pay off and what to do first. If you want that assessment run against your own estate, our team in the UAE does the work end to end: see AI strategy and readiness. If your blocker is gate 3 and you need the platform designed before the project starts, that is what our AI infrastructure practice is for.

https://www.azrty.com/blog/ai-readiness-checklist-five-gates-to-pass-before-you-commit-build-budget

<a href="https://www.azrty.com/blog/ai-readiness-checklist-five-gates-to-pass-before-you-commit-build-budget">AI readiness checklist: five gates to pass before you commit build budget</a> (Azrty)