„Ab wann brauchen wir den Digitalen Produktpass?“ Diese Frage höre ich in Projekten gerade häufig und die ehrliche Antwort lautet fast immer: „Das kommt darauf an, welches Produkt Sie meinen.“

Es gibt keinen einheitlichen Stichtag für alle Branchen. Stattdessen entscheiden Produktgruppe, Rechtsgrundlage und der jeweilige Rechtsakt, wann welche Pflicht greift. Das klingt zunächst unbefriedigend, ist aber der Kern der Sache: Wer den DPP-Fahrplan liest wie eine Liste fester Fristen, schätzt den eigenen Handlungsdruck oft falsch ein. Das gilt besonders für den Maschinen- und Anlagenbau.

Welche Fristen stehen für den Produktpass schon fest?

Nur ein Termin steht bislang wirklich fest: Ab dem 18. Februar 2027 wird der Batteriepass für bestimmte Batteriekategorien Pflicht. Betroffen sind Elektrofahrzeugbatterien, Batterien für leichte Verkehrsmittel wie E-Bikes und E-Scooter sowie Industriebatterien mit mehr als 2 kWh Kapazität.

Diese Pflicht ergibt sich aus der eigenständigen EU-Batterieverordnung, nicht aus der ESPR (Ecodesign for Sustainable Products Regulation). Technisch nutzt der Batteriepass zwar dieselbe Infrastruktur wie der Digitale Produktpass, rechtlich ist er aber ein eigener Fall.

Für alle anderen Produktgruppen nennt die Europäische Kommission bislang vor allem geplante Zeiträume für die Annahme produktspezifischer Rechtsakte, aber noch keine Anwendungstermine. Der aktuelle DPP-Fahrplan sieht Stand heute so aus:

• 4. Quartal 2026: Rechtsakt für Eisen und Stahl
• Februar 2027: Batteriepass wird für die genannten Kategorien Pflicht
• 2. Quartal 2027: Regelungen für Bauprodukte und DPP-Dienstleister
• 3.-4. Quartal 2027: Rechtsakte für Textilien, Aluminium und Reifen
• 2028: Rechtsakt für Möbel
• 2029: Rechtsakte für Matratzen und bestimmte ICT-Produkte

Wichtig dabei: Nach der Annahme eines ESPR-Rechtsakts ist grundsätzlich eine Übergangszeit von mindestens 18 Monaten vorgesehen, bevor die Anforderungen tatsächlich gelten. Maßgeblich bleiben jedoch die konkreten Regelungen des jeweiligen Rechtsakts. Ein Rechtsakt für Textilien im 4. Quartal 2027 bedeutet also nicht, dass ab 2028 jedes Kleidungsstück einen DPP braucht.

Bauprodukte sollten Sie übrigens besonders betrachten. Sie fallen unter die eigenständige Bauprodukteverordnung, nicht unter die ESPR-Systematik der übrigen Produktgruppen.

Warum Maschinen- und Anlagenbauer trotzdem betroffen sind

Wenn Sie im Bereich Maschinen- und Anlagenbau arbeiten, könnten Sie nach dem Lesen der Liste denken, dass Sie ja gar nicht betroffen sind. Und Sie haben insoweit recht, dass Maschinen und ganze Anlagen im aktuellen ESPR-Arbeitsplan nicht als eigene Produktgruppe gelistet sind. Einen eigenen „Maschinen-DPP“ gibt es also bislang nicht.

Wer daraus aber schließt, das Thema gehe die Branche nichts an, liegt leider falsch. Kein eigener Rechtsakt heißt nicht automatisch, dass keine Pflichten entstehen. Es sind vor allem drei Mechanismen, die dafür sorgen, dass der DPP auch ohne eigenen „Maschinen-DPP“ im Alltag vieler Unternehmen der Branche ankommt:

Verbaute Komponenten unterliegen eigenen Pflichten

Eine Maschine besteht selten aus einem einzigen Material. Oft sind Batterien verbaut, für die, wie zuvor erwähnt, ab dem 18. Februar 2027 der Batteriepass gefordert wird. Das gilt unabhängig davon, ob sie in einem Fahrzeug oder in einer Anlage verbaut sind.

Stahl- und Aluminiumkomponenten gehören zu den priorisierten ESPR-Produktgruppen mit Rechtsakten ab Q4 2026 beziehungsweise Q3/Q4 2027.

Für Elektromotoren nennt der ESPR-Arbeitsplan 2025–2030 voraussichtlich 2028 als Zeithorizont für neue Ecodesign-Anforderungen (First ESPR working plan).

Wer eine Maschine baut, muss die DPP-relevanten Daten dieser Zulieferteile also kennen und weiterreichen können, auch ohne selbst einen Produktpass für die Gesamtmaschine zu erstellen.

Kunden fordern Daten für ihren DPP an

Maschinen- und Anlagenbauer liefern häufig an Branchen, die selbst zu den priorisierten DPP‑Produktgruppen zählen, wie etwa an Textilhersteller, Stahlverarbeiter, Möbelproduzenten oder Batterieintegratoren.

Diese Kunden benötigen für ihre eigenen Produktpässe Material- und Komponentendaten, Herkunftsnachweise und Angaben zu Recyclingfähigkeit oder Ersatzteilen.

Ein Maschinenbauer wird dadurch zum Datenlieferanten im DPP-Ökosystem, ohne selbst unmittelbar reguliert zu sein.

Horizontale Maßnahmen können Maschinenkomponenten erfassen

Neben den produktgruppenspezifischen Rechtsakten plant die ESPR horizontale Anforderungen, die branchenübergreifend gelten: ein Repairability Scoring oder Vorgaben zu Rezyklatgehalt und Recyclingfähigkeit bei elektrischen und elektronischen Geräten. Solche Regeln zielen zwar nicht auf Maschinen als Gesamtprodukt, können aber deren elektrische Ausrüstung oder andere Komponenten betreffen.

Hinzu kommt: Die ESPR ist als Rahmenverordnung angelegt und für Erweiterungen offen. Dass Maschinen heute nicht als solche auf der Prioritätenliste stehen, ist eine Momentaufnahme, keine dauerhafte Ausnahme.

DPP-Pflichten beginnen vor dem eigentlichen Rechtsakt

Unsere Frage vom Anfang – „Ab wann brauchen wir den Digitalen Produktpass?“ – lässt sich für den Maschinen- und Anlagenbau also nicht mit einem Datum beantworten, wohl aber mit einer Richtung: Der Blick auf verbaute Komponenten, Kundenanforderungen und den offenen ESPR-Rahmen zeigt, dass eigene Pflichten nicht erst mit einem Rechtsakt beginnen, sondern längst über Lieferketten und Kundendaten entstehen können.

Wo steht Ihr Unternehmen bei dieser Einschätzung? Kennen Sie die DPP-relevanten Pflichten Ihrer Komponenten und die Datenanforderungen Ihrer Kunden bereits? In unserem Blog haben wir schon einige Informationen für Sie zusammengestellt, wie Sie Ihre Technische Redaktion am besten auf die neuen Anforderungen vorbereiten. Oder Sie sprechen uns einfach an!

Hinweis: Dieser Beitrag gibt den Stand der verfügbaren EU-Informationen vom 8. September 2026 wieder. Der Zeitplan ist indikativ und kann sich im weiteren Gesetzgebungsprozess ändern. Der Beitrag ersetzt keine rechtliche Beratung.

