Start with a task, not a model
“We need AI” is a direction, not a specification. Describe one task that costs time or leaves people without the information they need. Who performs it? What evidence do they use? What decision follows the result?
A document assistant, for example, needs a narrower definition than “answer company questions.” Specify which documents it may use, which people may ask, and what it should do when the evidence is incomplete. This gives a prototype something meaningful to prove.
Check the information behind the answer
Useful source material needs to be accessible, current and appropriate for the task. Make an inventory of the systems and documents involved, identify their owners, and decide which permissions must carry through to the AI feature.
Retrieval can supply relevant material to a model, but it does not automatically make the answer correct. Define how the product will point to sources, handle conflicting documents and respond when no supporting information is found.
Build an evaluation before expanding the rollout
Collect a representative set of questions or tasks, including difficult and unanswerable examples. Ask the people who do the work to describe acceptable responses. Evaluate usefulness, omissions and failure behavior alongside latency and cost.
Keep the first release narrow enough to inspect. A good demonstration is a reason to investigate further; it is not evidence that the system will behave reliably in every operational situation.
Decide where people stay in control
Drafting an internal summary and approving a consequential action have different requirements. Identify decisions that need review, make the reviewer’s role explicit, and ensure the underlying evidence remains available.
Your readiness checklist should name a workflow owner, approved data sources, quality criteria, access boundaries and a fallback process. If one is missing, discovery has a clear next task before implementation grows.