Start with work you can judge
A good pilot has a repeatable task and a clear definition of an acceptable result. Preparing a service summary from approved notes is easier to evaluate than asking a system to “understand the business”. Collect examples of good work, difficult exceptions and unacceptable errors. Decide who reviews the output before it reaches a customer or changes an important record.
The information boundary is part of the product
Identify which sources the system may use, who is allowed to see them and how long information should be retained. A useful answer should make its sources available when the task requires traceability. Access controls must apply to retrieval as well as the original documents. Begin with synthetic or properly permissioned examples while the design is being tested.
Measure the whole task
Compare the existing method with an assisted version using the same sample. Measure accuracy, omissions, review effort, latency and running costs. A faster first draft is not a saving if someone spends longer correcting it. The pilot should include cases where the system cannot answer and has to return the task to a person.
Know when a simpler tool is better
A rule, a form, a template or a better search function can be easier to operate than an AI feature. Use a model when its flexibility adds something valuable. Do not give it the final say on a consequential decision simply because it can generate a confident explanation.
What a first conversation should resolve
Bring one task, an example of the input, a description of a good result and the consequences of an error. Avoid sending sensitive data before access and handling have been agreed. We can then discuss the smallest test that would provide useful evidence.