In this article
This article is about the operating structure around adoption. It is different from teaching a particular prompt or appointing an enthusiastic volunteer to answer every question.
Give AI adoption a problem owner
Choose a business problem before choosing a programme name. Someone must explain who experiences the problem, what a better result looks like and which constraints cannot be relaxed.
Ethan Mollick describes leadership, lab and crowd as complementary contributors. Peak Belt's practical recommendation is to connect strategic direction, specialist scrutiny and everyday testing around a small number of real workflows.
In a hypothetical service business, the problem might be inconsistent handover summaries between shifts. That is specific enough to investigate. “Become an AI-first company” does not tell a supervisor what to test on Tuesday.
Assign three kinds of responsibility
Leaders should provide direction and resources. Specialists should assess feasibility, information handling and evaluation. Users should reveal where the proposed workflow fits or clashes with daily work.
| Contributor | Useful question |
|---|---|
| Leadership sponsor | Is this outcome worth the effort and risk? |
| Specialist reviewer | What evidence and controls are required? |
| Frontline participant | Can this work with the inputs and interruptions we actually have? |
One person may fill several roles in a small organisation. Name the responsibilities anyway, so important questions do not disappear simply because there is no formal innovation team.
Invite the person who checks the output, not only the person who generates it. Their effort is part of the workflow's real cost.
Use one shared experiment brief
A common brief prevents each group from discussing a different version of the idea. Keep it short enough to read in a working meeting.
Include the current process, proposed change, approved data, expected benefit, review method, pilot boundary and decision date. Also state what would lead you to stop.
For the hypothetical handover experiment, the brief might specify that the tool may restructure synthetic notes but cannot assign ownership or mark an unresolved item complete. A supervisor checks every draft during the pilot.
The sponsor judges whether better handovers justify the work. The specialist checks data handling and test design. Frontline colleagues identify whether the output preserves the awkward details that matter on the next shift.
Build a route from observation to decision
Give participants a place to record a useful result, a failure and the circumstances. Review patterns rather than collecting isolated screenshots of impressive responses.
Suppose users report that the tool creates a tidy summary but repeatedly drops temporary workarounds. The specialist can add relevant tests, while the sponsor decides whether the proposed scope remains worthwhile.
Do not make staff negotiate individually with several departments to raise a concern. Name the person who receives the observation and the person who decides the next step.
NIST's AI Risk Management Framework is a useful reference for risk-aware adoption. The organisation still needs to translate it into specific responsibilities and decisions.
Make room for evidence that challenges the plan
A pilot should be allowed to show that a task is unsuitable. If only success stories are welcome, users may conceal the checking effort or the exceptions that make a workflow unreliable.
Ask participants what they had to repair, what they chose not to upload and which instructions were unclear. Treat those observations as design information.
Avoid forcing an organisation-wide rollout because a senior leader enjoyed a demonstration. A demonstration can justify a test; it cannot substitute for evidence about ordinary work.
Resolve disagreements through a visible trade-off
The groups may disagree for good reasons. Leaders may want a broad improvement, specialists may need a tighter scope and users may worry about preparation time. Bring the disagreement into the experiment brief instead of treating one group as an obstacle.
In the hypothetical handover pilot, a sponsor could request automatic summaries for every shift. Users may report that the source notes are inconsistent, while the specialist recommends testing one standard input first. A sensible next step is a narrower trial that answers whether the input can support a reliable draft.
Write down what the narrower trial can establish and what it cannot. Success with one team does not prove suitability across every location, language or operating pattern.
Use the decision meeting to allocate work as well as approve the idea. Who standardises the input? Who reviews the test? Who covers the user's time? A pilot with enthusiastic agreement but no resources can fail for reasons unrelated to AI capability.
This makes leadership, specialist review and frontline learning part of one accountable process. Each group contributes evidence the others cannot supply alone.
Close the loop with a practical decision
At the pilot review, choose among adopting the narrow workflow, revising it, collecting more evidence or stopping. Record the reason and assign ownership for the next stage.
If you adopt it, publish the approved procedure, review point and route for reporting problems. If you stop, preserve the learning so another team does not repeat the same experiment without knowing its limitations.
Your next step is to identify one sponsor, one relevant specialist and two everyday users for a bounded task. Ask them to complete a single experiment brief together.
See the PiOfAI hub for the topic, the AI procedure guide for documentation and leading through change for the human side of implementation.
AI-assisted researched guidance from PeakBelt. Hypothetical examples are labelled in the text. See our editorial approach.