KI-Governance im Automotive-Engineering: GenAI, Agenten und KI-generierte Artefakte kontrollieren

Automobilunternehmen gehen von isolierten Experimenten mit generativer KI zu Systemen über, die Anforderungen prüfen, Architekturen analysieren, Bedrohungen vorschlagen, Code generieren, Tests erstellen, Defekte triagieren, Vorfälle zusammenfassen und Engineering-Werkzeuge aufrufen. Die Produktivitaetschance ist real. Die Governance-Herausforderung ebenso.

Ein Chatbot, der Besprechungsnotizen entwirft, erzeugt ein anderes Risikoprofil als ein KI-Assistent, der ein Bedrohungs-Szenario vorschlaegt. Ein Agent, der Issues eroeffnet, Anforderungen ändert, einen Prüfstand ausloest oder eine Restrisiko-Akzeptanz empfiehlt, hat eine wesentlich größere Konsequenz, weil er kontrollierte Engineering-Entscheidungen beeinflusst und über privilegierte Werkzeuge handeln kann.

Automotive-KI-Governance muss daher bis zum Arbeitsprodukt reichen und nicht beim Modell stehen bleiben. Teams müssen wissen, welches KI-System zu einer Anforderung, TARA, Kontrolle, einem Test, Bericht oder einer Vorfall-Entscheidung beigetragen hat; welche Quellen es genutzt hat; wer es geprüft hat; und welche Programme betroffen sind, wenn sich Modell, Prompt, Daten oder Workflow spaeter als fehlerhaft erweisen.

Dieser Leitfaden überträgt die Funktionen des NIST AI Risk Management Framework — Govern, Map, Measure und Manage — auf Automotive-Engineering und Cybersicherheit. Er zeigt auch, wie ThreatZ und Uraeus AI KI-unterstützte Cybersicherheitsarbeit innerhalb eines lebendigen CSMS steuern können, während die unternehmensweite Modellregistrierung, rechtliche Klassifikation, Datenschutz-Governance und Provider-Management in ihren autoritativen Systemen verbleiben.

KI-Beitraege zu kontrollierten Engineering-Artefakten steuern

Die wertvollste Governance-Frage lautet nicht "Hat jemand KI verwendet?". Sie lautet: "Hat KI ein Artefakt oder eine Entscheidung beeinflusst, auf die sich das Fahrzeugprogramm verlaesst?"

Kontrollierte Artefakte können sein:

• Item- und System-Definitionen.
• Anforderungen und Architekturentscheidungen.
• Schadens- und Bedrohungs-Szenarien.
• Angriffspfade, Machbarkeitsbewertungen und Risiko-Scores.
• Cybersicherheits-Ziele, Anforderungen, Kontrollen und Claims.
• Quellcode-, Konfigurations- und Kalibrierungsvorschlaege.
• Testfälle, erwartete Ergebnisse und Beweismittel-Zusammenfassungen.
• Lieferantenbewertungen und Schwachstellen-Entscheidungen.
• Compliance-Berichte und Cybersicherheits-Cases.
• Vorfall-Klassifikation, Impact-Analyse und Behebungsempfehlungen.

Erzeugen Sie für jeden wesentlichen Beitrag einen KI-Beitragsdatensatz, der mit dem finalen Artefakt verknuepft ist. Er sollte das KI-System und die Version, die Workflow- oder Prompt-Version, die Identität des Nutzers oder Agenten, autorisierte Eingabequellen, abgerufene Beweismittel, den Output-Zeitstempel, automatisierte Richtlinienentscheidungen, den menschlichen Reviewer, Annahme oder Ablehnung, Bearbeitungen sowie die final freigegebene Version erfassen.

Das ist nützlicher als ein generisches "KI-generiert"-Label. Es erzeugt eine prüfbare Kette von der Quellinformation über den KI-Vorschlag und die menschliche Entscheidung bis zum kontrollierten Arbeitsprodukt. Es unterstützt zudem die Blast-Radius-Analyse, wenn eine Modellversion, eine Retrieval-Quelle oder ein Agenten-Workflow spaeter zurückgezogen wird.

Mit einer Bestandsaufnahme von KI-Systemen und Workflows beginnen

