Module 03 · Lesson 05

Audit Trails and Documentation — What to Record and Why It Matters

Reading time: 18 minutes Track: Governance & Compliance · REQUIRED before role specialization Prerequisites: Module 03 · Lessons 01-04

What this lesson does

This is the final lesson in Module 03. It addresses the question that every regulator, every auditor, and every internal compliance review will eventually ask: show me what you did and why.

The other Module 03 lessons taught you what AI use is appropriate. This lesson teaches you how to make your appropriate use defensible — provable to someone reviewing the work later who didn't witness the original decisions.

By the end of this lesson, you'll be able to:

Identify what should be logged for any AI-assisted work product
Build documentation habits that scale across your daily work
Recognize the documentation expectations of different regulatory contexts
Position yourself ahead of likely future requirements

This lesson is shorter and more practical than the previous four. Most of it is checklists and habits.

01 · The single most important point

The regulatory and audit landscape around AI in biotech is evolving. What is or isn't required will shift over the next 24 months. New guidance documents, new inspection findings, new precedents.

You cannot future-proof against every possible requirement. You can do one thing: document your AI use thoroughly enough that any future regulatory requirement can be satisfied retroactively.

The cost of over-documenting is low — a few extra minutes per artifact. The cost of under-documenting and then having to reconstruct AI use history is enormous, and sometimes impossible.

Default to documenting more, not less. The habit is light. The cost of not having it is heavy.

02 · The five things to log

For any AI-assisted work product that might be reviewed later, log five things:

1. Tool and model

Which AI tool, which model, which version. "Claude" isn't enough. "Claude Opus 4.5 via Claude Enterprise" is enough. "ChatGPT" isn't enough. "GPT-5 via ChatGPT Enterprise" is enough.

Why specificity matters: model behavior changes between versions. If a reviewer later asks "could this output have been produced by the model you're claiming?", you need to be able to point at a specific version with documented capabilities.

2. Environment and configuration

Was it consumer or enterprise? Were specific settings active (data retention off, model selected manually, custom instructions in place)? Was it accessed via a workflow tool or directly?

Why this matters: the environment determines what data-handling guarantees applied. A reviewer reconstructing your AI use needs to know not just which model but which configuration.

3. Date and approximate time

Not down-to-the-minute precision (usually). Just enough to anchor the use in time. "Drafted with AI assistance on 2026-03-14" is sufficient for most purposes.

Why: AI capabilities change over time. The same model interaction in 2024 and 2026 may have produced different outputs. The date locks the context.

4. Input and output, in summary

What did you provide to the AI? What did it produce? Not necessarily the full prompts and responses (often impractical), but enough that someone could understand the scope of AI involvement.

Examples:

"Provided draft of Section 5.3 and asked for review against ICH-E3 completeness checklist; received list of 12 suggested additions, 8 of which I accepted"
"Provided study protocol and asked for plain-language summary; AI produced 600-word summary, which I revised for accuracy and tone before incorporating into the patient handout"

This is the most subjective of the five logs and the one where judgment matters most. The goal: a reviewer should be able to understand what AI did versus what you did.

5. Verification and revision history

What did you do to verify the AI output? What did you change before finalizing?

Examples:

"Verified all cited references manually against PubMed; corrected two incorrect publication years"
"Reviewed for off-label content; removed one paragraph that strayed beyond the approved label"
"Cross-checked all numeric values against source CSR tables; found and corrected one transcription error in the AI output"

This is the log that distinguishes responsible AI use from rubber-stamping. The presence of verification is the difference.

03 · Where to log

The right level of formality depends on the work product. Three tiers of formality:

Tier A — Lightweight logging

For internal, low-stakes work. A note in the document's metadata, a comment in version history, a sticky note next to the file.

Examples:

"AI-assisted drafting; M365 Copilot; verified before circulation" in document properties
A footer note: "Initial draft assisted by Claude Enterprise (Opus 4.5); revised and verified by [author]"

Lightweight logging takes 10 seconds. Do it always, even for work you think won't be reviewed. Habits don't differentiate which artifacts will end up under review.

Tier B — Standard logging

For most work product that goes anywhere internal or external. A short paragraph or table in version control, or a dedicated AI-use log file alongside the artifact.

Example log entry:

Document: Q1-2026-Board-Update.docx
AI involvement: Initial draft
Tool: Claude Opus 4.5 via Claude Enterprise
Date: 2026-04-08
Inputs provided: Bullet-point summary of clinical, regulatory, financial milestones
Outputs received: 1,100-word draft memo
Verification: Cross-checked all numeric values against source documents (no errors found)
Revisions: Tightened from 1,100 to 850 words; sharpened recommendations; added specific board asks
Final review: Author

That's a few minutes of work. It produces a record that survives.

Tier C — Formal documentation

For regulatory submissions, audit-relevant work, anything covered by SOPs requiring AI-use logging. Specific format usually defined by your company's SOP.

Typical elements:

