KI-Policies konfigurieren

Mit KI-Policies steuern Sie pro Mandant, welche KI-Aufgaben lokal, in der Cloud oder über eine Fallback-Kette laufen. Nutzen Sie diese Seite, wenn Sie Provider, Modellfähigkeiten, Datenschutzgrenzen, Budgets und Routing-Audit für einen AI-Task belastbar einrichten möchten.

Nach der Einrichtung hat der Task eine aktive Policy mit mindestens einer zulässigen Route. Workspace wählt dann deterministisch nach Task-Key, Route, Prompt-Modus, Modellprofil, Budget und Provider-Status. Wenn keine Route zulässig ist, erzeugt Workspace kein KI-Ergebnis.

Entscheidung treffen

Situation	Routing-Profil
Der Task verarbeitet personenbezogene Daten oder freie Nutzertexte.	Nutzen Sie lokal-only oder lokal-first. Eine Cloud-Fallback-Route darf nur `sanitized` oder `metadata_only` verwenden.
Der Task verarbeitet öffentliche Produkt- oder Suchdaten.	Nutzen Sie Cloud-only oder lokal-first nach Kosten, Latenz und Qualität.
Ein lokales Modell ist langsam, aber datenschutzseitig bevorzugt.	Setzen Sie eine lokale Route mit niedriger Priorität und optional eine Cloud-Fallback-Route mit maskiertem Prompt.
Ein Cloud-Provider hat harte Kosten- oder Monatsgrenzen.	Verknüpfen Sie Provider-Preis, Budget und Provider-Status.
Ein konkretes Modell soll nur für bestimmte Ausgaben genutzt werden.	Pflegen Sie ein Modellprofil für Text, JSON, Tool-Calling oder Bild-Metadaten.

Voraussetzungen prüfen

Prüfen Sie diese Punkte, bevor Sie Routen anlegen:

Voraussetzung	Warum sie nötig ist
Task-Key aus dem Task-Katalog	Die Policy hängt am exakten `taskKey`, zum Beispiel `INBOX_TRIAGE` oder `site_search.suggestions`.
Provider-Konfiguration	Die Route verweist auf einen aktiven Provider mit Provider-Typ, Modellname, Endpoint und Secret-Referenz.
Tenant-lokale Ollama-Freigabe	Lokale Ollama-Provider sind nur zulässig, wenn genau der Tenant `ai.ollama.tenant_provider_enabled=true` hat. Ein globaler Wert reicht nicht.
Ownership-Profil	Ausführende AI-Tasks mit Usage-Pflicht laufen fail-closed, wenn kein aktives Ownership-Profil für den Task existiert.
Modellprofil	Sobald für Provider und Modell Profile gepflegt sind, muss ein aktives Profil die Task-Fähigkeiten erfüllen.
Provider-Preis und Budget	Budgets greifen nur, wenn Preis und Budget dieselbe ISO-Währung verwenden.
Berechtigungen	Administratoren benötigen Schreibrechte für Provider, Preise, Budgets, Policies und Routen sowie Leserechte für Routing-Audit.

Task-Keys einordnen

Task-Key	Datenklasse	Empfohlenes Routing
`INBOX_TRIAGE`	Personenbezogene Daten und freie Nachrichtentexte	Lokal-only für Standardbetrieb. Cloud nur bewusst über Policy-Route mit `sanitized` oder `metadata_only`.
`CRM_LEAD_ASSIST`	Personenbezogene Daten, freie Texte und öffentliche Signale	Lokal-first oder Cloud mit `sanitized`/`metadata_only`, je nach Datenschutzfreigabe und Qualitätsbedarf.
`LEADS_PARSING`	Personenbezogene Daten und freie Texte	Lokal-only oder Cloud nur maskiert.
`site_search.suggestions`	Öffentliche Such- und Produktdaten	Cloud-only oder lokal-first; Budget und Modellprofil für strukturierte JSON-Ausgaben pflegen.
`pim.content.generate` und `pim.content.repair`	Produktdaten und freie Redaktionstexte	Cloud oder lokal möglich; Review bleibt Pflicht.
`pim.media.alt_text_propose`	Produktbild-Metadaten	Modellprofil muss Bild-Metadaten und JSON unterstützen.
`pim.product_structure.propose`	Produktstruktur-Daten	Cloud oder lokal möglich; JSON-Fähigkeit prüfen.
`SYSTEM_SETUP`	Systemoperation	Nur mit bewusst freigegebenem Provider und Review nutzen.

