Measurable acceptance criteria for an AI application security pilot

Criteria that work, by dimension

Detection quality

• Coverage: the pilot tests against a named, public taxonomy (for example the OWASP Top 10 for LLM Applications, genai.owasp.org/llmrisk/llm01-prompt-injection) rather than an ad-hoc demo set.
• Precision: an agreed maximum share of findings that turn out to be false positives, judged by your own team's review.
• Recall evidence: known-bad scenarios, seeded by your team and unknown to the vendor, that the product must catch.

Actionability

• Every finding includes reproduction steps and names the affected component, so an engineer can act on it directly.
• Findings map to fixes your team can realistically ship within the pilot window.

Workflow fit

• The product runs inside your existing pipeline (CI, ticketing, chat) rather than adding a new dashboard to babysit.
• Time-to-triage per finding is measured during the pilot, not asserted.

Operational reliability

• Latency and failure behavior under your real load are measured and documented, including what happens when the control itself fails - fail-open or fail-closed, as an explicit policy choice.
• Data handling during the pilot is documented: what leaves your environment, where it is processed, how it is deleted.

Exit criteria: decide in advance what result expands the deployment, what result ends it, and who decides. An open-ended pilot is a subscription in disguise.