Technische Spezifikation Generator

Das echte Ausmaß des Problems

Technische Spezifikationsdokumente in der Elektrotechnik, Pflichtenhefte, technische Beschreibungen, Produktspezifikationen, Inbetriebnahme-Dokus, folgen in aller Regel einer festen Struktur. 70–80 % des Inhalts ist wiederkehrend: Normverweise, Standardwerte für Betriebsparameter, Beschreibungen etablierter Systemkomponenten, Anforderungen an Schutzarten, Temperaturklassen, Spannungsebenen.

Trotzdem wird jedes Dokument neu geschrieben, oder besser: neu kopiert und angepasst. Das ist teuer, fehleranfällig und skaliert schlecht.

Eine Untersuchung von Produktivitätseffekten in Engineering-Umgebungen zeigt: Ingenieure verbringen durchschnittlich 3,2 Stunden täglich mit Dokumentationsarbeit, ein erheblicher Teil davon entfällt auf Tätigkeiten, die direkte Wiederholungen darstellen. Bei einer technischen Spezifikation von mittlerer Komplexität bedeutet das: 4–8 Stunden für ein Dokument, das bei vollständiger Automatisierung der Standardinhalte in unter einer Stunde fertig sein könnte.

Der unsichtbare Teil der Kosten liegt in den Qualitätsproblemen: Veraltete Normen aus kopierten Vorlagen, inkonsistente Bezeichnungen zwischen Projekten, vergessene kundenspezifische Anforderungen, die im letzten Review-Zyklus gefunden werden, wenn es teuer ist. Für einen mittelständischen Systemintegrator mit 20 Projekten pro Jahr und je 3–4 überarbeitungspflichtigen Dokumenten summiert sich das schnell auf Wochen vermeidbarer Überarbeitungsarbeit.

Mit vs. ohne KI, ein ehrlicher Vergleich

¹ Erfahrungswerte aus Implementierungen bei Elektrotechnikunternehmen mit 50–250 Mitarbeitenden.

Einschätzung auf einen Blick

Zeitersparnis, sehr hoch (5/5) Kein Anwendungsfall in dieser Kategorie spart Ingenieursstunden direkter und messbarer: Eine technische Spezifikation, die manuell 6 Stunden dauert, ist in 45 Minuten erledigt. Dieser Effekt tritt ab dem ersten Einsatz ein, nicht erst nach einer Anlaufphase. Auch der Aufwand für Revisionen und interne Reviews sinkt erheblich, weil Fehler aus Copy-Paste systematisch eliminiert werden.

Kosteneinsparung, niedrig (2/5) Die Kosteneinsparung ist real, aber sie entsteht primär über eingesparte Ingenieurszeit, nicht über direkte Materialkosten. Das macht sie schwerer zu isolieren und zu quantifizieren, als z.B. bei der Stücklisten-Analyse, wo Fehlerfolgekosten direkt in Produktionskosten übersetzt werden können. Unternehmen, deren Ingenieure mit der gesparten Zeit mehr Projekte statt besserer Projekte durchführen, sehen den Nutzen als Kapazitätserweiterung, was betriebswirtschaftlich wertvoll ist, aber schwerer in eine Zahl zu fassen.

Schnelle Umsetzung, hoch (4/5) Der Einstieg mit einem konfigurierten Template und einem LLM ist in 4–8 Wochen möglich, ohne ERP-Integration oder komplexe Systemanbindung. Wer bereits ein PLM oder ein Dokumenten-Management-System hat, kann darauf aufbauen. Wer ohne startet, kann mit einer strukturierten Prompt-Bibliothek in Claude oder ChatGPT beginnen. Etwas hinter der Stücklisten-Analyse, weil die Normenbibliothek gepflegt und die Templates professionell strukturiert sein müssen, das ist Aufwand, aber kein unüberwindbares Hindernis.

ROI-Sicherheit, sehr hoch (5/5) Kaum ein Anwendungsfall bietet eine direktere ROI-Messung: Du misst die Erstellungszeit vor der Einführung, misst sie nach der Einführung, und rechnest den Unterschied in Ingenieurszeit um. Kein Schätzen, keine Indirektheit. Auch die Qualitätsverbesserung, weniger Revisionen, aktuellere Normen, ist direkt zählbar. Das macht diesen Use Case zum einfachsten Business Case in dieser Kategorie.

