Werkstattnotiz 2026 · 03 7 Min.

Die Enttäuschung folgt fast immer demselben Muster: Man schreibt eine Anweisung — „Du bist ein erfahrener ISO-27001-Berater mit 15 Jahren Erfahrung“ — und ist von der ersten Antwort beeindruckt. Bei der dritten oder vierten schon nicht mehr. Das System behauptet Dinge mit derselben Selbstsicherheit, egal ob sie aus einem Normtext stammen oder frei erfunden sind. Es beantwortet eine Frage zur Ausschreibung im selben Ton wie eine zur Risikoanalyse. Und es prüft die eigene Antwort nie, bevor es sie abliefert.

Meine These: Das liegt selten am Modell. Es liegt daran, dass eine einzelne Anweisung keine Architektur ist — und ein virtueller Berater ohne Architektur bleibt ein beeindruckender Zufallsgenerator, kein Werkzeug, dem man Urteilsvermögen delegieren kann.

Ich habe mir über die letzten Monate selbst ein solches System gebaut, für die eigene Beratungsarbeit — mehrere Dutzend eng geschnittene Bausteine, an realen Szenarien getestet und immer wieder nachgeschärft. Es geht hier nicht darum, dieses System vorzustellen. Es geht um das, was sich beim Bauen als tragend erwiesen hat — und um die Fehler, die mich am meisten Zeit gekostet haben.

Was eine tragfähige Architektur ausmacht

Haltung und Fachwissen trennen. Der häufigste Anfängerfehler: Ein Prompt versucht gleichzeitig festzulegen, wie ein Berater denkt, und was er über ein Fachthema weiß. Beides vermischt sich, und jede fachliche Ergänzung verändert unbeabsichtigt den Ton. Wer beides in getrennten Bausteinen hält, kann die Denkweise verbessern, ohne das Fachwissen anzufassen — und umgekehrt.

Enge Domänen statt Alleswisser. Ein System, das „Security-Beratung“ als ein Thema behandelt, liefert überall mittelmäßige Antworten. Enge, klar abgegrenzte Bausteine mit expliziten Grenzen („dafür zuständig, dafür ausdrücklich nicht“) erzwingen Tiefe, statt sie durch Breite zu verwässern.

Qualitätsprüfung als erzwungener Schritt. Der wichtigste Baustein liefert kein Fachwissen, sondern prüft die anderen. Nach jeder Ausarbeitung läuft ein automatischer Check gegen feste Kriterien — ist jede Aussage belegt, jede Maßnahme einem Verantwortlichen zugeordnet. Fällt ein kritisches Kriterium durch, erzwingt das System eine Nachbesserung, bevor überhaupt ein Mensch das Ergebnis sieht. Das ist der Unterschied zwischen „das wird schon stimmen“ und einem System, das strukturell gezwungen ist, sich selbst zu prüfen.

Unsicherheit kalibrieren, nicht verstecken. Ein Berater, der jede Aussage gleich selbstsicher vorträgt, ist gefährlich — man kann nicht unterscheiden, ob eine Zahl belegt ist oder ein Bauchgefühl. Jede Behauptung sollte danach eingestuft werden, wie tragfähig ihr Beleg ist, und bei Unterschreitung ausdrücklich als Erfahrungswert gekennzeichnet werden, statt still als Fakt durchzugehen.

Übergaben testen, nicht nur Bausteine. Ein Modul für sich richtig zu prüfen sagt nichts darüber, ob die Übergabe zum nächsten hält.

Vertraulichkeit dort prüfen, wo das Risiko entsteht. Nicht erst vor der Veröffentlichung, sondern schon beim Schreiben.

Die Fehler, die am meisten gekostet haben

Über eine lange Testreihe mit vielen gefundenen und behobenen Lücken zeigte sich ein durchgehendes Muster: Fast keine Lücke lag an fachlicher Substanz. Das war die eigentliche Überraschung — man erwartet, dass eine KI in der Sache irrt. Tatsächlich lag fast jeder Fehler woanders:

Zwei für sich plausible Regeln, die sich im Einzelfall widersprechen. Bei fast jeder neuen Regel trat derselbe Fehlertyp auf: Zwei Aussagen, jede für sich korrekt, standen sich in einem konkreten Fall im Weg. Beim Schreiben unsichtbar, weil man eine neue Regel gegen sich selbst prüft, nicht gegen die bereits vorhandenen. Beim ersten echten Fall bricht der Widerspruch sofort auf. Gegenmittel: zu jeder neuen Regel bewusst einen Fall konstruieren, an dem sie gemeinsam mit den bestehenden greift.

Mit dem eigenen Normalfall testen, nicht mit der Praxis. Die Lücken lauteten regelmäßig: Cloud vorausgesetzt, wo der Kunde On-Premise arbeitet. Ein Tool vorausgesetzt, wo in der Praxis noch Papier läuft. Ein Standardverfahren unterstellt, wo tatsächlich verhandelt wurde. Man testet unbewusst mit dem Fall, der einem selbst am vertrautesten ist — und der ist selten der, an dem es später scheitert.

Den Bericht über die Arbeit für die Arbeit halten. Ein System kann einen beeindruckenden fachlichen Output liefern und trotzdem den eigentlich verlangten Abschlussschritt auslassen — das Ergebnis tatsächlich ablegen, den Stand aktualisieren, das Protokoll schreiben. Der zurückgemeldete Text klingt nach „erledigt“. War es nicht. Nachprüfen, ob etwas wirklich da ist, nicht der Selbstauskunft glauben.

Abgeleitete Dokumente laufen unbemerkt auseinander. Übersichten, Grafiken, Zusammenfassungen wurden mehrfach nicht mit aktualisiert, wenn sich etwas änderte — weil sie als „läuft schon irgendwie mit“ galten, statt fest in den Prozess eingebaut zu sein.

Grenzfälle der Interpretation überlassen statt sie festzulegen. Was passiert in einer Ausnahmesituation, die „eigentlich klar“ ist? Bis ein Testfall zeigt, dass zwei Leser es unterschiedlich verstehen. Jeder nicht festgelegte Grenzfall ist eine Wette, dass niemand ihn je erreicht.

Teilprüfung als Vollprüfung ausgeben. „Wir haben das getestet“ heißt in der Praxis oft: ein paar Fälle, nicht alle. Das ist an sich kein Problem — zum Problem wird es, wenn es stillschweigend als vollständig verkauft wird.

Der rote Faden: Fast nichts davon ist ein fachlicher Fehler. Es sind Fehler der Betriebsdisziplin — Widersprüche, Annahmen, Verifikation, Drift, Interpretationslücken, Abdeckungsgrad. Wer einen virtuellen Berater baut und nur auf die fachliche Qualität der Antworten achtet, prüft den Teil, der am seltensten bricht.

Die Fragen, die wirklich zählen

Gibt es eine getrennte Haltungs-Ebene, oder sind Ton und Fachwissen vermischt? Sind die Zuständigkeiten eng genug geschnitten? Gibt es einen erzwungenen Prüfschritt vor der Auslieferung? Kennzeichnet das System den Unterschied zwischen belegter Aussage und Erfahrungswert? Wurden die Übergänge zwischen Themen mit echten Fällen durchgespielt — nicht nur spezifiziert?

Ein Sprachmodell, das gut formuliert, ist heute keine Besonderheit mehr. Was ein System beratungstauglich macht, ist die Architektur drumherum — und die zeigt sich erst im wiederholten Test an echten Fällen, nicht beim ersten Entwurf.

Wer selbst an so etwas baut oder gerade evaluiert, ob ein bestehendes Setup trägt: Welcher dieser Punkte hat euch am meisten überrascht?