EU AI Act: Wir sind bereit

Der Moment, in dem der Agent stolperte

Letzte Woche passierte etwas, das in meiner Umgebung fast schon alltäglich geworden ist, aber für Außenstehende immer noch überraschend wirkt. Einer meiner KI-Agenten sollte einen bestehenden Kundenkontakt aktualisieren. Er hatte den Namen des Kunden bereits in seinen internen Kontext geladen und bereitete die API-Anfrage vor.

Drei Millisekunden später war die Anfrage blockiert.

Es gab keinen Fehlercode, der auf einen schlechten Schreibstil oder ein fehlendes Token hindeutete. Ein automatischer Wächter, den ich vor Monaten implementiert hatte, hatte erkannt, dass personenbezogene Daten in einem Kontext verarbeitet werden sollten, der dafür nicht freigegeben war. Der Befehl wurde gestoppt, bevor er das Netzwerk verlassen konnte. Ich musste nicht eingreifen. Ich habe nicht einmal bemerkt, dass es passiert ist, bis der Agent mir im Log meldete, dass er die Aktion aufgrund von Compliance-Regel 42.1 abbrechen musste.

Dieser Vorfall ist kein Ausrutscher. Er ist das Ergebnis einer architektonischen Entscheidung, die ich vor über einem Jahr getroffen habe.

Warum 14 Monate Vorsprung im AI Act entscheidend sind

Seit dem 2. August ist der EU AI Act in vollem Umfang durchsetzbar. Die Nachrichtenagenturen berichten über Bußgelder, die bis zu 7 Prozent des globalen Jahresumsatzes betragen können. Viele Unternehmen fangen an diesem Tag erst an, sich mit den Anforderungen auseinanderzusetzen. Sie lesen die Leitfäden der Kommission und versuchen, bestehende Systeme nachträglich zu rüsten.

Ich hatte 14 Monate Vorsprung.

Warum? Weil ich die Regeln des AI Act nicht als externe Vorgabe verstanden habe, sondern als technische Spezifikation für meine Infrastruktur. Als ich meine Agenten-Plattform entwickelt habe, habe ich nicht gefragt: „Wie bekomme ich die KI zum Laufen?“ Ich habe gefragt: „Wie kann ich sicherstellen, dass die KI niemals gegen datenschutzrechtliche Grundsätze verstößt, selbst wenn sie halluciniert oder falsch interpretiert wird?“

Das ist ein grundlegender Mentalitätswechsel. Traditionelle Sicherheit schaut auf den Input und den Output. Bei autonomen Agenten liegt das Risiko in der Kette der Entscheidungen. Ein Agent kann einen harmlosen Befehl erhalten, aber im Prozess der Ausführung unbemerkt auf Daten zugreifen, die er gar nicht darf.

Die Architektur der 182 Regeln

Mein System basiert auf einer Schicht, die ich „Guardrail-Layer“ nenne. Diese Schicht sitzt zwischen dem LLM (dem Gehirn) und den Executoren (den Händen), die tatsächlich Code ausführen oder Datenbanken abfragen.

Jede Aktion, die ein Agent initiiert, muss durch einen Filter laufen. Ich habe 182 automatische Prüfregeln implementiert. Diese decken drei Hauptbereiche ab:

1. Datenschutz: Erkannt und Blockiert werden Muster, die auf PII (Personally Identifiable Information) hindeuten, wenn sie in Logs geschrieben oder an externe APIs gesendet werden.
2. Berechtigungen: Der Agent darf nur auf Ressourcen zugreifen, die explizit in seiner Rolle definiert sind. Ein Agent für Marketing-Reporting darf keine Zugriffe auf die Finanzdatenbank initiieren.
3. Compliance-Logik: Bestimmte Aktionen erfordern eine menschliche Freigabe. Wenn der Agent einen Vertrag widerufen will, wird er angehalten und wartet auf ein Signal von einem menschlichen Supervisor.

96 Prozent dieser Regeln erzwingen sich ohne menschliches Zutun. Das ist ein bewusster Designentscheid. Menschen machen Fehler, besonders unter Zeitdruck. Ein Algorithmus, der eine Regex auf einen String anwendet, macht keine Fehler, wenn die Logik korrekt ist.

