Zeitalter der KI: Phasen, Kontrollpunkte und Grenzen

Analysis turns a product, its users and their situations into the needs that documentation has to serve — before any text exists.

Questions to ask at this stage:

• Which tasks do users have to perform, and in which situations?
• Which sources already answer them, and where do they contradict each other?
• What is out of scope, and who agreed to that?

AI is useful here as a reader: it can go through existing manuals, tickets and specifications faster than anyone and show what is there and what contradicts itself. What it finds is evidence of what exists. It is not evidence of what the product requires.

The analysis also sets what the documentation will never promise. That boundary is the first thing the machine needs to know, and it can only be drawn here.

• A topic list is not an analysis.
• What exists is not what is required.

What nobody analyzed is later filled with what the tool happens to know.

Modeling turns the analyzed need into units with meaning, metadata and relations, so that every later stage works on the same structure.

Questions to ask at this stage:

• Which unit carries which meaning, and where is that written down?
• Which metadata does a unit need to be found, reused and traced?
• Which terminology is fixed here, and where is it kept for the whole company?

The model is where meaning is decided once, so that it doesn’t have to be decided again in every text, every translation and every answer. AI can propose units and relations from existing content. Defining what a term means is a decision, and it stays one.

Terminology fixed in one project ends with that project. The model belongs to the company, and the terminology with it.

• A document is not a unit.
• A reused sentence is not a modeled unit.

What is not modeled is decided again at every later stage.

Creation writes the text that will be released: structured, in the terminology of the model, with its sources recorded.

Questions to ask at this stage:

• Which sources does this sentence rest on, and are they recorded?
• Where did AI draft, and what did the author change?
• Which safety-related information may not be shortened under any circumstances?

A draft written with AI support is a derived output until the author has made it their own and it has passed the gate. Recording what AI drafted is not a confession. It is the evidence that someone looked.

Fluent text hides missing sources well. The stage asks for the source of every claim, not for the quality of the sentence.

• A draft is not a source.
• A summary is not the information it summarizes.

Every sentence that arrives without a source leaves a decision unmade.

Verification checks content against its sources, against the model and against what the product requires, and records what was checked.

Questions to ask at this stage:

• Which claims are checked against which source?
• What did AI check, and what did a person check?
• How deep is the check, given what a mistake in this content would cause?
• Which findings are still open, and who closes them?

AI can check a great deal: terminology, style, completeness against a model, consistency between versions. It can’t declare content correct, because correctness is measured against the source and the product, not against another output.

Not every text needs the same depth of check. The depth follows the consequence of a mistake: safety-related and required information always gets the deepest check, whatever the deadline.

• Checking an output against another output is not verification.
• A style check is not a content check.

What was not checked against a source is not verified by being fluent.

Approving the source is the first and most important passage through the gate: a named person releases a version and takes responsibility for it.

Questions to ask at this stage:

• Who is accountable for this content, by name?
• What is still open, and does it have to be closed first?
• Which languages, variants and delivery channels does this release cover?

Everything before this stage proposes. Everything after it depends on it: the version, the translation, the publication and every answer built from the content.

The strength of the gate follows what can’t be undone later. A release that will be translated into twenty languages and answered from thousands of times needs a stronger gate than a note on an internal page.

• A completed review is not an approval.
• A tool can prepare a release; it can’t be the accountable role.

A release without a name is a decision nobody made.

Managing keeps released versions traceable and links them to the changes that produced them.

Questions to ask at this stage:

• Which version is current, and who says so?
• What depends on this version: translations, publications, answer functions?
• What happens to derived output when the source changes?

Once content is released, the machine starts answering from it. Every change of the source changes what the answer functions may say, so the version history is also the history of the answers.

Derived output doesn’t get a version of its own in the source. It is marked as derived and stays where it was used.

• The newest file is not automatically the released version.
• Derived text is not a version of the source.

Two truths are one truth too many.

Translation carries the released meaning into other languages and markets, and localizes what has to differ without changing what must not.

Questions to ask at this stage:

• Which terminology applies in this language?
• What did the machine translate, and what did a post-editor change?
• Which safety wording may not be adapted to fit?
• Who releases this language version?

Machine translation with post-editing is the oldest working model of AI in documentation: the machine produces, a person edits against the source and answers for the result. It is a good model for every other stage.

Every language version passes the gate on its own. A translation is not released because its source was.

• A translated sentence is not a reviewed sentence.
• Localization adapts form and context, not the required information.

The source text decides; the translation serves it.

Publishing turns the released version into the artifacts and channels in which people and the machine actually meet it.

Questions to ask at this stage:

• Which channels and formats serve which task?
• Which metadata travels with the content, so that the machine knows what it is reading?
• Where can a reader or the machine find the current version?
• What is deliberately not published?

Publishing is the last stage at which the company decides alone what can be read. After it, the content is read inside the company by its answer functions and outside by the answer functions of others.

That is why this stage also decides what stays unpublished, and how the published content says what it is, for whom and in which version.

• A published artifact is not a new version.
• Conversion may not change meaning.

What is published is what was released — or it is a second source.

Answering is the stage at which the machine reformulates released content for one question in one situation, and the user receives a text that nobody released.

Questions to ask at this stage:

• Which sources may this function answer from, and where must it stop?
• Can the answer be traced back to its sources and to the model version it used?
• What happens when no released source answers the question?
• Who checks the answers again when the model, the gateway or the settings change?

