The document has four human names on it. The meeting had five people. The actual number of contributors is harder to count.

One person used AI to outline the report. Another generated interview questions. A third asked for counterarguments, then carried two into the final recommendation. Someone pasted meeting notes into a model and returned with a summary that became the group’s shared memory.

The machine is everywhere in the work and nowhere in the responsibility chart.

Invisible contribution changes trust

Teams have always used tools. No one lists the spreadsheet as a coauthor. The difference is that generative systems contribute language, structure, alternatives, and apparent judgment—the very materials teams use to infer one another’s thinking.

If a colleague presents a sharp risk analysis, others may update their estimate of that colleague’s expertise. If the analysis was largely generated, the estimate may be wrong even when the content is good.

The problem is not purity. It is coordination based on false signals.

Disclosure cannot mean narrating every keystroke

A rule requiring every AI interaction to be documented would create bureaucracy and encourage concealment. Not all uses are equally important.

Correcting grammar is different from generating the central recommendation. Summarizing one’s own notes is different from summarizing confidential interviews. Brainstorming alternatives is different from inventing evidence.

Teams need disclosure at the level of decision influence.

A useful question is: Did the system materially shape what the group believes, recommends, or claims?

If yes, the use belongs in the work record.

The missing owner problem

Generated suggestions often enter a document through passive acceptance. A paragraph survives because no one objects, not because someone has examined and adopted it.

Later, when challenged, every member can say they did not write it.

This is the ghost’s most dangerous form: a claim with no human owner.

Before finalizing collaborative work, every significant claim should have a named person who can explain why it remains. Ownership does not mean original composition. It means accountable acceptance.

A simple team protocol

Teams can preserve speed without losing traceability by recording four things:

1. Purpose — What was AI used to do: summarize, brainstorm, translate, draft, analyze, or critique?
2. Material — What data or documents were provided, and was that permitted?
3. Influence — Which conclusions, sections, or decisions changed because of the output?
4. Owner — Which person verified and accepts responsibility for the final result?

This record can be short. Its value is not legal theater; it prevents the group from outsourcing memory of how the decision happened.

Teams also need a no-AI channel

Some conversations require a space where participants can think aloud without creating model input. Early uncertainty, personnel concerns, private feedback, and sensitive strategy may need this boundary.

A no-AI channel is not a rejection of tools. It is a protected room for speech that has not yet become data.

The boundary should be explicit. Otherwise each participant silently makes a different assumption about whether the meeting, document, or chat may be processed.

Credit and competence

If AI makes one member dramatically faster, the team may reward the visible output while losing sight of competence. This becomes serious when future work depends on that person’s ability to perform without the same tool, access level, or prompt history.

Evaluation should therefore include explanation. Can the contributor defend the choice? Can they adapt it when constraints change? Can they identify what the model got wrong?

The aim is not to catch people using assistance. It is to distinguish possession of an artifact from possession of the judgment behind it.

Bring the ghost into the minutes

AI will remain an ordinary part of group work. Pretending otherwise creates secrecy; treating it as a full colleague creates confusion.

The better approach is mundane transparency. Record where the system materially shaped the work, keep sensitive spaces unprocessed, and assign a human owner to every consequential claim.

The ghost does not need a seat at the table. But the team should know which sentences entered the room through it.

Name the invisible contributor

Teams do not need a confession ritual for every autocomplete. They do need shared thresholds. Generating an agenda may be ordinary assistance. Producing a market analysis, rewriting a colleague’s argument, or recommending a safety decision changes the substance of the work and should be visible.

A short contribution note can record where AI shaped evidence, wording, or choice. The note is not only for blame. It helps future readers understand how the artifact was made and where verification is most important.

Responsibility cannot be averaged away

When several people use different tools, accountability can dissolve into the team. Everyone touched the output; no one owns the claim. Assigning a human steward to each consequential section restores a clear line of responsibility. That steward need not have written every sentence, but must be able to explain the evidence and revise the conclusion.

The same principle applies in classrooms. Group assessment should include moments where members demonstrate what they understand independently and how they resolved disagreement.

The ghost in the project becomes dangerous when it is both influential and unaccountable. Making assistance legible does not eliminate error. It gives error somewhere to return.

The collaborator hidden inside a solo project

