What Should an AI Side-Project Client Tracker Record From First Contact Through Final Invoice?

Short answer: Record the minimum information needed to understand the relationship, define the work, review AI-assisted outputs, communicate decisions, issue an invoice, and resolve post-delivery questions. A useful tracker is a chronological project record—not a legal-compliance system and not a substitute for professional tax, privacy, or contract advice.

For a solo AI freelancer, the simplest reliable design is one project record with linked notes, files, and status changes. Capture what was requested, what was agreed, which tools and model versions were used, what data was permitted, who reviewed the output, what limitations were disclosed, what was approved, and what happened after delivery. Keep sensitive information out unless it is genuinely necessary.

Why an AI project needs more than a normal contact list

A basic CRM can tell you a prospect's name and the last time you contacted them. An AI side-project tracker also needs enough context to reproduce or evaluate a deliverable. The FTC has warned that AI providers must honor their privacy and confidentiality commitments, including promises about how customer data is used; it also notes that material omissions about data collection or use can matter. [1] That does not mean your spreadsheet creates compliance, but it does make tool, data-use, and permission notes sensible operational controls.

NIST describes its AI Risk Management Framework as voluntary guidance for incorporating trustworthiness considerations into the design, development, use, and evaluation of AI systems. [2] A lightweight tracker can borrow that mindset: identify the use case, record foreseeable risks, apply human review, and keep evidence of important decisions. The goal is traceability, not paperwork for its own sake.

The core record: fields to capture from first contact to closeout

1. Contact and intake

Start with a project ID, date received, contact name, organization, preferred channel, and a short description of the request. Add the source of the inquiry and the next action, but avoid copying an entire email thread into a general-purpose database. If a message contains confidential material, store a reference to the approved location rather than duplicating it.

At intake, record the intended user of the output and the context in which it will be used. “Draft internal product FAQ” is materially different from “automated advice shown to the public.” Add an initial output-risk level: low for brainstorming or formatting, medium for customer-facing content requiring review, and high for outputs that could affect health, safety, employment, eligibility, legal rights, or other consequential decisions. A high rating should trigger a pause and qualified review rather than an assumption that a tracker makes the work safe.

2. Requirements and scope

Translate the conversation into testable requirements. Record the deliverable, format, audience, source materials, exclusions, target milestones, number of review rounds, acceptance signals, and the person authorized to approve. Use plain language and mark each requirement as confirmed, open, or out of scope.

Keep a separate assumptions and questions section. Examples include whether the client owns or is authorized to provide source material, whether personal or confidential data will be supplied, whether the work is advisory or merely drafting, and whether a human must review every output before use. Do not infer consent from silence. Ask the client to confirm the relevant permission or approved data-handling path, and record the date and channel of that confirmation.

3. AI-specific method notes

For each material output, record the tool or provider, model name or version when visible, date used, major configuration or workflow, source set, and whether an external retrieval step was used. A prompt archive can be useful, but do not automatically retain raw prompts if they contain unnecessary personal, proprietary, or confidential information. Store a redacted prompt, a short method summary, or a secure reference where that is sufficient.

Add three fields that are easy to overlook. First, record data-use permission: what material was approved for processing, by whom, and for what stated purpose. Second, record the human reviewer and the review date. Third, record an evidence link for claims that need checking, such as a client-provided source, official documentation, test result, or revision note. These fields distinguish an AI-assisted draft from an unexamined output.

4. Risk, limitations, and approvals

Write a short risk note in ordinary language: what could go wrong, who could be affected, and what check reduces the risk. For example, a generated summary may omit context, so the reviewer compares it with the approved source set. A classification prototype may produce inconsistent labels, so the record includes test cases and a human escalation path.

