54east / Insights / Perspectives
Perspectives · Whitepaper
Build, buy, or wait
A decision framework for UAE government entities: build it, buy it, or wait — with a reason, and a date to revisit.
The catalogue is not a decision
A common deliverable is a use-case catalogue: ranked by an impact/effort matrix, a long list of opportunities, and no mechanism for choosing between them. The institution is left with slides, no working system, and a refreshed catalogue the next time a consultant is hired.
The failure is not a lack of ideas. A workshop will generate a plausible list. The failure is the absence of a decision that converts each candidate into one of three answers: build it, buy it, or explicitly wait.
This paper sets out that mechanism.
Why the catalogue model fails
A use-case catalogue is a diagnostic tool, not a decision tool. It answers “where could AI help,” which is nearly always “everywhere, a little.” It does not answer “what should we actually resource,” which is the question a director general or a permanent secretary needs answered.
Three structural problems recur.
No forcing function. Nothing in a ranked list compels a choice. Every use case can plausibly be “high impact.” Effort estimates produced before technical discovery are guesses dressed as analysis. The ranking feels rigorous and decides nothing.
No ownership boundary. A catalogue entry such as “AI-powered citizen services chatbot” does not specify whether the entity is proposing to build a system, license one, or wait for the market to mature. Each path is a different procurement, a different budget line, and a different risk profile. Conflating them is why initiatives stall in the gap between IT, procurement, and the sponsoring department.
No sequencing logic. Use cases are typically scored in isolation. In practice, a correspondence-routing system and a program-command dashboard for the same entity share infrastructure, governance patterns, and often the same underlying data. Evaluated separately, both look marginal. Evaluated as a sequence, the second is cheaper because the first already built the sovereignty fabric underneath it.
The build / buy / wait test
The useful unit of analysis is not “the use case.” It is “the decision.” For any candidate AI initiative, apply three tests in order.
Test one: commodity capability, or institutional?
If the capability is genuinely generic — document summarisation, meeting transcription, code assistance — a buy decision is usually correct. The market has already solved this, competitively and cheaply. Building a bespoke version wastes engineering time that should go to what differentiates the institution.
If the capability depends on the entity’s specific data, workflow, or regulatory position — correspondence routing that has to match a ministry’s actual approval chain, a program-command view built around a specific event’s protocol and security structure, an agent that acts inside a workflow no vendor has seen — buy options do not really exist. What is sold as a product is a template that will need to be substantially rebuilt. At that point the institution has commissioned a bespoke build from a vendor with less accountability than a direct engagement.
Test two: do hosting, classification, or sector rules make buy unavailable?
Some capabilities are commodity in function and still blocked as a buy. A chatbot over public information is a buy. A chatbot over classified files, or over data the institution cannot lawfully or contractually send to a vendor’s standard stack, is not — however mature the product.
The statute depends on who holds the data. Do not collapse this into “PDPL.” Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data does not apply to government data, governmental entities that control or process personal data, or personal data held by security and judicial authorities (Art. 2(2)(a)–(c)).1 PDPL is a personal-data transfer test for in-scope private-sector processing (Arts. 22–23). It is not a residency statute, and it is not the ministry’s statute.2
Apply the bar that actually binds:
Ministries and public institutions. Classified and citizen data held by a ministry sit outside PDPL. The live tests are data classification, the UAE Information Assurance Standard, and the National Cloud Security Policy — hosting, controls, and vendor access, not a privacy-transfer form.3 If the vendor cannot operate to that bar, buy is closed. There is no safe middle option.
Private-sector personal data (mainland). Where PDPL applies, Arts. 22–23 restrict outbound transfers: to a jurisdiction with an adequate level of protection as approved by the Data Office, or under listed derogations (contract, express consent, contract performance, judicial cooperation, public interest). Executive regulations, an adequacy list, and approved standard contractual clauses had not been issued as of mid-2026; the Art. 29 regularisation clock had not started.4 Overseas prompt or training routing of in-scope personal data is a transfer. It is not a requirement that the data never leave the UAE. Do not treat “meets PDPL” as in-country residency.
Banks. For CBUAE-licensed banks, Circular C 14/2021 requires Board or Board-committee approval, and prior CBUAE non-objection, for material outsourcing. Not every cloud or AI vendor relationship is material outsourcing.5 The February 2026 Guidance Note on Consumer Protection and Responsible Adoption and Use of AI/ML is guidance, not the 2021 circular: Board and senior management should be accountable for AI/ML systems and outcomes; licensed institutions should not employ AI models they have no control over.6
Health records. Health personal data is outside PDPL (Art. 2(2)(e)). Federal Law No. 2 of 2019 on ICT in health fields imposes a default in-country storage and processing rule, with limited export under Ministerial Resolution 51/2021.7
Exit is contract. Extraction rights, deletion, subprocessor disclosure, and a clean unwind are negotiated terms. They are not a PDPL condition. Put them in the agreement, or do not buy.
Where Test Two fails a buy candidate, the entity is left with build or wait. Proceeding with a vendor that cannot clear the applicable bar is a compliance decision made by default. Diligence questions — legal process against a foreign parent, key custody, support access, failover out of country — sit in the companion paper, Why a Cloud Region Isn’t a Jurisdiction.
Test three: is the readiness actually there?
Before committing to build, run a scored readiness check across the four foundations every major model already uses — data, infrastructure, workforce, governance — and write down what would have to be true first.8 If the honest answer is “the underlying data isn’t clean enough to train on,” or “there is no one internally who could operate this once delivered,” the correct decision is wait: name the gaps, and set a date to reassess.
Wait is not inaction. It is the explicit, resourced work of closing a named gap. Building on top of that gap is how deployments fail. That last sentence is practitioner judgment, not a measured cycle time.
What wait actually looks like
Wait is the most under-used of the three decisions because it is the hardest to defend in a room that wants visible progress. Done properly, it is not a shrug. It is a dated, written list of preconditions:
- Which data sets need to be structured, and by when
- Which roles need to exist internally before operation is feasible, and whether they are being hired
- Which governance approval — a data-sharing agreement, a ministerial sign-off, a budget cycle — is the actual blocker, and its expected resolution date
A wait decision with these specifics is a legitimate deliverable. A wait decision that is really “we didn’t get to it” is not, and tends to become permanent without ever being decided as one.
Sequencing: the catalogue’s missing dimension
Once individual initiatives have been sorted into build, buy, and wait, sequence the build list — not by isolated impact score, but by shared dependency. A national-programme command dashboard and an Arabic correspondence system, scored independently, are two mid-sized builds. Evaluated together, they share a governance model, an audit-trail architecture, and often the same underlying entity data. The second is cheaper and faster once the first exists.
That is the practical argument for one team across advisory and delivery, rather than strategy consulting handed to a separate implementer. Sequencing requires knowing, in engineering terms, what the first build leaves behind. A strategy team that hands off rarely has that visibility. The sequencing benefit is lost.
Why this is a UAE government paper
Two features of the UAE government environment make the framework a budget instrument, not generic best practice.
Budget cycles reward a written decision. A build/buy/wait output with named preconditions and dates is something a finance or planning committee can act on: approve the build, allocate the buy, or defer with a reason. A use-case catalogue is not a budget input. It is a workshop artifact.
The buy path is a hosting and classification question, not a PDPL one. For a ministry, citizen data and classified files are government data. The bar is IA, national cloud policy, and the contract — not Federal PDPL. Entities that skip Test Two do not “unwind a vendor under PDPL.” They discover, after go-live, that the vendor cannot meet the hosting bar they were always under. That is a procurement failure, not a privacy-statute surprise.
Banks and private controllers have different statutes, set out in Test Two. Do not borrow them for a ministry briefing.
A worked example (hypothetical)
Consider a hypothetical UAE government entity weighing three initiatives from a single strategy workshop: an internal document-summarisation tool; a correspondence-routing system matching its ministerial approval chain; and a public-facing citizen chatbot answering questions about service eligibility.
Applying the three tests produces three different answers, not one shared recommendation.
The summarisation tool is a commodity capability with no entity-specific dependency and no unusual data sensitivity. Test one says buy. A market-leading enterprise tool, configured for in-country processing as a procurement condition, closes the question. PDPL is not the reason.
The correspondence-routing system depends entirely on the entity’s approval chain and document conventions. Test one rules out buy. Test three determines whether the document archive is structured enough to build from now, or needs cleanup first.
The citizen chatbot sits in between: broadly commodity in function, but it touches citizen data held by a government entity. Test two applies. The diligence is classification, IA / national-cloud hosting, vendor access, and contractual exit — not PDPL Arts. 22–23. If this were instead a private-sector chatbot over in-scope personal data, the PDPL transfer test would be the live statute. It is not, here.
Run as a catalogue, these three look like three similar “high impact” lines. Run through the framework, they resolve into a buy that can proceed, a build gated on a named data-readiness gap, and a buy gated on vendor diligence against the hosting bar. That is a usable output for whoever has to resource the work.
Governance follow-through
A build/buy/wait decision is not the end of the process. It is the point where ownership is assigned. Catalogue-driven strategy loses momentum here, even after a good decision.
A build needs a named technical owner and a named accountable sponsor before work starts, not after.
A buy needs the diligence — hosting, keys, support access, exit terms, subprocessor chain — resolved as part of procurement, not left for legal to discover in contract review. For a bank, material outsourcing also needs the Board/committee pack and CBUAE non-objection before the contract is a fact.
A wait needs its stated preconditions tracked against an actual date, with someone accountable for revisiting it, or it becomes a permanent no without ever being decided as one.
Own the decision, then own the system
Winning institutions own the system. Ownership starts with a written decision: build this, buy that, wait on the third for a stated reason — each with an owner and a date. A long catalogue looks thorough. A short list of named decisions is the one that gets acted on.
54east runs decision audits for UAE government entities. The engagement ends in a written build/buy/wait decision, not a slide deck. If the team has a use-case list and no mechanism for choosing, start with a briefing.
Notes
Notes
- Federal Decree-Law No. 45 of 2021 concerning the Protection of Personal Data (PDPL), in force 2 January 2022 (Art. 33). Art. 2(2)(a)–(c) carves out government data, governmental entities that control or process personal data, and personal data held by security and judicial authorities. Official portal: https://uaelegislation.gov.ae/en/legislations/1972. US International Trade Administration summary of the carve-outs: https://www.trade.gov/market-intelligence/united-arab-emirates-allows-cross-border-data-flows-personal-data (22 January 2024).
- PDPL Arts. 22–23 (cross-border transfers). Adequacy as approved by the Data Office, or listed derogations. The law regulates how in-scope personal data may leave; it does not require it to stay. Same official text: https://uaelegislation.gov.ae/en/legislations/1972.
- UAE Information Assurance Standard, Cyber Security Council: https://csc.gov.ae/en/w/uae-information-assurance-standard. National Cloud Security Policy (UAE legislation portal): https://www.uaelegislation.gov.ae/en/policy/details/lsy-s-lotny-llamn-lsh-by.
- PDPL Arts. 28–29: executive regulations were to be issued within six months of issuance; controllers regularise within six months of those regulations. Legal trackers current to 2026 (including Chambers, Data Protection & Privacy 2026, UAE) report the executive regulations, a federal adequacy list, and approved contractual clauses as unpublished. Do not describe the transfer regime as fully operational “teeth.”
- CBUAE, Outsourcing Regulation for Banks, Circular C 14/2021, in force 15 July 2021. Board-approved materiality policy; material outsourcing approved by the Board or a Board committee (Art. 2.5.1); prior Central Bank non-objection (Art. 8.1). https://rulebook.centralbank.ae/en/rulebook/outsourcing-regulation-banks. Non-objection pack, including evidence of Board/committee approval: https://rulebook.centralbank.ae/en/rulebook/8-non-objection-central-bank.
- CBUAE, Guidance Note on Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning, February 2026 (guidance; board-level AI accountability). Press release, 23 February 2026: https://www.centralbank.ae/en/news-and-publications/news-and-insights/press-release/cbuae-issues-guidance-note-to-protect-consumers-and-ensure-responsible-use-of-artificial-intelligence-in-the-financial-sector/. Rulebook, governance and accountability: https://rulebook.centralbank.ae/en/rulebook/2-governance-and-accountability. Rulebook, outsourcing and third-party risk: https://rulebook.centralbank.ae/en/rulebook/9-outsourcing-and-third-party-risk.
- Federal Law No. 2 of 2019 concerning the Use of Information and Communication Technology in Health Fields: https://uaelegislation.gov.ae/en/legislations/1209. US ITA note on the in-country default and limited export: https://www.trade.gov/market-intelligence/united-arab-emirates-regulations-limit-cross-border-health-data-flows.
- The four axes — data, infrastructure, workforce/talent, governance — are the standard foundations in the major commercial readiness models (Gartner AI Maturity; Cisco AI Readiness Index; Accenture AIMM). 54east does not claim the axes. The useful output is a scored, evidenced gap-list with a date, not a new taxonomy. Gartner: https://www.gartner.com/en/chief-information-officer/research/ai-maturity-model-toolkit.
Related whitepapers
Start with one decision.
If this paper describes the problem in front of you, the next step is a briefing with the architects.