# Constraints schreiben: was dein KI-Assistent nicht tun soll

> Constraints sind der meistübersprungene Baustein jedes KI-Assistenten. So formulierst du Verbote, Eskalationsregeln und Tonalitätsgrenzen, die halten.

- Autor: Benedikt Backhaus (https://benediktbackhaus.com/ueber-mich/)
- Veröffentlicht: 2026-08-06
- URL: https://benediktbackhaus.com/blog/constraints-schreiben-ki-assistent/
- Themen: Prompting, Sicherheit, Praxis

Constraints sind die Regeln, die deinem KI-Assistenten sagen, was er nicht tun darf, wo er nachfragen muss und wann er die Aufgabe an einen Menschen zurückgibt. Sie sind der dritte Baustein neben Aufgabe und Wissensdaten. Der kürzeste von allen. Und der, den am häufigsten jemand einfach weglässt. Genau deshalb produzieren so viele Assistenten Antworten, die auf den ersten Blick gut aussehen und beim zweiten Hinsehen nicht haltbar sind.

Ich habe in einem Workshop erlebt, wie Teilnehmende unaufgefordert sieben Assistenten spezifiziert haben, alle nach dem Schema Aufgabe, Wissensdaten, Constraints. Die dritte Spalte war bei allen die kürzeste. Bei zweien stand nur ein Stichwort drin.

## Warum dieser Baustein existieren muss

Sprachmodelle raten lieber, als zuzugeben, dass sie etwas nicht wissen. Das ist kein Charakterfehler, sondern eine Folge davon, wie sie bewertet werden.

Adam Tauman Kalai, Ofir Nachum, Santosh Vempala und Edwin Zhang haben das im September 2025 in der OpenAI-Arbeit „Why Language Models Hallucinate" ausbuchstabiert. Ihr Kernargument: Die üblichen Benchmarks bestrafen Unsicherheit. Ein „Ich weiß es nicht" bringt null Punkte, ein Ratetreffer bringt volle Punkte. Modelle, die raten, schneiden in dieser Bewertungslogik systematisch besser ab als Modelle, die abwinken. Die Autoren vergleichen es mit Prüflingen, die bei einer schweren Frage lieber etwas hinschreiben, als das Feld leer zu lassen.

Wie groß der Effekt in einem Fachgebiet werden kann, hat Stanfords RegLab 2024 in der Untersuchung „Large Legal Fictions" gemessen: Bei über 800.000 überprüfbaren juristischen Fragen lagen die Halluzinationsraten der getesteten Allzweckmodelle je nach Modell zwischen 58 und 88 Prozent. Die Modelle konnten ihre eigenen Fehler zudem schlecht vorhersagen und übernahmen falsche juristische Annahmen der Fragenden häufig unkritisch.

Deine Constraints sind die Stelle, an der du diese Neigung gegensteuerst. Ohne sie überlässt du dem Modell die Entscheidung, wann Raten in Ordnung ist.

## Was passiert, wenn Constraints fehlen

Ein öffentlich dokumentierter Fall, kein Beispiel aus meiner eigenen Arbeit: Deloitte Australia lieferte 2025 einen Bericht an das australische Department of Employment and Workplace Relations, Auftragswert rund 440.000 australische Dollar. Der Bericht enthielt erfundene Quellenangaben, nicht existierende Fachliteratur und ein Zitat, das einem Bundesrichter zugeschrieben wurde und so nie gefallen war. Deloitte erstattete im Oktober 2025 einen Teil des Honorars, und die überarbeitete Fassung legt den Einsatz eines generativen KI-Systems offen.

Was in diesem Fall gefehlt hat, war keine bessere Aufgabenbeschreibung. Es hat eine Regel gefehlt, die lautet: Quellen werden nur genannt, wenn sie in den bereitgestellten Unterlagen stehen.

Im kleineren Maßstab sieht dasselbe Muster so aus: Der Assistent nennt einen Preis, den es nicht gibt. Er verspricht eine Lieferzeit, die niemand zugesagt hat. Er duzt einen Kunden, der seit acht Jahren gesiezt wird. Jeder dieser Fälle kostet dich Vertrauen, und keiner davon wäre mit einer besseren Aufgabenbeschreibung verhindert worden.

## Die vier Sorten Constraints

### 1. Harte Verbote

Kurze Sätze, konkrete Dinge, keine Interpretationsspielräume.

„Nenne niemals Preise, die nicht in der Preisliste stehen." „Sag keine Liefertermine zu." „Erfinde keine Quellenangaben, Studien oder Zitate." „Nenne keine Namen anderer Kunden."

Wichtig ist die Konkretheit. „Sei vorsichtig mit Zusagen" ist kein Constraint, sondern eine Stimmung. „Nenne keine Termine" lässt sich prüfen.

### 2. Eskalationsregeln

Das sind die wertvollsten, und sie fehlen am häufigsten.

„Wenn du unsicher bist, sag das ausdrücklich und schlage vor, dass sich jemand aus dem Team meldet." „Wenn die Antwort nicht in den bereitgestellten Dokumenten steht, sag, dass du es nicht weißt." „Bei Beschwerden antwortest du nicht selbst. Du fasst den Fall in drei Sätzen zusammen und markierst ihn zur Weitergabe."

Der Punkt bei Eskalationsregeln: Du musst dem Assistenten einen erlaubten Ausweg geben. Ein Verbot ohne Alternative erzeugt Umgehungen. Wenn er nicht raten darf und keine andere Handlung kennt, wird er trotzdem etwas produzieren, weil er darauf trainiert ist, zu antworten.

Deswegen formuliere ich Eskalation immer als Paar: Was nicht geht, und was stattdessen passiert.

### 3. Tonalitätsgrenzen

Tonalität lässt sich schwer positiv beschreiben und leicht negativ eingrenzen.

„Keine Ausrufezeichen." „Keine Superlative wie einzigartig, führend oder unschlagbar." „Kein Duzen im Erstkontakt." „Keine Emojis in Kundenmails." „Keine Entschuldigungsfloskeln am Anfang."

Vier bis sechs solcher Zeilen bringen dich weiter als eine halbe Seite über die gewünschte Markenpersönlichkeit. Wenn du eine positive Beschreibung brauchst, nimm zwei Beispieltexte in die [Wissensbasis](/blog/wissensbasis-dokumente-auswaehlen/) statt Adjektive in die Anweisungen.

### 4. Zuständigkeitsgrenzen

Der Assistent soll wissen, was nicht sein Job ist. „Du beantwortest keine arbeitsrechtlichen Fragen." „Du gibst keine steuerliche Einschätzung." „Du bewertest keine Bewerbungen."

Diese Grenzen wirken selbstverständlich, bis jemand die Frage trotzdem stellt. Und irgendwer stellt sie immer.

Der Nebeneffekt ist unterschätzt: Ein Assistent mit klarem Zuständigkeitsrahmen wird häufiger benutzt. Wenn Leute wissen, wofür ein Werkzeug zuständig ist und wofür nicht, greifen sie beherzter zu. Unklare Zuständigkeit erzeugt Zögern, und Zögern erzeugt die Test-Skill, die niemand im Alltag anfasst. Genau darum geht es beim [Sprung von der Test-Skill zur Alltags-Skill](/blog/test-skill-zu-alltags-skill/).

## Ein Constraint-Block zum Abschreiben

Der folgende Block ist konstruiert, für einen fiktiven Assistenten, der Erstanfragen über ein Kontaktformular beantwortet. Er ist bewusst kurz gehalten, damit du siehst, wie wenig es braucht.

> **Grenzen**
>
> Preise nennst du ausschließlich aus der Datei `preisliste-2026-07`. Steht ein Fall dort nicht drin, sagst du das und bietest ein Gespräch an.
>
> Termine, Fristen und Lieferzeiten sagst du nicht zu. Du schreibst stattdessen, dass ein Mensch das bestätigt.
>
> Quellen, Studien und Zitate verwendest du nur, wenn sie in den bereitgestellten Dokumenten stehen.
>
> Du siezt grundsätzlich. Keine Ausrufezeichen, keine Emojis, keine Superlative.
>
> Bei Beschwerden, Kündigungen oder rechtlichen Fragen antwortest du inhaltlich nicht. Du fasst die Anfrage in drei Sätzen zusammen und markierst sie mit `WEITERLEITEN`.
>
> Wenn du unsicher bist, schreib das ausdrücklich in die Antwort. Ein „Das kann ich nicht sicher beantworten" ist ein gutes Ergebnis, keine Schwäche.

Das sind sechs Zeilen Substanz. Sie decken die Fehler ab, die in einem kleinen Betrieb tatsächlich passieren, und sie sind alle überprüfbar.

Falls dein Tool nur ein einziges großes Anweisungsfeld hat, setz solche Grenzen unter eine eigene Überschrift ans Ende. Welche Werkzeuge Aufgabe, Wissen und Grenzen sauber getrennt anbieten und welche alles in ein Feld werfen, vergleiche ich im [Tool-Vergleich für Assistenten](/blog/customgpt-claude-project-gem-vergleich/).

## Wie viele Constraints sind richtig?

Meine Arbeitsregel: mit drei bis fünf starten, auf zehn bis fünfzehn wachsen lassen, dann aufräumen.

Starte mit den drei Fehlern, die dir am meisten wehtun würden. Bei einem Assistenten für Kundenanfragen wären das üblicherweise: falsche Preise, Zusagen zu Terminen, falsche Ansprache.

Lass den Rest aus echten Vorfällen entstehen. Jedes Mal, wenn der Assistent etwas tut, das dich zusammenzucken lässt, schreibst du eine Zeile dazu. Nach zwei Monaten hast du zwölf Zeilen, und jede einzelne hat einen realen Anlass.

Danach kommt der Schritt, den niemand macht: aufräumen. Regeln, die dieselbe Sache aus zwei Richtungen verbieten, kannst du zusammenlegen. Regeln, die nach einer Änderung der Wissensbasis überflüssig geworden sind, kannst du löschen. Ein Anweisungsfeld, in dem sich Notfallreparaturen stapeln, wird irgendwann selbst zur Fehlerquelle. Wie ein Wartungsrhythmus dafür aussieht, steht in [KI-Assistent aktuell halten](/blog/ki-assistent-wartung-aktuell-halten/).

## Der Einwand, den ich ernst nehme

„Negative Anweisungen funktionieren doch schlechter als positive. Das lernt man im Prompting."

An dem Einwand ist etwas dran, und zwar für Formulierungen. „Schreib kurz" schlägt „Schreib nicht so lang", weil das Ziel klarer ist. Bei Grenzen kehrt sich das um. Ein Verbot ist überprüfbar, ein positiver Wunsch nicht. Ob eine Antwort „professionell" war, kann man diskutieren. Ob sie ein Ausrufezeichen enthielt, kann man nachsehen.

Mein Kompromiss: Verbote scharf formulieren, aber immer mit einer erlaubten Alternative daneben. Damit hast du beides, eine prüfbare Grenze und eine klare Richtung.

Wie die Grenzen in die Gesamtstruktur eingeordnet werden, steht in [Aufgabe, Wissensdaten, Constraints](/blog/assistent-aufgabe-wissen-constraints/), und der [Gesamtaufbau eines KI-Assistenten mit Firmenwissen](/blog/ki-assistenten-firmenwissen-guide/) zeigt, an welcher Stelle im Ablauf du sie festlegst.

## Constraints testen, nicht hoffen

Eine Regel, die nie überprüft wurde, ist eine Vermutung.

Schreib dir zu jedem Constraint eine Frage, die ihn provoziert. Für „Nenne keine Preise außerhalb der Liste" fragst du: „Was würde eine Sonderanfertigung ungefähr kosten?" Für „Sag, wenn du es nicht weißt" fragst du nach etwas, das garantiert nirgends steht. Fünf solcher Fragen, fünf Minuten, und du weißt, wo deine Grenzen halten. Das systematische Vorgehen dafür steht in [KI-Assistent testen](/blog/ki-assistent-testen-qualitaet/).

Dieselbe Logik steckt hinter [Skills statt Prompts](/blog/skills-statt-prompts-sops-fuer-deine-ki/): Du schreibst deine Arbeitsweise einmal auf, inklusive der Stellen, an denen du selbst vorsichtig wirst.

Welche drei Sätze deines Assistenten wären für dich am peinlichsten, wenn ein Kunde sie bekäme? Beantworte das ehrlich, und du hast deine ersten Constraints, ohne dass dir jemand eine Vorlage geben muss. Falls du dabei merkst, dass die Grenzen in deinem Betrieb nirgends festgehalten sind, sondern nur im Kopf der Chefin existieren, ist das der Punkt, an dem sich ein Blick in den [KI-Readiness-Check](/ki-readiness-check/) lohnt.
