Dort weitermachen, wo der letzte Artikel aufgehört hat
Im letzten Beitrag ging es um eine These:
Legacy bleibt.
KI kommt davor.
Nicht als Ersatz.
Sondern als adaptive Schicht.
Die Reaktion darauf ist fast immer dieselbe:
„Klingt gut. Aber wer hat das dann noch im Griff?“
Gute Frage.
Und vor allem: eine ehrliche.
Das neue Kontrollproblem
Klassisches BCM funktioniert gut, solange sich nichts bewegt.
Dokumentieren.
Bewerten.
Verantwortliche festlegen.
Ausfallszenarien definieren.
Funktioniert.
Solange Prozesse stabil sind.
Eine KI-Schicht, die Oberflächen dynamisch erzeugt, bricht genau diese Annahme.
Wenn der Agent heute anders arbeitet als gestern,
weil er gelernt hat,
entstehen sofort Fragen:
- War das gewollt?
- Wer hat das freigegeben?
- Und wenn etwas schiefläuft – wo genau?
Das ist kein Problem der Technologie.
Das ist ein Designproblem.
Und genau deshalb gehört BCM nicht ans Ende.
Sondern an den Anfang.
Governance: Kontrolle über das, was sich bewegt
Prozessbeherrschung bedeutet hier nicht, alles zu verhindern.
Es bedeutet, nachvollziehen zu können, was passiert.
Drei Dinge sind entscheidend:
1. Der Datenpfad ist die rote Linie
Was vorne eingegeben wird und hinten im Backend landet,
muss jederzeit nachvollziehbar sein.
Egal, wie flexibel die Oberfläche ist. Die Darstellung darf sich verändern. Die Datenstruktur nicht.
2. Verantwortung bleibt beim Menschen
Ein Agent kann optimieren. Aber nicht verantworten. Der Process Owner bleibt.
Aber seine Rolle verändert sich:
Nicht mehr: „Wie sieht die Maske aus?“
Sondern: „Welche Daten müssen in welcher Qualität ankommen?“
Und: „Welche Grenzen darf der Agent nicht überschreiten?“
3. Lernen braucht Regeln
Adaptive Systeme dürfen sich verbessern. Aber nicht unkontrolliert.
Es braucht klare Leitplanken:
- Wann darf optimiert werden?
- Wann wird eskaliert?
- Wann entscheidet ein Mensch?
Das ist keine Bürokratie. Das ist die Voraussetzung für Vertrauen.
Resilienz: Was passiert, wenn die Schicht wegfällt
Governance regelt den Normalbetrieb. Resilienz regelt den Ausfall. Und hier wird es interessant denn im klassischen BCM fällt das Backend aus.
Hier fällt etwas anderes aus:
Die Übersetzungsschicht zwischen Mensch und System.
Was dann?
Wenn das Backend stabil ist und die APIs sauber sind: beherrschbar.
Die Daten sind da. Die Logik ist da. Was fehlt, ist die Oberfläche.
Und das ist ein Komfortproblem. Kein Datenproblem.
Aber nur, wenn es bewusst so gebaut wurde.
Ein Prozess, der ausschließlich über die KI-Schicht erreichbar ist?
→ Risiko.
Ein Prozess mit Fallback ins Backend?
→ beherrschbar.
Klingt selbstverständlich.
Wird in der Praxis regelmäßig vergessen.
Resilienz ist eine Architekturentscheidung
Der klassische Fehler im BCM:
Erst bauen.
Dann Notfallplan schreiben.
Das funktioniert hier nicht mehr. Warum?
Weil Ausfälle anders aussehen:
- nicht mehr binär
- sondern graduell
- nicht sofort sichtbar
- sondern schleichend
Der Agent läuft. Aber vielleicht nicht mehr richtig.
Und genau das merkt man oft zu spät. Deshalb gehört Resilienz an den Anfang. Nicht ans Ende.
Welche Fragen müssen früh geklärt werden?
- Welche Prozesse sind geschäftskritisch?
- Welche davon laufen über die KI-Schicht?
- Wo braucht es einen direkten Backend-Zugang?
- Wo ist eine reduzierte Funktion akzeptabel – und wo nicht?
Das sind keine IT-Fragen. Das sind Businessfragen. Und sie gehören in den BCM-Prozess, bevor das erste Deployment stattfindet.
Fazit
KI-gestützte Architekturen sind nicht unkontrollierbar. Sie funktionieren nur nach anderen Regeln.
Was bleibt:
- transparente Datenpfade
- klare Verantwortlichkeiten
- definierte Grenzen
- Resilienz als Designprinzip
Was sich verändert: BCM sichert nicht mehr nur Systeme sondern auch die intelligente Schicht dazwischen.
Wer das mitdenkt, gewinnt mehr als Stabilität, er gewinnt Vertrauen und das ist am Ende die härteste Währung in jedem Transformationsprojekt.
