Updated October 29, 2026. This article now describes privacy and policy review signals. It does not treat an evaluation score or a trace as proof of legal compliance.
An agent can answer a question correctly while collecting unnecessary information or sending data to the wrong destination. Reviewing only the final answer can miss that behavior. The useful engineering response is to make relevant data handling observable and connect flagged behavior to a defined requirement.
Quick answer: Identify the data required for the task, record appropriate evidence of collection and tool use, and flag deviations for qualified review. A scorer can help find possible issues. It cannot establish that an application complies with every applicable law, contract or organizational policy.
Define the requirement before flagging a failure
Consider an illustrative order-status workflow. The application’s approved design requires an authenticated session and an order identifier. If the agent additionally requests a date of birth, a reviewer should be able to inspect why that information was requested and whether the workflow actually needed it.
The European Data Protection Board’s guidance describes data minimisation as collecting personal data necessary for a specified purpose. Applying requirements to a particular product involves its actual context. An order number alone is not a universal authentication design, and a short transcript is not enough to declare a workflow lawful or unlawful.
Capture evidence without expanding the problem
Logging more personal data is not automatically a better audit. Decide which fields can be omitted, redacted or represented by references. Define appropriate access and retention for the evidence itself.
| Review question | Possible evidence |
|---|---|
| Did the agent request an unexpected field? | Task, approved workflow and relevant message |
| Did a tool receive data outside its purpose? | Tool definition, destination and appropriately minimized request metadata |
| Did the agent act outside a stated policy? | Policy version and captured action |
| Can the reviewer reconstruct the event? | Relevant identifiers, timestamps and available operation records |
Captured evidence depends on instrumentation and configuration. It does not reveal operations that were never recorded or prove that no unobserved event occurred.
Treat detection as a review queue
A pattern matcher may detect a string resembling personal data. It can miss sensitive material or flag benign text. A model-based judgment also needs a clear rubric and validation against reviewed cases.
Keep the finding, supporting evidence, rule version and review outcome together. Separate a possible issue, a confirmed internal-policy deviation and a legal determination. This helps engineers fix a concrete workflow without overstating what the evaluation established.
Test the corrected behavior
For the order-status example, exercise cases with an authenticated session, missing authorization and an unavailable order. Confirm that the agent requests only approved information and handles access failures appropriately.
I’m Shashank Agarwal, founder and CEO of Noveum AI and creator of API.market. I use evaluation evidence to support engineering investigation. The monitoring guide describes capture and review, while the eval-driven guide explains regression testing.
Follow my work on LinkedIn. This refresh was drafted with AI assistance.
Top comments (0)