How to Write a Workplace AI Pilot Charter

How to Write a Workplace AI Pilot Charter

A workplace AI pilot charter defines one task, accountable owner, participants, worker input, approved system and data, baseline, acceptance standard, measures, prohibited uses, incident path, stop conditions, rollback, decision date, and closeout before the test begins.

The charter prevents a temporary experiment from becoming a quiet rollout, surveillance program, performance-management system, or permanent automation.

flowchart TD
    A["Business question and one task"] --> B["Owner, participants, and affected people"]
    B --> C["Approved system, data, and non-goals"]
    C --> D["Baseline, cases, acceptance, and review"]
    D --> E["Measures, incidents, stop rules, and rollback"]
    E --> F["Time-boxed pilot"]
    F --> G{"Dated closeout"}
    G --> H["Approve exact use"]
    G --> I["Narrow and retest"]
    G --> J["Pause or decommission"]

State the business question

The charter should answer one decision.

"Should the project team use the approved AI feature to draft weekly internal status updates from authorized project records?" can produce evidence. "How can we use AI across the business?" cannot.

Name the current problem, affected outcome, existing process, and why a pilot is needed. State what the pilot will not decide.

Do not use a pilot to avoid a procurement, privacy, security, accessibility, labor, employment, records, legal, or policy decision that should already have happened.

Freeze one task and its non-goals

Write the trigger, input, action, output, reviewer, destination, and acceptance standard.

Then name adjacent uses that are prohibited during the pilot. A meeting-note test may exclude employee evaluation, customer commitments, legal records, contract interpretation, and enterprise search. A drafting pilot may exclude direct sending, public publication, and use of unapproved sources.

Scope should not expand because a feature appears in the same product or a participant finds another convenient use. Each new task has its own consequence and data boundary.

E019's [[How to Choose a First Workplace AI Task]] provides the selection gate. E042's [[How to Run a Bounded Workplace AI Pilot]] owns the full operating method after the charter is approved.

Name ownership and decision rights

The accountable owner controls purpose, scope, configuration, participant instructions, evidence, incidents, stop decisions, and the final recommendation.

Supporting roles may include the worker performing the task, process owner, data owner, domain reviewer, security, privacy, legal, records, accessibility, labor, procurement, IT, finance, and affected representatives. The right set depends on the task.

Use names or accountable roles, not "the business" or "the team." State who can pause the pilot, who investigates an incident, who approves a change, who owns the baseline, and who makes the closeout decision.

The NIST AI RMF Core calls for defined roles, purpose, context, human oversight, measurement, feedback, third-party risk, incident handling, recovery, and decommissioning. A charter can translate those voluntary outcomes into a small test.

Involve people who perform and receive the work

Workers can identify missing steps, judgment, workarounds, accessibility needs, peak periods, emotional labor, correction burden, and impacts a buyer may not see.

Ask them to review the current workflow, success definition, harmful failure, measures, training, feedback method, and stop conditions. Include people who receive the output and people who may be affected by errors.

State whether participation is voluntary or required, how selection occurs, what time is allocated, how support works, and how concerns can be reported without retaliation.

Do not treat prompt volume or feature usage as productivity. Do not repurpose pilot logs for individual performance management unless that use has a separate lawful, necessary, disclosed, reviewed, and authorized basis.

The EEOC and Department of Justice have warned about disability discrimination from AI and software in employment. Accessibility and accommodation should be considered before participation and evaluation.

Specify the technical and data boundary

Record the exact product, plan, tenant, account, feature, model if visible, configuration, user roles, connected sources, region, contract, documentation date, administrator settings, logging, retention, and output destination.

State the allowed data classes and prohibited data. Identify the source owner and approval. Explain how participants should handle an accidental disclosure or uncertain classification.

[[How to Set a Workplace AI Data Boundary]] provides the full map. The charter should link the approved matrix rather than recreating vague warnings.

Temporary access should have an expiration and removal owner. Test accounts, connectors, files, and exports need a closeout path.

Preserve the baseline and cases

Define accepted work and measure the current process before the pilot.

Include active effort, elapsed time, quality, material error, review, rework, support, and worker experience. Use representative ordinary and difficult cases. Include missing sources, contradictions, access restrictions, unusual terminology, and a case where the correct behavior is to abstain or escalate.

The pilot should use the same completion standard as the baseline. A generated draft is not equivalent to an approved record.

Record sample size and time box. Do not choose only polished examples that make the system look capable.

Define acceptance, review, and escalation

Name the reviewer and the evidence available to them. State the checks for factual support, calculations, completeness, permissions, uncertainty, accessibility, and downstream fit.

Use four decision states for each material output: accept, revise, reject, or escalate. Record material corrections and review time.

[[How to Review AI Output Before It Enters Real Work]] provides the acceptance protocol. The charter should identify high-consequence work that remains outside the pilot regardless of review.

Human oversight is not adequate when the reviewer lacks authority, capacity, source access, or domain competence.

Choose measures before seeing results

The scorecard should compare accepted outcomes and full effort. Include quality, source support, correction, rework, harmful failure, review burden, support, worker impact, accessibility, access behavior, and total cost.

Do not make usage the primary outcome. High usage can reflect novelty, mandate, poor first drafts, or repeated failure.

State how worker feedback will affect the decision. Preserve dissent and subgroup variation when it is safe and appropriate. An average can hide that the tool helps experienced workers, burdens novices, or creates an inaccessible process for some participants.

[[How to Measure Workplace AI Productivity Without Inventing ROI]] provides the matched comparison.

Write stop conditions and rollback

Stop conditions should be observable and tied to consequence.

Examples can include restricted-data exposure, discriminatory or harmful output, use outside the approved task, inability to reproduce required evidence, lost records, repeated source failure, inaccessible operation, an uncontained incident, or unavailable reviewer capacity.

State who can invoke the stop, how participants are notified, how access is restricted, how outputs are contained, how downstream records are corrected, and how the prior process resumes.

The NIST Generative AI Profile can inform task-specific tests for confabulation, privacy, information integrity, harmful bias, intellectual property, and overreliance. The charter still needs observable thresholds for the actual use.

A stop is a valid pilot result. It means the tested combination of task, system, configuration, data, workflow, people, and controls is not ready.

Set the closeout before the start

Choose a review date and four possible decisions: approve the exact use with controls, narrow and retest, pause pending a named change, or stop and decommission.

Approval should preserve the users, task, data, configuration, sources, review, monitoring, incident process, owner, and refresh trigger. It is not blanket permission for adjacent features or uses.

Closeout should address temporary accounts, connectors, participant data, logs, exports, retained evidence, source files, incident follow-up, corrected records, contracts, and support materials.

Record what the pilot could not establish. A short test may not reveal seasonal volume, long-term skill effects, model drift, rare failures, vendor changes, or organization-wide impact.

Use a charter table

The charter should be understandable to the people doing the work. If it requires a governance specialist to explain what workers may do tomorrow, it is not finished.

The pilot is ready when the organization can explain the task, boundary, evidence, responsibility, and exit before anyone uses real work data.

This guide was developed with AI assistance from the preserved E019 transcript, the linked charter record, and current NIST and EEOC sources. Dalton Anderson remains the author. It is not legal, employment, labor, privacy, security, accessibility, procurement, records, or governance advice. Worker, labor, accessibility, legal, privacy, security, domain, policy, source, and founder review are required before publication. Publication is not authorized.