Die meisten Organisationen können nicht steuern, was sie nicht sehen. KI gelangt durch Unternehmenslizenzen, Cloud-Plattformen, Entwicklerassistenten, Lieferantenwerkzeuge, Open-Source-Modelle, Browser-Erweiterungen, eingebettete Produktfunktionen und individuelle Accounts ins Engineering.

Inventarisieren Sie das vollstaendige KI-System, nicht nur das Foundation Model. Erfassen Sie:

• System-, Business- und technischen Owner.
• Anbieter, Modellfamilie, Version, Hosting und Region.
• Vorgesehene Anwendungsfälle und verbotene Nutzungen.
• Nutzer, Rollen, Projekte und angebundene Tools.
• Datenklassen, Retrieval-Quellen und Wissensbasen.
• Ob Prompts oder Outputs gespeichert oder für das Provider-Training verwendet werden.
• Agentenaktionen und Tool-Berechtigungen.
• Punkte für menschliche Prüfung und Freigabe.
• Evaluierungsergebnisse, Einschraenkungen und Akzeptanzschwellen.
• Regulatorische, sicherheitsbezogene, cybersicherheits-, datenschutz- und IP-Klassifikation.
• Lieferanten, Unterauftragsverarbeiter, Monitoring, Incident- und Stilllegungsplaene.

Verlangen Sie eine Registrierung, bevor ein System vertrauliche Engineering-Daten oder Zugriff auf einen Produktions-Workflow erhaelt. Discovery-Werkzeuge helfen, Schatten-KI zu finden; die Governance sollte aber auch dafür sorgen, dass der genehmigte Weg einfacher ist als der inoffizielle.

Für ThreatZ-angebundene KI sollte die Inventarisierung erkennen lassen, welche Module und Entitaeten die KI lesen oder Änderungen vorschlagen darf: Architektur, Assets, Bedrohungen, Risiken, Kontrollen, Tests, SBOM-Komponenten, Schwachstellen, Vorfälle, Berichte oder Organisationskataloge.

Anwendungsfälle nach Konsequenz klassifizieren

Eine Risikoeinstufung sollte widerspiegeln, was die KI beeinflussen kann — nicht, wie beeindruckend das Modell wirkt.

Stufe 1: Assistive, konsequenzarme Nutzung

Beispiele sind das Entwerfen nicht-vertraulicher Kommunikation, Umformatieren von Text oder Zusammenfassen freigegebener öffentlicher Inhalte. Kontrollen können leichter sein, dennoch zählen Datenschutz, IP und Genauigkeit.

Stufe 2: Engineering-Unterstützung

Die KI durchsucht freigegebenes Wissen, erlaeutert Code, prüft Anforderungen, fasst Befunde zusammen oder schlaegt Tests vor. Sie informiert Entscheidungen, kann aber kontrollierte Datensaetze nicht ohne menschliches Handeln ändern.

Stufe 3: Kontrollierte Engineering-Generierung

Die KI erzeugt vorgeschlagene Anforderungen, Bedrohungen, Angriffspfade, Kontrollen, Code, Testfälle oder Compliance-Texte, die in ein freigegebenes Arbeitsprodukt einfliessen können. Formale Provenienz, Evaluierung, Prüfung und Traceability sind erforderlich.

Stufe 4: Agentische Ausführung

Die KI kann Datensaetze erzeugen oder ändern, Issues eröffnen oder schliessen, Werkzeuge aufrufen, Analysen ausführen, Tests auslösen, Konfigurationen ändern oder Workflow-Zustaende vorantreiben. Strenge Workload-Identität, Least Privilege, Ausführungsgrenzen und explizite menschliche Autorisierung sind noetig.

Stufe 5: Produkt- oder sicherheitsrelevante KI

Das KI-Verhalten traegt zu einer Fahrzeugfunktion, betrieblichen Entscheidung oder sicherheitsrelevanten Ausgabe bei. Dies erfordert produktspezifische Safety-, Cybersecurity-, Validierungs- und Regulierungsprozesse jenseits der hier behandelten Unternehmenskontrollen.

Die Klassifizierung sollte Reversibilitaet, Skalierung, Detektierbarkeit, Datensensibilitaet, nachgelagerte Abhängigkeiten und Ausbreitung berücksichtigen. Ein Wortlautfehler in einem Entwurf ist leicht zu korrigieren. Ein generiertes Kontrollmuster, das in 30 Programme kopiert wird, kann einen grossen versteckten Defekt erzeugen.

