Software-Nachfolgeplanung für kleine KI-Anbieter

Ein Einkaufsteam verbringt drei Meetings damit, einen KI-Anbieter zu Datenresidenz und Trainingsrichtlinien zu befragen. Fast niemand stellt die Frage, die tatsächlich entscheidet, ob der Anbieter nächstes Jahr noch existiert: Was passiert mit dieser Software, wenn die Person, die sie gebaut hat, nicht mehr da ist.

Diese Lücke wird größer, nicht kleiner. KI-Werkzeuge lassen heute ein oder zwei Personen liefern, wofür früher ein Zehn-Personen-Team nötig war. Für Käufer ist das gut: schnellere Lieferung, geringere Kosten, ein System, das exakt für ihr Problem gebaut ist, statt eine konfigurierte Scheibe von etwas Generischem. Es bedeutet aber auch, dass ein wachsender Anteil der B2B-Software heute auf einem Bus-Faktor von eins läuft. Niemand versichert dieses Risiko, weil niemand danach fragt.

Das Konzentrationsrisiko, das niemand absichert

Vor zehn Jahren brauchte Software, die den Kernbetrieb eines Unternehmens tragen konnte, ein Unternehmen dahinter. Diese Korrelation ist zerbrochen. Ein einzelner Entwickler kann mit der aktuellen Generation von KI-Coding-Werkzeugen heute ein System bauen und ausliefern, für das ein Fünf-Personen-Team vor zehn Jahren zwei Quartale gebraucht hätte.

Das ist überhaupt erst das Argument dafür, mit kleinen, spezialisierten Anbietern zu arbeiten. Sie sind schneller, günstiger und bauen genau das, was das Geschäft braucht, statt das nächstgelegene konfigurierbare Modul einer Plattform, die für zehntausend andere Kunden entworfen wurde. Für einen Nischen-B2B-Betrieb ist diese Passgenauigkeit oft mehr wert als die Sicherheit eines bekannten Namens.

Was dabei still mitkommt, ist Konzentrationsrisiko. Wenn die Software den täglichen Betrieb eines Kunden trägt und eine Person das gesamte mentale Modell hält, wie sie funktioniert, hat dieser Betrieb jetzt eine Abhängigkeit ohne institutionelles Netz. Kein hypothetisches Szenario. Wird der Anbieter nicht mehr verfügbar, nicht mehr willens oder zahlungsunfähig, hat der Kunde funktionierende Software und keinen Weg, sie am Laufen zu halten.

Käufer fragen danach nicht, weil die Kategorie kaum einen Namen hat. Vendor-Security-Fragebögen sind ein etabliertes Genre. Vendor-Kontinuitäts-Fragebögen, für KI-Software von sehr kleinen Teams, gibt es meist noch gar nicht.

Große Plattformen verkaufen Kontinuität, nicht nur Software

Salesforce, HubSpot und Microsoft gewinnen selten einen Feature-für-Feature-Vergleich gegen ein System, das gezielt für den Workflow eines einzelnen Unternehmens gebaut wurde. Was sie gewinnen, ist die Gewissheit, dass der Anbieter in fünf Jahren noch Support-Tickets beantwortet, weil das Unternehmen dahinter tausende Mitarbeitende und eine Bilanz hat.

Diese Gewissheit ist nicht kostenlos. Der Käufer zahlt sie auf drei Wegen: ein Produkt, das auf den Durchschnittskunden zugeschnitten ist statt auf das eigene Problem, Integrationsarbeit, um ein generisches Tool um den eigenen Prozess zu biegen, und einen Preis, der Enterprise-Vertrieb und Support-Overhead widerspiegelt statt der Grenzkosten des Features, das tatsächlich genutzt wird.

Ein Boutique- oder Maßanfertigungs-KI-Anbieter kehrt diesen Tausch um. Bessere Passgenauigkeit, schnellere Lieferung, niedrigerer Preis. Was standardmäßig fehlt, ist das institutionelle Netz, weil keine Institution dahintersteht, nur eine Person oder ein kleines Team.