Nobody can release every answer. What is released is the answer function: the sources it may use, the warnings, limits and required information it may never leave out, and what it does when it has no source. That release is a passage through the gate like any other, and the answer and delivery steward answers for it.

The machine changes without the content changing. A new model, a new gateway, new settings or a new retrieval index change the answers as much as a new version of the source. A change of the machine is a change in the lifecycle, and it calls for a new check of the function.

• The answer serves the source; the source is not the answer.
• A reformulation is not a release.
• An unchanged source is no proof of unchanged answers.

The lifecycle doesn’t end at publishing. It ends where the answer arrives.

Use produces feedback: questions, errors, missing topics and answers that worked. Feedback changes the source only through the gate.

Questions to ask at this stage:

• Which questions come back that no source answers?
• Which answers were wrong, and which sources and which model version did they use?
• How does a finding become a change of the source?
• What is recorded about the user who asked, and for how long?

Feedback is the stage at which the lifecycle closes into a loop. It is also the stage at which derived text most easily flows back into the source: an answer that worked is copied into a topic, a cluster of questions becomes a page that nobody released.

Questions come from people. Recording them is useful and is also a decision about their data, made once in governance and not anew by every tool.

• A user question is not a requirement.
• Feedback doesn’t edit the source; it starts the next pass.

A correction that stays in the answer never reaches the next reader.

Maintenance keeps content valid over the life of the product, and withdraws or archives what no longer applies — without losing the trace.

Questions to ask at this stage:

• What still applies after a change of the product?
• Who decides that content is withdrawn, and what replaces it?
• Do the answer functions stop answering from withdrawn content?
• What remains readable after a withdrawal, and for how long?

A withdrawal is a passage through the gate: someone decides that content no longer applies and answers for that decision. It reaches the answer functions only if they stop using the withdrawn version.

Content that is no longer valid is still evidence of what was once released. The trace stays, even when the content goes.

• Archiving is not deleting.
• A withdrawn version stays traceable.

What was released once stays part of the record.

The gate is not a stage. It is the one form of decision in which a named person releases something and answers for it — and it is passed wherever something is released.

Questions to ask at every gate:

• Who passes the gate, and is that person named?
• What exactly is released: which version, which language, which function, which withdrawal?
• Which items are still open, and were they accepted knowingly?
• How strong does the gate have to be, given what can’t be undone after it?

The gate is passed when a source is released, when a language version is released, when an answer function is released with its sources, when feedback is taken into the source and when content is withdrawn. It is the same gate each time: one person, one release, one record.

A tool can prepare the gate — collect what is open, compare versions, list what a change affects. It can never pass it. Passing the gate is the moment at which responsibility becomes visible, and responsibility can’t be delegated to the machine.

• One gate, passed many times.
• A prepared release is not a release.

Everything before the gate proposes. Everything after it depends on it.

Governance is not a stage. It is the set of rules, roles, gates and records that apply at every stage, decided once and referred to everywhere.

Questions to ask across the stages:

• Which rules apply to every project, and where are they written?
• Which content may go into which AI service, and which may not leave the company?
• Into which risk classes is content divided, and how strong is the gate for each?
• Who releases a new answer function, a new source or a new language?
• Which records are kept, for how long, and what do they contain about people?

Governance decides the conflicts between the stages before they arise: how deep a check has to be, what an answer may never leave out, what is recorded about users, and what happens when the model changes.

It also decides what leaves the company. Sources, drafts and unpublished product data travel into the services of others at several stages. Which content may go where is decided once, at the point where the company reaches into the machine, not by every author with every prompt.

• Governance is not a stage you pass.
• A rule kept in one project is not a company rule.

Rules that live in one project end with it.

The boundary marks the line between what the company released and answers for and what the machine derived from it. On its other side lies text from outside that nobody in the company released.

Questions to ask at this boundary:

• Is this text a released source or a derived output?
• May derived output flow back into a corpus, a glossary or a training set — and through which gate?
• How is derived output marked where it is used?
• Which text in the corpus was never released by anyone in the company?

When derived text is fed back into the source without the gate, the source of truth thins out with every pass: answers are built from answers, and nobody can say any longer which sentence someone released. Models trained on generated data are known to degrade in the same way; in a company, the effect starts much earlier, in the corpus.

Text from outside is the other side of the same boundary. A supplier document, a forum post or a web page in the corpus is answered from as if someone had released it — and it can carry instructions meant for the machine. Foreign text is not a source until someone in the company has released it.

• Derived is not source.
• Foreign is not source.
• A generated sentence that nobody released is not documentation.

When derived text becomes a source, the source of truth dissolves.

Answers outside the company are the answers that search engines, chat assistants and agents of others give from published documentation.

Questions to ask at this boundary:

• Which of our published content is read and answered from outside the company?
• Does the published content say what it is, for whom, for which product and in which version?
• What should not be published, because an answer built from it outside the company could do harm?

Every model of a lifecycle assumes that someone in the company decides. Here nobody does. The user may never see the documentation; they see an answer that another company’s function wrote from it. Noticing, finding and understanding move to the machine, and the person only judges the result.

The company keeps one decision: the one made at publishing. What is published, how clearly it is marked and what is deliberately left out is all that reaches these answers. The cascade calls the corresponding place unconfigured AI use; this boundary is its counterpart on the side of published content.

• Published is not configured.
• An answer outside the company is not the company’s answer — but it is built from the company’s content.

Where the company doesn’t decide the answer, it decides what can be answered from.