Verantwortlichkeit über drei Ebenen definieren

KI-Verantwortung wird oft vage "dem Business" zugewiesen. Verwenden Sie drei explizite Owner.

System-Owner

Verantwortlich für den KI-Dienst, die Provider-Beziehung, Konfiguration, Zugriff, Sicherheit und Lebenszyklus.

Use-Case-Owner

Verantwortlich für den Workflow, Entscheidungsrechte, menschliche Prüfung, Leistungsanforderungen und das geschäftliche Ergebnis.

Artefakt- oder Produkt-Owner

Verantwortlich für die Anforderung, Architektur, Code, TARA, Test, Bericht, Release oder Betriebsentscheidung, die in das Fahrzeugprogramm eingeht.

Dieselbe Person kann mehrere Rollen halten, aber die Zustaendigkeiten müssen klar bleiben. Benennen Sie einen unabhängigen Reviewer für Anwendungsfälle mit hoher Konsequenz und eine Governance-Instanz, die das System aussetzen kann.

KI darf ihre eigene Arbeit nicht akzeptieren. Ein Recommender kann eine Bedrohung, Kontrolle oder einen Test vorschlagen; der verantwortliche Engineer akzeptiert, bearbeitet oder lehnt ab. Restrisiko-Akzeptanz, Compliance-Freigabe, Lieferantenakzeptanz und Release-Freigabe sollten menschlich kontrollierte Entscheidungen bleiben.

Daten vor Prompts steuern

Prompt-Vorgaben sind wichtig, die entscheidendere Kontrolle ist aber die Entscheidung darüber, welche Daten das System empfangen darf und wie sie behandelt werden.

Klassifizieren Sie Eingaben wie:

• Öffentliche Informationen.
• Interne Geschäftsinformationen.
• Vertrauliche Kunden- und Lieferantendaten.
• Quellcode und proprietaere Algorithmen.
• Fahrzeugarchitektur und Sicherheitsdesign.
• Personenbezogene Daten.
• Schwachstellen- und Vorfallinformationen.
• Exportkontrollierte oder regulierte Daten.
• Sicherheitsanalysen und unveröffentlichte Produktinformationen.
• Zugangsdaten, Schlüssel und andere Geheimnisse.

Definieren Sie für jede Klasse freigegebene Modell- und Hosting-Optionen. Sensible Engineering-Daten können private Cloud oder On-Premise-Bereitstellung, kein Provider-Training, eingeschraenkte Aufbewahrung, regionale Datenresidenz, Verschlüsselung, kontrollierte Administratoren und vollstaendige Audit-Logs erfordern.

Retrieval-Systeme müssen Quellberechtigungen erhalten. Ein KI-Assistent darf einem Engineer kein Lieferantendokument zurückgeben, das er an der Quelle nicht selbst öffnen könnte. Identität und Autorisierung müssen durch Retrieval, Zitate und Tool-Aufrufe propagiert werden.

In ThreatZ sollte KI nur mit Projekt- und Organisationsdaten arbeiten, auf die der Nutzer zugriffsberechtigt ist. Empfehlungen sollten Referenzen auf die Graph-Entitaeten und Beweismittel behalten, aus denen sie hervorgegangen sind, und nicht als unbelegter Freitext erscheinen.

Agenten-Identität und Berechtigungen kontrollieren

Ein Agent, der Werkzeuge aufrufen kann, ist wie ein privilegierter Service-Account zu behandeln.

Wenden Sie an:

• Eine eindeutige Workload-Identität.
• Getrennte Berechtigungen für Lesen, Vorschlagen, Ausführen und Freigeben.
• Least-Privilege-Zugriff auf Projekte, Repositories, Werkzeuge und Befehle.
• Umgebungstrennung zwischen Sandbox, Entwicklung und Produktion.
• Allowlists, Parameter-Validierung, Transaktionslimits und Rate-Controls.
• Menschliche Freigabe für wirkmaechtige Aktionen.
• Zeitlich begrenzte Credentials und schnelle Revokation.
• Vollstaendiges Logging von Tool-Aufrufen und Ergebnissen.
• Einen Kill-Switch und einen sicheren Rollback-Pfad.

