A team spends time finding procedures, preparing replies or rephrasing documents. AI looks promising. But “installing AI” does not yet identify the problem to solve or explain how to verify that it has been solved. The first useful deliverable is often a definition of the work to improve.
The CNIL recommends starting with identified uses and setting boundaries for permitted practices. In its voluntary risk management framework, NIST connects governance, context, measurement and risk treatment. The method below translates that approach into practical project scoping, to adapt to your organisation.
Describe an observable task
Choose a task specific enough to demonstrate. “Improve productivity” is too broad. “Prepare a draft reply from product documentation, then have an adviser approve it” already defines an input, an expected result and a human responsibility.
Record who performs the task, how often and with which tools. Identify exceptions: a missing document, conflicting information, a sensitive case or a different language. A demonstration prepared only with easy cases tells you little about the actual work.
Define the data that may be used
Before connecting a shared folder, list the sources the task needs. For each source, specify its owner, who may read it, how often it is updated and which information must be excluded.
A demonstration copy can use clearly identified fictional examples. Moving to real data is a separate decision. A document’s presence in a company tool does not mean it should be sent to every provider or made accessible to every employee.
Build a small evaluation set
Prepare representative cases before making a final model choice. Each case describes a request, the accessible sources and what would count as an acceptable answer. Add situations where the system should acknowledge missing information or refuse an unauthorised action.
Then measure several dimensions: accuracy, source quality, human review time, response time and usage cost. A pleasant answer may require more corrections than a straightforward draft. The complete workflow matters, through to approval and use of the result.
Separate the prototype from operations
A prototype answers a question: can this solution help within this scope? An operational service must also manage accounts, permissions, errors, backups and model changes.
The budget should therefore distinguish design, integration, compute, hosting and maintenance. When comparing proposals, ask what is delivered, which responsibilities remain with you and what happens as usage increases. The studio’s pricing guidance explains the distinction between an initial service and additional costs.
Plan a decision about the next step
Define in advance what would justify continuing, changing or stopping the project. Are answers sufficiently supported for the case being studied? Does review time remain compatible with the expected benefit? Do users know when not to use the tool?
This decision prevents every prototype from turning into an obligation to deploy. A trial may show that better document search or conventional automation meets the need more simply.
What to prepare for a first conversation
Bring a description of the task, a few non-sensitive examples, the tools involved, user roles and known constraints. Explain the results you want to observe. There is no need to send administrator access or a complete database to discuss the scope.
You can introduce your project to the studio with these initial details. Scoping is about making an informed decision before buying technology, starting with a clearly expressed need.
