A company buys an AI tool, tests it, and a few weeks later shelves it with the verdict "it does not work". In reality the technology usually works fine. Something else fails: the brief. The most common cause of a failed AI project is a vague request that even a person would struggle to understand.
> Tip from KP Solutions: Before you say "AI could not handle it", imagine you gave the same task to a new employee on day one. If they would not know what you mean either, the problem is not the AI.
The main cause: a vague brief
AI does not read minds. It works with what it is given. When a company asks to "make it better", "kick off our marketing", or "turn this into a report", everything important is missing: the goal, the audience, the format, and how we recognize success.
The result is predictable. AI produces something generic, the company is disappointed, and the project stalls. All it needed was a sharper brief.
"Make it better" versus a concrete specification
Here is the difference on a common real-world example.
Weak brief: "Make our customer replies better."
Good brief: "Draft replies to customer emails about order status. Tone: polite and factual, like our support team writes. Always include the order number and the expected date. If a value is missing, do not guess, flag it for completion instead. Keep it under 120 words."
The second brief says what, for whom, how, at what length, and what to do under uncertainty. AI can work with it because it does not have to guess.
| Brief element | Vague | Concrete |
|---------------|-------|----------|
| Goal | "better replies" | draft a reply about order status |
| Audience | unspecified | a customer waiting for an order |
| Format | none | email under 120 words |
| Rule under uncertainty | none | do not guess, flag for completion |
Our spec-driven approach
At KP Solutions we build AI solutions around one principle: a clear specification first, implementation second. A good brief for AI has four parts.
First, a clear goal: one sentence that states the result. Not "help with admin", but "draft an invoice from the order data".
Second, context: the information AI needs so the output fits, such as the company tone, the rules, the relevant data, and examples of good output. Without context you get the average of the internet, not your company's answer.
Third, the output format: state exactly how the result should look, whether an email, a table, a list, or a structured record. Leave it open and you will get a random format you then rework by hand.
Fourth, success criteria: how do we know the output is good? For example, it contains the required fields, respects the length, and includes no fabrications. Success criteria turn "give it a try" into a verifiable goal.
Practical examples: bad versus good brief
For reporting, bad is "make us a sales overview". Good is "from this data prepare a monthly sales overview by product, format a table plus a three-sentence summary, highlight products with a drop above 10 percent".
For internal communication, bad is "summarize this meeting". Good is "summarize the meeting notes into five bullets, one sentence each, followed by a task list with an owner per task, plain language for non-IT colleagues".
For document processing, bad is "process these invoices". Good is "from each invoice extract the supplier, amount, date, and reference number, output as a structured record, and if a value is missing ask a question instead of guessing".
In every case the difference is the same: the second brief is a specification, the first is a wish.
How to prevent it in your company
Preventing failure is not about better technology but better preparation. A practical path: pick one specific, repeated process rather than the whole company at once; write a specification for it with the four elements of goal, context, format, and success criteria; test it on real cases and compare the output against the criteria; adjust the specification rather than the tool until the output fits; and only then expand to more processes.
This is why some AI deployments deliver value within days while others give up after months. The difference is not the model but how precisely the company can say what it wants.
Conclusion
AI projects in companies fail mostly on a vague brief, not on technology. When you turn a request into a specification with a clear goal, context, format, and success criteria, the results change immediately. Process automation works exactly as well as you specify it.
If you want to set up an AI project to succeed, a [free first hour of AI consultation](/en/ai-konzultacie) is where we write the first good specification for your specific process together.