Verantwortungsvolle KI-Innovation: Ethik als ingenieurwissenschaftliche Disziplin

Im Jahr 2024 ordnete ein niederländisches Gericht die Aussetzung des SyRI-Systems an, das algorithmisch Bürger identifizierte, die des Sozialbetrugs verdächtigt wurden. Der Algorithmus funktionierte im engen technischen Sinne effektiv: Er klassifizierte Fälle mit hoher Präzision auf Trainingsdaten. Er war jedoch eine Blackbox, wirkte unverhältnismäßig auf bestimmte demografische Gruppen und bot Bürgern keine Möglichkeit zur Anfechtung. Das Gericht sah darin eine Verletzung der Menschenrechte.

Das ist kein Beispiel für böse Absichten. Es ist ein Beispiel dafür, dass ethische Verantwortung als äußere Schicht behandelt wurde – etwas, das man „nach“ der Fertigstellung des Systems hinzufügt. Im Jahr 2026, mit dem geltenden AI Act und einer wachsenden Zahl ähnlicher Urteile, ist diese Reihenfolge im Design sowohl ethisch fragwürdig als auch rechtlich riskant.

Verantwortungsvolle KI-Innovation ist eine ingenieurwissenschaftliche Disziplin. Sie erfordert konkrete Entscheidungen auf Architekturebene, nicht Werteerklärungen im Footer.

Die Erklärbarkeit eines KI-Modells ist die Fähigkeit, anzugeben, warum das System eine bestimmte Empfehlung oder Entscheidung getroffen hat. In der Praxis des Designs geht es um drei verschiedene Fragen, die leicht verwechselt werden.

Erklärbarkeit des Mechanismus fragt danach, wie das Modell Daten intern verarbeitet. Bei neuronalen Netzen machen die großen Dimensionen (LLM mit Milliarden von Parametern) dies zu einer Forschungsaufgabe, nicht zu einer operativen. Niemand im Unternehmen wird bei täglichen Entscheidungen die Transformer-Schichten interpretieren.

Erklärbarkeit der Entscheidung fragt danach, was konkret in den Eingabedaten das Ergebnis für einen bestimmten Fall beeinflusst hat. Hier liefern Tools wie SHAP, LIME oder Attention Visualization nützliche Näherungen, insbesondere für Klassifikationsmodelle auf tabellarischen Daten. Für LLM, die Text generieren, ist es möglich, Quellfragmente zu zitieren (die RAG-Architektur liefert dies natürlich).

Auditerklärbarkeit fragt danach, ob nachvollzogen werden kann, warum das System zu einem bestimmten Zeitpunkt so und nicht anders geantwortet hat. Dies erfordert das Logging von Eingaben, Ausgaben, verwendeten Kontexten und Modellversionen – unabhängig davon, ob der interne Mechanismus verstanden wird.

Für die meisten Unternehmensanwendungen ist die Auditerklärbarkeit eine notwendige und erreichbare Bedingung. Die Erklärbarkeit des Mechanismus bleibt ein offenes Problem. Die Verwechslung dieser beiden Ebenen führt entweder zu einem falschen Sicherheitsgefühl (die Behauptung, man verstehe ein Modell, das man nicht versteht) oder zu einer Lähmung bei der Implementierung (das Warten auf vollständige Interpretierbarkeit, die nicht kommen wird).

Der AI Act verlangt Auditerklärbarkeit für Hochrisikosysteme, nicht vollständige Interpretierbarkeit. Das ist ein wichtiger Unterschied für Unternehmen, die Implementierungen planen.

Der klassische Vorwurf gegenüber KI in Unternehmen lautet „Blackbox“: Das System liefert ein Ergebnis, aber man weiß nicht, warum. Im Jahr 2026 ist dieser Vorwurf teilweise überholt, teilweise treffender als je zuvor.

Überholt, weil die RAG-Architektur mit Quellenangaben das Problem der Erklärbarkeit für wissensbasierte Systeme löst. Wenn ein KI-Assistent eine rechtliche oder medizinische Frage beantwortet, kann er auf einen konkreten Paragraphen eines Gesetzes oder einen Artikel aus der Wissensdatenbank verweisen, aus dem die Antwort stammt. Das ist keine vollständige Interpretierbarkeit des Modells, aber eine ausreichende Entscheidungserklärbarkeit für ein Audit.

