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.
AI-Task-Mapping	Ordnet einen Task-Key einem Provider zu. Für `INBOX_TRIAGE` greift das Mapping nur, wenn der Task nicht als PII-sensitiv markiert ist.
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`	Enthält sensible Task-Keys. `INBOX_TRIAGE` steht standardmäßig in dieser Liste und nutzt dadurch den lokalen Provider-Pfad.
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.
Belassen Sie INBOX_TRIAGE in ai.pii_sensitive_tasks.
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 mehrere aktive Ollama-Provider existieren, verwendet Workspace den ältesten aktiven Ollama-Provider des Tenants. Vermeiden Sie deshalb mehrere aktive lokale Provider für denselben Tenant.

Wann Sie ein Task-Mapping brauchen

Sie brauchen ein Task-Mapping 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.

Gehen Sie dann so vor:

Dokumentieren Sie, dass der Tenant Inbox-Inhalte über einen externen Provider verarbeiten darf.
Entfernen Sie INBOX_TRIAGE für diesen Tenant oder Scope aus ai.pii_sensitive_tasks.
Konfigurieren Sie den externen AI-Provider.
Legen Sie ein aktives AI-Task-Mapping von INBOX_TRIAGE auf diesen Provider an.
Prüfen Sie, dass ein Ownership-Profil für INBOX_TRIAGE existiert.
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 Fall, 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.
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.
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 für den lokalen `INBOX_TRIAGE`-Pfad korrekt.
Ein Cloud-Provider soll für Inbox laufen.	Entfernen Sie `INBOX_TRIAGE` bewusst aus `ai.pii_sensitive_tasks` und legen Sie ein Task-Mapping an.
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?
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 INBOX_TRIAGE aus ai.pii_sensitive_tasks entfernt wurde oder ein Task-Mapping greift.