KI im Engineering braucht Regeln – und Vertrauen

Dass KI in PLM und Engineering Regeln braucht, hat sich inzwischen herumgesprochen. Es geht um Datenzugriffe, Zuständigkeiten, Freigaben, Nachweise und die Frage, welche Aufgaben ein System überhaupt übernehmen darf. Und am Ende muss ein Mensch die Verantwortung tragen.

Ich möchte diesem wichtigen Punkt etwas hinzufügen: KI im Engineering braucht nicht nur Regeln, sondern auch Vertrauen.

Das meine ich nicht sarkastisch. Und es ist auch kein Plädoyer dafür, einer KI einfach einen Vertrauensvorschuss zu geben. Vertrauen ist hier ganz konstruktiv gemeint: als Voraussetzung dafür, dass KI ihren Nutzen überhaupt entfalten kann. Wer einer KI keine Aufgabe und keinen Handlungsspielraum anvertrauen kann, hat am Ende vielleicht ein gut abgesichertes System – aber vermutlich nichts gewonnen.

Gleichzeitig entsteht Vertrauen nicht durch einen Beschluss. Es lässt sich nicht in einer Richtlinie verordnen und auch nicht dadurch ersetzen, dass jede einzelne Aktion von einem Menschen bestätigt werden muss. Vertrauen muss sich entwickeln: durch aktive Beschäftigung mit der KI, durch begrenztes Ausprobieren, durch Beobachtung ihrer Ergebnisse und durch ein wachsendes Verständnis ihrer Fähigkeiten und Grenzen.

Die eigentliche Managementfrage lautet deshalb nicht nur: Welche Regeln braucht die KI? Sie lautet auch: Wofür, unter welchen Bedingungen und mit welchen Folgen sind wir bereit, uns auf sie zu verlassen?

Das ist im Engineering besonders greifbar: Wenn eine KI eine Anforderungsbesprechung zusammenfasst, einen Widerspruch markiert oder nach ähnlichen Bauteilen sucht, ist ein Fehler meist(!) nur ärgerlich, aber beherrschbar. Wenn dieselbe KI eine freigegebene Stückliste verändert, eine Compliance-Aussage trifft oder einen Änderungsprozess bis in die Fertigung auslöst, sieht die Sache anders aus.

Vertrauen ist kein Freibrief

„Vertrauen ist gut, Kontrolle ist besser“ ist einfach gesagt und klingt richtig. Der Satz enthält schließlich einen wichtigen Kern: Ergebnisse sollten nicht ungeprüft übernommen werden. Im Umgang mit KI führt er jedoch in die Irre, wenn Kontrolle mit der Prüfung jedes einzelnen Arbeitsschritts gleichgesetzt wird.

Denn vollständige Einzelkontrolle skaliert nicht. Wer jede KI-Aktion einzeln bestätigt, schafft nicht automatisch mehr Sicherheit. Mit zunehmender Anzahl von Entscheidungen drohen Zeitdruck, Gewöhnung und Freigabemüdigkeit. Die Forschung zu Automation Bias beschreibt genau diesen Effekt: Wer mit einem automatisierten System arbeitet, prüft dessen Ausgaben mit der Zeit nachlässiger und übersieht Fehler, die ohne die Automatisierung aufgefallen wären. Am Ende wird dann möglicherweise genau das ungesehen bestätigt, was man eigentlich sorgfältig prüfen wollte.

Kontrolle ist also nicht kostenlos. Sie kostet Zeit, Aufmerksamkeit und Entscheidungskapazität. Und sie kann selbst zum Risiko werden, wenn sie an den falschen Stellen ansetzt.

Blindes Vertrauen ist aber keine Alternative. Ein plausibel formulierter Output (Stichwort AI Slop) ist noch kein belastbares Ergebnis. Eine KI kann überzeugend wirken, obwohl ihr Kontext fehlt, Daten falsch verknüpft sind oder sie eine Aufgabe außerhalb ihres geeigneten Einsatzbereichs bearbeitet.

