Tragfähige, robuste und sichere Prozesse mit KI erstellen

Du willst einen Prozess von Grund auf neu bauen: stabil, sicher, mit KI an den richtigen Stellen. Dieser Leitfaden zeigt den Weg für beide Fälle: wenn es schon einen manuellen Ablauf gibt, und wenn es nur eine Idee gibt.

Inhalt

• Bestehender Ablauf oder neue Idee
• Grundprinzipien vor jedem Bau
• Anatomie eines Prozesses
• Die Einstiege: Bestand aufnehmen oder Idee schärfen
• Sprache zuerst: Ein Wort, eine Bedeutung
• Entitäten, Identität, Zustände und die Sätze darüber
• Das Prüfraster: Sprache, Logik, Sache, Umsetzung, Recht
• Rollen und Berechtigungen
• Der Prozesssteckbrief: jeder Prozess bekommt einen Ausweis
• Einzelschritte und Transaktionen: der robuste Kern
• Fehlerfälle zuerst
• Wo KI hineinpasst und wo nicht
• KI-Bausteine messbar machen: Gold, Konfidenz, Review
• KI sicher einbetten
• Umsetzung mit Nachweis
• Supervision, lebende Dokumentation und Produktionsreife

Bestehender Ablauf oder neue Idee

• Dein Ausgangspunkt entscheidet über den ersten Schritt.
• Bestehender Ablauf: Das Wissen steckt in den Köpfen, nicht im Handbuch.
• Eine Woche zusehen und mitschreiben, so wie es wirklich passiert.
• Verbesserungsideen still notieren. Beobachtete stellen den Ablauf sonst besser dar.
• Neue Idee: als fachlichen Auftrag aufschreiben, ohne Technik, ohne Tool.
• 3 Fragen: Wer startet den Prozess? Was ist am Ende wahr? Wer hat was davon?
• Häufigster Fehler: die Methoden verwechseln.
• Zusammentreffen: Auslöser, Ergebnis und erste Regeln stehen fest, danach ist der Weg identisch.
• Das Ziel: ein dokumentierter, geprüfter, belegter, betriebsfähiger Prozess.
• Beispiele: Bescheid-Versand (bestehender Ablauf) und Lernzusammenfassung (neue Idee).

Du willst einen Prozess bauen, in dem auch KI zum Einsatz kommt. Dein Ausgangspunkt entscheidet über den ersten Schritt. Entweder es gibt schon einen Ablauf, den Menschen heute von Hand erledigen. Oder es gibt nur eine Idee, die noch niemand umgesetzt hat. Beide Wege führen zum selben Ziel. Die Wege beginnen an verschiedenen Stellen, und wer sie verwechselt, macht den ersten Schritt am falschen Ort.

Der Weg aus dem bestehenden Ablauf

Menschen erledigen die Arbeit heute. Diese Leute kennen die Sonderfälle, die Fristen und die Tricks. Dieses Wissen steht in keinem Dokument. Es steckt in ihren Köpfen.

Dein erster Schritt: Zusehen und mitschreiben, mindestens eine Woche lang. Schreib auf, was die Leute wirklich tun, Schritt für Schritt, mit allen Ausnahmen. Das vorhandene Handbuch liest Du später. Wenn Du Gedanken und Ideen für Verbesserungen hast, dann notiere sie Dir still und ohne Kommentar. Jetzt liegt der Fokus ausschließlich darauf, wie es gerade ist. Jede Frage von Dir, die auf eine Verbesserung abzielen würde, würde sofort die weitere Beobachtung des Prozesses stören. (Hintergrund: Menschen, die sich beobachtet oder bewertet fühlen, stellen einen Ablauf oft besser dar, als er ist.)

Der Weg aus der neuen Idee

Hier gibt es keinen Ablauf, dem Du zusehen könntest. Zusehen entfällt.

Dein erster Schritt: Schreib die Idee als fachlichen Auftrag auf. Beantworte dazu diese Fragen:

• Wer startet den Prozess?
• Was ist am Ende wahr?
• Wer hat was davon?

Schreib die Antworten so auf, dass sie ein Außenstehender versteht, der Deinen Betrieb nicht kennt. Keine Technik nennen, kein Tool nennen. Das kommt später.

Der häufigste Fehler am Anfang

Die Methoden verwechseln. Wer bei einer neuen Idee erst den Ist-Zustand dokumentieren will, hat nichts zu dokumentieren. Wer einen bestehenden Ablauf am Schreibtisch neu erfindet, wirft das Wissen der Leute weg, die ihn heute am Laufen halten. Beide Fehler führen am tatsächlichen Ablauf vorbei.

Wo beide Wege zusammentreffen

Beide Wege treffen am selben Punkt zusammen: Du kennst den Auslöser, das Ergebnis und die ersten Regeln Deiner Sache. Beim bestehenden Ablauf kommen sie aus Deinem Protokoll, bei der neuen Idee aus Deinem Auftrag. Danach ist der Weg bei beiden identisch:

• Begriffe klären
• Fachmodell bauen
• Prozesse entwerfen
• KI einbetten
• Nachweis führen
• Reifen lassen

Was am Ende steht

Ein Prozess, der diese Eigenschaften mitbringt:

• Er ist dokumentiert: Jeder Schritt steht schriftlich, ein Außenstehender kann ihn lesen.
• Er ist geprüft: Ein zweiter Mensch hat jeden Text mit den Quellen abgeglichen.
• Er ist belegt: Jede Aussage über sein Verhalten hat einen Nachweis aus Test oder Betrieb.
• Er ist betriebsfähig: Er läuft auf einer echten Umgebung, und die Leute, die ihn nutzen, verstehen ihn.

Die Software ist der Ort, an dem der Prozess läuft. Die KI darin ist ein Baustein. Der Baustein liefert Vorschläge, der Prozess prüft, ein Mensch entscheidet.

Die Beispiele dieses Leitfadens

Das Beispiel zum bestehenden Ablauf: der Bescheid-Versand. Heute schreibt nach jeder Seminar-Anmeldung ein Mensch eine E-Mail: Begrüßung, Termine, Zugangsdaten. 3 Schritte stehen im Handbuch, 11 Sonderfälle stecken im Kopf der Kollegin. In Die Einstiege: Bestand aufnehmen oder Idee schärfen schaust Du diesem Ablauf eine Woche lang zu. Danach steht fest: Auslöser „Anmeldung eingegangen", Ergebnis „Bescheid geprüft und versendet", erste Regel „Jeder Bescheid gehört zu genau einer Anmeldung".

Das Beispiel zur neuen Idee: die Lernzusammenfassung. Die Idee: Teilnehmer bekommen nach dem Seminar eine Zusammenfassung, die auf ihre Fragen eingeht. Den Ablauf gibt es noch nicht. In Die Einstiege: Bestand aufnehmen oder Idee schärfen schreibst Du die Idee als Auftrag auf. Danach steht fest: Auslöser „Seminar abgeschlossen", Ergebnis „Zusammenfassung freigegeben und versendet", erste Regel „Kein Versand ohne Freigabe durch einen Menschen".

Weiter mit Grundprinzipien vor jedem Bau, wenn Du in einem Satz sagen kannst, in welcher Lage Du bist und was Dein erster Schritt ist.

Grundprinzipien vor jedem Bau

