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

Die technische Due Diligence eines KI-MVP prüft dieselben Ebenen wie jede Prüfung individueller Softwareentwicklung, darunter Code, Infrastruktur, Sicherheit, Abhängigkeiten und Teamrisiken. Hinzu kommen KI-spezifische Nachweise: Evaluierungsdesign, Prompt- und Modellkonfiguration, datenschutzgerechte Traces, Fehlerverhalten, Wirtschaftlichkeit pro Aufgabe sowie Rechte an Trainings- und Retrieval-Daten. Eine Demo und einige ausgewählte Ausgaben können die Leistung über die vorgesehene Arbeitslast nicht belegen. Ein versionierter Evaluierungsprozess mit repräsentativen Fällen und nachvollziehbaren Aufzeichnungen liefert prüfbare Nachweise.

Das ist eine Engineering-Checkliste, keine Rechts-, Investment- oder Assurance-Beratung. Nachweisanforderungen unterscheiden sich je nach Käufer, Investor, Branche und Transaktion. Wir haben regulatorische und normative Quellen am 2. September 2026 erneut geprüft.

Willst du vor deiner Runde eine unabhängige technische DD?

Kostenloses Beratungsgespräch buchen

Warum Nachweis, nicht Demo

Benchmark-Ergebnisse sind arbeitslastspezifisch, zeigen aber, warum eine Demo nicht genügt. Eine vorregistrierte Stanford-Studie mit mehr als 200 offenen juristischen Fragen meldete zum Testzeitpunkt falsche Informationen in mehr als 17% der Antworten von Lexis+ AI und Ask Practical Law AI sowie in mehr als 34% von Westlaw AI-Assisted Research. Diese Werte lassen sich weder auf eine andere Domäne noch auf heutige Produktversionen übertragen. Sie zeigen aber, dass eine spezialisierte Oberfläche allein kein Zuverlässigkeitsnachweis ist. Prüfer brauchen Messungen für die vorgesehene und vorhersehbare Nutzung des Produkts, mit dokumentierter Unsicherheit, Fehlerbeispielen und Grenzen. Siehe Zusammenfassung und Studie von Stanford.

KI-spezifische Prüfpunkte ergänzen

Diese Punkte erweitern die normale Software-Prüfung. Jeder nennt das Prüfziel und ein Warnsignal.

Ein Evaluierungs-Set. Eine versionierte Stichprobe aus vorgesehener Nutzung, Randfällen, nicht beantwortbaren, adversarialen und relevanten Gruppenfällen, mit Referenzlabels oder Rubriken und Stichprobenbegründung. Unit-Tests bleiben für deterministische Eigenschaften sinnvoll; beurteilte Ausgaben brauchen zusätzlich kalibrierte Bewertung. Warnsignal: nur ausgewählte Beispiele und keine Analyse von Abdeckung oder Unsicherheit.
Regressionsevaluierung. Führe die relevante Suite bei wesentlichen Änderungen an Prompt, Retrieval, Modell, Richtlinie oder Tools vor dem Release aus und überwache anschließend Produktionssignale. Frequenz und blockierende Regeln sollen der möglichen Schadensschwere entsprechen. Warnsignal: Verhaltensänderungen gehen ohne Vergleich zur freigegebenen Basis in Produktion.
Datenschutzgerechte Observability. Erfasse nur die Metadaten, die zur Untersuchung von Qualität, Sicherheit, Latenz und Kosten nötig sind. Rohe Prompts und Antworten können personenbezogene, vertrauliche oder privilegierte Daten enthalten, daher müssen Erfassung, Schwärzung, Zugriff und Löschung begründet sein. Warnsignal: entweder keine Rückverfolgbarkeit oder uneingeschränktes, unbefristetes Inhaltslogging.
Aufzeichnungen zu Prompt, Modell und Konfiguration. Versioniere Prompts, Retrieval-Einstellungen, Richtlinien, Tools und Modellkennungen. Ein Anbieter kann Verhalten trotz stabiler Kennung ändern; bewahre daher Evaluierungsergebnisse und Release-Metadaten auf, statt exakte Reproduzierbarkeit zu versprechen. Warnsignal: Für einen Vorfall lässt sich die eingesetzte Konfiguration nicht feststellen.
Fehlerbehandlung. Definiere Timeouts, begrenzte Retries, degradiertes Verhalten, menschliche Eskalation und Wiederherstellungsziele. Ein zweiter Anbieter ist eine Option, keine universelle Pflicht, und bringt eigene Kosten- und Konsistenzrisiken. Warnsignal: Eine externe Abhängigkeit kann ohne getesteten Nutzerpfad ausfallen.
Wirtschaftlichkeit pro Aufgabe. Miss Input-, Output-, Cache-, Tool-, Medien-, Retry- und menschliche Prüfkosten pro erfolgreicher Aufgabe, einschließlich der tatsächlichen Aufrufverteilung. Warnsignal: Margenprognosen nutzen einen idealen Einzelaufruf oder setzen unveränderte Anbieterpreise voraus.
Rechte und rechtmäßige Datennutzung. Dokumentiere Herkunft, Lizenz oder andere Rechtsgrundlage, vertragliche Einschränkungen, gegebenenfalls Einwilligungen, Löschpflichten und zulässige Trainings- oder Retrieval-Nutzung je Quelle. Warnsignal: ein ungeklärter gescrapter Korpus oder Daten ohne nachvollziehbare Herkunft.
Gemessene Fehlermodi und Kontrollen. Berichte aufgabenspezifische Fehlerkategorien, Schwere und Konfidenzintervalle und verknüpfe jedes wesentliche Risiko mit getesteten Kontrollen wie Retrieval, Validierung, Verweigerung oder Eskalation. Warnsignal: "RAG behebt Halluzinationen" oder nur eine Gesamtzahl ohne Fehleranalyse.
Modellwahl und Konzentrationsrisiko. Dokumentiere, warum Modell und Hosting Qualität, Datenschutz, Verfügbarkeit, Rechtsraum und Kostenanforderungen erfüllen. Teste Portabilität, wo sie zählt, statt anzunehmen, eine Abstraktionsschicht mache Anbieter austauschbar. Warnsignal: kein Ausstiegsplan für eine wesentliche Anbieter- oder Modelländerung.

