Procurement & security questions before you sign

The worst time to discover that an AI platform can't export an audit trail is the day of your first security review from a major customer: after you've signed, deployed, and wired the systems together. A good evaluation moves that discovery to before the signature, while you still have a choice. This guide is written for the people actually in the evaluation room: the procurement team comparing proposals, and the security team signing off on the risk. It isn't a checklist of boxes to tick quickly: it's five areas, each with what a good answer looks like, and what the weak answer that's delivered with confidence looks like too.

Before we begin, one rule governs everything below: don't evaluate features, evaluate commitments. Any platform can show a beautiful screen in a rehearsed demo. The question isn't "can you?" but "will you commit to that in writing, and can I verify it myself?" The gap between those two answers is the gap between a platform you can defend to your committee and one you hope nobody asks about.

Area one: data residency and deployment options

This goes first because it governs the rest. The precise question: where is our data processed and where is it stored, literally, and what choices do we have?

• The good answer names the location explicitly and offers multiple deployment options: hosting within a defined geography, or deployment into your own private cloud (VPC): and explains where data goes under each, including data in transit to inference models. And it says it plainly: in the Saudi context, in-Kingdom residency is an available, supported option.
• The weak answer says "cloud" and moves on quickly, or says "your data is safe" without answering "where." Watch too for the answer that names the storage location and quietly omits the processing location: data can be stored next door and processed on another continent.

Why this matters: questions like "where does the data reside, for what purpose is it processed?" are ones you must hold documented answers to under a framework like the Personal Data Protection Law (PDPL). A platform that leaves the processing location vague puts the burden of answering on your shoulders, not the vendor's.

Area two: third-party data-sharing boundaries

A platform rarely operates alone; behind it sit models, infrastructure providers, and sometimes analytics tools. The precise question: who else touches our data, for what purpose, and is it used to train models?

• The good answer hands you a list of sub-processors and each one's role, commits explicitly that your data is not used to train general models, and details what stays inside your boundary and what leaves it. And crucially: it puts this in the contract, not in a reassurance email.
• The weak answer says "we respect your privacy" and points you to a generic twenty-page policy that doesn't answer your question. The biggest red flag is vagueness about training. If a platform can't say plainly "we do not use your data to train our models," assume it does.

Area three: permissions and human approvals

This is where governed AI separates itself from everything else. The precise question: at what level are permissions set, and where does a human step in before execution?

• The good answer talks about permissions at the level of the action and the data source: what each agent may read, what it may execute, and where it must stop and ask: not at the level of "a user account with full access." And it shows a documented human approval point for high-impact decisions: payments, customer data, contractual commitments.
• The weak answer boasts about full automation and "zero human intervention" as if it were a feature. On high-impact decisions, the absence of an approval point isn't speed: it's unmanaged risk. Watch too for the answer that sets permissions at the tool level rather than the action level: it grants the agent everything or nothing.

A practical test to pose in the room: "show us how to stop an agent from reading one specific table while keeping it able to read another table in the same system." A platform that stumbles on this request sets permissions at a coarser grain than your organization needs.

Area four: exportable audit logs

This is the area discovered late most often, and its price is the steepest. The precise question: can I export a complete record of every automated decision and action: who, what, when, under which permission, with what result: in a format I can hand to an auditor without manual preparation?

• The good answer shows you an actual log in front of you, exports it in an open format (JSON/CSV) or via an API, and covers automated actions in full: not just sign-in events. A good record is an automatic by-product of operating; it generates itself, unprompted.
• The weak answer shows a beautiful "analytics dashboard" that can't be exported, or settles for a login log that tells you nothing about what happened after sign-in. And if the answer is "we can prepare a report for you on request," read it this way: there is no ready record, and you'll wait days every time an auditor asks.

The value here is twofold: an exportable record turns audit readiness from an exhausting annual campaign into a standing condition, and it gives you evidence you can present with confidence at every later review instead of reopening the debate from zero each time.

Area five: the vendor's written commitments

The previous four areas are tested in the demo; this one is tested in the contract. The precise question: of everything said in the demo room, which is written and contractually binding, and which is a verbal promise?

• The good answer puts the material undertakings into binding documents: a data processing agreement, a service level agreement (SLA), breach notification within a defined window, and your right to export and recover your data when the engagement ends. A confident vendor welcomes these clauses because they reflect what it already does.
• The weak answer dodges the writing: "that's a detail we'll discuss later," or "trust us, our customers are happy." Be especially wary of absolute compliance claims: "certified" or "fully compliant." An honest vendor doesn't sell you a certification it doesn't hold; it says precisely that its controls are designed to support your journey toward compliance, and leaves the assessment decision to your teams and your regulators.

How to read the answers together

Don't look for the platform that answers "yes" to everything: that signals a skilled salesperson, not a mature product. Look for a different pattern: a platform that answers precisely, says "no" when no is the honest answer, shows rather than promises, and is glad to write down what it said. Professional confidence in this room looks like this: quiet detail, not boundless enthusiasm.

The first step

Before you send these questions to any vendor, order them by your own organization's priorities: which of the five areas is most critical for your data and your sector? Give it more weight in scoring, and make the rest minimum bars that must be cleared. Then turn the areas into written questions sent to every vendor in identical wording, so you compare answers against the same standard: not impressions from different demos. And bring security and compliance in from the first message, not after the finalist is chosen.

We've prepared the short version of this guide as an interactive checklist you can carry into the evaluation room and tick off during the demo. And if your sector sits within the Saudi context, start with an honest assessment of where you stand using the readiness assessment tool: because you're evaluating the vendor, yes, but you're also evaluating your own organization's readiness to answer.