THE SHORT ANSWER
An AI pilot needs a written charter before the team connects tools. It should specify the task under investigation, who will use its outputs and which actions remain outside scope. A charter does not prevent every failure. It makes sure participants investigate the same question and can assess results consistently afterwards. Write it concretely enough that another colleague could take over the experiment without reconstructing every conversation that led to its creation.
To connect individual AI applications with reliable marketing operations, read the pillar guide AI transformation in B2B marketing: from individual prompts to reliable operations.
State an improvement you can examine
Replace a broad ambition such as productivity with an observable improvement. For example, a research draft should include relevant primary sources and unresolved questions while requiring less expert rework. Separate the desired work product from an expected commercial effect. A better draft does not establish incremental revenue. Specify which evidence will support a decision and which claims the pilot does not investigate. This prevents a narrow experiment from later being presented as proof of a much broader transformation that was never actually tested.
Bound inputs and participants
List permitted document types, languages, data domains and participating roles. Marketing data is too broad if it covers confidential customer details alongside public product pages. Explain how inputs enter the process and who approves their use. Include situations in which the system should produce no substantive output. A limited user group makes feedback easier to attribute. It does not automatically create low risk: one participant can still trigger a consequential action if the system has the necessary access. Scope must cover capabilities as well as headcount. Explore this further in the guide Read, draft, change: permissions for marketing agents.
Define outputs and excluded actions
Describe a reviewable work product, such as an internal table containing claims, sources, uncertainty and review status. State separately whether the system may read, create drafts or modify records. Preparing a message does not authorise sending it. When tools technically permit changes, boundaries should also be enforced at that layer. A prompt instruction alone is an insufficient control. The charter should therefore reference the actual permission configuration and name the person responsible for checking it before any work begins.
Agree tests before implementation
Collect ordinary tasks and difficult exceptions: absent information, conflicting sources and prohibited action requests. For each, write down acceptable behaviour. Examine both the response and potential changes in the destination system. An agent can say that a task is complete while the actual change is missing. Define which failures prevent launch and which may initially be observed. These limits should fit the work at hand; a generic success percentage borrowed from another project cannot replace an accountable decision about your own use case. Explore this further in the guide Bounding agents: runtime, tool calls and stopping.
Expose effort and responsibility
Include source maintenance, expert review and error handling alongside implementation and model usage. Establish who handles daily operation and who may stop the experiment. A supportive sponsor is not automatically the eventual operator. Set a review point and define the manual fallback. Without these arrangements, an experiment can become a permanent exception with uncertain value and maintenance assigned by default to the most technically interested employees. Capacity for operating the process should be an explicit commitment rather than a hope that someone will find time.
Use a hypothetical boundary test
A fictional IT service software company wants to prepare internal product questions for expert review. Its pilot reads approved manuals, classifies questions and produces evidenced answer drafts. It neither edits manuals nor sends answers. A question concerning an unreleased version goes to the product owner. This is an illustrative scenario rather than a client result. It shows how a charter constrains the task and how a difficult case requires an operational decision before implementation, instead of leaving the model to infer an acceptable boundary.
Choose continuation, revision or retirement
The closing review should compare the initial charter with observed results. Were the agreed cases tested sufficiently, what rework appeared, and which prerequisites are still missing? Adjusting the input or ending the experiment can both be useful outcomes. Expanding autonomy requires a revised charter with suitable controls. Avoid letting the pilot continue silently beyond its review point. The charter serves its purpose when an accountable person makes a reasoned decision, records the evidence and shares the outcome with colleagues affected by the next step.
INTERACTIVE / FROM READING TO ACTION
Three checkpoints for your implementation
Choose a checkpoint and track your reading progress. Checks are neither saved nor sent and do not score your business.
CHECKPOINT 01
Define outputs and excluded actions
Describe a reviewable work product, such as an internal table containing claims, sources, uncertainty and review status.
Explore in the article ↗CHECKPOINT 02
Agree tests before implementation
Collect ordinary tasks and difficult exceptions: absent information, conflicting sources and prohibited action requests.
Explore in the article ↗CHECKPOINT 03
Expose effort and responsibility
Include source maintenance, expert review and error handling alongside implementation and model usage.
Explore in the article ↗Frequently asked questions
Does the charter need to be long?
No. Clear inputs, outputs, boundaries, ownership and decision criteria matter more than length.
Can a pilot send external messages?
Only when that capability is explicitly scoped, technically constrained and appropriately reviewed.
What if the pilot provides little value?
Retire or revise it. Preserve the findings so the same approach is not repeated without a reason.
How can I put “State an improvement you can examine” into practice?
Replace a broad ambition such as productivity with an observable improvement. For example, a research draft should include relevant primary sources and unresolved questions while requiring less expert rework. Separate the desired work product from an expected commercial effect.
What matters when working on “Bound inputs and participants”?
List permitted document types, languages, data domains and participating roles. Marketing data is too broad if it covers confidential customer details alongside public product pages. Explain how inputs enter the process and who approves their use.
