Introducing AI into the technical writing department is no longer a pioneering act in 2026. The question is no longer whether a language model contributes, but where it does so, who checks the output, and whose data it sees in the process. Anyone who does not clarify these three points builds in a risk that turns out more expensive later than any licence fee.
Over the past 18 months I have seen many writing departments acquire an LLM because management wanted to see „something with AI“. What then happened had little to do with efficiency. Texts were generated, errors in the texts were generated, and because the output came faster, the next output came faster still. In the end there was more material awaiting review than had been written in the first place. The productivity gain was negative.
The cause rarely lies in the model. It lies in the process upstream of it. AI belongs in the writing department, that is no longer seriously in dispute. It belongs there by the same pattern as a CCMS or a translation-memory system: plan big, start small, address the real bottleneck.
Why most AI pilot projects in writing departments fail
When I look at the failed pilot projects of the past 18 months, I see four patterns. In this order.
First: no data base. The model is given Word files in which three generations of writers have left their traces. Three spellings for the same component. Two terminologies for the same procedure. Half-finished tables that nobody maintains any more. The LLM does what it has to do: it adopts the inconsistency and produces it faster. Anyone expecting a quality improvement here mistakes AI for magic.
Second: no quality yardstick at the output. Nobody has ever formally defined what makes a „good“ operating manual within their own organisation. Before AI is introduced, this goes unnoticed, because an experienced writer has the yardstick in their head. As soon as the model writes, this yardstick is missing. Then people argue about whether a text „fits“, and in the end the loudest opinion decides, not the best reasoning.
Third: expectation instead of specification. „AI will make our manuals“ is not a brief, it is a wish. It would have to become concrete: which document types, which modules, at what language level, with what source base, with what review routine. Anyone who starts without this definition works on the wrong problem for six months.
Fourth: the pilot project must not fail. As soon as the board knows internally that „we’re doing AI now“, the pilot becomes a PR event. Negative findings are smoothed over, hard data points disappear, and in the end the steering committee hears: it’s running. Only nothing makes it into productive regular operation that way. A pilot that is not allowed to fail is no pilot.
The tekom publication „AI in Technical Communication“ is usable as an entry point, especially for management that does not yet have an overview. But it does not replace your own inventory.
Three tasks where AI in the writing department really saves effort today
The productive use cases are less spectacular than the marketing slides, but they work. These three can be deployed in almost every writing department as soon as the data base is right.
Translation as a raw draft, not as a finished product. A modern LLM produces a pre-translation that an editor brings to publication quality in 25 to 35 % less time, measured against pure TM pre-population. The prerequisite is a maintained terminology database and a clear handling of brand, product, and safety terms that the model must not „overwrite“. Without this groundwork, the effort shifts from translating to correcting. The effect on the overall budget is then zero.
Consistency checking across large volumes of documents. „Does the manual actually say maintenance flap everywhere, or sometimes service flap?“ An LLM answers this kind of question in minutes, where a human would need days. Nothing is generated in the process; a lot is measured. The results flow directly into the maintenance of the terminology database, where they have systematic value.
Structure suggestions for standard documents. If you have already written twenty operating manuals for variant machines, a model can suggest the basic structure for the twenty-first, including all the mandatory chapters from your documentation matrix. That saves about half a day per manual, which flows into the in-depth content work where the human is really needed.
For all three applications, the rule holds: the review stays human. Anyone who outsources or cuts that does not shift the bottleneck. They create a new one, further back in the chain, at the point „complaint“ or „liability case“.
Where AI in technical writing does not (yet) work
Just as important as these three applications is their inverse: where does AI fail today, and why? This is discussed far too rarely in consulting conversations.
Safety-relevant warnings are not a use case for a language model. A model weighs up probabilities. But a safety statement has to be true, not probable. Anyone who adopts AI outputs here into the finished product without expert review risks, under the Machinery Regulation 2023/1230 (binding from 14 January 2027), a conformity gap that is immediately noticed in market surveillance.
The model likewise cannot judge whether a matter is described correctly in technical terms. It can describe a coupling as force-fit even when it is form-fit, and it will do so as soon as the training data or the context is correspondingly skewed. This check costs an experienced design engineer five seconds. For a model it is simply impossible.
Comprehensibility for the target audience is the third gap. A model has no picture of who will read your text. It does not know whether your end customer is a university graduate or a working student on the second shift. This adaptation has to be made by a human who knows the target audience.
Data protection and trade-secret protection: five questions you have to ask every provider
This is where things most often go wrong in practice. The question „what happens to our data?“ is either not asked at all or ticked off with a marketing answer from the provider. Both are negligent. Engineering drawings, parameter lists, BOM data, and unpublished product information are trade secrets. They are protected by the Trade Secrets Act, but only as long as you yourself take appropriate secrecy measures. Anyone who hands them to an external service unchecked loses this protection.
These five questions have to be answered in writing before any AI introduction, ideally in the data-processing agreement under Art. 28 GDPR or in a separate data-processing arrangement:
- Are my inputs used to train the model? The answer has to be „No, not without explicit opt-in consent“. Anything else is unacceptable.
- Where is my data processed? Concretely: in which country, in which data centre, by which sub-processor. EU hosting alone does not yet mean GDPR conformity; US hosting does not yet mean automatic inadmissibility. Which case applies to you, you have to know before you can assess it.
- How long are my inputs stored? Storage beyond the processing needs two things: a written justification and a concrete deletion date.
- Who has access to my inputs in exceptional cases? Keyword abuse prevention: many providers store inputs for 30 days for abuse monitoring. You have to be able to know this, assess it, and where appropriate exclude it contractually.
- What happens to the processed data at the end of the contract? Deletion obligation, deletion deadline, written confirmation of deletion.
„We don’t use your data for training“ on a marketing slide is not an answer. The answer is in the contract. If the provider does not deliver this in writing, they are not the right provider, regardless of how good the demo looked.
The Bitkom practical guide „AI & data protection“ in its second edition provides the detailed contractual basis for these five points and is usable as a starting point for your own data-protection impact assessment.
Structured content first, AI afterwards
Here the circle closes to the actual question: what has to happen before AI is introduced? The sober answer: the same as before any other process or tool introduction. The content has to be modular, the terminology has to be maintained, reuse has to be lived as a principle.
That is exactly the groundwork that also makes a CCMS migration a success. Anyone who tackles both in parallel has a double benefit: the structured data base improves reuse immediately and sharpens the AI outputs later. Anyone who deploys AI on an unstructured data base burns the money more slowly, but reliably.
As a file format for intelligent delivery, iiRDS has established itself as an industry standard in recent years. Anyone structuring content today should do so with iiRDS in mind, otherwise the next migration effort awaits in two years.
What deploying AI realistically delivers
The question „how much will AI save us?“ is the most common in my initial consultations. The sober answer depends on the starting state, and it is usually uncomfortable.
A writing department without structured content, without maintained terminology, and without clear processes catches additional effort in the first year. Sorting, checking, structuring, correcting. The saving only comes once the data base is in place. That is not a sales message, but it is the truth.
A writing department with a maintained CCMS, clean terminology, and defined document types realistically achieves a 20 to 35 % reduction in effort on translations, 30 to 50 % on consistency checks, and 10 to 20 % on first drafts for standard documents. I see these figures consistently. But they are the result of the groundwork, not of the AI itself. The groundwork has its own return, entirely independent of the later AI deployment: it lowers the cost of poor documentation.
An introduction plan in six steps
So that you don’t start with a tool comparison but with the actual bottleneck, here is the order that has worked in my projects:
- Inventory. Which document types do you create, in what quantities, with what current effort per document? Without this base, all later statements about „savings“ are guesses in the dark.
- Define the pilot area. One document type, one product line, one language direction. Not the entire portfolio, not localisation into 14 languages at once. Start small.
- Set down the quality criteria. What distinguishes a good output from a mediocre one? Who decides that, when, and by what yardstick? In writing.
- Check and bring up the data base. Terminology, modules, reuse rules. This phase is uncomfortable. Without it, the other five steps do not work.
- Tool selection with a data-protection check. Only once the first four steps are completed is it worth comparing providers, guided by the five questions named above.
- Pilot, measure, decide. Three months’ duration, clear metrics, documented findings. Only then the scaling decision.
That sounds like more effort than „just buy a tool“. It is. But it is the order that is still sustainable in two years. The quick variant grinds to a halt after 18 months, because the data-base discussion then starts up again, only under greater pressure.
Where is AI worthwhile in your writing department, and where not?
Before you select a tool, a sober look at your data base and at the tasks where a model actually takes effort off your hands pays off. Schübeler Consulting carries out the inventory with you, examines the regulatory implications for your industry, and draws up a pilot plan that fits the size of your team.
Initial consultation: info@schuebeler-consulting.de or via the website.
Johann Jörgen Schübeler, Schübeler Consulting