Skip to main content
A contemporaneous log of AI use across a project. The same record feeds journal disclosure, sponsor audits, and EU AI Act documentation. Build it as you write — reconstruction at submission time is unreliable. For the principles behind this template, see Review and Accountability and Declaring AI Use.

​
How to use this template

  • Start the log at project kickoff, not at submission. “What tool did I use in week 2?” three months later doesn’t survive audit.
  • One log per project, deliverable group, or workstream — whatever your client or sponsor SOP defines as a unit.
  • Log every non-trivial AI use. Spell-check is generally exempt; everything else benefits from capture.
  • Store the log in the shared project location, not in a personal note. Audit trails that aren’t shared aren’t auditable.
  • Retain per the longest applicable timeframe (sponsor SOP, journal author guidelines, regulatory archiving). Default is the project’s record-retention period.

​
Project header

Fill in once at kickoff. Update if scope or ownership changes.

​
AI use entries

One row per discrete AI use. Add rows as you go. Add rows as needed. Keep entries one-line where possible; expand in the Notes column.

​
Field guidance

  • Date — when the AI was used, not when the entry was written.
  • Deliverable / section — be specific enough that a reviewer can locate the work product. “Manuscript” alone is not specific; “Manuscript Discussion section” is.
  • Tool + version — always include both. “Claude” without a version is undefined when reviewed six months later.
  • Scope of use — one of: Drafting, Editing, Translation, Verification, Synthesis, Image generation, Other. Match the categories used in Declaring AI Use.
  • Source inputs — what was given to the AI? Source documents, prompts, prior drafts.
  • Reviewer — the named human who checked the AI output. A blank reviewer field means an unaccountable AI use; the row is not yet complete.
  • Outcome — Accepted as-is / Accepted with edits / Rejected / Pending review. Clear all pending entries before sign-off.
  • Notes — brief context: what changed, what didn’t, what was flagged.

​
Sign-off block

Complete at deliverable finalisation.

​
What this log supports

A single log feeds four downstream uses:
  • Journal disclosure — entries become the basis for the AI-use statement, with the Disclosure Language Template as the wording reference.
  • Sponsor or client audit — when asked “What AI was used on this deliverable?”, the log is the answer. Without it, you reconstruct from memory under pressure.
  • EU AI Act documentation — the contemporaneous record of tool use, scope, and reviewer aligns with Article 50 transparency obligations and the general documentation expectations covered in AI Regulation in Pharma.
  • Internal QC retrospectives — patterns emerge across projects: which tools cause the most rework, which scope of use produces the cleanest output, where reviewers spend their time.

​
Common mistakes

  • Building the log at submission. “I’ll remember” is not a strategy. Weeks of AI use cannot be reconstructed reliably; entries get missed and the disclosure is weaker than it should be.
  • Logging only successful uses. Rejected and revised entries matter — they show review was active, not rubber-stamped.
  • Vague tool names. “ChatGPT” doesn’t tell a reviewer in 18 months whether it was GPT-4 or GPT-5. Always include version.
  • Missing the reviewer column. A log entry without a reviewer name is an unaccountable AI use. Complete the row before treating the entry as logged.
  • Storing the log in a personal note. If a colleague needs the log during your absence and can’t find it, the audit trail isn’t auditable. Store in the shared project location.
Last reviewed: 4 May 2026 · 6 min read