Viele Unternehmen begreifen die EU-Maschinenverordnung als Aktualisierungsaufgabe ihrer Dokumentation. Das greift zu kurz — und beginnt an der falschen Stelle. Was sich wirklich verändert, ist die Art, wie Sicherheit begründet und nachgewiesen werden muss.
Es gehört zu den verlässlichen Mustern europäischer Regulierung, dass sie jene Organisationsbereiche eines Unternehmens am wenigsten erreicht, die sie eigentlich treffen müsste. Die neue Maschinenverordnung der Europäischen Union, die am 20. Januar 2027 verbindlich anzuwenden sein wird, verspricht in dieser Hinsicht keine Ausnahme zu werden.
In vielen Unternehmen löst der Termin vor allem eine Bewegung aus, die man als organisatorischen Reflex bezeichnen kann: Man richtet den Blick auf die Technische Dokumentation. Müssen Betriebsanleitungen überarbeitet werden? Welche Nachweise gehören in die technischen Unterlagen? Wie verändert sich die Konformitätserklärung?
Die Fragen sind nicht falsch. Sie greifen nur zu kurz. Wer die Verordnung als Aktualisierungsaufgabe der Dokumentation begreift, hat ihren eigentlichen Charakter nicht erkannt. Denn das Problem, das sie aufwirft, ist kein redaktionelles. Es ist ein technisches.
Genauer: Die Maschinenverordnung verändert nicht in erster Linie, wie über Sicherheit geschrieben wird. Sie verändert, wie Sicherheit begründet, nachgewiesen und über den Lebenszyklus einer Maschine hinweg aufrechterhalten werden muss. Wer das übersieht, wird im Jahr 2026 versuchen, am Ende eines Entwicklungsprojekts zusätzliche Texte zu erzeugen – und im Jahr 2027 feststellen, dass das nicht ausreicht.
Maschinen waren auch bisher sicher zu konstruieren. Daran hat sich nichts geändert. Verändert hat sich, welche Entwicklungen heute in eine Sicherheitsbewertung hineinreichen. Software steuert das Verhalten der Maschine. Aktualisierungen verändern ihre Funktionen, nachdem sie in Verkehr gebracht wurde. Vernetzung schafft Angriffsflächen, die in Konstruktionsplänen nicht erscheinen. Lernende Systeme erzeugen Verhalten, das durch klassische Steuerungslogik nicht vollständig vorhergesagt werden kann.
Ein nicht unerheblicher Teil dessen, was sicherheitsrelevant geworden ist, entzieht sich damit den Routinen, die der Maschinenbau in einem Jahrhundert ausgebildet hat. Die Verordnung zwingt Unternehmen weniger dazu, mehr zu dokumentieren, als vielmehr dazu, genauer zu wissen, was sie eigentlich tun.
Welche Softwarefunktion ist sicherheitsrelevant, und ab welcher Schwelle? Welche Annahmen liegen der Risikobeurteilung zugrunde – und welche dieser Annahmen bleiben gültig, wenn ein Update das Verhalten der Maschine verändert? Welche Schnittstellen sind angreifbar, welche Tests belegen die Zuverlässigkeit einer Sicherheitsfunktion in den tatsächlich relevanten Betriebssituationen, welche Grenzen kennt ein KI-basiertes System? Wer diese Fragen am Ende eines Projekts durch redaktionelle Nacharbeit beantworten will, hat das eigentliche Problem nicht verstanden. Beantwortet werden müssen sie in der Entwicklung.
Besonders sichtbar wird das bei Software. In vielen Entwicklungsorganisationen herrscht eine ungeschriebene Übereinkunft: Was die Maschine tut, steht im Code. Der Code sei die Wahrheit; alles andere bestenfalls Begleitmaterial.
Für die Produktentwicklung mag diese Haltung gelegentlich tragfähig sein. Für die Konformität mit der Maschinenverordnung ist sie es nicht. Ein Quellcode-Repository zeigt, welche Implementierung zu einem bestimmten Zeitpunkt vorlag. Es erklärt nicht, weshalb eine Funktion als sicher bewertet wurde, gegen welche Gefährdung sie gerichtet war, welche Annahmen den Einsatzkontext bestimmen, und schon gar nicht beweist es aus sich heraus, dass die durchgeführten Tests im Hinblick auf die zu beweisende Sicherheitseigenschaft angemessen waren.
Notwendig ist deshalb eine andere Ebene: Anforderungen, Begründungen, Verknüpfungen. Diese Ebene ist mit klassischer Technischer Dokumentation nicht identisch, und auch nicht mit Softwaredokumentation im engeren Sinne. Sie liegt dazwischen – als strukturierte Sicherheitsargumentation, die Entscheidungen aus der Entwicklung nachvollziehbar macht.
Der entscheidende Punkt lautet daher nicht, dass Entwickler künftig wie technische Redakteure schreiben müssten. Sie müssen ihre Entscheidungen vielmehr so treffen und festhalten, dass aus ihnen ein belastbarer Sicherheitsnachweis hervorgehen kann.
Eine Maschine war aus regulatorischer Sicht lange Zeit ein vergleichsweise stabiler Gegenstand. Sie wurde konstruiert, gebaut, ausgeliefert und anschließend betrieben. Wartung, Umbau, Ersatzteile mochten ihren Zustand verändern, doch das sicherheitsrelevante Verhalten blieb im Wesentlichen, was es am Tag des Inverkehrbringens war.
Bei softwareintensiven Maschinen trifft diese Vorstellung nicht mehr zu. Funktionen werden nachgeliefert, Parameter angepasst, Algorithmen verbessert, Fehlerbehebungen eingespielt. Die Veränderbarkeit ist wirtschaftlich gewollt; sicherheitstechnisch ist sie anspruchsvoll, denn jede relevante Veränderung wirft die Frage auf, ob die ursprüngliche Risikobeurteilung noch trägt.
Das ist, anders als oft angenommen, keine vorrangig dokumentarische Frage. Es ist eine Frage der Systemgrenzen. Unternehmen müssen festlegen, welche Änderungen vom bestehenden Sicherheitskonzept gedeckt sind und wann eine neue Bewertung erforderlich wird; sie müssen bestimmen, wie Aktualisierungen freigegeben werden, welche Tests erneut durchlaufen werden müssen, welche Nachweise mit welchem Softwarestand verbunden bleiben. Sicherheit wird damit zu einem Prozess, der den Lebenszyklus begleitet, und nicht zu einem Zustand, der mit dem Inverkehrbringen erreicht und anschließend nur noch verwaltet wird.
Die eigentliche Schwäche vieler Organisationen liegt nicht darin, dass sie zu wenig Text produzieren. Sie liegt darin, dass Sicherheitsannahmen, Softwareversionen, Varianten, Testergebnisse und Freigaben nicht konsequent miteinander verbunden sind. Solange diese Informationen über Tickets, Tabellen, Wiki-Seiten und einzelne Köpfe verstreut bleiben, ist die Organisation im Ernstfall nicht nachweisfähig.
Ähnlich verhält es sich mit der Cybersicherheit. Sie lässt sich nicht als nachgereichtes Kapitel an eine fertige Maschinendokumentation anfügen. Sobald die Manipulation von Software, Daten, Parametern oder Kommunikationsschnittstellen sicherheitsrelevante Folgen haben kann – und das ist bei vernetzten Maschinen die Regel –, gehört die Cybersicherheit in die Konstruktion und nicht in die Betriebs-IT des Anwenders.
Das beginnt mit Bedrohungsannahmen: welche Schnittstellen existieren, wer auf sie zugreifen kann, welche Manipulationen sicherheitskritisch wären, welche Schutzmaßnahmen unbefugte Eingriffe verhindern, wie die Integrität von Softwareständen sichergestellt wird, wie Schwachstellen über den Lebenszyklus behandelt werden. Ein allgemeiner Satz, die Maschine sei gegen unbefugten Zugriff geschützt, genügt nicht. Ebenso wenig genügt eine technische Maßnahme, deren Bezug zum Risiko ungeklärt bleibt. Cybersicherheit wird damit zu einem Bestandteil der Sicherheitsarchitektur, und sie verlangt jene Nachvollziehbarkeit, die ohne Architektur nicht zu haben ist.
Noch schärfer stellt sich die Frage bei lernenden oder KI-basierten Funktionen. Hier genügt es nicht, ein Modell erfolgreich trainiert zu haben; eine gute Performance-Kennzahl ist kein Sicherheitsnachweis. Für sicherheitsrelevante Maschinenfunktionen muss erkennbar sein, in welchem Einsatzbereich ein System zuverlässig arbeitet, welche Situationen abgedeckt wurden, welche Grenzen es kennt und welche Maßnahmen greifen, sobald es außerhalb seines vorgesehenen Bereichs gerät oder selbst unsicher wird.
Das betrifft nicht allein die Implementierung. Es betrifft die Argumentation über die Implementierung – die Frage also, warum ein System in einem gegebenen Kontext als hinreichend sicher gelten kann, welche Daten diese Aussage stützen, welche Szenarien geprüft wurden, welche Abweichungen akzeptabel sind, wann ein Mensch eingreifen muss und welche Rückfallebene existiert. Gerade die Künstliche Intelligenz macht sichtbar, was für die Verordnung insgesamt gilt: Nachweisführung kann nicht im Nachhinein aus Dokumentation entstehen. Sie muss Teil der Entwicklungsmethodik selbst sein.
Werkzeuge für einzelne Teilprobleme stehen den meisten Unternehmen reichlich zur Verfügung. Anforderungen werden in Requirements-Werkzeugen verwaltet, der Quellcode in Git, Tests in Pipelines, Risiken in Tabellen oder Fachwerkzeugen, Änderungsstände im PLM, Betriebsanleitungen in der Technischen Dokumentation, Projektentscheidungen in Präsentationen oder Tickets. Jedes dieser Werkzeuge kann für sich genommen sinnvoll sein. Das Problem entsteht zwischen ihnen.
Eine sicherheitsrelevante Anforderung muss mit einer Gefährdung verbunden bleiben, eine Schutzmaßnahme auf eine Anforderung zurückgeführt werden können, eine Softwarekomponente eine Sicherheitsfunktion realisieren, ein Test deren Erfüllung belegen, ein Release die für ihn gültigen Nachweise mit sich führen, eine Betriebsanleitung die einschlägigen Restrisiken konsistent wiedergeben. Diese Verknüpfungen sind die eigentliche Nachweisarchitektur. Wo sie fehlt, entsteht ein gefährliches Muster, das im Alltag wenig auffällt: Die Informationen sind irgendwo vorhanden, doch der Zusammenhang ist nicht belastbar herzustellen.
Nachweisfähigkeit bedeutet, dass die Organisation den Zusammenhang zu zeigen vermag – nicht, dass irgendwo eine Spur davon existiert.
Es genügt dann nicht zu sagen, das müsse in irgendeinem Ticket stehen, das habe der Entwickler einmal erklärt, das werde die Testabteilung schon geprüft haben.
An dieser Stelle kommt die Technische Dokumentation ins Spiel, allerdings anders, als der reflexhafte Blick auf sie nahelegt. Die Vorstellung, sie werde am Ende eines Projekts aus unstrukturierten Informationen einen lesbaren Text formen, war stets problematisch; unter der Maschinenverordnung ist sie unhaltbar geworden. Wo sicherheitsrelevante Aussagen erst am Projektende redaktionell rekonstruiert werden müssen, ist das Risiko hoch, dass sie unvollständig, widersprüchlich oder schlicht nicht belastbar sind.
Die eigentliche Stärke der Technischen Dokumentation liegt anderswo. Sie hat über Jahre Methoden entwickelt, technische Informationen strukturiert, modular, variantenfähig und wiederverwendbar zu verwalten; sie denkt in Zielgruppen, Informationsarten, Gültigkeiten, Versionen und Publikationskontexten; sie weiß, dass eine Aussage nicht nur richtig sein muss, sondern auch auffindbar, pflegbar und konsistent. Diese Kompetenz wird unter der Maschinenverordnung wertvoller, nicht weniger wertvoll.
Sie ersetzt jedoch nicht die Verantwortung des Engineerings. Die Risikobeurteilung bleibt eine technische Aufgabe, ebenso die Bewertung einer Software-Sicherheitsfunktion, die Angemessenheit einer Cybersicherheitsmaßnahme, die Validierung eines KI-Systems. Die Technische Dokumentation kann diese Entscheidungen nicht erzeugen. Sie kann ihnen jedoch eine Form geben, die über den Lebenszyklus tragfähig bleibt.
Auch in der Werkzeugfrage ist Zurückhaltung angebracht. Component-Content-Management-Systeme, wie sie in der Technischen Dokumentation seit Jahren etabliert sind, können eine wichtige Rolle spielen – überall dort, wo es um die modulare Verwaltung, die Variantensteuerung, die Wiederverwendung und die konsistente Publikation von Informationen geht. Doch ein Redaktionssystem löst nicht aus sich heraus das Nachweisproblem des Engineerings. Wo Anforderungen, Risiken, Tests, Softwarestände und Architekturentscheidungen methodisch unsauber erfasst sind, kann auch das beste System daraus keine belastbare Sicherheitsargumentation erzeugen.
Seinen vollen Wert entfaltet die Methodik der Technischen Dokumentation dort, wo Engineering-Nachweise und Benutzerinformation aufeinandertreffen – also an jener Schnittstelle, an der Sicherheitsaussagen aus der Entwicklung in technische Unterlagen, Betriebsanleitungen und Konformitätsbewertung übergehen müssen. Hier ist die Erfahrung der Technischen Dokumentation mit modularen, variantenfähigen, versionierten Informationsstrukturen ein echter Hebel.
Die Werkzeugfrage sollte deshalb nicht lauten, ob man ein Redaktionssystem anstelle von Office, Wiki oder PLM benötigt. Sie sollte lauten, welche Informationsobjekte für die eigene Sicherheitsargumentation überhaupt erforderlich sind, wo sie entstehen, wer sie verantwortet, wie sie versioniert werden und auf welchen Wegen sie in technische Unterlagen, Betriebsanleitung und Konformitätsbewertung einfließen. Erst aus der Antwort darauf ergibt sich die passende Werkzeuglandschaft. Sie kann Requirements-Management, PLM, ALM, Test- und Risikomanagement ebenso umfassen wie ein Component-Content-Management-System. Entscheidend ist nicht das einzelne System, sondern die Nachweisfähigkeit über die Systemgrenzen hinweg.
Viele Unternehmen werden auf die Maschinenverordnung mit Schulungen reagieren. Das ist notwendig, aber nicht hinreichend. Selbstverständlich müssen Entwickler, Sicherheitsingenieure, Produktverantwortliche, technische Redakteure und Qualitätsbeauftragte verstehen, was sich ändert. Wissen allein verändert jedoch keine Organisation. Wer nach einer Schulung in unveränderte Prozesse zurückkehrt, wird dieselben Lücken erzeugen, die er zuvor erzeugt hat.
Die entscheidenden Fragen sind organisatorischer Natur. Wann wird entschieden, ob eine Softwarefunktion sicherheitsrelevant ist? Wo werden Sicherheitsannahmen festgehalten? Wer bewertet die Auswirkungen einer Cybersicherheitsmaßnahme auf die Maschinensicherheit? Wie wird eine Aktualisierung sicherheitstechnisch freigegeben? Welche Nachweise müssen vorliegen, bevor ein Release ausgeliefert wird? Wie werden Änderungen an Varianten und Softwareständen in der Betriebsanleitung nachvollzogen? Wann wird die Technische Dokumentation eingebunden? Wer prüft die Konsistenz zwischen Risikobeurteilung, technischer Unterlage und Benutzerinformation? Ohne Antworten auf diese Fragen bleibt die Maschinenverordnung ein Pflichtenprojekt. Mit Antworten wird sie zu einem Reifegradprojekt des Engineerings.
Die Maschinenverordnung trifft Unternehmen an einer empfindlichen Stelle. Sie setzt voraus, dass technische Entscheidungen nicht nur getroffen, sondern begründet, verknüpft und über die Zeit gehalten werden. Das widerspricht manchen Arbeitsgewohnheiten. In Entwicklungsprojekten zählt Geschwindigkeit; Entscheidungen entstehen pragmatisch, Wissen wandert mündlich, Dokumentation wird nachgezogen, Abweichungen werden lokal aufgelöst. Für einfache Produkte mag das tragfähig sein. Für softwareintensive, vernetzte und aktualisierungsfähige Maschinen ist es es nicht.
Der notwendige Kulturwechsel besteht nicht darin, aus Entwicklern Redakteure zu machen. Er besteht darin, die Nachweisfähigkeit als Bestandteil guter Ingenieurarbeit zu begreifen. Eine Sicherheitsfunktion ist nicht fertig, wenn sie implementiert ist; sie ist fertig, wenn nachvollziehbar ist, welches Risiko sie adressiert, welche Anforderungen sie erfüllt, wie sie validiert wurde, welche Grenzen gelten und für welche Produktvariante diese Aussage zutrifft. Eine Aktualisierung ist nicht fertig, wenn sie ausgeliefert werden kann, sondern wenn klar ist, ob und wie sie die Sicherheitsbewertung verändert. Eine Cybersicherheitsmaßnahme ist nicht fertig, wenn sie technisch eingebaut wurde, sondern wenn erkennbar ist, welche Bedrohung sie adressiert und worin ihre Angemessenheit besteht.
Die Maschinenverordnung wird unterschätzt, weil sie wie eine regulatorische Aktualisierung wirkt. Tatsächlich macht sie sichtbar, dass moderne Maschinenentwicklung einer veränderten Form der Nachweisführung bedarf. Software, Cybersicherheit, Künstliche Intelligenz und aktualisierungsfähige Systeme entziehen sich der Beherrschbarkeit durch nachgereichte Dokumentation. Sie verlangen strukturierte Sicherheitsargumentationen, die im Engineering entstehen, über Werkzeuggrenzen hinweg verbunden bleiben und in der Technischen Dokumentation konsistent sichtbar werden.
Die Technische Dokumentation spielt dabei eine wichtigere Rolle als bisher, nicht eine geringere. Ihre Methoden der Modularisierung, der Variantensteuerung, der Wiederverwendung und der konsistenten Informationspflege werden gebraucht. Aber die Verantwortung wandert nicht zu ihr. Sie verteilt sich auf die Schnittstellen zwischen Engineering, Sicherheit, Software, Qualitätswesen und Dokumentation.
Wer 2026 nur seine Dokumentationsabteilung auf die Maschinenverordnung vorbereitet, beginnt an der falschen Stelle. Die Frage, die das Inkrafttreten am 20. Januar 2027 stellt, lautet nicht, wer am Ende die Unterlagen schreibt. Sie lautet, ob das Unternehmen zu jedem sicherheitsrelevanten Zeitpunkt zu zeigen vermag, weshalb seine Maschine sicher ist.
Wo das ungewiss bleibt, hat das Unternehmen kein Dokumentationsproblem. Es hat ein Problem mit seinem Engineering.
Die Maschinenverordnung 2027 ist primär eine Engineering-Aufgabe, keine Redaktionsaufgabe. Sicherheit muss begründet, verknüpft und über den gesamten Lebenszyklus nachweisbar gehalten werden — entstehen muss das in der Entwicklung, nicht in nachgereichten Texten.
Die entscheidende Lücke ist selten zu wenig Text, sondern die fehlende Verbindung zwischen Anforderungen, Risiken, Softwareständen, Tests und Freigaben. Die Technische Dokumentation wird dabei wertvoller, weil ihre Methoden Struktur, Varianten und Konsistenz sichern — aber die Verantwortung verteilt sich auf die Schnittstellen zwischen Engineering, Sicherheit, Software, Qualität und Dokumentation.
Dieser Beitrag gibt die fachliche Einschätzung von KAMRADT Solutions wieder und dient der allgemeinen Information. Er ersetzt keine individuelle rechtliche oder technische Beratung. Stand: Juni 2026.
Wir helfen Ihnen, Nachweisführung als Bestandteil Ihrer Engineering- und Dokumentationsprozesse aufzubauen — von der Analyse bis zur tragfähigen Werkzeuglandschaft.
Oder rufen Sie uns gerne persönlich an: +49 (0) 23 81 - 33917-0