Routing-Profil: lokal-only

Nutzen Sie lokal-only für sensible Aufgaben und Pilotinstallationen, bei denen Prompts den Mandantenkontext nicht verlassen sollen.

Öffnen Sie Agents > KI-Provider und legen Sie einen aktiven ollama-Provider an.
Hinterlegen Sie Endpoint und Modell, zum Beispiel http://localhost:11434 und llama3.1.
Hinterlegen Sie eine gültige Secret-Referenz. Der lokale Ollama-Pfad wertet den Secret-Wert nicht aus, die Referenz muss aber gültig sein.
Setzen Sie für genau diesen Tenant ai.ollama.tenant_provider_enabled=true.
Legen Sie ein aktives Ownership-Profil für den Task-Key an. Für lokale, inkludierte Nutzung verwenden Sie den Ownership-Modus local_included.
Öffnen Sie Agents > KI-Modellprofile und legen Sie ein aktives Profil für Provider und Modell an. Aktivieren Sie mindestens Text und bei strukturierten Tasks JSON.
Öffnen Sie Agents > KI-Policies und legen Sie eine aktive Policy für den Task-Key an.
Öffnen Sie Agents > KI-Policy-Routen und legen Sie eine aktive Route mit Priorität 10, dem Ollama-Provider und dem passenden Prompt-Modus an.

Für lokale PII-Tasks ist original zulässig. Verwenden Sie trotzdem sanitized, wenn die fachliche Qualität genügt.

Routing-Profil: Cloud-only

Nutzen Sie Cloud-only für nicht-sensitive Aufgaben oder für Tenants, die eine explizite Cloud-Freigabe für den betroffenen Task haben.

Legen Sie einen aktiven Cloud-Provider an, zum Beispiel openai oder google.
Hinterlegen Sie Secret-Referenz und Modellname.
Legen Sie ein Modellprofil an. Strukturierte Tasks brauchen Text und JSON; Bild-Metadaten-Tasks brauchen zusätzlich Bildmetadaten.
Legen Sie ein Ownership-Profil an. Verwenden Sie platform_managed für abrechenbare Plattformnutzung oder bring_your_own_key, wenn der Tenant eigene Provider-Credentials verantwortet.
Legen Sie bei Kostensteuerung einen Provider-Preis und ein Budget mit derselben Währung an.
Legen Sie Policy und Route an. Verwenden Sie für PII-Tasks nie original, sondern sanitized oder metadata_only.

Wenn eine Cloud-Route für PII mit original konfiguriert wird, blockiert Workspace die Route. Der Routing-Audit zeigt dann einen stabilen Failure-Code statt Prompt-Inhalt.

Routing-Profil: lokal-first mit Cloud-Fallback

Nutzen Sie lokal-first, wenn lokale Verarbeitung bevorzugt ist, aber ein maskierter Cloud-Fallback fachlich erlaubt und betrieblich sinnvoll ist.

Legen Sie lokalen und Cloud-Provider an.
Legen Sie Modellprofile für beide Provider-/Modellkombinationen an.
Legen Sie ein Ownership-Profil für den Task an.
Legen Sie Cloud-Preis und Cloud-Budget an, wenn der Fallback Kosten erzeugt.
Legen Sie eine aktive Task-Policy an.
Legen Sie Route 10 auf den lokalen Provider.
Legen Sie Route 20 auf den Cloud-Provider.
Setzen Sie den Cloud-Prompt-Modus bei PII-Tasks auf sanitized oder metadata_only.
Starten Sie einen Testlauf mit harmlosen Daten und prüfen Sie Decision und Attempts.

Workspace probiert Routen nach Priorität. Providerfehler, ungültige strukturierte Ausgaben und Budget-Ablehnungen stoppen nicht die gesamte Aufgabe, solange eine weitere zulässige Route existiert.

Budgets und Währungen pflegen

