System instruction: boundaries for an AI assistant

Every answer an AI assistant gives comes from three ingredients: the visitor's question, the material it is allowed to search, and a text nobody ever sees – the system instruction. It sits in front of every conversation, applies to every answer, and settles who the assistant is, how it speaks, what it gives information about, what it must not promise, and what it does when it does not know something. Most complaints about an assistant are therefore not model failures but gaps in this text: it guessed because nobody told it that guessing is forbidden. This article shows which six building blocks belong in it, why subject knowledge has no place there, how to version an instruction, and how to tell whether a change has actually taken effect.

Enlarge graphic

Labels in the illustration

• System instruction: stands fixed
• Role and remit
• Tone and form of address
• Permitted topics
• Promises ruled out
• Handling the unknown
• Language and handover
• Changes rarely, applies to every single answer
• Knowledge base: kept current
• Prices and terms
• Opening and delivery times
• Product data and variants
• Legal texts and deadlines
• Questions and answers
• Changed without a new version of the instruction
• Changes often, without the instruction being rewritten
• Every version is measured before it goes live
• 1 Fix the version
• 2 Run the test cases
• 3 Measure the answers
• 4 Refine
• Schematic illustration, no promise of specific results

System instruction and knowledge base

What the System Instruction Really Is

With every request an assistant is handed three things: the question, the matching excerpts from the stored material, and the system instruction. The first two change from conversation to conversation, the third stays. It is the only part that applies to every answer, and at the same time the only part the operator holds completely in hand. Treating it as a side issue leaves role, tone and boundaries to the model's own defaults.

This text is never visible. The visitor reads the answer, not the rule that produced it. That is what makes the instruction so effective and at the same time so easy to neglect: a mistake in it does not look like a mistake in the conversation, it looks like an assistant with a mind of its own. Only when the same question is asked ten times and the same skewed tone comes back ten times does an impression turn into a finding.

Six Building Blocks of a Workable Instruction

A usable instruction is shorter than most people expect. It answers six questions, in the order a person would ask them: Who are you? How do you speak? What do you give information about? What do you never promise? What do you do when you do not know? Which language do you answer in? Every further sentence has to justify itself by answering one of these six more sharply – otherwise it merely dilutes them.

What is missing from that list is telling: not a single fact about the business. No opening hour, no delivery time, no product name. That is not an oversight but the most important dividing line in the whole setup.

What Does Not Belong in the Instruction

The most common mistake is the convenient one: the opening hours quickly move into the instruction because they take effect there immediately. Six months later the hours have changed, the knowledge base is maintained, the website is right, and only the assistant quotes the old ones – and nobody looks for the fault in a text no one has opened for months. Subject knowledge in the instruction goes stale in silence.

The rule of thumb is simple: anything an employee would look up belongs in the material. Anything an employee would be told as a house rule on their first day belongs in the instruction. With that split, every new line can be filed quickly. How to build a body of material that carries this load is described in the article on building the knowledge base.

Naming Boundaries: Handling the Unknown

A language model fills gaps. That is not malice but construction: it continues with whatever sounds plausible. Without an explicit rule this produces a phone number that never existed or a delivery time nobody promised. The instruction therefore must not only forbid guessing but state what to do instead. A prohibition without a replacement action leaves the assistant mute, and a mute assistant loses the conversation just as surely as an inventive one.

• No factual statement without a source in the stored material.
• Name the gap instead of talking around it: "I have nothing on that" is an answer, "I cannot say exactly" is an excuse.
• Offer the way to a human in the same breath, by form, callback or handover in the chat.
• Never derive contact details, numbers, deadlines or terms from context, not even when they seem obvious.
• On partial matches, say what is covered and what stays open instead of blending the two.
• Log the declined question – it shows most clearly which content is missing from the material.

This can only be shown with questions that deliberately aim into the void. In our own measurement series, 8 of 8 questions without a basis were declined instead of guessed; these were eight questions deliberately outside the material, and the wording of every answer is in the measurement file. The counter-check is just as countable: 42 of 48 answers carried a source reference – the count covers questions whose answer is in the knowledge base, six carried no source reference. Both figures are listed under measurements.