Die entscheidende Frage lautet deshalb nicht: Vertrauen wir der KI? Sondern: Wofür, unter welchen Bedingungen und mit welchen Folgen sind wir bereit, uns auf sie zu verlassen?

Vertrauen bedeutet, unter Unsicherheit zu delegieren

In der Vertrauensforschung wird Vertrauen nicht als Gewissheit verstanden, dass der andere sich richtig verhalten wird. Vertrauen bedeutet vielmehr die Bereitschaft, sich unter Unsicherheit und trotz einer gewissen Verwundbarkeit auf eine andere Partei einzulassen. Mayer, Davis und Schoorman haben diese Perspektive für Organisationen prägend beschrieben.

Für den Einsatz von Automation ist eine ähnliche Unterscheidung wichtig: Ziel ist nicht möglichst viel Vertrauen, sondern angemessene Verlässlichkeitserwartung. Lee und See sprechen in diesem Zusammenhang von appropriate reliance: Menschen sollen sich auf Automation verlassen, wenn sie für eine Aufgabe geeignet ist – und zugleich in der Lage bleiben, ihre Ergebnisse zu beobachten, zu hinterfragen oder zurückzuweisen.

Das klingt abstrakt, wird im Engineering aber schnell konkret. Vertrauen in eine KI ist nicht global. Es lautet nicht: „Wir vertrauen diesem Modell.“ Es lautet eher:

Dafür sind mindestens drei Fragen entscheidend:

Gerade der letzte Punkt wird unterschätzt. Eine generische KI kann für viele Aufgaben nützlich sein. Daraus folgt aber nicht, dass sie für jede Aufgabe geeignet ist. Ein System, das Texte gut zusammenfasst, ist nicht automatisch ein System, das freigegebene Produktdaten verändern sollte.

Eine KI besitzt keinen Charakter im menschlichen Sinn und kein eigenes Verantwortungsbewusstsein. Sie ist aber auch keine vollkommen neutrale Instanz. Trainingsdaten, Modellverhalten, Systemvorgaben und bereitgestellter Kontext prägen, wie sie antwortet, was sie priorisiert, was sie auslässt und welchen Umgang mit Unsicherheit sie zeigt. Diese “Haltung” ist nicht Persönlichkeit. Sie ist dennoch relevant für die Frage, ob das System zum Zweck und zu den Regeln des Unternehmens passt.

Vertrauen entsteht durch aktive Beschäftigung

Ich verwende ganz gerne folgende Analogie: Bei einem neuen Mitarbeiter oder einem neuen Team weiß man am Anfang noch nicht genau, was man erwarten kann. Man kennt zwar den CV oder die Teambeschreibung. Man kennt aber nicht die Fähigkeiten aus eigener Erfahrung. Man weiß nicht, wie jemand mit unklaren Anforderungen, Zeitdruck oder Fehlern umgeht. Deshalb beginnt Zusammenarbeit meist mit begrenzten Aufgaben, Rückfragen, Beobachtung und Feedback.

Mit der Zeit entsteht ein Bild: Was kann diese Person? Wo arbeitet sie zuverlässig? Wann braucht sie Unterstützung? Welche Verantwortung kann sie übernehmen? Wenn dieses Bild stabiler wird, kann kleinteilige Kontrolle zurückgehen.

Die Analogie des neuen Mitarbeiters hilft auch beim Umgang mit KI. Sie hat allerdings eine wichtige Grenze: Ein geeigneter Mitarbeiter kann Regeln verstehen, Rückfragen stellen, aus Erfahrung lernen und sein Verhalten an neue Situationen anpassen. Eine KI tut das nicht automatisch in derselben Weise. Ihr Arbeitsrahmen (und die Lernschleife) muss stärker technisch und organisatorisch hergestellt werden.

Deshalb entsteht Vertrauen in KI nicht durch einen Beschluss und auch nicht durch eine Präsentation über die Fähigkeiten des neuesten Modells. Es entsteht durch aktive Beschäftigung mit dem konkreten System:

• reale, aber begrenzte Aufgaben geben;
• Ergebnisse und Fehlermuster beobachten;
• geeignete und ungeeignete Kontexte identifizieren;
• Erwartungen mit der tatsächlichen Leistung abgleichen;
• Regeln, Prompts, Datenzugriff und Prüfungen anpassen;
• Autonomie erweitern oder zurücknehmen.

Entscheidend für die Lernschleife ist folgender Regelkreis:

ausprobieren → beobachten → einordnen → begrenzen oder erweitern → erneut beobachten

Die Vertrauensforschung beschreibt einen ähnlichen Verlauf. Lewicki und Bunker unterscheiden ein rechnerisches Vertrauen, das sich auf Absicherungen und Sanktionen stützt, von einem Vertrauen, das aus wiederholtem Austausch und beobachteter Vorhersagbarkeit entsteht – und schließlich von einem Vertrauen, das auf geteilten Werten und Identifikation beruht. Die dritte Stufe steht für KI nicht zur Verfügung. Genau deshalb bleibt der Umgang mit KI dauerhaft auf beobachtete Vorhersagbarkeit angewiesen: Vertrauen wächst hier nicht aus einer einzelnen großen Leistung, sondern aus vielen Erfahrungen, die eine Erwartung stabilisieren – und aus Bedingungen, die diese Beobachtung überhaupt möglich machen.

Das hat eine unmittelbare Konsequenz für Unternehmen: Wer sich mit KI nicht aktiv beschäftigt, kann weder angemessenes Vertrauen entwickeln noch angemessene Grenzen definieren. Ein Unternehmen, das nur auf ein besseres Tool oder Modell wartet, verpasst die eigentliche Lernaufgabe. Ein leistungsfähiges Modell ohne ausreichenden Kontext, verlässliche Daten und passende Prüfungen ist nur ein schnellerer Weg zu einem falsch verstandenen Ergebnis.

KI braucht ein definiertes “Spielfeld” – nicht nur eine Freigabe

Dieses Spielfeld kann man aus zwei Perspektiven betrachten. Auf dem Spielfeld selbst steht die Frage, wie die KI arbeiten darf. Vom Spielfeldrand aus betrachtet steht die Frage, wie die Organisation mit ihren Ergebnissen umgeht.

Die erste Perspektive könnte man als Handlungsrahmen und Guardrails für die KI bezeichnen. Dazu gehören unter anderem:

• der Zweck und der zulässige Einsatzbereich;
• die Datenquellen und der bereitgestellte Kontext;
• ein gemeinsames Informationsmodell;
• erlaubte und verbotene Werkzeuge und Aktionen;
• Anforderungen an Quellen, Form und Qualität der Ergebnisse;
• Schwellenwerte und technische Sperren;
• Logging, Versionierung und Feedbackschleifen.

Guardrails sind dabei mehr als Hinweise im System-Prompt. Eine Grenze, die der Agent selbst überschreiben oder umgehen kann, ist keine belastbare Grenze. Kritische Einschränkungen sollten deshalb möglichst außerhalb des Modells durchgesetzt werden – etwa über Zugriffsrechte, feste Freigabeschwellen, API-Gateways oder Prozesslogik.

Die zweite Seite ist die Aufsicht und Verantwortungsarchitektur der Organisation. Hier muss klar sein:

• Wer ist fachlich verantwortlich?
• Wer darf ein Ergebnis übernehmen oder freigeben?
• Wann muss die KI pausieren und eskalieren?
• Welche Ergebnisse werden nur beobachtet, welche aktiv geprüft?
• Wie wird ein Fehler erkannt, zurückgenommen und ausgewertet?
• Wer darf eine Autonomiestufe erhöhen – und wer kann sie wieder senken?

Governance und Guardrails sind damit nicht dasselbe. Governance definiert den organisatorischen Rahmen: Was ist erlaubt, wer ist verantwortlich und wie wird überwacht? Guardrails übersetzen Teile dieses Rahmens in technische Beschränkungen zur Laufzeit.