Der Preis der Sicherheit: Warum die erste Version scheiterte

Es klingt nach einem sauberen, modularen System. In der Realität war der Weg dorthin chaotisch.

Die erste Version meiner Guardrails war zu simpel. Ich hatte versucht, mit einer generischen Blockliste für sensible Daten zu arbeiten. Das Resultat war eine Katastrophe für die Produktivität.

Ein Beispiel: Meine Agenten sollten E-Mails für den Kundenservice entwerfen. Die neue Regel blockierte jede E-Mail, in der das Wort „Adresse“ vorkam, egal in welchem Kontext. Die Agenten wussten nicht, wie sie um diesen Begriff herumkommen sollten. Sie begannen, kryptische Formulierungen zu verwenden oder gaben einfach auf. Die Kundenzufriedenheit sank, weil die Antworten langsamer wurden.

Ich musste lernen, dass „Sicherheit“ nicht bedeutet, so viel wie möglich zu blockieren. Es bedeutet, das Risiko zu minimieren, ohne die Funktionalität zu zerstören.

Ich habe die Regeln in zwei Kategorien unterteilt:

• Hard Blocks: Dingen, die niemals passieren dürfen (z. B. Löschbefehle ohne Backup-Flag, Zugriff auf Zahlungsdaten durch nicht-finance-Role).
• Soft Blocks: Dingen, die erlaubt sind, aber protokolliert und im Zweifel zur Überprüfung an einen Menschen eskaliert werden.

Diese Unterscheidung hat Monate gedauert, um im Echtbetrieb zu kalibrieren. Ich habe Tausende von Logs analysiert, um zu verstehen, welche Aktionen wirklich riskant waren und welche nur falsch aussahen.

Open Source als Dienst am Mittelstand

Ich habe diese Arbeit nicht für mich allein behalten. Die meisten Mittelständler haben kein Team aus 50 Sicherheitsingenieuren, das 24/7 über AI-Compliance wacht. Sie brauchen etwas, das funktioniert, wenn es installiert ist.

Deshalb habe ich das fertige System als Open-Source-Paket veröffentlicht. Es ist kein Framework, das man erst aufbauen muss. Es ist ein fertiges Modul, das sich in bestehende Agenten-Infrastrukturen integrieren lässt.

Die Installation sieht so aus:

# Clone the repository
git clone https://github.com/frederik-vdh/ai-guardrails.git
cd ai-guardrails

# Install dependencies
pip install -r requirements.txt

# Initialize with your specific context
python init_config.py --mode=production

Das init_config.py Skript fragt nach den spezifischen Datenbanken und API-Endpunkten, die der Agent nutzen darf. Es generiert dann die 182 Regeln basierend auf diesen Konfigurationen.

In fünf Minuten ist das System live.

Einsatz in der Produktion: Zahlen statt Versprechen

Ich rede nicht von Laborexperimenten. Dieses System läuft in 13 Produktions-Apps.

Die Infrastruktur umfasst:

• 85 Container: Verteilt über Kubernetes-Cluster für Skalierung und Redundanz.
• 25 Datenbanken: Von PostgreSQL für transaktionale Daten bis zu Vektor-Datenbanken für semantische Suchen.
• 3 Branchen: Von Logistik bis hin zu Finanzdienstleistungen.

In der Logistik-Branche war die größte Herausforderung die Echtzeit-Verfolgung von Sendungen. Die Agenten mussten auf GPS-Daten und Fahrerdaten zugreifen. Die Guardrails stellten sicher, dass die Fahrerdaten (Name, Personalnummer) nie in die Logs der Sendungsverfolgung geschrieben wurden, obwohl die Agenten sie technisch hätten abrufen können, um Probleme zu lösen.

In der Finanzbranche war die Anforderung strenger. Hier gab es keine „Soft Blocks“ für Transaktionen. Jede Überweisung über ein bestimmtes Limit musste einen menschlichen Klick erfordern. Die Latenz stieg um 400 Millisekunden, was für den Endnutzer kaum spürbar war, aber rechtlich entscheidend war, da die Audit-Trail-Verpflichtungen strikt erfüllt wurden.

