When I think about a first AI project, I want to know who will use it on an ordinary working day. What will they give it? What do they need back? And how will they decide whether the result is good enough?
My background is in anesthesiology and medical-device development. Building Pavisus meant working with software developers, industrial designers and electrical engineers. A clinical need had to become something another person could design, build and test. The interesting part was often getting the requirement clear enough that we were solving the same problem.
I think that is a useful starting point for AI as well.
“Help us use AI” leaves a lot open. “Help our product team find the current answer in our approved documentation” gives us something we can examine.
Take a hypothetical example. A team answers recurring product questions using manuals, training material and internal guidance. Someone finds the relevant documents, checks which version applies and writes a response. An AI assistant might help with the search and the first draft.
Before choosing a model, I would want to walk through that task with the person who does it. Which questions recur? Where does the current source live? What happens when two documents disagree? Who is responsible for the answer that goes out?
Those answers shape the tool. If finding the right document is the slow part, a searchable collection with clear version information may be the most useful first step. If assembling the response takes longer, a draft linked to its sources may help. The user still needs an easy way to check it.
For a first trial, I would choose a small set of representative questions and agree what we are measuring. Time saved is one part. So are the corrections required and the effort of checking the result. A fast answer that takes longer to verify has not earned its place in the workflow.
I would include questions the material cannot answer. The system should make that gap visible, rather than fill it with a plausible sentence. I would also include an outdated document and a disagreement between sources. Those are useful tests of whether the tool handles the work as it actually arrives.
Data handling belongs in this conversation from the beginning. What may the tool read? Where will processing happen? What will be retained, and who can access it? Local processing and an approved cloud service are different options. The choice needs to fit the organisation's requirements and the task.
For an initial demonstration, public or synthetic documents can often be enough to show the proposed interaction. They do not prove that the finished system will perform well on the team's own material. That needs a separate, agreed evaluation.
A sensible first result might be a working prototype. It might also be a clearer document structure, or a decision that this particular task is a poor fit for AI. Each gives the team something concrete to act on.
The question I would bring to a first meeting is simple: which recurring task would you most like to make easier, and what would count as a useful improvement?
/Daniel
I use AI to help prepare drafts. I review and approve each issue before publication.