AI can draft a troubleshooting topic, rewrite a paragraph, or summarise a product specification in seconds. But that is just part of technical writing.
A Technical Author’s working day, in reality, includes research, planning, interviewing subject matter experts, checking facts, managing reviews, publishing content and maintaining it after release. Much of the job involves getting information from other people and moving it through an organisation.
Some of the points in this article come from Cherryleaf’s experience of providing AI technical writing consultancy. One recurring theme is that organisations focus too narrowly on writing. The problem usually needs to be examined across the whole documentation workflow.
That includes the inputs from Product Management, Engineering, Support, Legal, Compliance, Marketing, and other departments.
If you only use AI to produce sentences faster, you might improve the quickest part of the process while leaving the real delays untouched.
Here are seven mistakes organisations make when using AI in technical writing.
1. Starting with the writing task
The obvious use for generative AI is drafting content. Give it a prompt and it gives you words.
But the writing stage might not be the main constraint.
A Technical Author might spend an hour drafting a topic, then wait three days for an engineer to answer a question. The finished draft might sit with Legal or Product Management for another week. Later, nobody tells the documentation team that the feature has changed.
The larger opportunities often sit at the points where Technical Authors interact with other departments.
AI and automation might help by:
- Extracting documentation requirements from product specifications and development tickets.
- Identifying unanswered questions before an interview with an engineer.
- Comparing release information with existing Help content.
- Routing drafts to the right technical, legal or compliance reviewers.
- Chasing overdue approvals.
- Detecting product changes that might require documentation updates.
- Analysing support tickets to identify gaps in the knowledge base.
- Turning repeated support answers into proposed documentation topics.
The whole workflow matters. Look at where information originates, how it reaches the writer and what happens after the first draft.
The best opportunity might actually be improving the input from another department, rather than changing how the Technical Author writes.
2. Automating a process nobody has examined
Automation makes a good process faster. But it also makes a confused process faster.
If nobody knows when a topic is ready for review, an AI-generated draft will not fix that.
Start by making the current process visible:
- Where does the information originate?
- Who decides what needs documenting?
- What evidence does the technical author need?
- Who checks technical accuracy?
- Who has authority to approve publication?
- What triggers an update?
You also need to examine the quality and timing of inputs from other departments.
For example, does Product Management provide an agreed description of the user need? Do developers record important behaviour and limitations in their tickets? Does Support share the questions customers keep asking? Does Legal explain which wording is required and which wording is optional?
AI cannot make up for information that never reaches the documentation team.
Sometimes, steps can be removed. Others need a clear owner. Only then is it worth deciding where AI belongs.
3. Not knowing what good looks like
An AI system can produce fluent documentation that is incomplete, misleading, or wrong.
This means someone who knows what good looks like still needs to be in the loop.
That person needs to judge whether the content:
- Answers a real user need.
- Uses accurate source information.
- Includes the prerequisites, warnings and recovery steps.
- Matches the product.
- Follows the organisation’s terminology and style.
- Works for the intended audience.
- Can be found, reused and maintained.
- Meets any legal, security or regulatory requirements.
Before using AI at scale, define your content standards and review criteria. Create examples of acceptable documentation. Agree which checks people must carry out and which checks a tool can support.
AI can help apply a standard. It cannot invent a sound standard from a vague request to “make this better”.
4. Giving the AI poor source material
An AI assistant magnifies good quality content, and it also magnifies poor quality content. AI can make existing documentation debt more visible.
If the source material contains conflicting specifications, abandoned wiki pages, and outdated procedures, the output will reflect those problems. A well-written answer based on the wrong source can be more dangerous than an obviously incomplete one.
Technical Authors can spend a lot of time cleaning up source material that comes from development tickets, design files, product plans, policies, meeting notes, support systems and conversations with subject matter experts.
The same problem affects AI search and support systems that use retrieval-augmented generation, or RAG. These systems retrieve information from a knowledge base before generating an answer. If the retrieved content is outdated or contradictory, the answer will be unreliable.
Some of the biggest wins come from improving the quality of the source material, especially before connecting it to an AI system. Decide which content is authoritative. Remove duplication, record ownership, and create a maintenance process.
Cherryleaf’s AI services for technical writing teams include documentation workflow consultancy, governance support, and audits of content intended for AI retrieval.
5. Choosing a tool before defining the problem
We’ve seen situations where an organisation has selected an AI tool, without talking to the technical writing team to check it is right for them. We’ve also seen development teams being given access to frontier AI models, but not the technical publications team. As a result, the Technical Authors have been limited in what improvements they can make.
Start with a specific problem. For example:
- Release information reaches the documentation team too late.
- Reviewers miss important technical errors.
- Support teams repeatedly answer questions that should be covered in the knowledge base.
- Writers spend hours comparing specifications with published content.
- Documentation changes are difficult to trace to an approved source.
- Useful information is trapped in meetings, tickets and chat conversations.
- Different departments provide conflicting descriptions of the same product behaviour.
You can then test whether AI, and a specific tool, is appropriate. In some cases, the answer will be a language model. In others, it will be a workflow rule, a better template, or a conversation between two department heads.
A successful pilot should test one defined problem, use real material, and have a measurable outcome.
6. Treating human review as proofreading
Human oversight is sometimes reduced to checking spelling and tone after the AI has produced a finished draft.
That is too late and too narrow.
People should make decisions throughout the process. They decide whether the source is trustworthy, which audience matters, and whether information is safe to publish. They also decide what evidence is needed before accepting an AI-generated claim.
Those decisions might involve several departments. For example, an engineer checks technical behaviour.
The amount of review should depend on the risk. An internal draft for discussion needs different controls from a safety procedure. API documentation needs examples that have been tested.
Define who is accountable for the published information. Record the sources used where traceability matters. Make it easy for reviewers to see what the AI changed.
The AI can propose. A named person still approves.
7. Providing access without providing training
People need to understand what the tools can do, where they fail, and how to incorporate them into a controlled documentation process. They also need guidance on privacy, copyright, security, verification, and the organisation’s approved uses.
Training should cover more than prompt writing.
Documentation managers also need the skills to examine the complete process. They must understand how information crosses departmental boundaries and where AI could remove waiting, rework or repeated administration.
Cherryleaf offers an ISTC-accredited, self-paced Using Generative AI in technical writing course. It covers the use of AI during research, planning, writing, review, publishing and maintenance.
For team leads and documentation managers, the instructor-led Managing and mastering documentation projects with AI course focuses on project management, quality controls, collaboration and documentation workflows.
Cherryleaf also provides live training, workshops, and AI technical writing consultancy for organisations that need an approach based on their content, systems, departments, and risks.
Look for the queue, not only the keyboard
AI can help Technical Authors write. That might not be where work becomes stuck or time is wasted.
It could be the wait for accurate product information. It could be a support system that never feeds customer questions back into the knowledge base. It could be documentation that changes without anybody knowing which version is authoritative.
These are documentation problems, and they are also workflow and organisational problems. Solving them requires cooperation across departmental boundaries.
Someone also needs enough technical communication knowledge to recognise good documentation when they see it.
Cherryleaf provides technical writing and procedures writing services, documentation consultancy, AI workflow support, and training. Drawing on our consultancy experience, we can examine the whole process, identify the costly bottlenecks, and decide where AI will make a useful difference.
Because producing words faster is helpful. Producing the right information, at the right time, with less waiting and rework is better.
Leave a Reply