Ab dem 20. Januar 2027 gilt die neue EU-Maschinenverordnung (EU) 2023/1230 verbindlich. Für bestimmte Hochrisiko-KI-Systeme verlangt der EU‑AI-Act technische Dokumentation, die gepflegt, nachvollziehbar versioniert und den zuständigen Behörden grundsätzlich zehn Jahre lang zur Verfügung gehalten werden muss. Seit dem 28. Juni 2025 gelten außerdem für ausgewählte Produkte und Dienstleistungen verbindliche Barrierefreiheitsanforderungen nach dem European Accessibility Act und seiner Umsetzung in den Mitgliedstaaten. Drei Regelungsbereiche, ein gemeinsamer Nenner: Technische Informationen, Dokumentationsprozesse und Verantwortlichkeiten rücken enger zusammen.

Trotzdem tauchen die Begriffe „Governance“ und „Compliance“ in vielen Technischen Redaktionen eher selten auf. Sie klingen nach Rechtsabteilung, nach Vorstandsebene, nach einem Thema, um das sich andere kümmern. Ein Trugschluss, wie sich bei genauerem Hinsehen zeigt.

Was Governance und Compliance eigentlich meinen

Governance beschreibt den organisatorischen Rahmen: Wer ist wofür zuständig, welche Rollen gibt es, nach welchen Regeln wird gearbeitet und wie wird das gesteuert? Compliance meint die Einhaltung verbindlicher Vorgaben – gesetzlicher wie interner. In der Theorie lassen sich beide Begriffe sauber trennen. In der Praxis der Technischen Redaktion greifen sie ständig ineinander, denn dort wird dokumentiert, freigegeben, versioniert und nachweisbar gemacht, was später rechtlich und organisatorisch relevant wird.

Compliance in der Technischen Kommunikation ist dabei kein einzelnes Thema, sondern zeigt sich auf mehreren Ebenen gleichzeitig:

• Produkt-Compliance
  Eine unvollständige oder nicht geeignete Betriebsanleitung kann zu Problemen bei der Konformitätserklärung oder CE-Kennzeichnung führen. Die derzeit noch geltende Maschinenrichtlinie (ab dem 20. Januar 2027 die Maschinenverordnung), das Produktsicherheitsrecht und die Norm IEC/IEEE 82079-1 geben hier Orientierung. Wer hier schludert, riskiert im Zweifel Maßnahmen der Marktüberwachung bis hin zu einem Bereitstellungs- oder Verkaufsverbot.
• Regulatorische Compliance
  Der digitale Produktpass verlangt strukturierte, maschinenlesbare Produktinformationen für bestimmte Produktgruppen. Der European Accessibility Act macht Barrierefreiheit für bestimmte Produkte und Dienstleistungen zur Pflicht. Und der EU‑AI-Act verlangt für Hochrisiko-KI-Systeme eine technische Dokumentation, die die Konformität nachvollziehbar belegt und über Jahre verfügbar bleiben muss.
• Prozess-Compliance
  Unternehmen müssen zeigen können, dass ihre Dokumentationsprozesse kontrolliert und nachvollziehbar ablaufen. Redaktionsleitfäden, Terminologiestandards, Versionierung und Change Management im CCMS sind hier keine reinen Effizienzthemen mehr, sondern Nachweisinstrumente.
• Informationsqualität
  Verständlichkeit ist keine Kür, sondern Teil der Anforderungen an Gebrauchs- und Sicherheitsinformationen. Eine unverständliche Anleitung kann im Schadensfall haftungsrelevant werden.

Diese vier Ebenen laufen selten getrennt voneinander. Meist wirken sie gleichzeitig – am Produkt, am Prozess und an der Sprache selbst.

Ein Beispiel aus der Praxis

Wie wenig getrennt diese Ebenen tatsächlich ablaufen, zeigt ein Beispiel aus dem Maschinenbau. Ein Hersteller bringt eine Maschine mit softwaregesteuerter Sicherheitsfunktion auf den Markt. Bei Erfüllung aller einschlägigen Anforderungen  ist die Produkt-Compliance zunächst gegeben – die Maschine entspricht den geltenden Normen. Wird die Software später aktualisiert, kann das bei wesentlichen Änderungen  eine erneute Prüfung und gegebenenfalls eine neue Konformitätsbewertung auslösen. Damit ist die regulatorische Ebene im Spiel, und sie schlägt direkt auf das Produkt durch. Für die neue Bewertung braucht es dann ein strukturiertes, versioniertes Dokumentationssystem, das lückenlos zeigt, welche Anleitung zu welchem Softwarestand gehörte – das ist die Prozessebene. Und selbst wenn all das sauber läuft, bringt es wenig, wenn die überarbeitete Anleitung am Ende niemand versteht: Die Instruktionspflicht bleibt dann auf der Strecke, obwohl alle Formalien erfüllt sind. Ein einziger Vorgang, vier Ebenen gleichzeitig.

Beim EU‑AI-Act zeigt sich dasselbe Muster: Für Hochrisiko-KI-Systeme reicht keine einmalige Anleitung mehr, gefragt ist eine durchgehende, verständliche Dokumentationsführung, die über Jahre prüfbar bleibt.

In der Praxis stellt sich an diesem Punkt eine ganz konkrete Frage. Wer schon einmal ein Audit begleitet hat, kennt sie: „Können Sie das belegen?“ Ein wichtiger Teil der Antwort liegt häufig im Redaktionssystem – in der Versionierung, den Freigabeprozessen, den Leitfäden. Diese Frage lässt sich nicht an der Rechtsabteilung vorbei klären. Sie entscheidet sich dort, wo Inhalte entstehen, strukturiert und freigegeben werden: also oft in der Technischen Redaktion.

Was das für Ihre Dokumentation bedeutet

Governance und Compliance werden oft zwischen Rechtsabteilung und Geschäftsführung verhandelt. Ihre Schnittstelle – Produkt, Recht, Prozess und Verständlichkeit – liegt aber mitten in der Technischen Redaktion. Allein lösen lässt sich das nicht: Ohne ein CCMS, das Versionen sauber führt, ohne QM-Prozesse, die Freigaben nachvollziehbar machen, und ohne die Rückendeckung der Geschäftsführung bleibt auch die beste Redaktion an der Nachweisfähigkeit hängen. Aber ohne eine Redaktion, die diese Anforderungen in verständliche, prüfbare Inhalte übersetzt, nützen weder CCMS noch QM-Prozess etwas. Wer Dokumentation sauber aufsetzt, sichert nicht nur den Marktzugang, sondern reduziert Haftungsrisiken und schafft die Nachweisfähigkeit, die Behörden und Auditor:innen zunehmend einfordern.

In unserem Alltag als Dienstleister in der Technischen Kommunikation erleben wir täglich, wie neue EU-Vorgaben, interne Prozessanforderungen und der Anspruch an verständliche Inhalte zusammenkommen. Ob CCMS-Einführung mit sauberer Versionierung, Redaktionsleitfaden oder die Frage, wie das jetzt mit der KI geregelt ist. Wenn Sie mit uns über Ihre Compliance-Baustellen sprechen möchten, dann melden Sie sich gerne bei uns für ein Erstgespräch.

Hinweis: Dieser Beitrag gibt einen allgemeinen Überblick über ausgewählte Anforderungen an Governance und Compliance in der Technischen Redaktion. Er stellt keine Rechtsberatung dar und ersetzt insbesondere keine einzelfallbezogene Prüfung der jeweils anwendbaren Rechtsvorschriften, Normen und Übergangsregelungen. Maßgeblich sind die zum jeweiligen Zeitpunkt geltenden gesetzlichen Bestimmungen sowie die konkrete Ausgestaltung des Produkts, der Dienstleistung und der Dokumentationsprozesse.