Artefakte für den Evidence Room

Die genaue Anforderungsliste variiert. Diese Artefakte ermöglichen es Prüfern, Aussagen zu testen, ohne sich auf die Erinnerung eines Gründers zu verlassen. Ihr Vorhandensein garantiert weder Finanzierung noch Bewertung.

Artefakt	Warum die Due Diligence sich darum kümmert	Warnsignal, wenn es fehlt
Architekturdiagramm (datiert, benennt externe Abhängigkeiten)	Unterstützt die Prüfung von Vertrauensgrenzen, Skalierungsannahmen, Konzentration und Schlüsselpersonenrisiko	Wesentliche Abhängigkeiten oder Verantwortlichkeiten sind unklar
Datenflussdiagramm und Verarbeitungsinventar	Zeigt, welche Daten jede Partei aus welchem Grund, an welchem Ort und wie lange erhält	Personenbezogene oder vertrauliche Datenflüsse lassen sich nicht erklären
Evaluierungsberichte (versionierte Harness, Datensatz, Konfiguration und Ergebnisse)	Ermöglicht Prüfung von Abdeckung, Unsicherheit, Fehlern und Regressionsentscheidungen	Nur ausgewählte Beispiele oder eine unerklärte Gesamtzahl
Register für Modell, Prompt, Retrieval, Richtlinien und Tools	Verknüpft Release oder Vorfall mit der eingesetzten Konfiguration	Produktionsverhalten lässt sich keiner Konfiguration zuordnen
Runbook, Serviceziele und Incident Response	Zeigt Verantwortung, Erkennung, Eskalation, Wiederherstellung und Kommunikation	Fehlerpfade und Verantwortliche sind ungetestet
Aktuelles SBOM, Lizenzprüfung und Schwachstellenprozess	Unterstützt die Prüfung von Abhängigkeiten, Lizenzen und bekannten Schwachstellen	Abhängigkeiten und Behebungsverantwortung sind unbekannt
Rechtekette für IP und Daten	Zeigt Rechte an Mitarbeiter-, Gründer- und Auftragnehmerbeiträgen, Open Source, Modellen und Datensätzen nach Vertrag und Recht	Ein Kernwert hat keinen dokumentierten Eigentümer oder zulässigen Zweck
Risikobasierte Sicherheitsnachweise	Können Bedrohungsmodell, Secure-Development-Nachweise, Testberichte und relevante unabhängige Assurance umfassen	Aussagen sind nicht den Bedrohungen und Kontrollen des Systems zugeordnet

Daten, Datenschutz und Herkunft

