Acceptance criteria
State the added policy-decision latency and the conditions it was measured under, and document the behavior when a decision is slow or unavailable, including whether the control fails open or closed.
Why it matters
Added delay decides whether real-time enforcement is practical or only theoretical.
How to verify
Record the added decision time on pilot prompts and the behavior when a decision is slow.
OWASP adoption context
The listed assistant, platform and agent contexts can place controls inline with work, making added latency and failure behavior important deployment tests.
Framework mappings
Measured policy-decision latency and documented slow/unavailable behavior provide operational-design and disruption-planning inputs. The buyer must assess fail-open/fail-closed trade-offs; a latency number alone establishes neither adequate capacity nor acceptable risk, and 300 ms is not a framework threshold.
Latency results under stated test conditions provide performance-measurement evidence for evaluating AI operation against chosen objectives. The buyer must judge deployment relevance and acceptable failure behavior; documentation alone does not demonstrate performance under every operating condition.
Measured policy-decision delay and documented slow or unavailable behavior provide security-control performance and operational-design evidence. Define the measurement method, responsibility, cadence and evaluation, and adopt acceptable failure criteria. ISO sets no 300 ms target; a latency number does not establish capacity or acceptable fail-open risk.
Documented slow or unavailable behavior, including fail-open or fail-closed choices, informs resilience design. Test the behavior under adverse conditions and assess its acceptability; a latency measurement alone does not establish resource capacity.