Richtlinien und Limits

Als Admin oder Inhaber steuerst du unter Einstellungen > Richtlinien > Richtlinien & Limits Ressourcenverbrauch und Datenverarbeitung. Wähle den Bereich für dein Anliegen: Ausgaben, Uploads, Aufbewahrung, Funktionsverfügbarkeit, den Hinweis im Chat, das Teilen von Skills mit der ganzen Organisation oder die Zuständigkeit für eingehende Konversationen.

Ein Ausgabenbudget hinzufügen

1. Wähle unter Budgetregeln die Aktion Regel hinzufügen.
2. Wähle Bereich und Ziel. Nutze eine Rolle für eine Gruppe wie Redakteure, ein Team für gemeinsame Arbeit, ein Projekt für alles, was in einem Projekt ausgegeben wird, eine Person für ein individuelles Limit, einen API-Schlüssel für einzelne Zugangsdaten oder die Organisation für eine gemeinsame Obergrenze. Die Liste der API-Schlüssel enthält jeden aktiven Schlüssel, der in der Organisation gilt, mit dem Namen dessen, dem er gehört: den eigenen Schlüssel eines Mitglieds, einen Schlüssel, den ein Admin für ein Mitglied erstellt hat, und die Schlüssel eines Teams, eines Projekts oder der Organisation selbst. So begrenzt du das Skript oder Coding-Tool einer einzelnen Person oder die Integration eines Teams.
3. Wähle einen täglichen, wöchentlichen oder monatlichen Zeitraum. Setze mindestens ein positives Token-, Kosten- oder Anfragelimit. Kosten gibst du in USD an; ein leeres Feld begrenzt diese Größe durch die Regel nicht.
4. Setze bei Bedarf Warnschwelle (%) zwischen 0 und 100, um vor Erreichen des Limits zu warnen. Die Warnung eines Projektbudgets sehen alle, die im Projekt chatten.
5. Wähle Bestätigen, speichere die ausstehenden Seitenänderungen und prüfe Bereich, Ziel, Zeitraum und Limits der gespeicherten Regel.

Eine monatliche Rollenregel könnte Redakteuren beispielsweise ein persönliches Ausgabenlimit von 50 USD geben, während eine Organisationsregel die gemeinsamen Ausgaben auf 500 USD begrenzt. Das sind Beispielbeträge, keine empfohlenen Standardwerte.

Eine Regel bleibt in der Tabelle, auch wenn ihr API-Schlüssel nicht mehr funktioniert. Ziel nennt weiterhin den Schlüssel und seine Inhaberin oder seinen Inhaber. Der Status lautet Abgelaufen, solange der abgelaufene Schlüssel noch gespeichert ist, Deaktiviert, Widerrufen, wenn diese Organisation den Widerruf protokolliert hat, oder Ehemaliges Mitglied, wenn die Person die Organisation verlassen hat. Nicht verfügbar bedeutet, dass der Schlüssel bekannt ist, aber ohne protokollierten Grund nicht mehr gespeichert ist; das kann nach der Bereinigung abgelaufener Schlüssel passieren. Unbekannter Schlüssel kennzeichnet einen Schlüssel, zu dem diese Organisation keine Angaben hat. Entferne eine solche Regel, oder bearbeite sie und wähle einen aktiven Schlüssel.