Budgets verwenden ISO-4217-Währungen wie USD, EUR oder CHF und Decimal-Beträge. Workspace rechnet Währungen nicht automatisch um.

Ein Budget greift nur, wenn der hinterlegte Provider-Preis dieselbe Währung hat. Fehlt ein passender Preis oder überschreitet der nächste Aufruf das Budget, überspringt Workspace diese Route und prüft die nächste Route.

Workspace reserviert Budget vor dem Provider-Aufruf. Bei erfolgreichem Lauf wird die Reservierung verbraucht; bei Provider-, Ausgabe- oder Validierungsfehlern wird sie freigegeben und die nächste zulässige Route kann verwendet werden.

Externes Guthaben sperren

Wenn ein Provider meldet, dass Guthaben oder Monatskontingent erschöpft ist, öffnen Sie Agents > KI-Provider-Status, setzen den Status auf credit_exhausted und tragen renewal_at oder blocked_until ein.

Workspace fragt diese Route bis zu diesem Zeitpunkt nicht erneut an. Danach kann die Route wieder bewertet werden oder Sie setzen den Status manuell auf healthy.

Routing nachvollziehen

Öffnen Sie Agents > KI-Routing-Entscheidungen, um zu sehen, welche Policy, Route, Provider-Konfiguration und welches Modellprofil Workspace für einen KI-Lauf ausgewählt hat.

Öffnen Sie Agents > KI-Routing-Versuche, um die einzelnen Fallback-Schritte einer Entscheidung zu prüfen. Workspace zeigt Status, Failure-Stage, Failure-Code, Prompt-Modus, Budgetbezug und geschätzte Kosten.

Diese Auditdaten enthalten keine Prompts, Prompt-Auszüge, Secret-Referenzen oder rohen Providerfehler.

Erfolg erkennen

Die Einrichtung ist erfolgreich, wenn diese Prüfungen erfüllt sind:

Prüfung	Erwartetes Ergebnis
Task-Katalog	Der gewünschte `taskKey` ist vorhanden und die Datenklassen passen zur geplanten Route.
Provider	Jede Route verweist auf einen aktiven Provider mit erreichbarem Endpoint oder gültiger Cloud-Konfiguration.
Lokale Freigabe	Ollama-Routen funktionieren nur mit tenant-lokaler Freigabe.
Ownership	Für Tasks mit Usage-Pflicht existiert ein aktives Ownership-Profil.
Modellprofil	Das aktive Profil unterstützt Text und bei Bedarf JSON, Tool-Calling oder Bild-Metadaten.
Prompt-Modus	Cloud-Routen für personenbezogene Daten verwenden nicht `original`.
Budget	Budget und Provider-Preis verwenden dieselbe Währung.
Fallback	Eine gesperrte, budgetseitig abgelehnte oder fehlerhafte Route erzeugt einen Attempt und die nächste zulässige Route wird geprüft.
Audit	Die Routing-Entscheidung zeigt eine ausgewählte Route oder einen stabilen Failure-Code ohne Prompt-Inhalt.

Fehlersuche

Symptom	Prüfen
Keine Route wird ausgewählt.	Policy aktiv? Route aktiv? Provider aktiv? Modellprofil passend? Cloud-PII nicht versehentlich `original`?
Lokaler Ollama-Provider wird ignoriert.	Tenant-lokale Freigabe `ai.ollama.tenant_provider_enabled=true`, Provider-Typ `ollama`, Endpoint erreichbar, Modell verfügbar.
Cloud-Fallback läuft nicht.	Prompt-Modus, Budget, Provider-Preis, Provider-Status und Modellprofil prüfen.
Budget-Route wird übersprungen.	Währung, Unit-Cost, Budgetlimit und vorhandene Reservierungen prüfen.
`PROVIDER_UNAVAILABLE` oder `PROVIDER_TIMEOUT`.	Endpoint, Secret-Referenz, Modellname, Netzwerk und Provider-Status prüfen.
`INVALID_OUTPUT`.	Modellprofil, JSON-Fähigkeit, Prompt-Qualität und strukturiertes Ausgabeformat prüfen.
Audit zeigt keine Prompts.	Das ist korrekt. Routing-Audit speichert bewusst nur promptfreie Fakten.