Warum Ihre KI-Agenten im Produktivbetrieb ausfallen: Wie Sie Fehler lokal erfassen und für Regression sowie Sicherheit nutzen

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. In meiner Rolle bei DennisCraft AI Studio liefere ich KI-Systeme für DACH-B2B-Kunden aus – produktiv, nicht als Demo. Mein Stack: Claude, Supabase, n8n, Doppler, eigene Postgres. In den letzten sechs Monaten habe ich 14 produktive KI-Agenten bereitgestellt. Trotzdem stoße ich immer wieder auf das gleiche Problem: Ein Testlauf ist grün, aber im Produktivbetrieb bricht der Agent stillschweigend ab – kein Fehler im Code, sondern ein nicht erfasster Fehler im Agenten-Workflow.

Fehlerarten, die Sie ohne lokale Erfassung übersehen

Viele verlassen sich auf Cloud-Logs oder Monitoring-Dienste. Doch die meisten Fehler in KI-Agenten äußern sich nicht in Exceptions oder Abstürzen, sondern in stillen Fehlschlüssen: Falscher Funktionsaufruf, unzulässige Parameter, nicht nachvollziehbares Verhalten. Ohne lokale, strukturierte Fehlererfassung bleiben 70–80 % dieser Fälle unsichtbar. In einem aktuellen Projekt im Bereich industrielle Automatisierung wurde ein fehlerhafter SQL-String erst nach Tagen entdeckt – die Cloud-Logs halfen dabei nicht.

Vergleich: Ad-hoc vs. produktionsreife Fehlererfassung

Architektur: Fehler lokal und auditierbar erfassen

Produktionsreife KI-Agenten benötigen eine eigene Fehlererfassungs-Schicht. Diese sollte folgende Informationen erfassen:

• Agent-ID und Ausführungskontext
• Eingabeprompt und Parameter
• Roh-Ausgabe (inkl. Zwischenstände)
• Fehlermeldungen und Stack-Traces
• Zeitstempel, Audit-Log

Für DACH-Kunden setze ich auf eigene Postgres-Instanzen (oft via Supabase). DSGVO-Konformität: Vor Abspeicherung werden alle personenbezogenen Daten maskiert oder gehasht. Das ist essenziell für Compliance und ISO 27001/NIS2-Best Practices.

Beispiel-Tabellenschema für Fehler

CREATE TABLE agent_failures (
    id SERIAL PRIMARY KEY,
    agent_id TEXT NOT NULL,
    input JSONB NOT NULL,
    output JSONB,
    error_message TEXT,
    stack_trace TEXT,
    intermediate_state JSONB,
    created_at TIMESTAMP DEFAULT now()
);

Dieser Ansatz ist agentenunabhängig – egal ob Claude, GPT-4 oder Eigenentwicklung. Erfassen Sie jede ungewöhnliche Agentenantwort, nicht nur Exceptions.

Technische Umsetzung: Claude, Supabase, n8n

n8n als Orchestrator

In jedem produktiven Workflow implementiere ich nach jedem kritischen Agentenschritt einen "Fehler-Logging"-Node, der Fehler und Kontextdaten in Echtzeit an Supabase/Postgres schreibt.

const { createClient } = require('@supabase/supabase-js');
const supabase = createClient(process.env.SUPABASE_URL, process.env.SUPABASE_KEY);

async function logFailure(agentId, input, output, errorMsg, stackTrace, intermediate) {
    await supabase
        .from('agent_failures')
        .insert([{
            agent_id: agentId,
            input: input,
            output: output,
            error_message: errorMsg,
            stack_trace: stackTrace,
            intermediate_state: intermediate
        }]);
}

PII-Handling: Niemals Rohdaten (z.B. Namen, E-Mails) loggen. Mindestens Hashing oder Redaction. Prüfen Sie regelmäßig mit semgrep oder bandit auf versehentliche Datenleaks.

Fehler für Regression und Sicherheit nutzbar machen

Die lokal gespeicherten Fehler verwende ich als Input für:

• Regressions-Tests: Jeder Release wird gegen 10–20 echte Fehlerfälle getestet
• Sicherheitsanalysen: Suchen nach SQL-Injections, Prompt-Injection, Token-Leaks (z.B. mit semgrep, gitleaks, bandit)
• Monitoring-Dashboards: Fehlertrends (Supabase, Grafana) zeigen, welche Agenten degradieren

Python-Beispiel: Automatisierte Fehlerwiederholung

import requests

def replay_failure(agent_url, failure):
    response = requests.post(agent_url, json=failure['input'])
    assert response.status_code == 200
    # Optional: Erwartete Ausgabe prüfen

# Die letzten 10 Fehler aus Postgres abrufen
failures = get_failures_from_db(limit=10)
for f in failures:
    replay_failure('https://your-agent/api/invoke', f)

In meinen letzten Projekten waren 65 % der kritischen Fehler nur durch Replaying echter Fehlerfälle reproduzierbar – synthetische Tests reichen nicht.

FAQ

Muss ich alle Fehler dauerhaft speichern?

Nein. 3–6 Monate reichen meist, dann archivieren oder anonymisieren. Für regulierte Sektoren (Finanzen, Gesundheit) gelten eigene Vorgaben – prüfen Sie Ihre Compliance.

Wie integriere ich Fehlererfassung in ein bestehendes System?

Implementieren Sie Middleware oder einen separaten Logging-Layer. Die Fehlererfassung sollte getrennt von der Agentenlogik laufen, damit sie wartbar bleibt.

Was unterscheidet diesen Ansatz von Sentry/New Relic?

Standard-Tools erkennen Codefehler, aber keine LLM-spezifischen Agentenfehler oder Prompt-Probleme. Sie brauchen eine Schicht, die Prompt, Eingaben und Agenten-Reasoning protokolliert.

Wie gehe ich mit Fehlalarmen um?

Am Anfang manuell taggen, später (bei Volumen) mit semgrep/bandit semi-automatisieren. Einfache UI für Annotationen hilft bei der Qualitätssicherung.

Wie sichere ich die Fehlerdaten gegen Datenabfluss?

Zugriff stark einschränken, Storage verschlüsseln, regelmäßige Audits (gitleaks). Alerts für verdächtige Einträge oder PII-Leaks einrichten.

An welcher Stelle Ihrer LLM-Pipeline treten die meisten Fehler im Produktivbetrieb auf – statische Analyse, Laufzeitsandbox oder menschliche Kontrolle? Ich biete DACH-Gründern einen kostenlosen 30-min Stack-Audit für KI in regulierten Märkten an. Kontaktieren Sie mich auf LinkedIn oder schreiben Sie an @ger_dennis_ai.