AI projects often start as support tools, copilots, search features, or workflow assistants. Before launch, the important questions are access, approval, and what happens when the system fails.
AI risk used to be treated mainly as a model problem. That is too narrow now. Once the system can retrieve internal information, call tools, or trigger workflow steps, the model is only one part of the risk.
Start by finding the point where a suggestion can become an action.
Start with what the system can access.
Start with what the assistant can see: internal search results, uploaded files, connector content, cached prompts, chat history, and previous decisions.
A low-risk demo can become riskier once it can access policy documents, customer records, pricing notes, contract history, or engineering runbooks.
A serious review treats the feature as a trust boundary. What can it retrieve, who authorises that access, and what filtering applies? If any of that is unclear, the scope needs more work.
Retrieval changes the risk profile.
Once retrieval is involved, the review looks at document boundaries, record access, stale indexes, and over-broad embeddings. Summaries can leak beyond what the user sees. Retrieval often relies on loose permissions.
AI can make weak access control look safer than it really is. A person would rarely search five systems for a sensitive answer. An assistant can do it in seconds.
Access and exposure differ. Even when a user can see several source documents, the assistant can remove friction and context. Review what it can infer or repeat.
Tool access raises the stakes.
Once a system can call tools, it is doing business work. It can create tickets, move data, update records, draft responses, or change state.
The moment an AI system can affect state, the review has to examine the workflow around the action, not the words that triggered it.
Check available actions, inherited authority, approver evidence, and what happens when the model is wrong. Ask whether it can chain actions in unintended ways.
At scale, blast radius becomes the main concern. That pulls the conversation away from AI novelty and back toward operational consequences.
Meaningful approval
Teams often say “a human is in the loop,” but that phrase can hide a weak control. If the reviewer has limited context or cannot challenge it, the control exists only on paper.
The reviewer needs the retrieved material and a way to reject or interrupt the action. Otherwise it becomes an unreviewed queue.
A reviewer who sees source evidence, intended action, destination, and business consequence has enough context. A summary and two buttons usually do not.
Memory, prompts, and connectors.
Not every risk comes from a dramatic exploit. Sometimes the system prompt is too broad, memory resurfaces stale information, or a connector keeps exposing material after it should stop.
AI review is new for teams used to cleaner boundaries. It depends on configuration, prompts, retrieval, tools, and workflow design. Look at the whole system, not one layer.
Log enough to reconstruct the decision.
Teams need an audit trail for prompts, retrieved content, tool calls, approvals, and state changes. If nobody can reconstruct what happened, incident response becomes much harder.
Logging preserves enough evidence to reconstruct what happened and answer questions about the suggestion, source documents, the approval, and whether the behaviour was isolated or systemic.
What we check
The exact test plan depends on the workflow, but a useful review usually goes beyond prompt abuse and includes technical and operating checks:
- Prompt abuse and instruction-conflict handling
- Retrieval boundaries, permissions, and data access checks
- Tool permissions and action side effects
- Approval checkpoints and operator oversight
- Logging and investigation readiness
- Rollout constraints for higher-risk workflows
AI review goes beyond a narrow feature check. It asks whether the system stays trustworthy under pressure.
Why organisations ask for this review
AI reviews often start with engineering curiosity, launch readiness, procurement questions, or a feature that could affect real decisions.
The same questions apply: access, approval, evidence, and how the business explains the outcome.
If the AI can access business data, call tools, or influence outcomes, an AI security review is the right starting point. If the AI is embedded in a customer-facing product, pair it with an apps review.
Planning an AI rollout?
If your assistant can access internal documents, call tools, or influence approvals, tell us what it can access, what it can do, and what decision the review needs to support.