An AI message feed is the start of a review
Connecting Claude or another AI source gives you activity. Useful oversight also needs scope, rules, user context and a recorded decision.
A monitoring dashboard shows no exceptions. That could mean the messages passed the selected rules. It could also mean a source stopped returning data, the wrong policies were selected, or the activity happened outside the connected workspace.
The queue alone cannot distinguish those situations. Oversight needs a record of the work that produced it.
Start by defining what the connection covers
An AI provider’s compliance interface is a source of evidence with a particular scope. It is not a view of every way people use AI.
For example, Claude’s Compliance API requires enterprise configuration and authorised access. Content access depends on the available permissions and endpoints. Establish those settings before describing the coverage to anyone relying on the results. Claude Help Center, Access the Compliance API.
For each connected source, write down the workspace, available event types, relevant permissions and the period being collected. Identify what is outside that boundary: another workspace, a personal account, an unsupported surface or data the source no longer makes available.
This also gives a custom integration a clear contract. A source should describe what an event means, how its user is identified, which timestamp is authoritative and how duplicate or missing events are handled. Otherwise, the same event can be counted twice while another goes missing unnoticed.
Separate collection from evaluation
Treat these as distinct questions:
| Question | Evidence to retain |
|---|---|
| What was available? | Source and collection period, with known limitations |
| What was processed? | Run status, successful coverage and any collection errors |
| What was checked? | Selected policies and the rules applied |
| What needed attention? | Exceptions with source, user, reason and severity |
| What happened next? | Review state and the recorded outcome |
These fields are a proposed operating checklist, not a claim that every provider returns them directly. Some come from the source; others need to be recorded by the monitoring process.
The distinction becomes useful when someone asks about a quiet week. “No exceptions” is a result. “The intended sources were checked for the intended period under these policies” explains the result’s boundary.
Write rules around a decision someone can make
Consider an illustrative message: “Summarise the notes on Project Alder’s unannounced acquisition.” If Project Alder is on the firm’s restricted-project list, the message can trigger an exception under an internal information policy.
A useful finding identifies the user, source, relevant rule and reason. It gives the reviewer a route to investigate the circumstances. Was the information actually restricted? Was this an approved use in an authorised environment? Did the phrase appear inside an example rather than live transaction material?
Do not collapse those questions into a keyword match. Equally, do not write a rule so broad that every conversation about acquisitions reaches the same queue. Begin with a defined concern and the evidence needed to assess it.
The same principle applies to regulations. A phrase associated with a regulated use case can warrant investigation without establishing that a legal obligation has been breached. Keep detection, contextual assessment and the eventual decision distinguishable.
Test the quiet cases as well as the obvious ones
A rule that catches a deliberately alarming sentence has passed a small test. It also needs examples that should pass without a finding.
For a restricted-information rule, prepare reviewed examples covering direct references, paraphrases, public information, internal training material and ambiguous cases. Record the expected outcome and the reason. Use material approved for this purpose; do not create a new disclosure problem while testing the control.
When the rule changes, run those examples again. Inspect both missed concerns and unnecessary escalations. A queue that continually sends harmless messages for review consumes the attention needed for the important ones.
Maintain an owner for the rule and a reason for each material change. As policies and work patterns change, the test examples should change too. This is ongoing maintenance of a control, not a one-off prompt-writing exercise.
Retain the outcome without collecting everything forever
Decide what evidence the organisation needs, who may access it and how long it should be kept. Raw messages and a review record are different data objects. The right retention approach depends on the source, the purpose and the organisation’s obligations.
In Connor, connected message content is evaluated during ingestion. Exceptions retain the result, reasons and source metadata; raw message text is not retained in the activity record. The reviewer can acknowledge, resolve or reopen exceptions, and each monitoring run records its selected policies, period and source coverage.
That makes the rulebook and the run history part of the product, alongside the connection itself. Explore AI Monitoring.
The useful question is whether a particular source was checked under a particular set of rules, and whether the resulting concerns received a decision. Build the record so that question can be answered.
Frequently asked questions
Does an empty exception queue mean there is no risk?
No. It means no exceptions were raised by the checks that ran on the data available. Source coverage, rule scope and collection failures need to be inspected separately.
Should every matched message be treated as a breach?
No. A match can identify a conversation that needs context. The reviewer should establish what happened and record the outcome, including cases where the rule matched harmless activity.