Ordne bei EU-Deployments die DSGVO-Pflichten der tatsächlichen Verarbeitung und den Rollen der Parteien zu. Dazu können Verarbeitungsverzeichnisse, wo Artikel 30 sie verlangt, eine Rechtsgrundlage, eine Datenschutz-Folgenabschätzung nach Artikel 35 vor Verarbeitungen mit voraussichtlich hohem Risiko für Rechte und Freiheiten sowie Artikel-28-Bedingungen bei einem Auftragsverarbeiterverhältnis gehören. Ein Modellanbieter kann je nach Tatsachen und Vertragskette Verantwortlicher, Auftragsverarbeiter oder Unterauftragsverarbeiter sein. Die EDPB Opinion 28/2024 verlangt eine fallbezogene Anonymitätsprüfung und nimmt Anonymität nicht automatisch an. Nach dem geänderten EU AI Act enthält Artikel 50 mehrere rollen- und systemspezifische Transparenzpflichten, die überwiegend seit 2. August 2026 gelten. Hochrisiko-Regeln nach Anhang III gelten ab 2. Dezember 2027, produktintegrierte Hochrisiko-Regeln nach Anhang I ab 2. August 2028. Dokumentiere die tatsächlich anwendbare Klassifizierung, Rolle, Pflicht und Frist.

Fragen, die ein Prüfer testen kann

Ein Prüfer kann untersuchen, ob das Produkt von einem Modell oder Anbieter abhängt, ob behauptete Differenzierung belegt ist, ob Bruttomargen alle Inferenz- und Prüfkosten enthalten, ob Bindungsannahmen gemessen wurden und ob Evaluierungsergebnisse die Produktionsnutzung abbilden. Transaktionsdokumente, Bindungsvereinbarungen, Zusicherungen und Freistellungen sind dealspezifisch; eine generische Checkliste sagt solche Bedingungen nicht voraus. Sicherheits- und Eigentumsfragen bei KI-unterstütztem Code behandelt unser Beitrag zur Due Diligence bei Lovable, Bolt und Replit; Evaluierungsdesign steht in wann sich LLM-Evals lohnen.

"Eine Demo zeigt einen Pfad. Ein verantworteter Evaluierungsprozess zeigt, welche Arbeitslast gemessen wurde, wie oft sie scheitert und ob ein Release das Ergebnis verändert hat. Das ist ein Nachweis, den ein Prüfer untersuchen kann."

Häufig gestellte Fragen

Was ist technische Due Diligence für ein KI-Startup?

Eine abgegrenzte Prüfung von Code, Infrastruktur, Sicherheit, Abhängigkeiten, Datenflüssen, KI-Verhalten, Betriebsnachweisen und Teamrisiken. KI-spezifisch können Evaluierungsdesign, Aufzeichnungen zur Serving-Konfiguration, Wirtschaftlichkeit pro Aufgabe, Fehlerkontrollen, Datenschutz sowie Daten- und Modellrechte hinzukommen. Sie zertifiziert weder Skalierbarkeit noch rechtliche Sauberkeit.

Was könnte ein Prüfer bei einem KI-MVP untersuchen?

Die Anforderungen hängen von Transaktion und Branche ab. Häufig prüfbar sind Anbieterkonzentration, Nachweise für behauptete Differenzierung und Qualität, vollständige Inferenzkosten, Datenschutz- und Sicherheitskontrollen, gemessene Bindung, Incident Readiness sowie Rechte an Code, Modellen und Daten.

Welche Evaluierungsnachweise sollte ich vorbereiten?

Einen versionierten, repräsentativen Datensatz samt Rubrik, Stichprobenbegründung, an die Serving-Konfiguration gebundene Ergebnisse, Unsicherheits- und Gruppenanalyse, wesentliche Fehlerbeispiele, Freigabeschwellen, Regressionshistorie und Verknüpfungen zum Produktionsmonitoring. Menschliche Prüfung kann Teil der Methode sein; undokumentierte Stichproben sind nicht reproduzierbar.

Wie unterscheidet sich KI-Due-Diligence von normaler Software-Due-Diligence?

Sie behält die normale Prüfung von Code, Infrastruktur, Sicherheit, Abhängigkeiten und Team bei. Hinzu kommen variables Modellverhalten, Evaluierungsabdeckung, Prompt- und Serving-Konfiguration, Kosten pro Aufgabe, Konzentration bei externen Modellen, Fehlerbehandlung, datenschutzgerechte Traces sowie Rechte und Einschränkungen für Trainings- und Retrieval-Daten.

