A pilot is worth running only if it can end in a no. Scope it to one workflow, write the questions down first, and read the same evidence whichever way it points.
Most AI pilots do not fail. That is the problem with them. They run for months, a few people like the tool, nobody can say what was learned, and the pilot quietly becomes the rollout or quietly disappears. Neither outcome was a decision.
We run guided pilots of IQ Chat, and we run pilots as part of AI adoption work where the platform is still an open question. The shape that holds up is the same in both cases. It is small, it is written down before it starts, and it has three permitted endings: expand, revise, or stop. This article explains why we hold to that shape and what it takes to do it properly.
A pilot without a stop condition is a slow purchase
A pilot that can only end in yes is a rollout with a delay attached.
The usual version looks like this. A group gets access to a tool. They are told to explore. After some weeks someone collects impressions, and the impressions are positive, because the people who volunteered were already interested. The sponsor now has enthusiasm and no evidence. Finance asks what it will cost at full scale. Security asks what data went where. Nobody recorded either.
The fix is cheap, and it comes before anyone logs in: agree on the questions the pilot should answer, and agree on what a no would look like. If nobody in the room can describe a result that would stop the project, the pilot is not testing anything.
One workflow, chosen because it repeats
The unit of a pilot is a workflow, not a department and not a tool.
Pick work the team already repeats: a report, a review, a drafting cycle. Repetition matters for two reasons. The team knows what good output looks like, so they can judge the result without a rubric invented for the occasion. And the work will come around again during the pilot, so there is a second and third attempt to compare with the first.
"Let people try it on whatever they want" produces anecdotes. One recurring workflow produces a before and an after on the same piece of work.
What we ask for at the start is short: one recurring workflow, a short list of who will use it, and an IT contact for identity and connector questions. The rest gets worked out in the first conversation. Every pilot is scoped in a written statement of work before anything starts, covering timeline, deliverables, and cost. If a pilot is not the right move, the time to say so is before money is spent on it.
Configure the controls you would run in production
A pilot on a demo configuration answers the wrong question. It tells you whether the model can write. It does not tell you whether the tool survives your identity system, your connector rules, and your administrators.
So the pilot workspace is set up with the IT group around the chosen workflow: identity, connectors, model routing, and controls. The first pilot workspace is typically live within a week. In IQ Chat that setup means concrete things:
- Sign-in through SSO with Google, Microsoft, or Auth0, with users provisioned and deactivated through SCIM 2.0.
- Microsoft 365 and Google Workspace connectors that stay off until each user authorizes them. Administrators can keep them off for everyone.
- An admin-controlled model catalog with a workspace default and one backup model per model.
- Optional job-function roles with allow-lists for models, features, connectors, and tools.
- A retention window set per workspace, from 30 days to 10 years.
The point is to find the friction now. If the security review has an objection to a data path, a pilot is the right place to hear it. If a role needs a narrower model list, that is a finding too. A pilot that skipped the controls would have to be run again once they were turned on.
One capability suits pilot conditions particularly well. Data protection policies, in early access since the release of 6 November 2026, start in test mode and act on nothing until an administrator enforces them. During a pilot, that lets a compliance team see what a policy would have caught on real work before deciding whether to enforce it.
Provider terms need the same care as the product settings. Each model provider's data handling, retention, and training terms differ by provider and by contract. Those are confirmed in writing for the enabled providers before rollout, and a pilot is a reasonable deadline for getting that paperwork read.
What counts as evidence
At the end we review three things together: usage, deliverables, and feedback. Each one covers a gap the others leave.
Usage shows whether people came back. IQ Chat reports usage and calculated cost by model, user, agent, and feature, from the model prices administrators set. That gives the cost picture finance will ask for, built from the pilot's own activity instead of a vendor estimate. It also shows which models the team reached for once they had a choice, which is often different from the one they asked for.
Deliverables show whether the work was any good. These are the documents, analyses, and files the team produced on their own material. They can be put next to the last version of the same report, made the old way, and judged by the people who normally sign it off. The team keeps them whatever the outcome.
Feedback explains the other two. Low usage with good deliverables usually means a habit problem or a setup problem. High usage with weak deliverables means people are using the tool for something other than the workflow under test, which is worth knowing.
There is a fourth record behind these. Since the release of 26 September 2026, the workspace audit log covers sign-ins and refused attempts along with what people do: chats, shares, exports, deletions, uploads, agents, apps, and connectors. Each entry stores the hash of the one before it, and administrators can verify the chain in the console and export it with the hashes. When security asks what happened during the pilot, the answer is an export.
Stop is a legitimate result
The read on fit is written down before any rollout decision: what worked, what did not, and the usage and cost picture behind it. Then a plain recommendation.
Expand means the evidence supports it, and the next document is a scope and governance plan for the rollout. Revise means the workflow, the configuration, or the group was wrong, and a second, narrower run is justified. Stop means the finding is no. We document what did not hold and why.
A clear no is a useful outcome. An oversold maybe is not. An organisation that stops a pilot with a written reason has saved the cost of a rollout and kept the reason for the next time the question comes up. An organisation that drifts into a rollout on good feeling has spent more and knows less.
This applies to us as the vendor as well. In adoption work we evaluate platforms against the client's policy instead of starting from a vendor. IQ Chat is one option we can offer and it is never the only one. A pilot is the place where that claim gets tested.
What to write down before you start
If you are about to run an AI pilot, with us or with anyone else, five lines on one page will do most of the work:
- The workflow under test, and who owns it.
- The questions the pilot should answer.
- What a no would look like.
- The controls that will be on, and who in IT configured them.
- The date the evidence gets read, and who is in the room.
Then run it on real work for a defined period, long enough for the work to be real and short enough for the decision to come quickly. A pilot with those five lines can end three ways, and all three leave you with something in writing.