Die Kunst besteht darin, nicht für jede Aufgabe dasselbe Kontrollregime anzuwenden. Ein einfacher Zusammenfassungsdienst sollte nicht denselben Freigabeprozess durchlaufen wie ein System, das in sicherheitskritische Produktdaten schreibt. Das MIT Center for Information Systems Research (van der Meulen, Jewer, Levallet) schlägt dafür den Begriff minimum viable governance vor: so viel Governance, wie zur wirksamen Begrenzung des Risikos erforderlich ist. Oberhalb einer gewissen Obergrenze, so die Forschungsgruppe, bremst Governance mehr, als sie schützt – Entscheidungen stauen sich, und die eigentliche Chance verstreicht.

Das soll kein Plädoyer für weniger Governance, sehr wohl aber für die passende Governance sein.

Verantwortung verlangt Verständnis – aber nicht um jedes technische Detail

Abgestufte Governance heißt aber auch: Nicht jede KI-Aktion landet auf einem Prüftisch. Und damit steht sofort ein Einwand im Raum. Wenn Verantwortliche nicht jeden Arbeitsschritt der KI nachvollziehen müssen, wie können sie dann Verantwortung übernehmen?

Die Antwort liegt in einer genaueren Unterscheidung des Begriffs “Verstehen”. Für verantwortliche Aufsicht sind mindestens vier Ebenen auseinanderzuhalten:

• Inhaltliches Verständnis: Was bedeutet das Ergebnis für Produkt, Prozess und Entscheidung?
• Prozessverständnis: Unter welchen Daten, Regeln, Kontexten, Prüfungen und Freigaben ist das Ergebnis entstanden?
• Risikoverständnis: Was könnte passieren, wenn das Ergebnis falsch, unvollständig oder außerhalb seines Geltungsbereichs ist?
• Technisches Detailverständnis: Wie lässt sich jeder interne Verarbeitungsschritt des Modells rekonstruieren?

Die ersten drei Ebenen sind für verantwortliche Entscheidungen regelmäßig unverzichtbar. Die vierte kann in speziellen Fällen relevant sein, ist aber nicht mit Verantwortung gleichzusetzen und bei komplexen Prozessen ohnehin nur begrenzt erreichbar.

Auch der EU AI Act verlangt für die menschliche Aufsicht über Hochrisiko-KI-Systeme nicht, dass jede interne Modellberechnung vollständig rekonstruiert werden kann. Art. 14 stellt auf anderes ab: dass Aufsichtspersonen die Fähigkeiten und Grenzen des Systems angemessen verstehen, dem Automation Bias bewusst begegnen und Ergebnisse einordnen, verwerfen oder übersteuern können. Abs. 3 verlangt zudem ausdrücklich, die Aufsicht am Risiko, am Autonomiegrad und am Nutzungskontext auszurichten – also genau die Verhältnismäßigkeit, um die es hier geht.

“Technisches Detailverständnis ist nicht immer erforderlich” darf also nicht bedeuten, dass fachliches Verständnis verzichtbar ist. Ein Mensch, der nur auf einen Freigabeknopf klicken darf, aber die Aussage, den Entstehungsprozess und den möglichen Schaden nicht beurteilen kann, übt keine wirksame Aufsicht aus. Er ist lediglich formal im Prozess.

Das Problem wird häufig als Rubber-Stamping beschrieben: Der Mensch bleibt zwar nominell im Regelkreis, wird aber faktisch zum Abnicker. Systemische Kontrolle ist deshalb nur dann verantwortbar, wenn sie mit echtem Prozess- und Risikoverständnis verbunden ist. Der EU AI Act nimmt dafür die Betreiber in die Pflicht – Art. 26 Abs. 2 verlangt, die Aufsicht Personen zu übertragen, die dafür die nötige Kompetenz, Schulung und Befugnis haben.

Engineering kontrolliert seit jeher Übergaben, nicht jeden Gedankenschritt

