Tech DD muss heute auch KI-Risiken prüfen

Architektur, Team, technische Schulden, Sicherheit, Skalierbarkeit, Schlüsselpersonenrisiko und die Glaubwürdigkeit der Roadmap bleiben der Kern jeder technischen Due Diligence. KI ersetzt das nicht. KI legt eine zusätzliche Schicht über jeden dieser Bereiche – und wer sie auslässt, bewertet weder das Risiko noch die Chance des Targets vollständig.

In den 50-plus technischen Due Diligences, die wir begleitet haben, war die häufigste Lücke nicht fehlendes Fachwissen zu klassischen Themen. Sie war, dass niemand im DD-Team die KI-spezifischen Fragen konsequent in den bestehenden Prüfrahmen integriert hat – sie tauchten entweder gar nicht auf oder als isolierter Zusatzabschnitt, den das Investment Committee überblättert.

Der Grund ist meist keine Nachlässigkeit, sondern eine Kompetenzlücke: Ein DD-Team mit klassischem Architektur- und Sicherheitshintergrund hat selten dieselbe Erfahrung mit Modellabhängigkeit oder Agentenbetrieb wie ein Team, das produktiv mit diesen Systemen arbeitet. Diese Erfahrung lässt sich nicht durch eine Checkliste ersetzen, sie muss aus eigener operativer Praxis kommen.

Wenn Kernfunktionen des Produkts über die API eines einzelnen Modellanbieters laufen, ist dieser Anbieter ein kritischer Lieferant – mit allem, was das für eine Diligence bedeutet: Wechselkosten, Preisrisiko, Roadmap-Risiko, Verfügbarkeit. Zu prüfen ist, ob eine Abstraktionsschicht existiert, die einen Anbieterwechsel ohne Neuentwicklung erlaubt, oder ob API-Aufrufe fest im Code verdrahtet sind.

Ebenso relevant: Was passiert vertraglich und technisch, wenn der Anbieter Preise ändert, ein Modell abkündigt oder den Dienst in der genutzten Region einstellt? Ein Produkt, dessen Unit Economics auf den heutigen Preisen eines einzelnen Anbieters beruhen, trägt ein Risiko, das in der klassischen Diligence keinen Platz hatte.

Ein Team, das diesen Punkt schon vor der Diligence gelöst hat, zeigt das meist von selbst: eine dünne Abstraktionsschicht, die Modellanbieter austauschbar macht, Verträge mit mehr als einem Anbieter, und eine Kostenüberwachung, die einen Preissprung des Anbieters sofort sichtbar macht. Fehlt das alles, heißt es nicht automatisch, dass das Produkt schlecht gebaut ist – aber es heißt, dass ein Risiko im Business Case bislang unbepreist geblieben ist.

Hat das Unternehmen Modelle auf Daten trainiert oder feinjustiert, an denen die Rechtslage unklar ist – Kundendaten ohne ausdrückliche Erlaubnis, Web-Scraping, von Auftragnehmern hochgeladene Inhalte? Diese Frage gehört heute in jede IP- und Datenschutzprüfung, weil sie sowohl Gewährleistungs- als auch Haftungsfragen im Kaufvertrag berührt.

Relevant ist auch die andere Richtung: Erlauben Kundenverträge und Lieferantenverträge des Targets überhaupt, Kundendaten zum Training oder als Kontext für KI-Systeme zu verwenden? Eine Klausel, die das ausschließt, aber in der Praxis ignoriert wird, ist ein Vertragsrisiko, das erst bei genauem Hinsehen sichtbar wird.

Diese Prüfung überschneidet sich mit der klassischen Datenschutzprüfung, ersetzt sie aber nicht. Eine DSGVO-konforme Auftragsverarbeitung sagt nichts darüber aus, ob dieselben Daten auch für KI-Training oder als Kontext für einen Agenten genutzt werden dürfen – das ist eine eigene Erlaubnisfrage, die im Kaufvertrag gesondert adressiert werden sollte.

Ein Team, das KI-generierten Code ohne ausreichende Review-Disziplin ausliefert, baut eine andere Art von technischer Schuld auf als ein Team mit klassischer Legacy-Last – aber sie ist genauso real. Prüfpunkte sind die Entwicklung der PR-Größe über die Zeit, die Review-Tiefe, die Testabdeckung und die Incident-Rate seit Einführung von KI-Entwicklungswerkzeugen.

