B. AI in Collaborative Work: The Third-Party Problem

Purpose: When you use AI to help produce something you then share with colleagues, the AI becomes a silent third party in the collaborative relationship — present in the content but invisible to your collaborators. This document names what that does to team trust, describes the failure modes on both ends of the encapsulation spectrum, and proposes practices that keep collaborative relationships honest and functional.

This is distinct from publication disclosure (covered in B.ownership and E.journal-funder-policies). The focus here is everyday collaborative work: sharing drafts, co-authoring, delegating within a team, discussing ideas in progress.

The third-party problem

Collaboration is a relationship between people who can interrogate each other. When you share an idea with a colleague, they engage with it knowing something about you — your judgment, your biases, your history of being right and wrong, your intellectual agenda. That knowledge is how they calibrate their response.

When AI-assisted content enters that relationship without disclosure, a third party enters it too — one your colleague cannot see, cannot question, and cannot calibrate against. They think they are engaging with your thinking. They are partly engaging with Claude's.

This is not necessarily dishonest. It becomes a problem when:

The third-party problem is structural, not a matter of intent. It arises from the gap between how AI-assisted content is produced and how collaborative relationships work.

Two failure modes

Failure mode 1: The transparent pass-through

You share Claude's output with minimal digestion — copy-pasting a draft, forwarding a structured plan, presenting a list of arguments. You may or may not disclose that Claude produced it. If you do disclose, you cite Claude as the source of the position: "Claude said we should structure it this way."

The problem with pass-through is not the sharing — it is the citation pattern. When Claude is named as an authority in team deliberation, several things happen simultaneously:

Naming Claude as an authority in a team conversation misrepresents what Claude is. Claude is a thinking tool, not a participant. Its output is raw material for your judgment, not a position that stands on its own.

Failure mode 2: The opaque encapsulation

You fully absorb Claude's output and present it as your judgment, without any disclosure. Your colleagues engage with it as they would engage with thinking you had done yourself. Their trust in you extends to cover the AI output behind you.

This feels like the responsible end of the spectrum — you owned it, you can defend it. But there are problems:

The problem with opaque encapsulation is not the content — it may be excellent. It is the relationship: your colleagues are not in a relationship with you as you actually are.

The right principle: share your judgment, not Claude's output

The useful frame is not how much to disclose but what you are actually sharing.

You are entitled to use whatever tools help you think. You are responsible for what you put into the collaborative space. What belongs in that space is your judgment — formed however you formed it. What does not belong is Claude's output presented as your judgment when you have not actually made it your own.

This means the question before sharing is not "did I use Claude?" but "do I own this?" Can I explain why it is structured this way? Can I defend the key claims? Can I engage with my colleague's response — agree, disagree, revise — based on actual understanding rather than on what Claude said?

If yes: share it. The process that produced it is secondary.

If no: you are not ready to share it yet. More digestion is needed — not for the sake of concealment, but because you would be sharing something you are not yet in a position to stand behind.

The "Claude said" citation: two versions

Citing Claude in team discussion comes in two quite different forms. They are worth distinguishing because they have different implications.

The diplomatic flag: a legitimate use

A GDoc comment reads: "Claude flagged an issue here with the historical chronology — might be worth checking." Or: "I ran this section past Claude and it raised a question about the source — not sure if it's right."

This is transparent and genuinely useful. It signals: I used AI, I am not certain, someone with domain knowledge should look at this. The colleague reading it knows what they are dealing with. The AI is not presented as an authority — it is presented as a prompt for human verification. This is close to good practice.

The remaining limit of this form: your colleague cannot see the Claude conversation that produced the flag. They do not know what question you asked, what context you provided, or what else Claude said alongside the flagged item. If the flag is wrong — if Claude raised a false concern — your colleague has no way to assess that without going back to the source. The flag is more legible than opaque encapsulation, but it is still one step removed from the reasoning.

The authority citation: a failure mode

"Claude thinks we should use this framework." "I asked Claude and it recommended against this approach." "According to Claude, the standard in the field is X."

Each of these introduces Claude as a position-holder whose recommendation is being transmitted into the team conversation. The problems are specific:

Claude cannot be interrogated. Your colleague cannot ask Claude why it recommended against the approach, what alternatives it considered, whether it understood the specific context. Only you have access to that conversation, and only partially.

The output is context-dependent in ways your colleagues cannot see. It depends on what you put in — your framing, your emphasis, what you included or excluded. The same question asked differently would have produced a different answer. "Claude said X" presents the output as if it were a stable, interrogatable position. It is not.

It displaces deliberation. When a recommendation enters the conversation with Claude's name attached, it carries a kind of authority — the sense that a capable, neutral system has weighed in. That authority is unchallengeable and cannot be earned by Claude, which has no stake in the outcome and no accountability to the team.

It hides responsibility. "Claude suggested it" is a way of floating a position without owning it. This is sometimes unconscious. It is still a problem.

The alternative is consistent: "I worked through this with Claude and came to think we should use this framework — here is my reasoning." The AI assistance is acknowledged; the judgment is owned; the reasoning is open to engagement.

Team norms: making AI use legible

These problems are solvable, but they require naming them explicitly within the team — ideally before they become visible through a trust breakdown.

What a team needs to negotiate:

What kinds of AI use will be acknowledged? There is a difference between using Claude to brainstorm, to check your reasoning, to draft something you will substantially rewrite, and to produce deliverables you will share directly. Teams may have different norms about which require acknowledgment. Having that conversation is more valuable than any particular answer.

How will AI-assisted content be marked in shared spaces? Some teams use light conventions — a note in a document header, a brief mention in the covering message — that does not require detailed accounting but keeps provenance visible. This is different from the formal disclosure language of publication.

What is the norm around citing Claude in discussion? Agreeing that "Claude said" is not an acceptable citation — that Claude's outputs must be processed into someone's actual position before entering team deliberation — is a small norm with significant effect.

How will unequal use be handled? If some team members use AI heavily and others do not, that asymmetry needs to be visible and agreed upon, not concealed. The concealment creates resentment; the acknowledgment can lead to productive conversation about how the team works and who does what.

The trust asymmetry over time

Team trust is built through a history of interactions. You learn each other's judgment: how careful this person is, where they tend to overreach, what their blind spots are, what their strengths look like. This history is what makes delegation possible — you can hand something to a colleague and trust it without supervision because you know how they work.

Undisclosed AI use disrupts this calibration. If one person consistently produces high-quality output with heavy AI assistance, colleagues calibrate their trust against a signal that is partly false. They attribute capabilities to that person that may be partially AI-dependent. When the AI-assisted and un-assisted work diverge — as they will — the discrepancy is confusing and the trust revision is more painful than disclosure would have been.

Disclosed AI use — at the level of team norms, not item-by-item accounting — keeps the calibration honest. Colleagues can build an accurate model of what you are doing and extend trust accordingly.

The adoption gap

In most teams, AI adoption is not symmetric. Technical and programming-oriented members tend to adopt AI tools earlier and more extensively — they are closer to the tool's capabilities, more comfortable experimenting, faster to find productive workflows. This creates a real asymmetry: some team members produce more, faster, with apparently more fluency, while others are still finding their footing.

This asymmetry has two failure modes. One is concealment: the heavy users do not disclose, and the gap looks like a competence difference rather than a tool difference. The other is the opposite: technically-oriented members who know AI limitations well may become sceptical in ways that are also not clearly communicated — dismissing AI-assisted work without naming why, or holding a higher standard for it than they would name explicitly.

Neither the early adopters nor the sceptics are obviously right. The person who knows a tool's capabilities deeply may be the best judge of when to trust its output; they may also be systematically overconfident in their own ability to spot errors in domains outside their expertise. Having these differences visible within the team — so they can be discussed rather than acted out — is more productive than either side assuming their calibration is correct.

Sharing AI products with close individuals outside the team

The same dynamics apply, in a softer form, to sharing AI-assisted content with individual colleagues — a co-author you are emailing a draft to, a supervisor whose feedback you are asking for, a peer you are discussing an idea with.

The useful question is the same: are you sharing your judgment, or Claude's output? And does the person you are sharing with have enough information to engage with it appropriately?