Prozess- und Risikoverständnis muss man deshalb nicht an jeder Stelle in maximaler Tiefe aufbringen, sondern an den entscheidenden Stellen. Diese Auswahl trifft das Engineering seit jeher bewusst: Gute Entwicklungsprozesse kontrollieren nicht jede einzelne Tätigkeit eines Konstrukteurs, einer Projektgruppe oder eines Lieferanten (gleichwohl das vorkommt, oft aus ökonomischen und Controlling-Gründen). Sie setzen Kontrollpunkte dort, wo sich Risiko, Verantwortung oder der Status eines Ergebnisses verändert.

Design Reviews, Verifikation und Validierung, FMEA, Freigaben und Quality Gates verfolgen genau diesen Zweck. Sie prüfen nicht jede Überlegung, die zu einem Ergebnis geführt hat (Ausnahme: besonders streng regulierte Branchen). Sie prüfen, ob das Ergebnis den Anforderungen entspricht, ob relevante Risiken betrachtet wurden und ob die notwendigen Nachweise vorliegen.

Auch hier wieder die Analogie: Die Organisations- und Kontrolltheorie unterscheidet zwischen Verhaltens- und Ergebniskontrolle. Die Unterscheidung geht auf Ouchi zurück; Eisenhardt verbindet sie mit der Agency-Theorie. Verhaltenskontrolle ist sinnvoll, wenn der Kontrolleur den Prozess versteht, der aus einem Input einen Output macht. Ergebniskontrolle ist sinnvoll, wenn Ergebnisse klar beschrieben und bewertet werden können.

Bei einem großen KI-Modell ist eine vollständige Kontrolle des internen Verarbeitungsvorgangs in der Regel keine realistische Grundlage für Verantwortung. Das heißt nicht, dass man nichts kontrollieren kann. Es bedeutet, dass die Kontrolle an andere Stellen verschoben werden muss: auf Kontext, Daten, Regeln, Nachweise, Ergebnisqualität und Übergaben.

PLM-Governance für KI muss also nicht bei null anfangen. Sie kann an bestehende Lifecycle-, Freigabe- und Change-Logiken anknüpfen. Gleichzeitig zwingt KI dazu, diese Prozesse auf ihre tatsächliche Risikowirkung zu prüfen. Ein ohnehin langsamer und bürokratischer Change-Prozess wird durch zusätzliche Einzelgenehmigungen nicht automatisch besser.

Der Autonomiegrad muss mit dem Risiko korrelieren

Wenn Kontrolle an relevanten Übergaben ansetzen soll, muss die Organisation entscheiden, welche Übergaben wie viel Kontrolle benötigen. Dafür braucht es ein Kriterium, das über die bloße Frage „KI oder keine KI?“ hinausgeht.

Methoden gibt es dafür längst: Die FMEA bspw. bewertet ein Fehlerrisiko über drei Größen: Bedeutung (wie schwer wirkt der Fehler?), Auftreten (wie wahrscheinlich ist er?) und Entdeckung (wie wahrscheinlich fällt er vorher auf?). Die ältere Systematik multiplizierte diese Werte zur Risikoprioritätszahl (RPZ); die harmonisierte AIAG-VDA-FMEA von 2019 ersetzt sie durch eine Aufgabenpriorität. Die funktionale Sicherheit arbeitet mit einem verwandten, aber anders geschnittenen Set: ISO 26262 leitet die nötige Sicherheitsstufe (ASIL) aus Schwere, Häufigkeit der Betriebssituation und Beherrschbarkeit ab. Die Beherrschbarkeit ist für die Delegationsfrage besonders aufschlussreich – lässt sich die Situation noch auffangen, wenn der Fehler eintritt? Ich borge sie mir als vierte Frage zu den drei FMEA-Größen.

Diese Größen (die drei der FMEA, ergänzt um die Beherrschbarkeit aus der funktionalen Sicherheit) eignen sich als Kriterium, wie viel Autonomie eine KI-Aufgabe verträgt.

Für die Kombination aus Ausbreitung und Reversibilität kursiert in der Praxisdiskussion zu KI-Agenten ergänzend der Begriff Schadensradius (englisch blast radius, entlehnt aus dem IT- und Cloud-Betrieb, wo er selbst schon eine Metapher aus der Sprengwirkungsanalyse ist): der Umfang des Schadens, den eine falsche Entscheidung anrichten kann, bevor jemand sie auffängt. Die griffige Faustregel dazu – die Aufsicht muss mit dem Schadensradius mitwachsen – stammt aus dem Blog eines Anbieters von Werkzeugen für Coding-Agenten. Der Begriff ersetzt die FMEA-Logik nicht, kann sie aber ergänzen.