Skalierbarkeit, sehr hoch (5/5) Ein einmal konfiguriertes Spezifikations-Template läuft auf beliebig viele Projekte, ohne proportional steigenden Aufwand. Neue Dokumenttypen können als neue Templates hinzugefügt werden. Das System wächst mit eurem Projektvolumen ohne Mehrkosten für Infrastruktur, anders als bei personalintensiven Prozessen, die mit jedem neuen Auftrag mehr Arbeit bedeuten.

Richtwerte, stark abhängig von Dokumentvolumen, Normvielfalt und Produktkomplexität.

Was der Generator konkret macht

Ein KI-gestützter Spezifikations-Generator arbeitet auf einem Zwei-Schichten-Modell:

Schicht 1, strukturierte Wissensbasis: Im System wird eine Bibliothek aus Standardwerten, Normverweisen, typischen Bauteilbeschreibungen und projektübergreifenden Formulierungen gepflegt. Diese Bibliothek ist das “firmeneigene Ingenieurswissen”, formalisiert, versioniert und jederzeit abrufbar.

Schicht 2, Generative KI als Extraktions- und Formulierungs-Schicht: Wenn eine neue Kundenanfrage oder ein Lastenheft eingeht, analysiert das LLM das Dokument und extrahiert kundenspezifische Anforderungen (Betriebstemperaturen, Schutzklassen, spezielle Prüfanforderungen). Die Template-Struktur wird automatisch befüllt, mit Standardwerten aus der Bibliothek für alle generischen Felder und mit den extrahierten Kundenwerten für die spezifischen Abschnitte.

Das Ergebnis ist ein strukturiertes Dokument, das der Ingenieur lediglich reviewt und freigibt, anstatt es von Grund auf neu zu erstellen. Die Zeitersparnis liegt hauptsächlich im Wegfall der “Suche nach dem letzten ähnlichen Projekt” und dem manuellen Kopieren und Anpassen.

Ein wichtiger Unterschied zur einfachen Template-Automatisierung: Das System versteht natürlichsprachliche Anforderungen. Wenn das Lastenheft schreibt “die Anlage soll in Außenbereichen mit Temperaturen bis -20 °C betrieben werden”, übersetzt das System das automatisch in “Schutzart IP54 erforderlich, Tieftemperaturzulassung nach IEC 60068-2-1”, und fügt den entsprechenden Normverweis ein.

Konkrete Werkzeuge, was wann passt

SCHEMA ST4, für professionelle technische Redaktion mit Normkonformitätsprüfung Das führende CCMS für technische Dokumentation im deutschsprachigen Maschinenbau und der Elektrotechnik. SCHEMA ST4 verwaltet Dokumentinhalte modular, prüft automatisch auf Normen-Compliance (EN 82079-1, CE, ATEX) und erzeugt variantenspezifische Ausgabedokumente aus einem einzigen Informationspool. Das integrierte AI-Modul unterstützt beim Verfassen und Redundanzcheck. Sinnvoll für Unternehmen mit 50+ Produktvarianten und mehrsprachiger Dokumentationspflicht. Einrichtung: 3–6 Monate, Kosten: ab ca. 2.000 €/Monat.

Paligo, für Cloud-basiertes Single-Sourcing ohne On-Premise-Infrastruktur Leichterer Einstieg als SCHEMA ST4, mit fokussierter Stärke bei Variantendokumentation und Übersetzungsworkflows. Für Unternehmen, die von Word/FrameMaker umsteigen und keinen eigenen CCMS-Server betreiben wollen. Kein deutschsprachiger Support, aber EU-Hosting.

Claude + Prompt-Bibliothek, für sofortigen Einstieg ohne Systemintegration Ohne Tool-Einführung und ohne CCMS: Ein gut konfigurierter System-Prompt, der die Unternehmensstandards, häufige Normverweise und Standardformulierungen kennt, erzeugt aus einem Lastenheft-Dokument in Minuten einen strukturierten Spezifikationsentwurf. Kein automatischer Normenabgleich, aber hervorragend als Drafting-Tool. Kosten: 20 Euro/Monat für Claude Pro oder API-Nutzung.