Full prompt(s) or summary of prompt structure
Full output(s) before revision
Detailed verification log
Reviewer credentials and approvals
SOP references and policy compliance attestation
Date/time stamps with audit-trail rigor

This level is heavy. It's appropriate where audit defensibility is critical. It's not appropriate for routine work.

The mistake to avoid: Skipping Tier B logging because Tier C feels like overkill. Tier A or B is right for most work; the absence of any logging is the problem, not the level.

04 · The compliance regimes you're likely operating under

Quick survey of the regulatory regimes that may affect your AI documentation requirements:

GCP (Good Clinical Practice — ICH-E6)

GCP requires documentation of how clinical trial work was done, by whom, and with what verification. AI-assisted work performed in a GCP-relevant context (protocol development, monitoring, safety processing, CSR drafting) inherits these requirements.

Implication: Anything AI-touched in clinical work should be logged at Tier B minimum, Tier C if it directly contributes to regulatory submissions.

GxP (broader Good Practice — manufacturing, lab, distribution)

GxP frameworks generally require traceability of changes to validated processes. AI use that affects validated workflows (e.g., AI-suggested changes to manufacturing parameters, AI-generated batch records) requires formal documentation.

Implication: In GxP contexts, treat any AI involvement as requiring Tier C documentation by default.

21 CFR Part 11 (electronic records)

FDA's regulations on electronic records require specific controls (audit trails, electronic signatures, change tracking). AI-generated content in a Part 11 record inherits these requirements.

Implication: AI use in any Part 11 system must be documented as the system requires. The system itself should be designed to capture this; if it isn't, raise it.

Data Privacy (HIPAA, GDPR, equivalents)

Privacy regimes don't usually mandate AI-use documentation directly, but they require documentation of data flows (which include AI processing).

Implication: AI processing of regulated personal data must be logged as part of your data-flow documentation. Privacy Impact Assessments may be required for new AI workflows.

Sponsor / partner contracts

Contracts (CDAs, master services agreements, collaboration agreements) often have provisions about confidentiality and data use that affect AI documentation.

Implication: Read the contracts for the work you do. Some explicitly require documenting AI involvement; others implicitly require it via more general confidentiality clauses.

Industry-specific guidance

ICH (especially the M4 guidance on submissions), FDA reflection papers on AI, EMA's draft AI guidance, and various professional society documents are increasingly addressing AI use in biotech.

Implication: Subscribe to a few key sources (FDA AI/ML pages, EMA AI updates, your industry trade groups) to stay current. Standards are evolving.

05 · The "demonstrate" mindset

A useful mental shift: don't think of documentation as "covering yourself." Think of it as demonstrating something — to a colleague, an auditor, your future self.

Demonstrate what?

That you understood the data classification
That you selected an appropriate tool
That you verified the output appropriately
That you exercised judgment
That you have a defensible reason for what you did

When you write documentation in this frame, it has a different quality. It's not bureaucratic — it's narrative. You're telling the story of how the work was done, in a way that demonstrates competence.

A two-paragraph documentation in this style beats a checked-box compliance document for actual audit defensibility.

06 · Common documentation failures

The five most frequent documentation failures, and how to avoid them.

Failure 1 — No documentation at all

Most common. People use AI productively, ship the output, and never document the AI involvement. When someone asks later, "did you use AI for this?", they can't reliably reconstruct.

Prevention: Build a documentation step into your workflow. The artifact isn't done until the logging is done.

Failure 2 — Documentation in a separate place from the artifact

You log AI use in a personal notes app or a separate spreadsheet. The artifact lives in SharePoint. Three years later, when the artifact is reviewed, the documentation has been lost or detached.

Prevention: Keep documentation with the artifact. Version history. Metadata. A companion log file in the same folder. Whatever — but co-located.

Failure 3 — Documentation that's too vague to be useful

"AI was used in drafting." Useful: not at all. Doesn't say which AI, when, how, what was verified.

Prevention: Include the five things to log (Section 02). Don't shortcut.

Failure 4 — Documentation written defensively rather than honestly

"I verified all aspects of the AI output thoroughly." Sounds like it was written by a lawyer, not a practitioner. Reads as performative.

Prevention: Write what you actually did, not what you wish you'd done. Honest documentation of partial verification is more useful than dishonest documentation of complete verification.

Failure 5 — Documentation that doesn't match the work

The documentation says "AI provided initial draft; author revised extensively." The actual work was "author wrote prompt, AI produced draft, author sent draft with minimal revision." This mismatch is worse than no documentation.

Prevention: Document the actual work. If your actual work involved less revision than you're comfortable with documenting, the issue is the work, not the documentation. Fix the work.

07 · A documentation template

A starting template you can adapt for your context:

=== AI USE DOCUMENTATION ===

Artifact: [Filename or document title]
Author: [Your name]
Date completed: [Date]

AI Tool: [Specific tool, model, version]
Environment: [Specific environment / configuration]
Date(s) of AI use: [Date]

