KI-App veröffentlichen: 7 Dinge, die ein Link nicht löst

Du hast etwas gebaut. Mit Lovable, Cursor oder Bolt, an einem Wochenende, und es funktioniert. Jetzt soll der erste Kunde drauf, oder dein Team soll damit arbeiten. Also kopierst du den Vorschau-Link aus dem Tool und schickst ihn rüber. Und hier fängt das eigentliche Problem an: ein geteilter Link ist kein veröffentlichtes Tool. Er hat keinen Zugriffsschutz, keine eigene Domain, keine Kontrolle darüber, was bei einem Absturz passiert, und niemand weiß, wo die Daten deiner Nutzer landen.

Die gute Nachricht: Du musst dafür kein Server-Admin werden. Damit andere wirklich auf deiner App arbeiten können, brauchst du sieben Dinge, und du kannst sie in der richtigen Reihenfolge abhaken. Dieser Post zeigt dir genau diese Liste, vom Zugriffsschutz bis zur Frage, was passiert, wenn etwas kaputtgeht.

Das Wichtigste in Kürze

• Ein geteilter Tool-Link ist kein Betrieb: keine Zugriffskontrolle, keine eigene Domain, keine Kontrolle über Ausfälle und Daten.
• Red Access fand 2026 über 380.000 öffentlich erreichbare KI-Apps, viele ohne grundlegende Zugriffskontrolle, oft mit Admin-Zugang für jeden, der die URL kennt (The Hacker News, 2026).
• Sobald echte Nutzer drauf sind, verarbeitest du personenbezogene Daten, und damit gilt die DSGVO, unabhängig von der Projektgröße.
• Mit lowcloud bringst du die App in Minuten auf eigene Domain und Server in Deutschland live, statt Wochen an Infrastruktur zu verlieren.

Warum ein geteilter Link noch kein veröffentlichtes Tool ist

Ein Vorschau-Link teilt deinen Prototyp, er veröffentlicht ihn nicht. Der Unterschied ist Kontrolle: über wer reinkommt, unter welcher Adresse, was bei Fehlern passiert und wo die Daten liegen. Beim geteilten Link liegt all das beim Tool-Anbieter oder bei niemandem. Warum der Preview-Link kein echter Betrieb ist, zeigt ein eigener Beitrag im Detail.

Das ist kein theoretisches Risiko. Red Access scannte 2026 über 380.000 öffentlich erreichbare Apps von Vibe-Coding-Plattformen. Tausende davon waren ohne jede Zugriffskontrolle online, viele gaben jedem, der die URL kannte, standardmäßig Admin-Rechte (The Hacker News, 2026). Der Report trägt den Namen „The Shadow Builders", und gemeint sind genau die Leute, die schnell etwas gebaut und dann den Link rumgeschickt haben.

Bevor du tiefer in die einzelnen Punkte gehst, hilft eine klare Gegenüberstellung. Was unterscheidet den geteilten Link vom richtig veröffentlichten Tool?

Die rechte Spalte sieht nach Aufwand aus, ist es aber nicht. Eine moderne Plattform liefert Login, Domain, Datenbank und Monitoring fertig mit. Du tauschst den geteilten Link gegen ein echtes Deployment, nicht gegen ein DevOps-Projekt.

Wer darf rein? Zugriffsschutz und eigene Domain

Zugriffsschutz heißt: nicht jeder, der die URL hat, soll alles sehen und ändern können. Das ist die häufigste Lücke. Die meistverbreitete Schwachstelle in KI-gebauten Apps ist Broken Object Level Authorization, also die fehlende Prüfung, ob ein eingeloggter Nutzer überhaupt auf diesen Datensatz zugreifen darf (SoftwareSeni, 2026).

Für ein internes Team reicht oft ein Login plus eine Berechtigung pro Rolle. Für Kunden brauchst du echte Mandantentrennung, damit Kunde A nie die Daten von Kunde B sieht. Wenn deine Datenbank Row Level Security unterstützt, schalte sie auf jeder Tabelle ein. KI-Tools legen Secrets und Datenbank-Zugänge gern direkt ins Frontend, wo jeder sie in den Browser-DevTools lesen kann (Aikido, 2026). Jeder Schlüssel gehört auf den Server, nie ins ausgelieferte JavaScript.

Dazu kommt die eigene Domain. Eine Adresse wie app.deinefirma.de ist kein Kosmetik-Thema. Sie schafft Vertrauen, sie überlebt einen Plattformwechsel, und sie ist Voraussetzung für sauberes Login. Wer auf eine eigene Domain umzieht, muss bei den meisten Tools die Auth-Einstellungen nachziehen, etwa die Site-URL und die OAuth-Redirect-URLs auf die neue Domain setzen (Lovable Docs, 2026). Sonst funktioniert der Google-Login auf der schönen neuen Adresse plötzlich nicht mehr.

Was passiert mit den Daten deiner Nutzer?

Sobald echte Leute deine App nutzen, verarbeitest du personenbezogene Daten, und damit gilt die DSGVO. Eine E-Mail-Adresse reicht, eine IP-Adresse reicht, ein Chatverlauf reicht. Die DSGVO fragt nicht, ob du Solo-Gründer oder Konzern bist, sie fragt, ob personenbezogene Daten verarbeitet werden. Seit August 2026 kommt für KI-Anwendungen mit dem EU AI Act eine zweite Pflichtenebene dazu (Shadow AI Watch, 2026).

