Kundenprototypen mit KI unter NDA: eine gemeinsame RTX PRO Workstation für Agenturen

Klickdummys und Prototypen für Kunden, ohne das Briefing hochzuladen

Eine Agentur kann Kundenprototypen mit KI unter NDA bauen, wenn App-Builder und Sprachmodell auf ihrer eigenen Workstation laufen: Dyad oder OpenHands als lokale Alternative zu Lovable, ein offenes Modell wie Qwen3.8-27B in Ollama und eine NVIDIA RTX PRO Blackwell mit genug Speicher für mehrere Personen gleichzeitig. Briefing, Screens und erzeugter Code werden dann auf diesem Rechner verarbeitet und in einem Git-Repository je Kunde abgelegt. Für ein Studio, in dem mehrere Leute gleichzeitig bauen, ist eine RTX PRO 6000 Blackwell Workstation Edition oder Max-Q mit 96 GB der praktische gemeinsame Rechner.

Dieser Artikel richtet sich an Inhaber und technische Leitungen von Digitalagenturen, Produktstudios und freiberufliche Entwickler, die Klickdummys, Proofs of Concept und erste Versionen einer App verkaufen. Die Frage dahinter ist meist vertraglich. Das NDA oder die Datenverarbeitungsbedingungen eines Kunden regeln, welche Dritten das Briefing, Kundendaten in einer Demo oder den vorhandenen Code des Kunden sehen dürfen. Ein Cloud-Builder ist ein solcher Dritter, zusammen mit den Modellanbietern, die er nutzt. Was die EU-Richtlinie über Geschäftsgeheimnisse vom Inhaber vertraulicher Informationen erwartet und was ein eigener Server daran ändert, behandelt unser Leitfaden zu Geschäftsgeheimnissen, NDAs und KI-Werkzeugen.

Cloud-Builder veröffentlichen eigene Regeln, und die unterscheiden sich je Tarif. Die Dokumentation von Lovable, gelesen am 30. Oktober 2026, hält fest, dass Kundendaten aus den Tarifen Free und Pro seit dem 9. September 2026 zum Training von Modellen verwendet werden dürfen, sofern nicht jeder Nutzer seine eigenen Inhalte über eine Kontoeinstellung ausnimmt; der Opt-out wirkt ab diesem Zeitpunkt. Workspace-Daten in den Tarifen Business und Enterprise sind „excluded from model training by default“. Mit einem lokalen Builder stellt sich die Trainingsfrage nicht, weil kein externer Dienst die Inhalte erhält. Die Werkzeuge selbst im Einzelvergleich stehen in unserem Artikel zur selbst gehosteten Lovable-Alternative; hier geht es darum, was sich ändert, wenn die Arbeit für zahlende Kunden entsteht.

Die Werkzeuge und ihre Lizenzen für bezahlte Kundenarbeit

Eine Agentur braucht von einer Lizenz zweierlei: die Erlaubnis zur kommerziellen Nutzung und keinen Anspruch auf den erzeugten Code. Die Tabelle zeigt, was Lizenzdateien und Projektseiten sagen.

README, FAQ und Lizenzdatei in src/pro von Dyad, Repository und Release-Seite von OpenHands, Repository von Ollama, Modellkarte von Qwen3.8-27B, Repository-Seite von bolt.diy und die Lizenzseite zu WebContainers, alle gelesen am 30. Oktober 2026.

