Habr AI explained why ChatGPT shouldn't write a business's technical specification for AI implementation

The temptation to entrust AI not only with AI implementation but also with preparing a technical specification seems logical: fast, cheap, and without lengthy interviews. But precisely at this step, the business often gets a beautiful document that is poorly connected to the actual task, processes, and team constraints.

Why the template doesn't work

When a manager or customer asks ChatGPT to write a specification for AI implementation, the model usually assembles a plausible universal template. It contains many correct words: data analysis, model selection, security, integration, quality metrics. The problem is that such text is built on probability, not knowledge of a specific company.

It doesn't know how approvals are structured, where the data is located, who is responsible for support, and what solutions have already failed inside the business. Because of this, the document may look mature but remain hollow at the execution level. It often lacks priorities, project boundaries, acceptance criteria, and exception descriptions.

Even worse if the specification is written by someone who doesn't fully understand the subject matter themselves, and AI merely neatly packages these gaps in official style. The result is not an engineering document but a convincing imitation. This is dangerous from the very start of the project.

What problems emerge

The material discusses how AI generation is especially dangerous for AI implementation projects. There are too many dependencies here: quality of source data, legal restrictions, infrastructure costs, integration with internal systems, requirements for result explainability. Universal text almost inevitably smooths over these sharp edges and creates the illusion that the task is already formalized. This means real project risks surface too late, when money has already been partially spent.

• Formulations remain too general and allow dozens of interpretations
• Requirements for data and its quality are described superficially
• Metrics of success are replaced by abstract KPIs without business context
• Timelines and budget look realistic only on paper
• Comparing contractors by such a specification distorts the picture, because everyone responds to a vague request

This affects not just the contractor selection stage. If you distribute a weak specification to several teams and then ask AI to evaluate their proposals, the error scales up. The system will compare answers with the same superficial template and reward those who matched the formal wording better, rather than those who understood the problem more deeply. As a result, you might select a contractor with a beautiful presentation and weak architecture.

Where AI is useful

This doesn't mean AI should be removed from the specification preparation process. It has a useful role, but it's a supporting one. The model can be used to structure already-collected information: turn interviews with the customer into draft sections, suggest a list of clarifying questions, help check for logical gaps, bring terminology to a consistent style.

That is, AI is good where you need an accelerator for editorial and analytical work, not a substitute for project investigation. A working approach looks like this: first, the team manually documents the business goal, current process, constraints, available data, solution owners, and success criteria. Then AI helps bring this into understandable form, but doesn't substitute for the expertise of domain experts, analysts, and the technical lead.

The more expensive the implementation error, the more dangerous it is to trust the model with formulating initial requirements without human review. Only after that does it hand the text to the model for revision and editing.

What this means

The main conclusion is simple: AI can accelerate specification preparation, but it cannot itself reliably determine what needs to be implemented and how it will work within a specific organization. If you use the model as the author of requirements, the business risks buying not a solution but beautifully formatted uncertainty. Especially in projects where you'll later need to change processes, budgets, and people's responsibilities. This is what makes such documents particularly expensive.