Ein Servicetechniker steht vor der Maschine, das Wartungsintervall ist längst überschritten. Die Anleitung liegt als PDF irgendwo im Ordner ab – den Bezug zur Displayanzeige muss der Techniker selbst herausfinden. Genau diese Lücke zwischen Dokumentation und Maschine lässt sich schließen, wenn man PDF nicht mehr als einziges Ausgabeformat betrachtet, sondern Inhalte so aufbereitet, dass sie sich mit den Betriebsdaten des Produkts verknüpfen lassen.

Dieses gezielte Verknüpfen von generischen, anleitenden oder beschreibenden Inhalten und individuellen Betriebsinformationen des dokumentierten Produkts kann dabei über verschiedene Formate laufen. HTML ist ein guter Weg, wir haben aber ebenso Projekte mit JSON, Markdown und unterschiedlichen XML-Formaten, u.a. mit DITA realisiert.

Am Ende geht es darum, geeignete Platzhalter im Content auszuliefern, die sich dynamisch mit Werten füllen lassen, oder identifizierbare Informationseinheiten auszuliefern, die sich vom dokumentierten Produkt aus gezielt ansprechen lassen. Damit bewegen wir uns in Richtung digitaler Zwilling, auch wenn wir hier bewusst mit kleinen, machbaren Schritten anfangen.

Wir sprechen also – wie so oft – von Metadaten. Hier sind drei Beispiele aus der Praxis:

Wenn die Hilfe mitdenkt

Fangen wir mit dem an, was vermutlich jede und jeder schon mal genutzt hat, meist ohne groß darüber nachzudenken: der klassischen F1-Hilfe. Mit „F1“, gedrückt in einer fast beliebigen Windows-Anwendung, öffnet sich eine mit dem aktuellen Dialog verbundene Anleitung im Hilfefenster. Früher lag da das proprietäre HTMLHelp-Format dahinter (ja, das gibt es tatsächlich noch – aber Faxgeräte und Pferdedroschken ja auch), heute wird in der Regel eine HTML-Seite aufgerufen.

Der Vorteil: Es steht sofort die im aktuellen Arbeitskontext benötigte Information zur Verfügung.

Der Aufwand: Entwicklung und Technische Redaktion müssen sich auf eine Abbildung zwischen Elementen der Benutzeroberfläche einerseits und Informationseinheiten andererseits einigen. Das übliche Mittel der Wahl ist eine Hilfe-ID, die in der Software erfasst und im Redaktionssystem als Metadatum dem passenden Topic zugewiesen wird. Kombiniert mit dem passenden ISO-Sprachkürzel lässt sich der Hilfeaufruf ohne großen Mehraufwand dann auch sprachabhängig einrichten.

Wenn die Maschine selbst um Wartung bittet

Übertragen wir das Konzept von der Softwareoberfläche auf eine Maschinensteuerung. Anstelle der Hilfe-ID ordnen wir dem Topic, das einen Wartungsvorgang beschreibt, die ID eines Datenpunkts an der Maschine zu – etwa den Zähler für die Betriebsstunden seit der letzten Wartung.

Außerdem bringt das Topic die Information mit, aus wie vielen Stunden sich das Wartungsintervall zusammensetzt. Diesen Wert wertet die Maschinensteuerung aus. Nähern sich die Betriebsstunden diesem Grenzwert, wird den Bediener:innen automatisch die anstehende Wartung als Anleitung angezeigt.

Der Vorteil: Die Maschine kann die anleitende Information selbstständig einem Zustand oder Ereignis zuordnen und im richtigen Moment bereitstellen.

Der Aufwand für die Technische Redaktion ist kaum höher als im Beispiel mit der Hilfe-ID – es muss nur ein weiteres Metadatum gepflegt und mit ausgegeben werden.

Vom Handgriff zum Protokoll

Die Integration von Anleitung und Maschine lässt sich jetzt noch weiterentwickeln, indem man tiefer in die Details des Topics einsteigt und weitere Prozesse einbezieht. Jeder Handlungsschritt im Topic lässt sich einzeln nach dem Ausführen interaktiv bestätigen, und am Ende entsteht automatisch ein Wartungsprotokoll auf Basis der bereitgestellten Anleitung.

Umgekehrt lassen sich aktuelle Betriebsdaten wie Druck, Temperatur oder Drehzahl an sinnvollen Stellen der Handlungsanweisung als Platzhalter erfassen und direkt auf der Maschine live anzeigen: „Achten Sie darauf, dass die Temperatur des Moduls bei diesem Schritt nicht über 80 °C liegt. Aktuelle Temperatur: 82 °C.“

Der Vorteil: Durch die Integration von Anleitung und Protokoll entsteht für die Nutzenden ein Effizienzgewinn. Doppelter Pflegeaufwand entfällt, und eine mögliche Fehlerquelle verschwindet, wenn beide Dokumente sonst voneinander abweichen würden.

Der Aufwand, einen solchen Prozess abzustimmen und einzurichten, ist je nach Anzahl und Vielfalt der zu synchronisierenden Objekte natürlich nicht zu unterschätzen. Aber auch hier kann man mit einzelnen, wichtigen Punkten beginnen und nach und nach darauf aufbauen.

Das „Tada“ in Metadaten

Viele Technische Redaktionen arbeiten tagtäglich standardisiert, modular und klassifiziert mit Metadaten, Textbausteinen und einem ausgefeilten Variantenmanagement. Das heißt: Um die oben beschriebenen Möglichkeiten umzusetzen, sind die benötigten Grundlagen oft bereits vorhanden. Richtig eingesetzt, können Metadaten einen Überraschungseffekt liefern, wenn aus stumpfen Inhalten plötzlich lebendiger, kontextsensitiver Content wird.

Und dann produziert man PDFs, die Details bleiben im Silo, und all die Präzision zerfließt in einem graugrünen Informations-Smoothie, der einen irgendwie an Rosenkohl denken lässt. Dabei steckt das „Tada“ doch bereits in den Daten – man muss es nur noch herauslassen.

Uns geht es darum, Ihnen Denkanstöße zu geben, wie Sie nicht nur Ihre Technische Redaktion, sondern Ihr ganzes Unternehmen digital weiterbringen. Denn Digitalisierung ist selten eine Frage der Technik allein – sie beginnt damit, dass Menschen miteinander reden: Technische Redaktion, Entwicklung, Service. Genau dieser Austausch entscheidet auch darüber, was mit Ihren Metadaten möglich wird. Welche davon könnten schon heute mehr leisten, als nur PDF-Seiten zu befüllen? Wir sprechen gerne mit Ihnen darüber.

Kaum ein Gesetz hat in den letzten zwei Jahren für so viel Verunsicherung gesorgt wie die Verordnung (EU) 2024/1689, der EU-AI-Act. Auch Technische Redaktionen, die Künstliche Intelligenz nutzen, fragen sich oft, ob er für sie gilt und welche Pflichten daraus resultieren.

Eines ist klar: Wer Anleitungen, Hilfetexte oder Produktdokumentationen erstellt und dabei KI-Tools nutzt, ist von der Verordnung tatsächlich betroffen. Welche Pflichten sich daraus ergeben, schauen wir uns einmal genauer an.

Was der EU-AI-Act regelt und ab wann

