Technical documentation authoring: operating manuals & safety instructions (CCMS)

Every machine, device and appliance sold in the EU must ship with instructions. These are a regulated part of the product: warnings have to follow from the risk assessment, and the content must be produced in every market language and for every variant. Technical writers spend most of their time on routine work. They turn engineering data into procedures, rephrase text into controlled language, tag modules with metadata and look for reusable content. Generative AI built into the component content management system (CCMS) now drafts warning notices and step-by-step instructions from keywords or risk analyses, checks style and terminology, and classifies modules automatically. The writer stays the accountable author, and the result is ready for MT (LANG-009) and digital delivery.

Problem & value

• Who: technical writing departments at machine and plant builders, automotive and component suppliers, and medical-device and appliance makers, plus their documentation service providers. In the Mittelstand this is often a team of 1–5 people serving hundreds of product variants.
• Today: writers collect information from design engineers, CAD/PLM and the risk assessment. They write modules in a CCMS (Quanos SCHEMA ST4, DOCUFY COSIMA, MadCap IXIA, Paligo, Heretto), run checks with rule-based authoring tools (Congree, Acrolinx) and send the result for translation. Content grows, duplicates pile up, metadata is inconsistent and engineering changes are missed.
• Regulatory pressure: the EU Machinery Regulation (EU) 2023/1230 applies from 20 January 2027 and allows instructions to be supplied digitally instead of on paper. That shifts the deliverable from a PDF to modular, metadata-rich content that can be delivered by serial number and variant [1][2]. tekom notes that some details of the digital-instruction rules still need clarification [2].
• AI value: faster first drafts of procedures and warnings, consistent wording (which also lowers translation cost, since reused segments are not translated again), automatic metadata for content delivery, and detection of redundancies. No independent, published productivity figures existed as of 2026-10. Vendors and tekom describe efficiency gains only qualitatively [3][4], so measure your own baseline.

Variants

• Operating, assembly and maintenance manuals (core): machinery under 2023/1230 and IEC/IEEE 82079-1.
• CE technical-file content (scope variant): drafting text parts of the technical documentation required by the Machinery Regulation, such as the risk-assessment narrative, a list of applied standards and a draft declaration of conformity, from engineering inputs. A qualified person must sign it off. Risk-assessment software such as DOCUFY Machine Safety supplies the hazard list that warnings are derived from [4].
• Information on demand / iiRDS packages: classified modules delivered to content delivery portals, service apps and RAG assistants (KNOW-004). iiRDS 1.3 was released in November 2025 [5].
• Medical devices: IFU under MDR Annex I §23, including electronic IFU (eIFU) under Implementing Regulation (EU) 2021/2226. This is close to regulatory writing (HLTH-017).
• Consumer products: instructions and safety information under the GPSR (EU) 2023/988, often with plain-language versions (LANG-010).
• Software documentation is out of scope. See CODE-006.
• Private use: not relevant.

How it works

1. engineering inputs (BOM/PLM change, CAD views, risk assessment, service feedback)
2. retrieval of existing modules + terminology + style rules (RAG over the CCMS)
3. LLM drafting in the CCMS editor: procedure steps, descriptions, warnings (SAFE: Signal word, nature And source of hazard, consequences, escape/avoidance) from hazard entries
4. rule-based controlled-language & terminology check (deterministic guardrail)
5. automatic metadata classification (product, variant, information type, lifecycle phase; iiRDS)
6. reuse/redundancy detection (embedding similarity against existing modules)
7. technical review by writer + engineer; safety-relevant modules: mandatory sign-off ◀ human
8. publication per variant (PDF, HTML5, iiRDS)
9. MT + post-editing (LANG-009)
10. delivery portal

• Drafting: a general LLM with prompts from a shared prompt library, grounded in the existing modules. Output must be valid XML for the CCMS schema (DITA, PI-Mod or proprietary). Use schema-constrained generation or post-validation.
• Checking: rule-based linguistic engines (Congree, Acrolinx) act as deterministic guardrails on top of generated text, so the same input gets the same verdict [6][7].
• Classification: small LLMs or fine-tuned classifiers assign taxonomy classes. This is where AI has been in production longest, for example Quanos plusmeta and the ST4 AI Jetpack [3].
• Human-in-the-loop: a qualified author owns each module. Warnings and safety instructions are never released without review against the risk assessment.

