KI-generierte Software für Berufsgeheimnisträger betreiben

Eine KI-generierte Anwendung soll mit Mandanten-, Patienten- oder anderen Berufsgeheimnissen produktiv gehen? Betriebsmodell unverbindlich einordnen.

Werkzeuge wie Lovable, Bolt, Replit und KI-Coding-Assistenten verkürzen den Weg vom Konzept zu einem funktionierenden Prototyp. Ein sichtbares Frontend und ein erfolgreicher Login sind aber noch kein Nachweis für Produktionsreife. Das gilt für jede Software und wird besonders wichtig, wenn Berufsgeheimnisse verarbeitet werden.

Die richtige Reaktion ist nicht, KI-generierten Code pauschal abzulehnen. Er sollte wie übernommene Individualsoftware behandelt werden: Bestand aufnehmen, Risiken prüfen, Zielarchitektur festlegen, Änderungen reproduzierbar machen und den laufenden Betrieb klar zuordnen.

Warum der Prototyp und das Produkt zwei verschiedene Zustände sind

Ein Prototyp optimiert typischerweise auf Geschwindigkeit:

• eine Person arbeitet direkt gegen die Produktionsdatenbank
• Vorschau und Produktion teilen sich Umgebungsvariablen
• Authentifizierung funktioniert, aber Rollen sind noch unvollständig
• Fehler werden in der Browserkonsole statt in einem Monitoring sichtbar
• Schemaänderungen erfolgen manuell
• Backups sind vorhanden, aber nicht getestet
• externe Dienste wurden nach Komfort statt nach Datenfluss ausgewählt

Ein Produktivsystem braucht dagegen reproduzierbare Deployments, kontrollierte Änderungen, belastbare Berechtigungen und einen Wiederherstellungsweg. Bei Berufsgeheimnissen kommt die Frage hinzu, welche Parteien und Personen an der Verarbeitung mitwirken.

Schritt 1: Eigentum und vollständigen Bestand sichern

Vor jeder Migration muss geklärt sein, welche Bestandteile tatsächlich verfügbar sind:

Der Codeexport allein genügt nicht, wenn Daten, Authentifizierung oder Storage weiterhin an der ursprünglichen Plattform hängen. Der tatsächliche Exit ist erst möglich, wenn alle Laufzeitabhängigkeiten verstanden sind.

Schritt 2: Datenflüsse und externe Dienste erfassen

KI-Assistenten fügen Bibliotheken und Dienste oft pragmatisch hinzu. Prüfen Sie im Repository und im laufenden System:

• Analytics- und Telemetrie-SDKs
• Error Tracking und Session Replay
• externe Schriftarten, CDNs und Skripte
• E-Mail-, SMS- und Benachrichtigungsanbieter
• KI- und Embedding-APIs
• Datei- und Bildverarbeitung
• Zahlungs-, Signatur- oder Kartenservices
• Webhooks und Automatisierungsplattformen

Für jeden Dienst ist zu klären, welche Daten übertragen werden. Eine Fehlermeldung kann einen vollständigen Request enthalten, ein Session-Replay kann Inhalte aus Formularen erfassen und ein KI-Prompt kann Dokumenttext weitergeben.

Schritt 3: Berechtigungen serverseitig durchsetzen

Eine ausgeblendete Schaltfläche ist keine Zugriffskontrolle. Die Prüfung muss an der serverseitigen Vertrauensgrenze erfolgen:

• Kann Nutzer A Datensätze von Nutzer B über direkte API-Aufrufe lesen?
• Werden Rollen im Backend oder nur im Frontend geprüft?
• Sind administrative Endpunkte separat geschützt?
• Lassen sich Objekt-IDs erraten oder manipulieren?
• Sind Datei-Downloads an dieselben Rechte wie Metadaten gebunden?
• Trennen Datenbankrichtlinien Mandanten und Rollen zuverlässig?

Bei Supabase ist Row Level Security ein zentraler Teil dieser Grenze. RLS ersetzt trotzdem nicht jede Anwendungsprüfung: Service-Keys, Functions und serverseitige Komponenten können andere Berechtigungen besitzen.

Schritt 4: Entwicklungs- und Produktionsumgebung trennen

Mindestens Entwicklung und Produktion sollten getrennte Daten, Secrets und Deployments besitzen. Für geschäftskritische Anwendungen ist zusätzlich eine Staging-Umgebung sinnvoll.