Die Verordnung (EU) 2024/1689 ist am 1. August 2024 in Kraft getreten. Die Anwendung ist allerdings zeitlich gestaffelt. Hier hat sich in den letzten Monaten auch einiges verschoben. Der ursprüngliche Zeitplan wurde durch den sogenannten AI Omnibus an mehreren Stellen angepasst; insbesondere wurden einzelne Fristen für Hochrisiko-KI-Systeme verlängert. Aktuell gilt:

• Februar 2025: Verbotene KI-Praktiken nach Art. 5 sind bereits untersagt (etwa Social Scoring oder biometrische Massenüberwachung).
• August 2025: Die Pflichten für Anbieter von KI-Modellen für allgemeine Zwecke (GPAI, Kapitel V) greifen, relevant vor allem für Anbieter großer Sprachmodelle wie OpenAI oder Anthropic.
• August 2026: Die Transparenzpflichten nach Art. 50 Abs. 1, etwa die Kennzeichnungspflicht für Chatbots, treten in Kraft.
• Dezember 2027: Die Pflichten für Hochrisiko-KI nach Kapitel III und Anhang III (z. B. KI in Personalauswahl oder Bildung) gelten. Ursprünglich war hier der 2. August 2026 vorgesehen, das Datum wurde verschoben.
• August 2028: Hochrisiko-KI, die in Produkte eingebettet ist (Anhang I), muss die Anforderungen erfüllen. Auch dieser Termin wurde gegenüber dem ursprünglichen Plan (2. August 2027) nach hinten verlegt.

Der EU-AI-Act regelt also im Kern, wie KI-Systeme je nach Risiko eingestuft und behandelt werden, welche Pflichten Anbieter und Nutzende treffen und wie Transparenz gegenüber Endnutzer:innen hergestellt wird. Er gilt für alle Unternehmen, die KI-Systeme in der EU entwickeln, anbieten oder nutzen, unabhängig vom Firmensitz.

Anbieter oder Betreiber? Die entscheidende Frage

Bevor man sich durch Paragrafen wühlt, lohnt sich eine einzige Frage: Welche Rolle nimmt mein Unternehmen ein?

Der EU-AI-Act unterscheidet grundlegend zwischen zwei Perspektiven:

• Anbieter ist, wer ein KI-System entwickelt oder entwickeln lässt und unter eigenem Namen in Verkehr bringt.
• Betreiber ist dagegen, wer ein KI-System in eigener Verantwortung nutzt, ohne es selbst zu entwickeln oder zu vermarkten.

Für die allermeisten Technischen Redaktionen ist die Antwort eindeutig: Sie sind in der Regel Betreiber, nicht Anbieter. Wer ChatGPT, Claude, DeepL oder Copilot für Texterstellung, Übersetzung oder Recherche einsetzt, entwickelt kein KI-System, sondern nutzt es. Das grenzt den relevanten Pflichtenkreis erheblich ein.  Die umfangreichen Anforderungen an Anbieter, die im öffentlichen Diskurs viel Raum einnehmen, treffen die klassische Technische Redaktion damit in der Regel nicht. Es gibt aber Ausnahmen.

Wichtige Pflichten für Technische Redaktionen nach dem EU-AI-Act

Was heißt das nun ganz praktisch, wenn Sie als Betreiber KI-Tools im Redaktionsalltag einsetzen? Fünf Punkte verdienen Ihre Aufmerksamkeit:

1. Die Offenlegungspflicht für KI-generierte Texte greift bei klassischer Technischer Dokumentation in der Regel nicht. Artikel 50 Absatz 4 betrifft Texte, die veröffentlicht werden, um die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse zu informieren. Gewöhnliche Handbücher und Bedienungsanleitungen fallen typischerweise nicht darunter.
   Selbst wenn ein Text grundsätzlich in den Anwendungsbereich fällt, entfällt die Pflicht, wenn er einer menschlichen Überprüfung oder redaktionellen Kontrolle unterzogen wurde und eine natürliche oder juristische Person die redaktionelle Verantwortung für die Veröffentlichung trägt. Ein dokumentierter Review- und Freigabeprozess ist daher sinnvoll.
2. KI-Kompetenz ist längst Pflicht – und wird oft übersehen. Art. 4 verlangt seit dem 2. Februar 2025, dass Personal, das KI-Tools nutzt, über ausreichende KI-Kompetenz verfügt. Gemeint sind Schulungen zum kritischen Umgang mit KI-generierten Texten und Wissen um typische Fehlerquellen wie Halluzinationen.
3. Eine gesetzliche Meldepflicht an Behörden gibt es für Betreiber nicht. Trotzdem lohnt sich Nachvollziehbarkeit, also eine Dokumentation darüber, welches Tool wofür eingesetzt wird.
4. Die Offenlegungspflicht für Bild-, Ton- und Videoinhalte gilt nach Artikel 50 Absatz 4 unabhängig davon, ob ein öffentliches Interesse vorliegt. Sie betrifft jedoch nicht jedes KI-generierte Bild, sondern Bild-, Ton- oder Videoinhalte, die als Deepfake einzustufen sind – also Inhalte, die bestehenden Personen, Objekten, Orten oder Ereignissen ähneln und fälschlich als echt oder wahrheitsgetreu erscheinen könnten. Für künstlerische, kreative, satirische oder fiktionale Werke gelten besondere Erleichterungen. Bei fotorealistischen KI-Darstellungen von Produkten in Anleitungen sollte daher im Einzelfall geprüft werden, ob der Inhalt den Eindruck einer echten Aufnahme oder eines tatsächlichen Produktzustands erweckt.
5. Seit dem 2. August 2026 müssen Anbieter von KI-Systemen nach Artikel 50 Absatz 1 sicherstellen, dass Personen informiert werden, wenn sie direkt mit einem KI-System interagieren – etwa mit einem Chatbot oder einem KI-gestützten Hilfeassistenten in einer Produktdokumentation.

Einen kleinen Zusatz habe ich noch: Achten Sie auf eine mögliche Rollenverschiebung. Vertreiben Sie ein KI-System unter eigenem Namen weiter oder verändern Sie es durch Fine-Tuning oder ähnliche Eingriffe, kann unter Umständen Art. 25 relevant werden: Sie werden vom Betreiber zum Anbieter, mit allen damit verbundenen erweiterten Pflichten. Ob ein eigener Doku-Chatbot Sie zum Anbieter macht, müssen Sie ggf. vorab prüfen.

Der EU-AI-Act trifft also auch Technische Redaktionen, wenn auch deutlich leiser, als es die Schlagzeilen vermuten lassen. Viele geforderte oder sinnvolle Prozesse wie Freigaben und interne Prozessdokumentation sind für Technische Redakteur:innen ohnehin bereits Alltag. Wenn Sie hier noch Nachholbedarf haben, zeigt unser Blogartikel „Qualitätsprüfung ohne (CMS-)Lizenz: Ein cleverer Prozess für externe Reviews“, wie ein Review- und Freigabeprozess effizient aufgestellt werden kann.

In Sachen Nachvollziehbarkeit und interner Prozessdokumentation können Sie z.B. Metadaten vergeben (manuell oder automatisiert, wenn Texte etwa in einem Workflow automatisch mit KI erzeugt werden). Diese können später ausgewertet und zur Kennzeichnung verwendet werden. Sinnvoll ist das etwa bei einer anschließenden Publikation von Texten auf Webseiten.

Und wenn Sie auf der Suche nach Weiterbildung sind, dann lohnt ein Blick auf unsere PowerWebinare und unser KI-Coaching.