Record limitations acknowledged by the client or reviewer, such as incomplete source material, uncertain model behavior, unsupported claims, or a boundary against using the output for a high-stakes decision. Then capture approval as a dated event: version reviewed, comments resolved, approver identity or role, and whether approval covers the draft, the production release, or only a limited test. An approval record is evidence of a decision; it is not a guarantee of accuracy, legality, or suitability.

5. Delivery, invoice, and post-delivery issues

At delivery, record the version delivered, delivery date, destination, handoff instructions, and any remaining limitations. Link the final artifact rather than scattering copies across personal devices. If revisions follow, use version numbers and a brief change log so that a later reader can tell which file was accepted.

For the invoice stage, record invoice identifier, issue date, amount and currency as shown on the invoice, status, payment-channel reference, and the date the invoice was marked paid or disputed. Do not treat this article as tax or accounting advice: retention periods, invoice content, and bookkeeping treatment depend on the applicable rules and your circumstances. The IRS says business records help identify income sources, track expenses, prepare returns, and support items reported on returns. [3] Use current IRS guidance and a qualified tax professional for your own obligations.

Close the record with a post-delivery window, issue log, resolution, and final status. “No further action,” “revision requested,” and “escalated for specialist review” are more useful than deleting the project because the invoice was sent. Keep only what you need, restrict access, and define a deletion or archival review. A tracker that accumulates every document forever can create avoidable exposure.

A practical workflow with human checkpoints

1. Intake: Create the project ID and write the request in one sentence. Do not paste unnecessary sensitive content.
2. Qualification: Identify intended use, data types, output-risk level, decision-maker, and unanswered questions. Pause high-risk work until the right human or professional is involved.
3. Scope confirmation: Convert the request into deliverables, exclusions, milestones, review rounds, and an approval owner. Mark assumptions explicitly.
4. Method setup: Log the approved tool and model information, permitted source material, data-use boundary, and the test or review plan.
5. Production: Save a concise method note, evidence links, output version, and exceptions. Redact or omit data that the project does not need.
6. Human review: Have the named reviewer check factual support, limitations, format, and the intended use. Record defects and resolutions, not just “approved.”
7. Delivery and billing: Record the delivered version, handoff, invoice identifier, and status. Keep financial records in the system intended for them, with appropriate access controls.
8. Closeout: Log post-delivery issues, final resolution, retention or deletion decision, and a short lesson for the next project.

Original decision tool: the minimum-record test

Before adding a field, ask five questions. Purpose: what decision or action will this field support? Necessity: can the same purpose be met with less information? Permission: is the source and intended use clear? Review: who will check the field or the output it describes? Exit: when will it be archived, corrected, or deleted? Keep the field only when you can answer all five. This is an operational checklist, not a legal test.

For a quick go/no-go check, score each item as yes or no: the request has a defined user; the deliverable and exclusions are written; data sources and permissions are identified; the output-risk level is assigned; a human reviewer is named; evidence links exist for material claims; limitations are stated; the delivered version is identifiable; invoice status is separated from project approval; and a retention or deletion review is scheduled. Any “no” should become a tracked question, not an invisible assumption.

Common mistakes to avoid

The first mistake is turning the tracker into a warehouse for raw client data. The second is recording a model name without recording the source set, reviewer, or limitation. The third is treating a client’s approval as proof that an AI output is correct for every use. The fourth is mixing project status, invoice status, and issue status into one label. The fifth is using generic “consent obtained” language without saying what was permitted and when.

Finally, do not promise that recordkeeping ensures privacy, compliance, payment, client satisfaction, or project success. It improves visibility and makes follow-up easier, but the quality of the system depends on accurate entries, appropriate access, current primary rules, and qualified judgment.

Sources and further reading

1. Federal Trade Commission, “AI Companies: Uphold Your Privacy and Confidentiality Commitments.”
2. National Institute of Standards and Technology, “AI Risk Management Framework.”
3. Internal Revenue Service, “Why should I keep records?”
4. Internal Revenue Service, Publication 583, “Starting a Business and Keeping Records.”