Clarify use case and data before the specification is written? The AI Opportunity Check reviews one business process with sample data and systems and delivers a written decision brief with pilot scope and budget range. From €3,900 excl. VAT (as of October 2026). See the AI Opportunity Check
A requirements specification for an AI project (German: Lastenheft) defines which result the client expects and how it is measured. It differs from a specification for conventional software in three ways: the behaviour of the system is not fully predictable, the result depends on the data, and operation is part of the scope. This article provides an outline with eleven sections, a sample wording and a review question for each section, plus typical failure patterns. As of October 2026. It covers the specification for AI projects, not the use of AI to write or review specifications.
Table of contents
- Requirements for AI projects: what changes compared with conventional software
- Lastenheft, Pflichtenheft and service description in AI tenders
- When a specification comes too early
- The outline at a glance
- The eleven sections with sample wording and review question
- Failure patterns
- Our approach at WZ-IT
- Status and methodology
- Further guides
Requirements for AI projects: what changes compared with conventional software
| Topic | Conventional specification | Specification for an AI project |
|---|---|---|
| Expected behaviour | exact expectation per test case | measurement on reference cases with thresholds and blocking cases |
| Inputs | specified functionally | data and data quality are part of the requirement |
| Change after acceptance | only with a new version | a model, prompt or index change can shift quality |
| Operation | often commissioned separately | quality monitoring and regression testing are in scope |
| Legal framework | data protection, security | additionally the EU AI Act: role, risk class, transparency |
Lastenheft, Pflichtenheft and service description in AI tenders
Under DIN 69901-5 (edition 2009-01) the Lastenheft is the totality of requirements set by the client for the deliveries and services of a contractor within an order. The Pflichtenheft contains the implementation specifications developed by the contractor on the basis of the Lastenheft (wording in a student paper of LMU Munich, in German). The standard is a terminology standard (part 5: terms); its table of contents lists scope, normative references and terms.
In procurement law the Lastenheft corresponds, broadly speaking, to the Leistungsbeschreibung (service description); in practice the terms are not always kept clearly apart. The GWB rules on the service description apply to awards whose estimated value reaches or exceeds the EU threshold (section 106 GWB, in German). The service description describes the subject of the contract as unambiguously as possible so that all companies understand it in the same sense and bids can be compared, and it contains the functional or performance requirements or a description of the task to be solved, plus the circumstances and conditions of performance (section 121 GWB, section 31 VgV, both in German). Under section 31(6) VgV it must not refer to a particular make or source or to particular types where this would favour or exclude certain companies or products, unless the reference is justified by the subject of the contract; as an exception it is permitted where the subject cannot otherwise be described sufficiently precisely, then with the addition "or equivalent". For AI tenders this means: properties instead of product names. Acceptance criteria through reference cases are a recommendation of this article, not a requirement of procurement law.
When a specification comes too early
A complete specification presupposes three answers:
- Has the process in which the system works been chosen?
- Is sample data available that can be used technically?
- Can reference cases be named against which acceptance takes place?
If one answer is "no", the specification is built on assumptions. In that case an AI Opportunity Check clarifies the process first. If several processes and the target architecture are open, the AI Opportunity and Architecture Assessment orders use cases, operating model and roadmap.
The outline at a glance
Every requirement gets an ID and a priority (must, should, may), for example "AI-6.2 (must): All permission tests of the test set pass before acceptance." Without priorities, bids cannot be compared. Lists belong in annexes: source list, egress list, interface list, reference cases and glossary.
| No. | Section | Minimum content |
|---|---|---|
| 1 | Goal and benefit | measurable goal, baseline value, measurement period |
| 2 | Use case and user groups | process, roles, volume, point of human decision |
| 3 | Data sources and data quality | source list with owner, format, currency, language |
| 4 | Rights and data protection | purpose, data types, access rights, deletion, outbound connections |
| 5 | Model and platform requirements | location of operation, licence, language, replaceability instead of model name |
| 6 | Quality criteria and acceptance | reference cases, metrics, blocking cases, thresholds |
| 7 | Integration | interfaces, identity, target systems, action rights |
| 8 | Operation and monitoring | updates, regression test, quality monitoring, responsibilities |
| 9 | Exit and handover | export formats, scope of handover, rights to the test set |
| 10 | Legal framework | review questions on the EU AI Act and GDPR, responsibility |
| 11 | Exclusions | what the system explicitly does not do |
The eleven sections with sample wording and review question
The sample wordings are freely chosen templates; the placeholders in square brackets are not a recommendation of figures.
1. Goal and benefit
The goal names a measurable change in a process, not a technology. Without a baseline value the benefit cannot be proven after the project.
Example: "The handling time for standard requests falls from the baseline of [minutes] to [minutes], measured over [period] on [number] cases."
Review question: Who measures the baseline, and is it available before the project starts?
2. Use case and user groups
The use case describes trigger, input, result and the point at which a person decides. The degree of autonomy belongs here too: answer, draft or action (permissions and approvals).
Example: "The assistant answers staff questions about released policies and names the source for each answer. It changes no data and sends no messages."
Review question: Which decision does a person still make, and where do they see the result?
3. Data sources and data quality
Each source gets an owner, format, update rhythm, language and a rule for duplicates and outdated versions. Scanned documents need text recognition and a separate measurement. How sources are connected in operation is described in RAG with Nextcloud, SharePoint and DMS.
Example: "Source A ([system]) contains [number] documents, [share] of them scanned. [Role] is responsible. Outdated versions are marked or excluded."
Review question: Is there an owner for every source and a rule for outdated versions?
4. Rights and data protection
Two levels: data protection with purpose, data types, legal basis, recipients, outbound connections, deletion and evidence (seven review questions) and the access rights of the sources. Permissions are enforced before the search, not in the prompt (RAG with permissions).
Example: "A user only receives answers from documents they may read in the source system. The system connects only to the destinations on the egress list in annex [n]."
Review question: Where is the permission checked: in the source system or in the prompt?
5. Model and platform requirements
The specification names properties instead of model names, because models change faster than projects: location of operation, a licence that permits commercial use (licences), German as a language, context length and replaceability behind a gateway (What is LiteLLM?). Model selection is covered in Which LLM to self-host?.
Example: "The models run in Germany under a licence that permits commercial use. A model change requires no change to the applications."
Review question: Which property is really a must, and which model name is only habit?
6. Quality criteria and acceptance
Acceptance needs reference cases from the business department, metrics and thresholds agreed before measurement, and a split into blocking cases and averages. The test set belongs to the client. Figures such as "90 percent" are meaningless without reference to your own test set. Structure, metrics and baseline are described in Measuring RAG quality.
| Task type | Reference cases | Metric | Blocking cases |
|---|---|---|---|
| Knowledge assistant (RAG) | real questions with source, questions without an answer in the corpus, permission tests | recall@k, faithfulness, correctness as judged by the business department | permission tests, "not in the corpus" |
| Extraction from documents | documents per type, scanned and digital, with confirmed target values | hit rate per field | fields with legal or financial consequences |
| Classification | inputs per class, including rare ones | precision and recall per class | confusion of critical classes |
| Drafting, generation | tasks with a scoring grid | rating by the business department against the grid | prohibited statements, missing mandatory information |
| Agent, workflow | workflows with error cases and approval points | success rate per workflow, correct abort | action without approval or outside the tool catalogue |
The specification defines a procedure for this: first the test set is fixed jointly, then a simple configuration measures the baseline, then the thresholds are agreed relative to that baseline, before implementation starts. The business department, not the vendor, judges correctness.
Example: "Acceptance is granted when all blocking reference cases pass and the thresholds for [metric] on test set version [n] are met. Reference cases and thresholds are fixed before implementation starts."
Review question: Who selected the reference cases: client or vendor?
7. Integration
Record the interfaces, sign-in through the identity system and target systems. For systems that act, add the identity under which they access target systems.
Example: "Sign-in uses the client's identity system. The system reads only through the interfaces in annex [n] and does not write."
Review question: Under which account does the system access, and what can a single user trigger through it?
8. Operation and monitoring
Updates, responsibilities and backup are regulated as for any software. Quality is added: before changes to the model, prompt or index the test set runs, and in operation monitoring watches errors, cost and latency (What is Langfuse?).
Example: "The test set runs before every model, prompt or index change. The change is introduced only if no previously passed blocking case regresses."
Review question: Who starts the regression test, and who approves changes?
9. Exit and handover
At the end of the contract, configuration, prompts, the test set with results, documentation and credentials go to the client, with data in open formats. The index can be rebuilt from the source data.
Example: "The contractor hands over configuration, prompts, the test set with results and documentation in open formats. The index is reproducible from the source data."
Review question: Does the system run without components that only the contractor licenses or operates?
10. Legal framework
The specification contains no legal interpretation, only review questions with a named owner:
- EU AI Act: provider or deployer? Which risk class? Which transparency duties? (The EU AI Act for companies)
- GDPR: legal basis, data processing agreement, transfer to third countries (GDPR-compliant AI)
- Works council and professional secrecy, if affected (AI assistants and the works council)
Example: "The client clarifies role and risk class under the EU AI Act before the start. The contractor supplies the technical system description."
Review question: Who in the company clarifies role and risk class, and by when?
11. Exclusions
Exclusions protect acceptance, because otherwise the scope grows through expectations.
Example: "Not in scope are automated decisions about individuals, sending messages without approval and sources outside annex [n]."
Review question: Which obvious expectation is explicitly excluded?
Failure patterns
| Failure pattern | How to recognise it | Consequence | Section |
|---|---|---|---|
| Goal too open | "an AI assistant for the company", no baseline | benefit cannot be proven, dispute over success | 1, 2 |
| Missing acceptance | acceptance based on the impression of the demo | quality problems become visible only in operation | 6 |
| Vendor chooses the test cases | reference cases come from the contractor | the measurement only confirms the expected | 6 |
| Unresolved data rights | data exists, usage and access rights are unclear | late project stop or data leakage | 3, 4 |
| Model name instead of properties | one model as a must | licence and operating questions, no switch possible | 5 |
| Operation not described | specification ends at go-live | quality drops unnoticed after a model change | 8 |
| Everything is a must | no prioritisation | bids cannot be compared | overview |
Our approach at WZ-IT
The AI Opportunity Check clarifies before the specification whether and where AI fits a process. It comprises a workshop on one business process, a review of the sample data and systems, automation boundaries, risks and required human oversight, and a written decision brief with pilot scope and budget range. It records the goal, volume, participants and typical variants of the process as well as sample data, interfaces and target systems; these are also the details that sections 1 to 3 and 7 of the specification call for.
The check costs from €3,900 excl. VAT. The decision brief can be used without a follow-on order. Implementation, detailed system design and legal advice are not included. For several processes, the AI Opportunity and Architecture Assessment evaluates up to three processes, prioritises use cases and defines target architecture, operating model and roadmap. Prices excl. VAT, as of October 2026.
Status and methodology
- Status: 28.10.2026, all linked sources retrieved on that day.
- DIN 69901-5: The text of the standard is paid and was not consulted. The 2009-01 edition is listed as current by DIN Media; the wording of the definitions follows a student paper of LMU Munich (2017) that quotes the standard, and matches the slides of an LMU course (2015/16).
- Statutes: sections 106 and 121 GWB and section 31 VgV read in the original wording.
- Outline, examples, tables: our own compilation based on the linked guides on RAG quality, data protection and agent permissions. The examples are freely chosen, not projects.
- Thresholds: placeholders in square brackets are not a recommendation. Thresholds depend on risk and test set.
- Scope: Solutions that review specifications with AI, for example from pexon or elunic, are a different topic.
- Legal: This article is not legal advice.
Further guides
- What is RAG? - basics for knowledge assistants
- Measuring RAG quality - test set, metrics, acceptance criteria
- AI agents: permissions and approvals - identity, tool catalogue, approvals
- GDPR-compliant AI: assessment criteria - seven questions before use
- The EU AI Act for companies - role, risk class, timeline
Clarify whether and where AI fits before the specification? The AI Opportunity Check delivers the written decision brief, the architecture assessment orders several processes. AI Opportunity Check · AI Opportunity and Architecture Assessment