Code-Snippet: Wie eine Blockade aussieht

Hier ist ein vereinfachter Ausschnitt aus der Python-Logik, die prüft, ob eine Anfrage PII enthält, bevor sie an ein externes LLM gesendet wird:

import re
from dataclasses import dataclass

@dataclass
class GuardrailResult:
    is_allowed: bool
    reason: str
    action: str

def check_pii_in_prompt(prompt: str) -> GuardrailResult:
    # Example: Simple regex for German ID numbers and emails
    # In production, this uses NER (Named Entity Recognition) models
    pii_patterns = [
        r'\b\d{11}\b',  # Simple ID number pattern
        r'[\w\.-]+@[\w\.-]+\.\w+'  # Email pattern
    ]

    for pattern in pii_patterns:
        if re.search(pattern, prompt):
            return GuardrailResult(
                is_allowed=False,
                reason="PII detected in outbound prompt",
                action="BLOCKED_BY_RULE_104"
            )

    return GuardrailResult(
        is_allowed=True,
        reason="No PII detected",
        action="ALLOWED"
    )

In der echten Implementierung ist diese Funktion natürlich viel komplexer. Sie nutzt lokal laufende NER-Modelle, um Namen, Adressen und Kontonummern zu erkennen, ohne die Daten an Cloud-Dienste zu senden. Das ist ein entscheidender Punkt für die DSGVO-Compliance: Die Daten verlassen das eigene Netzwerk nicht.

Wichtigste Erkenntnisse

Wenn Sie heute mit KI-Agenten arbeiten oder es planen, hier sind die drei Lektionen, die ich mitnehme:

1. Compliance ist Architektur, nicht Dokumentation.
Sie können keine Compliance nachträglich durch Dokumenten-Management nachholen. Sie müssen sie in den Codepfad einbauen. Wenn der Agent technisch in der Lage ist, etwas Falsches zu tun, wird er es unter bestimmten Umständen tun. Machen Sie es technisch unmöglich.

2. Perfektion ist der Feind des Nutzens.
Zu strenge Regeln machen Ihr KI-System unbrauchbar. Sie müssen das Risiko akzeptieren, dass ein Agent manchmal etwas „Graues“ tut, solange die harten Grenzen (Hard Blocks) stabil bleiben. Kalibrieren Sie Ihre Regeln im Live-Betrieb.

3. Transparenz schafft Vertrauen.
Wenn Sie Open Source nutzen oder zumindest die Logik offenlegen, gewinnen Sie das Vertrauen Ihrer Kunden und Ihrer Mitarbeiter. Sie können zeigen, dass die KI nicht im Dunkeln arbeitet, sondern unter Aufsicht steht.

Ich habe in den letzten 14 Monaten gelernt, dass KI nicht magisch ist. Sie ist eine Technologie, die wie jede andere Technologie Risiken birgt. Aber sie ist auch eine Technologie, die, wenn man sie richtig einbettet, Prozesse automatisieren kann, die vorher unmöglich waren oder zu teuer waren.

Der EU AI Act ist keine Strafe für die Nutzung von KI. Er ist eine Anleitung dafür, wie man KI seriös und verantwortungsvoll einsetzt. Wer diese Anleitung liest und sie in seine Architektur übersetzt, hat einen Wettbewerbsvorteil. Nicht nur, weil er keine Bußgelder zahlt, sondern weil sein System robust, zuverlässig und vertrauenswürdig ist.

Ich habe diese Erfahrungen, die technischen Details und die strategischen Überlegungen ausführlich in meinem neuen Buch dokumentiert. Dort finden Sie die vollständigen Code-Beispiele, die Fallstudien aus den drei Branchen und die Roadmap, wie Sie Ihre eigene Infrastruktur Schritt für Schritt härten können.

Das beschreibe ich ausführlich in 'Läuft ohne mich'.

Das Buch: Taschenbuch (24,99 EUR) https://amazon.de/dp/B0HDMT162J | E-Book (9,99 EUR) https://amazon.de/dp/B0HDMS2YQ9

---

Dieser Artikel wurde mit KI erstellt, auf Basis meiner eigenen Systeme und Praxiserfahrung.