Sentiment monitoring privacy: what admins see and what they do not
An organization admin using sentiment monitoring sees aggregate sentiment and value signals across their team's AI sessions. They do not see the contents of individual conversations. This post is the definitive statement of that boundary: two explicit lists, no exceptions, no mechanism claims beyond what is confirmed.
In this article
- Why this question needs a straight answer
- What an admin can see
- What an admin cannot see
- Why the line is drawn here
- How this differs from workplace surveillance tools
- What to tell your team before turning this on
- FAQ
Why this question needs a straight answer
Any tool that reports on how a team is using AI is going to get asked, sooner or later, exactly what it shows a manager. That is a fair question and it deserves a fair answer, not a marketing paragraph that dodges it. Employees who hear "sentiment monitoring" for the first time reasonably assume the worst version of that phrase: someone reading their conversations and grading them on tone. That is not what this feature does, and the only way to make that credible is to state precisely what an admin sees and precisely what they do not, and hold that line consistently.
This post is written to be the reference. Every other post in this series that touches privacy points back here, and none of them should say anything that contradicts what is written below. For the general definition of the category, see what is AI sentiment monitoring.
What an admin can see
An organization admin with access to sentiment monitoring can see:
- Aggregate sentiment across their team's AI sessions, shown as a trend, not a single conversation.
- Aggregate value signals, indicating whether sessions across the team are producing useful outcomes or stalling out.
- Patterns over time, such as sentiment or value trending up or down across a week, a team, or a tool.
- Breakdowns by team or group, where the organization's structure supports that grouping, again as aggregates rather than individual records.
- Whether a category of activity (a particular use case, tool, or workflow) is associated with more positive or more negative sentiment than others, at an aggregate level.
Everything on this list is a summary. None of it is a transcript, and none of it is attributed to a single identifiable exchange that an admin can open and read line by line.
What an admin cannot see
An organization admin using sentiment monitoring cannot see:
- The contents of an individual AI conversation.
- The specific prompts a specific person typed, or the specific responses they received.
- A per-person "conversation log" or transcript view of any kind.
- Sentiment or value data broken down to a level small enough to single out one person's individual sessions.
- Anything about a session outside of what feeds the aggregate sentiment and value signal it belongs to.
If a capability is not on the "can see" list above, treat it as being on this list instead. That is the conservative reading, and it is the correct one.
This conservative reading is deliberate. When a new report or view is added to the admin panel in the future, the right question to ask is not whether it seems reasonable, but whether it appears explicitly on the first list. If it does not, it should not be assumed to be included, and it should be confirmed in writing before an organization treats it as available.
Why the line is drawn here
The purpose of sentiment monitoring is to answer a leadership-level question: is the team's AI usage working. That question can be answered with aggregate signals. It does not require reading anyone's individual conversation, and reading individual conversations would not make the aggregate answer more useful, it would just turn a value-measurement tool into a surveillance tool with a different name.
Where the underlying mechanism that keeps individual conversations out of an admin's view is not something we can fully describe here, the principle still holds without exception: the admin panel is built to surface aggregate signals, and it is not built to be a window into individual sessions. If a future capability changed that boundary, it would need to be a distinct, clearly labeled feature, not something bundled quietly into sentiment monitoring.
This same boundary applies to the SIGNLD extension for Claude. Sentiment monitoring is available in the SIGNLD admin panel today, and the same capability, aggregate effectiveness and value per team against token spend, is coming to the extension. It does not change what an admin sees down to the level of an individual conversation.
It is worth being explicit about what "aggregate" means in practice, since the word can be used loosely elsewhere. An aggregate signal here means a number or trend that describes a group of sessions taken together, not a number that happens to be labeled as a summary while still being small enough to point back at one person. A team of one is not a group for this purpose, and a reading that could only describe a single individual's activity does not qualify as aggregate no matter how it is presented on screen.
How this differs from workplace surveillance tools
Workplace surveillance software is generally built around the opposite premise: it exists specifically to give a manager visibility into an individual's activity, often including keystrokes, screenshots, or message content. That is a fundamentally different design goal from sentiment monitoring, which is built to answer a team-level and organization-level question about value, not an individual-level question about behavior.
The practical test is simple. If a tool lets a manager open one employee's session and read it, that is surveillance. If a tool only ever shows a trend line across a group, that is aggregate measurement. Sentiment monitoring is built to be the second thing, and any organization evaluating it should hold it to that test.
This distinction also matters for how a policy team should talk about the feature internally. Describing sentiment monitoring as a way to "see how employees are doing" invites the wrong assumption. Describing it as a way to "see whether the team's AI usage overall is producing value" is the accurate framing, and it is the one this entire post is built around.
For SIGNLD's broader approach to data handling, including read-only access and how everything read from source systems traces back to a source record, see /security and /legal/responsible-ai. For the general definition of sentiment monitoring as a category, revisit what is AI sentiment monitoring.
What to tell your team before turning this on
Turning on sentiment monitoring is easier to do honestly than to do quietly. Tell the team what it is (aggregate sentiment and value tracking across the team's AI sessions), what it is not (a way for a manager to read anyone's conversations), and point them at the two lists above. Most resistance to a monitoring feature comes from uncertainty about what it actually shows, not from the aggregate measurement itself. Removing that uncertainty up front tends to remove most of the resistance.
If your organization has a written AI usage policy, this is worth adding to it in plain language rather than leaving it to be inferred from a settings screen. A short, direct statement, copied close to word for word from the two lists above, does more to build trust than a longer explanation that hedges around the actual boundary.
It also helps to name who actually has access to the admin panel itself. Sentiment monitoring is scoped to organization admins, not to every manager in the company by default, and being specific about who holds that access is part of the same honesty this whole post is arguing for.
Related reading in this series: How admins measure the value their team gets from AI sessions and Measuring AI ROI beyond seat count.
Key takeaways
- Any tool that reports on how a team is using AI is going to get asked, sooner or later, exactly what it shows a manager.
- An organization admin using sentiment monitoring cannot see:.
- Workplace surveillance software is generally built around the opposite premise: it exists specifically to give a manager visibility into an individual's activity, often including keystrokes, screenshots, or message content.
- Turning on sentiment monitoring is easier to do honestly than to do quietly.
- For a general, vendor-neutral definition of the category, see what is AI sentiment monitoring.
FAQ
Can an admin read my individual conversations with sentiment monitoring turned on?
No. Sentiment monitoring shows aggregate sentiment and value signals across a team's sessions. It does not give an admin a transcript view of any individual conversation.
Can sentiment be traced back to one person?
Sentiment monitoring is designed to report at an aggregate level, not to single out one person's sessions. If a breakdown would be granular enough to identify an individual's activity, that is outside what this feature is built to show.
Does this apply the same way to the SIGNLD extension for Claude?
Yes. The same capability, aggregate effectiveness and value per team against token spend, is coming to the extension, and it follows the same boundary described in this post.
What if my organization wants more granular visibility than this?
That is a different conversation from sentiment monitoring, and it should be treated as one, with its own explicit policy and explicit consent rather than assumed as an extension of this feature.
Is this the same as an employee engagement survey?
No. An engagement survey asks people directly and reports what they say. Sentiment monitoring infers aggregate sentiment and value from AI session activity itself. Both are aggregate by design, but they measure different things through different methods.
Where can I read more about the category this feature belongs to?
For a general, vendor-neutral definition of the category, see what is AI sentiment monitoring. For answers to more common questions across the whole topic, see the sentiment monitoring FAQ.