Founder Operator Library

Checklist grounded in a published framework

An AI Delegation Checklist for Operators

Delegate a task to an AI system only after you can answer four things: how a wrong output would be noticed, who reviews it before it reaches anyone outside the team, how the decision is reversed, and whether the use has to be disclosed. If any of the four has no answer, the task is not ready to delegate yet.

What this page recommends

Run the checklist below against one recurring task before you automate it, and map your answers onto the NIST AI Risk Management Framework rather than an internal maturity model.

Short answer

Delegate a task to an AI system only after you can answer four things: how a wrong output would be noticed, who reviews it before it reaches anyone outside the team, how the decision is reversed, and whether the use has to be disclosed. If any of the four has no answer, the task is not ready to delegate yet.

Why delegation, not adoption, is the unit of decision

Most AI failures inside small teams are not model failures. They are delegation failures: a task moved to a system without anyone deciding who still owns the outcome. The tool worked exactly as designed and produced something nobody checked.

That makes the recurring task, not the tool, the right unit to reason about. A single model can be entirely appropriate for drafting an internal summary and entirely inappropriate for answering a customer, and no tool-level policy captures that difference.

There is a published, non-commercial framework for this. The National Institute of Standards and Technology released the AI Risk Management Framework 1.0 on 26 January 2023, developed through an open, consensus-driven process, and intended for voluntary use. NIST also publishes a companion Playbook. Using it has one practical advantage over a vendor's maturity model: nobody selling you anything wrote it.

The checklist

Work through this for one task at a time. A task that fails any single item is not blocked forever; it is blocked until that item has an answer.

  1. Name the task in one sentence, including who currently does it and how often.
  2. Describe what a wrong output looks like. If you cannot describe it, you cannot detect it.
  3. Say how a wrong output would be noticed, and by whom, before it causes harm.
  4. Name the reviewer. A named person, not a role that nobody currently fills.
  5. State the reversal path: how a wrong result gets undone, and how long that takes.
  6. Decide whether the output leaves the team. Anything customer-facing needs a higher bar.
  7. Check whether the use requires disclosure to a customer, a client, or a platform.
  8. Confirm what data the system sees, and whether any of it belongs to someone else.
  9. Write down the stop condition: what would make you take this task back.
  10. Re-run this list when the task changes, not on a calendar.

Four delegation tiers and what each requires

A useful shorthand once the checklist has been run once. The tier is set by where the output goes, not by how sophisticated the tool is.

TierExample taskReview before releaseDisclosure question
Draft onlySummarising an internal meeting for the teamAuthor reads it; no second reviewer neededNone, provided no external data is involved
Internal decision supportRanking inbound leads for a human to work throughReviewer spot-checks a sample each weekNone externally, but record the method internally
Customer-facing with reviewDrafting a reply that a person sendsNamed person reads every output before it sendsCheck platform and contract terms
Customer-facing autonomousA system that replies without a person in the loopSampling plus a logged escalation pathAssume disclosure is required until confirmed otherwise

The disclosure item is the one most often skipped

Operators tend to treat disclosure as a legal question to resolve later. In marketing contexts it is often already settled: the Federal Trade Commission publishes guidance on endorsements and testimonials that applies to how a message is presented regardless of how it was produced, and a claim does not become exempt because a model drafted it.

The practical version of this item is short. If the output makes a claim about a product, carries an endorsement, or presents itself as a person's own view, read the FTC guidance before it ships rather than after.

Sources

The published frameworks and guidance behind this checklist:

These are independent sources. They are not affiliated with this publication and nothing was paid for their inclusion. Requirements change; confirm the current text at the source before relying on it.

Related resources

Affiliated projects covering operator decision-making:

Questions people ask about delegating work to AI

Is the NIST AI RMF mandatory?

No. NIST states the framework is intended for voluntary use. Its value is that it is a published, independently developed reference, which makes it a better shared vocabulary than an internal scheme or a vendor's model.

What if nobody on the team can review the output?

Then the task is not ready to delegate. A task with no competent reviewer is a task where errors will be found by a customer, which is the most expensive place to find them.

How often should the checklist be re-run?

When the task changes, when the tool changes materially, or when a failure occurs. A fixed calendar review tends to become a formality.

Does disclosure mean labelling everything?

Not necessarily, and the answer depends on context and jurisdiction. The checklist item is to establish the answer deliberately rather than by default, starting with the FTC guidance where marketing claims are involved.

Editorial boundary

This is a general operating checklist. It is not a compliance assessment, and it does not tell you whether a particular AI use is lawful in your jurisdiction or industry.

This page is informational. It is not legal, medical, mental-health, immigration, financial, or professional advice.