Back to blog

A practical model for AI attribution

A statement that says “AI was used” reveals almost nothing. Practical attribution records contribution, ownership, initiation, review, and evidence.

WhoWorked team9 min read
Fine silver circuit paths running across a dark surface.

“AI was used in the creation of this work.”

The statement is transparent in the narrowest sense. It is also nearly useless.

It does not tell the reader whether AI corrected grammar or produced the first full draft. It does not say who initiated the work, what a person changed, whether the claims were checked, or who approved the final result. It discloses the presence of a tool while leaving the production process opaque.

As AI becomes part of ordinary knowledge work, teams need a better vocabulary. Not a forensic history of every prompt. Not a single percentage that pretends authorship can be measured exactly. A compact, consistent way to explain how people and AI systems contributed to a result.

What the AI Attribution Toolkit gets right

The AI Attribution Toolkit is a research prototype designed to help creators reflect on and disclose how generative AI contributed to their work. It starts from an important observation: existing conventions such as citations, credits, and licenses are poorly suited to collaborative workflows in which people and AI systems jointly produce an artifact.

The toolkit uses guided questions to help a person describe the system used, the nature and scope of its contribution, the degree of human modification or curation, and the location of final accountability. It then produces a standardized disclosure statement.

The most important choice is philosophical. The toolkit centers human judgment and self-reporting instead of claiming that software can infer authorship perfectly. It treats attribution as a communicative practice, not a verdict.

That is a strong foundation for professional work. A client, reviewer, or colleague usually does not need a complete conversation transcript. They need enough structure to understand what happened and enough accountability to know who stands behind the result.

WhoWorked adapts that idea from artifact disclosure to an operational record. A deliverable is not produced in isolation. It belongs to a project and workstream. It has an accountable owner, recorded human effort, one or more AI contributions, evidence with varying fidelity, and a review state that can change over time.

The disclosure is the readable output. The attribution record is the system underneath it.

Five questions make attribution useful

A practical model should answer five questions.

Attribution model

Five questions, one accountable owner

01InvolvementHow material was the AI contribution?
02ContributionWhat did the system actually do?
03InitiationWho started or directed the work?
04ReviewWhat did a responsible person check?
05EvidenceWhat supports the record?

Turn the fields into a plain-language disclosure.

Build a statement

1. How material was the AI involvement?

The first question is not whether any AI feature was present. Modern software contains AI in search, autocomplete, transcription, grammar correction, and dozens of background functions. Recording every incidental interaction creates noise.

The useful question is whether AI materially affected the delivered result.

A small involvement scale is easier to apply consistently:

  • No material AI involvement: AI did not meaningfully affect the delivered result.
  • Primarily human: A person produced the substantive work, with bounded AI assistance.
  • Collaborative: Human and AI contributions both materially shaped the result.
  • Primarily AI with human review: AI produced the first substantial output, and a named person evaluated and approved it.

These labels describe a production process. They are not quality scores. Excellent and poor work can emerge from any level.

2. What did the AI contribute?

“AI-assisted” still covers too much ground. The contribution should use plain verbs that connect to actual work:

  • Researched
  • Generated
  • Edited
  • Summarized
  • Translated
  • Coded
  • Reviewed

More than one can apply. A system might research sources, summarize them, and generate a first draft. The point is not to produce a long taxonomy. It is to distinguish materially different roles.

Contribution type is often more useful than the model name. Clients care that AI generated a first draft of legal analysis or translated interview notes. Whether the model was version 4.1 or 4.2 may matter internally, but it does not explain the work by itself.

3. Who initiated and directed the work?

Initiation distinguishes a person deliberately delegating a bounded activity from a system suggesting or triggering work on its own.

At minimum, record:

  • Human initiated: A person asked the AI system to perform the contribution.
  • AI suggested or system initiated: The system proposed or triggered the activity, subject to the team’s controls.

This becomes more important as agents operate in the background. A person prompting a model to summarize a meeting is different from a monitoring agent creating an alert overnight. Both can be legitimate, but they create different oversight and evidence needs.

4. What human review occurred?

Review is the bridge between contribution and accountability.

A binary “reviewed” flag may be sufficient for a lightweight disclosure, but operational systems benefit from a lifecycle:

  • Auto-drafted
  • Unreviewed
  • Reviewed
  • Verified
  • Dismissed

The distinction between reviewed and verified should be defined by policy. For example, reviewed might mean a responsible person checked the output for fit and obvious errors. Verified might require checking claims against sources, running tests, or completing a domain-specific checklist.

Review status should name the accountable person or role. “Human-reviewed” is more credible when the record can answer “by whom?”

5. What evidence supports the record?

Attribution can begin with self-reporting, but it becomes more reliable when supported by evidence. Evidence might include:

  • A linked agent session
  • Tool and model identifiers
  • Start and end timestamps
  • Provider usage data
  • Token counts and compute cost
  • A repository event or document version
  • A privacy-preserving tool activity signal
  • A reference to the reviewed deliverable

