Fähigkeit statt Abhängigkeit: KI bauen, die Ihr Team wirklich besitzt

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.

Markerzeichnung eines großen Würfels aus vielen kleinen modularen Blöcken, einer davon violett, an den Rändern lösen sich einzelne Blöcke

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.

Ähnliche Artikel

Weitere Insights zu Strategie und Betrieb

Markerzeichnung einer kleinen und einer größeren Plattform, verbunden durch eine Brücke, die in der Luft abbricht, mit einem violetten Block an der Bruchkante

ai adoption

Ein erfolgreicher Pilot ist noch keine erfolgreiche KI-Adoption

Nach einem erfolgreichen Pilotprojekt beginnt die eigentlich wichtige Arbeit: Skalierung und Implementierung. Welche Strecke dann noch vor einem liegt, und warum ihre Länge schon im Zuschnitt des Piloten festgelegt wird.

Insight lesen

Markerzeichnung eines ungeordneten Haufens von Blöcken, der sich von links nach rechts zu einer gleichmäßig ansteigenden Reihe ordnet, der erste geordnete Block violett

ai strategy

Vom Use-Case-Chaos zur KI-Roadmap: Priorisierung nach Wert und Machbarkeit

Die meisten Organisationen haben mehr KI-Ideen, als sie umsetzen können. Ein disziplinierter Ansatz aus Wert und Machbarkeit macht aus einem verstreuten Backlog eine sequenzierte Roadmap.

Insight lesen

Markerzeichnung dreier gestapelter Plattformen abnehmender Größe — unten ein dichtes Raster aus Blöcken, darüber wenige Strukturen und ein einzelner violetter Block auf der obersten Ebene

ai governance

Skalierbare KI-Governance – Daten, Modelle und Aufsicht

Governance wird oft als spät angeflanschte Launch-Bremse behandelt. Von Anfang an als Infrastruktur aufgebaut, ist sie das, was einer Organisation erlaubt, mehr KI-Systeme schneller und mit weniger Risiko einzusetzen.

Insight lesen

Markerzeichnung eines Schreibtischs von oben mit Laptop, Monitor, Tastatur, Telefon und Lampe in Grau und einer einzelnen violetten Kaffeetasse

change management

Adoption ist organisationaler Wandel, kein Software-Rollout

Ein Modell auszurollen ist ein technischer Meilenstein. Menschen dazu zu bringen, ihre Arbeitsweise wirklich daran auszurichten, ist das schwierigere, langwierigere und entscheidendere Projekt.

Insight lesen

Kommen wir ins Gespräch

Bauen Sie Ihre Intelligence Architecture.

Sagen Sie uns, wo Sie mit KI stehen. Wir sagen Ihnen offen, wo die Hebel liegen und wie Sie dorthin kommen.