Bevor KI-gebaute Software in den Betrieb geht, schauen wir hinein.
Mit KI entsteht eine funktionierende Anwendung heute in Tagen. Ob sie sicher, wartbar, datenschutzkonform und betreibbar ist, sieht man der Demo nicht an. Wir begutachten Vibe-Code-Software — neu entwickelte ebenso wie bestehende Systeme, die mit KI weiterentwickelt wurden — und liefern ein klares Ergebnis: nutzbar, nutzbar mit Auflagen oder nicht nutzbar ohne Nacharbeit.
- Gegenstand
- Raumbuchung für Seminarräume (fiktiv)
- Entstehung
- KI-unterstützt, ca. 85 % generiert
- Prüfstand
main @ 4e1c9a7- Umfang
- 6 AE · Repo, Testsystem, Doku
Abbildung: Deckblatt im tatsächlichen Ausgabeformat, gefüllt mit einem fiktiven Beispiel.
Warum gerade Vibe-Code eine eigene Prüfung braucht
KI-Assistenten schreiben Code, der läuft. Sie optimieren auf «funktioniert in der Demo» — nicht auf «hält einem Angreifer, einem Datenschutz-Audit und fünf Jahren Betrieb stand». Dazu kommt: Wer per Prompt entwickelt, hat oft nie jede Zeile gelesen. Die typischen Schwächen sind deshalb andere als bei klassisch entwickelter Software — und sie liegen fast immer dort, wo die Demo nicht hinschaut.
| Typisches Muster in Vibe-Code | Warum es entsteht | Folge im Betrieb | In der Demo sichtbar? |
|---|---|---|---|
| Berechtigung nur im Frontend | Die KI blendet Knöpfe aus, prüft aber serverseitig nicht, wer die Schnittstelle aufruft. | Fremde Datensätze lesen oder ändern, indem man die Anfrage direkt schickt. | nein |
| Geheimnisse im Code | API-Schlüssel landen beim Ausprobieren im Quelltext oder im ausgelieferten JavaScript. | Schlüssel liegen in der Git-Historie, oft auch öffentlich im Browser. | nein |
| Halluzinierte oder veraltete Pakete | Modelle schlagen Bibliotheken vor, die es nicht gibt oder die längst verwundbar sind. | Einfallstor für Lieferketten-Angriffe («Slopsquatting»), bekannte Schwachstellen. | nein |
| Offene Datenbank-Regeln | Backend-as-a-Service mit Standard-Freigaben; Zeilenrechte werden «später» gemacht. | Ganze Tabellen über die öffentliche API abrufbar. | nein |
| Platzhalter, die Produktion werden | Mock-Daten, Test-Logins und «TODO: absichern» überleben den Prototyp. | Hintertüren und Funktionen, die nur scheinbar existieren. | selten |
| Kopierte statt gebaute Struktur | Jede Anfrage erzeugt neuen Code; Logik wird dupliziert statt wiederverwendet. | Fehler werden an einer Stelle behoben und bleiben an fünf anderen. | nein |
| Kein Betriebskonzept | Logs, Backups, Updates und Wiederanlauf sind nie angefragt worden. | Nach dem ersten Ausfall weiss niemand, was passiert ist. | nein |
| Personenbezug ohne Konzept | Formulare speichern alles, Löschfristen und Zwecke fehlen, Drittdienste werden nebenbei eingebunden. | Datenschutzverstoss, Auskunfts- und Löschpflichten nicht erfüllbar. | kaum |
Mehr dazu, mit Quellen aus der Forschung: Was in KI-generiertem Code typischerweise schiefgeht.
Drei Prüftiefen — abrufbar in Arbeitseinheiten
Nicht jede Anwendung braucht ein Vollgutachten. Ein Prototyp für eine interne Demo braucht eine ehrliche Einschätzung in wenigen Stunden; ein Portal mit Studierendendaten braucht die volle Tiefe. Deshalb drei Pakete, die aufeinander aufbauen — was im Kurzcheck auffällt, wird im Basisgutachten nicht noch einmal bezahlt.
Kurzcheck / Triage
Richtwert 1–2 AE
Grundlage: Unterlagen, Screenshots, Demo, Architekturübersicht — auf Wunsch ein Blick ins Repository.
Ergebnis: kurzer Befund (2–4 Seiten) mit Risikohinweisen und einer klaren Empfehlung: weiter so, Basisgutachten, oder neu denken.
Für frühe Einschätzungen, Prototypen, interne Demos und Förderanträge.
Basisgutachten
Richtwert 4–8 AE
Grundlage: Repository, Dokumentation, Testsystem, Build-Anleitung, Tickets, CI/CD.
Ergebnis: Gutachten mit Nutzungsrahmen — nutzbar, nutzbar mit Auflagen oder nicht nutzbar ohne Nacharbeit — und einer priorisierten Befundliste.
Der Normalfall vor dem Produktivbetrieb.
Vollgutachten
Richtwert 10–20 AE
Grundlage: zusätzlich Test-/Staging-Umgebung, Infrastrukturkonzept, Rollenmodell, Logs, Deployments, Datenschutzunterlagen.
Ergebnis: ausführliches Gutachten mit reproduziertem Build, Sicherheitsreview, Massnahmenliste, Priorisierung, Restrisiko und Abnahmekriterien.
Für Anwendungen mit sensiblen Daten, vielen Nutzenden oder langer Lebensdauer.
Eine AE entspricht in unserem Vorschlag einem Gutachter-Personentag (8 Stunden). Die genaue Zahl je Projekt hängt von Grösse, Zahl der Dienste und Schnittstellen ab und wird vor Beginn verbindlich festgelegt. Nachprüfungen nach behobenen Befunden kosten typischerweise 25–40 % der ursprünglichen AE. Planen Sie ein Kontingent für mehrere Projekte? → Kontingent-Planer
Was in welchem Paket geprüft wird
| Prüfdomäne | S · Kurzcheck | M · Basis | L · Voll |
|---|---|---|---|
| Architektur & Aufbau | |||
| Codequalität & Wartbarkeit | |||
| Abhängigkeiten & Lieferkette | |||
| Tests & Build | |||
| Sicherheit (Code) | |||
| Sicherheit (laufendes System) | |||
| Datenschutz | |||
| Betrieb, Logs, Deployment | |||
| Rollen & Berechtigungen | |||
| Barrierefreiheit | |||
| KI-spezifische Risiken | |||
| Nachnutzung durch Dritte |
vollständig geprüft Stichprobe bzw. Indizien nicht Gegenstand. Die Details je Prüfpunkt stehen im Prüfkatalog.
So gehen wir vor
Drei Arten von Prüfung greifen ineinander. Eine deterministische Prüfstrecke liefert reproduzierbare Messwerte. Eine KI-gestützte, ausdrücklich kritische Analyse sucht nach den Mustern, die Werkzeuge nicht sehen. Und ein Mensch verifiziert, bewertet und unterschreibt. Keine KI-Aussage landet ungeprüft im Gutachten.
1 · Abruf
Die Hochschule bzw. Fachabteilung ruft ein Paket ab. Ein einseitiger Steckbrief klärt Zweck, Datenarten, Nutzerkreis und Schnittstellen — daraus folgt die AE-Zahl.
2 · Übergabe
Lesezugriff aufs Repository, Unterlagen und ein Testsystem. Vertraulichkeit und Auftragsverarbeitung sind vorher geregelt; Produktivdaten brauchen wir nicht.
3 · Prüfen
Prüfstrecke, KI-Analyse und Expertenreview laufen verzahnt. Kritische Funde melden wir sofort, nicht erst im Bericht.
4 · Ergebnis
Gutachten mit Urteil, Befunden, Massnahmen und Abnahmekriterien; Abschlussgespräch mit Entwicklung, Informationssicherheit und Datenschutz.
Wie das im Detail funktioniert — Werkzeugklassen, eigene Heuristiken, KI-Gegenproben und die Beweisregel — steht unter Methodik.
Das Ergebnis: ein Urteil, das man verwenden kann
Ein Gutachten ist nur nützlich, wenn es eine Entscheidung trägt. Darum folgt das Urteil festen, offengelegten Regeln — nicht dem Bauchgefühl:
Keine offenen kritischen oder hohen Befunde. Mittlere Befunde sind dokumentiert und haben einen Termin.
Betrieb kann starten.
Keine kritischen Befunde. Hohe Befunde sind mit einer konkreten Massnahme und Frist behebbar, ohne die Architektur umzubauen.
Betrieb nach Erfüllung der Auflagen — Nachweis per Nachprüfung oder Selbsterklärung, je nach Auflage.
Mindestens ein kritischer Befund, ein Datenschutz-Blocker (z. B. fehlende Rechtsgrundlage, unkontrollierter Abfluss) oder ein grundlegender Architekturmangel.
Mit Massnahmenliste und Priorisierung, damit die Nacharbeit planbar wird.
Warum wir das können
Wir betreiben Vibe-Code jeden Tag
VibeBoxes ist eine Plattform, auf der KI-gebaute Anwendungen laufen. Jedes Paket, das eine KI bei uns hochlädt, geht durch einen automatischen Deploy-Prüfer. Wir sehen also laufend, was KI-Assistenten tatsächlich produzieren — und wo es bricht.
Erfahrener Entwickler-Pool
Begutachtet wird von erfahrenen Softwareentwicklerinnen und -entwicklern aus unserem Netzwerk, zusammengestellt nach Stack: Web-Frontends, Backends, Datenbanken, Container und Infrastruktur. Wer ein Projekt prüft, hat in genau dieser Technik selbst produktive Systeme gebaut.
Compliance aus der Praxis
Langjährige Arbeit in regulierten Umgebungen: Microsoft-365-Sicherheit und -Compliance, Identität und Berechtigungen, Datenschutz nach DSGVO und Schweizer DSG, Barrierefreiheit nach BITV 2.0 — mit DokAudit betreiben wir selbst ein Prüfwerkzeug für barrierefreie PDFs.
Schnittstellen sind unser Alltag
SSO über Entra ID, SAML und OIDC, Microsoft Graph, Verzeichnisdienste, Mail mit SPF/DKIM/DMARC, DNS- und Proxy-APIs, MCP-Schnittstellen für KI-Agenten. Gerade an Schnittstellen macht Vibe-Code die teuersten Fehler.
Eigene Prüfmethoden
Neben Standardwerkzeugen setzen wir eigene Heuristiken für KI-typische Muster ein: Paket-Existenzprüfung, Platzhalter-Detektor, Berechtigungsmatrix aus den Routen, Doku-Code-Abgleich. Deterministisch, wo es geht — heuristisch, wo es nötig ist.
KI als Gegenspieler
Wir nutzen KI nicht, um Code schönzureden, sondern um ihn anzugreifen: mehrere Modelle in getrennten Rollen, Angriffshypothesen, generierte Missbrauchsfälle. Was die KI behauptet, prüft danach ein Mensch nach.
Unabhängigkeit — offen gesagt
Wir betreiben selbst eine Plattform für KI-gebaute Anwendungen. Das ist unser Erfahrungsvorsprung — und ein möglicher Interessenkonflikt. Deshalb gelten feste Regeln: Unsere Gutachten empfehlen keine eigenen Produkte, Betriebsempfehlungen sind herstellerneutral, Software auf unserer Plattform oder aus eigener Entwicklung begutachten wir nur mit ausdrücklicher Offenlegung, und Prüfung und Nachbesserung bleiben getrennt.
Für wen
Hochschulen & Verbünde
Lehr-Tools, Chatbots, Verwaltungs-Workflows, Forschungs-Apps: zentral beauftragt, dezentral abgerufen, in AE verteilt. Mehr für Hochschulen →
Öffentliche Verwaltung
Fachabteilungen bauen mit KI eigene Werkzeuge. Vor dem Produktivbetrieb braucht es eine Freigabe, die vor Informationssicherheit und Datenschutz besteht.
Unternehmen
Vor dem Kauf einer KI-gebauten Lösung, vor einer Übernahme, oder wenn ein Prototyp zum Produkt werden soll: Due Diligence für Code, den niemand vollständig gelesen hat.
Ein Steckbrief und ein Gespräch von 30 Minuten genügen, um Paket und AE-Rahmen einzuschätzen — auch für ein Kontingent über mehrere Einrichtungen.
Anfrage an hallo@vibeboxes.ch →