Inbox-KI konfigurieren

Richten Sie Inbox-KI ein, wenn Workspace eingehende Mails und Dokumente im Posteingang analysieren soll. Die Analyse hilft beim Prüfen, Klassifizieren, Zusammenfassen und Formulieren eines Antwortentwurfs. Workspace trifft dadurch keine automatische Fachentscheidung: Die Inbox-KI übernimmt kein Item, sendet keine Mail, weist niemanden zu und ändert keinen Posteingangseintrag ohne Ihre Aktion.

Diese Seite richtet sich an Administratoren und Betreiber. Nutzer lesen die Analyse im Posteingang unter Posteingang.

Ziel der Einrichtung

Nach der Einrichtung kann ein Tenant den AI-Task INBOX_TRIAGE ausführen. Ein erfolgreicher Lauf erzeugt einen Analyse-Snapshot am Inbox-Item mit Zusammenfassung, Klassifikation, erkannten Fakten, Routing-Vorschlag, Antwortentwurf, Warnungen und Historie.

Die Einrichtung soll drei Dinge gleichzeitig sicherstellen:

sensible Inbox-Inhalte bleiben standardmäßig auf einem lokalen Provider,
Cloud- oder BYOK-Provider bleiben möglich, aber nur nach explizitem Opt-in,
fehlerhafte oder unsichere Läufe schlagen kontrolliert fehl und ändern das Inbox-Item nicht automatisch.

Ablauf

Was Sie wissen müssen

Thema	Bedeutung für `INBOX_TRIAGE`
AI-Provider	Beschreibt, welcher Provider und welches Modell verwendet werden. Für den lokalen Pilotbetrieb reicht ein aktiver `ollama`-Provider.
KI-Policy	Ist der bevorzugte Zielzustand. Eine aktive Policy bewertet Routen nach Provider, Prompt-Modus, Budget, Modellprofil und Provider-Status.
AI-Task-Mapping	Ist nur der Legacy-Fallback, wenn keine aktive KI-Policy für den Task existiert.
AI-Pläne	Orchestrieren komplexere mehrstufige AI-Abläufe. Für die Inbox-KI-Triage benötigen Sie keinen AI-Plan.
`ai.pii_sensitive_tasks`	Schützt den Legacy-Fallback. Bei aktiven Policies bleibt zusätzlich der Prompt-Modus maßgeblich: Cloud-Routen für PII dürfen nur `sanitized` oder `metadata_only` verwenden.
Ownership-Profil	Legt fest, wem die AI-Nutzung gehört und wie sie abgerechnet oder quotiert wird. Ohne aktives Ownership-Profil läuft Inbox-KI fail-closed.

Empfohlener Pilotbetrieb mit Ollama

Nutzen Sie für den ersten Kundenpilot den lokalen Ollama-Pfad. Dieser Pfad ist für sensible Inbox-Inhalte der Standard.

Aktivieren Sie das Tenant-Feature ai / inbox.triage.
Legen Sie genau einen aktiven Ollama-Provider für den Tenant an.
Hinterlegen Sie Endpoint und Modell, zum Beispiel llama3.1.
Hinterlegen Sie die verlangte Credential-Referenz. Für den lokalen Ollama-Laufzeitpfad wird der Secret-Wert nicht ausgewertet, die Referenz muss aber gültig sein.
Legen Sie ein aktives Ownership-Profil für INBOX_TRIAGE an.
Legen Sie eine aktive KI-Policy mit einer lokalen Ollama-Route für INBOX_TRIAGE an. Die zentrale Anleitung steht unter KI-Policies konfigurieren.
Belassen Sie INBOX_TRIAGE in ai.pii_sensitive_tasks, damit auch der Legacy-Fallback lokal bleibt.
Starten Sie einen Re-Run an einem harmlosen Inbox-Item und prüfen Sie den Analyse-Snapshot.

Für diesen Betrieb brauchen Sie kein AI-Task-Mapping, wenn eine aktive KI-Policy existiert. Wenn Sie bewusst ohne Policy im Legacy-Fallback arbeiten, verwendet Workspace für PII-sensitive Tasks den ältesten aktiven Ollama-Provider des Tenants. Vermeiden Sie in diesem Legacy-Fall mehrere aktive lokale Provider für denselben Tenant.

Wann Sie eine Cloud-Route brauchen

Sie brauchen eine Cloud-Route für INBOX_TRIAGE, wenn Sie bewusst einen Cloud- oder BYOK-Provider verwenden möchten. Treffen Sie diese Entscheidung vorher mit Datenschutz, Betrieb und dem Tenant. Nutzen Sie dafür den Policy-Routing-Pfad, nicht ein neues Legacy-Task-Mapping.

Gehen Sie dann so vor:

Dokumentieren Sie, dass der Tenant Inbox-Inhalte über einen externen Provider verarbeiten darf.
Konfigurieren Sie den externen AI-Provider.
Legen Sie ein aktives Ownership-Profil für INBOX_TRIAGE an.
Legen Sie eine aktive KI-Policy für INBOX_TRIAGE an.
Legen Sie eine Cloud-Route mit Prompt-Modus sanitized oder metadata_only an. Verwenden Sie für Inbox-Inhalte nicht original.
Führen Sie einen Testlauf mit harmlosen Beispieldaten aus.

Bei nicht-lokalen strukturierten Providerpfaden maskiert Workspace den Modell-Prompt vor dem Provider-Aufruf. Wenn die fachliche Qualität mit maskiertem Prompt nicht ausreicht, bleiben Sie beim lokalen Provider-Pfad.

Was AI-Pläne hier nicht tun