Data preparation

This use case lives or dies with structured content. Relevant data: existing manuals and modules (DITA, PI-Mod, Word, InDesign, PDF), the terminology database, style guide, BOM and variant data from ERP/PLM, risk assessments and hazard lists, and service reports. In an SMB much of this sits in Word files on file shares, in scanned legacy manuals and in the heads of a few senior writers.

Typical gaps: unstructured Word/PDF manuals, duplicate and near-duplicate paragraphs, inconsistent terminology, missing metadata (product, variant, target group), outdated versions, and no link between hazards and warnings.

Steps: - Inventory manuals and engineering sources (PREP-001, PREP-005). - Convert legacy formats and scans to clean text or XML (PREP-006, PREP-007, DOC-014). - Split content into modules and tag it with metadata (PREP-010). - Consolidate terminology and abbreviations (PREP-015). - Collect approved gold-standard modules as examples (PREP-016).

Tools: the CCMS itself, OCR and document parsing, a duplicate finder, a vector database. Plan about 50 percent of total effort for content migration and metadata; AI adds little value on unstructured content.

Implementation paths

Which path for whom

• SMB: A, because established CCMS and authoring-assistant vendors already embed AI at SMB prices, with EU hosting, and the documentation process is standard.
• Enterprise: B, because documentation is tied to PLM, variant data and translation workflows that need custom integration and cost control at high volume.
• Developer: C, because open models plus your own terminology and module corpus give full control for building assistants and checkers.

Path A — Buy (recommended for most SMBs)

• AI inside the CCMS (EU vendors marked †):
• † Quanos SCHEMA ST4: ST4 AI Writer drafts warnings and step instructions from keywords, text or risk analyses and rewrites passive voice. ST4 AI Jetpack assigns metadata. ST4 AI Translator uses DeepL [3].
• † DOCUFY COSIMA: an "AI-supported" XML editorial system [4].
• † Paligo (Sweden): writing improvement plus Nexus Answers, a cited Q&A over published content [8].
• Heretto: the Etto copilot for drafting, summarising and improving readability [9].
• MadCap IXIA CCMS: for DITA, with AI-readiness/Syndicate delivery [10].
• Authoring assistance and governance: † Congree (Karlsruhe) combines rule-based linguistics with generative AI [6]. Acrolinx, now part of Markup AI, offers terminology/style governance and agents, with an MCP integration [7].
• XML editor add-on: Oxygen AI Positron for DITA topic creation. It can draft from Word, PDF or images and supports OpenAI, Claude, Gemini, Bedrock or a private LLM instance [11].
• Choose A when: you already run a CCMS. Activating its AI features is the lowest-risk start, because output stays in the validated content model. Check where the LLM is hosted (EU region), data-processing terms and whether your content is used for training.

Path B — Build on cloud APIs

• Models: Mistral (EU provider, La Plateforme or Azure/AWS EU regions), Claude (AWS Bedrock Frankfurt or Google Vertex EU), GPT via Azure OpenAI EU Data Zone, Gemini on Vertex EU. DeepL API for translation.
• Pattern: a RAG service over a CCMS export (DITA/XML), plus a prompt library per information type, plus XML schema validation, called from the CCMS through its API or from Oxygen's private-LLM connector. Add an embedding index for reuse detection and a classifier for iiRDS metadata.
• Choose B when: the CCMS has no AI module, or you need custom workflows such as PLM-change triggered update proposals or risk-assessment-to-warning generation.

Path C — Self-host (open source)

• Models: Mistral Small 3.x (24B), Qwen3 (e.g. 30B-A3B) or gpt-oss-20b for drafting. gpt-oss-120b or larger Qwen3 models on HW3 for higher quality. A small model (≤ 8B) or a fine-tuned encoder for metadata classification. bge-m3 or multilingual-e5 embeddings in Qdrant/pgvector.
• Stack: vLLM or Ollama with structured output, the DITA Open Toolkit for publishing, and LanguageTool or custom rules for controlled language. Docling turns legacy PDF manuals into structured topics for migration.
• Hardware: HW2 (one 24–32 GB GPU) is enough for a team of writers with a ~24–30B quantised model. HW3 for 120B-class models or many concurrent users.
• Why: unreleased product designs and risk assessments are trade secrets. Many machine builders want them on-prem.