Hinweis: Dieser Artikel gibt eine allgemeine Einordnung wieder und ersetzt keine individuelle Rechtsberatung. Bei konkreten Compliance-Fragen zu Ihrer Situation empfehlen wir, sich an eine entsprechend spezialisierte Kanzlei zu wenden.

„Kompetenzen von morgen“ – der Titel weckt Bilder von Fähigkeiten, die wir erst noch erwerben müssen. Tatsächlich aber ist die entscheidende Fähigkeit längst gefragt: der souveräne Umgang mit Künstlicher Intelligenz. Es geht dabei weniger um Werkzeugwissen als um Urteilsvermögen. Darum, maschinell erzeugte Inhalte zu hinterfragen und für ihre Qualität geradezustehen, denn Verantwortung kann nicht an die KI delegiert werden. So bleibt es die Technische Redaktion, die Prozesse selbst dann steuert, wenn KI sie beschleunigt – und genau darin liegt das Thema, dem sich die neue Ausgabe der technischen kommunikation widmet.

Wie gewohnt gibt es unsere Kommentare zu Artikeln aus der Ausgabe 04/2026 und dazu einen Blick auf unsere eigenen Beiträge in der Zeitschrift. Vielleicht machen sie Ihnen ja Lust, selbst zum neuen Heft zu greifen? Dann wünschen wir Ihnen viel Spaß beim Lesen!

Edgarn Hellfritsch
CEO

Arbeit neu denken

Prof. Dr.-Ing. Michael Schaffner, technische kommunikation 04/2026, S. 13-17

Michael Schaffner zeichnet ein differenziertes Bild: Redaktion wird durch generative KI eher ergänzt, Übersetzung stärker verschoben oder ersetzt. Aus unserer Projekterfahrung greift diese Trennung zu kurz. Entscheidend ist nicht das Berufsfeld, sondern der Strukturierungsgrad der Inhalte: Ohne konsequente Topic-Orientierung, saubere Metadaten und ein Redaktionssystem, das Terminologie und Varianten kontrolliert, bleibt KI-Unterstützung in beiden Bereichen Stückwerk.

Auch beim Deskilling-Risiko würde ich den Fokus verschieben. Nicht KI selbst lässt Prüf- und Strukturierungskompetenz verkümmern, sondern das Fehlen klarer Governance: definierter Qualitätskriterien, verbindlicher Review-Routinen und eindeutiger Verantwortlichkeiten für Freigaben. Genau das erleben wir in Kundenprojekten immer wieder als Weichenstellung – Teams mit etablierten Redaktionsprozessen nutzen KI produktiv, ohne an Substanz zu verlieren; Teams ohne diese Leitplanken laufen tatsächlich Gefahr, Verantwortung stillschweigend an die Maschine abzugeben.

Markus Nickl
CEO

Der Einstieg in KI-Bildgeneratoren

Dr. Tilo Gockel, technische kommunikation 04/2026, S. 30-35

Texte mit KI zu erzeugen, ist mittlerweile weitverbreitet. Bei Bildern haben aber viele Nutzer:innen noch Hemmungen. Schon allein deshalb ist der Artikel von Tilo Gockel hochwillkommen. Mit tiefem technischem Verständnis zeigt er, wie KI-Bildgeneratoren funktionieren und wie sich welche Bildgeneratoren einsetzen lassen. Ein ausführliches Glossar wesentlicher Fachbegriffe rundet den Beitrag ab – auch das ist ein nützlicher Überblick für Einsteiger in die Thematik.

Ein wenig problematisch fand ich allerdings den Anfang des Artikels, der erst einmal recht theoretisch daherkommt. Interessierte Leser:innen sollten sich davon aber nicht abschrecken lassen, im zweiten Teil wird der Beitrag sehr viel praxisnäher. Dranbleiben lohnt sich also. Ich persönlich bin schon gespannt auf den vom Autor angekündigten zweiten Teil in Ausgabe 5.

Johannes Dreikorn
Senior Consultant / Customer Success

Risikomanagement aktiv mitgestalten

Marco Hattemer, technische kommunikation 04/2026, S. 33-36

„Ask not what your country can do for you“ – Marco Hattemer nutzt das Kennedy-Zitat geschickt als Scharnier für eine Frage, die sich jede Technische Redaktion stellen sollte: Was können wir zum Risikomanagement beitragen, statt nur zu warten, bis ein Ergebnis bei uns ankommt? Die Antwort fällt überzeugend aus: eine Menge. Denn Technische Redakteur:innen sind Kommunikationsprofis, Produktkenner und Zielgruppenexpertinnen in einem – genau das, was eine gute Risikobeurteilung braucht.

Was dabei oft übersehen wird: Der Gewinn ist wechselseitig. Die Redaktion profitiert durch mehr Sichtbarkeit, tieferes Produktwissen und einen „Platz am Tisch“, der ihr in vielen Unternehmen noch immer verwehrt wird. In unserer Prozessberatung begegnet uns dieses Thema regelmäßig: Die Redaktion ist keine Dokumentationsabteilung, die erst ins Spiel kommt, wenn alle inhaltlichen Entscheidungen gefallen sind, sondern eine Engineering-Truppe, die früh eingebunden werden muss. Das ist auch eine Frage der Compliance: Eine Risikobeurteilung, die normkonform sein soll, muss präzise, vollständig und nachvollziehbar dokumentiert sein – und das ist keine ingenieurtechnische, sondern eine kommunikative Leistung.

In unseren Projekten erleben wir, wie schwer dieser Schritt fällt: nicht weil der Wille fehlt, sondern weil die Strukturen dafür schlicht nicht vorhanden sind. Rollenmodelle, die die Technische Redaktion als echten Stakeholder im Risikomanagement verankern, sind die Ausnahme, nicht die Regel. Genau diese Arbeit kennen wir bei doctima gut: Wir begleiten Redaktionen dabei, ihren Platz im Unternehmen neu zu definieren – und die Prozesse aufzubauen, die Compliance nicht nur versprechen, sondern auch belegen.

 

Artikel aus dem Hause doctima

 

Haben Sie die neueste Ausgabe der tekom-Zeitschrift schon gelesen? Wir freuen uns auf den Meinungsaustausch mit Ihnen!

Coverfoto Zeitschrift: © tcworld GmbH

Automatisierung soll eigentlich beschleunigen. Prozesse laufen im Hintergrund, die Redaktion kann sich auf ihre eigentliche Arbeit konzentrieren, lästige Routinetätigkeiten erledigen sich quasi von selbst. So die Theorie. In der Praxis erleben wir manchmal das Gegenteil: Ein Workflow, der gut gemeint war, bremst plötzlich die Technische Redaktion aus, statt sie zu entlasten.

Ein Projekt bleibt mir dabei besonders in Erinnerung. Ein Abgleich zwischen Redaktionssystem und Dokumentenmanagementsystem, der eigentlich Arbeit abnehmen sollte, hat stattdessen die Clients im gesamten Team einfrieren lassen – für einen kompletten Arbeitstag. Wie es dazu kam und wie wir das Problem beheben konnten, erzähle ich hier.

Technisch korrekt, aber langsam

In vielen Technischen Redaktionen reicht es nicht, nur die eigentliche Anleitung zu pflegen. Zusätzlich müssen oft zahlreiche Dokumente referenziert werden, etwa Zertifikate oder Sicherheitsdatenblätter. Diese Dokumente liegen typischerweise in einem eDMS (elektronisches Dokumentenmanagementsystem) und werden von dort aus im Redaktionssystem verlinkt. In der Praxis zeigt sich oft: Ohne einheitliche Schreibweisen und ohne Prüfung, ob ein referenziertes Dokument überhaupt noch verfügbar ist, entstehen Inkonsistenzen.

