Wichtigste Erkenntnisse
- Die lokale Architektur ist die stärkste Datenschutz-Kontrolle. Wenn Modell, Tool-Server und Daten innerhalb der Infrastruktur des Verantwortlichen mit null Egress liegen, entfällt das Cloud-LLM-Bedrohungsmodell — Schrems II, Auftragsverarbeiter-Listen und Folgenabschätzungen für grenzüberschreitende Übermittlungen sind nicht mehr anwendbar.
- 5 Workflow-Vorlagen decken den Großteil der Produktionsnachfrage ab: Dokumentenannahme und -klassifizierung, E-Mail-Triage mit Antwortentwürfen, Meeting-Zusammenfassung mit Aufgabenextraktion, Compliance-Report-Erzeugung, Rechnungsverarbeitung mit Bestellabgleich. Jede hat eine definierte Datenklassifizierung, Rechtsgrundlage, AI-Act-Stufe und Audit-Log-Form.
- EU-AI-Act-Stufen bestimmen die Pflichten. Die meisten Geschäftsworkflows fallen in Limited-Risk (Transparenz gegenüber dem Nutzer, dass KI beteiligt ist). HR-Screening, Kreditentscheidungen und Anspruchsprüfungen sind High-Risk und erfordern eine vollständige Konformitätsbewertung. Emotionserkennung am Arbeitsplatz und Social Scoring sind verboten.
- DSGVO-Arbeit ändert sich nicht durch lokalen Betrieb. Rechtsgrundlage (Artikel 6), Datenminimierung (Artikel 5), Sicherheit der Verarbeitung (Artikel 32), Audit-Logging und eine DSFA (Artikel 35) für hochwirksame Workflows. Der lokale Stack erleichtert den Nachweis dieser Kontrollen, macht sie aber nicht optional.
- DACH ergänzt zwei Ebenen. Mitbestimmung des Betriebsrats (BetrVG §87) gilt immer, wenn der Agent Mitarbeiterdaten berührt — auch passiv. §203 StGB für Berufsgeheimnisträger (Anwälte, Ärzte, Wirtschaftsprüfer, Steuerberater) macht die rein lokale Architektur nicht zur Präferenz, sondern zur Pflicht.
- Der Referenz-Stack: Ollama oder vLLM mit einem Tool-Calling-Modell (Gemma 4 27B, GLM-5.1 32B, Qwen3 32B für allgemeine Arbeit; Llama 3.2 3B für leichte E-Mail-Triage), Cline oder Goose+MCP als Agent-Runtime, ein unveränderliches Append-only-Audit-Log und manuelle Freigabe für jede Schreib- oder Sendeaktion.
- Drei zu vermeidende Fehlermodi: Bereitstellung ohne DSFA für einen Workflow, der eine benötigt; Vermischung personenbezogener und geschäftlicher Daten in einem Agent-Workspace; Auslassen von Freigabe-Gates bei ausgehenden Aktionen (E-Mail-Versand, Vertragsunterzeichnung, Zahlungsfreigabe).
Quick Facts
- Architektur: Ollama oder vLLM + Tool-Calling-Modell + Agent-Runtime (Cline oder Goose+MCP) + Audit-Log + RAG-Store, alles auf der Infrastruktur des Verantwortlichen.
- Abgedeckte Workflows: Dokumentenannahme, E-Mail-Triage, Meeting-Zusammenfassung, Compliance-Reporting, Rechnungsverarbeitung.
- EU-AI-Act-Verteilung über die 5 Vorlagen: 4 Limited-Risk, 1 High-Risk (bei Einsatz für HR-Screening), 0 verboten.
- DSFA-Schwelle: verpflichtend für High-Risk, auslöser-basiert (Artikel 35-Kriterien) für die anderen. Die meisten Teams sollten eine für jeden Workflow durchführen, der besondere Datenkategorien berührt.
- Hardware-Dimensionierung: Gemma 4 27B und Qwen3 32B passen auf 24 GB VRAM bei Q4_K_M; GLM-5.1 32B und Llama 3.3 70B benötigen 48 GB+ für vollen Kontext.
- Audit-Log-Aufbewahrung: DSGVO-Artikel-30-Verzeichnispflichten setzen die Untergrenze; sektorale Vorgaben (Finanzdienstleistungen, Gesundheitswesen) verlängern sie. 6 Jahre sind die sichere Voreinstellung für die meisten Enterprise-Kontexte.
- Kosten: null bei API-Ausgaben; Hardware amortisiert sich gegen ein Enterprise-SaaS-KI-Abo bei einem Team von 20+ Nutzern innerhalb von 6–12 Monaten.
Was lokale KI-Agenten für Geschäftsteams leisten
Ein lokaler KI-Agent ist ein Tool-Calling-Modell, das innerhalb der Infrastruktur des Verantwortlichen läuft, mit expliziten Freigabe-Gates zwischen Lese- und Schreibaktionen. Es ist kein Chat-Assistent, kein Workflow-Automator (n8n, Zapier) und kein feinjustierter Klassifikator — es ist die Schicht, die ein Modell in etwas verwandelt, das auf Ihren Systemen operiert.
📍 In einem Satz
Ein lokaler KI-Agent ist ein Tool-Calling-Modell plus Tool-Oberfläche plus Freigabe-Gate, das vollständig innerhalb der Infrastruktur des Verantwortlichen läuft — und EU-Compliance von einer Dokumentationsübung in eine architektonische Eigenschaft verwandelt.
💬 In einfachen Worten
Ein Agent ist ein Modell, das Ihr Dateisystem lesen, Ihre Datenbank abfragen, eine E-Mail senden oder Ihre interne API aufrufen kann — wobei ein Mensch jede Schreib- oder Sendeaktion freigibt. Lassen Sie das Modell, die Tools und das Audit-Log auf Ihrer eigenen Hardware laufen, und Sie ersetzen den gesamten Cloud-LLM-Compliance-Stack (Schrems II, Auftragsverarbeiter-Listen, Übermittlungs-Folgenabschätzungen) durch eine einzige architektonische Tatsache: Nichts verlässt Ihr Netzwerk. Was übrig bleibt, sind die DSGVO-Kontrollen für die Daten selbst, die für jedes System gelten, ob Cloud oder lokal.
- Definition: Modell + Tool-Oberfläche (Dateisystem, Datenbank, E-Mail, Kalender, interne API) + Freigabe-Gate pro Schreibvorgang = Agent. Das Modell schlägt vor; die Agent-Runtime führt aus; der Mensch genehmigt alles, was den Zustand verändert oder das Netzwerk verlässt.
- Abgrenzung zu Automatisierungstools. n8n, Zapier und Make.com sind deterministische Workflows — explizite Trigger, explizite Verzweigungen, explizite Aktionen. Ein Agent ist nicht-deterministisch: Das Modell entscheidet, welches Tool mit welchen Argumenten aufgerufen wird, basierend auf Eingabe und Konversationsstand. Verwenden Sie Automatisierung, wenn der Pfad fest ist; verwenden Sie einen Agenten, wenn der Pfad pro Eingabe variiert.
- Abgrenzung zu Chat-Assistenten. Ein Chat-Assistent beantwortet Fragen; ein Agent führt Aktionen aus. ChatGPT-artige "fasse diese E-Mail zusammen" gibt Text zurück; ein Agent liest den Posteingang, klassifiziert Nachrichten, entwirft Antworten und stellt sie zur Freigabe in eine Warteschlange. Andere Oberfläche, anderes Risikoprofil.
- Warum "lokal" speziell für Geschäftsworkflows zählt: Datenresidenz ist nachweisbar (die Bytes verlassen Ihr Netzwerk nie), der Audit-Trail ist Ende-zu-Ende (dasselbe Log erfasst die Modellausführung, den Tool-Aufruf und das Ergebnis), und es gibt keinen Drittauftragsverarbeiter in der Kette. Das Compliance-Argument schreibt sich von selbst, wenn die Architektur ganze Risikokategorien eliminiert.
- Wo lokale Agenten in der Organisation hineinpassen: überall dort, wo ein Workflow personenbezogene Daten (DSGVO), Mitarbeiterdaten (Betriebsrat), vertrauliche Drittdaten (NDAs, §203 StGB) oder regulierte Geschäftsdaten (Finanzwesen, Gesundheit, Recht) verarbeitet. Lokale Agenten verbessern keine Workflows, die nur öffentliche Daten berühren — dort sind Cloud-Agenten meist schneller und billiger.
- Für die Protokollebene, die das praktisch macht, siehe Ollama mit Datenbanken und APIs über MCP verbinden: Lokale Agent-Einrichtung 2026.
5 Workflow-Vorlagen für Geschäftsteams
Diese fünf Vorlagen decken den Großteil der Produktionsnachfrage für lokale Agenten in Geschäftsteams ab. Jede ist beschrieben als Trigger → Tools → Modellempfehlung → Freigabe-Muster → AI-Act-Stufe.
- 1. Dokumentenannahme und -klassifizierung. Trigger: PDF oder Scan landet in einem überwachten Ordner oder einer E-Mail. Tools: Dateisystem (lesen), OCR (bei Bedarf), Klassifizierungsmodell, Datenbank (schreiben). Modell: Gemma 4 27B oder Qwen3 32B für Tool-Calling und strukturierte Ausgabe. Freigabe-Muster: automatisch für Lesen und Klassifizieren, manuell für Routing, wenn das Dokument eine Person erwähnt. AI-Act-Stufe: Limited-Risk. DSFA: auslöser-basiert.
- 2. E-Mail-Triage mit Antwortentwürfen. Trigger: neue Nachricht in einem überwachten Posteingang. Tools: IMAP/Graph API (nur lesen), Klassifizierungsmodell, Entwurfs-Speicher (schreiben), Benachrichtigung. Modell: Llama 3.2 3B reicht für Triage; Gemma 4 27B für Entwurfserstellung. Freigabe-Muster: automatisch für Klassifizierung und Entwurf, manuell für den Versand (immer). AI-Act-Stufe: Limited-Risk. DSFA: auslöser-basiert; verpflichtend, wenn der Posteingang Mitarbeiterdaten verarbeitet.
- 3. Meeting-Zusammenfassung und Aufgabenextraktion. Trigger: Transkript landet im Speicher (Whisper oder Anbieter). Tools: Dateisystem (lesen), Zusammenfassungsmodell, Extraktionsmodell, Ausgabeziel (Notion/Jira/internes Wiki über API). Modell: Qwen3 32B für langen Kontext (128K) bei einstündigen Transkripten. Freigabe-Muster: automatisch für Zusammenfassung, manuell für Aktionspunkte, die in externe Systeme veröffentlicht werden. AI-Act-Stufe: Limited-Risk; Einwilligungserfassung pro Transkript prüfen.
- 4. Compliance-Report-Erzeugung. Trigger: zeitgesteuert (monatlich, vierteljährlich). Tools: Datenbank (lesen), Report-Vorlagen-Speicher, Report-Renderer, Reviewer-Benachrichtigung. Modell: GLM-5.1 32B oder Llama 3.3 70B — langer Kontext, strukturierte Ausgabe, geringe Halluzination. Freigabe-Muster: automatisch für Datenextraktion, manuell für den veröffentlichten Report. AI-Act-Stufe: Limited-Risk; verifizieren Sie, dass die zugrunde liegenden Datenquellen eine dokumentierte Rechtsgrundlage haben. Kombinieren Sie mit strukturierter Ausgabe und JSON-Modus, um die Report-Struktur stabil zu halten.
- 5. Rechnungsverarbeitung und -validierung. Trigger: Rechnung landet im Finanz-Posteingang oder AP-Ordner. Tools: Dateisystem (lesen), OCR, ERP-Integration (Bestellung und Lieferant lesen), Ausnahme-Warteschlange (schreiben). Modell: Gemma 4 27B für Tool-Calling; Qwen3 32B bei Rechnungen mit nicht-standardisierten Layouts. Freigabe-Muster: automatisch für Extraktion und Bestellabgleich, manuell für jede Ausnahme (Abweichung, neuer Lieferant, hoher Betrag). AI-Act-Stufe: Limited-Risk. DSFA: in der Regel nicht ausgelöst.
- Gemeinsames Muster über alle fünf: Die Leseschritte werden automatisch freigegeben; die Schreibschritte, die externe Systeme oder Rechte von Personen betreffen, manuell. Das Audit-Log erfasst jede Entscheidung.
EU-AI-Act-Klassifizierung für Geschäftsagenten
Der EU AI Act klassifiziert KI-Systeme nach dem Risiko für Grundrechte — nicht nach technischer Raffinesse. Dasselbe Modell und derselbe Stack bedienen Limited-Risk- und High-Risk-Workflows; die Pflichten knüpfen an die Nutzung an, nicht an die Technologie.
- Limited-Risk (die meisten Vorlagen): Transparenzpflichten. Der Empfänger einer KI-generierten E-Mail oder Zusammenfassung muss wissen, dass KI beteiligt war. Eine klare Kennzeichnung in der Nachricht und ein einzeiliger Hinweis in der Endnutzer-Dokumentation des Systems erfüllen das in der Regel. Keine Konformitätsbewertung erforderlich.
- High-Risk (spezifische Anwendungsfälle): vollständige Konformitätsbewertung, Eintragung in der EU-Datenbank, Marktbeobachtung und in einigen Unterkategorien eine notifizierte Stelle. Die Muster, die in Geschäftsteams High-Risk treffen, sind HR-Screening (CV-Ranking, Bewerber-Scoring), Kreditentscheidungen, Anspruchsprüfungen und Zugang zu öffentlichen Diensten. Anhang III des Acts ist die maßgebliche Liste.
- Verboten (nicht einsetzen): Echtzeit-biometrische Identifizierung in öffentlichen Räumen (mit engen Ausnahmen für Strafverfolgung), Social Scoring natürlicher Personen, manipulative Techniken, die auf Schwachstellen abzielen, Emotionserkennung am Arbeitsplatz (mit begrenzten medizinischen/Sicherheits-Ausnahmen), prädiktive Polizeiarbeit auf Basis von Profiling.
- Praktische Workflow → Stufen-Zuordnung für die 5 Vorlagen: Dokumentenannahme (Limited-Risk), E-Mail-Triage (Limited-Risk), Meeting-Zusammenfassung (Limited-Risk; Einwilligung prüfen), Compliance-Reports (Limited-Risk), Rechnungsverarbeitung (Limited-Risk). Die fünf Basis-Vorlagen sind alle Limited-Risk; dieselben Vorlagen, umfunktioniert für HR-Screening oder Kreditentscheidungen, erben High-Risk-Pflichten aus der Nutzung.
- Anbieter-vs.-Betreiber-Unterscheidung ist relevant. Wenn Sie das Modell in ein Produkt einbauen, das an andere verkauft wird, sind Sie Anbieter (mehr Pflichten). Wenn Sie das System für eigene Zwecke betreiben, sind Sie Betreiber (weniger Pflichten, aber dennoch real). Interne lokale Agenten machen Sie meist zum Betreiber.
- Aktion für jeden neuen Workflow: klassifizieren Sie ihn vor der Bereitstellungsfreigabe. Die Klassifizierung ist eine einzelne Entscheidung (Limited / High / Verboten) mit schriftlicher Begründung, vom DSB oder Compliance-Lead unterzeichnet, im technischen Dossier des KI-Systems abgelegt.
📌Note: Die High-Risk-Liste in Anhang III des EU AI Acts ist die maßgebliche Referenz — lesen Sie sie bei der Klassifizierung eines Workflows direkt. Verlassen Sie sich nicht auf zusammenfassende Artikel; der Gesetzestext ist kurz und präzise genug, um als Checkliste verwendet zu werden.
DSGVO-Kontrollen für Agent-Workflows
Lokale Architektur entfernt eine Bedrohung (Cloud-LLM-Datenweitergabe), aber keine DSGVO-Pflicht für die Daten selbst. Sechs Kontrollen decken die meisten Agent-Workflows ab; dieselben sechs lassen sich sauber in das technische Dossier abbilden, das der EU AI Act für High-Risk-Systeme erwartet.
- 1. Rechtsgrundlage (Artikel 6). Dokumentieren Sie vor der Bereitstellung, welche Grundlage gilt — Einwilligung, Vertrag, rechtliche Verpflichtung, berechtigtes Interesse, lebenswichtige Interessen oder öffentliche Aufgabe. Die meisten Geschäftsagenten-Workflows laufen auf Vertrag (Mitarbeiter-/Kundenbeziehung) oder berechtigtem Interesse (mit dokumentierter Abwägung). Besondere Datenkategorien (Gesundheit, Biometrie, politische Überzeugung) benötigen zusätzlich eine Bedingung nach Artikel 9.
- 2. Datenminimierung (Artikel 5(1)(c)). Der Agent darf nur die personenbezogenen Daten sehen, die der Workflow benötigt. Praktische Folge: Filtern und chunken auf der RAG-Ebene, nicht im Modell. Vermeiden Sie das Streaming ganzer Dokumente in die Konversation, wenn nur ein Abschnitt relevant ist. Vermeiden Sie die Aufbewahrung von Zwischen-Prompts mit personenbezogenen Daten nach Abschluss der Aufgabe.
- 3. Zweckbindung (Artikel 5(1)(b)). Der Agent darf nicht ohne Neubewertung über Aufgaben hinweg umgewidmet werden. Ein für die Rechnungsverarbeitung freigegebener Workflow kann nicht stillschweigend Aufgaben zur Mitarbeiter-Leistungsbeurteilung übernehmen — das ist ein neuer Zweck, eine neue Rechtsgrundlage, eine neue DSFA-Entscheidung.
- 4. Sicherheit der Verarbeitung (Artikel 32). Verschlüsselung im Ruhezustand, Zugriffskontrolle auf den Workspace, unveränderliches Audit-Log und ein Incident-Response-Plan, der "das Modell hat eine Ausgabe erzeugt, die nicht hätte erzeugt werden dürfen" einschließt. Lokale Architektur deckt hier viel ab; gehen Sie nicht davon aus, dass sie alles abdeckt.
- 5. Audit-Logging. Mindest-Logfelder pro Agent-Aktion: Zeitstempel, Nutzer/Initiator, Modellkennung und -version, Eingabe-Hash, Tool-Aufrufe und Argumente, Ausgabe-Hash, Genehmiger (bei manueller Freigabe). Append-only-Speicherung; Integritätsschutz (Hash-Kette oder signierte Log-Zeilen).
- 6. DSFA (Artikel 35). Verpflichtend, wenn der Workflow systematische Verarbeitung personenbezogener Daten mit erheblicher Auswirkung umfasst, besondere Datenkategorien in großem Umfang oder High-Risk nach AI Act. Auslöser-basiert für alles andere. Die DSFA dokumentiert die Kontrollen, das Restrisiko und die Freigabe des DSB.
- Für die Datenseiten-Architektur, auf der das aufbaut, siehe Lokales RAG für vertrauliche Geschäftsdaten — die RAG-Kontrollen speisen dieselbe Audit-Pipeline.
- Für die Prompt- und Ausgabekontrollen darüber, siehe Prompt-Governance in der Produktion und Prompt-Injection und Sicherheit.
Deutschland-Spezifika: Mitbestimmung des Betriebsrats und §203 StGB
DACH-Workflows haben zwei zusätzliche Ebenen, die englischsprachige Leitfäden routinemäßig übersehen. Beide greifen früh und beide sind entscheidungsblockierend, wenn übersehen.
- Mitbestimmung des Betriebsrats (BetrVG §87(1) Nr. 6). Jedes technische System, das Verhalten oder Leistung von Arbeitnehmern überwacht, löst Mitbestimmung aus. "Überwachen" wird von deutschen Arbeitsgerichten weit ausgelegt — ein Agent, der Mitarbeiter-E-Mails klassifiziert oder Mitarbeiter-Meetings zusammenfasst, zählt dazu. Der Betriebsrat muss zur Designzeit einbezogen werden, nicht nach der Bereitstellung. Das Auslassen dieses Schritts hat Agent-Rollouts nachträglich gekippt.
- Praktische Folge: Bevor Sie einen Workflow bereitstellen, der Mitarbeiterdaten verarbeitet — auch passiv, auch wenn die unmittelbare Ausgabe dem Mitarbeiter selbst zugutekommt — beziehen Sie den Betriebsrat ein. Die Vereinbarung (Betriebsvereinbarung) wird Teil des technischen Dossiers des Systems. Die meisten Betriebsräte sind konstruktiv, wenn sie früh einbezogen werden; fast keiner ist es, wenn er spät einbezogen wird.
- §203 StGB Berufsgeheimnis. Anwälte, Ärzte, Wirtschaftsprüfer, Steuerberater und einige weitere Berufe haben strafrechtliche Haftung für unbefugte Offenbarung von Mandantendaten. Die Ausnahme für "Gehilfen" (§203(3)) deckt internes Personal ab, aber nicht automatisch externe Dienstleister. Ein Cloud-LLM ist ein externer Dienstleister; das ist der rechtliche Kern, warum §203-Kanzleien auf lokale Stacks umgestiegen sind.
- Praktische Folge: Für jeden §203-pflichtigen Beruf ist die rein lokale Architektur keine Präferenz, sondern die Standardvoraussetzung, damit der Workflow überhaupt existieren darf. Der Vertrag mit dem Anbieter des Agenten (falls vorhanden) muss §203-Compliance-Klauseln enthalten; das technische Dossier muss dokumentieren, dass keine Mandantendaten die Infrastruktur der Kanzlei verlassen.
- Österreich und Schweiz: Österreich spiegelt §203 eng (StGB §121); die Schweizer Vertraulichkeit (Art. 321 StGB CH) ist sogar weiter gefasst. Die architektonische Schlussfolgerung ist dieselbe — rein lokal, keine Ausnahmen für sensible Berufsdaten.
- Für das Datenseiten-Compliance-Bild beim selben Verantwortlichen siehe Lokales RAG für vertrauliche Geschäftsdaten — der RAG- und Agent-Stack teilen das Audit-Log und die Zugriffskontrolle.
Auswahl des richtigen Modells für Geschäftsagenten
Tool-Call-Zuverlässigkeit ist eine Modelleigenschaft, keine Harness-Eigenschaft. Dieselbe Harness mit einem kleinen Allzweckmodell scheitert; mit einem auf Tool-Calls trainierten 27B+-Modell gelingt sie. Wählen Sie zuerst das Modell.
- **Gemma 4 27B (
gemma4:27b).** Bester Allzweck-Tool-Caller im Mai 2026. Passt in 16 GB Unified Memory oder 24 GB VRAM bei Q4_K_M. Zuverlässig bei Dokumentenannahme, E-Mail-Triage und Rechnungsverarbeitung. Etwas konservativ bei verketteten Tool-Aufrufen — passt zu Geschäftsworkflows, in denen jeder Schritt ohnehin explizit freigegeben wird. - **GLM-5.1 32B (
glm5:32b).** 128K Kontext out-of-the-box. Starke Tool-Call-Zuverlässigkeit. Die Wahl für Compliance-Reporting und Meeting-Zusammenfassungen mit langer Eingabe. Möchte 24 GB+ VRAM bei Q4_K_M für vollen Kontext. - **Qwen3 32B (
qwen3:32b).** Ausgewogen, sehr zuverlässig bei mehrstufigen Plänen. Guter Fallback, wenn Gemma 4 zu konservativ ist. 32K Kontext out-of-the-box; passt für die meisten Geschäftsaufgaben. - **Llama 3.3 70B (
llama3.3:70b).** Höchste Decke, schwerste Hardware. 48 GB+ VRAM oder 64 GB Unified Memory bei Q4_K_M. Verwenden Sie es für Compliance-Reports und Ausnahmebehandlung, wenn Zuverlässigkeit wichtiger ist als Geschwindigkeit. - **Llama 3.2 3B (
llama3.2:3b).** Leichte Wahl für Hochvolumen-Triage. Läuft komfortabel auf 8 GB VRAM. Gut genug für "Ist das Kundensupport / Vertrieb / Spam"; nicht gut genug für das Verfassen von Antworten. Kombinieren Sie mit einem 27B+-Modell für den Entwurfsschritt. - Mistral Large. EU-gehostete Alternative für hybride Setups, in denen rein lokal überdimensioniert ist, US-Cloud aber nicht infrage kommt. Über Mistrals EU-Endpoint mit AVV einsetzen; Daten bleiben in der EU-Jurisdiktion.
- Für Tool-Calling vermeiden: alles unter 7B für Produktionsarbeit, jedes Allzweckmodell ohne explizites Tool-Call-Training und stärkere Quantisierungen als Q4_K_M am unteren Ende. Symptome sind fehlerhafte Tool-Aufrufe, halluzinierte Argumente und stehengebliebene Agent-Loops.
- Für die Vergleichsdaten siehe Beste lokale Modelle für Tool-Calling 2026. Für VRAM- und Hardware-Dimensionierung über dieselben Modelle siehe Lokaler-LLM-Hardware-Leitfaden 2026.
Agent-Stack-Vergleich für den Geschäftseinsatz
Vier Agent-Runtimes sind 2026 für Geschäftsworkflows glaubwürdig. Sie unterscheiden sich bei Freigabe-Gate-UX, Audit-Trail-Reichtum und Eigenentwicklungsaufwand.
- Wählen Sie Cline + Ollama, wenn das Team entwicklungslastig ist und die Workflows in VS Code passen. Geringste Installations-Reibung, schnellster Weg zu einem funktionierenden Agenten.
- Wählen Sie Goose + MCP, wenn der Workflow auf einem Headless-Server läuft (geplanter Compliance-Report, Ordner-überwachender Ingestor) ohne IDE.
- Wählen Sie n8n + Ollama, wenn der Workflow eine deterministische Form mit ein oder zwei Modellschritten hat. n8ns Human-in-the-Loop-Knoten geben Ihnen Freigabe-Gates ohne eigene Oberfläche.
- Wählen Sie Custom LangGraph nur, wenn die Workflow-Form mit den obigen wirklich nicht kompatibel ist. Der Aufbau-Aufwand ist real; der Audit-Trail- und Freigabe-Gate-Code liegt bei Ihnen.
- Für einen ehrlichen Zuverlässigkeitsvergleich über diese Stacks, siehe Lokale KI-Agenten 2026: Was tatsächlich funktioniert (und was noch scheitert).
| Runtime | Setup | Freigabe-Gates | Audit-Trail | Geeignet für |
|---|---|---|---|---|
| Cline (VS Code) | Eine Extension-Installation | Pro Schritt, in der IDE; Auto-Freigabe-Allowlist | In-Extension-Log; Export für Compliance nötig | Coding-artige Workflows, Single-Developer-Audit |
| Goose + MCP | Brew install + mcp.json | CLI-Prompts; pro Tool konfigurierbar | CLI-Logdatei; in unveränderlichen Speicher rotieren | CLI-Workflows, Headless-Server |
| n8n self-hosted + Ollama | Docker + n8n LLM-Knoten | Workflow-Ebene Human-in-the-Loop-Knoten | Natives n8n-Ausführungslog + Datenbank | Deterministisch geformte Workflows mit ein bis zwei Modellschritten |
| Custom LangGraph + Ollama | Python-Projekt, echte Test-Suite | Selbst gebaut (Interrupts-API) | Selbst gebaut | Produktions-Workflows, die den Engineering-Aufwand rechtfertigen |
Häufige Fehler beim Einsatz lokaler Agenten in EU-Geschäftsworkflows
- Fehler 1: Bereitstellung ohne DSFA. Jeder Workflow, der besondere Datenkategorien berührt oder Entscheidungen über Personen trifft, benötigt eine DSFA. Die DSFA ist kurz — 4–8 Seiten für die meisten Agent-Workflows — aber verpflichtend und genau das, wonach die Aufsichtsbehörde zuerst fragt. Schreiben Sie sie vor der Bereitstellung, nicht danach.
- Fehler 2: Cloud-verbundener Agent für vertrauliche Dokumente. Ein lokales Modell reicht nicht aus, wenn Agent-Runtime, Audit-Log oder Embeddings-Store in fremder Cloud liegen. Die Architektur ist Ende-zu-Ende; eine einzige Cloud-Abhängigkeit in der Kette bricht das Lokal-Argument.
- Fehler 3: Kein Freigabe-Gate für Schreib- oder Sendeaktionen. Der Agent liest, klassifiziert, entwirft, sendet. Der Sendeschritt ist der, den Menschen jedes Mal freigeben müssen, egal wie zuverlässig das Modell bisher war. Auto-Send-Agenten sind, wie die Aufsichtsbehörde von Ihnen erfährt.
- Fehler 4: Vermischung personenbezogener und geschäftlicher Daten in einem Workspace. Das Arbeitsverzeichnis und der Vektor-Store des Agenten sollten pro Workflow gescopt sein, nicht geteilt. Kreuzkontamination verletzt die Zweckbindung; die Bereinigung ist teuer.
- Fehler 5: Audit-Log auslassen. "Wir können es aus dem Konversationsverlauf des Modells rekonstruieren" ist kein Audit-Log. Append-only, hash-verkettet, gemäß einschlägiger Aufbewahrungsfrist gespeichert, abfragbar durch DSAR-Bearbeitung — das ist die Messlatte.
Quellen
- EU AI Act konsolidierter Text (artificialintelligenceact.eu) — offizieller Aggregat der Verordnung; Anhang III ist die maßgebliche High-Risk-Liste.
- DSGVO Volltext (gdpr-info.eu) — Artikel 5, 6, 25, 32, 35 sind die maßgeblichen für Agent-Design.
- NIST AI Risk Management Framework — nicht-EU, nicht bindend, aber die Struktur GOVERN / MAP / MEASURE / MANAGE ist eine nützliche Audit-Vorbereitungs-Checkliste.
- EDSA-Leitlinien 03/2018 zu automatisierter Einzelfallentscheidung — maßgeblich für jeden Workflow, der Entscheidungen über Personen trifft; relevant unter DSGVO Artikel 22 und AI Act.
- BfDI-Positionspapier zu KI-Systemen (BfDI) — DACH-spezifisch, verweist auf §203 StGB und Betriebsrats-Praxis.
FAQ
Sind lokale KI-Agenten standardmäßig DSGVO-konform?
Nein — sie sind durch Architektur DSGVO-kompatibel, aber nicht standardmäßig DSGVO-konform. Die rein lokale Architektur entfernt das Cloud-LLM-Bedrohungsmodell (Schrems II, Auftragsverarbeiter-Listen, grenzüberschreitende Übermittlungen), aber die DSGVO-Kontrollen für die Daten selbst gelten weiterhin: Rechtsgrundlage (Artikel 6), Datenminimierung (Artikel 5), Sicherheit der Verarbeitung (Artikel 32), Audit-Logging und eine DSFA, wo der Workflow es rechtfertigt. Der lokale Stack erleichtert den Nachweis dieser Kontrollen, macht sie aber nicht optional.
Welche Workflows sind unter dem EU AI Act High-Risk?
Anhang III listet die maßgeblichen High-Risk-Anwendungsfälle. Die Muster, die Geschäftsteams am häufigsten treffen, sind HR (CV-Screening, Bewerber-Ranking, Leistungsbeurteilung), Kreditentscheidungen, Anspruchsprüfungen und Zugang zu wesentlichen Diensten. Die meisten allgemeinen Geschäftsworkflows (Dokumentenannahme, E-Mail-Triage, Meeting-Zusammenfassung, Rechnungsverarbeitung, Compliance-Reporting) sind Limited-Risk — nur Transparenzpflichten, keine vollständige Konformitätsbewertung.
Brauche ich eine DSFA für einen E-Mail-Triage-Agenten?
Auslöser-basiert. Eine DSFA ist verpflichtend, wenn der Workflow systematische Verarbeitung personenbezogener Daten mit erheblicher Auswirkung umfasst (Artikel 35(1)) oder eine Pflicht-DSFA-Liste der Aufsichtsbehörde trifft. Ein allgemeiner Posteingang-Triage-Agent löst oft nicht automatisch aus; derselbe Agent in einem HR- oder Bewerber-Posteingang schon. Die meisten Teams sollten eine kurze DSFA für jeden Posteingang mit Mitarbeiterdaten durchführen, unabhängig von strikten Auslöser-Kriterien — die Kosten sind Stunden, der Vorteil ist dokumentierte Freigabe.
Kann ein lokaler Agent Mitarbeiterdaten verarbeiten?
Ja, mit zwei zusätzlichen Schritten in DACH. Erstens: Mitbestimmung des Betriebsrats (BetrVG §87(1) Nr. 6) — Betriebsrat zur Designzeit einbeziehen, eine Betriebsvereinbarung unterzeichnen, die Zweck, Aufbewahrung, Zugriff und Audit-Anforderungen definiert. Zweitens: Rechtsgrundlage nach DSGVO — meist Vertrag oder berechtigtes Interesse mit dokumentierter Abwägung. Das Auslassen des Betriebsrats-Schritts hat Rollouts vor deutschen Arbeitsgerichten nachträglich gekippt.
Welche Modellgröße bewältigt Geschäftsworkflows zuverlässig?
Gemma 4 27B ist die zuverlässige Voreinstellung für Allzweck-Tool-Calling. GLM-5.1 32B ist die Wahl bei langer Eingabe (Compliance-Reporting, einstündige Meeting-Transkripte) — 128K Kontext out-of-the-box. Qwen3 32B ist der ausgewogene Fallback. Llama 3.3 70B hat die höchste Decke, möchte aber 48 GB+ VRAM. Llama 3.2 3B reicht für Hochvolumen-Klassifikation, nicht für Entwürfe. Modelle unter 7B emittieren fehlerhafte Tool-Aufrufe, unabhängig von der umgebenden Agent-Runtime.
Wie auditiere ich, was der Agent getan hat?
Jede Agent-Aktion schreibt einen Logeintrag: Zeitstempel, Nutzer/Initiator, Modellkennung und -version, Eingabe-Hash, Tool-Aufrufe mit Argumenten, Ausgabe-Hash, Genehmiger bei manueller Freigabe. Speicherung ist append-only mit Integritätsschutz (Hash-Kette oder signierte Log-Zeilen). Aufbewahrung folgt DSGVO Artikel 30 als Untergrenze; sektorale Vorgaben (Finanz, Gesundheit) verlängern sie. Das Audit-Log beantwortet DSAR-Anfragen und speist das technische Dossier des AI Acts in einer Form.
Kann ich einen Agenten abteilungsübergreifend teilen?
Architektonisch ja, rechtlich heikel. Jede Abteilung hat ihren eigenen Zweck, ihre eigene Rechtsgrundlage, ihre eigene Aufbewahrung und potenziell ihre eigene Betriebsvereinbarung. Geteilte Agenten verwischen all das und schaffen Kreuzkontaminations-Risiko unter Zweckbindung (Artikel 5(1)(b)). Das saubere Muster: eine Agent-Runtime, separate Workspaces pro Workflow, separate Audit-Logs pro Workflow, einzelne Bereitstellung des zugrunde liegenden Modells. Das Modell ist eine geteilte Ressource; die Workflows sind es nicht.
Was ist mit grenzüberschreitenden Tochtergesellschaften?
Wenn der Verantwortliche die EU-Einheit ist und die Daten in EU-Infrastruktur bleiben, deckt die rein lokale Architektur die meisten grenzüberschreitenden Bedenken standardmäßig ab. Beachten Sie zwei Fälle: eine nicht-EU-Tochter, die den lokalen Agenten auf EU-personenbezogenen Daten betreibt (die Daten müssen in der EU bleiben; der Agent kann remote betrieben werden, solange keine personenbezogenen Daten ausgehen), und ein nicht-EU-Support-Team, das auf die Ausgabe des Agenten zugreift (als Übermittlung behandeln; Rechtsgrundlage unter Kapitel V DSGVO dokumentieren). Mistral Large auf Scaleway ist die übliche hybride Wahl, wenn rein lokal überdimensioniert und US-Cloud nicht infrage kommt.
Wie passen lokale KI-Agenten zum BSI-Grundschutz?
Die einschlägigen Bausteine sind APP.5 (für Anwendungssoftware) und SYS.1.x (für IT-Systeme), ergänzt durch CON.3 (Datensicherungskonzept) und OPS.1.1.5 (Protokollierung). Der lokale Stack erfüllt mehrere Standardanforderungen automatisch (Datenresidenz, keine Drittauftragsverarbeiter, durchgängiger Audit-Trail). Die verbleibende Arbeit konzentriert sich auf Zugriffsmanagement (ORP.4), Härtung des Hosts (SYS.1.1) und Notfallplanung (DER.2.1). Dokumentieren Sie die Bausteinzuordnung im technischen Dossier des Systems; das ist genau das, was BSI-konforme Auditoren erwarten.
Ist der Aufwand für einen mittelständischen Betrieb ohne festen DSB tragbar?
Ja, mit drei Anpassungen. Erstens: nutzen Sie eine externe DSB-Stelle für die DSFA-Prüfung und Freigabe (Tagessätze 1.000–2.000 €; eine DSFA dauert 1–2 Tage). Zweitens: starten Sie mit einer einzigen Workflow-Vorlage (Rechnungsverarbeitung oder Dokumentenannahme — beide Limited-Risk, niedrige DSFA-Schwelle), nicht mit allen fünf gleichzeitig. Drittens: Cline + Ollama + Gemma 4 27B auf einem Workstation-Mac (M5 Max 64 GB) reicht für 5–20 Nutzer; kein Server-Operations-Team erforderlich. Die anfänglichen Kosten liegen unter 5.000 €; das amortisiert sich gegen Enterprise-SaaS-KI-Lizenzen in 6–12 Monaten.