Inputs provided to AI:
- [Item 1]
- [Item 2]
- [Item 3]

Outputs received from AI:
- [Summary of what AI produced]

Verification performed:
- [What you checked]
- [What you found and corrected]

Revisions made before finalization:
- [Summary of changes from AI output to final]

Data classification: [Tier and reasoning]
Tool appropriateness: [Why this tool was appropriate for this tier]

Reviewer (if applicable): [Name]
Review date: [Date]

==========================

Adapt this. Strip it down for lightweight logging. Expand it for formal documentation. The key elements are the five Section 02 items plus classification and reviewer info.

08 · The audit-ready habit

A specific framing that helps: imagine you've just received notice that a regulatory inspection is coming next month, and the inspector will look at five randomly selected pieces of your work from the past year.

Question: Could you produce, for each randomly selected piece, a clear narrative of what AI did and what you did?

If yes: your documentation habits are good.

If no: build the habits now, while the cost is low.

This isn't paranoia. AI-related inspection findings are increasing in frequency in the industry. The biotechs being inspected aren't being penalized for using AI — they're being penalized for not being able to demonstrate that they used it responsibly.

The simple discipline of logging Tier B for every meaningful AI-assisted artifact protects against this. It takes a few minutes per artifact. It pays for itself the first time an audit happens.

09 · A note on prompt confidentiality

One more topic that comes up: are the prompts themselves confidential?

Generally: The prompts you write are your intellectual property. The library of well-crafted prompts you've developed is a meaningful asset.

Implications:

Treat prompt libraries as Tier 2 or Tier 3 internal content (depending on how strategic they are)
Be careful about sharing prompts in public forums (LinkedIn, conference talks, etc.) — you may be giving away competitive advantage
Within your company, consider building a shared prompt library that's accessible to colleagues but not external parties

But: When you're documenting AI use, don't withhold the prompt structure because you consider the prompts confidential. The documentation can describe the prompt without exposing it verbatim ("Prompt structure: role-defined as senior regulatory writer, task to review section for completeness, format constraints for findings...").

This balance — sharing enough to demonstrate competent use without exposing your IP — gets easier with practice.

10 · Knowledge check

Three questions to lock in this lesson.

Q1. Which of these is the most accurate statement about AI use documentation in biotech?

a) Documentation is only required for regulatory submissions b) Documentation requirements are well-defined and consistent across the industry c) Documentation requirements are evolving; the right posture is to document thoroughly enough that future requirements can likely be satisfied retroactively d) Documentation is optional for AI-assisted work

Q2. What are the five things you should typically log for AI-assisted work product?

a) Tool/model, environment, date, inputs/outputs summary, verification/revision history b) Cost, time saved, tool name, output, signature c) Author, reviewer, date, tool, version d) Only the tool name and date

Q3. Which is the most common documentation failure to avoid?

a) Over-documenting routine work b) No documentation at all — many people use AI productively without leaving any record c) Documenting too thoroughly d) Using the wrong format

Answers: Q1: c · Q2: a · Q3: b

11 · You've finished Module 03

Congratulations — you've completed the governance module.

What you can now do:

Recognize bright-line situations (data and uses that never involve AI)
Classify any data into one of five tiers
Match data tiers to appropriate AI environments
Reason through gray-zone cases using structured frameworks
Document AI use thoroughly enough to be defensible later

What this means for the rest of the curriculum:

You're now cleared to proceed to your role-specific path module (Module 04A through 04AB, depending on your role). The role-specific modules will build on everything you've learned in Modules 01-03.

The role-specific modules will assume:

You know how to write specifications (Module 02)
You verify AI output as a habit (Modules 01, 03)
You design simple workflows rather than fire off one-off prompts (Modules 02, 03)
You select tools appropriately (Module 03)
You make compliant decisions automatically (Module 03)

If any of those feels weak, revisit the relevant lesson before starting your role path.

12 · What's next

Your role path is next. Find the module that matches your role from the curriculum catalog:

04A — Bench R&D / Lab Scientist
04B — Computational Biology / Bioinformatics
04C — Translational Science
04D — Clinical Operations
04E — Clinical Development
04F — Biostatistics & Data Management
04G — Regulatory Affairs
04H — Medical Writing
04I — Pharmacovigilance & Drug Safety
04J — Quality Assurance / Quality Control
04K — CMC & Manufacturing
04L — Field Medical (MSL)
04M — In-house Medical Affairs / Medical Information
04N — Brand Marketing
04O — Commercial Operations & Analytics
04P — Market Access & HEOR
04Q-04U — Sales paths (Specialty, Oncology, Rare Disease, Ultra-Rare, Buy-and-Bill)
04V — Executive Leadership
04W — Business Development & Strategy
04X — Finance & Accounting
04Y — Legal / Corporate Counsel
04Z — IP / Patent Strategy
04AA — HR / People Operations
04AB — IT Operations
04AC — InfoSec / CISO

After your role path, all learners return for the advanced modules (05 through 10).

End of Module 03.