Treffender, weil agentenbasierte Modelle, die mehrstufige Aufgaben ausführen (Buchung, Datenanalyse, Dokumentenversand), Entscheidungsketten erzeugen, bei denen jeder Schritt protokolliert werden kann, die Rekonstruktion des gesamten Entscheidungswegs im Fehlerfall jedoch schwierig ist. Je mehr Autonomie ein Agent hat, desto höher sind die Anforderungen an das Logging.

Drei Designmuster, die das Problem der Blackbox in der Praxis verringern:

• RAG mit Quellenangaben: Das Modell generiert Antworten nicht aus dem Gedächtnis, sondern auf Basis konkreter Fragmente. Jede Antwort enthält einen Verweis auf die Quelldokumente. Ein juristischer, steuerlicher oder medizinischer Assistent sollte zitieren, nicht paraphrasieren.
• Entscheidungslogs des Agenten: Jeder Aufruf eines Tools durch den Agenten (Suche, Datensatzänderung, Versand) wird mit Kontext protokolliert: Was war die Eingabe, welches Tool wurde aufgerufen, was war das Ergebnis. Bei einem Vorfall kann die Sequenz nachvollzogen werden.
• Human-Gate bei nicht umkehrbaren Aktionen: Entscheidungen, die nicht rückgängig gemacht werden können (E-Mail-Versand an Kunden, Vertragsänderung, Eintrag in ein Register), erfordern eine Bestätigung durch einen Menschen. Automatisierung ohne Human-Gate bei nicht umkehrbaren Aktionen ist ein Fehlerdesign, kein Systemdesign.

Bias in KI-Modellen ist ein Thema, das oft entweder bagatellisiert („Das ist nur Statistik“) oder übertrieben wird („KI ist immer voreingenommen“). Die Realität ist präziser.

Statistischer Bias ist die Differenz zwischen dem geschätzten Wert des Modells und dem wahren Wert. Jedes Modell hat ihn, und er ist eine Folge der Trainingsdaten und der Architektur. An sich ist das kein ethisches Problem.

Diskriminierender Bias entsteht, wenn das Modell systematisch bestimmte Gruppen, die durch geschützte Merkmale definiert sind (Geschlecht, Alter, Nationalität, Religion, Behinderung), schlechter bedient oder ungünstiger klassifiziert. Der AI Act klassifiziert Systeme, die Entscheidungen in den Bereichen Beschäftigung, Kreditvergabe, Bildung oder Zugang zu grundlegenden Dienstleistungen treffen, als Hochrisikosysteme, die vor der Implementierung auf Diskriminierung geprüft werden müssen.

Vier Fragen, die vor jeder Implementierung eines Entscheidungssystems gestellt werden sollten:

Verantwortungsvolle Innovation bedeutet nicht den Verzicht auf Entscheidungsmodelle. Sie bedeutet, dass die Antworten auf diese Fragen vor der Implementierung dokumentiert und bei jeder Modelländerung aktualisiert werden.

Viele Praktiker betrachten den AI Act als Belastung: eine weitere Liste von Anforderungen, die vor der Übergabe des Systems abgehakt werden muss. Das ist keine nützliche Projektperspektive.

Der AI Act als Designgerüst ist eine andere Lesart: Die Risikoklassifizierung zwingt dazu, zu fragen, was das System konkret tun wird und welche Folgen ein Fehler hat. Die Pflicht zur Registrierung von Hochrisikosystemen erzwingt eine Inventur dessen, was implementiert wurde. Die Logging-Anforderung zwingt dazu, von Anfang an einen Audit-Trail zu entwerfen. Die Anforderung von Human-Oversight zwingt dazu, die Grenzen der Automatisierung zu definieren.

Drei Anforderungen des AI Act, die gleichzeitig gute ingenieurwissenschaftliche Praktiken sind – unabhängig vom Recht:

Logs und Systemdokumentation. Der AI Act verlangt die Aufbewahrung von automatisch generierten Logs für Hochrisikosysteme. Selbst ohne diese Anforderung: Ein KI-System ohne Logs ist ein System, das nach einem Vorfall nicht debuggt oder auditiert werden kann.

