Scoping ·
Scoping a generative AI project
Behind the request “we want to do AI” lie very different projects. Insufficient scoping is paid for later, in delays and budget. Here are the questions we settle before writing a line of code.
1. Name the project type
A request for a “large language model expert” may mean fine-tuning a model, integrating an API or designing a complete document search system. These involve different skills, different risks and different durations.
The first act of scoping is therefore to name the project type. We distinguish five families:
| Family | Purpose |
|---|---|
| Retrieval-augmented generation (RAG) | Query a document base in natural language, with cited answers |
| Agents | Automate a sequence of tasks that a model carries out using tools |
| Model fine-tuning | Specialise an existing model for a domain |
| Evaluation and industrialisation | Measure quality and operate the system in production |
| Strategy and scoping | Choose use cases, architecture and roadmap |
2. Document the real data
A proof of concept that succeeds on clean, hand-picked data often fails on production data. Scoping therefore documents the data as it is, not as one would wish it to be:
- Volume: number of documents, rows, pages
- Formats: PDF, word processing, spreadsheets, databases
- Quality: scanned, structured or raw documents
- Languages and business vocabulary
- Update frequency
- Sensitivity: personal data, trade secrets, classified information
3. Settle the sovereignty question
As soon as sensitive data enters processing, where the models run becomes a first-order criterion. It determines the choice of models, the infrastructure and the contractual framework.
| Criterion | Running in your infrastructure | External provider API |
|---|---|---|
| Models | Open models, run locally | Proprietary models, hosted by the provider |
| Data | Stays within your perimeter | Sent to the provider |
| Cost | Hardware investment | Usage-based billing |
| Compliance | Under your control | Depends on the provider's commitments |
| Disconnected operation | Possible | Impossible |
4. Define verifiable deliverables
“A working system” is not a deliverable. A deliverable can be tested, measured and reused. For a document search project, for example:
- A query service deployed in your infrastructure
- An indexing pipeline for new documents
- An evaluation report: accuracy, correctness of refusals, quality of citations
- Recorded architecture decisions
- Operating documentation
5. Set measurable success criteria
Before building, we agree with you on a representative question set and the expected thresholds. The decision to move from one stage to the next is taken on these measurements, not on the impression left by a demonstration.
Scoping is the first deliverable
Rigorous scoping is not a formality. It reduces misunderstandings about expectations, makes the budget estimable and protects the project. That is why none of our projects starts without validated scoping.