Legen Sie für die Inbox-KI-Triage keinen AI-Plan an. Die Inbox-Triage ist absichtlich enger gebaut als ein freier Agentenablauf:

kein Tool-Calling,
kein Secret-Kontext im Prompt,
kein automatischer Mailversand,
keine automatische Promotion in Vorgang, Lead, Angebot oder Eingangsrechnung,
keine automatische Änderung am kanonischen Inbox-Item.

Diese Einschränkung ist Teil der Sicherheitsgrenze. Sie sorgt dafür, dass auch unerkannte Prompt-Injection-Anweisungen keine Werkzeuge ausführen, keine Secrets lesen und keine operativen Änderungen auslösen können.

Erfolg erkennen

Eine lokale Ollama-Einrichtung ist erfolgreich, wenn diese Punkte erfüllt sind:

Prüfung	Erwartetes Ergebnis
Feature	`ai / inbox.triage` ist für den Tenant aktiv.
Ollama-Freigabe	Für genau diesen Tenant ist `ai.ollama.tenant_provider_enabled=true` gesetzt. Ein globaler Wert reicht nicht aus.
Provider	Ein aktiver `ollama`-Provider existiert und zeigt das gewünschte Modell.
Ollama	Der konfigurierte Endpoint ist vom Workspace-Server erreichbar.
Ownership	Für `INBOX_TRIAGE` existiert ein aktives Ownership-Profil.
Policy	Für `INBOX_TRIAGE` existiert eine aktive Policy mit zulässiger Route.
Sensitiver Task	`INBOX_TRIAGE` bleibt in `ai.pii_sensitive_tasks`.
Testlauf	Ein harmloses Inbox-Item erhält einen Analyse-Snapshot mit Provider `ollama` und dem konfigurierten Modell.
UI	Die aufgeklappte Inbox-Kachel zeigt `Analyse verfügbar` und keine rohen technischen Fehlercodes.
Spam-Test	Eine offensichtliche Werbe- oder Spam-Mail erscheint als `Spam oder irrelevant` mit Vorschlag `Verwerfen`. Workspace führt diesen Vorschlag nicht automatisch aus.

Sicherheitsmodell

Inbox-Inhalte sind untrusted input. Eine Mail kann Anweisungen enthalten, die wie System- oder Betreiberbefehle wirken. Workspace blockiert erkennbare Hochrisikosignale vor dem Provider-Aufruf. Diese Blockade ist hilfreich, aber nicht die einzige Sicherheitsgrenze.

Die tragende Sicherheitsgrenze ist:

Die Inbox-KI bekommt keinen Secret-Kontext.
Die Inbox-KI darf keine Tools ausführen.
Die Inbox-KI versendet keine Nachrichten.
Die Inbox-KI übernimmt keine Items automatisch.
Die Inbox-KI speichert nur einen Analyse-Snapshot.
Nutzer treffen die fachliche Entscheidung im Posteingang.

Bewerten Sie einen Kundenpilot deshalb nicht nach „jede Prompt-Injection wird erkannt“. Bewerten Sie ihn nach „erkannte Hochrisikosignale blockieren vor dem Provider-Aufruf, und unbekannte Anweisungen können keine Werkzeuge, Secrets, Mails, Promotions oder Inbox-Mutationen auslösen“.

Häufige Entscheidungen

Situation	Entscheidung
Ein Kunde startet mit sensiblen Inbox-Inhalten.	Nutzen Sie lokalen Ollama-Betrieb.
Ein aktiver Ollama-Provider ist eingerichtet, aber kein Task-Mapping.	Das ist korrekt, wenn eine aktive KI-Policy oder der lokale Legacy-Fallback greift.
Ein Cloud-Provider soll für Inbox laufen.	Legen Sie eine KI-Policy mit Cloud-Route an und verwenden Sie `sanitized` oder `metadata_only`.
Mehrere Ollama-Provider sind aktiv.	Deaktivieren Sie alle nicht gewünschten lokalen Provider.
Die Analyse meldet `PROVIDER_UNAVAILABLE`.	Prüfen Sie Endpoint, Container-/Host-Erreichbarkeit, aktiven Provider und Modellverfügbarkeit.
Die Analyse liefert schwache Zusammenfassung oder `unknown`.	Prüfen Sie Modellqualität, Prompt-Qualität und Testkorpus; die Pipeline kann trotzdem technisch korrekt laufen.
Offensichtliche Werbung bleibt `unknown`.	Prüfen Sie das Testkorpus, Modell und Prompt-Qualität. Die Sicherheitsgrenze bleibt trotzdem: Nutzer müssen `Verwerfen` selbst ausführen.

Fehlersuche

Wenn keine Analyse entsteht, prüfen Sie zuerst:

Ist das Feature ai / inbox.triage aktiv?
Existiert ein aktives Ownership-Profil für INBOX_TRIAGE?
Existiert genau ein aktiver Ollama-Provider für den lokalen Pilotpfad?
Ist der Ollama-Endpoint vom Workspace-Server erreichbar?
Ist das konfigurierte Modell in Ollama verfügbar?
Existiert eine aktive KI-Policy mit zulässiger Route für INBOX_TRIAGE?
Bleibt INBOX_TRIAGE in ai.pii_sensitive_tasks, wenn lokaler Betrieb erwartet wird?
Gibt es alte fehlgeschlagene Analyse-Snapshots in der Historie, während der neueste Snapshot bereits erfolgreich ist?

Wenn ein Cloud-Provider verwendet wird, obwohl lokaler Betrieb erwartet wurde, prüfen Sie, ob eine Cloud-Route in der aktiven KI-Policy zulässig ist oder im Legacy-Fallback ein Task-Mapping greift.