A supervisor giving feedback on a Claude-drafted section they think you wrote is giving feedback under false premises. Their feedback will be calibrated to what they believe they are reading. If they knew it was Claude-drafted and awaiting your revision, their feedback would be different — and more useful.

This does not require formal disclosure every time. It requires that the nature of what you are sharing be legible: is this a finished thing you are standing behind, or a draft in process, or raw material for discussion? Those are different objects and deserve different kinds of engagement.

In practice: collaborative research teams

The dynamics described in this document take concrete form in teams that use Slack for discussion and shared documents for collaborative writing — the typical infrastructure of a contemporary research group.

In shared documents with comments: The collaborative document is where AI-assisted content enters most visibly. A draft section appears; comments accumulate; colleagues revise in suggestion mode. The question of provenance — who wrote this, what is its status — is already implicit in document culture. Adding AI to the picture makes that question more loaded. A section that was drafted by Claude and lightly reviewed is a different object than a section written slowly by the person whose name is in the version history. The document's comment system is the natural place for provenance signals: a note in the header, a comment at the top of a Claude-drafted section, a flag in the sharing message. Light, not forensic.

In Slack: Discussion moves faster than document review. When AI-generated content enters Slack — a summary, a draft paragraph, an analysis — the informal register tends to suppress disclosure that would feel natural in a document. "Here's a quick thing Claude drafted, thoughts?" is easy to say; it is also easy to omit under time pressure. The discipline of naming provenance in fast communication is harder to maintain and more important, because Slack conversations shape decisions that then propagate into documents.

The shared full-report case: Sometimes the right workflow is to have Claude compile an analytical report from data and share the output — reviewed but not substantially rewritten — as a team document. This is a legitimate and efficient workflow. The condition that makes it work: the provenance must be legible to everyone who reads it. A document header noting "compiled by Claude from [dataset], reviewed by [person], [date]" is sufficient. What breaks the workflow is when readers engage with it as if it were a human analytical judgment, when it is actually a structured AI output that has been checked for errors but not re-argued. Colleagues reading a report calibrate their engagement to what they think they are reading. Make it easy for them to calibrate correctly.

The coauthor subteam: Within a larger team, the tightest collaborative work happens in small coauthor groups — two or three people working closely on a shared manuscript or analysis. This is where the third-party problem is most acute, because these relationships carry the most trust and the most accountability. A coauthor who uses Claude heavily without disclosure is importing a silent collaborator into a relationship built on the assumption of direct intellectual engagement. The closer the collaboration, the more disclosure matters — not as a formal requirement but as a condition of the relationship actually being what it appears to be.

Building on existing attribution culture: Teams that already have explicit norms about co-authorship — who appears on which paper, in which order, for what contribution — have a foundation that AI disclosure norms can extend rather than replace. The same honesty that governs credit attribution governs AI use. Teams without that culture face a harder conversation, because they have to establish the norm from scratch at the same moment the technology is changing what it means.

The inter- and transdisciplinary advantage: Research teams that bring together historians, social scientists, and technical members already navigate a question AI makes more complex: who can evaluate what? In a disciplinarily diverse team, it is already normal to say "this is outside my expertise, I trust your reading of this source" or "I cannot evaluate the network analysis, can you walk me through it?" That culture of acknowledged expertise asymmetry and mutual respect is actually a strong foundation for handling AI — because the same question applies. Who can evaluate what Claude produced here? In whose domain does the AI-generated claim land, and who has the standing to check it?

Teams with a culture of negotiation and shared attunement rather than imposition are also less vulnerable to the "Claude as authority" failure mode. A team oriented toward deliberation does not readily accept unchallengeable recommendations — whether from a senior colleague or an AI system. The problem to watch for is the mirror: a team that is good at attunement may start treating Claude's outputs as another voice to attune to, rather than as raw material that requires a person to own it before it enters the conversation. The discipline is the same one already practiced in interdisciplinary work — not deference to expertise, but engagement with reasoning that can be followed and questioned. Claude can provide reasoning that looks followable. The question is whether it is actually grounded in the specific context your team inhabits, which Claude does not share.