Transparenz gegenüber Nutzern. Systeme, die mit Menschen interagieren (Chatbots, Assistenten, Empfehlungssysteme), müssen als KI identifizierbar sein. Das ist nicht nur eine rechtliche Anforderung – Nutzer, die wissen, dass sie mit einem Modell sprechen, haben andere und zutreffendere Erwartungen an Fehler und Grenzen.

Konformitätsbewertung vor der Implementierung. Für Hochrisikosysteme ist eine formale Bewertung vor der Markteinführung erforderlich. Für andere Systeme ist eine interne Risikobewertung (analog zur DPIA in der RODO) eine gute Praxis, da sie Lücken aufdeckt, bevor sie durch Vorfälle sichtbar werden.

Die rechtlichen Pflichten und Fristen des AI Act im Kontext polnischer Unternehmen werden ausführlich im Artikel AI Act und RODO 2026: Pflichten für Unternehmen behandelt.

Guardrails sind Mechanismen, die das Verhalten eines KI-Modells kontrollieren: was es sagen darf, auf welche Fragen es antworten soll, welche Aktionen es ausführen kann. Sie sind die technische Umsetzung ethischer Grenzen.

Ohne Guardrails neigen Sprachmodelle zu sogenannten Halluzinationen (Generierung sicherer Antworten auf Fragen, für die sie keine Daten haben), zum Verlassen des Themenbereichs, zur Anfälligkeit für Prompt Injection und zur Wiederholung von Mustern aus den Trainingsdaten, die voreingenommen oder veraltet sein können.

Guardrails werden auf mehreren Ebenen umgesetzt:

Eingabeebene: Filterung von Anfragen außerhalb des Bereichs, Erkennung von Manipulationsversuchen (Injection), Überprüfung, ob die Anfrage keine personenbezogenen Daten enthält, die vor dem Eintreffen beim Modell maskiert werden sollten.

Retrieval-Ebene (in der RAG-Architektur): Einschränkung der Quellen auf eine verifizierte Wissensdatenbank, Schwellenwert für Retrieval-Sicherheit – wenn das System kein ausreichend passendes Fragment findet, sollte es „Ich weiß es nicht“ sagen, statt eine Antwort aus dem Modellgedächtnis zu generieren.

Generierungsebene: Systemanweisung, die Rolle, Umfang und Grenzen definiert; Modelltemperatur, die auf die Aufgabe abgestimmt ist (niedrig für präzisionskritische Aufgaben, höher für kreative).

Ausgabeebene: Überprüfung der generierten Antwort vor der Rückgabe an den Nutzer – Prüfung von Format, Umfang und Vorhandensein geschützter Informationen.

Fortgeschrittenere Schutzmechanismen für agentenbasierte Systeme werden im Artikel Sicherheit von KI-Agenten behandelt.

Human-in-the-Loop ist ein Muster, bei dem ein Mensch in den Entscheidungsprozess eines KI-Systems eingebunden ist. Es wird oft als Standardlösung für jedes ethische Risiko betrachtet: „Wir fügen einen Menschen hinzu.“ Das ist ein Designfehler.

Ein Mensch in der Schleife ohne die richtigen Werkzeuge, Zeit und Kompetenz zur Bewertung von Entscheidungen erhöht nicht die Sicherheit – er schafft eine Illusion von Aufsicht. Ein Operator, der 200 algorithmische Entscheidungen pro Stunde genehmigt, kann keine davon wirklich bewerten.

Die produktive Frage lautet nicht „Sollen wir einen Menschen hinzufügen?“, sondern „Wo liegt die Grenze der Automatisierung?“. Eine nützliche Heuristik:

• Automatisierung ohne Aufsicht: Wiederholbare Aufgaben mit geringem Risiko und hoher Vorhersehbarkeit (Datenextraktion aus strukturierten Dokumenten, Klassifizierung nach klaren Regeln, Benachrichtigungen).
• Human-in-the-Loop: Entscheidungen mit Konsequenzen für einzelne Personen, bei denen Fehler vor der Ausführung erkannt und behoben werden können (Empfehlung eines Angebots an einen Kunden, Entwurf einer Antwort auf eine Beschwerde zur Genehmigung, Eskalation vom Assistenten zum Berater).
• Human-on-the-Loop: Das System arbeitet autonom, aber ein Mensch überwacht und kann eingreifen (Überwachung von Anomalien in Daten, Alerts zur Analyse).
• Ausschließlich menschliche Entscheidung: Nicht umkehrbare Maßnahmen mit hohem Risiko oder solche, die ein ethisches Urteil erfordern, das das System nicht liefern kann (Entscheidung über die Kündigung eines Mitarbeiters, Verweigerung einer medizinischen Dienstleistung, Bewertung eines Rechtsfalls mit Präzedenzfall).

Der AI Act bezeichnet diese letzte Ebene als Human-Oversight und verlangt sie explizit für Hochrisikosysteme. Bei der Gestaltung von agentenbasierten Systemen lohnt es sich, diese Ebenen bereits in der Architekturphase zu definieren, nicht im Nachhinein.

RODO wird oft ähnlich wie der AI Act behandelt: als Liste von Einschränkungen, die umgangen oder minimal erfüllt werden müssen. Für KI-Systeme bringt ein technischer Ansatz bessere Ergebnisse.

Das Prinzip der Datenminimierung (nur das Sammeln, was notwendig ist) ist gleichzeitig eine gute Ingenieurpraxis: Ein kleinerer Datensatz ist günstiger in der Wartung, einfacher zu auditieren und weniger anfällig für Lecks. PII in einem RAG-Index ist nicht nur ein rechtliches Risiko – es besteht die Gefahr, dass das Modell personenbezogene Daten in Kontexten verwendet, in denen es nicht sollte.

Vier Praktiken, die RODO-Compliance mit der Qualität von KI-Systemen verbinden:

Maskierung von PII vor dem Embedding. Personenbezogene Daten in Anfragen an den Assistenten (Namen, Telefonnummern, Adressen) sollten lokal maskiert werden, bevor die Anfrage an das Modell oder die Vektorsuche gesendet wird. Das schützt nicht nur die Privatsphäre – es entfernt Rauschen aus dem Index, was die Retrieval-Qualität verbessert.

Begrenzte Aufbewahrungsdauer von Logs. Konversationslogs sind für Audits und Systemverbesserungen unerlässlich, sollten aber eine definierte Aufbewahrungsdauer haben. Dauerhaftes Logging ohne Löschrichtlinie schafft ein wachsendes Risiko für Datenlecks.

Recht auf Löschung von Daten in RAG-Systemen. Wenn ein Nutzer die Löschung seiner Daten verlangt (Art. 17 RODO), muss das RAG-System nicht nur die Datensätze in der relationalen Datenbank, sondern auch die Vektoren im Vektorindex löschen. Die Architektur sollte dies von Anfang an unterstützen, nicht als spätere Anpassung.

DPIA für Systeme, die sensible Daten verarbeiten. KI-Systeme, die Gesundheits-, Finanz- oder Kinderdaten verarbeiten, erfordern vor der Implementierung eine Datenschutz-Folgenabschätzung. Das ist nicht nur eine rechtliche Anforderung – die DPIA systematisiert die Risikoanalyse auf eine Weise, die unabhängig von formalen Pflichten nützlich ist.

Für Unternehmen aus dem Finanz-, Rechts- oder Gesundheitssektor lohnt es sich, Self-Hosting von Modellen in Betracht zu ziehen, das das Risiko von Datenlecks durch externe APIs eliminiert. Technische und rechtliche Details dieses Ansatzes werden im Artikel Self-Hosted LLM und RODO behandelt.

Beschreiben Sie das KI-System, das Sie implementieren möchten oder bereits betreiben. Das Modell zeigt potenzielle ethische und rechtliche Risiken sowie konkrete Gegenmaßnahmen auf Architekturebene an (Playground: PII maskiert, keine Speicherung):