Das schränkt die KI-gestützte Weiterentwicklung nicht ein. Das Kundenteam kann weiterhin mit Lovable, Bolt, Replit, einem lokalen Editor oder anderen KI-Coding-Werkzeugen arbeiten. Änderungen werden in das vereinbarte Git-Repository gepusht. Die von WZ-IT betriebene Delivery-Strecke baut daraus automatisch ein Artefakt und rollt es je nach Modell zunächst nach Staging oder direkt in die Zielumgebung aus. Produktion kann eine zusätzliche Prüfung oder Freigabe verlangen.

Ein kontrollierter Weg sieht beispielsweise so aus:

1. Änderung im Repository prüfen.
2. Abhängigkeiten und Tests ausführen.
3. reproduzierbares Artefakt oder Container-Image bauen.
4. Datenbankmigration gegen eine Testumgebung prüfen.
5. Deployment freigeben und protokollieren.
6. Funktion, Logs und Metriken nach dem Rollout kontrollieren.
7. Rückfallweg für Anwendung und Datenbank bereithalten.

Direkte Änderungen in Produktion erschweren nicht nur Fehlerbehebung. Sie machen auch unklar, welcher Code zu einem bestimmten Datenstand gehört.

Schritt 5: Anwendung und Infrastruktur gemeinsam absichern

Die Verantwortung endet nicht an der Containergrenze. Zum Betriebsumfang gehören je nach Anwendung:

• private Managementzugänge und MFA
• Netzwerksegmentierung und minimale öffentliche Endpunkte
• Patch- und Updateprozess für Host, Plattform und Anwendung
• Monitoring für Verfügbarkeit, Fehler, Kapazität und Jobs
• Schutz vor Brute Force, Missbrauch und unkontrollierten Uploads
• Backup von Datenbank, Dateien, Konfiguration und Secrets
• Wiederherstellungstest mit dokumentiertem Ergebnis
• Incident- und Kommunikationsweg

Für den Anwendungsreview bieten OWASP ASVS und der OWASP Top 10 strukturierte Prüfpunkte. Sie ersetzen keine anwendungsspezifische Bedrohungsanalyse, schaffen aber eine belastbare Basis.

Schritt 6: Die §203-Kette am realen Betrieb ausrichten

Für die Einordnung nach §203 StGB ist relevant, welche mitwirkenden Personen und Dienstleister im produktiven Modell tatsächlich beteiligt sind. Das betrifft beispielsweise Managed Operations, Infrastruktur, externen Support und Dienste, die Inhaltsdaten erhalten.

Der rechtliche Scope sollte deshalb auf dem technischen Systembild aufbauen. Ein Vertrag, der nur den Server nennt, passt nicht zu einer Anwendung, die zusätzlich externe KI-, E-Mail- und Fehlertracking-Dienste nutzt. Umgekehrt sollten Dienste ohne fachliche Daten nicht pauschal so behandelt werden, als erhielten sie vollständige Akteninhalte.

Ein sinnvoller Übernahmepfad

WZ-IT strukturiert die Übernahme typischerweise in vier Phasen:

1. Bestand: Repository, Komponenten, Datenflüsse, Zugriffe und Betriebszustand aufnehmen.
2. Zielbild: Plattform, Isolation, Identität, Backup, Monitoring und Verantwortlichkeiten festlegen.
3. Probelauf: Anwendung und Daten in einer Zielumgebung deployen, Nutzerwege und Wiederherstellung testen.
4. Cutover: Umschaltung planen, produktive Daten übernehmen, Abnahme durchführen und Betrieb starten.

Der Umfang bleibt individuell, weil ein kleiner interner Workflow und ein mandantenfähiges Portal trotz gleicher Entwicklungsplattform nicht dieselbe Prüfung benötigen.

Passende WZ-IT-Angebote

• Der AI Code & Production Readiness Audit liefert vor Go-live oder Übernahme eine priorisierte Bewertung von Auth, Daten, Security, Deployment und Betrieb.
• Prototype to Production übernimmt MVPs aus Lovable, Bolt, v0, Replit oder Base44 in eine wartbare Produktionsstrecke.
• Über Softwareentwicklung und Co-Development kann WZ-IT Befunde beheben, Integrationen ergänzen und die Anwendung gemeinsam mit dem Kundenteam weiterentwickeln.
• Für Berufsgeheimnisse ergänzt die §203 Managed Cloud für KI-generierte Software diese eigenständigen Leistungen um das dafür vorgesehene Betriebsmodell.

Quellen

• § 203 StGB - Verletzung von Privatgeheimnissen
• OWASP Application Security Verification Standard
• OWASP Top 10
• Supabase-Dokumentation: Row Level Security