Path D — Custom training

Worth it mainly for metadata classification and house-style adaptation. Thousands of already-classified modules in the CCMS are ready-made training data for a classifier or a LoRA on a small LLM. Fine-tuning a drafting model on your own manuals helps with tone and terminology but not with factual correctness. Grounding in engineering data matters more. Not worth it below a few thousand modules.

State of the art (2026)

• CCMS-native generative assistants are now standard features rather than pilots. Quanos ships four AI tools in the ST4 standard package [3]. Heretto, Paligo and Oxygen offer copilots [8][9][11].
• Hybrid AI + rule-based checking: the field has settled on generative drafting followed by deterministic controlled-language and terminology checks, because LLM output varies from run to run [6][7].
• Structured content as AI fuel: vendors position modular DITA/iiRDS content as the source for RAG assistants and AI search, so authoring and delivery (KNOW-004) are converging [5][10].
• Agentic authoring: agent modes in XML editors create or update topics across a project from Word, PDF or image input [11]. tekom/tcworld discusses Skills.md-style instruction files for consistent agent output, and risk-based governance of AI-generated content [12].
• No public benchmark exists for manual drafting quality. Evaluate on your own modules.
• Limits: LLMs invent plausible but wrong values such as torques, intervals or residual-risk statements. They can omit hazards that are not in their context and weaken warning wording. They cannot see the physical machine, so steps must be checked against CAD or the real machine. Multimodal drafting from CAD views is still immature.

Shared resources & combinations

• Downstream: LANG-009 (MT for all EU languages, the most common combination), LANG-010 (plain-language/easy-read safety info), KNOW-004 (technician assistant reading the same iiRDS content), KNOW-021 (spare-part search linked to manual modules), KNOW-011 (FAQ generation).
• Upstream: DOC-013 (reading engineering drawings for figure legends and part lists), KNOW-027 (SOPs from screen/expert videos), LANG-040 (risk assessments in occupational health and safety; same hazard logic, different legal basis), DOC-023 (SDS data for hazardous-substance warnings).
• Neighbours: LANG-011 (style/brand rewriting, same rule engines), LANG-003 (business reports), CODE-006 (software docs), HLTH-017 (MDR/regulatory writing).
• Shared building blocks: one EU-hosted or on-prem LLM endpoint (HW2/HW3), one embedding index over the CCMS, the terminology database and the iiRDS/PI-Mod taxonomy. These serve authoring, translation QA and the service assistant (KNOW-004) together.

Effort, cost & KPIs

• Path A: weeks to activate CCMS AI features. Most effort goes into the prompt library, style rules and terminology. Licences are usually an add-on to the CCMS subscription.
• Path B/C: 2–4 months for a RAG + drafting service with XML validation and CCMS integration. Path C adds one GPU server and MLOps effort.
• Cost drivers: CCMS licences, content clean-up and migration (often the largest item), and translation volume. Cleaner reuse lowers translation cost.
• KPIs: hours per new manual or variant, reuse rate, terminology/style violations per 1,000 words, share of modules with complete metadata, translation cost per publication, review rework rate, and field feedback/service tickets traced back to documentation errors.

People & change

Involve management and the documentation lead first, then engineering and product safety as data owners for risk assessments and variant data. IT handles CCMS integration and accounts, legal-compliance clarifies liability for safety warnings, and suppliers deliver component documentation. Technical writers are the core end users and should help design the workflow from the start.

Works council: depends. Where the system only drafts text, co-determination is unlikely; if the CCMS or AI assistant logs individual writers' output or corrections, it can qualify under §87(1) no. 6 BetrVG, and §90(1) no. 3 requires timely information when work processes change. Engaging an expert is possible under §80(3).