Budgets gelten für neue kostenpflichtige Arbeit, einschließlich Chat, Sprachausgabe, Transkriptionen und Diktat, Indexierung und Suche im Wissen, verwalteter Agentenläufe, der llm-Schritte von Automatisierungen, von Mit KI verbessern im Posteingang, der Bilder, die Agenten erstellen, und der Aufrufe der Modell-Endpunkte. Tale prüft jede Chat-Anfrage, bevor sie läuft — eine gesendete Nachricht, eine neu erzeugte oder bearbeitete Antwort, beide Seiten eines Modellvergleichs, eine Nachricht, die auf einen Anhang wartet, und ein Senden über die REST-API — und lehnt sie ab, sobald eine zutreffende Grenze erreicht ist. Die Ablehnung nennt die Grenze und wann sie zurückgesetzt wird. Antworten, die noch geschrieben werden, halten Runde für Runde fest, was sie verbrauchen können, ebenso entstehende Sprachausgabe, der llm-Schritt einer Automatisierung, der Titel eines Chats, Mit KI verbessern, eine Transkription und jede Embedding-Anfrage der Indexierung und Suche im Wissen, damit gleichzeitig gesendete Anfragen eine fast erreichte Grenze nicht gemeinsam überschreiten. Die Bildanfrage eines Agenten wird ebenso geprüft, bevor das Bildmodell aufgerufen wird: Solange ihre Bilder entstehen, hält sie geschätzte Kosten fest, und die Prüfung zählt auch mit, was der eigene Lauf des Agenten noch für sein Modell ausgeben kann. Jedes Bild zählt als eine Anfrage. Die Bildgenerierung braucht Kosten- oder Anfragelimits, weil ihre Nutzung nicht in Text-Tokens gemessen wird. Ein Connector-Aufruf — ein Such- oder Web-Werkzeug des Assistenten, der Connector-Schritt eines Agenten oder einer Automatisierung, eine aus dem Posteingang gesendete E-Mail — wird für sich gezählt und nie auf ein Anfragelimit angerechnet. Ein Zug eines verwalteten Agenten auf einem Anbieter-Abonnement zählt als eine Anfrage ohne Kosten: Anfrage- und Tokenlimits gelten für ihn, Kostenlimits nicht. Ein Tokenlimit zählt Eingabe- und Ausgabetokens, und zur Eingabe gehört auch der Teil eines Prompts, den ein Anbieter aus seinem Cache gelesen oder dort abgelegt hat. Dieser Teil wird anders berechnet als die übrige Eingabe, deshalb kann ein Agent, der einen langen Prompt wiederverwendet, ein Tokenlimit erreichen, während seine Kosten niedrig bleiben. Untersuche Warnungen in der Nutzungsanalyse.

Sprachausgabe reserviert während eines laufenden Versuchs die geschätzten Kosten und eine Anfrage. Der llm-Schritt einer Automatisierung reserviert die geschätzte Eingabe und die erlaubte Ausgabe zum Katalogpreis sowie eine Anfrage. Diese Reservierungen zählen zusammen mit Chats und verwalteten Agenten gegen die jeweils geltenden Limits. Es sind Schätzwerte, keine Garantie für die endgültige Abrechnung des Anbieters.

Scheitert ein bereits reservierter Sprachversuch oder bleibt sein Ergebnis unbekannt, erfasst Tale den gespeicherten Schätzwert und eine Anfrage genau einmal, auch wenn der Fehler vor dem Anbieteraufruf auftrat. Für einen direkten Modellaufruf einer Automatisierung mit unbekanntem Ergebnis bucht Tale ebenfalls den reservierten Schätzwert. Diese vorsichtige Abrechnung bestätigt keine tatsächliche Belastung durch den Anbieter. Ein erneuter Versuch braucht eine neue Reservierung und muss einschließlich des vorherigen Schätzwerts ins Budget passen.

Verstehen, welche Grenzen gelten

Persönliche Limits werden für jede Größe aus der spezifischsten Regel ermittelt, die sie festlegt: zuerst Person, dann Team, Rolle und Standard. Gehört jemand mehreren Teams mit einer Regel an, gilt für die Person die strengste dieser Grenzen. Organisationslimits gelten zusätzlich. Ein Teambudget begrenzt auch die gemeinsame Nutzung der aktuellen Teammitglieder, selbst wenn ein Mitglied eine spezifischere persönliche Regel hat: Die Nutzung eines neuen Mitglieds im laufenden Zeitraum zählt sofort, die eines ausgetretenen Mitglieds nicht mehr. API-Schlüssellimits begrenzen unabhängig die mit diesem Schlüssel authentifizierten Anfragen, deren Nutzung dem Schlüssel angerechnet wird, nicht andere Arbeit in der Oberfläche. Der eigene Schlüssel eines Teams, eines Projekts oder der Organisation ist keine Person: Für ihn gilt keine Personen-, Rollen- oder Standardregel. Die Limits der Organisation und ihre API-Schlüsselregeln gelten, der Schlüssel eines Teams zählt für das Budget seines Teams und wird von ihm begrenzt, und der Schlüssel eines Projekts ebenso für das Budget seines Projekts.