• Die Regeln stehen vor jedem Bau und gelten für beide Wege und den ganzen Betrieb.
• Erst die Sache, dann die Technik: Fachmodell vor Framework, Sätze vor Tabellen, Prozesssteckbrief vor Code.
• Wer mit dem Tool anfängt, bekommt den Prozess, den das Tool gerade kann.
• Jede Aussage braucht einen Nachweis: Test, Protokolleintrag oder beobachteter Fall.
• Was keinen Nachweis hat, steht als offener Punkt in der Liste, nicht als Behauptung im Text.
• Verantwortung bleibt beim Menschen: Die KI liefert Vorschläge, der Prozess prüft, ein Mensch entscheidet.
• Tragfähig: trägt alle Sonderfälle. Robust: fällt kontrolliert. Sicher: ohne Erlaubnis geht nichts.
• Praxis-Beleg: 115 Dateien Prozessbeschreibungen, jede Zeile mit Quelle.

Bevor irgendetwas gebaut wird, stehen die Regeln. Die Regeln gelten für beide Wege, für jeden Schritt danach und für den ganzen Betrieb.

Erst die Sache, dann die Technik

Wer mit dem Tool anfängt, bekommt den Prozess, den das Tool gerade kann. Du willst den Prozess, den Deine Sache braucht. Darum ist die Reihenfolge fest:

• Zuerst das Fachmodell, dann das Framework (das technische Grundgerüst der Software).
• Zuerst die Sätze (die Regeln des Modells), dann die Tabellen.
• Zuerst der Prozesssteckbrief, dann der Code.

Beispiel: Beim Bescheid-Versand war die erste Versuchung ein Mail-Tool. Erst der Satz „Jeder Bescheid gehört zu genau einer Anmeldung" zeigte, was die Technik können muss: Duplikate verhindern, egal wie oft jemand klickt.

Belegen oder offen lassen

Jede Aussage über den Prozess braucht einen Nachweis: einen Test, einen Protokolleintrag, einen beobachteten Fall. Was keinen Nachweis hat, steht als offener Punkt in der Liste. Es steht nicht als Behauptung im Text.

Beispiel: Der Satz „Der Versand dauert unter einer Minute" kam erst in die Doku, nachdem der dokumentierte Lauf es gezeigt hatte. Vorher stand er als offener Punkt in der Liste.

Verantwortung bleibt beim Menschen

Die KI liefert Vorschläge, der Prozess prüft, ein Mensch entscheidet. Diese Reihenfolge gilt an jeder KI-Stelle. Jede Entscheidung mit Tragweite nennt ihre Person.

Beispiel: Bei der Lernzusammenfassung gibt die Kursbegleitung frei. Der Name der Kursbegleitung steht in der Freigabe, mit Datum. Die KI hat den Text geschrieben. Die Verantwortung trägt der Mensch, der freigibt.

Was tragfähig, robust und sicher konkret heißen

• Tragfähig: Der Prozess trägt die echte Last: alle Sonderfälle, nicht nur den Normalfall.
• Robust: Er fällt kontrolliert, nie still. Jeder Fehler hat seinen Ausgang.
• Sicher: Ohne Erlaubnis geht nichts. Daten fließen nur, soweit die Sache sie braucht. Jede wichtige Handlung ist später belegbar.

Praxis-Beleg aus einem echten Projekt

Ein laufendes System mit 115 Dateien voller Prozessbeschreibungen: Jede Zeile hat eine Quelle, jede Regel einen Nachweis, jede offene Frage einen Platz in der Liste. Keine einzige Zeile ist geraten. Dahinter stehen genau diese Regeln.

Weiter mit Anatomie eines Prozesses, wenn Du für jede Regel sagen kannst, an welcher Stelle Deines Projekts sie wirkt.

Anatomie eines Prozesses

• Jeder Prozess hat 3 Teile: Auslöser, Schritte, Ergebnis.
• Fehlt ein Teil, ist es kein Prozess.
• 4 Arten: Hauptprozess (ein Mensch startet), Teilprozess (ein Prozess ruft), Lauf (die Uhr startet), Sicht (nur lesen).
• Die Art bestimmt den Auslöser.
• Aufgabe oder Problem: die wichtigste Frage für KI.
• Aufgabe: bekannt, wiederholbar, einem neuen Kollegen zeigbar. Problem: neu und offen.
• KI kann Aufgaben übernehmen. Probleme bleiben bei Menschen.
• Beispiele: Versand um 3 Uhr ist ein Lauf, die Freigabe ein Hauptprozess, die offenen Anmeldungen eine Sicht.

Bevor Du Prozesse entwirfst, brauchst Du ihre Teile und ihre Arten.

Die Teile: Auslöser, Schritte, Ergebnis

• Auslöser: Das Ereignis, das den Prozess startet.
• Schritte: Die Handlungen in fester Reihenfolge.
• Ergebnis: Was am Ende wahr ist.

Fehlt ein Teil, ist es kein Prozess. Ohne Auslöser weiß niemand, wann er läuft. Ohne Ergebnis weiß niemand, wann er fertig ist.

Die Arten

• Hauptprozess: Ein Mensch startet ihn, etwa über eine Eingabemaske (ein Formular am Bildschirm).
• Teilprozess: Andere Prozesse rufen ihn auf. Er liefert sein Ergebnis an den Rufer zurück.
• Lauf: Die Uhr startet ihn. Er arbeitet ohne Zutun eines Menschen.
• Sicht: Eine Sicht liest nur und ändert nichts.

Die Art bestimmt den Auslöser. Ein Lauf braucht einen Zeitplan, ein Hauptprozess eine Maske, ein Teilprozess einen Rufer.

Aufgabe oder Problem: die wichtigste Frage für KI

Eine Aufgabe ist bekannt und wiederholbar. Es gibt Beispiele, und ein neuer Kollege kann sie lernen. Ein Problem ist neu und offen. Es hat keine bekannte Lösung.

KI kann Aufgaben übernehmen. Probleme bleiben bei Menschen. Die Prüffrage lautet: Kann ich einem neuen Kollegen zeigen, wie es geht, und er kann es danach? Ja heißt Aufgabe.

Beispiele aus den Durchgangsfällen:

• Der nächtliche Versand der Bescheide ist ein Lauf. Er startet um 3 Uhr, holt alles im Zustand freigegeben, versendet.
• Das Freigeben der Zusammenfassung ist ein Hauptprozess. Die Kursbegleitung öffnet den Entwurf und entscheidet.
• Die Liste offener Anmeldungen ist eine Sicht. Diese Sicht zeigt Daten und ändert keine.
• Bescheid-Texte schreiben ist eine Aufgabe. Über eine Warteliste entscheiden ist ein Problem.

Weiter mit Die Einstiege: Bestand aufnehmen oder Idee schärfen, wenn Du für Deine Sache Auslöser, Schritte und Ergebnis in je einem Satz aufschreiben kannst.

Die Einstiege: Bestand aufnehmen oder Idee schärfen

• Die erste Frage: Gibt es schon einen Ablauf?
• Bestand: eine Woche zusehen und mitschreiben: Schritte, Ausnahmen, Dauer und Wartezeiten.
• Danach das Handbuch gegen das Protokoll lesen: Die Abweichungen zeigen die Wirklichkeit.
• Fachlicher Kern: Was muss bleiben? Was war Gewohnheit? Wo fängt heute ein Mensch Fehler ab?
• Beispiel: 3 Schritte im Handbuch, 11 Sonderfälle im Protokoll.
• Aus dem Sonderfall wird der Satz „Kein Bescheid ohne bestätigten Platz".
• Idee: fachlicher Auftrag ohne Technik. Aus 5 Stichworten wird ein Auftragstext.
• Beide Einstiege liefern denselben Stand: Auslöser, Ergebnis, erste Regel.

Erst die Frage: Gibt es schon einen Ablauf? Die Antwort wählt den Einstieg. Am Ende steht bei beiden Einstiegen dasselbe Ergebnis.

Einstieg über den bestehenden Ablauf: eine Woche zusehen

