AI can update individual help articles, but it cannot reliably maintain a documentation set without structured content because unstructured docs contain hidden duplicates that AI updates inconsistently. A security disclaimer might appear in 40 pages across a wiki. When the policy changes and AI rewrites the disclaimer on page 12, the other 39 pages keep the old wording. AI does not see them as related — to a wiki, they are just similar paragraphs sitting in different documents.
This article is not an argument against AI in documentation. It is an argument against unstructured AI in documentation. Components, conditions, and variables are the guardrails that turn AI from a fast typist into a reliable maintainer. Tools that promise AI replaces the content model are selling a shortcut that breaks somewhere between 30 and 50 pages.
The failure mode: silent drift across hidden duplicates
When a documentation team uses a wiki, page-based tool, or any system without component reuse, identical or near-identical content gets duplicated across pages. This is not a discipline problem. It is what the tool encourages. Two writers, two months apart, each write a security disclaimer. The wording is 92 percent the same. Neither knows the other exists.
Now you point AI at the corpus and ask it to update the security disclaimer when policy changes. What happens depends on how the AI was prompted, what context window it had, and which documents were retrieved when the update ran. In the best case, the AI finds all 40 instances and rewrites each one. In the realistic case, it finds the 8 it was shown, rewrites those, and leaves 32 untouched. In the worst case, two separate AI runs across a few weeks update overlapping subsets — a handful of pages get version A of the new disclaimer, another handful get version B, and the rest keep the original.
Three months later, you have 40 versions of what should be one paragraph. Eight are updated. A dozen are not. The rest are half-updated by a different AI run with different instructions. The audit trail does not tell you which one is canonical because there is no canonical version — just 40 pages that all look authoritative.
This is not a hypothetical. It is the predictable outcome of running probabilistic updates against a content model with no shared identity between duplicates.
The three guardrails: how structured content fixes this
Structured content provides three mechanisms that turn AI updates from inherently risky to predictably correct. Each one removes a class of failure that unstructured tools cannot prevent at the model level.
Components — one source, every reference updates
A component is a block of content stored once and referenced from every topic that uses it. When you update the source, every reference reflects the change. There are not 40 disclaimers. There is 1 disclaimer used in 40 places. AI updates the source. The 40 references update because they are not copies, they are pointers.
DITA implementations have called this conref (content reference) since the DITA 1.3 specification and earlier. Newer cloud-native tools like Paligo and Topicary call them components or snippets. The mechanism differs. The guarantee is identical: there is no duplicate to fall out of sync because there is no duplicate. For a deeper look at how this works without writing XML, see structured authoring without the XML.
Conditions — variant awareness, not accidental crossover
Conditional content tells the system which audience or context a block of content serves. A setup guide might have a block tagged platform="windows" and another tagged platform="macos". When AI is asked to update the Windows setup steps, conditions tell it exactly which blocks are in scope and which to leave alone.
Without conditions, AI sees two paragraphs that look like setup steps and updates both, or guesses which to change based on the surrounding prose. With conditions, the boundary is explicit and machine-readable. AI cannot accidentally rewrite the macOS instructions while updating Windows, because the metadata draws the line for it.
Variables — swap a value, not a sentence
Variables let you reference a value by name. The product is product_name. The current release is current_version. The support email is support_email. When the version increments from v2.3 to v2.4, you change the variable definition. Every reference updates.
This matters for AI because variables convert a high-risk operation — rewriting prose to change a version number — into a low-risk one: replacing the value of a named variable. AI does not need to interpret the sentence around the version number. It updates a key-value pair. The prose is untouched. There is no risk of an LLM "improving" the sentence at the same time and quietly changing its meaning.
AI updates: unstructured vs. structured content
| Dimension | Unstructured (wiki, page-based) | Structured (component-based) |
|---|---|---|
| Duplicated passages | Dozens of independent copies | One source, multiple references |
| Update propagation | AI must find every copy | Update source, references reflect it |
| Audience-specific content | Mixed in prose, scope inferred | Tagged with conditions, scope explicit |
| Version numbers, names, URLs | Embedded in sentences | Variables, swapped by key |
| Drift risk | High and silent, accumulates | Structural — a reference cannot drift without breaking |
| Audit trail | Diff against per-page history | Diff against component history plus reference graph |
| Cost of one wrong update | Repeated across every duplicate | Caught at the source, fixed once |
The last row is the one that matters most in regulated environments. A wrong update to a single safety warning in a structured system is a wrong update in one place. The same wrong update in a wiki is a wrong update in every page that quoted the warning — and you have no inventory of which pages those are.
When AI-first tools are the right call
The case for AI-first, structure-light tools is real. Tools like Documentation.AI (formerly Archbee), Ferndesk, and StorytoDoc are faster to set up than a component-based CCMS. They have lower learning curves. Their AI features are typically more polished because they ship with the tool rather than bolted on years later.
Use an AI-first tool when:
- Your documentation site is under 30 to 40 pages
- You publish to a single output — a web help center, not PDF and Markdown and print
- You serve a single audience with a single product, no platform variants, no plan tiers, no audience-specific content
- You are not subject to regulatory or compliance requirements that demand audit trails
- The cost of a content drift incident is low — you can fix a wrong page when the next user complaint arrives
This describes a real and substantial set of teams. A SaaS startup with 25 help articles, one product, and a single tier does not need component reuse. The overhead of a CCMS would slow them down. AI-first tools serve them well, and the productivity gains from in-tool AI are immediate.
When you need structure first
The economics flip when any of the following are true:
- Content is reused across products, versions, platforms, or audience tiers
- Your documentation publishes to more than one format — web plus PDF, plus Markdown, plus print
- You operate in a regulated industry — medical devices, financial services, aerospace, automotive
- You have more than 50 topics with shared passages between them
- A wrong update reaching production has measurable business cost — recall, fine, churn, support spike
In these cases, structured content is not an optimization. It is a prerequisite. AI applied to an unstructured corpus at this scale produces drift faster than humans can audit it. Structure gives AI the constraints it needs to make updates that propagate correctly.
A useful test: count the number of times any sentence in your docs appears more than once across pages. If the answer is over 20, you are already paying the duplication tax. AI updates against that corpus will not fix it. They will compound it.
What the AI-first tools get right
It would be dishonest to dismiss the AI-first approach. Documentation.AI's editor is genuinely good. Ferndesk's onboarding is faster than any traditional CCMS. StorytoDoc's screen-recording-to-documentation flow handles a real workflow problem that structure-first tools handle poorly.
These tools are betting that AI capability will improve quickly enough to overcome the structural limits of unstructured content. That bet is reasonable for narrow use cases. For others, no amount of AI improvement closes the gap, because the problem is not "AI is not smart enough." The problem is that the content model has no concept of shared identity between duplicates. A smarter model still cannot update a duplicate it cannot recognize as a duplicate.
The honest framing is that AI-first tools have raised the floor of what a small team can produce. They have not raised the ceiling of what a large team can maintain without structure.
How structure-aware AI works in practice
The tools that combine structured content with AI fall into three rough categories.
- Enterprise DITA platforms with AI add-ons — IXIASOFT, Heretto, and MadCap IXIA CCMS. AI assists with content review, link suggestions, and reuse identification. The structural layer is XML-based, which is powerful but has a steep adoption curve.
- Cloud-native structured authoring with AI — Paligo and Topicary. Components, conditions, and variables in a visual editor, plus AI for writing assistance, content findings, and reader-facing search. No XML required.
- Middle ground — GitBook offers limited reuse through reusable content blocks and an AI assistant. The reuse model is shallower than a CCMS, but the AI features are first-class.
The pattern across the structure-first tools is consistent. AI is given the content graph — which components exist, which topics reference them, which conditions apply, which variables are in scope — and operates within that graph. A request to update the security disclaimer updates one component, and the 40 references update with it. A request to rewrite Windows setup steps filters by the Windows condition and updates only those blocks. The AI's blast radius is bounded by the structure, not by the size of its context window or the quality of its retrieval.
This is what people mean when they say structure makes AI safer. It is not that structured tools have better AI models. It is that the model is constrained to operate on objects with explicit identity, scope, and references. Most of the failure modes of AI on unstructured content come from the model guessing at all three. Structure stops the guessing.
For side-by-side detail on how Topicary's approach compares with the AI-first model, see Topicary vs Documentation.AI. For a comparison against the enterprise DITA model with AI add-ons, see Topicary vs MadCap.
The takeaway for a documentation team in 2026
The choice is not AI or structure. The choice is whether your content model gives AI the constraints it needs to be reliable. AI-first tools work when the documentation is small enough that drift does not happen. Structured tools work because drift cannot happen. As your documentation grows, the second category becomes the only one that scales.
If you are evaluating tools today, the question to ask vendors is not "do you have AI." Every tool has AI. The question is "what does AI operate on — pages, or components." If the answer is pages, you have bought a faster way to produce drift. If the answer is components, conditions, and variables, you have bought AI on top of guardrails that make the AI's output trustworthy.
That is the bet worth making.
FAQ
Does AI replace the need for a CCMS?
Not at the scale where a CCMS matters. AI improves the speed of writing and updating individual pieces of content, but it does not create shared identity between duplicates. If your content has hidden duplicates — which any wiki or page-based system accumulates over time — AI will update a fraction and miss the rest. A CCMS prevents duplicates from existing in the first place, which is the structural problem AI does not solve.
Are AI-first documentation tools bad?
No. They serve teams with small documentation sets, a single audience, and a single output channel well. The problem is not the tools, it is the assumption that they scale to large, multi-audience, multi-channel documentation without a content model. Use them where they fit. Move to structured tools when you outgrow them.
What is content drift in documentation?
Content drift is the silent divergence of duplicated content over time. When the same paragraph appears in 40 pages and only a handful of copies get updated, the duplicates drift apart. Certain users see version A. Others see version B. Still others see a half-updated hybrid. Drift is the default outcome of any system that stores duplicates instead of references.
Why does AI struggle with conditional content in unstructured docs?
Because the audience or context of a block is implicit in the surrounding prose, not tagged as metadata. When AI is asked to update the Windows setup steps, it has to infer which blocks are Windows-related from the words around them. In a conditional content system, the boundary is explicit — the block is tagged platform="windows" and AI knows precisely what is in scope. Inferring scope from prose works part of the time. Reading explicit conditions works every time.
Can I add structure to an unstructured documentation site later?
Yes, but it is more work than starting structured. Most CCMS platforms can import Markdown, HTML, Confluence, or Word content. The harder part is identifying duplicates that already exist as separate pages and converting them to shared components. It is a one-time content engineering exercise. Whether it is worth doing depends on how much duplication has accumulated and how frequently that duplication is causing real incidents — for a documentation set under 50 pages with infrequent updates, the migration cost may exceed the drift cost. For anything larger, the math reverses.
Does Topicary use AI?
Yes. Topicary has AI features at both ends — an AI assistant in the editor for drafting and rewriting, and an AI search widget on published sites for readers. Both run on top of the structured content model rather than against unstructured pages. The structure is the reason the AI features work reliably at scale.
Sources
- OASIS. DITA v1.3 Specification — Content reference (conref). 2018. oasis-open.org
- Net-Effect. Measuring ROI of Structured Content. 2023. net-effect.com
- Paligo. What is a CCMS? 2024. paligo.net