Ein Projektbudget begrenzt alles, was in einem Projekt ausgegeben wird, egal von wem: die Chats des Projekts mit ihren Titeln, den vorgelesenen Antworten, den darin transkribierten Aufnahmen und den Tool-Aufrufen und Suchen des Assistenten; die dafür indexierten Dateien; die Läufe seiner Agenten und die Agenten- und llm-Schritte der Automatisierungen, die darin laufen, mit den Bildern, die sie erstellen; und die Aufrufe mit den eigenen API-Schlüsseln des Projekts. Es gilt zusätzlich zu den Limits dessen, der die Arbeit angestoßen hat, auch für Läufe, die ein Zeitplan gestartet hat, und nie für Arbeit außerhalb des Projekts. Laufende Chatantworten und ihre Titel, Agentenzüge, Sprachversuche, Transkriptionen und Modellaufrufe von Automatisierungen reservieren ihre zugelassene Nutzung auch im Projektbudget, sodass gleichzeitige Anfragen diese Reservierungen berücksichtigen. Lehnt es eine Chatnachricht ab, sagt Tale, dass das Limit des Projekts erreicht ist. Mit einer Warnschwelle sehen alle, die im Projekt chatten, wie viel vom Budget noch übrig ist, sobald die Nutzung die Schwelle überschreitet, in einem Banner, das das Projekt nennt. Eine Automatisierung zählt für das Projekt, in dem sie läuft. Ein Lauf ohne eigenes Projekt, von einer Automatisierung, die in mehreren Projekten installiert ist, zählt für jedes davon und muss in jedes Projektbudget passen, so wie die Nutzung eines Mitglieds für jedes seiner Teams zählt; eine Automatisierung, die in keinem Projekt installiert ist, zählt nur für die Organisation.

Chatantworten, Sprachversuche und Modellaufrufe von Automatisierungen behalten die Projekte, die bei ihrer Zulassung erfasst wurden. Verschiebst du den Chat oder änderst du während der Ausführung die Projektinstallationen einer Automatisierung, bleiben Reservierung und spätere Buchung den ursprünglichen Projekten zugeordnet. Ein Versuch, der ohne Projekt zugelassen wurde, bleibt außerhalb der Projektbudgets.

Verwaltete Agentenläufe zählen für die Person, die sie gestartet hat. Ein Lauf, den du aus einer Aufgabe, einem Kommentar, über die REST-API oder den MCP-Endpoint startest, verbraucht deine persönlichen und Team-Grenzen; ein mit einem API-Schlüssel gestarteter Lauf zählt zusätzlich für diesen Schlüssel. Läufe, die ein Zeitplan, ein Webhook oder ein Ereignis gestartet hat, haben keine Person dahinter: Für sie gelten nur die Organisationslimits und, wenn sie in einem Projekt laufen, die des Projekts, und die Nutzungsanalyse führt sie unter Automatisierungen (Trigger). So wird die Nutzung gezählt erklärt die Regel für jede Art von Arbeit.

Ein Aufruf der Modell-Endpunkte wird wie eine Chat-Anfrage geprüft. Bevor er läuft, ermittelt Tale den ungünstigsten Fall, den geschätzten Prompt plus die höchstmögliche Ausgabe zum Katalogpreis des Modells, und lehnt ihn mit 429 BUDGET_EXCEEDED ab, wenn dieser Fall nicht in das passt, was unter einer Grenze für den Schlüsselinhaber oder den Schlüssel noch übrig ist. Solange der Aufruf läuft, ist dieser Fall gegen diese Grenzen reserviert. Danach werden die vom Modell-Gateway gemessenen Kosten unter der Person und dem Schlüssel verbucht, und jeder Aufruf zählt als eine Anfrage.

Wird eine Anfrage unerwartet abgelehnt, prüfe alle passenden Grenzen und Zeiträume. Ein höheres persönliches Limit hebt keine Organisations-, Team-, Projekt- oder API-Schlüsselgrenze auf.

Mitglieder sehen ihren eigenen Stand unter Einstellungen > Nutzung. Dort steht jede persönliche, Team- und Organisationsgrenze, die für sie gilt, mit aktueller Nutzung und nächstem Zurücksetzen. Die Regeln selbst sehen sie dort nicht.

So werden Regeln kombiniert