Vermeiden Sie weitreichende Berechtigungen "damit der Agent nützlich sein kann". Beginnen Sie mit Nur-Lese-Kontext und vorgeschlagenen Änderungen. Erweitern Sie erst dann, wenn die Evaluierung verlaessliche Leistung zeigt und die Organisation Fehlfunktionen erkennen, eindaemmen und rückgaengig machen kann.

Tool-Beschreibungen und abgerufene Inhalte sind Teil der Sicherheitsgrenze. Ein manipuliertes Ticket, Dokument, Codekommentar oder eine Webseite kann den Agenten durch Prompt-Injection umlenken. Authentifizieren Sie Connectors, validieren Sie Tool-Outputs, trennen Sie Anweisungen von Daten und testen Sie mehrstufigen Missbrauch — nicht nur isolierte Prompts.

KI-unterstützte TARA als begrenzten Review-Workflow steuern

KI-unterstützte TARA ist ein starker erster Anwendungsfall, weil sie wertvoll, messbar und natuerlich prüfbar ist. Sie ist auch riskant, wenn Vorschlaege stillschweigend in freigegebene Bedrohungen oder Risiko-Entscheidungen umgewandelt werden.

Verwenden Sie einen sechsstufigen Workflow:

• Kontrollierter Kontext: Die KI erhaelt das freigegebene Systemmodell, den Item-Scope, Katalog und die Beweismittel, auf die der Nutzer zugreifen darf.
• Vorschlag: Die KI empfiehlt Kandidaten-Assets, Schadens-Szenarien, Bedrohungen, Angriffspfade, Kontrollen oder Testfälle mit Begründung und Quellenverweisen.
• Strukturierter Review: Ein qualifizierter Engineer sieht den Vorschlag neben der relevanten Architektur, dem bestehenden Risiko und der Quellinformation.
• Disposition: Der Reviewer akzeptiert, bearbeitet, lehnt ab oder stellt den Vorschlag zurück und dokumentiert den Grund wesentlicher Entscheidungen.
• Nachvollziehbare Baseline: Akzeptierte Inhalte werden zu einem versionierten Projekt-Artefakt, das mit seinem KI-Beitragsdatensatz und der menschlichen Freigabe verknuepft ist.
• Monitoring und Lernen: Praezision, Ablehnungsmuster, übersehene Bedrohungen, Reviewer-Aufwand und spaeter aufgetretene Defekte fliessen in Evaluation und Workflow-Verbesserung ein.

Uraeus AI in ThreatZ ist für dieses Propose-and-Review-Modell ausgelegt. Je nach aktivierten Modulen und aktuellem Release-Scope kann es Empfehlungen für Assets, Bedrohungen, Kontrollen und Tests unterstützen, Projekte auf fehlende Verknuepfungen prüfen und beim Import oder bei der Reparatur von Legacy-Datenbeziehungen helfen. Das Produktteam sollte "empfohlen" visuell und logisch klar von "freigegeben" trennen.

Die KI darf niemals eine Quelle erfinden, eine Risikomethodik stillschweigend ändern, ein Restrisiko freigeben oder eine kontrollierte Baseline überschreiben. Wenn die Beweismittel unvollstaendig sind, ist der korrekte Output ggf. eine Frage oder Luecke — keine selbstsichere Empfehlung.

Provenienz für KI-unterstützte Artefakte verlangen

Nützliche Provenienz umfasst:

• KI-System, Modell und Version.
• Prompt, Agent-Workflow und Policy-Version.
• Identität des Nutzers oder Workloads.
• Eingangsquellen und Retrieval-Referenzen.
• Output-Zeitstempel und ggf. aussagekraeftige Konfidenzindikatoren.
• Automatisierte Filter und Richtlinienentscheidungen.
• Menschlicher Reviewer und Disposition.
• Änderungen nach der Generierung.
• Finale Artefakt-Version und Freigabe.

Speichern Sie sensible Prompts nicht wahllos. Nutzen Sie risikobasierte Aufbewahrung und schuetzen Sie die Datensaetze. In manchen Fällen sind Hash, strukturierte Quellliste, Workflow-Version und Entscheidungs-Zusammenfassung angemessener als der vollstaendige Prompt.

Provenienz sollte abfragbar sein. Wird spaeter festgestellt, dass eine Modellversion eine Klasse von Angriffspfaden auslaesst, sollte die Organisation jeden TARA-, Kontroll- oder Testvorschlag identifizieren können, der darauf basiert.

