Getting Legal and Security to Approve an AI Project

A security review feels like an obstacle because it arrives as a hundred-question spreadsheet with no visible structure. Underneath, it is trying to establish three things, and if you bring the evidence for those three the spreadsheet takes an afternoon instead of a quarter.

What the review is establishing

Every question on the form is a proxy for one of three claims. Knowing which one a question serves tells you what evidence answers it, and tells you when a question does not apply to your case.

• 1. What data leaves, to whom, and under what terms. The reviewer is building a mental picture of a boundary being crossed. Every question about retention, training, residency and sub-processors is refining that picture.
• 2. What happens when it misbehaves. Not whether it will — reviewers are past that — but whether a bad output can reach somebody or something that matters, and what stands between. This is where prompt injection, tool permissions and human review live.
• 3. Whether you can see it and stop it. Logging, attribution, an off switch, and evidence that someone would notice. A reviewer will accept a surprising amount of risk if the answer to “how would we find out” is convincing.

Almost every review that drags is a review where the applicant answered questions one at a time without ever making one of those three claims explicitly. Make them explicitly, at the top, and the questions become a checklist against a position rather than an interrogation.

The one page they actually want

Before the questionnaire, produce a data-flow page. It is half an hour’s work and it removes most of the back-and-forth, because most of the back-and-forth is the reviewer trying to reconstruct this from your answers.

DATA FLOW — one page

WHAT      the exact fields sent. Not "ticket data" — the field names,
          and whether free text is included (it is, and it contains
          whatever users typed).

FROM      the system of record, and the lawful basis / customer
          contract under which we already hold it.

TO        the endpoint, the legal entity behind it, and the region
          the request is served in.

VIA       every hop in between: our gateway, a retrieval service, a
          logging pipeline, an observability vendor. Each hop is a
          place the data exists.

KEPT      retention at each hop, including our own logs, and the
          default retention at the provider — which is a separate
          number from whether they train on it.

SEEN BY   who can read it: our engineers, the vendor's staff under
          what circumstances, any sub-processor.

OFF       how this is stopped, by whom, in how long.

The VIA row is the one that surprises people. An observability tool that captures prompts and responses is a processor holding customer data, and it is routinely omitted from the diagram because it was adopted by engineers as a debugging tool rather than procured as a data destination. Find it before the reviewer does.

The question list

Grouped by the claim each group supports. The right-hand thought for each is what artefact settles this — a review moves at the speed of artefacts, not answers.

Data terms

• Are inputs or outputs used to train or improve the provider’s models, by default and under our plan? This is a question about the published terms and it is answered by reading the clause rather than by asking sales.
• What is the retention default, why does it exist, and can it be set to zero? “We do not train on your data” and “we do not store your data” are different statements, and zero retention does not mean the same thing at every vendor.
• Where is the request processed, and is that contractual or best-effort? Artefact: the residency commitment in writing, not a region setting in a console.
• Who are the sub-processors, and how are we told when the list changes? Artefact: the published list plus the notice period, which belongs in the data processing agreement.
• What is the deletion path, and how would we evidence a deletion to a customer who asks?

Behaviour and blast radius

• Does the model see content from outside our trust boundary — web pages, inbound email, uploaded files? If yes, this is an indirect prompt injection surface and the reviewer is right to focus on it.
• What can the system do besides produce text? Every tool it can call is a permission, and the review should treat it as one.
• Does an output reach a person, a customer or a system without a human in between? If so, what is the failure budget and who watches it?
• Can the system be made to reveal data from another user or another tenant? Artefact: a test in CI, not an assurance.

Visibility and control

• What is logged, for how long, and does it contain personal data? Artefact: the field list, and the redaction applied at capture.
• Given a complaint, can you produce the exact request, response, model version and cost? Artefact: a retention and audit design somebody has actually queried.
• What is the kill switch, who holds it, and how quickly does it take effect?
• How do you learn the provider changed the model underneath you?

What has to come from the vendor in writing

A distinction worth being strict about: some of the above you can assert about your own system, and some of it is only a fact if the vendor has written it down. Assurances given on a call are not evidence and a reviewer is correct to say so.

Ask for the terms themselves rather than a summary — the data processing agreement, the sub-processor list, the retention and training clauses for the tier you are actually on, the security documentation or report, and the incident notification commitment with its clock. Note that many of these differ by plan: a term that applies to an enterprise agreement may not apply to the self-serve tier the pilot ran on, and reviewing the wrong one is a common and expensive waste of a fortnight. The clauses that most often bite later are the ones about unilateral change, deprecation notice and liability caps, which is the subject of the terms that get you at scale.

One asymmetry to state plainly to your reviewer, because it is true and it builds credibility: a security report tells you a company has controls and a process, not that your particular data flow is safe. The report is necessary and it is not sufficient, and saying so yourself is worth more than being told.

Making the review short

• Scope narrowly and say so. “This request covers one queue, no special-category data, human review before anything is sent” is a small review. “An AI platform” is a large one, and the large one takes months because the reviewer must assume the worst case of a thing with no edges.
• Bring your own risk list. Hand over the two or three residual risks you have not fully mitigated, with what you propose to do about each. A reviewer’s job is to find those; arriving with them already found changes the relationship, and the list is the first rows of your risk register.
• Reuse. The second project through the same vendor, with the same data classification and the same controls, should be a variation on an approved pattern rather than a new review — which is what a pre-approved path is for.
• Book the time. Security review is queue time, not work time, and queue time is the dominant term in an enterprise AI timeline. Start it the week the pilot starts, not the week the pilot ends.