The first AI pilot in an organization sets more precedent than anyone intends. The access pattern it establishes gets copied. The service account it creates outlives it. The way success was claimed becomes the standard for the next request.
So it is worth spending an hour on five questions before the first one starts. None of them are technical. All of them are answerable in a meeting.
1. What data will this touch, and who can already reach that data?
The second half of the question is the one that gets skipped, and it is the one that matters.
Ask any pilot team what data their tool needs and you will get a reasonable answer: the ticket history, the policy library, the shared drive for that department. Then go and look at who can currently read that location. In most mid-market environments, the honest answer is "more people than anyone would have guessed," because permissions accumulated over a decade of reorganizations and nobody has had a reason to audit them.
An AI tool does not create that exposure. It makes it usable. Data that was technically readable but practically buried across ten thousand documents becomes searchable in natural language, which changes the risk profile without changing a single permission.
If the answer to "who can reach this" is unsatisfying, you have found the actual first project. It is not a reason to cancel the pilot. It is a reason to scope the pilot to a location whose permissions you are willing to defend.
2. Who is the principal?
When the tool reads a document, what identity is on the request?
There are three possible answers and only one of them is good. It might be the individual user, acting in the moment through delegated access — acceptable for an interactive assistant, provided the delegation is scoped and expires. It might be a distinct workload identity that belongs to the tool, with its own permissions and its own owner — this is the right answer. Or it might be a shared account, or a long-lived token minted by whoever built the integration, in which case nobody can tell later what the tool did versus what a person did.
The third answer is the default in a hurry, which is exactly why the question has to be asked before the hurry starts.
3. What does "it worked" mean, in a number you already collect?
Pilots that end without a decision usually ended without a measure.
The constraint that makes this useful is already collect. If evaluating your pilot requires standing up new instrumentation, you will not do it, and the assessment will come down to whether the people who built it liked using it. Pick something in a system you already run: time to first response in the ticket queue, percentage of tickets resolved without escalation, hours the finance team spends on a monthly close.
Write down the current value before you start. Not after — the number moves once people know it is being watched, and a baseline reconstructed later is not a baseline.
And decide in advance what result would cause you to stop. A pilot that cannot fail is not a pilot. It is a procurement decision with extra steps.
4. Who runs this in ninety days?
Pilots are staffed by the enthusiastic. Production is staffed by whoever is on the rota.
Before it starts, name the person or team who will own this thing when it is ordinary: who gets paged when it breaks, who reviews its access when the quarterly review comes round, who decides whether to upgrade it when the vendor deprecates the model underneath it. If that person is not in the room for the pilot, they will inherit something built to assumptions they never agreed to.
For an organization of a few thousand users with a small internal team, this is usually the binding constraint — more than budget and more than technical difficulty. You can run three pilots at once. You cannot operate three new systems at once. Sequence accordingly.
5. What is the way out?
Ask what happens if you stop using this in a year.
Where does the data you have sent it live, and can you get it deleted? If the tool has been accumulating context, embeddings or fine-tuning material derived from your documents, who owns that and what happens to it on termination? If you built a workflow on top of it, what is the manual fallback while you replace it?
This is not pessimism, and it is not a reason to delay. It is the difference between a vendor relationship you chose and one you are stuck in. The answers are usually fine. They are considerably harder to obtain after signature than before.
The shape of a good first pilot
Taken together, these questions point at a particular kind of first project: narrow data with permissions you can defend, its own identity, a measure you already collect, a named owner past the launch, and a documented exit.
That is a less exciting project than the one people usually propose. It is also the one that produces a decision instead of a demo — and the one whose patterns you will be content to see copied twenty times.