Das System gegen den realen Workflow evaluieren

Generische Benchmark-Scores belegen keine Eignung für einen Automotive-Anwendungsfall. Evaluieren Sie mit repräsentativer Architektur, Terminologie, Daten, Nutzern und Fehlerkonsequenzen.

Messen Sie für Engineering- und Cybersecurity-Workflows:

Genauigkeit und Vollstaendigkeit

Sind die Empfehlungen technisch korrekt? Lassen sie kritische Assets, Bedrohungen, Annahmen oder Varianten aus?

Grounding und Traceability

Laesst sich jede wesentliche Aussage auf eine freigegebene Quelle, Graph-Entitaet, Regel oder klar gekennzeichnete Inferenz zurückführen?

Robustheit und Sicherheit

Wie reagiert das System auf mehrdeutige Eingaben, widerspruechliche Quellen, Prompt-Injection, vergiftete Retrieval-Inhalte, fehlerhafte Tool-Outputs und Berechtigungsgrenzen?

Konsistenz

Erzeugt derselbe freigegebene Input ohne Erklärung erheblich unterschiedliche Risikobehandlung? Bleibt der Output über Programme und Varianten konsistent?

Human Factors

Können Reviewer Fehler erkennen? Zeigt die Oberflaeche Quelle, Unsicherheit und Freigabestatus? Fördert die Arbeitslast durchdachte Prüfung oder Abnicken?

Betriebsleistung

Was passiert bei Modellausfall, Quota-Erschoepfung, Retrieval-Fehler, Provider-Wechsel oder unvollstaendiger Tool-Ausführung?

Erstellen Sie für KI-unterstützte TARA ein expertengeprüftes Evaluationsset. Verfolgen Sie Praezision von Kandidaten-Bedrohungen, Recall wichtiger Bedrohungen, unangemessene Kontrollen, fabrizierte Quellen, falsche Trace-Links, doppelte Vorschlaege, Review-Zeit und die Rate wesentlicher Änderungen nach Annahme.

Definieren Sie Akzeptanzschwellen vor dem Testen. Anwendungsfälle mit hoher Konsequenz sollten Negativtests, Red-Team-Übungen und unabhängige Prüfung umfassen.

Menschliche Aufsicht muss gestaltet, nicht erklärt werden

"Human in the Loop" kann sorgfaeltige Expertenprüfung oder einen Nutzer beschreiben, der nach einer Zeile auf Freigeben klickt. Gestalten Sie die Review-Aufgabe.

Legen Sie fest, wer qualifiziert ist, welche Beweismittel sichtbar sein müssen, was der Reviewer prüfen muss, welche Fehler eskaliert werden, ob ein zweiter Reviewer erforderlich ist, wie Uneinigkeit dokumentiert wird und welche Aktionen nicht delegierbar sind.

Vermeiden Sie Genehmigungsmuedigkeit. Erzeugt ein Agent Hunderte von Vorschlaegen geringer Wertigkeit, werden Nutzer sie abnicken. Verbessern Sie die Praezision, priorisieren Sie wirkmaechtige Empfehlungen und trennen Sie informativen Output von genehmigungspflichtigen Aktionen.

Für kritische Entscheidungen ist die KI der Vorschlagende und der menschlich gesteuerte Workflow bleibt die Entscheidungsinstanz. In ThreatZ sollten akzeptierte Empfehlungen denselben Versionierungs-, Freigabe- und Reporting-Prozess durchlaufen wie manuell erzeugte Artefakte.

Modell- und Workflow-Änderungen als Engineering-Änderungen behandeln

Cloud-KI-Dienste können Modelle, Safety-Filter, Kontextlimits, Retrieval-Verhalten, APIs, Hosting oder Unterauftragsverarbeiter ändern. Interne Teams ändern ebenfalls Prompts, Tools, Kataloge und Agenten-Berechtigungen.

Definieren Sie Trigger für wesentliche Änderungen:

• Neues Modell oder neuer Anbieter.
• Neuer Retrieval-Korpus oder Security-Katalog.
• Prompt-, Agent-Workflow- oder Policy-Änderung.
• Neue Tool-Berechtigung oder Projekt-Scope.
• Neue Datenklasse.
• Fine-Tuning-, Adapter- oder Embedding-Änderung.
• Wesentliche Evaluations-Drift.
• Neue rechtliche oder Lieferantenbedingungen.