Brauche ich ein SBOM für die Due Diligence?

Es ist nützlich, wenn Softwareabhängigkeiten wesentlich sind. Halte ein aktuelles SBOM in einem standardisierten maschinenlesbaren Format, gleiche es mit dem Build ab und ergänze Lizenz- und Schwachstellenprozesse. Wenn die einschlägigen Regeln des Cyber Resilience Act ab 11. Dezember 2027 gelten, müssen erfasste Produkte ein SBOM in der technischen Dokumentation enthalten, in einem gängigen maschinenlesbaren Format und mindestens für Top-Level-Abhängigkeiten. Das erfasst nicht jedes KI-MVP oder jede Transaktion.

Was ist eine Rechtekette für IP und Daten?

Nachweise, wer Code, Datensätze, Modelle, Medien und andere Werte nach anwendbarem Recht und Vertrag besitzt oder nutzen darf. EU-Softwarerecht unterscheidet Programme von Arbeitnehmern von anderen Urheberschaftssituationen; Auftragnehmerverträge variieren. Prüfe Übertragungen oder Lizenzen, Open-Source-Pflichten, Modellbedingungen und Datensatzrechte mit Rechtsberatung, statt aus einer Rechnung Eigentum abzuleiten.

Wie wirkt sich die DSGVO auf die KI-Due-Diligence in der EU aus?

Ordne Artikel-30-Verzeichnisse, wo nötig, Rechtsgrundlagen und gegebenenfalls Artikel-9-Bedingungen, Artikel-35-DSFA bei voraussichtlich hohem Risiko, Betroffenenrechte, Übermittlungen, Aufbewahrung, Sicherheit und Artikel-28-Bedingungen zu. Die Rolle eines Modellanbieters hängt von Tatsachen und Verträgen ab. EDPB Opinion 28/2024 verlangt eine fallbezogene Prüfung vor der Annahme, ein Modell sei anonym.

Gilt der EU AI Act schon für mein MVP?

Das hängt von System und Rolle ab. Verbotsbestimmungen gelten, Pflichten für GPAI-Anbieter können gelten und Artikel 50 enthält mehrere spezifische Transparenzpflichten, überwiegend seit 2. August 2026. Hochrisiko-Regeln nach Anhang III gelten ab 2. Dezember 2027, produktintegrierte Regeln nach Anhang I ab 2. August 2028.

Ist technische Due Diligence in Österreich anders?

Die technische Methode ist ähnlich, doch anwendbare österreichische Unternehmens-, Arbeits-, IP-, Förder-, Steuer- und Regulierungsfragen brauchen lokale Prüfung. Bei öffentlicher Förderung legst du Fördervertrag, Nachweise förderfähiger Kosten, Berichtspflichten, Change-of-Control- und Rückzahlungsbedingungen vor, statt eine Standardauflage anzunehmen.

Wie zeige ich, dass mein KI-Produkt mehr als ein Modell-Wrapper ist?

Verlass dich nicht auf das Etikett. Zeig gemessene Nutzerergebnisse, Workflow- und Integrationstiefe, vorhandene lizenzierte oder proprietäre Werte, Betriebswissen, Bindungsnachweise, getestete Portabilität und Stückkosten bei realistischer Nutzung und unterschiedlichen Anbieterpreisen.

Fazit

Die technische Due Diligence eines KI-MVP ist breiter als ein generischer Code-Review. Die KI-spezifische Ebene soll Evaluierungsnachweise, Serving-Konfigurationen, Wirtschaftlichkeit pro Aufgabe, Fehlerkontrollen, Datenschutz sowie Daten- und Modellrechte mit den behaupteten Eigenschaften verbinden.

Bereite die Nachweise vor der Prüfung vor: Verantworte das Eval-Set, dokumentiere Releases, teste Fehlerpfade, berechne Kosten aus echten Traces, dokumentiere Rechte und halte Artefakte aktuell. Das macht Due Diligence nicht zur Formsache, aber Aussagen prüfbar und Lücken sichtbar, solange noch Zeit zur Behebung bleibt.

Willst du Eval-Set und Artefakte vor deiner Runde bereit haben?

Kostenloses Beratungsgespräch buchen

Primärquellen für diesen Diligence-Leitfaden

Diese Checkliste stützt sich auf öffentliche Referenzen zu KI-Risiko, sicherer Entwicklung, Datenschutz, Produktsicherheit und EU-Recht.