Dyad kommt einem Prompt-zu-App-Builder lokal am nächsten. Code außerhalb des Ordners src/pro steht unter Apache 2.0. Der Pro-Ordner steht unter der Functional Source License 1.1, die jeden Zweck außer einer „Competing Use“ erlaubt: dem Bereitstellen der Software für andere in einem kommerziellen Produkt oder Dienst, der sie oder ein anderes Produkt ihrer Hersteller ersetzt oder „the same or substantially similar functionality“ bietet. Die Klausel betrifft die Weitergabe von Dyads eigenem Code, und als erlaubte Zwecke nennt die Lizenz die Nutzung „for your internal use and access“ und „in connection with professional services that you provide to a licensee using the Software“, also die eigene interne Nutzung und Dienstleistungen für einen Lizenznehmer. Eine Agentur, die mit Dyad Kunden-Apps baut, gibt die Apps weiter, nicht Dyads Code, und jede Version des Pro-Codes wird zwei Jahre nach ihrer Veröffentlichung zu Apache 2.0. Die Eigentumsfrage beantwortet Dyads FAQ direkt: „Your code is your code, and it's all on your computer.“ Dyads Datenschutzerklärung, zuletzt aktualisiert am 22. Juni 2026, hält fest, dass mit lokalen Modellen „everything stays on your device“ und dass Telemetrie, die nur mit Einwilligung gesendet wird, keine Chatnachrichten, Prompts oder Code enthält. Die FAQ sagt außerdem: „Dyad only supports JavaScript-based apps at this time“; ein Kunden-Backend in Python oder Java ist daher eine Aufgabe für OpenHands.

OpenHands ist ein MIT-lizenzierter Coding-Agent, der Dateien bearbeitet und Befehle ausführt. Er passt zum Schritt nach dem Klickprototyp: einem MVP mit Backend, Tests und Build-Skript. Seine lokale Weboberfläche bindet standardmäßig an 127.0.0.1.

bolt.diy steht unter MIT, doch die damit gebauten Apps laufen in der WebContainers-Laufzeit von StackBlitz, deren Lizenzseite eine Lizenz für „production usage of the API in a commercial, for-profit setting“ verlangt und „Prototypes or POCs“ ausnimmt. Welcher Fall für bezahlte Kundenprototypen gilt, klärt StackBlitz; deshalb liefern wir bolt.diy nicht vorinstalliert aus.

Die Lizenz des Modells zählt so viel wie die des Werkzeugs. Qwen3.8-27B und Qwen3-Coder-Next stehen laut ihren Modellkarten unter Apache 2.0. Manche Bild- und Videomodelle, die Agenturen nutzen, sind nicht frei für kommerzielle Zwecke, wie unser Leitfaden zum KI-Server für Kreativagenturen zeigt; prüfen Sie jedes Modell, bevor es in die Kundenarbeit geht.

Sie können die RTX PRO Workstation allein bestellen, die Einrichtung von Ollama, Modell und Dyad oder OpenHands allein oder beides zusammen: die Workstation mit allem fertig installiert und eingerichtet; schreiben Sie uns, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

Kunden auf einem Rechner sauber trennen

Auf einer gemeinsamen Workstation liegt die Arbeit mehrerer Kunden gleichzeitig, also muss die Trennung von Anfang an geplant sein. Wie streng sie sein muss, entscheidet meist das NDA; die Schritte unten reichen vom Minimum bis zur strengsten Form.

1. Ein Repository je Kundenprojekt. Dyad legt jede App in einem eigenen Ordner ab, typischerweise ~/dyad-apps/<name>, und jede App ist ein Git-Repository. Benennen Sie Projekte nach Kunden und legen Sie Briefings, Screenshots und Testdaten in den Projektordner, nicht in einen gemeinsamen Download-Ordner.
2. Ein Benutzerkonto je Person. Der App-Ordner liegt im Home-Verzeichnis des Nutzers, getrennte Konten geben also jeder Person ihre eigenen Projekte, und Dateirechte entscheiden, wer die Arbeit eines anderen lesen darf.
3. Eine Sandbox je Agenten-Aufgabe. Im Docker-Betrieb führt OpenHands die Befehle des Agenten in einer Sandbox aus, sodass ein Agent am Code eines Kunden nur die dort eingebundenen Ordner erreicht; die README kennzeichnet den npm-Start als Betrieb ohne Sandbox.
4. Getrennte Caches am Modellserver. Ein Modellserver merkt sich keine früheren Gespräche, doch das Prefix Caching von vLLM verwendet gespeicherten Kontext zwischen Anfragen wieder. Die vLLM-Dokumentation warnt, dass gemeinsame Caches „timing-based attacks where an adversary could infer cached content by observing latency differences“ ermöglichen, und bietet je Anfrage ein Feld cache_salt: Nur Anfragen mit demselben Salt nutzen gegenseitig ihren Cache. Ein kleines Gateway vor dem Modell kann je Kundenprojekt ein eigenes Salt setzen, so wie unser Leitfaden zum LLM-Gateway mit Schlüsseln und Protokollen es für Schlüssel beschreibt.
5. Ein sauberes Projektende. Verlangt das NDA Rückgabe oder Löschung der Unterlagen, löschen Sie den Projektordner, seine Git-Historie und Kopien in den Logs des Modellservers und in Backups, und halten Sie das Datum fest.

