A managing partner can't tell who uses Claude on Clio from five laptops. What each setup records, where the one firm-wide log lives, what Claude's own admin tools show by plan, and five questions for any vendor.
[ KEY TAKEAWAYS ]
A managing partner cannot see who in the firm is using the AI on the case system when the connector is installed on each person's laptop, because each laptop keeps its own log and nobody opens five files on five machines. The answer lives in one place only when the connector runs on a server: in the firm's own cloud, where the log is the firm's, or hosted by a vendor, where the log sits on their database. Either way you get one firm-wide log (who, when, which tool, which matter, how many records) and a usage page that answers the question in a minute. Claude's own admin tools answer a different question: Team shows per-seat usage, Enterprise adds audit logs and a Compliance API, and neither shows which matter was opened in Clio or MyCase.
log files for a five-person firm with the connector on every laptop. One per machine, none in the same place.
log when the connector runs on a server, in the firm's cloud or hosted. Every person's calls, one file.
fields a usable log line needs: time, person, tool, matter id, outcome, record count. Nothing else.
matters visible in Claude's own admin logs. They show Claude activity, not what was opened in your case system.
This came up on a call this week with the managing partner of a five-person litigation firm. Every person in the office has Claude, every person has the connector that lets Claude read their Clio, and he has written his own skills for intake scoring, drafting and a weekly sweep of quiet matters. He wasn't asking about features. He was asking a supervision question, and he'd already worked out that he had no way to answer it.
"Finding out what people are actually doing with these tools in my office is very complicated. I have no idea how often somebody else is using it." A managing partner, five-person firm, this week. Every person had the connector installed. Nobody could see it being used.
When the connector runs on a laptop, it writes its log on that laptop. Ours writes an append-only file in the user's home folder. Others write theirs somewhere similar, or nowhere. Either way, the only person who can read the paralegal's log is the paralegal, and only if they know where to look. The managing partner would have to collect five files from five machines, by hand, every time he wanted to know.
He put it more bluntly: he had no idea how often anyone else in the office used the thing at all. Not whether they used it well. Whether they used it. That is the state of most small firms that adopted AI through individual installs, and it has nothing to do with the quality of the tool.
Connector on each laptop
Free, and the right first step for one person trying it out. Each machine keeps its own log. There is no usage page, no roster, and no way to disconnect someone except by walking to their desk. Fine for an individual. Blind for a firm.
Connector on a server the firm owns
Each person signs in with their own case-system login once, through the firm's own cloud account. One log, on the firm's database, with the firm's encryption key. A usage page shows who has connected, when they last used it, and how many calls each person made this month, with the log exportable as a spreadsheet. The access pattern never leaves the firm's infrastructure.
Connector hosted by a vendor
Same sign-in, same log, same usage page, with the server and the database on the vendor's side. Nothing to administer, updates land without anyone doing anything, and the vendor holds the master key and can see which matter each person opened and when. For most firms that trade is fine. For a practice where the pattern of access is itself sensitive, it is the reason to pick the previous row.
Two things are the same in all three rows. The log never contains matter content, if the connector is built properly, and Claude only sees what each person's own login can see in the case system. What changes is whether the log exists in one place and who can read it.
The partner's first instinct was to look for the answer inside Claude, and he'd found that the auditing features sit on a plan tier priced at a multiple of what a five-person firm pays. That matches what Anthropic publishes. Team admins get usage reporting with per-seat exports. Audit logs, and the Compliance API that gives programmatic access to the organisation's activity feed and, for claude.ai organisations, to chats, files and projects, are listed for Enterprise.
Even on Enterprise, that log answers a different question. It tells you that a person used Claude, which features, roughly when. It does not tell you that they opened matter 4821 in Clio through the connector at 9:14 on Tuesday, because the connector call happens outside Claude's own records. The place that knows is the connector. So the two logs are complementary: Claude's for Claude activity, the connector's for case-system activity. A small firm can have the second without paying for the first.
A line that is useful for supervision and safe to keep looks like this: timestamp, the person, the tool that was called (say, get matter), the matter id, whether it succeeded, how many records came back. That is enough to answer "who touched this matter through the AI this month" and "how often does each person use it".
What it must never contain is the content: client names, note text, custom field values, search queries, time entry narratives. A log that captures those is a second copy of the client file sitting in a place nobody treats as a client file. The way to be sure is a test, not a promise: run every tool with marker values and check that none of them land in the log. The open-source connector we maintain ships that test in the public repository, with an allowlist that decides which arguments may be written and redacts the rest. If a vendor cannot show you the equivalent, assume content can leak. The ten-minute canary test works on any connector's local log.
One shared login undoes all of it If the whole team signs in to the AI, or to the connector, with one account, every line in every log carries the same name. The usage page becomes a single bar. Per-person sign-in is not a nice-to-have on top of the log; it is what makes the log mean anything.
The log is for the question "what happened on this matter". The usage page is for the question the partner actually asked: who is using this at all. On a server deployment the page is a roster pulled from the case system itself, so it shows everyone who could connect, marked connected or not, with the date each one last used it and the number of calls this month, broken down by person and by tool. The three people who never connected are visible by their absence. The paralegal who ran intake scoring on fourteen matters last week is visible by their count.
Two switches belong next to that page. A firm-wide read-only switch that removes every tool that writes to the case system, so a cautious firm can roll out reading first and turn on writing when it decides to. And a disconnect button that revokes that person's authorisation at the case system, not just at the connector, so leaving the firm means leaving the connector too.
Want the one log instead of five?
We deploy the connector in your own cloud account or run it for you, with per-person sign-in, the firm-wide log and the usage page. A 30-minute call tells you which shape fits your firm.
Ask these in writing
A vendor on any architecture can answer all five. A vendor who hedges on the second or third is the red flag, not a vendor whose log sits somewhere different from ours.
The partner's conclusion was that the inability to see what anybody is doing is a problem worth solving, and that it is the reason to move the connector off the laptops. Not the scheduling, not the features. The log. If your firm adopted AI one laptop at a time, that is probably your reason too.
Only from a log that lives in one place. A connector installed on each person's laptop keeps a separate log on that laptop, so the answer is scattered across five machines. A connector that runs on a server, in the firm's cloud or hosted by a vendor, keeps one firm-wide log and can show a usage page with who has connected, when they last used it and how many calls each person made. Claude's own admin console shows Claude usage per seat, not which matters were opened in Clio.
Claude Team gives admins usage reporting and per-seat exports. Audit logs and the Compliance API, which give programmatic access to the organisation's activity feed and, for claude.ai organisations, chats, files and projects, are listed by Anthropic for Enterprise organisations. Check the current plan page before you rely on either, because the feature lists move.
Timestamp, which person, which tool was called, which matter id, the outcome and how many records came back. It should never contain matter content, client names, note text, custom field values or search queries. The test is simple: run every tool with marker values and check that none of the markers appear in the log. If a vendor cannot show you that test, assume content can leak into the log.
It shows which matter each person opened and when, without the content. For most firms that is the supervision feature they want. If the pattern of access is itself sensitive, the log should sit on infrastructure the firm controls rather than on a vendor's database. That is a deployment choice, not a feature switch.
ABA Formal Opinion 512 ties generative AI use to the existing duties of competence, confidentiality and supervision of lawyers and non-lawyers. A firm that cannot say who used which tool on which matter will struggle to show it supervised anything. A one-place log is the cheapest way to have that answer ready.
It does the opposite. One login for the whole team means every line in every log says the same name, so the log can no longer tell you who did what. Per-person sign-in is what makes the usage page and the audit log mean anything.
NEWSLETTER
[ WRITTEN BY ]
Petar Jovanović
Co-Founder & Technical Lead
Co-Founder and Technical Lead at Oktopeak. Builds regulated software for legal and healthcare teams, and leads the rescues of codebases other vendors left half-finished.
[ LEGAL TECH ]
LEGAL TECH
Sep 2, 2026 · 9 min read
Every AI connector advertises an audit log. Almost nobody reads one. A ten-minute diagnostic for any connector: where the file lives, the canary test that shows whether it stores content or references, why denylist redaction fails open, and the five questions worth putting to a vendor.
Read ArticleLEGAL TECH
Oct 7, 2026 · 8 min read
Projects, per-user connectors, tool approval, a connector in your own cloud. What each isolates for a four-attorney firm on Enterprise, and what does not.
Read ArticleLEGAL TECH
Oct 9, 2026 · 8 min read
A lawyer sorted his own skills in one sentence: anything with a yes/no gate needs a person, anything that only reads can run alone. The three-question test, his skills sorted, and what the server actually changes.
Read Article[ GET STARTED ]
30-minute call. No pitch deck. Just an honest conversation about your project.