Führen Sie vor dem produktiven Einsatz Regressions-Evaluierungen durch. Bewahren Sie die zuvor freigegebene Konfiguration und einen Rollback-Pfad. Halten Sie fest, welche kontrollierten Artefakte unter welcher Version erzeugt wurden.

Ein angebundenes CSMS macht die Änderungs-Impact-Analyse praktisch. Fällt ein Modell oder Workflow aus, kann ThreatZ helfen, die Architekturelemente, Bedrohungen, Kontrollen, Tests, Berichte und Programme zu identifizieren, die mit den betroffenen KI-Beitraegen verknuepft sind. Die KI-Plattform oder das Modellregister bleibt Source of Truth für den Modell-Lebenszyklus; ThreatZ liefert den Blast-Radius der Produktsicherheit.

KI im Betrieb überwachen

Die Pre-Deployment-Evaluierung ist nur eine Baseline. Überwachen Sie:

• Nutzung nach System, Team, Projekt und Datenklasse.
• Abgelehnte oder gegen Richtlinien verstossende Anfragen.
• Tool-Aufrufe und privilegierte Aktionen.
• Raten von menschlicher Annahme, Ablehnung und wesentlichen Bearbeitungen.
• Unbelegte Empfehlungen und Zitations-Fehlschlaege.
• Retrieval-Fehler und veraltete Quellen.
• Prompt-Injection- und Connector-Sicherheitsereignisse.
• Kosten, Latenz, Verfügbarkeit und Modell-Drift.
• Wirkmaechtige Outputs ohne abgeschlossene Prüfung.
• Unerwartete Anwendungsfälle oder übergreifender Projektzugriff.

Überwachen Sie für agentische Systeme Aktionssequenzen, nicht nur einzelne Aufrufe. Eine Reihe erlaubter Aktionen kann insgesamt ein unsicheres Ergebnis liefern.

Verknuepfen Sie wesentliche KI-Befunde mit dem betroffenen Projekt und Artefakt. Ein Modelldefekt ist nicht nur ein IT-Vorfall, wenn er eine Cybersecurity-Anforderung oder einen Test beeinflusst hat, der in ein Fahrzeugprogramm eingegangen ist.

Playbook für KI-Vorfall und Artefakt-Rückruf vorbereiten

KI-Vorfälle können die Offenlegung vertraulicher Daten, unautorisierte Tool-Ausführung, schädlich generierten Code, beschaedigte Anforderungen, falschen Compliance-Text, Prompt-Injection, Provider-Kompromittierung oder die breite Wiederverwendung einer fehlerhaften Empfehlung umfassen.

Die Reaktion sollte:

• Das System deaktivieren oder einschraenken und Zugangsdaten widerrufen.
• Logs, Modell- und Workflow-Versionen sowie relevante Beweismittel sichern.
• Betroffene Nutzer, Artefakte, Projekte, Lieferanten, Releases und Berichte identifizieren.
• Auswirkungen auf Produkt, Safety, Cybersecurity, Datenschutz und Vertraege bewerten.
• Generierte Artefakte unter Quarantaene stellen, prüfen oder korrigieren.
• Stakeholder bei Bedarf benachrichtigen.
• Evaluierungen, Kontrollen und Trainings aktualisieren.
• Eine kontrollierte Rückkehr in den Betrieb freigeben oder den Workflow ausser Dienst stellen.

Die schwierigste Aufgabe ist der Artefakt-Rückruf. ThreatZ kann ihn unterstützen, indem es KI-Beitragsdatensaetze mit kontrollierten Cybersecurity-Artefakten und deren nachgelagerten Beziehungen verknuepft. Die Organisation kann dann z. B. fragen, welche Hochrisiko-Kontrollen von Workflow-Version X vorgeschlagen wurden und über welche Programme hinweg wiederverwendet wurden.

Regulatorischer und normativer Kontext 2026

Der EU AI Act ist am 1. August 2024 in Kraft getreten und gilt in Phasen. Verbotene Praktiken und KI-Kompetenzpflichten gelten seit Februar 2025, während Governance-Regeln und Pflichten für General-Purpose-AI-Modelle ab August 2025 anwendbar sind. Die aktuelle Umsetzungsseite der Europaeischen Kommission gibt an, dass die meisten verbleibenden Regeln ab 2. August 2026 gelten, mit spaeteren Daten für bestimmte Hochrisikosysteme im Anschluss an die politische Einigung 2026 zum AI Omnibus. Organisationen sollten den finalen Gesetzestext und offizielle Leitlinien unmittelbar vor Veröffentlichung oder einer Compliance-Entscheidung verifizieren.