Promises That Are Ruled Out

An assistant speaks on behalf of the business. What it says is attributed to the business – even when nobody ever approved that wording. The Higher Regional Court of Hamm classified a chatbot as a technical means used by the operator and over which the operator had sufficient control; the classification and its consequences are set out in the article on the ruling on chatbot liability. For the instruction this means: whatever the business does not want to promise has to be ruled out there explicitly.

• Delivery, response or processing deadlines that no connected system has confirmed.
• Discounts, goodwill or special terms that are not on file.
• Legal, medical or tax assessments.
• Statements about other companies' offerings, even when the visitor asks for them.
• Confirmations that sound like a binding contract.
• Properties and effects the business itself cannot substantiate.

Disclosure: The Point With No Discretion

One building block of the instruction is not a matter of taste. Article 50(1) of Regulation (EU) 2024/1689 obliges providers to design and develop AI systems intended to interact directly with natural persons in such a way that the persons concerned

The exception applies only where the machine is obvious from the circumstances anyway – nobody whose window looks like a chat with the team should rely on that. Under paragraph 5 of the same provision, the information has to be provided in a clear and distinguishable manner at the latest at the time of the first interaction. The instruction therefore contains a fixed sentence for the question whether there is a human at the other end, plus the rule not to soften it. A persona may have character, but not a biography. What disclosure requires in detail is set out in the article on the transparency duty under the AI Act.

Language Choice Left to Nothing

Without a rule, a model answers in whichever language dominates the context – often the language of the website, even though the question arrived in another. The instruction reverses this: the answer is given in the language of the question. Four side rules belong with it, settled once and then no longer up for discussion.

• Product names, technical terms and catalogue labels stay untranslated.
• Legal texts are not translated but linked in the version in which they apply.
• With mixed input, the language of the last question applies until the visitor switches.
• If the visitor switches language, the assistant switches too, without commenting on the switch.

How far this rule carries and where a separate version of the material becomes necessary is described in the article on the multilingual assistant. The instruction governs behaviour; it is no substitute for the material in the second language.

Versioning: One Change per Version

An instruction is source code, even when it is written in prose. It gets a number, a date and a reason, and it is not overwritten but replaced. The reason is mundane: if three sentences change at once and the assistant answers differently afterwards, nobody knows which of the three did it. One change per version is slower, and it is the only order that teaches you anything. Every change also needs a before value, otherwise every later statement stays a guess with a timestamp.

• Version number, date and reason sit at the head of the instruction.
• One change per version, even when two changes would fit together.
• The same test questions before and after the change, in identical wording.
• The old version stays available, so the way back takes a minute and not a night.
• Whatever should no longer apply is deleted, not dragged along in a subordinate clause.

Four Mistakes That Keep Recurring

Mistakes in system instructions look similar across industries. They rarely come from ignorance, mostly from the wish to settle everything at once.

How We Set Up an Instruction

At the start there is no text but a collection of real questions: what actually arrives in the inbox, on the phone and through the form. From that it follows which topics have to be permitted and where the assistant will inevitably run into a boundary. Only then is anything written, and in the language of the business rather than that of a rulebook.

• Collect real questions and sort them into permitted topics, forbidden topics and borderline cases.
• Fix role, tone and remit in one sentence each, plus two example answers.
• Write prohibitions as a pair of prohibition and replacement action.
• Spell out the rule for the case without a basis, including a sample sentence for declining.
• Define the test questions before the first version goes live.
• After two weeks read real conversations and refine the instruction, not earlier.

What comes out of this is not a document for the folder but a text that works every day. We create it alongside the material, keep the two apart, and record for every version what it was meant to change and what it actually changed. If you have an existing assistant whose answers feel unpredictable, it pays to look into this text first and into the model second. What the material next to it looks like is shown in the documentation; via contact we will take a look at your version.

Frequent questions