Technische-Due-Diligence-Checkliste für KI-MVPs vor der Finanzierung

Die technische Due Diligence eines KI-MVP prüft dieselben Ebenen wie jede Software-Prüfung (Code, Infrastruktur, Sicherheit, Team) plus eine Reihe KI-spezifischer Punkte, die ein Generalist übersieht: Haben Sie ein Evaluierungs-Set und Regressions-Evals, sind Prompts und Modelle versioniert, protokollieren Sie jeden Modellaufruf, was passiert, wenn das Modell versagt, was kostet eine Inferenz tatsächlich, und haben Sie die Rechte an den Daten, auf denen Sie trainieren oder abrufen. Das Einzige, was ein finanzierbares KI-MVP von einer Demo unterscheidet, ist der Nachweis. Investoren behandeln eine private, versionierte Eval-Suite zunehmend als Beweis dafür, dass Ihre KI funktioniert. "Wir testen das von Hand" reicht dafür nicht. Das ist die Checkliste, die Sie an sich selbst durchgehen sollten, bevor andere es tun.

Das ist eine Engineering-Sicht für Gründer, mit den Fragen der Investoren explizit gemacht. Die regulatorischen Termine sind auf dem Stand von Mitte 2026; einer davon ist besonders eine Falle, wenn Sie um eine Verzögerung herumplanen, die noch nicht eingetreten ist, weiter unten markiert.

Warum Nachweis, nicht Demo

Zwei unabhängige Befunde setzen den Maßstab. Eine Stanford-Studie zu eigens entwickelten Legal-AI-Tools, also der Sorte, die als präzise verkauft wird, maß bei manchen Produkten dennoch Halluzinationen bei mehr als 17 Prozent der Benchmark-Anfragen und bei anderen bei mehr als 34 Prozent. Und ein 2025 vielzitierter, am MIT angesiedelter Bericht fand heraus, dass rund 95 Prozent der unternehmensseitigen generativen KI-Pilotprojekte keine messbare Wirkung auf das Geschäftsergebnis erzielten. Die Lehre für einen Gründer, der Geld einsammelt, ist unmissverständlich: Eine funktionierende Demo beweist fast nichts, und der Investor weiß das. Was eine Runde bewegt, ist der gemessene Nachweis, dass Ihr System funktioniert, nicht regrediert und auch im Maßstab wirtschaftlich und rechtlich solide ist.

Die KI-spezifischen Punkte, die ein Generalist übersieht

Das ist der Kern dieses Beitrags und der Teil, den eine generische Software-Prüfung überspringt. Zu jedem Punkt: was zu prüfen ist, warum es zählt und das Warnsignal.

1. Ein Evaluierungs-Set. Ein versionierter Golden-Datensatz plus ein Bewertungsraster. Unit-Tests sagen Ihnen grün oder rot; sie können nicht sagen, ob eine Antwort korrekt oder treu zur Quelle war. Warnsignal: "Wir schauen uns die Ausgaben an", kein Golden-Set, keine Zahlen.
2. Regressions-Evals als CI-Gate. Die Eval-Suite läuft bei jeder Prompt- oder Modelländerung vor dem Deploy. Derselbe Prompt liefert eine andere Ausgabe, wenn sich die Modellversion oder die Eingabe verschiebt, und ein Fix für einen Fall bricht stillschweigend einen anderen. Warnsignal: Prompt-Änderungen gehen direkt in die Produktion.
3. Observability der Modellaufrufe. Tracing jedes Modellaufrufs, mit Token- und Kostenabrechnung sowie erfassten Prompts und Antworten. Sie können eine schlechte Antwort nicht debuggen, die Sie nicht rekonstruieren können. Warnsignal: "Wir nutzen das Provider-Dashboard" als die ganze Geschichte.
4. Prompt- und Modellversionierung. Prompts sind versionierte Artefakte und das Modell ist festgepinnt, nicht als "latest" aufgerufen, das sich unter Ihnen automatisch aktualisiert. Warnsignal: Prompts inline hartkodiert, Modell auf latest gealiast.
5. Ein Fallback, wenn das Modell versagt. Retries, ein sekundäres Modell oder ein zweiter Provider, sanfte Degradation. Ihre Verfügbarkeit ist jetzt durch eine Drittanbieter-API begrenzt. Warnsignal: ein Provider, ein Modell, kein Timeout oder degradierter Pfad, sodass ein Ausfall eines Anbieters ein vollständiger Ausfall ist.
6. Stückkosten pro Inferenz. Kosten pro Aufruf modelliert, dann pro Aktion, dann in die Bruttomarge. Agentische Abläufe fächern eine Aktion in Hunderte Aufrufe auf. Warnsignal: keine Kennzahl für Kosten pro Aktion und eine Marge, die als "SaaS-ähnlich" angenommen wird.
7. Rechte an den Trainings- und Abruf-Daten. Dokumentierte Herkunft und eine Lizenz oder Erlaubnis pro Quelle. Die Frage ist nicht mehr "ist es Fair Use", sondern "können Sie belegen, woher jedes Datum stammt und dass es rechtmäßig beschafft wurde". Warnsignal: gescrapte Daten unbekannter Herkunft, ein RAG-Korpus ohne Nutzungsrechte.
8. Eine gemessene Halluzinationsrate plus Guardrails. Eine Fehlerrate auf einem Domänen-Benchmark, plus Retrieval-Grounding und Ausgabevalidierung. Warnsignal: keine gemessene Rate und "RAG behebt Halluzinationen", als wäre es gelöst.
9. Modellwahl und Lock-in. Eine Begründung für proprietäre API versus offene Gewichte und eine Abstraktionsschicht, die den Anbieterwechsel erlaubt. Warnsignal: fest an das SDK eines einzigen Anbieters gekoppelt, mit einer Ökonomie, die nur zum heutigen subventionierten Preis funktioniert.

