A checklist earns its keep when you can run it during a real rollout and have it catch the thing you would have forgotten. This one is built that way. Every item is something you can verify as done or not done, and every item carries a one-line justification so you know why it is on the list rather than just trusting it.
Work through it in order. The early items are prerequisites that the later items depend on, so skipping ahead tends to produce the failures the list exists to prevent. Where an item does not apply to your stakes, mark it deliberately rather than ignoring it, because the act of deciding is itself a guardrail.
Treat the checklist as a living document. After your first quarter with the assistant, revisit each item and note what you would change. The version you finish with will fit your team better than the one you start with, and that drift is the point.
Before You Switch It On
Scope and Authority
- Write a one-paragraph charter naming what the assistant drafts, watches, and never touches, because every later check depends on knowing its job.
- Draw an explicit authority line listing autonomous versus human-gated actions, since accountability cannot be delegated to a tool.
- Identify one named owner of the assistant's configuration, because a tool nobody owns drifts without anyone noticing.
- Decide what happens when the assistant is unavailable, because a team that has fully offloaded a task to a down tool is stuck until someone remembers how to do it by hand.
Data Readiness
- Define a ticket contract: required owner, real due date, meaningful status, because the assistant inherits your input quality.
- Audit a random sample of twenty tickets against that contract, since a clean sample predicts trustworthy summaries and a messy one predicts fluent nonsense.
The reasoning behind these prerequisites is argued at length in Best Practices That Hold Up When AI Runs Your Projects.
During the Pilot
Choose the Right First Job
- Start with a low-risk task like a channel digest where a wrong output costs a skim, not a client relationship.
- Recruit one skeptical pilot user, because a critic's error log teaches more than an enthusiast's approval.
Instrument From Day One
- Pick one outcome the pilot should move, such as report-writing time, so you can tell signal from activity.
- Log every output the pilot user corrects, because the correction pattern is your real training data.
Picking the right first job is half the battle, as the scenarios in Real Scenarios Where AI Project Assistants Earned Their Keep show.
Before Anything Reaches a Client
Review Gates
- Require human review on every client-facing draft, because the model cannot see tone, politics, or relationship history.
- Confirm risk flags show their underlying evidence, since an unauditable verdict gets dismissed the first time it is wrong.
Notification Discipline
- Replace any live feed with a role-tuned digest, because a feed of every change trains people to filter the assistant out.
After the Rollout Stabilizes
Ongoing Hygiene
- Schedule a weekly spot-check of one generated summary against its source, because drift is invisible until you measure it.
- Re-audit accuracy immediately after any vendor or model update, since behavior can change without warning.
Honest Measurement
- Tie each enabled feature to a named outcome, and retire any feature you cannot connect to one.
- Review the charter and authority line quarterly, because scope creeps quietly when nobody revisits it.
- Confirm at least one person can still perform each offloaded task manually, because skills the assistant absorbs decay until the day you suddenly need them back.
How to instrument the outcomes above is covered in Reading the Numbers That Show an AI Assistant Is Working, and the trade-offs between feed and digest in How to Decide Between Competing AI Project Management Approaches.
Adapting the List to a Second Project
Carry Forward What You Learned
The first time through, the checklist is generic. By the second project, you should be folding in your own discoveries: the specific ticket field your team keeps leaving blank, the notification that always gets muted, the kind of risk flag your assistant tends to miss. Each becomes a checked item tailored to how your tools actually behave, which is far more valuable than the generic version.
Keep the Charter and the List in Sync
When you revise the assistant's charter, revise the checklist to match. The two documents describe the same boundaries from different angles, and they drift apart if maintained separately. A checklist that still gates a capability the charter has since removed wastes effort, and a charter that grants a capability the checklist never vetted creates exactly the kind of unreviewed authority that causes incidents. Treat them as one artifact in two formats, updated together.
How to Use This Checklist
Run It as a Gate, Not a Reference
The temptation is to read the list once and feel prepared. Resist it. The value comes from physically checking each item against your setup at the moment it applies, because the gaps you would have rationalized away are exactly the ones a gate catches. A practical way to enforce this is to assign each section an owner and a date, so that no rollout phase begins until the prior section's items are signed off. The owner does not have to do the work, but they do have to confirm it happened. That single accountability step is what separates a checklist that shapes behavior from one that decorates a wiki page nobody opens twice.
Adapt the Severity to Your Stakes
A team managing internal projects can run a lighter version than an agency managing client revenue. Decide the severity on purpose. A skipped item should be a recorded decision, not an oversight, so that when something breaks you know whether the checklist failed or you did.
The recorded-decision habit pays off most during a post-incident review. When something goes wrong with the assistant, the first question is always whether the team knew the risk and accepted it or simply missed it. A checklist with deliberate skip annotations answers that instantly: you can see that the team consciously chose to forgo, say, the cross-tool audit because their work lived in one system, or that they overlooked it entirely. The former is a reasonable bet that happened to lose; the latter is a process gap to close. Without the annotations, every incident dissolves into finger-pointing, and the same gap reopens on the next project because nobody can prove it was ever there.
Frequently Asked Questions
Which checklist item matters most if I can only do one?
The charter. Naming what the assistant does, watches, and never touches makes every other item meaningful and prevents the scope creep that causes most failures. One paragraph, written before you switch the tool on.
Why audit twenty tickets specifically?
Twenty is a sample large enough to reveal systemic input problems and small enough to check in fifteen minutes. The exact number matters less than the habit of testing your data before trusting the assistant to summarize it.
Can I skip the pilot and roll out to everyone?
You can, and you will skip the cheapest place to learn. A pilot confines mistakes to one user and produces an error log you can fix before scaling. A full rollout makes every mistake public and harder to attribute.
How is this checklist different for 2026 versus earlier?
The fundamentals are stable, but model behavior now changes more often through vendor updates, which is why the post-update re-audit item carries more weight than it once did. Treat behavioral drift as a routine event, not a rare one.
What does a role-tuned digest actually require?
Decide which events each audience cares about and configure separate digests rather than one feed for all. A lead wants risk rollups; a contributor wants their own at-risk items. The work is in the configuration, not the tooling.
How often should I revisit the whole checklist?
Quarterly for the charter and feature-to-outcome items, and immediately after any vendor update for the accuracy items. The list is meant to evolve into your team's own version within a couple of cycles.
Key Takeaways
- Start with a charter and authority line; every later check depends on knowing the assistant's job.
- Define and audit a ticket contract before trusting any summary, because the tool inherits input quality.
- Pilot with a skeptic on a low-risk task, instrument one outcome, and log every correction.
- Gate all client-facing drafts behind human review and require risk flags to show their evidence.
- Schedule weekly spot-checks, re-audit after vendor updates, and tie every feature to a named outcome.