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.

Administratoren und Betreiber richten die Analyse hier ein. Wie Nutzer das Ergebnis im Posteingang prüfen, beschreibt Posteingang bearbeiten.

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.

Klassifikation und Pflegegrenzen

Die Inbox-KI erzeugt nicht nur freien Text. Der Provider muss eine strukturierte Antwort liefern, deren Klassifikation genau einen dieser Werte enthält:

Technischer Wert	Anzeige	Fachliche Grenze
`sales_new_business`	`Vertriebsanfrage`	Neue Angebotsanfragen und Kundenbestellungen.
`customer_support`	`Kundenservice`	Anliegen zu bestehenden Produkten, Aufträgen oder Services.
`billing_finance`	`Abrechnung und Finanzen`	Abrechnungs- und Zahlungsthemen; eine erkennbare Lieferantenrechnung gehört nicht hierher.
`procurement_supplier`	`Beschaffung oder Lieferant`	Lieferantenbezogene Eingänge und erkennbare Eingangsrechnungen.
`general_administration`	`Administration`	Organisatorische Eingänge ohne passendere Fachkategorie.
`spam_or_irrelevant`	`Spam oder irrelevant`	Werbung, Spam oder fachlich nicht verwertbare Inhalte.
`unknown`	`Unbekannt`	Keine belastbare oder widerspruchsfreie Einordnung.

Diese Taxonomie und ihre sichtbaren Bezeichnungen sind Teil des Produkts. Administratoren können weder zusätzliche Kategorien anlegen noch die fachlichen Grenzen je Mandant umdefinieren. Workspace prüft die Providerantwort, normalisiert unbekannte Werte und wendet anschließend feste Regeln für eindeutige Spam-, Lieferantenrechnungs- und Kundenbestellungssignale an. Harte Routing-Vorschläge benötigen außerdem einen ausreichenden Sicherheitswert und direkte Evidenz. Andernfalls fordert Workspace eine Review an.

Bestandteil	Wo er gepflegt wird
Klassifikationen, Normalisierung und Sicherheitsgrenzen	Produktseitig; nicht je Mandant konfigurierbar.
Provider, Modell und Endpoint	Agents > KI-Provider.
Modellfähigkeiten	Agents > KI-Modellprofile.
Route, Priorität, Prompt-Modus und `failClosed`	Agents > KI-Policies und Agents > KI-Policy-Routen.
Budget, Preise und Provider-Status	In den zugehörigen Bereichen unter Agents.
Ownership-Modus und Quota-Bezug	Durch einen freigegebenen Bereitstellungsprozess des Instanzbetreibers; dafür gibt es derzeit keinen Administrationsdialog.
Fachliche Entscheidung für einen einzelnen Eingang	Durch den Benutzer im Posteingang.

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.

Lassen Sie einen Systemadministrator das Mandanten-Feature ai / inbox.triage über die unterstützte Feature-Zuweisung aktivieren. Ein Beispiel mit nucli finden Sie unter Tenant-Feature zuweisen.
Legen Sie genau einen aktiven Ollama-Provider für den Mandanten 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.
Lassen Sie den Instanzbetreiber ein aktives Ownership-Profil für INBOX_TRIAGE bereitstellen. Für lokale, inkludierte Nutzung ist der Modus local_included vorgesehen.
Legen Sie eine aktive KI-Policy mit einer lokalen Ollama-Route für INBOX_TRIAGE an. Die zentrale Anleitung steht unter KI-Policies konfigurieren.
Aktivieren Sie in der Policy failClosed. Eine aktive Policy ohne zulässige Route darf nicht auf die Legacy-Auflösung ausweichen.
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.
Lassen Sie den Instanzbetreiber ein aktives Ownership-Profil für INBOX_TRIAGE bereitstellen.
Legen Sie eine aktive KI-Policy für INBOX_TRIAGE an.
Aktivieren Sie in der Policy failClosed.
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 über die System-Admin-Zuweisung für den Mandanten 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 `failClosed` und mindestens einer zulässigen 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.

Prüfen Sie die Klassifikation zusätzlich mit einem kleinen, harmlosen Testkorpus. Verwenden Sie mindestens je einen eindeutigen Fall für Kundenanfrage, Support, Abrechnung, Lieferantenrechnung, allgemeine Verwaltung, Spam und einen absichtlich unklaren Eingang. Kontrollieren Sie bei jedem Fall Klassifikation, Sicherheit, Evidenz, Warnungen und Routing-Vorschlag. Ein technisch erfolgreicher Lauf ist noch kein Nachweis für ausreichende fachliche Qualität.

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 meldet `PROVIDER_NOT_FOUND`.	Prüfen Sie die aktive KI-Policy und deren Provider-Konfiguration.
Die Analyse meldet `PROVIDER_TIMEOUT`.	Der Provider ist vorhanden, hat den Lauf aber nicht rechtzeitig abgeschlossen. Prüfen Sie Host, Modell und Timeout.
Die Analyse meldet `INPUT_TOO_LARGE`.	Die Nachricht passt nicht in das lokale Kontextbudget. Kürzen Sie den fachlichen Eingang oder prüfen Sie das Modellprofil.
Die Analyse meldet `MODEL_OUTPUT_INVALID`.	Das Modell hat keine vollständige Antwort geliefert oder den strukturierten Ausgabevertrag nicht erfüllt.
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.