Data protection: manuals contain little personal data, but service reports and prompts may; check with the DPO and conclude an AVV (Art. 28 GDPR) with any cloud provider. AI literacy: support writers with training on hallucinated values, controlled language and review duties (AI Act Art. 4; GUIDE-006). Pilot with one product line and two or three writers. Common fear: "AI replaces technical writers". Address it by shifting their role to review, risk logic and quality, and by stating that every safety-relevant text is approved by a qualified person. See GUIDE-008 and GUIDE-004.

Risks, regulation & compliance

• EU AI Act: an authoring assistant is typically minimal risk. It is not a safety component of the machine, and Annex III does not list it. Art. 4 AI literacy applies. Art. 50 transparency obligations fall on providers of generative systems and on deployers of deepfakes or public-interest text. Reviewed technical documentation under the manufacturer's editorial responsibility is generally outside Art. 50(4) [13]. This does not change the manufacturer's liability for the content.
• Product law: under the Machinery Regulation 2023/1230 (Annex III 1.7.4) and IEC/IEEE 82079-1, instructions are part of conformity. Faulty instructions can make a product non-compliant and, under the new Product Liability Directive (EU) 2024/2853, defective. Other sector rules: GPSR 2023/988 for consumer products, MDR for IFU. AI does not shift responsibility. Document who reviewed and approved every safety-relevant module.
• Safety-specific risks: warnings that do not match the risk assessment, hallucinated values, and variant mix-ups. Mitigations: generate warnings only from the hazard entries in the risk assessment, enforce the SAFE/ANSI Z535.6 structure, use mandatory four-eyes review, and check values automatically against PLM data.
• GDPR: content rarely contains personal data. Author names and review logs are personal data under normal employment rules.
• Confidentiality / IP: product designs before launch are trade secrets. Use EU hosting with no-training terms, or Path C.

Getting started

1. Clean up first: consolidate terminology, the style guide and the module taxonomy in the CCMS. AI quality depends on them.
2. Activate or test your CCMS vendor's AI features, such as ST4 AI Writer or Heretto Etto, on 20 real modules, including warnings drafted from a real risk assessment.
3. Add a deterministic check layer (Congree, Acrolinx or rule sets) and measure violations before and after.
4. Automate metadata classification for iiRDS delivery, with a sample-based human check.
5. Before the Machinery Regulation applies in January 2027, plan the move to digital instructions and link the same content to MT (LANG-009) and the service assistant (KNOW-004).

Sources

1. European Commission — Machinery (Regulation (EU) 2023/1230, application 20 January 2027) — https://single-market-economy.ec.europa.eu/sectors/mechanical-engineering/machinery_en
2. tekom — Whitepaper "Neue Maschinenverordnung (EU) 2023/1230" — https://www.tekom.de/die-tekom/publikationen/fachbuecher/detail/neue-maschinenverordnung
3. Quanos — SCHEMA ST4 (ST4 AI Writer, AI Jetpack, AI Translator, AI Language Factory) — https://quanos.com/en/products/schema-st4/
4. DOCUFY — COSIMA, Machine Safety and product overview — https://www.docufy.de/en/
5. iiRDS — Intelligent Information Request and Delivery Standard (v1.3, Nov 2025) — https://iirds.org/
6. Congree Language Technologies — https://www.congree.com/
7. Acrolinx (Markup AI) — https://www.acrolinx.com/
8. Paligo — AI features (Nexus Answers) — https://www.paligo.net/
9. Heretto — Etto AI copilot — https://www.heretto.com/
10. MadCap Software — IXIA CCMS — https://www.madcapsoftware.com/products/ixia-ccms/
11. Oxygen XML — AI Positron Assistant — https://www.oxygenxml.com/ai_positron.html
12. tcworld e-magazine — AI in technical communication articles — https://www.tcworld.info/e-magazine/
13. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
14. tekom — Whitepaper "KI in der Technischen Kommunikation" (2024) — https://www.tekom.de/services-unsere-angebote/publikationen/fachbuecher/detail/ki-in-der-technischen-kommunikation
15. Regulation (EU) 2023/1230 (Machinery Regulation) — https://eur-lex.europa.eu/eli/reg/2023/1230/oj