Die Grundidee hinter Lazy AI ist im Namen bereits angelegt: Wer eine Anwendung braucht, soll nicht zuerst eine Entwicklungsumgebung einrichten, ein Framework auswählen, Abhängigkeiten installieren, einen Server konfigurieren und eine Bereitstellungskette aufbauen müssen. Stattdessen beschreibt man, was die Anwendung tun soll, die KI erzeugt den Code, und die Plattform stellt die Anwendung in einer eigenen Cloud-Umgebung bereit. Änderungen erfolgen wiederum per Anweisung, etwa „füge ein Feld für die Kostenstelle hinzu“ oder „schicke bei jedem neuen Eintrag eine Nachricht in den Team-Kanal“.
Hinter Lazy AI steht nach unserem Kenntnisstand ein vergleichsweise junges Software-Unternehmen. Angaben zu Sitz, Eigentümerstruktur, Finanzierung und Rechtsform sollten Sie vor einer geschäftlichen Nutzung direkt beim Anbieter und im Impressum beziehungsweise in den Vertragsunterlagen prüfen, denn gerade bei jungen Plattformen ändern sich solche Rahmendaten schnell. Für die Bewertung im Mittelstand ist ohnehin weniger die Gründungsgeschichte entscheidend als drei Eigenschaften, die das Angebot prägen:
Unter dem Begriff Prompt-to-App-Plattformen fassen wir Werkzeuge zusammen, die aus einer Beschreibung in natürlicher Sprache eine vollständige, ausführbare Anwendung erzeugen und diese in der Regel auch gleich bereitstellen. Sie unterscheiden sich damit von klassischen Coding-Assistenten wie GitHub Copilot oder Cursor, die Entwicklerinnen und Entwickler beim Schreiben von Code in ihrer eigenen Umgebung unterstützen. Bei Prompt-to-App-Plattformen ist die Umgebung selbst Teil des Produkts: Editor, Laufzeit, Vorschau und Hosting liegen beim Anbieter.
Zur Kategorie gehören neben Lazy AI etwa Bolt.new, Lovable, v0 von Vercel, Replit mit seinem Agenten oder GitHub Spark. Die Werkzeuge unterscheiden sich in ihrem Schwerpunkt: Manche setzen stark auf moderne Web-Oberflächen, andere auf vollständige Full-Stack-Anwendungen, wieder andere auf Bots und Hintergrunddienste. Gemeinsam ist ihnen der Anspruch, dass auch Menschen ohne tiefe Programmierkenntnisse funktionierende Software erzeugen können, und die Tatsache, dass dabei echter Quellcode entsteht, der verstanden, geprüft und gepflegt werden muss. Diese Doppelnatur zwischen Low-Code-Werkzeug und Entwicklungsumgebung macht die Kategorie so interessant und zugleich so anspruchsvoll in der Governance.
Lazy AI hat sich nach unserem Eindruck früh auf Anwendungen konzentriert, die nicht primär durch eine aufwendige Oberfläche, sondern durch Logik und Anbindungen bestimmt werden: Bots für Chat-Plattformen, kleine Schnittstellen-Dienste, Datenabfragen, Workflows und KI-gestützte Hilfsanwendungen. Nach unserem Kenntnisstand basieren viele der erzeugten Anwendungen auf Python im Backend, ergänzt um einfache Web-Oberflächen. Das unterscheidet Lazy AI von Werkzeugen, die vor allem React-Oberflächen generieren und sich an Produktteams und Designer richten. Welche Sprachen und Frameworks aktuell unterstützt werden, sollten Sie in der Dokumentation des Anbieters prüfen, da sich der Zuschnitt in diesem Markt laufend verändert.
Für den Mittelstand ist diese Ausrichtung durchaus interessant. Viele Digitalisierungswünsche aus Fachbereichen sind keine großen Produkte, sondern kleine Verbindungsstücke: eine Benachrichtigung bei bestimmten Ereignissen im ERP, ein Formular, das Daten in eine Tabelle schreibt, ein Bot, der häufige Fragen beantwortet, eine Auswertung, die einmal pro Woche verschickt wird. Genau solche Aufgaben bleiben in der IT oft liegen, weil sie zu klein für ein Projekt und zu groß für eine Tabellenkalkulation sind.
Prompt-to-App-Plattformen sind eng mit dem Begriff Vibe-Coding verbunden, also der Arbeitsweise, Software überwiegend durch Beschreibung und Rückmeldung statt durch eigenes Programmieren entstehen zu lassen. Für Fachbereiche ist das eine neue Form von Citizen Development, wie sie aus Low-Code-Plattformen bekannt ist, allerdings mit einem wichtigen Unterschied: Das Ergebnis ist kein Modell in einer geschlossenen Plattform, sondern Quellcode mit allen Möglichkeiten und Risiken, die Quellcode mit sich bringt.
Daraus folgt eine klare Rolle für die IT. Sie muss Prompt-to-App-Werkzeuge nicht verhindern, sollte aber den Rahmen setzen: welche Daten verwendet werden dürfen, welche Anwendungen in der Anbieter-Cloud laufen dürfen, wann eine Anwendung in die eigene Infrastruktur überführt wird und wer für Betrieb, Sicherheit und Pflege zuständig ist. Ohne diesen Rahmen entstehen schnell Anwendungen, die zwar funktionieren, aber niemandem gehören. Die folgenden Kapitel zeigen, wie sich dieser Rahmen für Lazy AI konkret ausgestalten lässt.
Im Mittelpunkt steht der Builder, eine Browser-Oberfläche, in der Nutzer mit der KI im Dialog an ihrer Anwendung arbeiten. Eine typische Sitzung beginnt mit einer Beschreibung oder der Auswahl einer Vorlage. Die KI erzeugt daraus den Code, startet die Anwendung in einer Testumgebung und zeigt das Ergebnis. Danach folgt ein iterativer Prozess: Der Nutzer beschreibt, was fehlt oder falsch ist, die KI passt den Code an, und die Vorschau wird aktualisiert. Fehlermeldungen aus der Laufzeit können zurück an die KI gegeben werden, die daraufhin einen Korrekturvorschlag macht.
Für technisch versierte Nutzer ist entscheidend, dass der Code nicht hinter einer visuellen Oberfläche verborgen bleibt. Nach unserem Kenntnisstand lässt sich der erzeugte Code in Lazy AI einsehen und gezielt verändern. Das ist ein wesentlicher Unterschied zu klassischen No-Code-Werkzeugen, bei denen die Logik in proprietären Modellen steckt. Es bedeutet aber auch, dass die Qualität des Ergebnisses so gut oder so schlecht ist wie der erzeugte Code, mit allen Konsequenzen für Sicherheit und Wartung.
Die Vorlagen-Bibliothek ist für viele Nutzer der eigentliche Einstieg. Statt mit einer leeren Seite zu beginnen, wählt man eine Anwendung, die dem Ziel nahekommt, und passt sie an. Das spart Zeit und erhöht die Chance auf ein funktionierendes Ergebnis, weil die Vorlage bereits eine lauffähige Struktur mitbringt. Für Unternehmen hat dieser Weg allerdings eine Kehrseite: Vorlagen bringen Abhängigkeiten, Bibliotheken und Annahmen mit, die nicht immer offensichtlich sind. Wer eine Community-Vorlage als Grundlage für eine interne Anwendung nutzt, sollte prüfen, welche externen Dienste sie anspricht, welche Pakete sie lädt und ob ihre Lizenz eine geschäftliche Nutzung erlaubt.
Lazy AI positioniert sich als Werkzeug für alle, die schnell eine funktionierende Anwendung brauchen, vom Gründer mit einer Produktidee über Entwickler, die Routinearbeit abgeben wollen, bis zu Fachanwendern ohne Programmierkenntnisse. Diese breite Zielgruppe ist zugleich Stärke und Herausforderung. Für Einsteiger ist die Plattform zugänglich, für Profis bietet sie eine Abkürzung bei Standardaufgaben. Für Unternehmen bedeutet das aber auch, dass die Plattform nicht primär auf die Anforderungen größerer Organisationen zugeschnitten ist. Funktionen wie zentrale Benutzerverwaltung, Rollen, Freigabeprozesse, Protokollierung und vertragliche Zusicherungen zum Datenstandort sollten Sie deshalb gezielt nachfragen, statt sie vorauszusetzen.
Die Kernfunktion ist die Erzeugung einer vollständigen Anwendung aus einer Beschreibung. Je präziser die Beschreibung, desto brauchbarer das Ergebnis. Eine Anweisung wie „baue ein Werkzeug für Urlaubsanträge“ führt zu einem generischen Entwurf, während eine Beschreibung mit Feldern, Rollen, Genehmigungsschritten und Benachrichtigungen ein deutlich treffenderes Ergebnis liefert. In der Praxis bewährt sich ein schrittweises Vorgehen: zuerst ein einfacher Kern, dann gezielte Erweiterungen. Wer versucht, eine komplexe Anwendung in einer einzigen Anweisung zu beschreiben, erhält oft ein Ergebnis, das an vielen Stellen nachgebessert werden muss.
Änderungen erfolgen ebenfalls per Anweisung. Die KI analysiert den bestehenden Code, nimmt die gewünschte Änderung vor und startet die Anwendung neu. Bei kleinen, klar umrissenen Änderungen funktioniert das erfahrungsgemäß gut. Bei größeren Umbauten steigt das Risiko, dass die KI an anderer Stelle etwas verändert oder bestehende Funktionen beschädigt. Deshalb ist es sinnvoll, nach jeder größeren Änderung die wichtigsten Abläufe der Anwendung kurz durchzuspielen und funktionierende Zwischenstände festzuhalten.
Eine Besonderheit von Lazy AI ist nach unserem Eindruck die Stärke bei Anwendungen ohne aufwendige Oberfläche. Dazu gehören Bots für Messenger und Team-Chats, kleine Schnittstellen-Dienste, die Daten zwischen Systemen weiterreichen, geplante Aufgaben, die regelmäßig Daten abrufen und auswerten, sowie Webhook-Empfänger, die auf Ereignisse in anderen Systemen reagieren. Solche Anwendungen sind im Unternehmensalltag häufig, werden aber selten als eigenes Projekt aufgesetzt, weil der Aufwand für Infrastruktur und Bereitstellung im Verhältnis zur eigentlichen Logik zu hoch erscheint.
Genau hier kann Lazy AI den Aufwand drastisch reduzieren. Die Logik wird beschrieben, die Plattform kümmert sich um Laufzeit und Erreichbarkeit. Zu beachten ist allerdings, dass solche Dienste oft Zugangsdaten zu produktiven Systemen benötigen. Wer einem Bot Lesezugriff auf das Ticketsystem oder Schreibzugriff auf eine Datenbank gibt, sollte dafür eigene, eng begrenzte Zugänge anlegen und diese nicht mit persönlichen Administratorkonten verknüpfen.
Neben Hintergrunddiensten erzeugt Lazy AI auch Anwendungen mit Bedienoberfläche, etwa Formulare, Übersichtsseiten oder einfache Dashboards. Die gestalterischen Möglichkeiten sind nach unserem Eindruck eher funktional als ausgefeilt, was für interne Werkzeuge meist ausreicht. Für die Datenhaltung können je nach Anwendung einfache Speicherlösungen der Plattform oder externe Datenbanken angebunden werden. Welche Speicheroptionen aktuell angeboten werden und wo die Daten physisch liegen, sollten Sie vor der Nutzung mit echten Unternehmensdaten klären.
Ein weiterer Anwendungsbereich sind KI-gestützte Anwendungen, also Werkzeuge, die selbst wieder Sprachmodelle nutzen, etwa zum Zusammenfassen von Dokumenten, zum Klassifizieren eingehender Anfragen oder als Frage-Antwort-Assistent. Dabei entsteht eine doppelte Datenkette: Die Plattform verarbeitet den Code, und die Anwendung schickt zur Laufzeit Inhalte an einen Modellanbieter. Beide Ketten müssen datenschutzrechtlich betrachtet werden, wie Kapitel 09 zeigt.
Lazy AI nutzt für die Code-Erzeugung große Sprachmodelle. Welche Modelle konkret zum Einsatz kommen, ob der Anbieter eigene Anpassungen vornimmt und ob Nutzer zwischen Modellen wählen können, ist nach unserem Kenntnisstand nicht durchgängig transparent dokumentiert und kann sich ändern. Für Unternehmen ist diese Frage nicht nur technisch, sondern vor allem datenschutzrechtlich relevant: Jede Anweisung und jeder Codeausschnitt, der an ein Modell geht, verlässt die Plattform in Richtung eines weiteren Dienstleisters. Fragen Sie deshalb gezielt nach den eingesetzten Modellanbietern, deren Standort und den vertraglichen Zusicherungen zur Nicht-Verwendung Ihrer Daten für Trainingszwecke.
Die automatische Korrekturschleife ist eine der praktischsten Funktionen, hat aber klare Grenzen. Sprachmodelle beheben Syntaxfehler, fehlende Abhängigkeiten und offensichtliche Laufzeitfehler meist zuverlässig. Schwieriger wird es bei fachlichen Fehlern, die keine Fehlermeldung erzeugen: eine falsch berechnete Summe, eine Rundung an der falschen Stelle, eine Berechtigung, die zu weit gefasst ist. Solche Fehler erkennt nur, wer die Anwendung fachlich prüft. Hinzu kommt ein bekanntes Muster: Wenn die KI an einem Problem mehrfach scheitert, neigt sie dazu, immer neue Varianten auszuprobieren und den Code dabei unübersichtlicher zu machen. Spätestens dann lohnt es sich, einen Schritt zurückzugehen, auf einen funktionierenden Stand zurückzusetzen und die Aufgabe kleiner zu formulieren.
Code aus Prompt-to-App-Plattformen ist nicht automatisch unsicher, aber er wird selten mit derselben Sorgfalt geprüft wie von Menschen geschriebener Code. Typische Schwachstellen in generierten Anwendungen sind fehlende Authentifizierung, offen erreichbare Verwaltungsfunktionen, unzureichende Prüfung von Eingaben, im Code hinterlegte Zugangsdaten und veraltete Abhängigkeiten. Gerade weil die Anwendung nach wenigen Minuten öffentlich erreichbar sein kann, ist das Risiko real. Unsere Empfehlung: Jede Anwendung, die mit Unternehmensdaten arbeitet oder aus dem Internet erreichbar ist, sollte vor dem produktiven Einsatz mindestens eine kurze Sicherheitsprüfung durchlaufen, idealerweise ergänzt um einen automatischen Scan der Abhängigkeiten.
Da Lazy AI Code erzeugt, kann eine Anwendung grundsätzlich jede Schnittstelle ansprechen, die über das Internet erreichbar ist und für die eine Bibliothek oder Dokumentation existiert. In der Praxis beschreibt man der KI, welcher Dienst angebunden werden soll, und hinterlegt die nötigen Zugangsdaten in der Geheimnisverwaltung der Plattform. Wichtig ist, diese Zugangsdaten niemals in die Anweisung selbst oder direkt in den Code zu schreiben, weil sie sonst in Verläufen, Protokollen oder Exporten auftauchen können.
Für den Zugriff auf interne Systeme wie ein ERP im eigenen Rechenzentrum stellt sich eine zusätzliche Frage: Eine Anwendung in der Anbieter-Cloud kann ein internes System nur erreichen, wenn dieses aus dem Internet zugänglich ist. Interne Systeme dafür zu öffnen, ist in den meisten Fällen keine gute Idee. Sinnvoller ist eine abgesicherte Zwischenschicht, etwa eine bestehende Schnittstellenplattform oder ein bewusst eingerichteter, eng begrenzter Endpunkt, oder die Überführung der Anwendung in die eigene Infrastruktur.
Die wichtigste Integration aus Unternehmenssicht ist der Weg aus der Plattform hinaus. Solange eine Anwendung ausschließlich in der Umgebung des Anbieters existiert, hängt sie vollständig von dessen Verfügbarkeit, Preisen und Geschäftsentwicklung ab. Prüfen Sie deshalb vor dem ersten ernsthaften Einsatz, ob der vollständige Quellcode inklusive Konfiguration exportiert werden kann, ob eine Anbindung an eine Versionsverwaltung wie Git möglich ist und ob die exportierte Anwendung ohne plattformspezifische Bibliotheken lauffähig bleibt. Ein kurzer Testexport mit einer Beispielanwendung schafft hier mehr Klarheit als jede Produktbeschreibung.
In vielen Unternehmen existieren bereits Werkzeuge für Automatisierung, etwa Workflow-Plattformen, Low-Code-Umgebungen aus dem Microsoft-Ökosystem oder eigene Integrationsdienste. Lazy AI tritt hier nicht zwingend in Konkurrenz, sondern kann eine Ergänzung sein: für Aufgaben, die mit visuellen Workflow-Bausteinen umständlich werden, oder für Prototypen, die später in die Standardplattform überführt werden. Entscheidend ist, dass die IT einen Überblick behält, welche Anwendungen wo laufen und welche Systeme sie berühren. Ein einfaches Register aller Prompt-to-App-Anwendungen mit Verantwortlichen, Datenquellen und Zugängen ist dafür oft ausreichend.
Bolt.new, Lovable und v0 haben ihren Schwerpunkt nach unserem Eindruck stärker auf modernen Web-Oberflächen. Sie richten sich an Produktteams, die einen klickbaren Prototyp oder eine erste Version einer Web-Anwendung mit ansprechender Oberfläche benötigen. Lazy AI ist dagegen besonders dort stark, wo die Logik im Vordergrund steht und die Oberfläche zweitrangig ist: Bots, Schnittstellen-Dienste, regelmäßige Aufgaben. Replit nimmt eine Sonderrolle ein, weil es eine vollwertige Entwicklungsumgebung im Browser mit einem KI-Agenten verbindet und damit sowohl Einsteiger als auch erfahrene Entwickler anspricht. GitHub Spark verfolgt einen ähnlichen Ansatz für kleine persönliche Anwendungen im GitHub-Ökosystem.
Für die Auswahl ist weniger die einzelne Funktion entscheidend als die Frage, welche Art von Anwendung überwiegend entstehen soll und wie gut das Werkzeug zur bestehenden Infrastruktur passt. Unternehmen, die bereits stark auf GitHub oder Vercel setzen, finden bei den dort verankerten Werkzeugen eine engere Einbindung. Wer vor allem kleine Automatisierungen und Bots für Fachbereiche benötigt, sollte Lazy AI in die engere Wahl nehmen und mit einem konkreten Anwendungsfall gegen eine Alternative testen.
Coding-Assistenten wie GitHub Copilot, Cursor, Windsurf oder Claude Code arbeiten in der Entwicklungsumgebung oder auf der Kommandozeile des Entwicklers und greifen auf bestehende Repositorys zu. Sie eignen sich für die Weiterentwicklung großer, langlebiger Systeme mit etablierten Prozessen für Versionierung, Tests und Bereitstellung. Prompt-to-App-Plattformen setzen früher an: Sie schaffen die Anwendung, die es vorher nicht gab. Beide Ansätze schließen sich nicht aus. Ein sinnvolles Muster ist, eine Anwendung in Lazy AI als Prototyp zu erzeugen, sie bei Erfolg zu exportieren und in einem eigenen Repository mit einem klassischen Coding-Assistenten weiterzuentwickeln.
Low-Code-Plattformen wie Microsoft Power Apps, Mendix oder OutSystems verfolgen ein ähnliches Ziel, nämlich Anwendungen ohne klassische Programmierung zu ermöglichen. Sie arbeiten jedoch mit visuellen Modellen in einer geschlossenen Plattform, bringen ausgereifte Funktionen für Benutzerverwaltung, Rechte und Governance mit und sind häufig bereits in die Unternehmens-IT eingebunden. Prompt-to-App-Plattformen sind flexibler, weil sie echten Code erzeugen, und schneller im Einstieg, aber in Sachen Governance und Unternehmensintegration meist weniger ausgereift. Für Unternehmen mit etablierter Low-Code-Strategie ist Lazy AI deshalb eher eine Ergänzung für Sonderfälle und Prototypen als ein Ersatz.
Der einfachste Weg ist, Anwendungen direkt in der Cloud von Lazy AI zu erstellen und zu betreiben. Das ist für Prototypen, Demos und Anwendungen ohne personenbezogene oder vertrauliche Daten vertretbar. Sobald echte Kundendaten, Mitarbeiterdaten oder vertrauliche Geschäftsinformationen verarbeitet werden, sollten Sie prüfen, wo die Plattform rechnet und speichert, welche Verträge zur Auftragsverarbeitung angeboten werden und welche Subprozessoren beteiligt sind. Ein Self-Hosting der Plattform selbst ist nach unserem Kenntnisstand nicht das primäre Angebot; ob es Enterprise-Varianten mit dedizierter Umgebung oder Regionswahl gibt, klären Sie bitte direkt mit dem Anbieter.
Die datenschutzfreundlichere Alternative ist ein zweistufiges Modell: Die Anwendung wird in der Plattform mit Testdaten entwickelt, anschließend exportiert und in einer eigenen Umgebung betrieben, etwa bei einem Cloud-Anbieter mit Rechenzentrum in der EU oder auf eigenen Servern. Damit verlassen nur Code und Anweisungen, nicht aber die produktiven Daten das Unternehmen. Voraussetzung ist ein funktionierender Export und jemand, der die Anwendung in der eigenen Umgebung betreiben kann.
Die größte Gefahr bei Prompt-to-App-Anwendungen liegt nicht im ersten Tag, sondern im zweiten Jahr. Eine schnell erstellte Anwendung wird genutzt, gewinnt an Bedeutung, und irgendwann hängt ein Prozess an ihr. Wenn dann die Person, die sie gebaut hat, das Unternehmen verlässt, eine Schnittstelle sich ändert oder eine Abhängigkeit eine Sicherheitslücke aufweist, fehlt oft jemand, der sich zuständig fühlt. Planen Sie deshalb von Anfang an, wer eine Anwendung pflegt, wie Aktualisierungen erfolgen und wann eine Anwendung entweder in eine professionelle Entwicklung überführt oder bewusst abgeschaltet wird. Ein einfaches Kriterium: Sobald ein Geschäftsprozess ohne die Anwendung nicht mehr funktioniert, gehört sie in die Verantwortung der IT.
Ein typisches Beispiel ist ein Produktionsbetrieb mit 200 Mitarbeitenden, in dem die IT aus drei Personen besteht, die vollständig mit ERP, Netzwerk und Arbeitsplätzen ausgelastet sind. Die Qualitätssicherung erfasst Reklamationen bisher in einer Tabelle, die per E-Mail herumgeschickt wird. Mit Lazy AI baut eine technisch interessierte Mitarbeiterin der Qualitätssicherung gemeinsam mit einer Person aus der IT eine kleine Anwendung: Erfassungsformular, Übersicht offener Fälle, automatische Benachrichtigung an die zuständige Abteilung. Der erste lauffähige Stand entsteht an einem Nachmittag, die Verfeinerung zieht sich über einige Tage.
Entscheidend für den Erfolg ist in diesem Szenario nicht die Geschwindigkeit, sondern der Rahmen. Die Anwendung verarbeitet Lieferantendaten und gelegentlich Namen von Ansprechpartnern, also personenbezogene Daten. Deshalb wird sie nach der Entwicklung exportiert und auf einem Server in der EU betrieben, den die IT ohnehin verwaltet. Die IT prüft Anmeldung und Zugriffsrechte, die Qualitätssicherung bleibt fachlich verantwortlich. So entsteht kein Wildwuchs, sondern eine kleine, dokumentierte Lösung mit klarer Zuständigkeit.
Für Dienstleister, Ingenieurbüros oder Softwarehäuser im Mittelstand ist Lazy AI ein Werkzeug, um Ideen mit Kunden schneller greifbar zu machen. Statt einer Präsentation mit Bildschirmentwürfen wird im Workshop ein funktionierender Prototyp gezeigt, der echte Interaktion erlaubt. Das verbessert die Qualität der Anforderungen und reduziert Missverständnisse. Wichtig ist, gegenüber dem Kunden klar zu kommunizieren, dass ein Prototyp kein Produkt ist. Der generierte Code kann als Ausgangspunkt dienen, sollte aber vor einem produktiven Einsatz überarbeitet, getestet und in eine ordentliche Entwicklungs- und Bereitstellungskette überführt werden. Zudem dürfen im Prototyp keine echten Kundendaten verwendet werden, solange die Datenschutzfragen nicht geklärt sind.
In vielen Unternehmen entstehen kleine Automatisierungen ohnehin, oft mit privaten Konten, kostenlosen Diensten und ohne Wissen der IT. Eine bewusst eingeführte Prompt-to-App-Plattform kann diese Schatten-IT in geordnete Bahnen lenken. Statt Verbote auszusprechen, bietet die IT einen freigegebenen Weg an: ein Unternehmenskonto, klare Regeln für Daten und Zugänge, ein Register und eine Anlaufstelle für Fragen. Erfahrungsgemäß sind Fachbereiche eher bereit, Regeln einzuhalten, wenn es einen einfachen, offiziellen Weg gibt.
Kostenmodell realistisch einschätzen. Lazy AI bietet nach unserem Kenntnisstand einen kostenlosen oder sehr günstigen Einstieg sowie kostenpflichtige Tarife mit höheren Kontingenten für KI-Anfragen, mehr Anwendungen oder erweiterten Betriebsfunktionen. Bei Prompt-to-App-Plattformen ist der Verbrauch an KI-Anfragen häufig der entscheidende Kostentreiber: Jede Iteration, jede Fehlerkorrektur und jede Änderung verbraucht Kontingent. Hinzu kommen gegebenenfalls Kosten für den Betrieb der Anwendungen in der Anbieter-Cloud, für externe Dienste wie Sprachmodelle in der eigenen Anwendung und für den Betrieb exportierter Anwendungen in eigener Infrastruktur. Konkrete Preise, Kontingente und Tarifgrenzen ändern sich in diesem Markt häufig; prüfen Sie die aktuellen Konditionen direkt beim Anbieter.
Für die Wirtschaftlichkeit zählt weniger der Lizenzpreis als der Vergleich mit der Alternative. Eine kleine Anwendung, die einer Abteilung pro Woche einige Stunden manueller Arbeit erspart, rechnet sich schnell, selbst wenn Prüfung und Betrieb zusätzlichen Aufwand verursachen. Unterschätzt wird dagegen oft der Folgeaufwand: Pflege, Aktualisierungen, Sicherheitsprüfungen und gegebenenfalls die spätere Überführung in eine professionelle Entwicklung. Planen Sie diesen Aufwand von Anfang an mit ein.
Lazy AI ist nach unserem Kenntnisstand kein Anbieter mit Sitz und Rechenzentren ausschließlich in der EU. Prüfen Sie deshalb vor der Nutzung mit echten Daten, wo die Plattform den Code erzeugt, wo Anwendungen betrieben und Daten gespeichert werden, welche Cloud-Infrastruktur zugrunde liegt und welche Modellanbieter für die Code-Erzeugung eingesetzt werden. Liegen Verarbeitung oder Speicherung in den USA oder anderen Drittstaaten, stellen sich die bekannten Fragen nach einer tragfähigen Rechtsgrundlage für den Transfer, etwa über das EU-US Data Privacy Framework, soweit der jeweilige Dienstleister zertifiziert ist, oder über Standardvertragsklauseln mit ergänzender Risikobewertung. Ebenso wichtig sind ein Vertrag zur Auftragsverarbeitung, eine Liste der Subprozessoren, Zusicherungen zur Nicht-Verwendung Ihrer Daten für das Training von Modellen und klare Regeln zur Löschung.
Aus Sicht der Datensouveränität ist das zweistufige Modell aus Kapitel 07 die DSGVO-konformere Option: Entwicklung in der Plattform ausschließlich mit Test- oder Beispieldaten, Betrieb der exportierten Anwendung in einer EU-Region oder in der eigenen Infrastruktur. Werden in der Anwendung selbst Sprachmodelle genutzt, sollten diese ebenfalls über einen Anbieter mit EU-Rechenzentrum oder als lokal betriebene Modelle angebunden werden. So bleibt zumindest die Verarbeitung der produktiven Daten unter eigener Kontrolle.
Auch wenn eine Anwendung keine personenbezogenen Daten verarbeitet, kann sie schützenswert sein. Beschreibungen von Abläufen, Kalkulationslogiken, Schnittstellen zu internen Systemen und der erzeugte Quellcode selbst enthalten Wissen, das im Sinne des Geschäftsgeheimnisgesetzes angemessen geschützt werden muss. Wer interne Preisregeln, Rezepturen, Fertigungsparameter oder Kundenstrukturen in Anweisungen an eine Cloud-Plattform beschreibt, gibt dieses Wissen an Dritte weiter. Klären Sie deshalb vertraglich, wem der erzeugte Code gehört, welche Nutzungsrechte der Anbieter an Ihren Eingaben und Ergebnissen beansprucht, ob Projekte öffentlich sichtbar sein können und wie Sie Ihre Daten bei Vertragsende vollständig erhalten und löschen lassen. Achten Sie besonders darauf, dass interne Anwendungen nicht versehentlich als öffentliche Vorlage oder öffentlich erreichbare Anwendung freigegeben werden.
Jede produktiv genutzte Anwendung, die personenbezogene Daten verarbeitet, gehört in das Verzeichnis von Verarbeitungstätigkeiten, unabhängig davon, ob sie in drei Wochen oder in drei Stunden entstanden ist. Werden mit einer Anwendung Leistung oder Verhalten von Beschäftigten erfasst oder ausgewertet, ist in Deutschland in der Regel der Betriebsrat zu beteiligen. Für die Plattform selbst sind die Anforderungen aus dem EU AI Act überschaubar, solange sie zur Erzeugung von Software genutzt wird. Anders kann es aussehen, wenn die erzeugte Anwendung selbst KI-Funktionen in sensiblen Bereichen einsetzt, etwa bei der Bewertung von Bewerbern oder bei Entscheidungen über Beschäftigte. In solchen Fällen ist eine gesonderte Prüfung notwendig. Zudem verlangt der AI Act von Unternehmen, die KI einsetzen, ein angemessenes Maß an KI-Kompetenz bei den Beschäftigten, was für Fachanwender, die Anwendungen per Prompt erzeugen, gezielte Schulungen nahelegt.