Setz Dich daneben und schreib mit, mindestens eine Woche lang. Was Du aufschreibst:

• jeden Schritt, so wie er wirklich passiert,
• jede Ausnahme und wie die Leute sie lösen,
• jede Dauer und jede Wartezeit.

Verbesserungsideen notierst Du still und ohne Kommentar, wie in Bestehender Ablauf oder neue Idee beschrieben. Das vorhandene Handbuch liest Du danach und gleichst es mit Deinem Protokoll ab. Die Abweichungen zeigen, wo Handbuch und Wirklichkeit auseinandergehen.

Den fachlichen Kern herausziehen

Nach der Woche gehst Du das Protokoll durch, Schritt für Schritt, mit diesen Fragen:

• Was muss bleiben, weil die Sache es verlangt?
• Was war nur Gewohnheit und darf weg?
• Wo fängt heute ein Mensch Fehler ab, die der neue Prozess selbst abfangen muss?

Beispiel Bescheid-Versand: Das Handbuch kennt 3 Schritte. Das Protokoll zeigt 11 Sonderfälle dazu. Einer davon: Die Kollegin prüft vor jedem Versand, ob der Platz noch bestätigt ist. Diese Prüfung gehört zum fachlichen Kern. Aus ihr wird der Satz „Kein Bescheid ohne bestätigten Platz". Der Versand immer um 16 Uhr dagegen war Gewohnheit. Er fällt weg.

Einstieg über die neue Idee: der fachliche Auftrag

Hier gibt es nichts zu beobachten. Du schreibst die Idee als fachlichen Auftrag auf. Beantworte dazu diese Fragen:

• Wer startet den Prozess?
• Was ist am Ende wahr?
• Wer hat was davon?

Schreib so, dass ein Außenstehender es versteht. Keine Technik, kein Tool, kein Name eines KI-Modells. Das kommt später.

