When your security reviewer has an AI

Something quietly shifted in the last twelve months. The person reading your security submission, the customer's procurement reviewer, the regulator, the app-store cyber team, is now reading it with help. They paste your questionnaire into a model. They ask it to flag inconsistencies. They ask it to summarize. They ask it whether your answer to question #14 actually maps to the standard you cited.

We've watched this happen in three different review contexts in the last quarter. None of the reviewers announced it. They didn't need to. The patterns in what gets pushed back are different now, and they're different in a specific direction.

What changes

Three things get worse for vague submissions, and they all get worse fast.

Cross-question consistency. When question #6 says you use TLS 1.3 and question #19 mentions "TLS 1.2 minimum," a human reviewer working through a 60-question submission might miss it. A model scanning the whole document in a single pass will not. Submissions that contradict themselves now get rejected on the first read.

Citation specificity. "We follow NIST guidelines" was always a weak answer. It is now actively dangerous, because the model can ask which NIST publication, which revision, and which controls. If you can't name them, the model writes the rejection for the reviewer. The reviewer ships it.

Evidence shape. Reviewers now ask the model to grade evidence. PDFs of policy documents grade worse than tables of controls. Marketing-style architecture diagrams grade worse than numbered system inventories. The right shape for evidence is now the shape an AI can score.

What to do about it

A few things have started working for our clients.

1. Write the questionnaire like documentation, not marketing. Short answers, specific standards by version, named controls. If a control is partially implemented, say so and name the gap.
2. Make consistency machine-checkable. Maintain one source of truth for the security claims, a single document, single table, single repo. Generate the questionnaire from it. If the source drifts, every submission inherits the drift.
3. Include the negative space. Name the things you don't do. Reviewers (and their AIs) now penalize submissions that claim universal coverage. "We do not support OAuth 2.0 authorization code without PKCE" is a more credible answer than "We follow OAuth best practices."
4. Ship the evidence in a form a model can read. Tables and bulleted controls beat prose every time. Numbered references beat citation-by-implication.

The meta point

The reviewer-with-an-AI is now the median reviewer. Designing your submission for that reader isn't pessimism; it's the new baseline. The good news is that the same rigor that makes submissions AI-readable also makes them better, sharper, more honest, more useful to a human reading them six months later.

We're seeing this pattern repeat in every review surface that matters: customer procurement, regulatory bodies, app-store cyber teams. None of them advertise it. All of them are doing it.

Build for it.