Jede Richtlinie auf dieser Seite und unter Inhalte & Modelle liest ihre Regeln auf dieselbe Weise. Der spezifischste Bereich gewinnt: eine Personenregel vor einer Teamregel, eine Teamregel vor einer Rollenregel, eine Rollenregel vor dem Standard. Gehört eine Person mehreren Teams mit einer Regel an, werden die Teamregeln nach ihrer Art kombiniert:

• Eine Grenze, etwa ein Budget oder eine Obergrenze für das Kontextfenster, ergibt den strengsten Wert. Der Beitritt zu einem großzügigen Team hebt niemandes Grenze an.
• Eine Erlaubnisliste, etwa der Modellzugriff, ergibt die Vereinigung der erlaubten Modelle; eine Sperre in einer der Regeln gilt für dieses Modell weiterhin.
• Eine einzelne Auswahl, etwa das Standardmodell, folgt der Reihenfolge der Regeln in der Tabelle: Die erste passende Teamregel gewinnt.

Uploads steuern

Die Uploadrichtlinie legt erlaubte und gesperrte Dateiendungen, erlaubte MIME-Typen, die maximale Dateigröße in MB und das Gesamtvolumen pro Person in GB fest. Wähle die benötigten Typen und teste nach dem Speichern eine erlaubte und eine abgelehnte Datei.

Dateiendung, Inhaltstyp und Größe sind getrennte Prüfungen. Vergleiche bei einem Fehler alle drei mit der Richtlinie. Prüfe den schon belegten Speicher der Person, wenn einzelne Dateien passen, weitere Uploads aber scheitern.

Aufbewahrung und Wiederherstellung festlegen

Wähle im Bereich der Aufbewahrungsrichtlinie Bearbeiten und richte die benötigten Kategorien ein. Die Übersicht zeigt wirksame Werte, deaktivierte Kategorien und die Bereinigung temporärer Dateien. Eine deaktivierte geplante Aufbewahrung verhindert keine ausdrückliche Löschung oder Löschanfrage.

Prüfe vor einer Änderung die Mindest- und Höchstgrenzen des Deployments. Änderungen mit Prüfung oder Wartezeit erscheinen als Vorschläge oder vorgemerkte Änderungen. Lies ihren Wirksamkeitszeitpunkt, statt von einer sofortigen Anwendung auszugehen.

Automatisierungsversionen ist ausgeschaltet, bis du die Kategorie aktivierst. Ist sie an, werden gespeicherte Versionen gelöscht, die älter als der Zeitraum sind. Ausgenommen sind die Live-Version, die Versionen der letzten zehn Live-Schaltungen, jede Version, die ein Lauf verwendet hat, die neuesten zwanzig Versionen, die Versionen, aus denen diese wiederhergestellt wurden oder auf denen sie basieren, und Versionen, die eine Person unter Aufbewahrungssperre gespeichert hat. Eine Versionsnummer wird nie erneut vergeben, und ein Link auf eine entfernte Version sagt, dass es sie nicht mehr gibt.

Die Schonfrist für Löschungen ist das Wiederherstellungsfenster unterstützter vorläufig gelöschter Datensätze. Ein positiver Wert lässt Zeit für die Wiederherstellung im Papierkorb; null erlaubt die sofortige endgültige Bereinigung. Nicht jede Kategorie lässt sich wiederherstellen. Ein Legal Hold schützt betroffene Daten vor Bereinigung.

Für selbst gehostete Deployments beschreibt die Aufbewahrungskonfiguration Betreiberkontrollen und Unterschiede zwischen Kategorien. Leite aus einer deaktivierten Richtlinie oder einem angezeigten Zeitraum allein keine Archivgarantie ab.

Funktionskontrollen prüfen

Funktionskontrollen umfassen bereichsspezifische Kontextlimits und den organisationsweiten Schalter für Sprachausgabe. Ein Kontextlimit bestimmt, wie viel Kontext eine KI-Antwort erreicht. Es ist etwas anderes als ein Ausgabenbudget. Ein Limit unter 200.000 Token gilt auch für Agentenläufe mit Claude Code, und zwar das Limit der Person, die den Lauf gestartet hat: Der Agent fasst seine Konversation zusammen, bevor sie über das Limit hinauswächst. Ein Limit unter 100.000 Token behandelt Claude Code wie 100.000. Ist die Sprachausgabe ausgeschaltet, können Mitglieder sie weder über eigene Standardwerte noch einzelne Konversationen aktivieren.