Unser Kunde hatte diese Herausforderung bereits erkannt und schon bei der Einführung seines Redaktionssystems SCHEMA ST4 einen Workflow bauen lassen, der die Verlinkung automatisiert hat. Ein guter erster Schritt.

Das eigentliche Problem lag woanders: Die Dokumente im eDMS enthalten Metadaten, die auch für die Inhaltserstellung im CCMS wertvoll sind – etwa für die Zuordnung zu Taxonomien. Also wurde der bestehende Workflow so erweitert, dass er diese Metadaten ausliest und auf entsprechende Datenknoten im System mappt. Fachlich eine saubere Lösung. Nur leider eine, die kaum praktikabel war, wie sich herausstellte.

Bei rund 1000 Datenknoten hat ein vollständiger Abgleich mit dem eDMS etwa 24 Stunden gedauert. Das allein ist schon schlimm genug. Richtig problematisch wurde es dadurch, dass der Vorgang extrem ressourcenintensiv war: Während der Workflow lief, sind bei den Redakteur:innen die Clients eingefroren. Parallel im System zu arbeiten? Praktisch unmöglich.

Workflows arbeiten anders als Menschen

Woran lag das? Bei unserer Analyse hat sich gezeigt, dass die Ablauflogik des Workflows im Grunde menschliches Vorgehen nachgebildet hat: einen Datenknoten nach dem anderen abarbeiten, Taxonomie mappen, weiter zum nächsten. Für eine Person am Schreibtisch ist das ein gangbarer Weg. Für eine Maschine, die potenziell tausende Vorgänge parallel verarbeiten könnte, ist es das genaue Gegenteil von effizient.

Diese Beobachtung ist übrigens kein Einzelfall. Immer wieder sehen wir bei Digitalisierungsprojekten in der Technischen Redaktion, dass automatisierte Prozesse zwar funktionieren, aber schlicht die Denkweise sequenzieller, manueller Arbeit übernehmen, statt die Möglichkeiten der Systeme wirklich auszuschöpfen. Ein Workflow, der wie ein Mensch arbeitet, ist in der Geschwindigkeit immer limitiert.

Wie schnell kann ein Workflow werden?

Der entscheidende Hebel war, den Prozess von Grund auf neu zu denken, statt ihn nur zu optimieren. Statt Datenknoten einzeln und nacheinander zu bearbeiten, haben wir die Aufgabe parallelisiert und als Batchjob umgesetzt. Zusätzlich hat sich gezeigt, dass sich die zugrunde liegende Abfrage über die erweiterte Suchfunktion des Systems deutlich performanter lösen lässt als über den bisher genutzten ST-Path-Ansatz.

Das Ergebnis hat selbst uns überrascht: Aus 24 Stunden Laufzeit wurden 90 Sekunden. Kein Tippfehler – anderthalb Minuten. Ein Abgleich, der früher den kompletten Arbeitstag der Technischen Redaktion lahmgelegt hat, lässt sich heute kurz vor Feierabend nebenbei anstoßen, ohne dass jemand überhaupt etwas davon mitbekommt.

Automatisierung ist nicht automatisch besser

Was diesen Fall aus unserer Sicht besonders macht: Die Lösung lag nicht in mehr Rechenleistung oder einer neuen Softwarelizenz, sondern in einer anderen Herangehensweise an ein bestehendes Problem. Genau solche Stellschrauben zu finden, ist oft der Unterschied zwischen einem Workflow, der auf dem Papier gut aussieht, und einem, der die Technische Redaktion wirklich unterstützt.

Dieses Beispiel zeigt gut, dass Automatisierung allein noch keine gute Lösung garantiert. Entscheidend ist, wie ein Prozess intern aufgebaut ist – und ob er die Stärken des jeweiligen Systems tatsächlich nutzt. Ein Workflow, der zwar Arbeit abnimmt, dabei aber ganze Teams für Stunden ausbremst, hat sein Ziel nur halb erreicht.

Wenn Sie in Ihrer eigenen Redaktion ähnliche Erfahrungen mit trägen Workflows oder Systemintegrationen gemacht haben: Wie sind Sie damit umgegangen? Wir freuen uns über den Austausch – schreiben Sie uns gerne, welche Stolpersteine Ihnen bei der Automatisierung Ihrer Redaktionsprozesse begegnet sind.

Seien wir mal ehrlich: In jedem Unternehmen gibt es Dinge, die nicht so richtig rundlaufen. Und alle fragen sich, woran das liegt und wie man das lösen könnte. Wenn es dabei um sprachliche Probleme geht, heißt die Lösung erstaunlich oft: mit Terminologie (oder noch besser mit Bare Bones Terminology). In unserem heutigen Blogpost wollen wir deshalb einmal ein paar Problemsituationen vorstellen, die im Alltag viel Geld kosten und die sich oft recht einfach mit terminologischen Methoden lösen lassen.

Der KI-Chatbot kommt nicht gut an

Das strategisch wichtige KI-Projekt ist abgeschlossen, das passende, leistungsfähige Sprachmodell ist gewählt, die relevanten Inputdaten sind eingebracht, der neue Chatbot ist prominent auf der Homepage platziert. Und doch sind die Ergebnisse nicht zufriedenstellend: Chatbot und Kunden scheinen sich nicht so recht zu verstehen, nach anfänglicher Begeisterung sinken die Zugriffszahlen im Chatbot.

Der Grund könnte darin liegen, dass Chatbot und Kunden nicht die gleiche Sprache sprechen. Ist die Terminologie im Inputmaterial nicht stimmig, so fällt es der KI schwer, sich ein schlüssiges Gesamtbild zu erstellen. Relevante Inhalte werden nicht erkannt, weil scheinbar von einem anderen Bauteil, oder einer anderen Maschine die Rede ist. Andererseits kann eine einheitliche Terminologie ebenfalls schädlich sein, wenn die KI nur die festgelegten Benennungen kennt, die Kunden aber andere Bezeichnungen verwenden, z. B. „Ablassschraube“ statt „Entleerschraube“. Dann versteht die KI nicht, was der Kunde meint – Terminologie trifft auf Realität und die Kosten für das schöne, innovative KI-Projekt laufen ins Leere.

Der Support kommt nicht zurecht

Dasselbe Problem legt an anderer Stelle auch den Support auf Eis. Wenn die Bezeichnungen uneinheitlich sind, dann steigt die Bearbeitungsdauer für Supportfälle, die Erstlösungsquote (FCR) sinkt und die Zufriedenheit der Kunden wird weiter auf die Probe gestellt. Denn mit uneinheitlichen Bezeichnungen lässt sich nur schwer in den Daten- und Dokumentationsbeständen suchen. Oft wissen Supportmitarbeiter selbst nicht genau, ob sich hinter zwei verschiedenen Benennungen zwei unterschiedliche Materialkomponenten verbergen oder ob es sich nur um stilistische Varianz handelt. Aufwändige Klärungsprozesse sind dann die Folge, die Lösung für den Kunden verzögert sich.

Manche Unternehmen steuern dem gegen, indem sie notgedrungen den Personalbestand im Support erhöhen. Doch selbst dann wirken sich terminologische Probleme negativ aus, denn dadurch steigt die Einarbeitungszeit. Der Zeitpunkt, ab dem die neuen Mitarbeiter selbstständig zur Fehleranalyse beitragen können, verschiebt sich in die Zukunft.

Der Shop läuft nur so lala

