--- title: "Technische Due Diligence für KI-MVPs" canonical: https://wavect.io/de/blog/technical-due-diligence-ai-mvp/ language: de description: "Die KI-spezifische Due-Diligence-Checkliste vor der Finanzierung: Evals als Nachweis, Prompt- und Modellversionierung, Inferenzkosten und EU AI Act." image: "https://wavect.io/img/blog/headers/header_technical-due-diligence-ai-mvp.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min Lesezeit · 16. Juni 2026 Zuletzt geprüft 7. August 2026 [**Weiter**](/de/blog/llm-evaluation-cost-roi-production/) # Technische-Due-Diligence-Checkliste für KI-MVPs vor der Finanzierung TL;DR Die Due Diligence eines KI-MVP ergänzt den üblichen Software-Check um modellspezifische Nachweise: versionierte Evals, festgelegte Modelle und Prompts, Observability je Aufruf, Fallbacks, realistische Inferenzkosten und dokumentierte Datenrechte. Bereite Architekturdiagramm, Datenfluss, Eval-Berichte, Modell- und Prompt-Register, SBOM sowie IP-Rechte vor. Manuelle Stichproben reichen nicht. Die Transparenz nach Artikel 50 gilt seit 2. August 2026; Hochrisiko-Fristen hängen von Systemtyp und Rolle ab. Die technische Due Diligence eines KI-MVP prüft dieselben Ebenen wie jede Prüfung [individueller Softwareentwicklung](/de/services/software-development/) (Code, Infrastruktur, Sicherheit, Team) plus eine Reihe KI-spezifischer Punkte, die ein Generalist übersieht: Hast du ein Evaluierungs-Set und Regressions-Evals, sind Prompts und Modelle versioniert, protokollierst du jeden Modellaufruf, was passiert, wenn das Modell versagt, was kostet eine Inferenz wirklich, und hast du die Rechte an den Daten, auf denen du trainierst oder abrufst? Was ein finanzierbares KI-MVP von einer Demo unterscheidet, ist einzig der Nachweis. Investoren behandeln eine private, versionierte Eval-Suite zunehmend als Beleg dafür, dass deine KI funktioniert. "Wir testen das von Hand" reicht dafür nicht. Das ist die Checkliste, die du an dir selbst durchgehen solltest, 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 tückisch, wenn du um eine Verzögerung herumplanst, die noch gar nicht in Kraft 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 dein 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 dir grün oder rot; sie können nicht sagen, ob eine Antwort korrekt oder quellentreu 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. Eine schlechte Antwort, die du nicht rekonstruieren kannst, kannst du auch nicht debuggen. 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 dir 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. Deine Verfügbarkeit hängt jetzt an einer Drittanbieter-API. 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 "kannst du 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 deine Bewertung hält. Wenn sie nur im Kopf eines Gründers leben, wird jede Lücke zu einem Abschlag. | Artefakt | Warum die Due Diligence sich darum kümmert | Warnsignal, wenn es fehlt | | --- | --- | --- | | Architekturdiagramm (datiert, benennt externe Abhängigkeiten) | Prüft, ob es das 10-Fache verkraftet, und deckt Schlüsselpersonen-Risiko auf | Architektur lebt nur im Kopf eines Gründers | | Datenflussdiagramm (folgt den Daten, nicht den Services) | Zeigt, welche Dritten welche Daten berühren; DSGVO-Exposition | Unbekannte Datenschutz-Exposition, die der Investor erbt | | Eval-Berichte (versionierte Harness, Ergebnisse je Modell und Prompt) | Wie ein behaupteter KI-Burggraben verifiziert statt geglaubt wird | Kein objektiver Nachweis, dass das Modell funktioniert oder nicht regrediert | | Modell- und Prompt-Registry | Reproduzierbarkeit und Rollback jeder Ausgabe | Produktionsverhalten lässt sich nicht reproduzieren | | Runbook und Incident Response | Senkt Schlüsselpersonen-Abhängigkeit, grundlegender Compliance-Nachweis | Ungemessenes Ausfallrisiko | | SBOM (SPDX oder CycloneDX, in CI neu generiert) | Deckt Copyleft-Kontamination und ungepatchte CVEs auf | Unbekannte Lizenz- und Schwachstellen-Exposition | | IP-Chain-of-Title (Zuweisungen von Gründern und Auftragnehmern) | Der klassische Deal-Killer; eine Rechnung zu bezahlen überträgt kein IP | Ein ausgeschiedener Beitragender, der ein Kernmodul nie übertragen hat | | Sicherheitsbericht (aktueller Pentest, SOC 2 oder ISO 27001 falls zutreffend) | Standard im Jahr 2026, und es entriegelt Enterprise-Vertrieb | Unbekannte Breach-Exposition | ## Daten, Datenschutz und Herkunft Bei einem EU-KI-MVP werden Deals hier neu bepreist. Die Due Diligence prüft DSGVO-Verzeichnisse, Rechtsgrundlage, nötige Datenschutz-Folgenabschätzung und Auftragsverarbeitungsverträge. Eine Modell-API, die Nutzer-Prompts verarbeitet, ist Teil der Verarbeitungskette und braucht passende Verträge und Datenkontrollen. Die EDPB Opinion 28/2024 warnt zudem, dass ein mit personenbezogenen Daten trainiertes Modell nicht automatisch anonym ist. Nach dem aktuellen AI-Act-Zeitplan gilt Artikel-50-Transparenz ab 2. August 2026, eigenständiges Hochrisiko ab 2. Dezember 2027 und produktintegriertes Hochrisiko ab 2. August 2028. Ein belastbarer Data Room benennt, welches Datum und welche Rolle gelten. ## Was Investoren tatsächlich anmerken Von der Investoren- und Erwerberseite, und diese Quellen sind interessierte Parteien, also gewichte 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 rechne 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](/de/blog/lovable-bolt-replit-app-due-diligence/), und die Eval-Disziplin, die Punkt eins und zwei untermauert, steht in [wann sich LLM-Evals lohnen](/de/blog/llm-evaluation-cost-roi-production/). ![Kevin Riedl](/img/team/kevin.webp) "Eine Demo beweist, dass du einmal eine gute Antwort bekommst. Ein Eval-Set beweist, dass du konstant gute Antworten bekommst und merkst, 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." ## Häufig gestellte Fragen ### Was ist technische Due Diligence für ein KI-Startup? Eine Prüfung von Code, Infrastruktur, KI-Systemen, Datenflüssen und Team hinter einem KI-Produkt durch Investor oder Erwerber, die verifiziert, dass es funktioniert, skaliert, rechtlich sauber ist und keine Ein-Personen- oder Ein-Anbieter-Haftung darstellt. Für KI kommen Eval-Nachweise, Modell- und Prompt-Versionierung, Inferenz-Ökonomie und Datenrechte-Prüfungen hinzu, die generalistische Software-Due-Diligence überspringt. ### Was prüfen Investoren bei einem KI-MVP? Ob es mehr ist als ein dünner Wrapper um eine einzige Modell-API, seine Verteidigungsfähigkeit durch Daten- oder Workflow-Tiefe, die Bruttomarge nach Inferenzkosten, die Bindung und zunehmend private Eval-Ergebnisse, die Produktionsqualität statt einer Demo belegen. ### Welchen Eval-Nachweis brauche ich vor einer Runde? Einen versionierten Golden- und Regressions-Datensatz, bewertete Ergebnisse je Modell- und Prompt-Version, ein CI-Gate, das Regressionen blockiert, und eine gemessene Fehler- oder Halluzinationsrate auf einem domänenrepräsentativen Benchmark. "Wir testen manuell" reicht dafür nicht. ### Wie unterscheidet sich KI-Due-Diligence von normaler Software-Due-Diligence? Normale Due Diligence fragt, ob der Code gut ist und skaliert. KI-Due-Diligence fragt zusätzlich, ob du jede Modellausgabe reproduzieren kannst, ob du Modellaufrufe protokollierst und beobachtest, was eine Inferenz kostet, was passiert, wenn das Modell versagt, und ob du die Rechte an den Daten hast, auf denen du trainierst oder abrufst. ### Brauche ich ein SBOM für die Due Diligence? Zunehmend ja. Ein aktuelles SBOM in SPDX oder CycloneDX deckt Open-Source-Lizenzkonflikte und bekannte Schwachstellen auf, und sowohl M&A-Käufer als auch der EU Cyber Resilience Act erwarten inzwischen maschinenlesbare SBOMs. ### Was ist IP-Chain-of-Title und warum killt sie Deals? Der dokumentierte Beweis, dass das Unternehmen sein gesamtes IP besitzt. Das Urheberrecht liegt standardmäßig beim Autor, also überträgt die Bezahlung der Rechnung eines Auftragnehmers kein IP. Ein nicht übertragenes Co-Founder- oder Auftragnehmer-Modul ist ein klassischer Grund, warum Startups die Due Diligence vor der Series A nicht bestehen. ### Wie wirkt sich die DSGVO auf die KI-Due-Diligence in der EU aus? Die Due Diligence prüft dein Verarbeitungsverzeichnis (Artikel 30), eine Rechtsgrundlage für das Training mit personenbezogenen Daten (Artikel 6 und 9), eine DSFA für risikoreiche Verarbeitung (Artikel 35) und DPAs mit Sub-Auftragsverarbeitern, einschließlich der Modell-API, die die Prompts deiner Nutzer aufnimmt. Die EDPB Opinion 28/2024 warnt, dass trainierte Modelle nicht automatisch anonym sind. ### Gilt der EU AI Act schon für mein MVP? Teilweise. Verbote, KI-Kompetenz, GPAI-Pflichten und Artikel-50-Transparenz gelten bereits. Eigenständige Hochrisiko-Pflichten gelten ab 2. Dezember 2027 und produktintegrierte ab 2. August 2028. ### Technische Due Diligence in Österreich, gibt es Unterschiede? Die Substanz ist EU-Standard, DSGVO und der AI Act. Die österreichischen Besonderheiten sind eine aktiv durchsetzende Datenschutzbehörde, die KI keine Ausnahme gewährt, und aws- oder FFG-Förderauflagen auf deinem Cap Table, die ein späterer Investor sauber haben will. ### Wie beweise ich, dass mein KI-Produkt nicht nur ein GPT-Wrapper ist? Zeig Workflow-Tiefe und Wechselkosten durch Integrationen, proprietäre oder lizenzierte Daten und persistenten Kontext, eine Abstraktionsschicht, die den Anbieterwechsel erlaubt, und Stückkosten, die zu einem nicht subventionierten Modellpreis Bestand haben. ## Fazit Die technische Due Diligence eines KI-MVP ist kein generischer Code-Review mit dem Wort KI obendrauf. Die Ebenen, die über deine Runde entscheiden, sind die KI-spezifischen: Evals, die beweisen, dass das Ding funktioniert und nicht regrediert, Versionierung, die jede Ausgabe reproduzierbar macht, ehrliche Inferenz-Ökonomie und saubere Rechte an deinen Daten. Die gute Nachricht: All das lässt sich vor der Due Diligence billiger beheben, als es während ihr zu erklären. Bau das Eval-Set, pinne die Modelle, protokolliere die Aufrufe, lass die IP-Chain-of-Title unterschreiben und halte die Artefakte in einem Ordner bereit. Tu das, und die Due Diligence wird zur Formsache. Lass es weg, und jede Lücke wird zu einem Abschlag auf deine Bewertung. ## Das könnte dich auch interessieren.. [**Wann sich LLM-Evals lohnen** Die Eval-Disziplin, die Investoren jetzt erwarten: deterministische Checks, LLM-as-Judge und menschliche Kalibrierung, und wann die Harness ihre Kosten wert ist.](/de/blog/llm-evaluation-cost-roi-production/) [**KI-Enablement versus generische KI-Beratung** Die eine reicht dir ein Strategie-Deck. Die andere liefert ein funktionierendes Setup auf deiner Infrastruktur, das dein Team besitzt und betreiben kann.](/de/compare/ai-enablement-vs-generic-ai-consultancy/) ## Primärquellen für diesen Diligence-Leitfaden Wavects Evidence-Room-Checkliste ist an diesen öffentlichen Referenzen zu AI Risk und Secure Development ausgerichtet. - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [NIST Secure Software Development Framework](https://csrc.nist.gov/projects/ssdf) - [OWASP LLM Security Verification Standard](https://owasp.org/www-project-llm-verification-standard/) MVP-Validierung ## In diesem Cluster weiterlesen Nachfrage, Piloten und technische Machbarkeit evidenzbasiert prüfen, bevor das Budget wächst. [Mit dem Grundlagenartikel starten**B2B-SaaS-Idee in DACH validieren**](/de/blog/validate-b2b-saas-idea-dach/) - [YC-Bewerbung: Der technische Readiness-Check für dein Startup](/de/blog/yc-application-technical-readiness-checklist/) - [B2B-SaaS-Idee in DACH validieren](/de/blog/validate-b2b-saas-idea-dach/) - [Bezahlter Pilot vs. PoC vs. Design Partner: Was beweist Nachfrage?](/de/blog/paid-pilot-vs-poc-vs-design-partner/) - [Das MVP ist tot. Bau ein Minimum Credible Product.](/de/blog/minimum-credible-product/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min Lesezeit · 16. Juni 2026 Zuletzt geprüft 7. August 2026 [**Weiter**](/de/blog/llm-evaluation-cost-roi-production/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/technical-due-diligence-ai-mvp/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/de/blog/technical-due-diligence-ai-mvp/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Die Due Diligence eines KI-MVP ergänzt den üblichen Software-Check um modellspezifische Nachweise: versionierte Evals, festgelegte Modelle und Prompts, Observability je Aufruf, Fallbacks, realistische Inferenzkosten und dokumentierte Datenrechte. Bereite Architekturdiagramm, Datenfluss, Eval-Berichte, Modell- und Prompt-Register, SBOM sowie IP-Rechte vor. Manuelle Stichproben reichen nicht. Die Transparenz nach Artikel 50 gilt seit 2. August 2026; Hochrisiko-Fristen hängen von Systemtyp und Rolle ab.", "articleBody": " Blog-Übersicht/Produkt und MVP/MVP-Validierung Technische-Due-Diligence-Checkliste für KI-MVPs vor der Finanzierung TL;DR Die Due Diligence eines KI-MVP ergänzt den üblichen Software-Check um modellspezifische Nachweise: versionierte Evals, festgelegte Modelle und Prompts, Observability je Aufruf, Fallbacks, realistische Inferenzkosten und dokumentierte Datenrechte. Bereite Architekturdiagramm, Datenfluss, Eval-Berichte, Modell- und Prompt-Register, SBOM sowie IP-Rechte vor. Manuelle Stichproben reichen nicht. Die Transparenz nach Artikel 50 gilt seit 2. August 2026; Hochrisiko-Fristen hängen von Systemtyp und Rolle ab. Die technische Due Diligence eines KI-MVP prüft dieselben Ebenen wie jede Prüfung individueller Softwareentwicklung (Code, Infrastruktur, Sicherheit, Team) plus eine Reihe KI-spezifischer Punkte, die ein Generalist übersieht: Hast du ein Evaluierungs-Set und Regressions-Evals, sind Prompts und Modelle versioniert, protokollierst du jeden Modellaufruf, was passiert, wenn das Modell versagt, was kostet eine Inferenz wirklich, und hast du die Rechte an den Daten, auf denen du trainierst oder abrufst? Was ein finanzierbares KI-MVP von einer Demo unterscheidet, ist einzig der Nachweis. Investoren behandeln eine private, versionierte Eval-Suite zunehmend als Beleg dafür, dass deine KI funktioniert. \"Wir testen das von Hand\" reicht dafür nicht. Das ist die Checkliste, die du an dir selbst durchgehen solltest, 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 tückisch, wenn du um eine Verzögerung herumplanst, die noch gar nicht in Kraft 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 dein 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. Ein Evaluierungs-Set. Ein versionierter Golden-Datensatz plus ein Bewertungsraster. Unit-Tests sagen dir grün oder rot; sie können nicht sagen, ob eine Antwort korrekt oder quellentreu war. Warnsignal: \"Wir schauen uns die Ausgaben an\", kein Golden-Set, keine Zahlen. 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. Observability der Modellaufrufe. Tracing jedes Modellaufrufs, mit Token- und Kostenabrechnung sowie erfassten Prompts und Antworten. Eine schlechte Antwort, die du nicht rekonstruieren kannst, kannst du auch nicht debuggen. Warnsignal: \"Wir nutzen das Provider-Dashboard\" als die ganze Geschichte. Prompt- und Modellversionierung. Prompts sind versionierte Artefakte und das Modell ist festgepinnt, nicht als \"latest\" aufgerufen, das sich unter dir automatisch aktualisiert. Warnsignal: Prompts inline hartkodiert, Modell auf latest gealiast. Ein Fallback, wenn das Modell versagt. Retries, ein sekundäres Modell oder ein zweiter Provider, sanfte Degradation. Deine Verfügbarkeit hängt jetzt an einer Drittanbieter-API. Warnsignal: ein Provider, ein Modell, kein Timeout oder degradierter Pfad, sodass ein Ausfall eines Anbieters ein vollständiger Ausfall ist. 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. 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 \"kannst du belegen, woher jedes Datum stammt und dass es rechtmäßig beschafft wurde\". Warnsignal: gescrapte Daten unbekannter Herkunft, ein RAG-Korpus ohne Nutzungsrechte. Eine gemessene Halluzinationsrate plus Guardrails. Eine Fehlerrate auf einem Domänen-Benchmark, plus Retrieval-Grounding und", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "NIST AI Risk Management Framework", "url": "https://www.nist.gov/itl/ai-risk-management-framework" }, { "@type": "WebPage", "name": "NIST Secure Software Development Framework", "url": "https://csrc.nist.gov/projects/ssdf" }, { "@type": "WebPage", "name": "OWASP LLM Security Verification Standard", "url": "https://owasp.org/www-project-llm-verification-standard/" } ], "dateModified": "2026-08-07", "datePublished": "2026-06-16", "description": "Die Due Diligence eines KI-MVP ergänzt den üblichen Software-Check um modellspezifische Nachweise: versionierte Evals, festgelegte Modelle und Prompts, Observability je Aufruf, Fallbacks, realistische Inferenzkosten und dokumentierte Datenrechte. Bereite Architekturdiagramm, Datenfluss, Eval-Berichte, Modell- und Prompt-Register, SBOM sowie IP-Rechte vor. Manuelle Stichproben reichen nicht. Die Transparenz nach Artikel 50 gilt seit 2. August 2026; Hochrisiko-Fristen hängen von Systemtyp und Rolle ab.", "headline": "Technische Due Diligence für KI-MVPs vor der Finanzierung", "image": "https://wavect.io/img/blog/headers/header_technical-due-diligence-ai-mvp.svg", "inLanguage": "de", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/technical-due-diligence-ai-mvp/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/technical-due-diligence-ai-mvp/", "wordCount": 2014 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/product-mvp/", "name": "Produkt und MVP", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/mvp-validation/", "name": "MVP-Validierung", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/technical-due-diligence-ai-mvp/", "name": "Technische Due Diligence für KI-MVPs | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Eine Prüfung von Code, Infrastruktur, KI-Systemen, Datenflüssen und Team hinter einem KI-Produkt durch Investor oder Erwerber, die verifiziert, dass es funktioniert, skaliert, rechtlich sauber ist und keine Ein-Personen- oder Ein-Anbieter-Haftung darstellt. Für KI kommen Eval-Nachweise, Modell- und Prompt-Versionierung, Inferenz-Ökonomie und Datenrechte-Prüfungen hinzu, die generalistische Software-Due-Diligence überspringt." }, "name": "Was ist technische Due Diligence für ein KI-Startup?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Ob es mehr ist als ein dünner Wrapper um eine einzige Modell-API, seine Verteidigungsfähigkeit durch Daten- oder Workflow-Tiefe, die Bruttomarge nach Inferenzkosten, die Bindung und zunehmend private Eval-Ergebnisse, die Produktionsqualität statt einer Demo belegen." }, "name": "Was prüfen Investoren bei einem KI-MVP?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Einen versionierten Golden- und Regressions-Datensatz, bewertete Ergebnisse je Modell- und Prompt-Version, ein CI-Gate, das Regressionen blockiert, und eine gemessene Fehler- oder Halluzinationsrate auf einem domänenrepräsentativen Benchmark. \"Wir testen manuell\" reicht dafür nicht." }, "name": "Welchen Eval-Nachweis brauche ich vor einer Runde?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Normale Due Diligence fragt, ob der Code gut ist und skaliert. KI-Due-Diligence fragt zusätzlich, ob du jede Modellausgabe reproduzieren kannst, ob du Modellaufrufe protokollierst und beobachtest, was eine Inferenz kostet, was passiert, wenn das Modell versagt, und ob du die Rechte an den Daten hast, auf denen du trainierst oder abrufst." }, "name": "Wie unterscheidet sich KI-Due-Diligence von normaler Software-Due-Diligence?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Zunehmend ja. Ein aktuelles SBOM in SPDX oder CycloneDX deckt Open-Source-Lizenzkonflikte und bekannte Schwachstellen auf, und sowohl M&A-Käufer als auch der EU Cyber Resilience Act erwarten inzwischen maschinenlesbare SBOMs." }, "name": "Brauche ich ein SBOM für die Due Diligence?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Der dokumentierte Beweis, dass das Unternehmen sein gesamtes IP besitzt. Das Urheberrecht liegt standardmäßig beim Autor, also überträgt die Bezahlung der Rechnung eines Auftragnehmers kein IP. Ein nicht übertragenes Co-Founder- oder Auftragnehmer-Modul ist ein klassischer Grund, warum Startups die Due Diligence vor der Series A nicht bestehen." }, "name": "Was ist IP-Chain-of-Title und warum killt sie Deals?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Die Due Diligence prüft dein Verarbeitungsverzeichnis (Artikel 30), eine Rechtsgrundlage für das Training mit personenbezogenen Daten (Artikel 6 und 9), eine DSFA für risikoreiche Verarbeitung (Artikel 35) und DPAs mit Sub-Auftragsverarbeitern, einschließlich der Modell-API, die die Prompts deiner Nutzer aufnimmt. Die EDPB Opinion 28/2024 warnt, dass trainierte Modelle nicht automatisch anonym sind." }, "name": "Wie wirkt sich die DSGVO auf die KI-Due-Diligence in der EU aus?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Teilweise. Verbote, KI-Kompetenz, GPAI-Pflichten und Artikel-50-Transparenz gelten bereits. Eigenständige Hochrisiko-Pflichten gelten ab 2. Dezember 2027 und produktintegrierte ab 2. August 2028." }, "name": "Gilt der EU AI Act schon für mein MVP?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Die Substanz ist EU-Standard, DSGVO und der AI Act. Die österreichischen Besonderheiten sind eine aktiv durchsetzende Datenschutzbehörde, die KI keine Ausnahme gewährt, und aws- oder FFG-Förderauflagen auf deinem Cap Table, die ein späterer Investor sauber haben will." }, "name": "Technische Due Diligence in Österreich, gibt es Unterschiede?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Zeig Workflow-Tiefe und Wechselkosten durch Integrationen, proprietäre oder lizenzierte Daten und persistenten Kontext, eine Abstraktionsschicht, die den Anbieterwechsel erlaubt, und Stückkosten, die zu einem nicht subventionierten Modellpreis Bestand haben." }, "name": "Wie beweise ich, dass mein KI-Produkt nicht nur ein GPT-Wrapper ist?" } ] } ```