Die Übergabe-Artefakte, die ein finanzierbares KI-MVP bereithält

Wenn diese existieren, ist die Due Diligence schnell und Ihre Bewertung hält. Wenn sie nur im Kopf eines Gründers leben, wird jede Lücke zu einem Abschlag.

Daten, Datenschutz und Herkunft

Bei einem EU-KI-MVP werden hier Deals neu bepreist. Die Due Diligence prüft Ihr Verzeichnis von Verarbeitungstätigkeiten (DSGVO Artikel 30), eine Rechtsgrundlage für das Training mit personenbezogenen Daten (Artikel 6 und 9, mit einer dokumentierten Abwägung des berechtigten Interesses), eine Datenschutz-Folgenabschätzung vor risikoreicher Verarbeitung (Artikel 35) und Auftragsverarbeitungsverträge mit Sub-Auftragsverarbeitern. Beachten Sie eines, was Gründer übersehen: Eine Modell-API, die die Prompts Ihrer Nutzer aufnimmt, ist ein Sub-Auftragsverarbeiter, braucht also einen DPA und eine No-Training-, Zero-Retention-Konfiguration, nicht Consumer-Bedingungen. Die EDPB Opinion 28/2024 warnt zudem, dass ein auf personenbezogenen Daten trainiertes Modell nicht automatisch anonym ist, sodass unrechtmäßige Trainingsdaten das eingesetzte Produkt kontaminieren können. Beim EU AI Act ist das geltende verbindliche Datum für die meisten Hochrisiko- und Transparenzpflichten der 2. August 2026. Ein Vorschlag zur Verzögerung kursierte 2026, ist aber nicht in Kraft, und ein Compliance-Plan, der auf die Verzögerung setzt, ist selbst ein Warnsignal.

Was Investoren tatsächlich anmerken

Von der Investoren- und Erwerberseite, und diese Quellen sind interessierte Parteien, also gewichten Sie sie entsprechend, lauten die wiederkehrenden Anmerkungen: ein dünner Wrapper um ein einzelnes Modell ohne Workflow-Tiefe; ein schwacher Burggraben (die dauerhaften sind heute proprietäre oder lizenzierte Daten, Integrationen und persistenter Kontext, nicht das Basismodell); Bruttomarge nach Inferenzkosten, da Inferenz reale variable Kosten sind, die die SaaS-Margen-Annahme brechen; fragile Bindung bei niedrigen Wechselkosten; und zunehmend das Fehlen privater kontinuierlicher Evals. Speziell bei einer Übernahme rechnen Sie mit Bindungsklauseln für zentrale KI-Engineers und mit Garantien, die an Zusicherungen zur Datenherkunft gekoppelt sind. Der Vibe-Coding-Aspekt davon, Sicherheit, IP-Eigentum und was ein Erwerber bei KI-erzeugtem Code prüft, ist eine eigene Checkliste in unserem Beitrag zur Due Diligence bei Lovable, Bolt und Replit, und die Eval-Disziplin, die Punkt eins und zwei untermauert, steht in wann sich LLM-Evals lohnen.

"Eine Demo beweist, dass Sie einmal eine gute Antwort bekommen. Ein Eval-Set beweist, dass Sie konstant gute Antworten bekommen und merken, wenn das aufhört. Investoren ließen sich vom Ersten nicht mehr beeindrucken und begannen, das Zweite zu verlangen. Diese Verschiebung ist das ganze Spiel in der KI-Due-Diligence."