Ein KI-Projekt kann bei der Übergabe gelingen und später trotzdem zum Problem werden — wenn niemand im Haus das System erklären, ändern oder reparieren kann. Welche Festlegungen das verhindern, und wann sie getroffen sein müssen.
Fähigkeit statt Abhängigkeit: KI bauen, die Ihr Team wirklich besitzt
Es gibt eine Art von KI-Projekt, die bei der Übergabe gelingt und später trotzdem Ärger macht: Das System läuft, die Abnahme ist sauber — aber im Haus kann niemand erklären, warum es entscheidet, wie es entscheidet, und niemand traut sich, etwas daran zu ändern. Solange nichts passiert, fällt das nicht auf. Es fällt auf, wenn sich eine fachliche Anforderung ändert oder etwas nicht mehr stimmt.
Das ist kein Vorwurf an die Beteiligten. Es ist meist eine Frage dessen, was im Projekt vereinbart war — und was nicht.
Warum das auch bei guter Zusammenarbeit passiert
Wer ein System baut und dafür bezahlt wird, kennt es am Ende besser als alle anderen. Das ist normal und zunächst kein Problem. Zum Problem wird es, wenn dieses Wissen nirgendwo anders landet.
Dazu braucht es keine Absicht. Es genügen Entscheidungen, die sich einzeln gut begründen lassen: eine eigene Abstraktion, weil sie an dieser Stelle eleganter ist; ein Stück Logik, das noch nicht dokumentiert wurde, weil der Termin drückt; ein Werkzeug, mit dem das Projektteam schnell ist. Jede für sich vertretbar — zusammen ergeben sie ein System, das ohne die Leute, die es gebaut haben, schwer zu betreiben ist.
Ein Anbieter hat dabei selten einen Anreiz, dem entgegenzuwirken, wenn niemand danach fragt. Das lässt sich vertraglich regeln, aber nur, wenn es vorher jemandem auffällt.
Was Eigentümerschaft voraussetzt
Verstehen, nicht nur bedienen können. Weiß im Haus jemand, warum das System so gebaut ist, wie es ist — und welche Alternativen verworfen wurden? Ein Team, das ein System bedienen, aber nicht durchdenken kann, ändert bei der ersten neuen Anforderung eher an der falschen Stelle.
Wissenstransfer im Bau, nicht danach. Wissenstransfer, der als Dokumentationsphase ans Projektende gehängt wird, erzeugt oft Dokumente, die niemand liest. Eingebaut in die laufende Arbeit — eigene Entwicklerinnen und Entwickler, die bei echten Entscheidungen dabei sind, statt eine fertige Lösung vorgeführt zu bekommen — entstehen Leute, die das System später erweitern können, weil sie es mitgebaut haben. Die Frage vor Projektstart lautet also: Wer aus dem eigenen Haus arbeitet mit, und ist diese Zeit eingeplant?
Verbreitete Werkzeuge statt Speziallösungen. Wo ein breit unterstützter Ansatz und ein spezieller etwa gleich gut funktionieren, spricht vieles für den verbreiteten: Er hält den Kreis derer offen, die das System später pflegen können. Die Frage dahinter ist eine Personalfrage — für welche Technik lassen sich in einigen Jahren noch Leute finden?
Festgehaltene Entscheidungen, nicht nur dokumentierter Code. Code-Dokumentation erklärt, was das System tut. Was fehlt, ist meist das Warum: Weshalb diese Architektur, welche Annahmen lagen zugrunde, was war bewusst ausgeschlossen? Genau das braucht jemand, der später beurteilen soll, ob die ursprüngliche Entscheidung noch trägt.
Ein benanntes Ende. Woran wäre erkennbar, dass Sie externe Unterstützung für den Betrieb nicht mehr brauchen? Wenn sich das vor Projektstart nicht beschreiben lässt, wird es hinterher auch nicht eintreten — und niemand merkt, dass es fehlt.
Woran man es im Projektalltag erkennt
Eigene Entwicklerinnen und Entwickler schreiben von früh an mit am Produktivcode, nicht erst nach einer „finalen“ Übergabe. Architekturentscheidungen werden mit Begründung festgehalten, damit jemand, der später dazukommt, das System versteht, ohne es sich zusammensuchen zu müssen. Und wo zwei Werkzeuge in Frage kommen, wird die Wahl damit begründet, wer sie später bedienen soll — nicht nur damit, welches im Projekt schneller ist.
Das kostet zunächst mehr, und zwar sichtbar: Mitarbeit bindet Leute, die anderswo gebraucht werden. Der Nutzen dagegen zeigt sich erst später und lässt sich schlecht beziffern. Deshalb verliert dieser Punkt in der Projektplanung regelmäßig — es sei denn, jemand hat ihn vorher zur Anforderung gemacht.
Was am Ende zählt
Das System ist das Sichtbare an einem KI-Projekt. Ob sich die Investition trägt, entscheidet sich meist an etwas anderem: ob im Haus jemand da ist, der es betreiben, ändern und beim nächsten Mal einen Teil davon selbst bauen kann.
Ob Sie das brauchen, hängt vom Fall ab. Bei einem abgegrenzten System, das jahrelang unverändert läuft, ist Betreuung von außen womöglich der günstigere Weg. Bei allem, was sich mit dem Geschäft weiterentwickeln soll, wird die Frage nach der eigenen Fähigkeit früher gestellt, als einem lieb ist — meist von jemandem, der etwas geändert haben will.