Technische Due Diligence für KI-gebaute Produkte

Was sich durch KI-Entwicklung ändert

Ob Seed-Investment, Übernahme eines Start-ups oder Kauf einer Softwarelösung durch ein Mittelstandsunternehmen: Immer häufiger ist das Produkt mit Lovable, Bolt, Base44, Cursor, Claude Code oder Codex entstanden. Das ist kein Makel. Es verschiebt aber das Risiko. Die Frage lautet weniger „Kann das Team bauen?“ als „Versteht und beherrscht jemand, was gebaut wurde?“.

Prüfbereiche und typische Fragen

So läuft eine Prüfung typischerweise ab

1. Datenraum und Zugänge: Lesezugriff auf Repository, Hosting, Monitoring und Ticketsystem.
2. Automatisierte Analysen: Abhängigkeiten, Lizenzen, bekannte Schwachstellen, Secrets in der Git-Historie, Testabdeckung.
3. Manuelle Durchsicht: Authentifizierung, Datenzugriff, Kernprozesse und Architektur – hier zeigen sich die Probleme, die Werkzeuge übersehen.
4. Gespräch mit dem Team: Entwicklungsprozess, Einsatz der KI-Werkzeuge, Wissensverteilung.
5. Bericht: Befunde nach Schwere, Aufwandsschätzung zur Behebung, Empfehlung für die ersten 90 Tage nach Abschluss.

Rechte, Lizenzen und Urheberrecht

Bei KI-generiertem Code ist die Rechtslage vielschichtig. Nach deutschem Urheberrecht setzt Schutz eine persönliche geistige Schöpfung voraus; wie weit rein maschinell erzeugter Code geschützt ist, ist nicht abschließend geklärt. Der eigentliche Wert liegt daher oft im Produkt, in Daten, Kundenbeziehungen und Know-how, weniger im Code allein. Technisch prüfbar ist:

• ob alle Beitragenden – auch externe Freelancer – ihre Nutzungsrechte vertraglich übertragen haben,
• welche Lizenzen die Abhängigkeiten tragen (eine Software-Stückliste, kurz SBOM, schafft Überblick; Copyleft-Lizenzen wie AGPL im Backend verdienen besondere Aufmerksamkeit),
• ob Domains, Cloud-, Store- und KI-Konten auf das Unternehmen laufen und nicht auf Privatpersonen.

Die rechtliche Bewertung gehört in die Legal Due Diligence. Dieser Text ist keine Rechtsberatung.

Sicherheit, Datenschutz und Bus-Faktor

In KI-gebautem Code finden sich wiederkehrende Muster: API-Schlüssel im Browser-Code, zu offene Zugriffsregeln (etwa fehlende Row Level Security bei Supabase), Endpunkte ohne Berechtigungsprüfung, ungeprüfte Eingaben in Prompts oder Datenbankabfragen. Für deutsche Käufer kommen DSGVO-Fragen hinzu: Wo werden personenbezogene Daten verarbeitet, gibt es Auftragsverarbeitungsverträge mit Hosting- und KI-Anbietern, und werden Daten an Anbieter außerhalb der EU übermittelt?

Wissen im Team

Lassen Sie sich eine aktuelle Änderung zeigen: Wie wurde sie formuliert, geprüft und ausgerollt? Kann das nur eine Person – oder niemand wirklich erklären, warum der Code so aussieht –, liegt der Bus-Faktor bei eins oder null. Gute Zeichen sind Anweisungsdateien wie AGENTS.md oder CLAUDE.md, Architekturnotizen, ein Review-Prozess und Tests in der CI-Pipeline.

Wichtig für die Bewertung: Viele Befunde lassen sich mit überschaubarem Aufwand beheben. Eine gute Due Diligence liefert deshalb nicht nur Risiken, sondern auch eine grobe Einschätzung, was die Beseitigung kostet – das ist für Kaufpreis und Investitionsplanung oft die relevantere Information.

So unterstützt jocapps

OnlineAppCreator ist unser B2B- und B2G-Delivery-Team seit 2014, ISO-zertifiziert in Deutschland und spezialisiert auf individuelle Apps, KI-Integration und die Produktivsetzung von KI-Prototypen. Weil das Team diese Härtung selbst durchführt, kann es eine Codebasis aus Sicht derer bewerten, die sie später betreiben und erweitern müssen – und bei Bedarf übernehmen. Hintergründe finden Sie unter Vom Vibe-Coding-Prototyp zur produktiven Anwendung und auf unserer Seite Prototyp zu Produktion.

Steht eine Entscheidung an, klären wir den Prüfumfang gern in einem kostenlosen 30-minütigen Erstgespräch.