Most AI vendor decks answer questions you did not ask: model size, partner logos, and a pilot timeline that assumes clean APIs. A GCC CIO needs a different interrogation — one that exposes residency, Arabic evidence, agent identity, human gates, and exit rights before the contract hardens.
This is a practical checklist. Not a cost model. Not a post-mortem on failed programmes. Use it in RFPs, security reviews, and steering meetings when someone says “the model is best-in-class.”
1. Where does work actually run?
Ask for a workload map, not a region marketing name.
- Where is inference for prompts that include customer or employee data?
- Where are embeddings, vector indexes, and backup snapshots stored?
- Where do logs, traces, and tool-call records live — including support copies?
- Which sub-processors touch content, and under which transfer mechanism?
If the answer is a vague “we have a Middle East presence,” demand the data-flow diagram for your workload classes. Presence is not permission.
2. What is the evidence for Arabic — on our kind of work?
Do not accept “Arabic supported” as a line item.
- Which registers were tested — MSA for records, Gulf dialect for support, mixed Arabic–English?
- Can they run evaluation on your redacted tickets and policies, under NDA?
- Do they score retrieval honesty (citation to the right document) or only fluent chat?
- What fails today, in writing — not only what the demo passes?
A vendor that cannot describe failure modes is selling theatre.
3. How does retrieval treat our documents as ours?
- Can indexes be permission-aware by role and unit, not only by workspace password?
- How are superseded policies retired from retrieval?
- Who can export chunk-level provenance for audit?
- Is our corpus used for vendor training by default, opt-in, or contractually forbidden?
If provenance cannot be exported, you do not own the knowledge path — you rent a black box.
4. What can the agent change — and as whom?
For anything called an agent or tool-using assistant:
- Which systems can it write to, and which actions are blocked by default?
- Does it use shared god-credentials or least-privilege, per-workflow identities?
- How are secrets stored, rotated, and revoked when a workflow is retired?
- Can you force step-up approval before irreversible acts (pay, provision, message, file)?
Shared service accounts are not an implementation detail. They are a governance decision the CIO owns.
5. Where is the human gate — really?
- Which actions require a human, and is that enforced in product or only in a slide?
- What does the approver see — fields to change, evidence, blast radius, accountable role?
- Can gates reuse existing dual-control and amount thresholds, or do they invent a parallel AI policy?
- How are overrides logged and fed back into evaluation?
“Humans remain in control” without an approval artefact is a slogan.
6. How do we exit without rebuilding the business process?
- Can prompts, tools, eval packs, and corpus indexes move to another runtime?
- What is the timeline and format for data return and deletion?
- Which parts of the stack are open standards vs proprietary glue?
- If the vendor’s model path becomes non-viable for regulatory fit, what is the documented re-point plan?
Lock-in is not only commercial. It is operational paralysis when policy changes.
7. What are the operating promises for agents — not only uptime?
Classic SaaS uptime is necessary and insufficient.
- What is the response when the agent takes a wrong write?
- Who is on call for tool failures across integrated systems of record?
- How are model version changes announced, tested, and rolled back?
- What audit pack do you receive after an incident — identities, prompts, tools, approvals?
If the SLA only mentions API availability, it does not cover agentic risk.
8. Who is accountable in the room?
- Named security, data protection, and delivery contacts with escalation paths
- Clear split between vendor responsibility and your process owners
- Evidence of delivery in regulated or public-sector contexts similar to yours — qualitative case structure, not invented ROI figures
- Willingness to put residency, training use, and exit into contract schedules, not only security questionnaires
Ambiguity here becomes finger-pointing later.
How to use the list without freezing procurement
You will not get perfect answers on day one. Score vendors on honesty and architecture, not on who shouts “sovereign” loudest:
- Green: written data flows, testable Arabic packs, least-privilege tools, portable corpus, real gates
- Amber: partial answers with a dated plan and contractual hooks
- Red: demo-only evidence, shared credentials, training-use fog, no exit story
Disqualify red on critical workloads even if the model benchmark looks impressive.
Questions to stop prioritising
- “How many parameters?”
- “Can we go live in two weeks?” without corpus and gate design
- “Who else in the region bought a logo slide?”
- Pure price comparison before identity and residency are fixed
Those questions optimise for theatre speed. CIOs are paid for operable risk.
A one-page RFP insert
Copy this block into vendor requirements:
- Data-flow diagram by workload class (inference, embeddings, logs, sub-processors)
- Arabic evaluation protocol including register coverage and retrieval scoring
- Permissioned retrieval and provenance export
- Tool allow-list, identity model, and human-gate specification
- Training-use prohibition or explicit opt-in for enterprise content
- Exit: export formats, deletion certificate, re-point runbook
- Incident and model-change operating procedures
If a vendor cannot engage that list, they are not ready for your production path.
The quiet conclusion
Procurement is where architecture becomes binding. For GCC enterprises, the winning vendor is not the one with the flashiest model card. It is the one that can answer — in writing — where work runs, how Arabic is proven, how documents stay yours, who the agent is, where humans stop the write, and how you leave.
Ask those questions early. Put the answers in the contract. Everything else is decoration.