Stellen Sie sich vor, Sie suchen ein Ersatzteil und finden es nicht im Shop des Herstellers. Was würden Sie tun? Beim Hersteller anrufen? Es beim Wettbewerber kaufen? Auf jeden Fall würde Sie das verunsichern, nicht wahr?

Falls Sie jetzt denken, das ist ja alles nur ein theoretisches Problem – ganz im Gegenteil. Ohne schlüssiges Terminologiemanagement stimmen zum Beispiel sehr häufig Bezeichnungen in Anleitungen und Ersatzteillisten nicht überein. Auf die Anfrage des Kunden liefert der Webshop schlechte Treffer. Die passenden Produkte sind durch unzureichende SEO mit allgemeinen Suchmaschinen wie Google oder Bing ebenfalls nicht zu finden. Im schlimmsten Fall bestellt der Kunde bei Wettbewerbern. Oder er ordert das falsche Produkt, ist unzufrieden und verursacht Rücklaufkosten für Ihr Unternehmen.

Die Übersetzungen dauern – und kosten

Wer viele Märkte bedient, der potenziert solche terminologischen Probleme. Zum einen, weil auch in den jeweiligen Zielsprachen zusätzliche Varianten entstehen. Zum anderen, weil terminologische Schwächen zu Verständnisproblemen bei menschlichen Übersetzern führen. Langwierige Klärungsschleifen sind dann notwendig. Noch dramatischer wird die Situation, wenn automatisierte Übersetzungen angefertigt werden. Dann besteht eine hohe Gefahr, dass Übersetzungsfehler und damit im schlimmsten Fall Sicherheitsrisiken auftreten.

Noch viel mehr Probleme

Das waren nur ein paar Beispiele, wie terminologische Ungenauigkeiten zu wirtschaftlichen Einbußen führen. Wer noch mehr sehen möchte, kann sich in unserem Blog informieren, wie unsystematische Stammdatenhaltung zu gravierenden Problemen führt. Denn eines haben all diese Fälle gemeinsam: Die Ursachen scheinen erst einmal klein und im Hintergrund zu sein, doch die Folgen haben oft gravierende finanzielle Auswirkungen.

Beim Digitalen Produktpass (DPP) gibt es aktuell wichtige gesetzliche Neuerungen: Die EU hat die zentrale DPP-Registry per Durchführungsrechtsakt verbindlich geregelt, und mit den ersten harmonisierten Standards liegt seit Kurzem auch die technische Basis offiziell im Amtsblatt vor. Aus dem bisherigen Rahmenwerk wird damit sichtbar mehr konkrete, betriebliche Infrastruktur.

Wir schauen uns die beiden Neuerungen etwas genauer an.

EU-Register für Digitale Produktpässe

Das EU-Register für Digitale Produktpässe ist, wie die Kommission es selbst beschreibt, ein Indexierungsdienst – eine Art zentrales Verzeichnis, in dem eindeutige Kennungen, Registrierungsdaten und grobe Metadaten zu jedem Produktpass hinterlegt werden. Die detaillierten Produktdaten bleiben dort, wo sie hingehören: dezentral, bei den verantwortlichen Unternehmen oder deren DPP-Dienstleistern. Das Produktpassregister ist also kein Datenspeicher für Produktpässe.

Wozu dieses Register? Bevor ein Produkt in der EU in den Verkehr gebracht wird, müssen die zuständigen Wirtschaftsakteure ihren DPP im Register hinterlegen. Die dazugehörige Durchführungsregelung 2026/1778 legt fest, wie das im Detail läuft – Zugangskontrolle, Nutzerverifikation, Datenregistrierung, Speicheranforderungen, technischer Systemaufbau.

Auch für Behörden ist die Registry relevant: Der Zoll kann darüber elektronisch prüfen, ob ein importiertes Produkt einen gültig registrierten DPP hat, bevor es zur für den Markt freigegeben wird. Marktüberwachungsbehörden bekommen für ihre Zwecke ebenfalls Zugriff.

Praktisch heißt das für Unternehmen: Die Registrierung läuft über ein EU-Log-in, danach folgt ein mehrstufiger Verifizierungsprozess für die eigene Organisation. Das Benutzerhandbuch für Wirtschaftsbeteiligte erklärt diese Schritte genau.

Erst wenn die Organisation verifiziert ist, lassen sich einzelne Produktpässe darüber registrieren – über den eindeutigen Produktidentifikator, der auf die tatsächlich gehosteten DPP-Daten verweist. Ein Testbereich steht parallel zur Verfügung, damit sich Unternehmen mit dem Ablauf vertraut machen können, ohne live Daten anzufassen.

Erste Standards für den Digitalen Produktpass

Fast zeitgleich mit dem Start der Registry hat die EU-Kommission den Durchführungsbeschluss 2026/1736 veröffentlicht, in dem die ersten harmonisierten Normen für digitale Produktpässe gelistet sind.

Das ist deshalb bedeutsam, weil diese Standards technisch festlegen, wie ein Produktpass überhaupt funktionieren muss, damit er EU-weit einheitlich lesbar und nutzbar ist. Aktuell sind sechs Normen veröffentlicht, zwei weitere zu Sicherheit und Verlässlichkeit befinden sich noch in Arbeit:

• EN 18216 – Protokolle zum Datenaustausch: definiert, wie Daten zwischen Systemen übertragen werden.
• EN 18219 – Eindeutige Kennungen: legt fest, wie Produkte eindeutig identifiziert werden.
• EN 18220 – Datenträger: regelt, wie die Verbindung zwischen physischem Produkt und digitalem Pass hergestellt wird, etwa über Kennzeichnung oder Datenträger.
• EN 18221 – Datenspeicherung, Archivierung und Datenpersistenz: beschreibt, wie Informationen langfristig gespeichert und verfügbar gehalten werden.
• EN 18222 – Programmierschnittstellen (APIs) für das Lebenszyklusmanagement und die Durchsuchbarkeit vom Produktpass: definiert Schnittstellen, über die ein Produktpass verwaltet und gefunden werden kann.
• EN 18223 – System-Interoperabilität: sorgt dafür, dass unterschiedliche Systeme dieselben Daten konsistent verstehen und nutzen können.

Zwei weitere Normen, EN 18239 (Benutzerrechte, IT-Sicherheit, Geschäftsgeheimnisse) und EN 18246 (Datenauthentifizierung, Zuverlässigkeit und Integrität), sind noch nicht final. Das sind ausgerechnet die Themen, bei denen es um Vertrauenswürdigkeit und Zugriffsschutz geht – also die Fragen, die in der Praxis oft Diskussionsbedarf auslösen. Hier lohnt sich also ein wachsames Auge auf die kommenden Monate.

Was bedeuten diese Standards? Für Unternehmen, die sich an die bereits veröffentlichten Standards halten, gilt eine Vermutung der Konformität – zumindest, soweit der jeweilige Standard den betreffenden Anforderungsteil tatsächlich abdeckt. Das ist ein handfester Vorteil, aber kein Freifahrtschein für alle Produktgruppen. Sektorale Vorgaben und weitere Detailanforderungen werden weiterhin separat geregelt.

Von der Idee in die Umsetzung

Vom groben Rahmen zur betrieblichen Umsetzung – so lässt sich der Sprung der letzten Woche wohl am treffendsten beschreiben. Das DPP-Register ist erreichbar, die ersten Standards sind verbindlich referenziert, und die technische Architektur des Digitalen Produktpasses bekommt langsam Kontur.

