Define a workflow before choosing a model

Start with a complete journey: who makes the request, what information is available, what outcome is expected and who checks it? An assistant that drafts a response and an agent that executes an action have different requirements.

Identify situations where conventional rules or human intervention remain more appropriate. This can reduce scope and avoids budgeting for AI when a software integration is sufficient.

  • Which delay or friction are you trying to reduce?
  • Which errors would be acceptable, expensive or irreversible?
  • How will you check that the outcome is better than the current process?

Examine the data and its permissions

Scattered, poorly structured or outdated documents need preparation. Identify authoritative sources, how often they change and the access rules that apply.

For document search, the budget covers more than retrieval: ingestion, updates, deletion and permission enforcement matter too. A prototype using a few files does not demonstrate that these requirements have been addressed.

Separate delivery from operation

The delivery budget covers discovery, the interface, integrations, controls, evaluations and deployment. The number of systems involved and business requirements may matter more than the initial model choice.

Recurring costs include model usage, infrastructure, storage, monitoring, support and changes. They depend on volumes and conversation length, but also on operations triggered behind the scenes.

  • Define normal and peak usage scenarios.
  • Plan suitable usage limits and alerts.
  • Separate automated costs from human review time.
  • Agree who will handle incidents and provider changes.

Budget for validation, not just a demo

Build a set of representative cases: straightforward requests, ambiguity, missing information, denied access and attempts to misuse the system. Define success criteria before expanding the rollout.

These cases should be replayable after a change to the model, instructions or sources. Continuous evaluation is part of the product, not just a final acceptance exercise.

Choose a measurable first step

A useful first scope addresses a real need end to end, for a defined group of users. It should make quality, exceptions and costs measurable without granting overly broad permissions.

To prepare a discussion, gather a few example requests, an overview of the sources, the tools involved and confidentiality requirements. We can then propose a scope and make the assumptions behind an estimate explicit.

What about your project?

You have identified a use case but the scope is still unclear? We can review the data, integrations and quality criteria before defining a first delivery.

Artificial intelligence