Microsoft 365 Copilot, für Word-/SharePoint-basierte Dokumentationsworkflows Wenn Spezifikationen als Word-Dateien in SharePoint gepflegt werden, kann Copilot beim Befüllen von Templates aus Quelldokumenten assistieren. Kein dediziertes CCMS, aber für Teams mit vorhandenem M365-Ökosystem ein schneller Einstieg. Kosten: ca. 30 €/Person/Monat zusätzlich.

Wann welcher Ansatz:

• Viele Produktvarianten, Normkonformitätspflicht → SCHEMA ST4
• Mittelgroßes Team, keine On-Premise-Infrastruktur gewünscht → Paligo
• Schneller Einstieg, wenig Budget → Claude + strukturierte Prompt-Bibliothek
• Microsoft 365 als primäres Ecosystem → M365 Copilot

Datenschutz und Datenhaltung

Technische Spezifikationen sind Kernbestandteil des geistigen Eigentums eines Elektrotechnikunternehmens. Sie enthalten proprietäre Konstruktionsansätze, kundenspezifische Anforderungen und interne Standardwerte.

Für cloud-basierte LLM-Tools gilt: Prüft, ob der Anbieter eure Dokumente für Modelltraining nutzt. OpenAI und Anthropic bieten Enterprise-Tarife an, in denen Daten nicht für Training genutzt werden, das sollte vertraglich gesichert sein. Der EU AI Act klassifiziert KI-Systeme für technische Sicherheitsdokumentation als potenziell hochriskant, technische Dokumentation, die sicherheitskritische Anlagen betrifft, erfordert besondere Sorgfalt bei Auswahl und Nachweis des eingesetzten Systems.

SCHEMA ST4 und Paligo bieten EU-Datenhosting: SCHEMA ST4 kann vollständig On-Premise oder in deutschen Rechenzentren betrieben werden. Für die LLM-Komponente gilt: Azure OpenAI Service mit EU-Datenresidenz (West Europe/Switzerland North) ist die DSGVO-freundlichste Variante, wenn keine On-Premise-LLM-Infrastruktur betrieben werden soll.

AVV-Pflicht nach Art. 28 DSGVO gilt auch hier, sobald personenbezogene Daten in Dokumenten verarbeitet werden (z.B. Ingenieursnamen, Kundenkontakte in Briefköpfen).

Was es kostet, realistisch gerechnet

Einmalige Einrichtungskosten

• Prompt-Bibliothek + Workflow-Setup (Claude/ChatGPT): 3.000–8.000 Euro für strukturierte Dokumentation der Standardinhalte und Prompt-Engineering
• SCHEMA ST4 oder Paligo Einführung: 15.000–50.000 Euro inkl. Migration bestehender Dokumente
• CCMS für mittelgroßes Team (5–10 Redakteure): 20.000–60.000 Euro Einrichtung

Laufende Kosten (monatlich)

• Claude API oder ChatGPT API: 20–100 Euro/Monat je nach Nutzungsvolumen
• SCHEMA ST4: ab ca. 2.000 €/Monat (Subscription)
• Paligo: auf Anfrage, früher ca. 400 USD/Nutzer/Monat
• M365 Copilot: ca. 30 €/Person/Monat

Konservative Nutzenrechnung 5 Ingenieure erstellen je 3 Spezifikationen pro Monat zu je 6 Stunden = 90 Ingenieursstunden. Bei 45 €/Stunde: 4.050 Euro/Monat. Bei 80 % Zeitersparnis (von 6h auf 1,2h): 3.240 Euro/Monat eingesparte Arbeitszeit. Bei Implementierungskosten von 15.000 Euro: Amortisation in unter 5 Monaten.

Wie du den Nutzen tatsächlich misst Einfachste Methode: Stopuhr vor und nach der Einführung. Dokumentiere für 10 Spezifikationen vor dem Rollout die gesamte Erstellungszeit inklusive Review-Zyklen. Nach 3 Monaten Betrieb dasselbe für 10 vergleichbare Dokumente. Die Differenz ist dein ROI-Nachweis.

Typische Einstiegsfehler

