Pexon Consulting | 9 Min. Lesezeit | 08.07.2026
TL;DR
KI Normkonformität bedeutet: Der Engineering-Copilot findet nicht nur die passende Norm, er prüft die Konstruktion aktiv gegen deren Regeln und meldet Verstöße mit Referenz („verletzt IEC 60076-3“). Pexon Consulting baut solche Prüf-Copilots mit ISO/IEC 42001 als Governance-Rahmen: auditierbar, nachvollziehbar, mit Audit-Log. Ergebnis: Norm-Reviews in Stunden statt Tagen.
Ein Engineering-Copilot ist genau dann wertvoll, wenn er gegen die Norm prüft. Wollt ihr, dass er sagt: das verletzt IEC 60076-3? Genau da trennt sich der teure Spielzeug-Chatbot vom echten Werkzeug. Ein Copilot, der nur die Norm findet und zitiert, spart einem erfahrenen Ingenieur zwei Minuten Suche. Ein Copilot, der die konkrete Konstruktion gegen die Norm-Regel rechnet und den Verstoß meldet, ersetzt einen halben Review-Tag.
Warum „Norm finden“ nicht reicht
Die meisten Engineering-Copilots, die aktuell gebaut werden, sind Retrieval-Systeme. Sie legen alle Normen, Datenblätter und internen Richtlinien in eine Vektor-Datenbank und beantworten Fragen wie „Was sagt die IEC 60076-3 zu Prüfspannungen?“. Das ist nützlich, aber es verschiebt nur das Nachschlagen. Die eigentliche Arbeit, nämlich zu bewerten ob die aktuelle Konstruktion die Norm einhält, bleibt komplett beim Menschen.
Der Unterschied ist fundamental. Retrieval beantwortet „Was steht in der Norm?“. Normprüfung beantwortet „Verletzt mein Design die Norm?“. Das Zweite braucht die Norm-Regel maschinenlesbar plus die konkreten Konstruktionsparameter plus eine Prüf-Logik dazwischen. Wer nur RAG auf PDF-Normen baut, kommt hier nicht hin. Wir raten Kunden, die den Prüf-Anwendungsfall wollen, klar von reinen Retrieval-Piloten ab: Ihr baut sonst zweimal.
Die Grenze klassischer Retrieval-Ansätze auf technischen Dokumenten liegt genau an dieser fehlenden Prüf-Schicht. Standard-RAG kann eine Norm zitieren, aber es rechnet nicht.
So prüft der Copilot gegen die Norm
Der Kern ist eine Trennung: Die Norm-Regel wird zu maschinenlesbaren Constraints, die Konstruktion liefert die Ist-Werte, und eine Prüf-Funktion vergleicht beide. Das LLM übernimmt das Verstehen der Anfrage und das Formulieren der Antwort, die eigentliche Konformitätsprüfung läuft deterministisch. Das ist wichtig: Ob 38 kV die zulässige Prüfspannung überschreitet, darf kein Sprachmodell „schätzen“, das rechnet eine Regel.
Ein vereinfachtes Beispiel für die IEC 60076-3 (Isolationskoordination bei Leistungstransformatoren), die den Zusammenhang zwischen höchster Betriebsspannung Um und zulässiger Kurzzeit-Wechselspannungs-Prüfung festlegt:
# Norm-Regel als maschinenlesbarer Constraint (Auszug IEC 60076-3, Tabelle 2)
# Ordnet der höchsten Spannung eines Betriebsmittels die Steh-Spannung zu.
IEC_60076_3_STEHSPANNUNG = {
12.0: 28, # Um in kV : zulässige AC-Steh-Spannung in kV
24.0: 50,
36.0: 70,
52.0: 95,
}
def pruefe_isolationskoordination(um_kv: float, gewaehlte_spannung_kv: float) -> dict:
# Prüft eine Konstruktion gegen IEC 60076-3, gibt Verstoß mit Referenz zurück.
soll = IEC_60076_3_STEHSPANNUNG.get(um_kv)
if soll is None:
return {"status": "unbekannt", "hinweis": f"Um={um_kv} kV nicht in Tabelle 2 gelistet"}
if gewaehlte_spannung_kv < soll:
return {
"status": "VERSTOSS",
"norm": "IEC 60076-3, Tabelle 2",
"meldung": f"Spannung {gewaehlte_spannung_kv} kV unterschreitet "
f"den Sollwert {soll} kV bei Um={um_kv} kV",
"sollwert_kv": soll,
}
return {"status": "konform", "norm": "IEC 60076-3, Tabelle 2"}
# Der Copilot übergibt die aus der Konstruktion gelesenen Werte:
ergebnis = pruefe_isolationskoordination(um_kv=24.0, gewaehlte_spannung_kv=38.0)
# -> {"status": "VERSTOSS", "norm": "IEC 60076-3, Tabelle 2",
# "meldung": "Spannung 38 kV unterschreitet den Sollwert 50 kV bei Um=24 kV", ...}Das LLM sitzt vor und hinter dieser Funktion. Vorne extrahiert es aus der Konstruktions-Anfrage die Parameter (Um, gewählte Spannung), hinten übersetzt es das strukturierte Verstoß-Objekt in einen sauberen Satz für den Ingenieur. Die Prüfung selbst ist auditierbarer Code, keine Halluzination. Genau dieses Muster, Konstruktionsdaten strukturiert gegen ein Soll abzugleichen, kennt ihr aus dem KI-gestützten Lastenheft-Abgleich, nur dass hier die Norm das Soll ist.
Für den Zugriff auf die Konstruktionsdaten selbst, etwa Werte aus CAD-Modellen oder Datenblättern, braucht es multimodale Extraktion. Die Werte müssen strukturiert und verlässlich aus PDF, Zeichnung oder Datenblatt kommen, bevor die Prüf-Regel überhaupt greifen kann.
Warum ISO/IEC 42001 hier zum Pflichtrahmen wird
Sobald eine KI aktiv über Norm-Konformität mitentscheidet, wird sie selbst governance-pflichtig. ISO/IEC 42001, veröffentlicht im Dezember 2023 als erste zertifizierbare Norm für KI-Managementsysteme (AIMS), liefert dafür den Rahmen: 38 Controls in 9 Bereichen (Annex A), Zertifikat drei Jahre gültig, jährliche Überwachungsaudits. Ein Prüf-Copilot, der einem Ingenieur sagt „das ist konform“, muss belegen können, wie er zu dem Urteil kam.
Der Punkt, den viele unterschätzen: Ein Copilot, der Norm-Verstöße meldet, ist in vielen Kontexten selbst ein KI-System mit Konformitätsbewertungs-Charakter. Damit rückt er in die Nähe der Hochrisiko-Kategorie des EU AI Act, dessen Pflichten für Hochrisiko-Systeme nach Annex III ab dem 2. Dezember 2027 und nach Annex I ab dem 2. August 2028 greifen (verschoben durch die Änderungsverordnung (EU) 2026/1744, in Kraft seit 27.07.2026). Bei Verstößen drohen Bußgelder bis 15 Mio EUR oder 3% des weltweiten Jahresumsatzes, je nachdem was höher ist. Wer den Copilot ohne Governance-Schicht in den Engineering-Prozess einbaut, baut sich ein Compliance-Risiko in den Kern.
Weltweit halten Stand Frühjahr 2026 erst rund 350 Organisationen ein ISO-42001-Zertifikat, die Norm ist also jung und der Wettbewerbsvorsprung für Early Mover real. Wie ISO 42001 und der EU AI Act zusammenspielen, ordnen wir im EU-AI-Act-Compliance-Framework ein. Wichtig zur Einordnung: ISO/IEC 42001 ist laut ISO derzeit keine harmonisierte Norm unter dem AI Act und begründet keine Konformitätsvermutung, aber sie ist der belastbarste verfügbare Nachweis reifer KI-Governance.
Das Audit-Log ist kein Nice-to-have
Ohne lückenloses Audit-Log ist ein Prüf-Copilot unter ISO 42001 nicht betreibbar. Die Norm verlangt Nachvollziehbarkeit und Rückverfolgbarkeit jeder KI-Entscheidung. Praktisch heißt das: Jede Norm-Prüfung wird protokolliert, mit Eingabe, angewandter Regel, Ergebnis und Modell-Version. Wenn ein Ingenieur in zwei Jahren fragt „Warum galt diese Konstruktion 2026 als konform?“, muss das System antworten können.
import json, datetime, hashlib
def log_normpruefung(nutzer: str, konstruktions_id: str, regel: str,
eingabe: dict, ergebnis: dict, modell_id: str) -> None:
# Schreibt jede Norm-Prüfung revisionssicher weg (ISO 42001: Nachvollziehbarkeit).
eintrag = {
"zeitstempel": datetime.datetime.utcnow().isoformat() + "Z",
"nutzer": nutzer,
"konstruktion": konstruktions_id,
"angewandte_regel": regel, # z.B. "IEC 60076-3, Tabelle 2"
"eingabe": eingabe, # geprüfte Ist-Werte
"ergebnis": ergebnis, # konform / VERSTOSS + Referenz
"modell_id": modell_id, # z.B. "claude-sonnet-4-6"
}
# Hash-Verkettung macht nachträgliche Manipulation erkennbar.
eintrag["hash"] = hashlib.sha256(json.dumps(eintrag, sort_keys=True).encode()).hexdigest()
with open("audit_normpruefung.jsonl", "a", encoding="utf-8") as f:
f.write(json.dumps(eintrag, ensure_ascii=False) + "n")
# Beispiel-Aufruf nach einer Prüfung:
log_normpruefung(
nutzer="m.weber", konstruktions_id="TRAFO-2026-0412",
regel="IEC 60076-3, Tabelle 2",
eingabe={"um_kv": 24.0, "spannung_kv": 38.0},
ergebnis={"status": "VERSTOSS", "sollwert_kv": 50},
modell_id="claude-sonnet-4-6",
)Die namentliche Modell-ID im Log (hier claude-sonnet-4-6) ist kein Detail. Wenn ihr das Modell wechselt, ändert sich potenziell das Prüfverhalten, und das Audit muss zeigen können, welche Version welches Urteil gefällt hat. Das ist der Unterschied zwischen „wir nutzen halt KI“ und einem auditierbaren KI-Managementsystem.
Der blinde Fleck: geistiges Eigentum und Exportkontrolle
Der am häufigsten übersehene Governance-Aspekt ist, wer welche Norm und welche Konstruktionsdaten überhaupt sehen darf. Konstruktionsdaten kontrollierter Produkte fallen unter die Dual-Use-Exportkontrolle, und seit dem Maßnahmenpaket vom 1. Februar 2026 ist auch der immaterielle Transfer klar erfasst: Es braucht keinen physischen Versand, damit ein Compliance-Verstoß entsteht. Ein Copilot, der Norm plus Konstruktion zusammenführt und die Antwort an einen Nutzer im falschen Land oder ohne Berechtigung ausgibt, kann genau diesen Transfer auslösen.
Unsere klare Empfehlung: Baut die Berechtigungsprüfung direkt in den Copilot, nicht daneben. Vor jeder Ausgabe prüft das System Freigabestufe, Standort und geschäftliche Notwendigkeit, exakt so, wie man es bei exportkontrollierten technischen Spezifikationen ohnehin tun muss. Das ist auch der Grund, warum wir bei diesen Projekten fast immer auf einen souveränen, in Deutschland gehosteten Stack routen statt auf eine beliebige Public-Cloud-API. Das gehört in dieselbe Governance-Schicht wie das ISO-42001-Audit-Log, nicht in ein separates Nachgelagertes.
Häufig gestellte Fragen
Was ist der Unterschied zwischen KI Normkonformität und einem normalen RAG-Copilot?
Ein RAG-Copilot findet und zitiert die passende Norm, die Bewertung bleibt beim Menschen. Ein normkonformer Prüf-Copilot rechnet die konkrete Konstruktion gegen die Norm-Regel und meldet Verstöße mit Referenz und Sollwert. Der entscheidende Zusatz ist eine deterministische Prüf-Schicht plus ein Audit-Log, nicht nur die Suche über Norm-PDFs.
Was kostet ein Engineering-Copilot mit Normprüfung?
Ein belastbarer Pilot auf einer klar abgegrenzten Normfamilie (zum Beispiel IEC 60076 für Transformatoren) liegt bei uns im Bereich eines 6-Wochen-Projekts mit Budgets zwischen 50k und 90k EUR, abhängig davon wie viele Normen maschinenlesbar gemacht werden müssen. Der teure Teil ist selten das LLM, sondern das Übersetzen der Norm-Tabellen in prüfbare Constraints.
Brauche ich ISO 42001, um so einen Copilot zu betreiben?
Zertifiziert sein müsst ihr nicht sofort, aber nach ISO 42001 arbeiten solltet ihr von Anfang an. Sobald die KI über Konformität mitentscheidet, braucht ihr Nachvollziehbarkeit, Audit-Log und Modell-Versionierung, genau das, was die Norm fordert. Es ist deutlich billiger, das von Tag eins einzubauen als es später nachzurüsten.
Fällt ein Norm-Prüf-Copilot unter den EU AI Act?
Häufig ja, weil ein System, das über Konformität mitentscheidet, Charakteristika eines Hochrisiko-Systems tragen kann. Die Hochrisiko-Pflichten greifen nach der Änderungsverordnung (EU) 2026/1744 ab dem 2. Dezember 2027 (Annex III) bzw. 2. August 2028 (Annex I), bei Verstößen drohen Bußgelder bis 15 Mio EUR oder 3% des Jahresumsatzes. Wir bewerten die Einstufung projektbezogen, statt sie pauschal zu behaupten.
Kann die KI die Norm-Prüfung selbst durchführen oder braucht es Code dahinter?
Die eigentliche Grenzwert-Prüfung sollte deterministischer Code sein, kein Sprachmodell. Ob 38 kV unter dem Sollwert von 50 kV liegen, ist eine Rechnung, keine Interpretation. Das LLM übernimmt das Verstehen der Anfrage und das Formulieren der Antwort, das Urteil über Konformität liefert die Regel. Das ist auch aus Audit-Sicht sauberer, weil jede Entscheidung reproduzierbar ist.
Nächster Schritt
Wenn ihr gerade evaluiert, ob ein Engineering-Copilot bei euch mehr sein soll als eine bessere Suche: Der schnellste Weg ist, den Prüf-Anwendungsfall an einer echten Normfamilie durchzuspielen, mit Governance von Anfang an.
Verwandte Themen
→Multimodale RAG-Pipelines für ISO-Normen und CAD
→KI-gestützter Lastenheft-Abgleich in der Praxis