Der Netzzugang gehört zum selben Plan. Ollama lauscht standardmäßig nur auf 127.0.0.1; zieht das Modell auf einen gemeinsamen Rechner, sollte sein Port aus dem Studionetz erreichbar sein und sonst nirgends, wie unser Leitfaden zur Absicherung eines GPU-Servers beschreibt. Was die Werkzeuge von sich aus nach außen senden, behandelt unser Artikel zu Telemetrie in selbst betriebenen KI-Tools.

Den Prototyp übergeben

Da eine Dyad-App laut FAQ „just a regular Git repo“ ist, besteht die Übergabe aus dem Repository: auf den Git-Server des Kunden übertragen oder als Archiv geliefert. Die GitHub-Integration von Dyad überträgt nach GitHub; für einen Kunden mit anderem Git-Server funktionieren die üblichen Git-Befehle im selben Ordner. Dyad bietet außerdem „Copy app without history“, das die Git-Historie zurücksetzt, wenn der Kunde den Code ohne die Arbeitsschritte der Agentur erhalten soll.

Drei Punkte gehören in die Übergabenotiz. Erstens behalten die Bibliotheken, die der Builder hinzugefügt hat, wie in jedem Projekt ihre eigenen Lizenzen; listen Sie sie auf. Zweitens nennen Sie, welche Werkzeuge und Modelle den Code geschrieben haben, weil manche Kunden danach fragen und manche Verträge es verlangen; wem mit KI geschriebener Code gehört und was eine Firmenrichtlinie dazu sagen sollte, behandelt unser Leitfaden zur Richtlinie für KI-Coding-Assistenten. Drittens ist ein Prototyp kein Produktivsystem: Bevor er echte Kundendaten verarbeitet, braucht er die Prüfung aus unserem Artikel zu Sicherheitsprüfungen beim Vibe Coding vor dem Livegang. Wo die App danach läuft, entscheidet der Kunde; ein lokaler Builder liefert Quellcode und Vorschau, das Hosting ist ein eigener Schritt.

Welche RTX PRO Workstation für eine Agentur

Der Speicher entscheidet, wie viele Personen gleichzeitig bauen können. Jede Person, die gerade arbeitet, belegt eine Agenten-Sitzung, und jede Sitzung legt ihren Kontext im KV-Cache ab, dem Speicher, in dem das Modell festhält, was es gelesen hat. Unsere Regel für Nutzer je Karte nimmt 90 Prozent des vom Treiber gemeldeten Speichers und zieht 3 GiB je Karte ab, wie unser Leitfaden Wie viele Nutzer bedient eine RTX PRO 6000 erklärt. Qwen3.8-27B legt seinen Cache nur in 16 seiner 64 Schichten an: nach unserer Rechnung aus seiner Konfiguration 64 KiB je Token in 16 Bit, also etwa 8,1 GiB für eine Sitzung von 128K Token und 4,1 GiB für 64K, einschließlich eines kleinen festen Zustands.

Unsere Schätzungen nach der Regel für Nutzer je Karte (nutzbarer Speicher 25,7, 61,5, 83,0 und 166,1 GiB), Gewichte aus Ollamas qwen3.8-Tags (18 GB in 4 Bit, 30 GB in 8 Bit), 16-Bit-Cache wie in Ollamas Voreinstellung; keine Messungen. Ein FP8-Cache, wie vLLM ihn bietet, verdoppelt die Sitzungszahlen etwa.