Praktisch heißt das zwei Dinge. Erstens brauchst du eine eigene Datenbank, deren Inhalt dir gehört und die du nicht verlierst, wenn ein Tool-Tarif ausläuft. Eine Datenbank, aus der du auf Anfrage alle Daten eines Nutzers löschen kannst, trennt das Spielzeug vom Tool. Zweitens solltest du wissen, wo diese Datenbank steht. Wenn deine Nutzer in Deutschland sitzen und ein Kunde nach dem Speicherort fragt, ist „Server in Deutschland" eine kurze, gute Antwort statt eines langen Termins beim Datenschutzbeauftragten. Eine Checkliste, wie du deine App rechtssicher in der EU hostest, gibt es separat.

Das ist der Punkt, an dem EU-Hosting zum stillen Vorteil wird. Es ist nicht der Grund, warum du veröffentlichst, aber es macht den Datenschutz-Teil von einem Risiko zu einem Verkaufsargument. Wie das mit dem typischen Vibe-Coding-Stack zusammenpasst, zeigt der Beitrag zum Vibe-Coded App deployen im Detail.

Hält das stand, wenn echte Leute drauf sind?

Stabilität entscheidet sich nicht an einem guten Tag, sondern an dem Tag, an dem zwanzig Leute gleichzeitig auf der App sind und etwas kaputtgeht. Drei Dinge gehören dafür eingebaut, bevor du den Link rausgibst: ein Health-Check, der merkt, wenn die App hängt, ein Logstream, in dem du Fehler tatsächlich siehst, und eine Rollback-Möglichkeit, um in Sekunden auf die letzte funktionierende Version zurückzugehen.

Hier zeigt sich, wie groß die Lücke zwischen „läuft bei mir" und „läuft für andere" ist. Eine Q1-Analyse von über 200 KI-gebauten Apps fand in 91,5 Prozent mindestens eine Schwachstelle (SoftwareSeni, 2026). Ein separater Scan von 5.600 öffentlich deployten Apps fand über 2.000 kritische Schwachstellen, 400 offen liegende Secrets und 175 Fälle mit echten Personendaten (SoftwareSeni, 2026). Das sind keine Hacker-Geschichten, das sind ganz normale Apps, die jemand einfach live geschickt hat, getroffen von den typischen Deployment-Problemen beim Vibe Coding.

Aus den Deploys, die Vibe-Coder bei uns auf lowcloud machen, sehen wir fast immer dasselbe Muster: Der Code läuft, aber niemand hat überlegt, was bei einem Fehler passiert. Deshalb liefern wir Monitoring, Logs und Rollback ab dem ersten Deploy mit, statt sie als Extra-Projekt zu behandeln. Und wenn doch etwas hakt, gibt es einen echten Ansprechpartner, nicht nur einen Forum-Thread. Dieser Support-Punkt fehlt beim geteilten Link komplett.

Häufige Fragen

Reicht der Vorschau-Link von Lovable oder Bolt für echte Kunden?

Für eine kurze Demo ja, für den Dauerbetrieb nein. Der Link hat keine eigene Domain, oft keinen sauberen Zugriffsschutz und keine Kontrolle über Ausfälle. Sobald Kunden echte Daten eingeben, brauchst du ein eigenes Deployment mit Login, eigener Datenbank und einem klaren Plan für den Fehlerfall.

Brauche ich wirklich eine eigene Datenbank?

Ja, sobald Nutzer Daten anlegen, die nicht verloren gehen dürfen. Eine eigene Datenbank gibt dir Backups, Kontrolle über den Speicherort und die Möglichkeit, auf DSGVO-Anfragen alle Daten eines Nutzers gezielt zu löschen. Mit dem geteilten Tool-Speicher ist das meist nicht sauber möglich.

Muss ich mich um die DSGVO kümmern, wenn es nur ein internes Tool ist?

Ja. Auch ein internes Team besteht aus Personen, deren Daten verarbeitet werden, etwa Namen, E-Mails und Logins. Die DSGVO gilt ab der ersten personenbezogenen Information. Server in Deutschland und eine klare Liste, welche Daten wo liegen, machen diesen Teil unkompliziert.

Was passiert, wenn die App abstürzt, während ein Kunde drauf ist?

Beim geteilten Link: nichts Sichtbares, du erfährst es vielleicht gar nicht. Bei einem richtigen Deployment greifen Health-Check und Alert, du siehst den Fehler im Log, und du kannst per Rollback auf die letzte funktionierende Version zurück. Diese Sicherheit unterscheidet ein Tool von einem Prototyp.

Fazit

Etwas zu bauen, das andere wirklich nutzen, ist mehr als einen Link zu teilen. Zwischen „läuft bei mir" und „mein Kunde verlässt sich drauf" liegen sieben konkrete Schritte: kein nackter Link, Zugriffsschutz, geklärter Datenschutz, eigene Domain, Stabilität, eine eigene Datenbank und ein Plan für den Fehlerfall. Keiner davon verlangt, dass du Infrastruktur-Profi wirst. Sie verlangen nur, dass du sie einmal bewusst durchgehst, bevor der erste echte Nutzer kommt, statt danach.

Bring deine App dahin, wo andere sich darauf verlassen können, auf eigener Domain und Servern in Deutschland: jetzt mit lowcloud starten.