Ein zusätzliches Signal: Existiert eine Eval- oder Regressionssuite speziell für KI-gestützte Funktionen, oder verlässt sich das Team auf manuelles Stichprobentesten? Fehlt eine solche Suite, ist die Aussage „das Feature funktioniert“ schwer zu verifizieren – ein Risiko für jede Aussage im Datenraum, die auf der Funktionsfähigkeit dieser Features beruht.

Agenten mit Schreibzugriff auf Produktionssysteme, Retrieval-Systeme, die versehentlich sensible Daten in eine Antwort einfließen lassen, und Prompt-Injection über Nutzereingaben oder externe Inhalte sind Angriffsflächen, die in einer klassischen Sicherheitsprüfung nicht vorkommen. Zu prüfen ist konkret, welche Aktionen ein Agent tatsächlich ausführen kann, wie diese Rechte begrenzt sind und ob es einen dokumentierten Vorfallprozess für Fehlverhalten von Agenten gibt.

Ein häufig übersehener Punkt: Viele dieser Integrationen laufen über Drittanbieter-Plugins oder externe Tools, die der Agent selbstständig aufrufen darf. Jede dieser Verbindungen ist ein zusätzlicher Vertrauensanker, der geprüft werden muss – nicht nur die Kernintegration mit dem Modellanbieter selbst.

Kann das Team KI tatsächlich operationalisieren, oder bleibt der Einsatz bei Pilotprojekten? Gibt es eine belastbare Toolchain, dokumentierte Prozesse und die organisatorischen Rollen, die ein produktiver Agentenbetrieb braucht? Diese Einschätzung beeinflusst direkt, wie glaubwürdig die KI-getriebenen Teile des Businessplans sind – ein Wachstumsplan, der auf Automatisierung setzt, ist nur so belastbar wie die Fähigkeit des Teams, sie tatsächlich umzusetzen. Wer mit dem agentischen Betriebsmodell vertraut ist, erkennt hier schnell, ob Owner, Freigabegrenzen und Audit-Trail für die vorhandenen Agenten überhaupt definiert sind, oder ob das Konstrukt beim ersten Nachfragen zusammenfällt.

Ein einfacher Test zeigt viel: Man bittet das Team, den Weg eines einzelnen produktiven Agenten von der Idee bis zum aktuellen Betrieb nachzuzeichnen – wer hat entschieden, wer betreibt ihn heute, welche Kennzahl zeigt seine Qualität. Ein Team mit echter Agentic Readiness beantwortet das in Minuten. Ein Team, das nur Pilotprojekte hat, verliert sich in der Beschreibung der Technologie, ohne zum Betrieb zu kommen.

Eine Tech DD, die nur nach Risiken sucht, liefert ein unvollständiges Bild. Genauso wichtig ist eine nüchterne Einschätzung der KI-Chancen: Welche der im Businessplan genannten Automatisierungspotenziale sind mit der vorhandenen Datenlage und Systemlandschaft tatsächlich erreichbar, und welche setzen eine Systemablösung oder Datenbereinigung voraus, die im Plan nicht vorkommt?

Diese Einschätzung verhindert zwei entgegengesetzte Fehler: dass ein Käufer ein reales KI-Potenzial übersieht, weil das Managementteam es nicht artikuliert hat, oder dass er einen zu optimistischen KI-getriebenen Wachstumsplan ungeprüft in seine Bewertung übernimmt. Beides ist in der Praxis häufiger, als die reine Risikoprüfung vermuten lässt.

Die Ergebnisse dieser Prüfpunkte gehören in den Bericht und in die Vertragsgestaltung. Modellabhängigkeit und Datenherkunft sind klassische Themen für Gewährleistungen und Freistellungen im Kaufvertrag. Fehlende Agentic Readiness ist ein Argument für einen Teil des Kaufpreises, der an das Erreichen definierter Meilensteine nach Closing gekoppelt wird, statt vollständig bei Signing fällig zu sein.

Für den 100-Tage-Plan nach Closing sind dieselben Befunde der Ausgangspunkt: Ein Risiko, das im DD-Bericht als „mittelfristig zu beheben“ markiert wurde, gehört in die ersten Wochen der Integration, nicht in eine spätere Roadmap-Diskussion, die im Tagesgeschäft leicht wieder aus dem Blick gerät.

Diese Prüfpunkte gehören in jedes klassische Kapitel als zusätzlicher Abschnitt: Das Architekturkapitel bekommt einen Abschnitt zur Modellabhängigkeit, das Sicherheitskapitel einen Abschnitt zu LLM-Angriffsflächen, das Teamkapitel eine Einschätzung der Agentic Readiness. So bleibt die Bewertung im gewohnten Format für das Investment Committee, ohne die neuen Risiken zu verstecken.