Die Einstiegsstufe reicht für eine Person; der gemeinsame Rechner beginnt bei 72 GB. Eine RTX PRO 6000 Workstation Edition oder Max-Q gibt einem Studio 13 Sitzungen zu 64K, nach unserer Schätzung genug für etwa ein Dutzend Leute, die gleichzeitig bauen, oder sie betreibt Qwen3-Coder-Next in FP8 (80,4 GB) mit fünf Sitzungen zu 64K. Mit zwei Max-Q zu je 300 W läuft auf jeder Karte eine eigene Modellkopie. NVIDIA nennt bis zu vier Max-Q je Workstation; drei oder vier gehören nur in ein dafür gebautes Gehäuse mit starker, gerichteter Luftführung, und zwei Workstation Editions mit 600 W sind für diese Edition das realistische Maximum. Größere Agenturen mit 20 oder mehr Entwicklern, die Agenten nutzen, sind mit einem Rack-Server besser bedient, wie unser Leitfaden zum Server für Coding-Agenten zeigt.

Die Geschwindigkeit hängt von der Speicherbandbreite der Karte und der Größe der Gewichte ab. Nach unserer Schätzung aus der von NVIDIA angegebenen Speicherbandbreite und etwa 28 GB gelesenen Gewichten je Token kommt eine Anfrage in 8 Bit auf einer Workstation Edition oder Max-Q (1.792 GB/s) auf höchstens etwa 63 Token pro Sekunde und auf einer Server Edition auf etwa 56; reale Werte liegen darunter (StorageReview maß für eine Anfrage der NVFP4-Version mit vLLM 17 bis 22 Token pro Sekunde), und ein Test mit Ihren eigenen Prompts zeigt, was Ihr Aufbau erreicht. Ob ein Modell dieser Größe für Ihre Art von Apps reicht, behandelt unser Artikel Reicht ein lokales Modell fürs Vibe Coding?, die vollständige Ausstattung je Stufe unser Leitfaden zur Vibe-Coding-Workstation.

Nennen Sie uns die Zahl der Personen, die gleichzeitig bauen, und die Art Ihrer Prototypen, und wir schlagen Karte und Einrichtung vor, die dazu passen.

Der Betrieb im Studio

Für den Aufbau gibt es zwei Wege. Im ersten nutzt jeder Entwickler Dyad auf dem eigenen PC und verbindet es mit dem Modellserver der gemeinsamen Workstation; die Projekte bleiben auf den PCs, die Workstation hält nur das Modell. Dyad findet Ollama auf localhost selbst und nutzt ein gesetztes OLLAMA_HOST, so Dyads Leitfaden zum lokalen Coding vom 4. Februar 2026. Im zweiten liegen auch die Projekte auf der Workstation, in einem Konto je Person; dann bleibt alles Kundenmaterial auf einem Rechner, der an einer Stelle gesichert und gelöscht wird.

Setzen Sie den Kontext des Modells auf mindestens 64.000 Token, was Ollama in seiner Ankündigung vom 23. Januar 2026 für Coding-Tools empfiehlt, und betreiben Sie Ollama 0.35.0 oder neuer, das CVE-2026-103663 behebt, wie unser Leitfaden zum Coding-Assistenten festhält. Die in Ollamas FAQ beschriebene Einstellung OLLAMA_NO_CLOUD=1 entfernt die Cloud-Modelle und die Websuche, damit kein Kunden-Prompt versehentlich den Rechner verlässt. Ollama beantwortet je Modell eine Anfrage nach der anderen, bis OLLAMA_NUM_PARALLEL erhöht wird, und jeder parallele Platz kostet zusätzlichen Kontextspeicher, wie unser Vergleich von vLLM, SGLang, TensorRT-LLM und Ollama zeigt; teilen sich mehr als eine Handvoll Leute das Modell, ist vLLM mit seinem Feld cache_salt der bessere Server. Den Schritt vom einzelnen PC zum gemeinsamen Server beschreibt Von Ollama auf dem PC zum KI-Server für die Firma.

FAQ