1. Templates ohne strukturierte Wissensbasis erstellen. Viele beginnen damit, ein LLM direkt aus dem Lastenheft in ein Spezifikationsdokument umwandeln zu lassen, ohne eine gepflegte Datenbank der Standardwerte. Das Ergebnis: Das System erfindet Standardwerte, oder es übernimmt Werte aus dem Lastenheft, die eigentlich durch interne Standarddefinitionen ersetzt werden sollten. Eine Wissensbasis ist keine optionale Ergänzung, sie ist die Grundlage, auf der das System arbeitet.

2. Normenbibliothek nicht pflegen. Normverweise in technischen Spezifikationen haben Gültigkeitsdaten. IEC-Normen werden typisch alle 5 Jahre überarbeitet, VDE-Umsetzungen folgen mit Verzögerung. Ein System, das mit Normreferenzen aus dem Jahr 2019 arbeitet, produziert ab 2025 systematisch veraltete Dokumente, die dann im Kundenreview oder schlimmer: bei der CE-Konformitätsbewertung auffallen. Quartalsweise Überprüfung der Normbibliothek ist Pflicht.

3. Dokumente ohne finale Freigabe durch Fachingenieur ausliefern. Kein KI-generierter Spezifikationsentwurf sollte ohne fachkundige Überprüfung ausgeliefert werden, insbesondere bei sicherheitskritischen Anlagen. Das ist keine Schwäche des Systems, sondern professionelle Sorgfalt. Wer das Modell als letztes Qualitätssicherungssystem positioniert statt als Drafting-Assistent, riskiert Haftungsprobleme und Reputationsschäden. Der Ingenieur reviewed und trägt Verantwortung, das System spart Zeit bei der Erstellung.

4. Alle Dokumenttypen gleichzeitig automatisieren wollen. Der Reflex, nach dem ersten Erfolg sofort alle Dokumenttypen in das System aufzunehmen, Betriebsanleitungen, Prüfpläne, CE-Erklärungen, führt zu einem halbfertigen System für alles. Besser: Mit einem Dokumenttyp starten (z.B. technische Spezifikation), diesen auf Produktionsreife bringen, dann erst ausweiten.

Was mit der Einführung wirklich passiert, und was nicht

Technische Redakteure und Ingenieure, die seit Jahren ihre Spezifikationen manuell erstellen, werden das System anfangs mit einer gesunden Skepsis betrachten. Das ist verständlich und sogar gut: Kritische Prüfung der ersten Outputs deckt Schwächen in der Wissensbasis auf, die sonst unbemerkt bleiben würden.

Was typischerweise passiert: Die ersten zwei, drei Dokumente zeigen, dass die Standardwerte-Bibliothek unvollständiger ist als gedacht. Formulierungen, die intern “klar” schienen, sind nicht dokumentiert. Normen, die “jeder kennt”, sind nirgends formal hinterlegt. Das ist wertvoll, und kostet Anpassungszeit, die bei der Einführung eingeplant sein muss.

Nach 6–8 Wochen tritt der Wendepunkt ein: Die Wissensbasis ist so weit gefüllt, dass das erste selbst erstellte Dokument länger gebraucht hätte als das generierte. Ab diesem Moment ist die Akzeptanz deutlich höher.

Was nicht funktioniert: Das System für “kreative” Spezifikationsarbeit nutzen, also für neuartige Anlagentypen ohne Vorläuferprojekte oder für sehr spezifische kundenindividuelle Anforderungen, die keine Entsprechung in der Wissensbasis haben. Für diese Fälle bleibt manuelle Arbeit notwendig, und das sollte offen kommuniziert werden.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

“Unsere Spezifikationen sind zu individuell für ein Template.” Das stimmt für einen Teil, aber beobachte mal, wie viel Text zwischen zwei Spezifikationen wirklich anders ist. Erfahrungsgemäß sind es 20–30 % individuelle Inhalte, 70–80 % Standardtext. Das System muss nicht alles automatisieren, um wertlos zu sein, selbst wenn es “nur” die Standardabschnitte liefert, spart das 60–70 % der Erstellungszeit.

“Was, wenn die KI falsche Normverweise einfügt?” Das ist das Risiko bei einem schlecht konfigurierten System. Die Lösung ist nicht, das System abzulehnen, sondern die Normbibliothek als verifizierte, gepflegte Quelldatenbank zu verwalten, nicht dem LLM überlassen, Normen aus dem Gedächtnis zu zitieren. Ein gut eingerichtetes System zieht Normverweise aus der eigenen Datenbank, nicht aus dem Trainingswissen des Modells. Die Unterscheidung ist entscheidend.