Nicht per Definition, aber unverantwortliche KI-Innovation führt oft zu Implementierungen, die nach den ersten Vorfällen gestoppt oder umgebaut werden müssen. Guardrails, Logging und Human-Gate, die von Anfang an entworfen werden, sind günstiger als nachträglich zu einem laufenden System hinzugefügt, das bereits Probleme verursacht hat. Die Kosten unverantwortlicher Implementierungen (Sicherheitsvorfälle, RODO-Verstöße, diskriminierende Entscheidungen) sind schwer im Voraus abzuschätzen, aber in der juristischen Literatur gut dokumentiert. Der Artikel Wo anfangen mit der KI-Implementierung beschreibt, wie diese Aspekte bereits in der Planungsphase berücksichtigt werden können.

Der AI Act definiert Hochrisikosysteme anhand von zwei Kriterien: der Anwendungskategorie und dem potenziellen Einfluss auf Grundrechte. Zu den Hochrisikokategorien gehören Systeme, die in der Personalbeschaffung und -verwaltung, der Kreditwürdigkeitsprüfung, dem Zugang zu Bildung, öffentlichen Dienstleistungen und grundlegenden Dienstleistungen, der Grenzkontrolle sowie der Justiz eingesetzt werden. Systeme, die in diesen Bereichen verwendet werden, erfordern die Registrierung in einer EU-Datenbank, technische Dokumentation, Logging, Human-Oversight und eine Konformitätsbewertung vor der Implementierung. Eine detaillierte Übersicht mit Beispielen für polnische Anwendungen bietet der Artikel AI Act: Hochrisikosysteme.

Die RAG-Architektur mit Quellenangaben ist das grundlegende Werkzeug. Das Modell antwortet auf Basis konkreter Fragmente aus der Wissensdatenbank, nicht aus dem parametrischen Gedächtnis, und jede Antwort enthält einen Verweis auf das Quelldokument. Ergänzende Mechanismen sind: ein Schwellenwert für die Retrieval-Sicherheit (Verweigerung der Antwort, wenn kein ausreichender Kontext vorhanden ist), eine auf die Aufgabe abgestimmte Modelltemperatur (niedrig bei präzisionskritischen Aufgaben), die Überprüfung von Struktur und Umfang der Antwort in der Guardrails-Schicht sowie regelmäßige Regressionstests mit einem Satz von Fragen und erwarteten Antworten. Methoden zur Begrenzung von Halluzinationen werden ausführlich im Artikel Wie man Halluzinationen von KI begrenzt behandelt.

Der AI Act gilt für Unternehmen, die KI-Systeme auf dem EU-Markt einführen oder in der EU nutzen – unabhängig von der Unternehmensgröße. Die Pflichten hängen von der Rolle ab: Der Anbieter eines Systems (das Unternehmen, das das System entwickelt oder im Auftrag implementiert) hat andere Pflichten als der Nutzer eines von einem externen Anbieter gekauften Systems. Kleine Unternehmen, die fertige KI-Tools nutzen (Assistenten, Chatbots von externen Anbietern), sind Nutzer und haben geringere formale Pflichten, haften jedoch weiterhin für die Art der Nutzung. Ein Unternehmen, das ein KI-System auf Bestellung oder für den Eigenbedarf in Hochrisikokategorien entwickelt, hat die vollen Pflichten eines Anbieters. Die Bewertung der Prozessreife und der Agenten-Blueprint helfen dabei, zu identifizieren, in welche Kategorie die geplante Implementierung fällt.

Die DPIA (Datenschutz-Folgenabschätzung) ist eine strukturierte Analyse der Risiken im Zusammenhang mit der Verarbeitung personenbezogener Daten. Für ein KI-System umfasst sie: die Beschreibung des Systems und des Datenflusses (was wird verarbeitet, von wem, wie lange), die Bewertung der Notwendigkeit und Verhältnismäßigkeit (ob der Zweck einen solchen Datenumfang erfordert), die Identifizierung von Risiken für die Rechte der Betroffenen (Zugang, fehlerhafte Entscheidungen, Datenlecks, Diskriminierung) und Gegenmaßnahmen für jedes Risiko. Eine DPIA ist erforderlich, wenn die Verarbeitung systematisch und in großem Umfang erfolgt, sensible Daten betrifft oder automatisierte Entscheidungen mit erheblichen Auswirkungen auf Personen umfasst. Das Tool Agenten-Blueprint führt durch die wichtigsten Designfragen, die der Ausgangspunkt für eine DPIA sind.