Der Standardschalter für benutzerdefinierte Anweisungen legt die Organisationsvorgabe für die persönlichen Anweisungen der Mitglieder fest: Solange er aktiv ist, gelten die benutzerdefinierten Anweisungen jedes Mitglieds für seine Chatantworten, es sei denn, das Mitglied hat die Funktion unter Einstellungen > Personalisierung selbst ausgeschaltet. Verbindliche Organisationsanweisungen stehen separat unter Guardrails.

Festlegen, was der Chat erstellen darf

Chat-Tools legt fest, was der Chat-Assistent neben seinen Antworten erstellen darf. Jeder Schalter entfernt sein Tool aus allen Chats deiner Organisation; der Assistent bekommt also nie etwas angeboten, das er nicht nutzen darf:

• Dateien — Textdateien, die der Assistent selbst schreibt, etwa Markdown, CSV, HTML oder Kalendereinträge. Dafür startet nichts.
• Skills — Anleitungen aus der Skill-Bibliothek der jeweiligen Person, die der Assistent liest, wenn eine zur Anfrage passt.
• Code — Code in einer leichten Sandbox, für Word-, Excel-, PowerPoint- und PDF-Dateien, Diagramme und Berechnungen. Jedes Gespräch nutzt jeweils eine leichte Sandbox, und das Limit für leichte Sandboxes deiner Organisation begrenzt, wie viele gleichzeitig laufen.

Alle drei sind eingeschaltet, bis du einen ausschaltest, und eine fehlende Richtliniendatei lässt sie eingeschaltet. Eine Richtliniendatei, die existiert, aber nicht gelesen werden kann, schaltet alle drei aus, bis sie repariert ist; so schaltet eine defekte Datei nichts wieder ein, was du ausgeschaltet hast, und diese Seite zeigt dann, dass die Richtlinie nicht gelesen werden konnte. Ändere die Schalter und speichere dann die offenen Änderungen der Seite in der Kopfzeile; die nächste Antwort in jedem Chat folgt ihnen. Bilder gehören nicht zu diesem Abschnitt: Der Chat erstellt sie nur, solange die Bildgenerierung eingeschaltet ist. Was Mitglieder sehen, zeigt Im Chat Dateien erstellen und Skills nutzen.

Einen Vertraulichkeitshinweis im Chat anzeigen

Vertraulichkeitshinweis blendet für alle Mitglieder deiner Organisation eine kurze Zeile unter dem Nachrichtenfeld im Chat ein, etwa die Erinnerung, keine sensiblen Daten zu teilen. Der Hinweis bleibt aus, bis du ihn einschaltest.

1. Schalte Vertraulichkeitshinweis ein. Mitglieder sehen den Hinweis sofort im Chat, in ihrer Sprache; geöffnete Chats aktualisieren sich ohne Neuladen.
2. Gib bei Bedarf in den Sprach-Tabs English, Deutsch und Français eigene Texte mit jeweils höchstens 280 Zeichen ein. Speichere danach die ausstehenden Seitenänderungen.

Mitglieder sehen den Text in ihrer Sprache. Ein Tab mit der Markierung nicht übersetzt hat keinen eigenen Text: Mitglieder mit dieser Sprache sehen deinen englischen Text oder, wenn auch dieser fehlt, den Standardhinweis, und das leere Feld zeigt diesen Text als Vorschau. Ein roter Punkt markiert eine Sprache mit zu langem Text; Speichern ist erst wieder möglich, wenn du ihn kürzt. Schaltest du den Hinweis aus, bleiben deine Texte für das nächste Einschalten erhalten.

Der Hinweis ist nur eine Erinnerung. Er prüft, blockiert oder verändert keine Nachrichten. Um auf sensible Inhalte zu reagieren, richte Guardrails ein.

Festlegen, wer Skills mit allen teilt

Standardmäßig kann jedes Mitglied einen Skill mit der ganzen Organisation teilen. Mit Skill-Freigabe behältst du das weniger Personen vor: Wähle unter Skills mit der Organisation teilen, wer das darf, und speichere die offenen Änderungen der Seite.

