Prüfung und Übernahme einer mit KI entwickelten Anwendung
Ein Prototyp aus Lovable, Bolt, Replit, Cursor oder einem anderen KI-Werkzeug kann bereits Formulare speichern, Benutzer anmelden und in einer Präsentation überzeugen. Schwieriger wird es, sobald echte Kunden, Zahlungen, sensible Daten oder die dauerhafte Wartung hinzukommen.
Wir unterstellen nicht, dass KI-unterstützter Code grundsätzlich schlecht ist. Wir prüfen, ob sich die Anwendung reproduzierbar starten, kontrolliert bereitstellen, nach einem Ausfall wiederherstellen und ohne unerwartete Nebenwirkungen ändern lässt. Erst danach lässt sich entscheiden, ob gezielte Reparaturen, der Austausch eines Moduls oder eine neue Version sinnvoll sind.
Für das erste Gespräch müssen Sie weder Sprache noch Architektur kennen. Beschreiben Sie Zweck, funktionierende Teile und die Stelle, an der das Projekt nicht weiterkommt.
Wann lohnt sich die Prüfung?
Der Prototyp läuft, die Produktionsreife ist aber unklar
Eine Vorschau belegt nicht, dass Konfiguration, Datenzugriff, Fehlerbehandlung, Backups, Monitoring und Rückkehr zur vorherigen Version funktionieren.
Jede Änderung verursacht einen neuen Fehler
Eine Ansicht beschädigt die Anmeldung, ein Feld verteilt Änderungen über viele Dateien oder dieselbe Funktion entsteht mehrfach. Dahinter kann ein lokaler Fehler, aber auch fehlende Struktur stecken.
Die Anwendung verarbeitet bereits Nutzer, Daten oder Zahlungen
Dann zählen Rollen, serverseitige Rechte, Mandantentrennung, Webhook-Prüfung, Wiederholungen und abgebrochene Vorgänge – nicht nur die sichtbare Oberfläche.
Der bisherige Ersteller kann nicht weitermachen
Dokumentation, Deployment und Zugänge sind oft unvollständig. Vor einer Übernahme klären wir Repository, externe Dienste und Reproduzierbarkeit der Umgebung.
Ein funktionierender Bildschirm zeigt nicht das ganze Risiko
Bei einer Abonnement-Anwendung kann ein Nutzer Konto, Tarif und Zahlung erfolgreich durchlaufen. Offen bleibt dennoch, ob er ausschließlich eigene Daten sieht, ob der Server die Signatur des Zahlungsanbieters prüft, wie ein doppelt zugestelltes Ereignis behandelt wird und ob ein offengelegtes Geheimnis tatsächlich widerrufen wurde.
Dieses Beispiel ist hypothetisch. Es zeigt, warum wir neben dem Erfolgsfall auch fehlende Daten, Ausfälle externer Dienste, andere Rollen und wiederholte Vorgänge betrachten.
Ablauf der Analyse
- Projekt qualifizieren. Wir klären Zweck, Technologie, Umgebungen, Daten und Blockade und bestätigen, ob das Projekt in unseren Kompetenzbereich fällt.
- Sicheren Zugang vereinbaren. Repository, Konfiguration und technische Konten werden über einen passenden Weg bereitgestellt; Passwörter und Schlüssel gehören nicht in eine normale Nachricht. Lesezugriff reicht häufig für den Anfang.
- Bezahlte Analyse durchführen. Wir starten das Projekt kontrolliert, prüfen kritische Abläufe und dokumentieren Befunde mit Auswirkung und Nachweis.
- Entscheidungswege vorlegen. Wir zeigen, was bleiben kann, was dringend ist und was sich besser ersetzen lässt. Die Umsetzung erhält anschließend einen eigenen Umfang.
Was wird geprüft?
Bereich
Prüfung
Bedeutung
Setup und Abhängigkeiten
Reproduzierbarkeit, Dienste, Pakete und Konfiguration.
Zeigt, ob ein anderer Entwickler ohne Ratespiel arbeiten kann.
Anmeldung und Rechte
Authentifizierung, Rollen, serverseitige Operationen und Datentrennung.
Trennt versteckte Schaltflächen von echter Zugriffskontrolle.
Daten
Schema, Migrationen, Backups, Löschung, Importe und externe Übertragungen.
Macht Verlust, Vermischung und ungewollte Offenlegung sichtbar.
Integrationen und Zahlungen
Schlüssel, Webhooks, Signaturen, Wiederholungen, Limits und Fehler.
Zeigt Risiken durch Abbruch oder doppelte Ereignisse.
Code und Tests
Struktur, Duplikate, Kopplung, Fehlerbehandlung und kritische Tests.
Hilft Kosten und Risiko künftiger Änderungen einzuschätzen.
Deployment und Betrieb
Release, Backup, Protokolle, Monitoring und Rollback.
Entscheidet über eine verantwortliche Weiterentwicklung.
Ein internes Werkzeug braucht eine andere Prüftiefe als ein öffentlicher Dienst mit Zahlungen und Daten mehrerer Unternehmen. Wir wählen die Punkte, die die Entscheidung tatsächlich verändern.
Vier mögliche Ergebnisse
Behalten
Der Kern ist verständlich. Punktuelle Korrekturen, kritische Tests und ein geordnetes Deployment genügen.
Stabilisieren
Die Anwendung erfüllt ihren Zweck, doch neue Funktionen würden das Risiko erhöhen. Daten, Abhängigkeiten und Releases kommen zuerst.
Modul ersetzen
Der Großteil bleibt; Anmeldung, Zahlung oder Datenzugriff wird gezielt neu umgesetzt.
Neue Version bauen
Der Prototyp bestätigt den Ablauf, bietet aber keinen tragfähigen Wartungsweg. Bildschirme und Prozesswissen bleiben als Grundlage erhalten.
Ergebnis des Auftrags
Sie erhalten eine Beschreibung von Technologie und Abhängigkeiten, priorisierte Befunde mit Nachweisen, dringende Maßnahmen für Zugänge oder Daten, eine Liste erhaltbarer Teile sowie eine Empfehlung und einen ersten umsetzbaren Umfang. Das Material bleibt auch für einen anderen späteren Dienstleister nutzbar.
Ein einzelnes Problem mit hoher Auswirkung ist wichtiger als viele kosmetische Scanner-Hinweise. Automatische Werkzeuge finden bekannte Muster, Abhängigkeiten und versehentlich gespeicherte Geheimnisse; Geschäftslogik, Berechtigungen und Datenflüsse prüfen wir zusätzlich von Hand. Grundlage bilden unter anderem der OWASP-Leitfaden zur Codeprüfung und das NIST SSDF.
Grenzen und Einsatz von KI
Die Standardanalyse ist kein Sicherheitszertifikat, kein vollständiger Penetrationstest und keine Rechtsberatung. Wir können technische Datenflüsse für eine spätere Datenschutzprüfung benennen, ersetzen aber nicht die rechtliche Bewertung des Verantwortlichen. Auch die Technologie wird vor einer Übernahme qualifiziert; bei einem fremden Stack ist eine andere Spezialisierung ehrlicher als ein Experiment am laufenden System.
KI-Werkzeuge können bei der Suche nach Abhängigkeiten oder der Ordnung von Befunden helfen. Für die Schlussfolgerungen bleibt ein Mensch verantwortlich. Der Einsatz externer Modelle wird vereinbart, bevor ein Repository geteilt wird. Eine Prüfung ohne externes Modell ist möglich, wenn dieses Erfordernis zu Beginn genannt wird und die notwendige Umgebung verfügbar ist.
Häufige Fragen
Lohnt sich die Prüfung vor dem ersten öffentlichen Start?
Ja, besonders bevor echte Zahlungs-, Personen- oder Mandantendaten gespeichert werden.
Ist eine Prüfung ohne Repository möglich?
Eine erste Sichtprüfung ist möglich. Für eine belastbare Aussage zu Code, Abhängigkeiten und Deployment brauchen wir jedoch vereinbarten Zugriff auf die Quellen.
Können Sie die Entwicklung danach übernehmen?
Ja, wenn Technologie und Zustand zum vereinbarten Umfang passen. Reparatur, Stabilisierung oder Neubau bilden einen eigenen Auftrag.
Garantiert die Prüfung, dass keine Schwachstelle existiert?
Nein. Sie reduziert Unsicherheit im vereinbarten Umfang, kann aber nicht jede mögliche Schwachstelle oder jeden zukünftigen Fehler ausschließen.
Was gehört in die erste Nachricht?
Beschreiben Sie Zweck, Werkzeug oder Technologie, funktionierende Teile und aktuelle Blockade. Nennen Sie vorhandene Nutzer, Zahlungen, personenbezogene Daten und ein Repository. Dokumentation, Screenshots, Umfangstabellen oder ein ZIP-Archiv können beigefügt werden.
Das Formular nimmt bis zu fünf Dateien mit höchstens 5 MB je Datei und 10 MB insgesamt an. Dateiendung, Typ und Größe werden geprüft; vor dem Versand erfolgt ein ClamAV-Scan. Senden Sie keine Passwörter, API-Schlüssel, Produktionsdatenbank oder Kundendaten.
Ein größerer Auftrag kann in die Modernisierung oder Übernahme der Entwicklung übergehen. Der Beitrag Entwicklerwechsel bei einer bestehenden Anwendung enthält eine Vorbereitungsliste.
Technische Quellen
Projekt beschreiben
Wir prüfen Code, Datenzugriffe, Berechtigungen, Integrationen und Deployment von Anwendungen, die mit KI-Werkzeugen entstanden sind. Das Ergebnis ist ein nachvollziehbarer Plan für Reparatur, Übernahme oder Neubau.