Evidence does not need to include prompt and response content. In many professional settings, capturing that content would create more risk than value.

The five fields in a portable attribution record
QuestionRecord fieldWhat it clarifies
How material was the involvement?Involvement levelWhether AI materially affected the delivered result
What did the system contribute?Contribution typeThe role AI played in the work
Who initiated and directed it?InitiationWhether the activity was delegated or system-triggered
What human review occurred?Review state and reviewerWho stands behind the result and what they checked
What supports the record?Evidence provenanceWhich observable facts make the account verifiable

Add the business context

Artifact disclosure answers how a piece of work was produced. Work attribution also needs to answer where that work belongs.

For operational use, attach the five dimensions to:

  • The responsible person or team
  • The client or internal project
  • The workstream
  • Actual human time, when relevant
  • The delivered outcome
  • Applicable policy or client requirements

This context is what turns an AI disclosure into a useful business record.

Suppose an analyst uses an AI assistant to synthesize 12 customer interviews. The system generates an initial set of themes. The analyst returns to the source calls, rejects two weak patterns, adds contradictory evidence, and approves the final research summary.

A client-facing disclosure might say:

This research summary was prepared by Maya Chen with assistance from Claude. AI was used to organize source notes and draft an initial synthesis. Maya verified the findings against the source interviews, revised the conclusions, and approved the final deliverable.

The internal record can carry more detail:

Involvement: Collaborative Contributions: Summarized, researched, generated Initiation: Human initiated Review: Verified by Maya Chen Evidence: Linked tool session and 12 source references Project: Northstar positioning Workstream: Customer research Outcome: Five supported themes and two rejected hypotheses

The two versions come from the same underlying facts. They are different views for different audiences.

Why we would not use a confidence score

Confidence can be useful when a system infers whether AI was involved. It is less useful when a person is asked to assign a numerical confidence to their own disclosure.

A value such as “82% confident” looks precise without explaining what uncertainty remains. Was the person unsure which contribution type applied? Did they forget part of the workflow? Was the evidence incomplete? The number collapses different problems into one score.

WhoWorked favors explicit review state and evidence provenance. An auto-captured event can be marked as a draft. A person can confirm, edit, or dismiss it. The record can show whether it came from self-reporting, a provider, an integration, or another source.

That gives reviewers something they can interpret and act on.

Why tokens and cost belong in the operational record

Tokens and compute cost do not explain authorship. They do matter for operations.

A firm may need to understand AI cost by client, model, project, or workstream. Finance may want to decide whether compute remains overhead or is passed through. Engineering may need to compare models. Procurement may need evidence that only approved systems touched a project.

For those reasons, WhoWorked adds optional usage and cost fields to the attribution record. They support budgeting and audit questions without being mistaken for measures of value.

One million tokens do not prove that useful work occurred. A low-cost model call can still produce a critical contribution. Cost belongs in the evidence, not at the center of the story.

Privacy should constrain capture

Better attribution does not require deeper surveillance.

Teams should collect the minimum evidence needed for the decision at hand. Tool name, model, timestamp, active-time signal, contribution type, and review state may be enough. Full prompt and response content should require a separate, explicit justification and appropriate controls.

This is especially important for client services. Prompts may contain confidential context, personal data, source material, or proprietary reasoning. A system that copies everything into an attribution database can create a new governance problem while trying to solve an old one.

A defensible principle is:

Record that the tool was used, how it contributed, and who reviewed the result. Do not collect the conversation unless the use case truly requires it.

From disclosure sentence to portable record

The same model can produce several useful outputs:

  • A one-sentence document disclosure
  • A detailed client report note
  • A repository attribution string
  • An invoice explanation
  • A machine-readable JSON record
  • An internal review queue item

A compact string could look like this:

AIA: collaborative | researched, generated | human-initiated | human-verified | Claude

The exact syntax matters less than consistency, documentation, and a plain-language version that anyone can understand. A compact format should point to the full record, not replace it.

A standard should make better conversations possible

AI attribution will not eliminate judgment. Teams will still disagree about what counts as material involvement, what review is sufficient, and what a client needs to see.

That is not a failure of the model. A good model gives those conversations stable terms.

Instead of asking “Was this made by AI?”, a team can ask:

  • What did the system materially contribute?
  • Who directed the work?
  • What did a person verify?
  • What evidence supports the record?
  • What does this audience need to know?

Those questions preserve nuance without making disclosure vague. They create a practical bridge between creative attribution, operational evidence, client trust, and business accountability.

“AI was used” is a start. A useful record tells us how.

Sources

Related posts

AI did the work. Who gets the credit?

Human timesheets and AI usage logs each record only half the work. A useful attribution model keeps accountability human while making material AI contributions visible.

WhoWorked team8 min read

Start counting all the work.

30-day free trial. Bring the time history you already have.