“Das bindet uns an einen einzigen Workflow.” Ein Spezifikations-Template ist kein Workflow-Lock-in, es ist eine formalisierte Best Practice. Sonderanforderungen können jederzeit manuell ergänzt werden. Der Unterschied zum aktuellen Stand: Der Standard-Teil ist schnell und konsistent, der individuelle Teil bekommt die volle Ingenieuraufmerksamkeit.

Woran du merkst, dass das zu dir passt

• Ihr schreibt im Jahr mehr als 20 technische Spezifikationen, und jedes Mal wird ein ähnliches Dokument von Grund auf neu erstellt
• Neue Teammitglieder brauchen Monate, um das implizite Wissen über Standardwerte und Normverweise zu lernen, das in keinem Dokument steht
• Eure Reviews und Freigabekollegen finden regelmäßig veraltete Normen oder inkonsistente Bezeichnungen, weil Dokumente aus Vorprojekten kopiert wurden
• Ihr habt Projekte verloren oder Nachbesserungsaufwand gehabt, weil Spezifikationen nicht dem aktuellen Normstand entsprachen
• Euer Dokumentationsaufwand wächst schneller als euer Team

Wann es sich noch nicht lohnt, drei harte Ausschlusskriterien:

1. Unter 15–20 Spezifikationsdokumenten pro Jahr. Der Aufwand für Wissensbasis-Aufbau und Template-Konfiguration amortisiert sich bei niedrigem Volumen nicht. Unter dieser Schwelle ist eine gut gepflegte Word-Vorlage mit aktuellen Normverweisen die bessere Investition.

2. Kein dokumentierter Standard für Spezifikationsinhalte vorhanden. Ein Spezifikations-Generator kann nur so gut sein wie das Wissen, auf dem er aufbaut. Wenn Standardwerte, Normverweise und Formulierungen ausschließlich in den Köpfen erfahrener Ingenieure stecken und nie formalisiert wurden, ist der erste Schritt die Wissenserfassung, nicht die KI-Einführung. Der Generator danach ist ein Bonus.

3. Kein Verantwortlicher für Wissensbasis-Pflege vorgesehen. Wie bei einem internen Wissensassistenten gilt: Ohne kontinuierliche Pflege werden Templates und Normbibliothek veralten. Nach 18 Monaten ohne Pflege generiert das System Dokumente, die nicht mehr dem aktuellen Normstand entsprechen, mit dem Unterschied, dass sie professionell formatiert aussehen und damit weniger auffällig falsch sind.

Das kannst du heute noch tun

Der erste Schritt braucht kein Tool, nur einen guten Prompt und ein vorhandenes Lastenheft-Dokument.

Quellen & Methodik

• Dokumentationsaufwand (3,2 Stunden täglich): Engineering Productivity Research, context-clue.com (2024); eigenständig bestätigt durch Befragungen in elektrotechnischen Planungsbüros.
• 60 % Reduktion Dokumentationsaufwand durch KI: MindStudio.ai “How Manufacturers Use AI to Automate Documentation Workflows” (2024). Hinweis: Herstellernähe, eigene Erfahrungswerte aus Pilotprojekten zeigen 65–80 % Reduktion der reinen Erstellungszeit, Gesamtprozess (inkl. Review) ca. 50 % kürzer.
• AI documentation completeness (94 % vs. 76 %): ResearchGate, “AI-Driven Automated Software Documentation Generation for Enhanced Development Productivity” (2024). Angewendet auf elektrotechnische Spezifikationen analog.
• Normaktualisierungszyklen IEC/VDE: IEC-Webstore (2025); ZVEI-Normenübersicht Elektrotechnik.
• EU AI Act und sicherheitskritische Dokumentation: Verordnung (EU) 2024/1689 (AI Act), Anhang III, Hochrisiko-KI-Systeme.

Du willst einschätzen, wie viel eurer aktuellen Spezifikations-Arbeit sich automatisieren lässt, bevor ihr eine Tool-Entscheidung trefft? Schreib uns, wir analysieren das gemeinsam.