• Alle Mitglieder behält die Voreinstellung bei.
• Redakteure und höher lässt Redakteure, Entwickler, Admins und Inhaber zu, also die Rollen, die Agenten ausstatten.
• Nur Inhaber und Admins lässt nur Inhaber und Admins zu.

Inhaber und Admins dürfen immer mit allen teilen. Soll eine weitere Person das ohne höhere Rolle dürfen, weise ihr unter Kompetenzen Skills für die Organisation veröffentlichen zu.

Alle anderen können weiterhin Skills erstellen und mit ihren eigenen Teams teilen. Sie können keinen Skill für die ganze Organisation anlegen, keinen eigenen auf Organisation erweitern und keinen organisationsweiten Skill direkt ändern. Einen eigenen Skill können sie auf ihre Teams einschränken, auch zusammen mit anderen Änderungen im selben Speichervorgang, oder löschen. Die Regel gilt im Skill-Editor, für Zip- und Ordner-Uploads, für Automatisierungspakete mit Skills und für die REST-API. Jede Ablehnung erscheint in den Audit-Logs als Veröffentlichen eines Skills abgelehnt.

Eine strengere Einstellung schränkt keine Skills ein, die bereits mit der Organisation geteilt sind. Um sie zu prüfen, öffne Einstellungen > Skills, wähle Filter > Sichtbarkeit > Organisation und sieh dir die Spalte Erstellt von an. Schränke die Skills ein, die nicht mehr für alle bestimmt sind, oder lösche sie.

Konversations-Routing

Mit dem Konversations-Routing ordnest du neue Konversationen danach zu, wo sie eingehen. Füge eine Regel hinzu, fülle ihre Felder aus und speichere:

• Eingang über: Beliebiges Postfach, ein bestimmtes Postfach mit seinem Namen oder eine API-App. Eine API-App erscheint, sobald sie eine Konversation synchronisiert hat.
• Gesendet an: die Adresse, an die die Konversation gesendet wurde. Sie ist bei Beliebiges Postfach Pflicht, bei einem bestimmten Postfach optional und entfällt bei einer API-App. Die Adressprüfung ignoriert Groß- und Kleinschreibung.
• Zuweisen an: ein Team, eine Person oder beides.

Eine Regel für support@example.com erfasst auch Post mit Zusatz wie support+rechnung@example.com; eine Regel für die Adresse mit Zusatz hat für diese Adresse Vorrang. Treffen mehrere Regeln zu, gilt die genaueste: zuerst ein Postfach mit genau dieser Adresse, dann ein Postfach mit der Grundadresse, dann eine Adresse in beliebigem Postfach, zuletzt ein Postfach allein.

Bei Teamzuordnung sehen die Teammitglieder die Konversation, bei Personenzuordnung diese Person. Sind beide gesetzt, genügt eine der Zuordnungen für den Zugriff. Nicht zugewiesene Konversationen sortieren Admins und Inhaber ein.

Regeln greifen beim Eintreffen einer neuen Konversation. Sie ändern keine bestehende Zuordnung, wenn eine Antwort hinzugefügt wird. Verweist eine Regel auf eine gelöschte Person, ein gelöschtes Team oder ein entferntes Postfach, kommt die Konversation trotzdem ohne diese Routing-Zuordnung an. Teste mit einer neuen Nachricht und prüfe die entstandene Zuständigkeit.

Anmeldelimits separat einrichten

Aktiviere Passwort-Rotation aktivieren und setze Rotationszeitraum (Tage), damit Mitglieder ihr Passwort nach Ablauf dieses Zeitraums ändern müssen. Dann erscheint die Seite Passwortänderung erforderlich und fordert das Mitglied auf, vor dem Fortfahren ein neues Passwort festzulegen. Passwortanforderungen, Anmeldeversuchslimits, Sitzungs-Inaktivitätslimit und Zwei-Faktor-Richtlinie stehen unter Einstellungen > Richtlinien > Sicherheit. Ein Organisations-Inaktivitätslimit kann die Deployment-Grenze verschärfen. Bei Trusted-Header-Authentifizierung stimme das Sitzungsende mit Proxy oder Identitätsanbieter ab, da diese das Mitglied erneut authentifizieren können.