Autonomie sollte deshalb nicht pauschal für ein Modell oder einen Agenten festgelegt werden. Sie ist eine bewusste Entwurfsentscheidung, keine automatische Folge steigender Modellfähigkeiten. Das zieht sich so durch mehrere Autonomie-Frameworks, von den Autonomiestufen des Knight First Amendment Institute bis zum Autonomie-Stufenmodell der Cloud Security Alliance. Für die eine Aufgabe kann KI Vorschläge machen, für eine andere Analysen vorbereiten und für eine dritte innerhalb harter Grenzen selbstständig handeln.

Eine pragmatische Abstufung könnte wie folgt aussehen:

Stufe	Bezeichnung	Was die KI darf
01	Vorschlagen	Die KI erzeugt Entwürfe, Zusammenfassungen, Klassifizierungen oder Suchergebnisse. Die weitere Verwendung bleibt außerhalb der KI und wird von Menschen entschieden.
02	Vorbereiten und informieren	Die KI verknüpft Informationen, analysiert Auswirkungen oder befüllt Änderungsdaten. Sie beeinflusst eine Entscheidung, löst sie aber nicht allein aus.
03	Ausführen innerhalb harter Grenzen	Die KI darf eine Aktion selbst auslösen, wenn Umfang, Datenzugriff, Schwellenwerte, Protokollierung, Rücknahme und Eskalation klar geregelt sind.

Diese Stufen sind keine starre Norm. Je nach Unternehmen und Anwendungsfall können nuanciertere Stufen sinnvoll sein.

KI zur Chefsache machen – aber nicht zur Bürokratie

Solche Kriterien lassen sich nicht per Richtlinie verordnen. Wer sie in ein Formular gießt, bekommt ein Formular und kein besseres Urteil darüber, welche Aufgabe wie viel Autonomie verträgt. Dieses Urteil entsteht in der Organisation, und dafür braucht es einige Leitplanken auf Führungsebene.

Vertrauen ist das Ergebnis guter Bedingungen

KI wird ihren Nutzen im Engineering erst dann voll entfalten können, wenn Unternehmen ihr nicht nur Aufgaben, sondern auch angemessenen Handlungsspielraum geben. Dieser Handlungsspielraum darf weder aus Euphorie entstehen noch aus Angst blockiert werden.

Und: Vertrauen in KI ist kein Ein/Aus-Schalter. Es ist aufgabenspezifisch, beobachtungsbasiert und widerrufbar. Es wächst, wenn ein Unternehmen sich aktiv mit der KI auseinandersetzt, ihre Fähigkeiten und Grenzen kennenlernt und aus ihren Ergebnissen Konsequenzen zieht.

Dafür braucht es einen guten Kontext, klare Leitplanken, relevante Kontrollpunkte, sichtbare Ergebnisse, geklärte Verantwortung und eine funktionierende Möglichkeit zur Rückstufung.

Die Zukunft des Engineering liegt deshalb weder in der vollständigen Kontrolle der KI noch in ihrer vollständigen Autonomie. Sie liegt in der Fähigkeit, ihr genau dort Handlungsspielraum zu geben, wo Menschen ihre Leistung, ihre Grenzen und die Folgen eines Fehlers verstanden haben.

Fragen und Antworten

Warum braucht KI im Engineering nicht nur Regeln, sondern auch Vertrauen?

Weil eine KI ihren vollen Nutzen erst entfaltet, wenn ihr eine Aufgabe und ein Handlungsspielraum anvertraut werden. Wer jede einzelne Aktion freigeben lässt, hat am Ende ein gut abgesichertes System – aber kaum etwas gewonnen. Vertrauen ist dabei kein Vorschuss, sondern die begründete Bereitschaft, sich für eine konkrete Aufgabe unter Unsicherheit auf das System zu verlassen.