So gerahmt ist die Entscheidung nicht "sichere Plattform gegen riskanten Anbieter". Es ist ein Trade-off zwischen zwei verschiedenen Kostenarten: entweder Kontinuität, die man vielleicht nie braucht, im Voraus bezahlen, eingepreist in jedes Feature, oder für exakte Passgenauigkeit und Tempo bezahlen und Kontinuität separat einkaufen, bewusst dimensioniert auf das, was das Projekt tatsächlich braucht.

Was Kontinuität konkret bedeutet, in fünf Bausteinen

"Wir sorgen dafür, dass Sie abgesichert sind" ist keine Zusage. Es ist ein Gefühl, und Gefühle überstehen keine Risikoprüfung eines Kunden. Kontinuität, richtig gemacht, sind fünf konkrete Bausteine.

Technische Dokumentation. Architektur, Deployment-Schritte, Umgebungsvariablen, Datenbankschema, Recovery-Prozeduren, aktuell gehalten statt einmal beim Kickoff geschrieben und dann liegen gelassen. Jeder andere Baustein auf dieser Liste hängt von diesem ab. Escrow ohne aktuelle Dokumentation ist ein Code-Dump, den niemand betreiben kann.

Ein Backup-Entwickler-Vertrag. Ein geprüfter externer Entwickler, unter NDA, der den Code regelmäßig durchsieht, idealerweise ein Probe-Deployment gegen Staging fährt, damit sein Wissen aktuell bleibt, und vertraglich verpflichtet ist, innerhalb eines vereinbarten Zeitfensters einzusteigen, wenn ein Auslöseereignis eintritt. Dieser Baustein macht aus "wir haben den Code" ein "jemand kann ihn tatsächlich betreiben".

Software-Escrow. Quellcode, Dokumentation und Deployment-Skripte, hinterlegt bei einer neutralen dritten Stelle, freigegeben an den Kunden unter definierten Auslösebedingungen wie längerer Nichtverfügbarkeit oder Insolvenz. Das ist der formalste und teuerste Baustein, und der, den die meisten B2B-Käufer standardmäßig für vorhanden halten. Meist ist er es nicht, außer jemand fragt gezielt danach.

Schlüsselpersonenversicherung. Eine Police, die den Kunden oder das Projekt als Begünstigten benennt und auszahlt, wenn der Gründer oder Lead-Entwickler stirbt oder dauerhaft arbeitsunfähig wird. Sie stellt Kontinuität nicht selbst wieder her. Sie finanziert den Übergang und deckt die Kosten für einen Ersatzentwickler oder eine überstürzte Übergabe, während Backup-Entwickler-Vertrag und Dokumentation die operative Arbeit leisten.

Eine Kontinuitätsklausel im Vertrag. Der Baustein, der die anderen vier durchsetzbar macht statt nur versprochen. Er legt fest, was eine Übergabe auslöst, worauf der Kunde Anspruch hat und in welchem Zeitrahmen. Ohne ihn ist alles oben nur guter Wille.

Keiner dieser fünf Bausteine setzt einen großen Anbieter voraus. Sie setzen einen Anbieter voraus, der entschieden hat, bevor er gefragt wird, dass das Teil dessen ist, was er zusammen mit der Software verkauft.

Nicht jedes Projekt braucht den vollen Stack

Der Fehler in die andere Richtung ist, alle fünf Bausteine für jedes Projekt als Pflicht zu behandeln. Ein kleines internes Dashboard, das jemandem zwei Stunden pro Woche spart, braucht kein Software-Escrow. Die Kosten würden das abgedeckte Risiko übersteigen.

