Start the Conversation Before There's Anything to Review

The instinct is to build first and bring security in once there's a working system to show. This is backward. Security and legal review is frequently the true critical path of an engagement — the thing that determines the go-live date, regardless of how fast the engineering moves. Loop in the customer's security contact during discovery, ask what their standard AI vendor questionnaire covers, and start gathering answers in parallel with the build. Weeks saved here routinely exceed everything else in the engagement combined.

The Questions Every Security Review Asks

  • Where does our data go? — which systems and providers touch the customer's data, in what form, and whether it crosses any geographic or regulatory boundary the customer cares about.
  • Is our data used to train the model? — this is usually a contractual question about the model provider's terms for the specific tier and agreement the customer is under, not a technical one. Know the current answer for the provider and tier in use, and don't guess.
  • How long is data retained, and by whom? — at the model provider, at any intermediate logging or observability layer, and in the customer's own system. Each of these can have a different retention policy; conflating them in an answer erodes trust fast.
  • Who can access the data, and how is that enforced? — this is where the access-boundary work from Article 5 becomes directly relevant; be ready to describe, concretely, how retrieval respects the customer's existing permission model.
  • What happens when the system is wrong? — the human-in-the-loop model from the scope document (Article 3), stated plainly: does a person review before action is taken, and what's the blast radius of an unreviewed error.
Know what you own and what you escalate

An FDE should be able to answer technical and architectural questions with authority — how retrieval works, what's logged, where compute runs. Contractual questions — data training terms, liability, indemnification — belong to the account team and legal, and the fastest way to lose a security reviewer's confidence is to guess at one of these rather than saying "let me get you the exact contractual language" and following up same-day.

Data Minimization as a Design Habit

The easiest security question to answer well is one you've designed around from the start: don't send data to a model or a logging system that the task doesn't need. If a task only requires a document's summary, don't pipe the full document through every layer of the pipeline "just in case." If personally identifiable information isn't needed for a given step, redact or exclude it before that step, not after. This isn't just good practice for the review — it measurably shrinks the actual risk surface, which is the point of the review in the first place.

Audit Trails From Day One

Enterprise AI systems need a complete, queryable record of what happened: every input received, every output produced, the user or process that triggered the request, a timestamp, and — for retrieval-augmented systems — exactly which source documents were retrieved and used. Build this logging into the system from the first production deployment, not as a reaction to an incident. Retrofitting an audit trail after the fact is far more expensive than including it from the start, and its absence is one of the fastest ways to fail a review outright.

Common Objections and How to Address Them Directly

  • "What if the model hallucinates something harmful?" — describe the specific mitigations in place: retrieval grounding, human review points, and the evaluation data from Article 7 showing measured failure rates, not a promise that it can't happen.
  • "How do we know it won't leak data across customers?" — walk through the actual tenant isolation architecture concretely; vague reassurance here reads as evasion.
  • "Can we turn it off if something goes wrong?" — have a real, tested kill switch and say so plainly. If one doesn't exist yet, build it before this conversation, not after someone asks.
  • "Who's accountable if it makes a bad decision?" — this maps directly to the human-in-the-loop model; a system where a human approves every consequential action has a very different accountability story than one operating autonomously, and the review should reflect which one this actually is.

Frequently Asked Questions

When should security review start in an engagement?
As early as possible, ideally alongside discovery, not after the prototype is built. Security and legal review timelines are frequently the true critical path of an engagement, and starting the conversation only once there's a working demo routinely adds weeks that could have overlapped with build time.

Is an AI FDE responsible for the model provider's data retention policy?
Responsible for knowing and accurately representing it, yes — not for negotiating it. An FDE should be able to state clearly, in writing, whether customer data is used for model training, how long it's retained, and under what contractual terms, and should escalate to the account team when a customer's requirements don't match the standard terms.

What belongs in an audit trail for an enterprise AI system?
At minimum: every input the model received, every output it produced, which user or process triggered the request, the timestamp, and — for retrieval-augmented systems — which source documents were retrieved. This should be logged from the first production deployment, not retrofitted after an incident.