Beispiel Lernzusammenfassung: Aus 5 Stichworten („KI, Zusammenfassung, nach dem Seminar, persönlich, Kontrolle durch uns") wird dieser Auftrag: „Nach jedem Seminar bekommt jede teilnehmende Person eine Zusammenfassung, die auf ihre Fragen eingeht. Eine KI schreibt den Entwurf. Ein Mensch der Kursbegleitung prüft und gibt frei. Erst dann geht der Versand raus."

Am Ende steht bei beiden dasselbe

Weiter mit Sprache zuerst: Ein Wort, eine Bedeutung, wenn Auslöser, Ergebnis und die ersten Regeln Deiner Sache auf Papier stehen.

Sprache zuerst: Ein Wort, eine Bedeutung

• Fehler in Prozessen beginnen als Fehler in der Sprache.
• 2 Prüffragen: mehrere Worte für dieselbe Sache? Ein Wort für mehrere Sachen?
• Glossar je Begriff: Wort, Bedeutung in einem Satz, verbotene Synonyme, Quelle.
• Jeder Begriff kommt überall gleich vor: Doku, Code, Prompt, Maske.
• Wer ein neues Wort braucht, legt es zuerst im Glossar an.
• Beispiel: Anmeldung, Buchung, Registrierung parallel. Die Auswertungen stritten, bis „Anmeldung" blieb.
• Bei KI doppelt wichtig: Die KI übernimmt jede Ungenauigkeit und wiederholt sie tausendfach.

Fehler in Prozessen beginnen als Fehler in der Sprache. Darum kommt vor jedem Modell das Glossar.

Die Prüffragen

• Gibt es mehrere Worte für dieselbe Sache?
• Gibt es ein Wort für mehrere Sachen?

Beide Fälle erzeugen Fehler. Im ersten Fall reden die Leute aneinander vorbei, ohne es zu merken. Im zweiten Fall versteht jeder etwas anderes unter demselben Wort.

Das Glossar bauen

Für jeden Begriff schreibst Du auf:

• das Wort,
• die Bedeutung in einem Satz,
• die verbotenen Synonyme,
• die Quelle der Bedeutung: Wer hat es festgelegt, wann.

Danach gilt: Jeder Begriff kommt überall gleich vor. In der Doku, im Code, im Prompt (dem Auftragstext an die KI), in der Maske. Wer ein neues Wort braucht, prüft zuerst das Glossar und legt den Begriff dort an.

Beispiel: In einem Team hieß derselbe Vorgang mal Anmeldung, mal Buchung, mal Registrierung. Eine Auswertung zählte Buchungen, eine andere Anmeldungen. Die Zahlen stritten seit Monaten, niemand wusste warum. Nach dem Glossar blieb „Anmeldung". Die anderen Worte sind seither verboten, und die Auswertungen stimmen überein.

Warum das bei KI doppelt zählt

Die KI übernimmt jede Ungenauigkeit und wiederholt sie tausendfach. Steht im Prompt „Seminar" und gemeint ist mal der Kurs, mal der einzelne Termin, mischt die Ausgabe beides. Das Glossar ist damit auch ein Stück KI-Sicherheit.

Weiter mit Entitäten, Identität, Zustände und die Sätze darüber, wenn Dein Glossar die zentralen Begriffe enthält und bei jedem die verbotenen Synonyme danebenstehen.

Entitäten, Identität, Zustände und die Sätze darüber

• Das Fachmodell: die Dinge der Sache, ihre Zustände und die Sätze darüber.
• Entität: ein Ding mit eigenem Lebenslauf, das der Prozess speichert oder über die Zeit verfolgt.
• Identität: das Merkmal, das jede Entität eindeutig macht. Ohne Identität kein „genau eines".
• Zustände: Jeder Wechsel gehört zu genau einem Prozess. Rückwärts nur über einen eigenen Prozess.
• Sätze: kurz und prüfbar, kein „sollte", kein „möglichst".
• Die Sätze sind eigene Knoten im Modell: Zusammengehörigkeit, Reihenfolge, Verantwortung.
• Aus jedem Satz werden später eine Datenbankregel und ein Testfall.
• Beispiel: Seminar, Teilnehmende Person, Lernzusammenfassung, Freigabe, Frage der Person.

Aus den Begriffen des Glossars wird jetzt das Fachmodell: die Dinge Deiner Sache, ihre Zustände und die Sätze darüber.

So sieht ein Fachmodell aus, gezeigt am Beispiel der Lernzusammenfassung. Blau sind die Entitäten, grün die Prozesse, violett die Rolle und gold die Sätze. Die Sätze sind eigene Knoten, also eigene Kästen in der Grafik: Die Sätze sagen, was zusammengehört, was vor was kommt und wer verantwortlich ist. Später werden aus ihnen Datenbankregeln und Testfälle. Die Liste unter der Grafik erklärt jedes Element.

• Seminar (Entität): Veranstaltung mit Beginn und Ende. Eindeutig über die Seminarnummer. Zustände: geplant, läuft, abgeschlossen, abgesagt.
• Teilnehmende Person (Entität): Ein Mensch im Seminar. Eindeutig über die Anmeldeadresse.
• Lernzusammenfassung (Entität): Das Dokument, für das der ganze Prozess existiert. Zustände: entworfen, in Prüfung, freigegeben, versendet, verworfen.
• Freigabe (Entität): Die schriftliche Entscheidung eines Menschen über einen Entwurf.
• Frage der Person (Entität): Was die Person im Seminar gefragt hat. Darauf muss ihre Zusammenfassung eingehen.
• Nur für besuchte Seminare (Satz): Keine Zusammenfassung für ein Seminar, in dem die Person nicht war.
• Gehört zu genau einem Seminar (Satz): Keine Zusammenfassung ohne Seminar, keine bei zweien. Wird zur Datenbankregel.
• Versand erst nach Freigabe (Satz): Ohne Freigabe geht nichts raus.
• Freigabe nennt ihre Person (Satz): Jede Freigabe steht mit Namen darin.
• Entwurf erzeugen (Prozess, Lauf): Läuft zeitgesteuert. Für jedes abgeschlossene Seminar ohne Entwurf schreibt die KI einen. Die Daten kommen aus der Datenbank, der Text von der KI. Bei Unsicherheit meldet der Baustein Unklar.
• Zusammenfassung freigeben (Prozess, Hauptprozess): Ein Mensch der Rolle Kursbegleitung liest den Entwurf und entscheidet.
• Freigegebene versenden (Prozess, Lauf): Versendet alles im Zustand freigegeben.
• Kursbegleitung (Rolle): Die einzige Rolle, die freigeben darf.

Entitäten finden

Entitäten sind die Dinge, die Dein Prozess speichert oder über die Zeit verfolgt. Der Test: Hat das Ding einen eigenen Lebenslauf? Dann ist es eine Entität.

Beispiel Lernzusammenfassung: Seminar, Teilnehmende Person, Lernzusammenfassung, Freigabe, Frage der Person.

Identität: was macht es eindeutig

Jede Entität braucht ein Merkmal, das sie von allen anderen unterscheidet. Ohne Identität gibt es kein „genau eines" und keine Datenbankregel.

• Seminar: eindeutig über die Seminarnummer.
• Teilnehmende Person: eindeutig über die Anmeldeadresse.
• Lernzusammenfassung: eindeutig über Seminar und Person zusammen.

Zustände und Übergänge

Jede Entität mit Lebenslauf bekommt Zustände. Die Lernzusammenfassung: entworfen, in Prüfung, freigegeben, versendet, verworfen.

Die Regeln dazu:

• Jeder Zustandswechsel gehört zu genau einem Prozess. Nichts wechselt „irgendwie".
• Rückwärts geht es nur über einen eigenen Prozess. Ein Entwurf wird verworfen, nicht zurückgespult.

Die Sätze über den Entitäten

Die Sätze sind die Regeln des Modells. Diese Regeln sagen, was zusammengehört, was vor was kommt und wer verantwortlich ist. Beispiele:

• „Jede Zusammenfassung gehört zu genau einem Seminar."
• „Versand erst nach Freigabe."
• „Freigabe nennt ihre Person."

Schreib Sätze kurz und prüfbar. Kein „sollte", kein „möglichst". Aus jedem Satz werden später eine Datenbankregel und ein Testfall. Darum stehen die Sätze in der Grafik als eigene Knoten.

Weiter mit Das Prüfraster: Sprache, Logik, Sache, Umsetzung, Recht, wenn jede Entität ihre Identität und ihre Zustände hat und die Sätze darüber aufgeschrieben sind.

Das Prüfraster: Sprache, Logik, Sache, Umsetzung, Recht

• Ein Modell ohne Prüfung ist eine Vermutung.
• Das Raster hat 5 Achsen: Sprache, Logik, Sache, Umsetzung, Recht.
• Jede Änderung am Fachmodell läuft durch das Raster, Achse für Achse.
• Jeder Fund bekommt genau 2 Wege: Reparatur oder begründete Abweichung mit Datum und Name.
• Ein Fund ohne Reparatur oder Begründung bleibt nicht stehen.
• Beispiel: Der Bescheid konnte vor der Platzbestätigung rausgehen, weil kein Satz es verbot.
• Reparatur: neuer Zustand „Platz bestätigt" plus der Satz „Kein Bescheid ohne bestätigten Platz".

Ein Modell ohne Prüfung ist eine Vermutung. Jede Änderung am Fachmodell läuft durch das Prüfraster.

Die Achsen und ihre Fragen

• Sprache: Hat jeder Begriff genau eine Bedeutung?
• Logik: Widersprechen sich 2 Sätze?
• Sache: Kann etwas passieren, bevor seine Voraussetzung eingetreten ist?
• Umsetzung: Lässt sich jede Regel als Datenbankregel oder Test schreiben?
• Recht: Sind Datenhaltung und Zugriff erlaubt und notwendig?

Wie geprüft wird

Du gehst das Modell Achse für Achse durch. Zeigt eine Antwort einen Fehler, gibt es genau 2 Wege:

• Du reparierst das Modell.
• Du begründest die Abweichung als bewusste Entscheidung, mit Datum und Namen.

Ein Fund ohne Reparatur oder Begründung bleibt nicht stehen.

Beispiel: ein Fund aus dem Raster

Beim Bescheid-Versand deckte die Frage aus der Achse Sache einen Fehler auf: Der Bescheid konnte rausgehen, bevor der Platz bestätigt war. Die Reihenfolge war möglich, weil kein Satz sie verbot.

Die Reparatur: neuer Zustand „Platz bestätigt" und der Satz „Kein Bescheid ohne bestätigten Platz".

Das Raster als Tabelle

So sieht ein Durchlauf aus. Jede Zeile ein Sachverhalt, jede Spalte eine Achse, jeder Treffer ein Fund:

Weiter mit Rollen und Berechtigungen, wenn Dein Modell den Durchlauf durchs Raster überstanden hat und jeder Fund seinen Weg hat.

Rollen und Berechtigungen

• Eine Rolle ist ein Bündel von Erlaubnissen für eine Aufgabe, kein Jobtitel.
• Eine Person kann mehrere Rollen tragen, eine Rolle kann mehrere Personen haben.
• Rollen kommen aus dem Fachmodell: Jede Handlung braucht eine Rolle, die sie darf.
• Fail-closed: Was nicht ausdrücklich erlaubt ist, ist verboten.
• Neue Handlung: erst für niemanden erlaubt, dann freigegeben mit Datum und Begründung.
• Nur die Daten erheben, die die Sache braucht. Jede wichtige Handlung protokollieren: wer, was, wann, woran.
• Die Nie-Liste der KI: freigeben, löschen, Stammdaten ändern, im eigenen Namen nach außen handeln.

Wer darf was tun, wer darf was sehen? Ohne diese Antwort kann jeder Aufruf alles: lesen, ändern, löschen. Diese Antwort legst Du hier fest.

Rollen kommen aus dem Fachmodell

Eine Rolle ist ein Bündel von Erlaubnissen für eine Aufgabe, kein Jobtitel. Dieselbe Person kann mehrere Rollen haben, und eine Rolle kann mehrere Personen tragen.

Beispiel: Die Kollegin aus dem Sekretariat trägt die Rollen Kursverwaltung und Kursbegleitung. Die Rolle Kursbegleitung tragen insgesamt 3 Personen, damit die Freigabe auch im Urlaub läuft.

Jede Rolle entsteht aus dem Fachmodell: Gibt es eine Handlung, dann gibt es eine Rolle, die sie darf. Die Kursbegleitung existiert, weil die Freigabe jemanden braucht.

Fail-closed: ohne Erlaubnis bleibt der Weg zu

Die Grundregel heißt fail-closed. Was nicht ausdrücklich erlaubt ist, ist verboten. Eine neu gebaute Handlung ist zunächst für niemanden erlaubt. Dann wird sie für eine Rolle freigegeben, mit Datum und Begründung.

Die Gegenprobe für jede Frage „Darf Rolle X die Handlung Y?": Steht es in der Tabelle? Wenn nicht, lautet die Antwort nein.

Beispiel: Der neu gebaute Schritt „Bescheid erneut versenden" ist nach dem Einbau für niemanden erlaubt. Erst wenn die Kursverwaltung die Handlung für ihre Rolle freigibt, kann sie aufgerufen werden.

Datensparsamkeit und Nachweis

• Erhebe nur die Daten, die die Sache braucht.
• Protokolliere jede wichtige Handlung: wer, was, wann, woran.
• Halte das Protokoll so, dass ein Außenstehender den Fall später rekonstruieren kann.

Beispiel: Im Protokoll der Freigabe steht: „12.09.2026, Kursbegleitung Meier, Entwurf 4711 freigegeben". Damit ist der Fall später vollständig rekonstruierbar.

Was die KI nie darf

Die KI bekommt keine Rolle mit Entscheidungsrecht. Der Baustein arbeitet innerhalb eines Schritts, mit festem Eingang und geprüftem Ausgang. Die Nie-Liste:

• freigeben,
• löschen,
• Stammdaten ändern (Grunddaten wie Seminare oder Personen),
• im eigenen Namen nach außen handeln.

Beispiel: die Rollentabelle der Lernzusammenfassung

Weiter mit Der Prozesssteckbrief: jeder Prozess bekommt einen Ausweis, wenn für jede Handlung die erlaubte Rolle feststeht und die Nie-Liste der KI unterschrieben ist.

Der Prozesssteckbrief: jeder Prozess bekommt einen Ausweis

• Jeder Prozess bekommt eine Karteikarte: den Prozesssteckbrief.
• Erst wenn der Prozesssteckbrief steht, existiert der Prozess.
• Die Felder: Kennung, Art, Auslöser, Ergebnis, beteiligte Bausteine, Stand.
• Der Prozesssteckbrief zwingt zu Entscheidungen, bevor gebaut wird.
• Diskussionen laufen über die Karteikarte, nicht über halbfertigen Code.
• Jede Änderung am Prozess ist eine neue Version der Karteikarte.
• Beispiele: bescheid-versand (Lauf, täglich um 3 Uhr) und zusammenfassung-freigeben (Hauptprozess).

Jeder Prozess bekommt eine Karteikarte: den Prozesssteckbrief. Erst wenn der Prozesssteckbrief steht, existiert der Prozess. Vorher ist er eine Absicht.

Die Felder des Prozesssteckbriefs

• Kennung: eindeutig und unveränderlich, zum Beispiel „bescheid-versand".
• Art: Hauptprozess, Teilprozess, Lauf oder Sicht.
• Auslöser: das Ereignis, das startet.
• Ergebnis: was am Ende wahr ist.
• Beteiligte Bausteine: Entitäten, Sätze, Rollen und KI-Bausteine, die der Prozess nutzt.
• Stand: Entwurf, geprüft, im Test oder live.

Warum die Karteikarte zuerst kommt

Der Prozesssteckbrief zwingt zu Entscheidungen, bevor gebaut wird. Diskussionen laufen über die Karteikarte, nicht über halbfertigen Code. Und jede Änderung am Prozess ist eine neue Version der Karteikarte. So bleibt nachvollziehbar, wann sich was geändert hat und warum.

Beispiel: der Prozesssteckbrief des Bescheid-Versands

Beispiel: der Prozesssteckbrief des Freigebens

Weiter mit Einzelschritte und Transaktionen: der robuste Kern, wenn jeder Deiner Prozesse eine ausgefüllte Karteikarte hat.

Einzelschritte und Transaktionen: der robuste Kern

• Der Prozesssteckbrief sagt, was der Prozess tut. Die Schrittfolge sagt, wie.
• Feste Reihenfolge: Eingang speichern, Berechtigung, Eingabe, Datensatz laden, Handlung, speichern, Protokoll, Folgen, abschließen.
• 403 vor 422: Wer keinen Zugriff hat, bekommt keine Auskunft über Felder.
• Folgen ganz zuletzt: Eine Mail lässt sich nicht zurückholen.
• Ein Schritt, eine Handlung, einzeln testbar.
• Transaktion: alles oder nichts. Entweder steht jeder Eintrag oder keiner.
• Ein Aggregat pro Transaktion, das Protokoll schreibt in derselben mit.
• Dauerhafte Folgen gehen erst nach dem endgültigen Speichern raus.

Der Prozesssteckbrief sagt, was der Prozess tut. Die Schrittfolge sagt, wie.

Die feste Reihenfolge

Jeder Prozess läuft in derselben Grundfolge:

• Eingang speichern: Zuerst landet der Auftrag in der Datenbank. Geht danach alles schief, ist nichts verloren.
• Berechtigung prüfen (403): Darf diese Rolle diese Handlung?
• Eingabe prüfen (422): Stimmen Format und Pflichtfelder?
• Datensatz laden (404): Existiert das Ding, an dem gehandelt wird?
• Handlung (409): Die eigentliche Arbeit. Fachliche Konflikte melden sich hier.
• Ergebnis speichern.
• Protokoll schreiben: wer, was, wann, woran.
• Folgen auslösen: Mails, Folgeprozesse, externe Aufrufe.
• Abschließen: Der Prozess meldet sein Ergebnis.

Die Zahlen in Klammern sind die Statusmeldungen, mit denen ein System dem Aufrufer antwortet. Jede Zahl steht für einen bestimmten Fehlerausgang. Was jede bedeutet, steht in Fehlerfälle zuerst.

Die Reihenfolge hat Gründe. Der Eingang kommt zuerst, damit kein Auftrag verloren geht. Die Berechtigung kommt vor der Eingabeprüfung: Wer keinen Zugriff hat, bekommt auch keine Auskunft über fehlerhafte Felder. Jede Fehlermeldung würde verraten, wie der Datensatz aufgebaut ist. Die Folgen kommen ganz zuletzt, weil man eine Mail nicht zurückholen kann.

Ein Schritt, eine Handlung

Jeder Schritt tut genau eine Sache und ist einzeln testbar. Ein Schritt, der „prüft und speichert", lässt später nicht mehr erkennen, was zuerst geschah.

Die Regeln für die Transaktion

Eine Transaktion ist ein gebündelter Speichervorgang: Alles darin wird gemeinsam gespeichert oder gemeinsam verworfen.

• Ein Aggregat pro Transaktion: Die Handlung verändert genau einen fachlichen Datensatz samt seinem direkten Umfeld.
• Das Protokoll schreibt in derselben Transaktion mit ab. Kein Zustand ohne seinen Eintrag.
• Dauerhafte Folgen wie Mails gehen erst nach dem endgültigen Speichern (Commit) raus.

Die Transaktion gilt alles oder nichts: Entweder steht am Ende jeder Eintrag oder keiner.

Beispiel für einen halben Zustand: Der Entwurf ist freigegeben, aber der Protokolleintrag fehlt. Niemand kann später prüfen, wer wann entschieden hat. Genau das verhindert die Transaktion: Fehlt der Protokolleintrag, rollt auch die Freigabe zurück.

Beispiel: „Zusammenfassung freigeben" Schritt für Schritt

Weiter mit Fehlerfälle zuerst, wenn die Schrittfolge steht und die Klammer um die Transaktion gezogen ist.

Fehlerfälle zuerst

• Ob der Prozess robust ist, zeigt sich, wenn etwas schiefgeht.
• Fehlerwege werden vor dem Bau festgelegt, nicht danach geflickt.
• Jeder Fehler bekommt seinen Ausgang: 403, 422, 404, 409, 429, 500.
• Kein Fehler endet in einer weißen Seite. Kein Fehler verschwindet ohne Meldung.
• 500: keine Einzelheiten nach außen.
• Idempotenz: Jeder Vorgang hat eine Kennung. Der zweite Klick legt nichts doppelt an.
• Der letzte Versuch steht im Datensatz: Sichtbarkeit, Bremse, Grundlage für 429.
• Beispiele: doppelte Anmeldung, Platz nicht bestätigt, leere KI-Antwort.

Der Normalfall ist der leichte Teil. Ob der Prozess robust ist, zeigt sich, wenn etwas schiefgeht. Darum werden die Fehlerwege vor dem Bau festgelegt, nicht danach geflickt.

Jeder Fehler bekommt seinen Ausgang

• 403 kein Zugriff: Die Rolle darf die Handlung nicht. Fail-closed aus Rollen und Berechtigungen.
• 422 Eingabe falsch: Der Aufruf ist fachlich unvollständig oder falsch. Der Absender kann es korrigieren.
• 404 nicht gefunden: Der Datensatz existiert nicht oder nicht mehr.
• 409 fachlicher Konflikt: Der Zustand verbietet die Handlung, etwa Freigeben eines schon versendeten Entwurfs.
• 429 zu viele Anfragen: Der Ruf kommt zu oft. Der Prozess bremst, statt zu kippen.
• 500 technischer Fehler: Etwas Infrastruktur ist kaputt. Der Prozess stoppt kontrolliert und protokolliert. Nach außen erfährt der Aufrufer keine Einzelheiten.

Kein Fehler endet in einer weißen Seite. Kein Fehler verschwindet ohne Meldung. Jeder Ausgang sagt dem Aufrufer, was los ist, und schreibt ins Protokoll.

Idempotenz: der zweite Klick legt nichts doppelt an

Wiederholungen kommen vor, täglich:

• Doppelklicks,
• doppelte Mails,
• wiederholte Aufrufe.

Die Antwort ist Idempotenz. Jeder Vorgang bekommt eine Kennung. Kommt derselbe Vorgang noch einmal, erkennt der Prozess die Kennung und legt nichts doppelt an. Er meldet das vorhandene Ergebnis zurück.

Beispiel: Die Kursbegleitung klickt „freigeben" zweimal, weil die Maske hakt. Ergebnis: eine Freigabe, ein Protokolleintrag. Der zweite Klick bekommt die Antwort „ist schon freigegeben".

Der gespeicherte letzte Versuch

Bei wiederholbaren Handlungen steht der Zeitpunkt des letzten Versuchs im Datensatz. Es hat diese Wirkungen:

• Sichtbarkeit: Wann lief es zuletzt?
• Bremse: Kein Dauerfeuer auf dieselbe Handlung.
• Grundlage für 429: Der Prozess erkennt „zu viele Anfragen" aus den Zeitstempeln.

Beispiel: mehrere Wege durch denselben Prozess

• Doppelte Anmeldung: gleiche Person, gleiches Seminar. Der Prozess erkennt die Kennung und meldet 409 mit dem Hinweis auf die vorhandene Anmeldung.
• Platz nicht mehr bestätigt: Der Bescheid-Lauf findet eine Anmeldung ohne bestätigten Platz. Kein Versand, Eintrag ins Protokoll, Aufgabe für die Kursverwaltung.
• Leere KI-Antwort: Der Textbaustein meldet Unklar. Der Entwurf geht nicht raus. Der Review-Pfad aus KI-Bausteine messbar machen greift.

Weiter mit Wo KI hineinpasst und wo nicht, wenn für jeden Schritt Deines Prozesses die Fehlerwege auf dem Papier stehen.

Wo KI hineinpasst und wo nicht

• Jetzt erst kommt die KI: Der Prozess steht bereits.
• 3 Prüffragen: Aufgabe abgegrenzt? Fehlschlag erkennbar? Mensch kann prüfen?
• Ein Nein: Die Stelle bleibt deterministisch oder beim Menschen.
• Was exakt sein muss, wird berechnet, nie generiert: Beträge, Fristen, Berechtigungen.
• Die KI ersetzt einen Schritt im Prozess, nie den ganzen Prozess.
• Ablehnung: keine blinde Wiederholung, erst steht die Änderung fest.
• Das Briefing wird gebaut, nicht formuliert: Aufgabe, Richtlinien, Ausgabe-Struktur, Profile.
• Gegenbeispiel: Über Wartelistenplätze entscheiden bleibt beim Menschen.

Jetzt erst kommt die KI. Der Prozess steht bereits: Modell, Rollen, Schritte, Fehlerwege. Die KI bekommt genau abgegrenzte Stellen darin.

Die Prüffragen für eine KI-Stelle

• Ist die Aufgabe klar abgegrenzt?
• Ist ein Fehlschlag erkennbar?
• Kann ein Mensch das Ergebnis prüfen?

Alle Antworten Ja: Die Stelle ist ein KI-Kandidat. Eine Antwort Nein: Die Stelle bleibt deterministisch (fest berechnet, immer mit demselben Ergebnis) oder beim Menschen.

Was deterministisch bleibt

Alles, was exakt sein muss, wird berechnet, nie generiert:

• Der Rechnungsbetrag kommt aus der Datenbank.
• Fristen kommen aus dem Kalender.
• Berechtigungen kommen aus der Rollentabelle.

Eine KI, die Beträge formuliert, wird irgendwann einen erfinden. Darum schreibt sie nur den Text um die Zahlen herum. Die Zahlen selbst kommen aus festen Abfragen.

Die KI als Baustein mit unsicherem Ausgang

Der Baustein bekommt einen festen Eingang und liefert einen Ausgang, den der Prozess prüft. Unklar ist ein gültiges Ergebnis mit eigenem Weg. Die KI ersetzt einen Schritt im Prozess, nie den ganzen Prozess.

Die Stationen einer KI-Stelle

Lehnt der Kritiker ab, folgt keine blinde Wiederholung. Die Neu-Erstellung legt zuerst die Änderung fest: Briefing präzisiert, Parameter geändert oder Modell gewechselt. Erst dann läuft der Durchlauf erneut.

Das Briefing: gebaut, nicht formuliert

Der Auftragstext an die KI heißt Briefing. Er entsteht aus Schichten, die Du bereits gebaut hast:

• Aufgabendefinition: aus dem Prozesssteckbrief.
• Richtlinien: aus den Sätzen des Fachmodells.
• Ausgabe-Struktur: aus dem Ergebnis des Prozesses.
• Rollen und Profile: aus dem Fachmodell.

Keine dieser Schichten wird frei formuliert. Definiere im Briefing das Ergebnis und den Kontext klar und lass der KI Raum bei der Umsetzung. Zu viele Einzelvorgaben widersprechen sich irgendwann, und die KI muss raten, was zuerst gilt. Braucht die Aufgabe Wissen aus eigenen Dokumenten, holt ein vorgeschalteter Suchschritt die passenden Stellen aus Deinem Bestand, bevor geschrieben wird.

Beispiel Bescheid-Versand: Aufgabendefinition „Anschreiben formulieren", Richtlinie „Kein Bescheid ohne bestätigten Platz", Ausgabe-Struktur „Begrüßung, Termine, Zugangsdaten", Profil „Ton der Kursverwaltung".

Beispiel: die KI-Stelle im Bescheid-Versand

Die Aufgabe: Aus Seminar, Terminen, Zugangsdaten und Textbausteinen ein Anschreiben formulieren. Abgegrenzt? Ja, Eingang und Ausgang stehen im Prozesssteckbrief. Fehlschlag erkennbar? Ja: leerer Text, falsches Datum, falsches Seminar fallen bei der Prüfung auf. Mensch kann prüfen? Ja, die Kollegin liest jeden Entwurf im Stichproben- und Review-Verfahren aus KI-Bausteine messbar machen.

Das Gegenbeispiel: „Die KI soll über Wartelistenplätze entscheiden." Kein klares Prüfmaß, keine abgegrenzte Aufgabe, große Tragweite. Das ist ein Problem im Sinne von Anatomie eines Prozesses. Es bleibt beim Menschen.

Weiter mit KI-Bausteine messbar machen: Gold, Konfidenz, Review, wenn Du die Prüffragen für jede Stelle beantwortet hast und jede Nein-Antwort ihren festen Platz hat.

KI-Bausteine messbar machen: Gold, Konfidenz, Review

• Bevor der Baustein arbeitet, stehen seine Zahlen.
• Goldstandard: geprüfte Beispiele mit Eingang und erwartetem Ausgang, auch schiefe Fälle.
• Qualitätsziel und Schwelle stehen schriftlich, bevor die KI das erste Mal läuft.
• Konfidenz: Unter der Schwelle meldet der Baustein Unklar, statt zu raten.
• Unklar ist ein gültiges Ergebnis mit eigenem Weg zu einem Menschen.
• Review-Pfad: Wer prüft, in welcher Frist, mit welchem Recht.
• Review-Ergebnisse fließen zurück in den Goldstandard: belegbar besser statt gefühlt besser.
• Telemetrie im Betrieb: Ablehnungsquote, Durchlaufzeit, Kosten je Ergebnis.

Bevor ein KI-Baustein arbeiten darf, stehen seine Zahlen.

Der Goldstandard

Der Goldstandard ist eine Sammlung von Beispielen: Eingang und erwarteter Ausgang, von einem Menschen geprüft und für richtig befunden. Die Beispiele kommen aus echten Fällen, auch aus den schiefen.

Beispiel: 20 geprüfte Bescheid-Texte. Darunter der Normalfall, die Anmeldung mit Sonderwunsch, der Fall mit fehlendem Termin. Jeder Text hat die Freigabe der Kollegin.

Qualitätsziel und Schwelle

Vor dem ersten Lauf legst Du das Qualitätsziel fest: Ab wann ist der Baustein gut genug? Etwa: 19 von 20 Goldstandard-Fällen ohne fachlichen Fehler. Und Du legst fest, was passiert, wenn er darunter liegt: Der Baustein geht nicht live, die Stelle läuft weiter manuell.

Die Schwelle steht schriftlich, bevor die KI das erste Mal läuft. Wer die Schwelle erst nach dem Messen festlegt, passt sie dem Ergebnis an.

Konfidenz und der Unklar-Ausgang

Der Baustein meldet zu jedem Ergebnis seine Konfidenz: wie sicher er sich ist. Unter der Schwelle gilt: Er meldet Unklar, statt zu raten. Unklar ist ein gültiges Ergebnis. Es hat einen eigenen Weg im Prozess, und der Weg führt zu einem Menschen.

Der Review-Pfad

Für die Unklar-Fälle und die Stichproben steht der Review-Pfad:

• Wer prüft: die Kollegin, nicht „das Team".
• In welcher Frist: vor dem nächsten Versand-Lauf.
• Mit welchem Recht: ändern, freigeben oder verwerfen.

Die Review-Ergebnisse fließen zurück in den Goldstandard. Jeder geprüfte Fall macht die Messung genauer. So wird der Baustein belegbar besser, statt gefühlt besser.

Regeln, Filter und Grenzwerte

Die Prüfung am Review-Pfad läuft gegen feste Instrumente:

• Regeln: formale Anforderungen, etwa Aufbau und Pflichtteile des Ergebnisses.
• Filter: was nie vorkommen darf, etwa erfundene Daten oder fremde Namen.
• Grenzwerte: ab wann eingegriffen wird, etwa die Schwelle der Konfidenz.

Die formale Vorprüfung kann ein zweites KI-System übernehmen. Die Entscheidung mit Tragweite bleibt beim Menschen, wie in Grundprinzipien vor jedem Bau festgelegt.

Telemetrie: die Zahlen des Betriebs

Für jede KI-Stelle misst der Prozess im Betrieb:

• die Ablehnungsquote: wie oft die Prüfung ablehnt,
• die Durchlaufzeit: wie lange ein Durchlauf braucht,
• die Kosten je freigegebenem Ergebnis.

Diese Zahlen zeigen, ob der Baustein besser wird. Mit ihnen schärfst Du Schwelle und Grenzwerte nach, und sie liefern das Material für das Beobachten und Nachjustieren in Supervision, lebende Dokumentation und Produktionsreife.

Weiter mit KI sicher einbetten, wenn Goldstandard, Schwelle und Review-Pfad schriftlich stehen.

KI sicher einbetten

• Die Schutzregeln gelten für jede KI-Stelle, ohne Ausnahme.
• Ein- und Ausgabe gelten als unsicher: prüfen, begrenzen, nie ungeprüft weiterreichen.
• Kein KI-Text direkt in eine Mail. Kein KI-Wert direkt in die Datenbank.
• Datensparsamkeit im Prompt: nur die Daten, die die Aufgabe braucht.
• Protokoll: Zeitpunkt, Bezug, Ergebnis, Konfidenz. Modell, Version und Parameter stehen schriftlich.
• Intern ist der Standardweg. Extern ist eine bewusste Option je Aufgabe, mit klassifizierten Daten.
• Ausfallweg: kontrollierter Stopp oder Ersatzweg. Der Prozess darf nie hängen und nie raten.
• So bleibt der Baustein austauschbar: anderes Modell, derselbe Prozess, dieselben Prüfungen.

Der Baustein ist gemessen. Jetzt bekommt er seine Schutzregeln. Die Regeln gelten für jede KI-Stelle, ohne Ausnahme.

Ein- und Ausgabe gelten als unsicher

Alles, was zur KI geht und von ihr kommt, wird behandelt wie eine Eingabe aus dem Internet: prüfen, begrenzen, nie ungeprüft weiterreichen. Kein KI-Text geht direkt in eine Mail. Kein KI-Wert geht direkt in die Datenbank. Dazwischen steht immer die Prüfung des Prozesses.

Datensparsamkeit im Prompt

In den Prompt kommen nur die Daten, die die Aufgabe braucht.

Beispiel Bescheid-Text: Im Prompt stehen:

• Seminarname,
• Termine,
• Zugangsdaten,
• Anrede.

Nicht dabei:

• Namen anderer Teilnehmer,
• Zahlungsdaten,
• interne Notizen.

Daten, die die KI nicht bekommt, kann sie auch nicht weitergeben.

Protokoll und Modellfestlegung

• Jede KI-Handlung wird protokolliert: Zeitpunkt, Bezug, Ergebnis, Konfidenz.
• Modell, Version und Parameter (die Einstellungen des Modells) stehen schriftlich.
• Ein Modellwechsel ist eine Änderung mit Datum und Begründung, kein stiller Tausch zwischendurch.

So bleibt der Baustein austauschbar: Morgen ein anderes Modell, derselbe Prozess, dieselben Prüfungen, derselbe Goldstandard.

Intern oder extern: die Datenregeln entscheiden

Der Standardweg ist ein Modell auf der eigenen Umgebung: Die Daten bleiben im eigenen Haus, die Kosten bleiben kalkulierbar. Ein externer Anbieter ist eine bewusste Option je Aufgabe. Vor jedem externen Aufruf stehen die Datenregeln:

• Klassifiziere die Daten der Aufgabe: Was darf das Haus verlassen?
• Was nicht freigegeben ist, geht nicht raus.
• Die Entscheidung steht schriftlich, mit Datum und Begründung.

Beispiel: Seminarname, Termine und Anrede im Bescheid-Text sind als versendbar klassifiziert. Zahlungsdaten und interne Notizen sind es nicht. Beide kommen in keinen externen Prompt, wie in der Datensparsamkeit oben festgelegt.

Der Ausfallweg

Antwortet die KI nicht, dauert sie zu lange oder liefert sie Unsinn, gilt der festgelegte Ausfallweg:

• kontrollierter Stopp: Der Prozess hält an der Stelle an und protokolliert.
• Ersatzweg: Standardtext ohne KI, oder der Versand verschiebt sich, oder ein Mensch wird gerufen.

Der Prozess darf nie hängen. Und er darf nie raten.

Beispiel: Beim Lauf der Lernzusammenfassung ist die KI nicht erreichbar. Der Lauf protokolliert „übersprungen, KI nicht erreichbar", die Kursbegleitung bekommt einen Hinweis, und kein halbfertiger Entwurf geht raus. Beim nächsten Lauf holt der Prozess die fehlenden Entwürfe nach.

Weiter mit Umsetzung mit Nachweis, wenn die Schutzregeln stehen und der Ausfallweg einmal probehalber durchgespielt wurde.

Umsetzung mit Nachweis

• Wer die vorherigen Schritte gearbeitet hat, setzt hier nur noch um, was auf dem Papier steht.
• Jede Tabelle aus einer Entität, jedes Feld aus einer Eigenschaft, jede Regel aus einem Satz.
• Jeder Prozess kommt aus einem Prozesssteckbrief.
• Wer beim Bau raten muss, geht zurück ins Fachmodell. Geratener Code hat keine Quelle.
• Ein Prozess nach dem anderen, ein Schritt nach dem anderen, jeder einzeln getestet.
• Tests in beide Richtungen: Der Normalweg geht, jeder Fehlerweg liefert seinen Ausgang.
• Der dokumentierte Lauf: echte Daten, protokolliert, an die Doku angehängt.
• „Läuft bei mir" gilt nicht. Der dokumentierte Lauf gilt.

Aus dem Modell wird ein laufendes System. Der Weg ist vorgezeichnet: Wer die vorherigen Schritte gearbeitet hat, setzt hier nur noch um, was auf dem Papier steht.

Die Ableitung aus dem Fachmodell

• Jede Tabelle kommt aus einer Entität.
• Jedes Feld kommt aus einer Eigenschaft.
• Jede Datenbankregel kommt aus einem Satz.
• Jeder Prozess kommt aus einem Prozesssteckbrief.

Geht das nur mit Raten, fehlt etwas im Fachmodell. Dann führt der Weg zurück zu Entitäten, Identität, Zustände und die Sätze darüber, nicht ins Improvisieren im Code. Geratener Code hat keine Quelle. Ohne Quelle kann niemand prüfen, ob er stimmt.

In kleinen Schritten bauen

Ein Prozess nach dem anderen. Ein Schritt nach dem anderen. Jeder Schritt ist einzeln lauffähig und getestet, bevor der nächste kommt. Wer mehrere Schritte auf einmal baut, kann am Ende nicht sagen, welcher davon funktioniert.

Testen in beide Richtungen

Für jeden Schritt gibt es Tests in beide Richtungen:

• Es geht: Der Normalweg liefert das erwartete Ergebnis.
• Es scheitert richtig: Jeder Fehlerweg aus Fehlerfälle zuerst liefert seinen Ausgang, schreibt ins Protokoll und hinterlässt keinen halben Zustand.

Beispiel: Die Testmatrix des Freigebens prüft:

• den Normalfall,
• den Doppelklick,
• die fehlende Rolle,
• den schon versendeten Entwurf,
• den Datenbankausfall mitten in der Transaktion.

Der dokumentierte Lauf

Am Ende steht der dokumentierte Lauf: ein Lauf auf der Entwicklungsumgebung mit echten Daten. Er wird protokolliert und an die Doku angehängt: Was lief, mit welchen Daten, mit welchem Ergebnis, wann. Erst dann gilt der Prozess als fertig gebaut. „Läuft bei mir" gilt nicht. Der dokumentierte Lauf gilt.

Weiter mit Supervision, lebende Dokumentation und Produktionsreife, wenn der dokumentierte Lauf steht und die Testmatrix grün ist.

Supervision, lebende Dokumentation und Produktionsreife

• Gebaut ist nicht betrieben: Es fehlen geprüfte Doku, Gate und Beobachten im Betrieb.
• Supervision: Ein zweiter Mensch gleicht jede Beschreibung mit den Quellen ab.
• Strittige Punkte werden eskaliert: entschieden, datiert, begründet.
• Kein Inhalt ohne Quelle: Zeilen ohne Quelle fliegen raus oder werden belegt.
• Das Gate: kein offener Punkt ohne Entscheidung, Testmatrix grün, dokumentierter Lauf, Supervision unterschrieben.
• Eine benannte Person bestätigt schriftlich, dass alle Punkte erfüllt sind.
• Jede Änderung am Prozess ändert im selben Zug Doku, Modell und Tests.
• Beispiel Anrede: Stammdaten statt Ableitung aus dem Vornamen, Pflichtfeld, die KI bekommt sie fertig geliefert.

Gebaut ist nicht betrieben. Bis zum Betrieb fehlen noch:

• die geprüfte Dokumentation,
• das Gate zur Produktion,
• das Beobachten und Nachjustieren im Betrieb.

Supervision: ein zweiter Mensch gleicht alles mit den Quellen ab

Bevor etwas live geht, gleicht ein zweiter Mensch jede Beschreibung mit den Quellen ab: mit dem Fachmodell, mit den Tests, mit dem dokumentierten Lauf. Die Prüffragen:

• Stimmt jede Angabe?
• Ist jeder Schritt eindeutig?
• Widerspricht sich der Text?
• Passt er zu den anderen Beschreibungen?
• Deckt er sich mit dem Fachmodell?
• Läuft der Ablauf folgerichtig?
• Kann man daraus bauen?

Was strittig ist, wird eskaliert: entschieden, datiert, begründet.

Kein Inhalt ohne Quelle

Jede Zeile der Dokumentation nennt ihre Quelle: Fachmodell, Test, Lauf-Protokoll oder Eskalationsentscheidung. Zeilen ohne Quelle fliegen raus oder werden belegt. Das ist dieselbe Regel wie in Grundprinzipien vor jedem Bau, hier als Dauerzustand.

Das Gate zur Produktion

Vor dem Livegang steht das Gate. Durch geht nur, was alles erfüllt:

• kein offener Punkt ohne Entscheidung,
• Testmatrix grün,
• dokumentierter Lauf vorhanden,
• Supervision unterschrieben.

Das Gate heißt: Eine benannte Person bestätigt schriftlich, dass alle Punkte erfüllt sind.

Lebende Dokumentation im Betrieb

Im Betrieb heißt es: beobachten, messen, nachjustieren. Jede Änderung am Prozess ändert im selben Zug Doku, Modell und Tests. Eine Doku, die nicht mitzieht, beschreibt einen Prozess, den es nicht mehr gibt. Wer ihr vertraut, baut auf falschen Angaben auf.

Beispiel: ein eskalierter Punkt

Die Supervision fand: „Die KI leitet die Anrede aus dem Vornamen ab." Strittig, weil Namen nicht eindeutig sind. Die Entscheidung: Die Anrede kommt aus den Stammdaten (den Grunddaten der Person), das Feld ist Pflicht, die KI bekommt sie fertig geliefert. Datiert, begründet, im Fachmodell nachgezogen, Test ergänzt.

Der ganze Weg

Damit steht der vollständige Pfad: von der Idee oder dem bestehenden Ablauf über Sprache und Fachmodell, über Design und Fehlerwege, über die gemessene und abgesicherte KI bis zum belegten Betrieb. Der Prozess am Ende ist dokumentiert, geprüft, belegt und betriebsfähig.

Der Leitfaden ist damit zu Ende. Der Prozess läuft weiter: beobachten, messen, nachjustieren.