Nicht jeder interne Engineering-Assistent ist ein Hochrisiko-KI-System unter dem AI Act. Auch wo eine konkrete Pflicht nicht gilt, bleiben die Governance-Fähigkeiten wertvoll: Inventar, Rollen, Datengovernance, technische Dokumentation, Logging, menschliche Aufsicht, Genauigkeit, Robustheit, Cybersicherheit und Post-Deployment-Monitoring.

Das NIST AI RMF bietet eine freiwillige Struktur über Govern, Map, Measure und Manage. Sein Generative-AI-Profil ergänzt Aktionen für Risiken, die durch generative Systeme verstaerkt werden. ISO/IEC 42001 liefert ein Rahmenwerk für KI-Managementsysteme auf Organisationsebene. Automotive-Standards für Safety, Cybersecurity, Qualität und Software gelten weiterhin für die durch KI beeinflussten Artefakte und Produkte.

Der richtige Ansatz ist integrierte Assurance, kein separates KI-Papier-Silo.

Ein ThreatZ-Kontrollmuster für governte Uraeus AI

ThreatZ ist kein unternehmensweites Modellregister, keine allgemeine Datenschutzplattform und keine rechtliche AI-Act-Klassifikations-Engine. Seine staerkste Rolle ist die Steuerung von KI-Beitraegen innerhalb des Automotive-Cybersecurity-Engineerings.

Ein verteidigbares Kontrollmuster lautet:

• Kontext autorisieren: RBAC begrenzt Projekt, Katalog, Architektur, Lieferant und Beweismittel, auf die Nutzer und KI-Dienst zugreifen können.
• Vorschlag erzeugen: Uraeus AI erzeugt eine Empfehlung, einen Review-Befund oder einen Import-/Link-Reparatur-Vorschlag, statt ein freigegebenes Artefakt still zu ändern.
• Begründung erhalten: Der Vorschlag behaelt seine Quell-Entitaeten, Workflow-Version und relevanten Beweismittel.
• Disposition verlangen: Ein qualifizierter Owner akzeptiert, bearbeitet, lehnt ab oder eskaliert die Empfehlung.
• Ergebnis als Baseline setzen: Akzeptierte Inhalte gehen in Versionskontrolle und regulaere CSMS-Freigabe.
• Verifikation verknuepfen: Kontrollen und Anforderungen verbinden sich mit Tests und Beweismitteln; fehlgeschlagene oder veraltete Beweismittel können den Review wieder öffnen.
• Wirkung überwachen: Vorfälle, Schwachstellen, Architekturänderungen oder Modelldefekte lassen sich auf die betroffenen Risiken und Artefakte zurückverfolgen.
• Transparent berichten: Das Projekt kann zeigen, welche Inhalte KI-unterstützt waren, wer sie freigegeben hat und welche Beweismittel die finale Entscheidung tragen.

Das ist kommerziell staerker als die Behauptung "KI automatisiert TARA". Der Wert ist gesteuerte Beschleunigung: Die Plattform kann repetitive Analyse reduzieren und Engineering-Verantwortung, Traceability und Audit-Beweismittel intakt halten.

Ein 90-Tage-Pilot für governte KI in ThreatZ

Waehlen Sie einen begrenzten Workflow, zum Beispiel das Vorschlagen von Bedrohungen und Testfällen für einen ECU oder das Prüfen eines Projekts auf fehlende Risiko-Kontroll-Test-Verknuepfungen.

Tag 1-30: Scope und Baseline definieren

Registrieren Sie KI-System und Use Case. Waehlen Sie Projekt, autorisierte Daten, Reviewer-Rollen, verbotene Aktionen, Evaluierungsset, Akzeptanzschwellen und die aktuelle manuelle Baseline für Qualität und Aufwand.

Tag 31-60: Konfigurieren und evaluieren