Was ist der Unterschied zwischen KI-Governance und Guardrails?

Governance ist der organisatorische Rahmen: Was ist erlaubt, wer ist fachlich verantwortlich, wer gibt frei, wie wird überwacht? Guardrails übersetzen Teile davon in technische Beschränkungen zur Laufzeit – Zugriffsrechte, Schwellenwerte, API-Gateways, Prozesslogik. Entscheidend: Eine Grenze, die der Agent selbst überschreiben kann, ist keine Grenze. Kritische Beschränkungen gehören außerhalb des Modells durchgesetzt.

Wie viel Autonomie sollte eine KI im PLM und Engineering bekommen?

So viel, wie die einzelne Aufgabe verträgt – Autonomie wird pro Aufgabe zugewiesen, nicht pauschal pro Modell. Drei Stufen geben Orientierung: Vorschlagen (die KI erzeugt Entwürfe, Menschen entscheiden über die Verwendung), Vorbereiten und informieren (die KI verknüpft Informationen und analysiert Auswirkungen, löst die Entscheidung aber nicht aus) und Ausführen innerhalb harter Grenzen (die KI handelt selbst, wenn Umfang, Datenzugriff, Protokollierung, Rücknahme und Eskalation geregelt sind).

Wie bewertet man das Risiko einer KI-Aufgabe?

Über vier Fragen aus etablierten Engineering-Methoden. Aus der FMEA: Ausbreitung (wie weit wirkt ein Fehler in Produkt, Prozess und Organisation?), Kontextqualität (hat das System die richtigen Informationen?) und Beobachtbarkeit (fällt der Fehler auf, bevor er wirkt?). Dazu die Beherrschbarkeit aus der funktionalen Sicherheit nach ISO 26262, hier als Reversibilität: Lässt sich die Aktion in allen betroffenen Systemen zurücknehmen? Ausbreitung und Reversibilität zusammen ergeben den Schadensradius (blast radius) – und die Aufsicht muss mit ihm mitwachsen.

Reicht Human-in-the-loop als Aufsicht über KI-Systeme?

Nein. Ein Mensch im Prozess ist noch keine wirksame Aufsicht. Dafür muss diese Person die relevanten Informationen erhalten, das Ergebnis inhaltlich einordnen, seine Folgen abschätzen und tatsächlich eingreifen dürfen. Fehlen Zeit, Kompetenz oder Rücknahmemöglichkeit, entsteht Rubber-Stamping – der Mensch bleibt nominell im Regelkreis, wird aber zum Abnicker. Vollständige Einzelkontrolle hilft dagegen nicht: Sie erzeugt Freigabemüdigkeit und damit genau den Automation Bias, den sie verhindern soll.

Was verlangt der EU AI Act zur menschlichen Aufsicht über KI?

Art. 14 verlangt für Hochrisiko-KI-Systeme nicht, dass jede interne Modellberechnung rekonstruierbar ist. Gefordert wird, dass Aufsichtspersonen die Fähigkeiten und Grenzen des Systems angemessen verstehen, dem Automation Bias bewusst begegnen und Ergebnisse einordnen, verwerfen oder übersteuern können. Abs. 3 verlangt, die Aufsicht am Risiko, am Autonomiegrad und am Nutzungskontext auszurichten; Art. 26 Abs. 2 nimmt Betreiber in die Pflicht, sie Personen mit der nötigen Kompetenz, Schulung und Befugnis zu übertragen.

Kann zu viel Governance den KI-Einsatz behindern?

Ja. Das MIT Center for Information Systems Research fasst das als minimum viable governance: so viel Governance, wie zur wirksamen Begrenzung des Risikos nötig ist. Oberhalb dieser Grenze bremst sie mehr, als sie schützt – Entscheidungen stauen sich, die Chance verstreicht. Unpassende Governance fördert zudem Shadow AI: Mitarbeitende weichen auf den inoffiziellen Weg aus und entziehen den Einsatz gerade der vorgesehenen Kontrolle.