Für die Technische Redaktion ist das keine Randnotiz aus der Rechtsabteilung, sondern eine direkte Aufforderung, sich mit Datenmodellen, Metadaten und Wiederverwendbarkeit auseinanderzusetzen – am besten, bevor die nächsten Standards zu Sicherheit und Authentifizierung dazukommen.

Mit unserer DPP-Reifegrad-Checkliste können Sie schon jetzt prüfen, wie gut Sie auf den Digitalen Produktpass vorbereitet sind.

Die EU plant für zahlreiche Warengruppen eine Neuerung: den Digitalen Produktpass (DPP). Für Batteriehersteller wurde er bereits als Standard umgesetzt. Wir können also sicher sein, dass er auch für den Maschinenbau verpflichtend wird. Viele Technische Redaktionen beobachten deshalb diese Entwicklung mit Spannung. Denn bei diesem Standard stellen sich hohe Herausforderungen. Es bietet sich aber auch die Chance, sich als Technische Redaktion mit ihren Kernkompetenzen in einem Projekt einzubringen, das für das gesamte Unternehmen eine hohe strategische Wichtigkeit hat.

Andererseits fragen sich aber auch viele Redaktionen, ob es nicht sinnvoll ist, noch ein wenig abzuwarten. Denn bisher sind die genauen Details der Ausgestaltung des DPP für die meisten Branchen noch offen. Sehen wir uns also an, was dafür spricht, den Ball erst einmal flachzuhalten. Und was für einen baldigen Start spricht.

Option abwarten

Tatsächlich gibt es einige Aspekte, die darauf hindeuten, erst einmal abzuwarten, wie sich die Lage entwickelt. Sehen wir sie uns einmal ein wenig genauer an.

Da gibt es zum einen das Problem, dass die genauen Anforderungen für viele Produktgruppen und insbesondere für den Maschinenbau noch gar nicht feststehen. Wer also den DPP bereits jetzt vollständig implementieren möchte, läuft Gefahr, dass er Datenstrukturen und Funktionalitäten implementiert, die sich im Nachhinein als überflüssig erweisen. Das ist besonders angesichts der Komplexität von Maschinenbau-Produkten und auch wegen der langen Lebenszyklen schmerzhaft. Ärgerlich, wenn man hier ohne Not Geld in Datenstrukturen investiert hat, die später nicht gebraucht werden. Zumal Maschinenbauunternehmen die notwendigen Produktdaten oft gar nicht, nur verteilt oder unsystematisch strukturiert vorliegen haben.

Auch aus strategischen Gründen kann es lohnend sein, abzuwarten, wie energisch die EU ihre Regeln für den DPP durchsetzt. Wer zu spät reagiert, riskiert Bußgelder oder den Ausschluss vom EU-Binnenmarkt. Trotzdem kann es sinnvoll sein, erst abzuwarten: Da der digitale Produktpass zunächst andere Branchen betrifft, lohnt es sich, deren Erfahrungen zu beobachten und daraus abzuleiten, wie groß die rechtlichen Risiken in der Praxis tatsächlich sind.

Option gleich starten

Andererseits gibt es aber auch zahlreiche Punkte, um schon jetzt mit den Arbeiten zum Digitalen Produktpass zu beginnen. Der wichtigste Punkt: Der Digitale Produktpass wird häufig als eine Art Software-Einführung verstanden. Tatsächlich ist der Software-Aspekt aber der kleinere Teil der Arbeiten, die für den DPP notwendig sind. Im Wesentlichen geht es beim Digitalen Produktpass um die gezielte Sammlung, Vereinheitlichung und Bereitstellung von Produktinformationen. Das heißt, es geht um abteilungs- und teilweise sogar unternehmensübergreifende Prozesse, die miteinander abgestimmt und teilweise sogar erst noch aufgebaut werden müssen.

Die Komplexität der Prozesse ist dabei nur eine Seite der Medaille. Denn viele Unternehmen – das haben wir in zahlreichen Projekten zur Datenhomogenisierung festgestellt – überschätzen die Vollständigkeit und Qualität ihrer Daten. Oft liegen Daten in unabhängigen Varianten vor, es ist vieles ungeklärt, z. B. wo der Single Source of Truth liegt oder wie Verantwortlichkeiten bei der Datenpflege aussehen. Für viele Unternehmen wird deshalb der Zeitraum zwischen der Bekanntgabe der endgültigen Anforderungen des Digitalen Produktpasses und der verpflichtenden Einführung nicht ausreichen, um alle Daten und Prozesse korrekt und vollumfänglich bereitzustellen.

Aber wie lässt sich beginnen, auch wenn die geforderten Daten noch gar nicht feststehen? Nun, das ist gar nicht so schwer. Tatsächlich ist bei einem Großteil der Daten bereits heute erwartbar, dass sie Teil des Produktpasses werden: Produktbezeichnungen, Betriebs- und Verbrauchsstoffe, direkte Lieferantenbeziehungen etc. Solche Daten liefern ein ideales Testfeld, um Vorbildprozesse aufzubauen und Erfahrungen in der Datengewinnung und -homogenisierung zu sammeln.

Frühzeitig zu starten lohnt sich außerdem nicht nur für den Digitalen Produktpass. Eine bessere Datenqualität in den Stammdaten hilft an vielen Stellen: Unternehmensshop, Ersatzteilverwaltung, Supportanfragen – einmal optimiert profitieren zahlreiche Stellen im Unternehmen. Und gleichzeitig sorgt ein bereits laufender Produktpass dafür, dass man zeigt, dass man dem Wettbewerb (wieder einmal) eine Nasenlänge voraus ist. Denn der DPP hat eine hohe öffentliche Aufmerksamkeit. Wer ihn frühzeitig umsetzt, kann dadurch sein Image als Innovationstreiber weiter stärken.

Zu guter Letzt: Es gibt auch finanzielle Gründe, die dafür sprechen, schon jetzt tätig zu werden. Wie bei jeder umfassenden Stichtagseinführung dürfte auch beim DPP ein Engpass auftreten, wenn man sich zu spät Dienstleister sucht oder eine Produktpass-Software einführen möchte. In der Konsequenz muss man zu einem späten Zeitpunkt also mit höheren Kosten rechnen oder findet sogar gar keine qualifizierten Anbieter mehr.

Unser Fazit

Die Gründe, die für einen späten Start beim Digitalen Produktpass sprechen, sind real. So gesehen lässt sich jedes Unternehmen verstehen, das sich zunächst einmal fürs Abwarten entscheidet.

Aus unserer Sicht ist abwarten dennoch ein Fehler. Denn: Auch wenn manche Details noch nicht feststehen – der Digitale Produktpass wird sicher kommen. Der Digitale Produktpass muss deshalb schon jetzt Teil der Unternehmensstrategie sein, denn der Handlungsdruck ist real und die notwendigen Vorarbeiten sind komplexer, als sie auf den ersten Blick erscheinen.

Tatsächlich sind die wesentlichen Fakten auch bereits geklärt. Wer sich auf diese Punkte konzentriert, kann nichts verkehrt machen. So lässt sich Zeit gewinnen und frühzeitig auch ein Nutzeffekt generieren für andere strategische Themen wie digitaler Zwilling oder KI-Einführung.

Machen Sie deshalb jetzt den ersten Schritt. Mit unserer Gratis-Checkliste können Sie in wenigen Minuten selbst erfassen, wo Sie beim Digitalen Produktpass stehen. Sie gewinnen Klarheit über die wesentlichen Themenfelder, auf die Sie sich konzentrieren sollten. Und danach kommen wir gerne ins Gespräch.