"We want to do something with AI" is not a brief, it is a symptom. Projects that start from a technology ("we need a chatbot," "let's fine-tune a model") routinely burn a quarter's budget before anyone can state which business number should move. A good AI project brief is one page, and it is deliberately uncomfortable to fill in: it forces the business problem before any technology, demands one measurable success metric, and makes the data situation and the veto-holders explicit. This article gives you that one-page structure, a filled-in example, and the mistakes that quietly kill briefs.
Why most AI briefs get non-answers
The typical AI brief fails in one of a few repeatable ways, and each failure produces the same downstream symptom: a team building confidently toward a target nobody agreed on.
| Brief failure | What it sounds like | What it causes |
|---|---|---|
| Technology-first framing | "We need a RAG chatbot for support" | The actual problem (slow answers? wrong answers? cost?) never gets stated or measured |
| No metric | "Improve efficiency with AI" | Success is undefinable, so the project can neither succeed nor be stopped |
| Data optimism | "We have tons of data" | Month three: the data is scattered, unlabeled or GDPR-restricted |
| Invisible constraints | Latency, budget or compliance limits surface at review | A technically working solution that can never launch |
| Missing veto-holder | Legal, works council or security first sees the project at rollout | Late-stage blockage after the expensive part is done |
The one-page brief: seven fields
This is the whole document. Every field has a forcing question; if a field cannot be filled in honestly, that gap is the project's first work item, before any model is touched.
- 1Business problem (2-3 sentences, no technology words): what hurts today, who feels it, what it costs. Test: delete "AI" and the paragraph must still make sense.
- 2Success metric (1 line): the one number that should move, its current value, its target value, and when. Example: "first-response time from 8h to under 1h by Q3."
- 3Data situation: which data the solution needs, where it lives, who owns it, whether it is labeled, and the legal basis for using it. Unknowns are written down as unknowns.
- 4Constraints: hard limits on latency, cost per transaction, hosting/data residency, explainability and compliance, each with its source (regulation, contract, policy).
- 5Stakeholders: who sponsors (pays), who uses the output daily, who operates it after launch, and who can veto, each named as a person, not a department.
- 6Scope and explicit non-goals: what the first shippable version covers, and two or three things it deliberately does not do.
- 7Timebox and budget frame: how much time and money buys the first go/no-go decision point, not the whole project.
The two fields that do the real work: problem and metric
The problem statement and the success metric carry the whole brief, and they are where vague language hides. The rewrite pattern is always the same: from activity to outcome, from adjective to number.
| Vague version | Real-answer version |
|---|---|
| "Use AI to improve customer support" | "Support answers take 8h on average; 30% of tickets are repeat questions already answered in our docs" |
| "Increase efficiency in order processing" | "Manual order checks cost 4 FTE; error-driven rework affects 6% of orders" |
| "Success: the chatbot works well" | "Success: deflection of 25% of tier-1 tickets at CSAT >= today's baseline, measured over 4 weeks" |
| "Success: the model is accurate" | "Success: forecast error (MAPE) drops from 22% to under 12% on a held-out quarter" |
Data, constraints, stakeholders: the un-glamorous fields that decide feasibility
These three fields are where projects are actually won or lost, and each has a checklist worth running before the brief is called done.
- 1Data access test: can someone pull a real sample this week? If access requires a two-month integration or a legal review, that is the project's true critical path.
- 2Label check: if the use case needs labeled examples, who labels, at what quality, and at what cost? "We'll label as we go" is a red flag, not a plan.
- 3Constraint sourcing: for every constraint, note where it comes from. Constraints without a source are often preferences that can be negotiated; real ones (GDPR, sector regulation, contractual SLAs) cannot.
- 4Veto walk: show the one-pager to legal/compliance, security, and, where applicable, the works council before kickoff. A 30-minute read now beats a launch block later.
- 5Operator question: name who owns the system twelve months after launch. If the answer is "the project team," there is no answer yet.
A filled-in miniature example
An illustrative one-pager for a fictional e-commerce mid-market company, condensed. Note what it does not say: no model names, no framework choices, those come later and downstream of this document.
| Field | Content (condensed) |
|---|---|
| Business problem | Return reasons are free text; categorizing them for purchasing takes 2 FTE and lags 6 weeks, so assortment decisions run on stale data |
| Success metric | Reason categorization lag from 6 weeks to under 1 day; purchasing-usable category accuracy >= 90% vs. human baseline |
| Data situation | About 1.8M historical return comments in the shop DB (fictional figure), unlabeled; 10k human-categorized rows exist from a 2024 audit; personal data must be masked |
| Constraints | EU hosting only (company policy); cost under EUR 0.02 per classified return (margin math); no customer-facing output in v1 |
| Stakeholders | Sponsor: Head of Purchasing; users: 4 category managers; operator: data team lead; veto: DPO and works council |
| Non-goals | No automated refund decisions; no supplier-facing reports in v1 |
| Timebox | 6 weeks and a fixed pilot budget to a go/no-go with measured accuracy on live data |
Common mistakes that quietly kill briefs
- 1Writing the brief after choosing the vendor or the model, which turns the document into a justification instead of a decision tool.
- 2Accepting a metric without a current value: a target without a baseline cannot fail, and therefore cannot succeed either.
- 3Letting "data situation: good" pass without anyone having pulled a sample; optimism about data is the most expensive optimism in AI.
- 4Filling the stakeholder field with departments instead of names; departments do not attend workshops or sign off on launches, people do.
- 5Treating the brief as a one-time artifact: it should be re-checked at every phase gate, and updated when reality diverges from it.