Betreiben Sie Uraeus AI im Propose-Only-Modus. Messen Sie Praezision, kritische Auslassungen, fabrizierte Quellen, falsche Verknuepfungen, Reviewer-Zeit und Resistenz gegen Prompt-Injection. Erfassen Sie jede Disposition und stimmen Sie den Workflow ab, ohne die Risikomethodik still zu ändern.

Tag 61-90: Mit Kontrollen betreiben

Aktivieren Sie den freigegebenen Workflow mit RBAC, Provenienz, Review, Versionierung, Monitoring und Incident Response. Simulieren Sie einen Modell- oder Retrieval-Defekt und weisen Sie nach, dass das Team jeden betroffenen Vorschlag und jedes freigegebene Artefakt identifizieren kann.

Expandieren Sie erst, nachdem der Pilot sowohl Engineering-Wert- als auch Kontrollschwellen erfuellt.

Kennzahlen für das Management

Verfolgen Sie:

• Anteil registrierter und klassifizierter KI-Systeme und Workflows.
• Anteil hoch-konsequenter Anwendungsfälle mit freigegebenen Evaluierungen.
• Anteil der Agenten-Tools mit eindeutigen Least-Privilege-Identitäten.
• KI-unterstützte kontrollierte Artefakte mit vollstaendigen Beitragsdatensaetzen.
• Annahme-, Ablehnungs- und wesentliche Bearbeitungsraten von Empfehlungen.
• Recall wichtiger Bedrohungen und Rate unangemessener Kontrollen für KI-unterstützte TARA.
• Rate unbelegter Zitate und falscher Trace-Links.
• Zeit bis zur Identifikation von Artefakten, die von einem Modell- oder Workflow-Problem betroffen sind.
• Modell- oder Provider-Änderungen, die auf Regressionstests warten.
• Prompt-Injection- und unautorisierte Tool-Aufruf-Ereignisse.
• Reviewer-Aufwand und Geschäftsergebnis nach Use Case.
• Erkannte nicht freigegebene KI-Dienste.

Messen Sie Erfolg nicht nur an Lizenzen, Prompts oder generiertem Inhalt. Messen Sie, ob KI Engineering-Ergebnisse verbessert, ohne die Produktkontrolle zu schwächen.

Häufig gestellte Fragen

Reicht eine unternehmensweite KI-Nutzungsrichtlinie aus?

Nein. Richtlinien sind notwendig, doch jeder wesentliche Use Case braucht Owner, Datenregeln, Evaluierung, Berechtigungen, Provenienz auf Artefaktebene, menschliche Aufsicht, Monitoring und Änderungsmanagement.

Kann KI eine TARA oder Restrisiko-Akzeptanz in ThreatZ freigeben?

KI kann bei Vorschlaegen und Projektreviews helfen, doch verantwortliche Engineers sollten kontrollierte Artefakte und Risiko-Entscheidungen freigeben. Die KI darf ihren eigenen Output nicht freigeben.

Was unterscheidet agentische KI?

Ein Agent kann über Werkzeuge handeln, Systeme ändern und Schritte über die Zeit kombinieren. Governance muss Identität, Berechtigungen, Aktionssequenzen, Freigaben und Rollback steuern, nicht nur generierten Text.

Was ist der staerkste erste ThreatZ-Use-Case?

Ein begrenzter Propose-and-Review-Workflow für Bedrohungen, Kontrollen oder Testfälle an einem ECU ist stark, weil Qualität, Reviewer-Aufwand, Provenienz und sicheres Fehlverhalten messbar sind.

Wie oft sollte ein KI-System neu evaluiert werden?

Neu evaluieren bei wesentlichen Änderungen an Modell, Anbieter, Daten, Prompt, Katalog, Tool-Berechtigungen oder Workflow sowie nach einem risikobasierten Zeitplan, informiert durch das Betriebs-Monitoring.

Autoritative Referenzen

• NIST AI Risk Management Framework
• NIST AI RMF Playbook
• NIST Generative AI Profile
• Umsetzungsseite der Europaeischen Kommission zum AI Act
• Regulation (EU) 2024/1689 - der EU AI Act
• Leitlinien der Europaeischen Kommission für Anbieter und Betreiber von Hochrisiko-KI-Systemen
• ISO/IEC 42001:2023 - AI-Managementsysteme

Weiterführende Beiträge auf VxLabs

• ThreatZ AI Explainability
• ThreatZ Governance
• TARA mit KI automatisieren