An AI tool review starts with its data
Before discussing a control checklist, I would draw the data flow. What enters the tool? What can it retrieve? Where does it send information? Who sees the answer?
“It is an internal assistant” does not answer those questions. An internal interface may still use an external provider, retrieve documents with different access restrictions or connect to tools that can perform actions.
Start with the use case
A tool that suggests wording for a draft has a different use case from one that changes a record. I would establish the intended users, permitted inputs, output audience and decisions that need human review. The owner should be clear as well.
For a knowledge assistant, document access is worth examining closely. A user should not gain access to information merely because the assistant can retrieve it. I would request evidence of the permission checks and tests covering restricted documents.
Documents can contain instructions
OWASP describes indirect prompt injection through material such as retrieved documents. That makes the boundary between information and instructions important. I would propose tests with adversarial document content, then examine the tool’s output and any actions it attempts. A test plan is not evidence that the control passed.
Ask what happens when the system changes
A new model, document collection or integration can change the risk. I would want to understand the change process, evaluation evidence and who responds when someone reports a failure.
NIST’s AI Risk Management Framework is a useful reference for organising these discussions. A useful review still has to connect the framework to the actual use case, its evidence and the people who own the decisions.
The fictional work sample shows the questions I would start with. It does not report completed tests or claim that an example system meets a standard.