The situation
The browser controls have been running at a client for a month. The client's chief operating officer asks a fair question: "What did we actually get for this?" A week later, the client's cyber insurance renewal form asks whether the organization controls what staff put into AI tools, and the broker wants something in writing. Both questions need the same thing: a short, regular report that a non-technical leader can read in five minutes and that holds up when someone outside the organization asks for evidence.
Most MSSPs already produce monthly security reports. An AI risk report is a new section or a companion document, and it has one design constraint that other reports do not: it must describe risky behaviour without reproducing the sensitive data involved. This guide walks through what the report contains, section by section. If the client is still deciding whether to act at all, start with what to tell clients who ask what to do about AI.
What the rules actually say
No regulation prescribes the format of a client AI risk report. Several sources do shape what it should contain and what it should leave out.
- NIST AI RMF. The AI RMF 1.0 calls for approaches and documentation to regularly identify and track AI risks (MEASURE 3.1), for ongoing monitoring and periodic review with a defined frequency (GOVERN 1.5), and for incidents to be tracked, responded to and documented (MANAGE 4.3). A monthly report is the practical record of all three. The framework is voluntary.
- PIPEDA. Schedule 1 limits collection to what is necessary for the identified purposes (clause 4.4) and calls for retention guidelines with minimum and maximum periods (clause 4.5.2). A report built from event metadata rather than prompt content is consistent with that approach: it records that a risk occurred without keeping a copy of the personal information involved.
- Ontario's Employment Standards Act. Ontario employers with 25 or more employees on January 1 must have a written policy on electronic monitoring that says whether and how they monitor employees and for what purposes. The requirement is about transparency and does not create new privacy rights. Ontario clients should ask counsel whether their AI controls belong in that policy. Clients in Quebec and other provinces have their own rules to confirm.
Why policies and bans fall short
A policy with no report has no feedback loop. Nobody can say whether it is being followed, which teams struggle with it, or whether last quarter's training made a difference.
A ban produces a report, but a thin one. "Visits to AI sites blocked this month" tells leadership nothing about which data was at risk, and it rises and falls with how often people try before giving up and switching to a phone. The opposite approach, capturing full prompts, creates a different problem: a new copy of sensitive client data, held by the MSSP, that staff know is being read. That pushes AI use onto personal devices, where nothing is visible. There is a middle path, described in getting visibility into shadow AI without banning every tool, and the report should reflect it.
The report also has to respect irreversibility. Once content is submitted to a public AI tool, it cannot be recalled and becomes subject to the provider's terms. So the most important distinction in the report is between events stopped or redacted before submission and events that went through.
What a practical control looks like
A monthly client AI risk report can follow this outline. The sections describe content, not a fixed layout.
- Summary. One paragraph for leadership: coverage this month, the headline change since last month, and the single most important recommended action.
- AI tools in use. The AI tools observed across managed browsers, which teams use them, and any tools that appeared for the first time this month.
- Sanctioned and unsanctioned tools. The tools observed, compared against the client's approved list. Unsanctioned tools that also appear in sensitive-data events are the priority.
- Flagged events by data type and policy. Counts grouped by the type of data involved (client names and identifiers, personal information, health information, financial data, source code, deal terms) and by the policy that applied, with the outcome: redacted, blocked, or allowed after a warning.
- Trends. Month-over-month change, read alongside coverage so that growth in deployment is not mistaken for growth in risk.
- Coaching outcomes. Whether teams that saw in-the-moment explanations generate fewer repeat events, and which teams would benefit from targeted training.
- Incidents and exceptions. Any incidents staff reported, how they were assessed, and policy exceptions requested or granted.
- Recommended actions. Three to five decisions for the client, each with an owner and a date, such as adding a tool to the approved list or adjusting a policy for one department.
State what the report does not contain: no prompt text, no file contents, and no AI responses. Agree with the client whether it stops at team level or names individuals, and for what purpose.
Sanitized Ai supplies the data behind sections two through six. It is a browser extension for Chrome, Edge and Firefox that detects sensitive data in AI prompts and file uploads and redacts or blocks it before submission, with a plain-language explanation to the person so each event doubles as coaching. Its administrator dashboard shows flagged-event metadata (which tool, what type of data, which policy, when) and never prompt content, and it exports audit-ready reports that an MSSP can turn into a monthly report without reading anyone's prompts. The events caught before submission can serve as evidence of reasonable safeguards, although no report guarantees any regulatory or insurance outcome.
To see a complete example laid out for a client, request the sample client AI risk report through the intake form.