Auf zwei Fragen dimensionieren: Wie stark hängt der Betrieb des Kunden tatsächlich davon ab, dass das läuft, und wie schlimm ist eine Lücke, wenn es stoppt. Eine Marketing-Microsite oder ein internes Reporting-Tool braucht Dokumentation und eine Klausel, mehr nicht. Ein System, das den täglichen Betrieb eines Kunden trägt, das Lager, Schadensprozess oder Kundenservice lahmlegen würde, wenn es ausfällt, rechtfertigt den Backup-Entwickler-Vertrag und, ab einer gewissen Deal-Größe oder Kritikalität, auch Escrow und Versicherung.

Hier hört Kosten auch auf, der erwartete Einwand zu sein. Dokumentation ist vor allem Disziplin, kein Budgetposten. Ein Backup-Entwickler-Vertrag kostet ein paar tausend Euro im Jahr für vierteljährliche Reviews, in etwa derselben Größenordnung wie ein jährlicher Penetrationstest, den die meisten B2B-Softwarekäufer ohnehin anderswo einplanen. Escrow und Schlüsselpersonenversicherung kosten mehr, genau deshalb gehören sie auf die Systeme, bei denen der Schaden im Ernstfall das tatsächlich rechtfertigt, nicht standardmäßig auf alles.

Warum wir das einbauen, statt es nachträglich anzuflanschen

Wir haben kürzlich darüber geschrieben, KI-Vertrauen und EU-Souveränität als Produktentscheidungen zu behandeln statt als Kommunikation, weil sich der Käufer geändert hat und heute konkrete, prüfbare Fragen stellt statt einen Absatz auf der About-Seite zu akzeptieren. Kontinuität ist die operative Hälfte derselben Verschiebung. Souveränität bedeutet, strukturell nicht davon abhängig zu sein, wo das Modell eines Anbieters läuft oder was mit den eigenen Daten passiert. Kontinuität bedeutet, strukturell nicht davon abhängig zu sein, ob der Anbieter noch da ist.

Wir betreiben mehrere Kundensysteme, die klar in die Kategorie "würde einen Betrieb stoppen" fallen, darunter eine live laufende 24/7-Automatisierung, von der ein Kunde täglich abhängt. Bei Projekten dieser Größenordnung sind Dokumentation und eine Kontinuitätsklausel nicht etwas, das ein Kunde nach Vertragsunterzeichnung nachverhandeln muss. Sie sind Teil dessen, was vor dem ersten Sprint festgelegt wird.

Die ehrliche Version dieses Artikels lautet nicht "eine große Plattform beauftragen, um dieses Risiko zu vermeiden". Große Plattformen lösen Kontinuität, indem sie sie in alles einpreisen, ob das konkrete Projekt sie braucht oder nicht, und indem sie die Passgenauigkeit aufgeben, die ein maßgeschneidertes System überhaupt erst lohnenswert macht. Die bessere Antwort, für ein wirklich nischiges oder komplexes B2B-Problem, ist, den kleinen Anbieter vor Ihnen nach seinem Kontinuitätsplan zu fragen, bevor Sie unterschreiben, nicht nachdem etwas schiefgelaufen ist.

Was zu tun ist

Wenn Sie einen Boutique- oder Maßanfertigungs-KI-Anbieter prüfen, fragen Sie nach dessen Kontinuitätsplan, bevor Sie unterschreiben, nicht nachdem etwas schiefgelaufen ist. Fragen Sie konkret: Gibt es aktuelle Dokumentation, gibt es einen Backup-Entwickler, der einspringen könnte, und was garantiert der Vertrag tatsächlich, wenn der Anbieter nicht verfügbar ist.

Wenn Sie als Solo-Entwickler oder kleines Team B2B-Software bauen, ist die günstigste Version davon, mit aktuell gehaltener Dokumentation und einer Klausel in Ihrem Standardvertrag anzufangen. Fügen Sie einen Backup-Entwickler-Vertrag hinzu, sobald der Betrieb eines Kunden wirklich davon abhängt, dass das System läuft. Der Rest skaliert mit der Größe dessen, was Sie absichern.