Although I have often worked on my application alone, the resulting code is not the product of an isolated mind. AI has proposed architectures, generated implementation drafts, compared interface patterns, and helped me inspect inconsistencies across many pages. When I describe the project as something I built, that statement is true in the sense that I chose the direction, accepted the responsibility, and integrated the work. It is incomplete if it suggests every line emerged from unaided authorship.

The ambiguity became sharper when generated changes crossed many parts of the system. A model could create a shared AI layer, new routes, proposal types, and UI components in one response. Later, when a bug appeared, there was no teammate to ask, “Why did you choose this?” The ghost had contributed code without retaining responsibility for its consequences. I was the only person left in the room, and therefore the only owner of decisions I might not fully understand.

This is not solved by adding “AI was used” to a footer. Disclosure at that level is too broad to help a maintainer, reviewer, or reader understand what happened. The useful record is closer to a design log: which parts were generated, which constraints came from me, what I verified, and what remains uncertain.

Aethel has the same problem in editorial form. Saying that AI assisted with research or editing is honest, but the publication still needs visible human contribution: experiences, source selection, judgments, corrections, and a willingness to remove a paragraph that I cannot defend. The ghost can help with language. It cannot accept a correction request.

A contribution record for human–AI work

For consequential changes, I now prefer a short contribution record. It contains the original problem, the non-negotiable constraints, what the model proposed, what I changed, and how I checked the result. In a team, this could live in a pull request or decision note. In a personal project, it can be a plain text entry. The point is not surveillance of every prompt. It is preservation of ownership.

The record also improves collaboration with future humans. Someone joining the project should be able to distinguish a deliberate product rule from a convenient generated default. They should know why an AI action requires approval, why the Today workspace should not depend on an active sprint, and why a fixed sidebar belongs inside the content layout rather than over the viewport. Those decisions are not obvious from the code alone.

There is a boundary. Requiring exhaustive disclosure for every spelling correction, autocomplete suggestion, or routine lookup would create paperwork without trust. The level of documentation should follow consequence: the more a contribution changes behavior, data, safety, authorship, or evaluation, the more legible its origin should be.

The ghost becomes harmful when it allows everyone to receive the benefit while no one owns the judgment. The answer is not to pretend the ghost was absent. It is to bring the contribution into the minutes, attach decisions to accountable people, and ensure that at least one human can explain why the work deserves to remain.

The group needs a map of contribution, not a confession ritual

Teams often respond to AI by demanding either total disclosure or none. Total disclosure produces chat logs no one can interpret. No disclosure makes it impossible to know whether a member contributed judgment, merely submitted output, or quietly exposed confidential material.

A better contribution map records functions. One member gathered sources, another framed the argument, a model generated alternative structures, and the group verified the final claims. This description is short enough to use and specific enough to assign responsibility.

The map should also name prohibited delegation. A team may allow summarization and formatting while reserving interviews, safety judgments, grading, or final approval for identified people.

A case where polish distorts credit

Imagine four students presenting a design proposal. One student uses AI to turn rough notes into a coherent narrative. Another performs the calculations. A third identifies a safety constraint that changes the design. The fourth coordinates the work. If the presentation is graded mainly on fluency, the visible contribution may receive disproportionate credit.

The solution is not to devalue communication. It is to assess multiple artifacts: the decision log, evidence, calculations, revisions, and final presentation. The group can then distinguish work that improved expression from work that changed the substance.

NIST’s AI Risk Management Framework emphasizes governance and clear responsibility. In a small team, governance can be as simple as knowing who can explain each claim and who must respond if it is wrong.

Keep one human-only checkpoint

Before submission, hold a short meeting without generation. Each member answers three questions: What is our main claim? What is the weakest evidence? What would make us change the recommendation? Differences reveal whether the group shares a model or merely shares a document.

This checkpoint protects against the missing-owner problem. A polished artifact should not be allowed to circulate unless real people can reconstruct its reasoning, identify its limits, and accept the consequences together.

Test the map under pressure

Before the final deadline, choose one important claim at random and ask the named owner to reconstruct its evidence without opening the generated draft. Then ask a second member to explain what would make the claim weaker. If neither can do so, the team has document continuity without knowledge continuity.

This small test also reveals unequal access. A member who was excluded from the prompting or source-selection process may appear less prepared even though the workflow, not their ability, created the gap. Contribution records should therefore be available throughout the project, not assembled only after the work is finished.