Wer in den letzten Jahren ein Softwareprojekt begleitet hat, kennt den klassischen Ablauf. Zuerst entstehen Wireframes, dann gestaltete Entwürfe in einem Designwerkzeug, anschließend ein klickbarer Prototyp, und erst danach beginnt die Entwicklung, die das Ganze in Code übersetzt. An jeder dieser Übergaben geht Information verloren: Abstände werden geschätzt, Zustände wie Ladeanzeigen oder Fehlermeldungen fehlen im Entwurf, und Entwicklerinnen und Entwickler bauen Komponenten nach, die es so im Designsystem eigentlich schon gibt. Werkzeuge wie MagicPath setzen genau an diesen Bruchstellen an. Sie erzeugen Entwürfe, die von Anfang an aus Code bestehen, und verkürzen so den Weg von der Idee zum funktionierenden Frontend.
Zum Anbieter selbst sind öffentlich vergleichsweise wenige belastbare Angaben verfügbar. Nach unserem Kenntnisstand handelt es sich um ein junges Unternehmen mit Sitz in den USA, das MagicPath ab 2025 als Cloud-Dienst gestartet hat und das stark aus der Designer-Community heraus entwickelt wurde. Produktumfang, Tarife und technische Details haben sich seit dem Start mehrfach verändert, wie bei fast allen Werkzeugen dieser Generation. Wir beschreiben MagicPath deshalb bewusst entlang seiner Arbeitsweise und ordnen es in die Kategorie ein; konkrete Funktionsdetails, Exportformate und Vertragsbedingungen sollten vor einer Entscheidung immer beim Anbieter geprüft werden. Drei Merkmale prägen das Werkzeug:
KI-gestützte UI-Generierung ist kein einzelnes Produkt, sondern ein Sammelbegriff für Werkzeuge, die Benutzeroberflächen aus Beschreibungen, Bildern oder bestehenden Designs erzeugen. Grob lassen sich drei Richtungen unterscheiden. Die erste Richtung sind Code-zentrierte Generatoren wie v0 von Vercel, die aus einem Prompt direkt Komponenten für einen bestimmten Technologie-Stack erzeugen und eng mit einer Hosting-Plattform verbunden sind. Die zweite Richtung sind App-Builder wie Lovable oder Bolt, die nicht nur die Oberfläche, sondern eine komplette Anwendung mit Datenbank, Anmeldung und Veröffentlichung liefern. Die dritte Richtung sind designzentrierte Werkzeuge, zu denen MagicPath gehört: Sie stellen den visuellen Entwurf und das Vergleichen von Varianten in den Mittelpunkt und behandeln Code als das Material, aus dem diese Entwürfe bestehen.
Daneben haben auch die etablierten Designwerkzeuge KI-Funktionen ergänzt, und Anbieter wie Builder.io übersetzen bestehende Figma-Entwürfe in Code. Die Grenzen zwischen diesen Richtungen verschwimmen zunehmend, weil fast alle Werkzeuge in Richtung der jeweils anderen wachsen. Für die Auswahl im Unternehmen ist es dennoch hilfreich, die Grundorientierung eines Werkzeugs zu kennen: Wer vor allem gestalten und vergleichen will, braucht etwas anderes als jemand, der bis Freitag eine lauffähige interne Anwendung veröffentlichen muss.
Viele mittelständische Unternehmen haben keine eigene UX-Abteilung. Oberflächen für Kundenportale, Konfiguratoren, interne Werkzeuge oder Maschinenbedienungen entstehen oft direkt in der Entwicklung oder werden bei einer Agentur beauftragt. Das führt zu zwei typischen Problemen: Entweder wird zu wenig über die Oberfläche nachgedacht, bevor programmiert wird, oder die Abstimmung über Entwürfe dauert Wochen, weil jede Änderungsrunde Geld und Zeit kostet. KI-gestützte UI-Generierung verändert diese Rechnung. Eine Produktverantwortliche kann in einer Stunde fünf Varianten eines Bestellprozesses zeigen, die Fachabteilung kann direkt darauf reagieren, und das Entwicklungsteam erhält einen Ausgangspunkt, der bereits aus Komponenten besteht.
Gleichzeitig entstehen neue Risiken. Wenn Entwürfe so schnell entstehen, sinkt die Hemmschwelle, unfertige Oberflächen ohne Prüfung zu übernehmen. Barrierefreiheit, Konsistenz mit dem Corporate Design und saubere Code-Struktur fallen nicht automatisch ab. Hinzu kommen Fragen nach dem Schutz von Produktideen, Kundendaten in Screenshots und der Verarbeitung bei einem Anbieter außerhalb der EU. Dieser Artikel ordnet beide Seiten ein, damit die Entscheidung für oder gegen ein Werkzeug wie MagicPath auf einer realistischen Grundlage getroffen werden kann.
Im Kern bietet MagicPath eine Arbeitsfläche im Browser, auf der Projekte angelegt werden. Innerhalb eines Projekts entstehen Bildschirme und Komponenten, die man per Prompt erzeugt, verändert und verfeinert. Die Ergebnisse lassen sich über Links teilen, als Vorschau anklicken und, je nach Tarif, als Code exportieren oder in andere Werkzeuge übernehmen. Eine lokale Installation oder eine Version für den Betrieb im eigenen Rechenzentrum ist nach unserem Kenntnisstand nicht vorgesehen. MagicPath ist damit ein reiner Cloud-Dienst, was für die Datenschutzbewertung in Kapitel 09 eine zentrale Rolle spielt.
Wie bei vielen KI-Werkzeugen ist das Abrechnungsmodell an die Rechenleistung gekoppelt, die die Generierung verbraucht. Das bedeutet in der Praxis: Je mehr Varianten erzeugt, je größer die Bildschirme und je leistungsfähiger die gewählten Modelle, desto schneller ist ein Kontingent aufgebraucht. Für eine realistische Kostenschätzung sollte deshalb in einem Pilot gemessen werden, wie viele Generierungen ein typisches Projekt tatsächlich benötigt.
MagicPath richtet sich nach Auftritt und Funktionsumfang vor allem an Designerinnen und Designer, Produktverantwortliche und Frontend-Entwickler, die visuell denken. Das Werkzeug versteht sich nicht als Plattform, auf der fertige Anwendungen betrieben werden, sondern als Ort, an dem Oberflächen entstehen, verglichen und verfeinert werden. Der Code ist dabei das Bindeglied zur Entwicklung. Diese Positionierung unterscheidet MagicPath von App-Buildern, die eine komplette Anwendung inklusive Datenbank und Hosting versprechen, und von klassischen Designprogrammen, deren Ergebnis zunächst ein Bild ist, das erst noch in Code übersetzt werden muss.
Für Unternehmen hat diese Positionierung eine klare Konsequenz: MagicPath ersetzt weder das Designwerkzeug, in dem das Corporate Design gepflegt wird, noch die Entwicklungsumgebung, in der die eigentliche Anwendung entsteht. Es schiebt sich als neue Station dazwischen. Ob sich diese zusätzliche Station lohnt, hängt davon ab, wie viel Zeit heute in der Abstimmung über Oberflächen und in der Übersetzung von Entwürfen in Code verloren geht. In Teams, die Oberflächen ohnehin direkt im Code bauen, ist der Mehrwert kleiner als in Organisationen mit langen Abstimmungsschleifen zwischen Fachabteilung, Design und Entwicklung.
Das auffälligste Merkmal von MagicPath ist die räumliche Arbeitsweise. Statt einer linearen Abfolge von Chatnachrichten, bei der ältere Versionen nach oben aus dem Blick verschwinden, liegen alle Entwürfe auf einer gemeinsamen Fläche. Man kann hineinzoomen, um ein einzelnes Eingabefeld zu betrachten, oder herauszoomen, um einen ganzen Prozess mit Startseite, Formular, Bestätigung und Fehlermeldung auf einen Blick zu sehen. Varianten lassen sich nebeneinander anordnen und direkt vergleichen.
Diese Arbeitsweise kommt dem Denken in Design-Workshops deutlich näher als ein Chatfenster. In einem Termin mit der Fachabteilung lassen sich so drei Ansätze für ein Dashboard nebeneinanderstellen, Rückmeldungen direkt umsetzen und die gewählte Richtung weiterentwickeln, während die verworfenen Varianten als Dokumentation der Entscheidung erhalten bleiben. Gerade in Organisationen, in denen viele Beteiligte mitreden, ist diese Nachvollziehbarkeit ein unterschätzter Vorteil.
Die Generierung beginnt typischerweise mit einer Beschreibung, etwa „eine Übersichtsseite für Serviceaufträge mit Filterleiste, Statusanzeigen und einer Tabelle der offenen Einsätze“. Die KI erzeugt daraus einen Bildschirm mit plausiblen Inhalten, Platzhalterdaten und einer ersten Gestaltung. Alternativ kann eine Bildvorlage dienen: ein Foto einer Whiteboard-Skizze, ein Screenshot einer bestehenden Anwendung oder eine Referenz, deren Stil man übernehmen möchte. Gerade die Arbeit mit Screenshots ist für den Mittelstand interessant, weil sich so veraltete Masken aus Bestandssystemen schnell in eine moderne Oberfläche übersetzen lassen, die als Diskussionsgrundlage für eine Modernisierung dient.
Wichtig für die Erwartungshaltung: Die KI interpretiert. Sie übernimmt nicht pixelgenau, sondern erzeugt eine eigene Umsetzung dessen, was sie in der Vorlage erkennt. Bei einfachen Layouts ist das Ergebnis oft verblüffend nah, bei dichten Fachanwendungen mit vielen Feldern, Abhängigkeiten und Sonderfällen fehlen dagegen regelmäßig Details. Der Entwurf ist deshalb immer ein Startpunkt, der fachlich geprüft werden muss.
Damit aus vielen schnellen Entwürfen kein Flickenteppich entsteht, bietet MagicPath Möglichkeiten, gestalterische Vorgaben zu hinterlegen. Dazu gehören Farbpaletten, Schriften, Rundungen, Abstände und ein allgemeiner Stil, der bei neuen Generierungen berücksichtigt wird. Wiederkehrende Elemente wie Navigationsleisten, Karten oder Tabellen können als Komponenten wiederverwendet werden. In welcher Tiefe sich ein bestehendes Designsystem eines Unternehmens abbilden lässt, ist eine der wichtigsten Fragen für einen Pilot, denn davon hängt ab, ob die Ergebnisse später ohne großen Umbau in die eigene Anwendung passen.
Für die Übergabe stehen nach unserem Kenntnisstand mehrere Wege zur Verfügung: interaktive Vorschauen, die per Link geteilt werden, der Export von Komponenten als Code sowie Übernahmen in andere Werkzeuge. Die genauen Formate und Zielsysteme haben sich seit dem Start mehrfach erweitert. Vor einer Entscheidung sollte geprüft werden, ob der exportierte Code zum eigenen Technologie-Stack passt, wie er strukturiert ist und welche Abhängigkeiten er mitbringt. Ein Team, das mit Angular oder klassischen serverseitigen Templates arbeitet, profitiert vom Code-Export weniger als ein Team, das ohnehin auf React setzt.
Technisch betrachtet ist UI-Generierung eine Spezialform der Code-Generierung. Große Sprachmodelle haben im Training enorme Mengen an Frontend-Code gesehen und können daher plausiblen Code für Oberflächen schreiben. Werkzeuge wie MagicPath ergänzen dieses Grundvermögen um eine Umgebung, die den Code sofort sichtbar macht, um Vorgaben, die den Stil steuern, und um Mechanismen, die einzelne Bereiche gezielt verändern, ohne das Ganze neu zu erzeugen. Der Vorteil dieses Ansatzes: Was man sieht, ist bereits lauffähig. Es gibt keine Lücke zwischen Bild und Umsetzung, die später geschlossen werden muss.
Daraus folgt aber auch eine wichtige Einschränkung. Das Modell optimiert auf ein plausibles Aussehen, nicht auf eine saubere Software-Architektur. Generierter Code ist häufig lang, wiederholt sich, enthält fest eingetragene Texte und Werte und folgt nicht automatisch den Konventionen eines bestehenden Projekts. Für einen Prototyp ist das unproblematisch, für produktive Software muss der Code dagegen überarbeitet werden: Komponenten zerlegen, Daten anbinden, Zustände ergänzen, Texte für Mehrsprachigkeit auslagern und Tests schreiben.
In unserer Beobachtung von Werkzeugen dieser Kategorie zeigen sich wiederkehrende Muster. Besonders gut gelingen visuell klar strukturierte Oberflächen wie Landingpages, Übersichtsseiten, Karten-Layouts, Einstellungsdialoge und einfache Formulare. Auch das Übertragen eines Stils auf neue Bildschirme und das Erzeugen ästhetisch ansprechender Varianten funktioniert meist überzeugend. Schwieriger wird es bei komplexer Fachlogik, etwa bei Formularen mit vielen voneinander abhängigen Feldern, bei Tabellen mit Sortierung, Filterung und Inline-Bearbeitung oder bei Abläufen, die über viele Schritte konsistente Zustände benötigen.
Ein weiterer Schwachpunkt ist die Barrierefreiheit. Generierte Oberflächen sehen oft gut aus, erfüllen aber nicht zuverlässig Anforderungen an Kontraste, Tastaturbedienung, Beschriftungen für Screenreader oder sinnvolle Überschriftenstrukturen. Seit das Barrierefreiheitsstärkungsgesetz für viele digitale Produkte und Dienstleistungen im Verbraucherbereich gilt, ist das kein Detail mehr. Wer generierte Oberflächen in Kundenanwendungen übernimmt, muss die Barrierefreiheit eigenständig prüfen und nachbessern.
Die Qualität der Ergebnisse hängt stark davon ab, wie präzise die Anforderung formuliert wird. Bewährt haben sich Beschreibungen, die Zweck, Nutzergruppe, Inhalte und Zustände nennen, etwa: wer nutzt den Bildschirm, welche Aufgabe soll erledigt werden, welche Daten werden angezeigt, welche Aktionen sind möglich und wie sieht der Bildschirm aus, wenn keine Daten vorhanden sind oder ein Fehler auftritt. Hilfreich sind außerdem Referenzen auf vorhandene Gestaltung und klare Hinweise auf das Zielgerät. Teams, die solche Vorlagen für typische Bildschirmarten sammeln, erreichen schneller konsistente Ergebnisse und verbrauchen weniger Kontingent für Korrekturschleifen.
In den meisten Unternehmen, die überhaupt systematisch gestalten, ist Figma das zentrale Werkzeug für Entwürfe und Designsysteme. Für ein Werkzeug wie MagicPath ist die Verbindung zu Figma deshalb in beide Richtungen relevant. Nach unserem Kenntnisstand lassen sich Ergebnisse aus MagicPath in Figma übernehmen, und vorhandene Gestaltung kann als Vorlage dienen. Wie verlustfrei diese Übergänge funktionieren, also ob Ebenen, Komponenten und Abstände sauber erhalten bleiben, sollte im Pilot mit echten Beispielen getestet werden. Für Teams ohne eigenes Designwerkzeug kann MagicPath selbst als Ort dienen, an dem die visuelle Richtung entsteht, sollte dann aber nicht die einzige Ablage für verbindliche Gestaltungsregeln sein.
Wichtig ist eine klare Rollenverteilung: Wo liegt die verbindliche Quelle für Farben, Schriften und Komponenten? In gut organisierten Teams ist das ein gepflegtes Designsystem, idealerweise mit Design-Tokens, die sowohl im Designwerkzeug als auch im Code verwendet werden. MagicPath sollte an diese Quelle angebunden werden, nicht zu einer zweiten, abweichenden Quelle werden.
Der exportierte Code basiert nach unserem Kenntnisstand auf React und einem Utility-CSS-Ansatz, wie er in modernen Frontend-Projekten verbreitet ist. Für Teams mit diesem Stack ist der Export unmittelbar nutzbar: Komponenten lassen sich in ein bestehendes Projekt kopieren, anpassen und weiterentwickeln. Teams mit anderen Frameworks können den Code als Referenz nutzen oder von einem Coding-Assistenten übersetzen lassen, verlieren dabei aber einen Teil des Geschwindigkeitsvorteils.
Unabhängig vom Stack gilt: Generierter Code gehört nicht unverändert in den Hauptzweig eines Produkts. Er sollte wie jeder andere Beitrag über einen Pull Request mit Review eingebracht werden. Sinnvoll ist eine Art Übergabeprotokoll, das festhält, welche Teile aus dem Generator stammen, welche Abhängigkeiten hinzugekommen sind und welche Nacharbeiten noch ausstehen, etwa Datenanbindung, Fehlerbehandlung, Übersetzbarkeit und Barrierefreiheit.
Besonders interessant wird KI-gestützte UI-Generierung im Zusammenspiel mit Coding-Assistenten wie Cursor, GitHub Copilot oder Claude Code. Der UI-Generator liefert die visuelle Richtung und einen Komponenten-Entwurf, der Coding-Assistent integriert diesen Entwurf in die bestehende Codebasis, ersetzt Platzhalter durch echte Datenquellen und passt die Struktur an vorhandene Konventionen an. Einige Anbieter in diesem Markt stellen dafür inzwischen Schnittstellen über das Model Context Protocol bereit, über die Coding-Assistenten direkt auf Entwürfe zugreifen können. Ob und in welchem Umfang MagicPath das aktuell unterstützt, sollte beim Anbieter geprüft werden.
Dieses Zusammenspiel verändert die Rollen im Team. Designerinnen und Designer arbeiten näher am Code, Entwicklerinnen und Entwickler übernehmen mehr Verantwortung für die Qualität der Integration statt für das Nachbauen von Entwürfen. Damit das funktioniert, braucht es gemeinsame Regeln: welche Komponenten aus dem Designsystem verwendet werden müssen, wann ein generierter Entwurf als freigegeben gilt und wer für Barrierefreiheit und Performance verantwortlich ist.
v0 von Vercel ist der naheliegendste Vergleich. Auch v0 erzeugt aus Prompts und Bildern Oberflächen auf Basis von React und verbreiteten Komponentenbibliotheken. Der Schwerpunkt liegt aber stärker auf dem Code und auf der Veröffentlichung über die Plattform des Anbieters. Wer bereits mit diesem Stack arbeitet und schnell zu produktionsnahem Code kommen will, ist mit v0 oft direkter am Ziel. MagicPath punktet dagegen beim visuellen Erkunden, beim Vergleichen vieler Varianten und bei der Arbeit von Personen, die eher gestalterisch als programmierend denken.
App-Builder wie Lovable, Bolt oder Replit gehen einen anderen Weg. Sie erzeugen nicht nur Oberflächen, sondern ganze Anwendungen mit Datenbank, Benutzerverwaltung und Veröffentlichung. Für interne Werkzeuge oder Prototypen, die echte Daten verarbeiten sollen, ist das attraktiv, bringt aber auch mehr Verantwortung mit sich: Sicherheit, Datenhaltung und Betrieb müssen mitgedacht werden. MagicPath hält sich bewusst aus diesem Bereich heraus und ist damit ein Werkzeug für die Gestaltung, nicht für den Betrieb.
Figma hat eigene KI-Funktionen ergänzt, mit denen sich Entwürfe erzeugen, Inhalte füllen und Prototypen schneller bauen lassen. Für Organisationen mit einem etablierten Designsystem in Figma ist das ein starkes Argument, weil kein neues Werkzeug eingeführt werden muss. Dienste wie Builder.io mit Visual Copilot setzen am anderen Ende an und übersetzen bestehende Figma-Entwürfe in Code. MagicPath liegt zwischen diesen Ansätzen: Es entwirft mit KI, aber der Entwurf ist von Beginn an Code. Daneben experimentieren auch große Plattformanbieter mit eigenen UI-Generatoren, und Ansätze wie GitHub Spark verbinden Oberflächen mit kleinen Anwendungen. Der Markt ist in Bewegung; eine Entscheidung sollte daher nicht auf Funktionslisten, sondern auf einem Vergleich mit eigenen Beispielen beruhen.
Die wichtigste Leitplanke für den Betrieb ist eine einfache, verständliche Regel, welche Inhalte in MagicPath verarbeitet werden dürfen. Unproblematisch sind in der Regel Prompts mit allgemeinen Beschreibungen und erfundene Platzhalterdaten. Vorsicht ist geboten bei Screenshots aus produktiven Systemen, die Kundennamen, Bestelldaten oder interne Kennzahlen zeigen, bei unveröffentlichten Produktkonzepten und bei Inhalten, die unter Geheimhaltungsvereinbarungen mit Kunden fallen. Solche Inhalte sollten vor der Nutzung geschwärzt oder durch Beispieldaten ersetzt werden.
Hilfreich ist ein kurzes internes Merkblatt mit Beispielen für erlaubte und unerlaubte Eingaben. Es senkt die Unsicherheit bei den Mitarbeitenden und reduziert das Risiko, dass vertrauliche Inhalte aus Bequemlichkeit hochgeladen werden. Ergänzend sollte geregelt werden, wer Konten anlegen darf, ob private Konten für dienstliche Zwecke erlaubt sind und wie Projekte bei einem Personalwechsel übergeben werden.
Der zweite Baustein des Betriebs ist die saubere Übergabe in die Entwicklung. Bewährt hat sich, Entwürfe aus MagicPath als Anhang an ein Ticket zu hängen, in dem fachliche Anforderungen, Zustände und Akzeptanzkriterien beschrieben sind. Der exportierte Code wird in einem eigenen Zweig eingebracht, von einem Coding-Assistenten oder einer Entwicklerin an die Projektkonventionen angepasst und über einen Pull Request mit Review übernommen. Automatisierte Prüfungen auf Barrierefreiheit, Code-Stil und Sicherheitsabhängigkeiten gehören in die Pipeline wie bei jedem anderen Code. Auf diese Weise bleibt der Geschwindigkeitsvorteil erhalten, ohne dass ungeprüfter Code in produktive Anwendungen gelangt.
Damit sich die Investition lohnt, sollten einige Voraussetzungen erfüllt sein. Erstens braucht es Personen, die gestalterisch urteilen können. Ein UI-Generator erzeugt viele Varianten, aber jemand muss entscheiden, welche davon zur Zielgruppe, zum Prozess und zum Unternehmen passt. Zweitens hilft ein zumindest grundlegendes Designsystem mit festgelegten Farben, Schriften und Komponenten, sonst entsteht mit jeder Generierung ein neuer Stil. Drittens muss der Weg in die Entwicklung geklärt sein. Ohne ein Team, das den Code übernimmt und weiterentwickelt, bleiben die Ergebnisse schöne Bilder.
Ebenso wichtig ist die Haltung im Team. KI-gestützte UI-Generierung verändert die Arbeit von Designerinnen, Entwicklern und Produktverantwortlichen. Wer das Werkzeug als Bedrohung wahrnimmt, nutzt es zögerlich; wer es als Erweiterung der eigenen Fähigkeiten versteht, entdeckt schnell neue Möglichkeiten. Eine offene Kommunikation über Ziele, Grenzen und die Rolle menschlicher Gestaltung ist deshalb Teil jeder erfolgreichen Einführung.
Der Erfolg lässt sich an wenigen, gut beobachtbaren Größen festmachen: der Zeit von der ersten Anforderung bis zum abgestimmten Entwurf, der Anzahl der Abstimmungsrunden, dem Anteil der Entwürfe, die tatsächlich in Code übernommen werden, und dem Nacharbeitsaufwand in der Entwicklung. Sinnvoll ist ein Vergleich mit einem Projekt, das auf dem bisherigen Weg umgesetzt wurde. Weiche Faktoren wie die Zufriedenheit der Fachabteilung mit dem Abstimmungsprozess gehören ebenfalls dazu, denn gerade dort zeigen UI-Generatoren oft ihren größten Effekt.
Realistisch betrachtet wird MagicPath in den meisten mittelständischen Unternehmen kein Werkzeug für alle sein. Es eignet sich für eine kleine Gruppe von Personen, die regelmäßig Oberflächen entwerfen oder abstimmen. Für diese Gruppe kann der Effekt aber deutlich sein, insbesondere wenn heute externe Agenturen für jeden Entwurf beauftragt werden oder Entwicklungsteams mehrfach umbauen müssen, weil Anforderungen erst am fertigen Produkt sichtbar werden.
Kostenmodell realistisch einschätzen. MagicPath bietet nach unserem Kenntnisstand einen kostenlosen oder günstigen Einstieg sowie kostenpflichtige Tarife mit monatlicher Abrechnung und erweitertem Generierungskontingent. Konkrete Preise, Kontingente und Teamkonditionen ändern sich bei Werkzeugen dieser Generation häufig und sollten aktuell beim Anbieter geprüft werden. Zu den Lizenzkosten kommen interne Aufwände für Einarbeitung, Pflege von Stilvorgaben, Datenschutzprüfung und die Überarbeitung des generierten Codes. Diese internen Aufwände übersteigen die Lizenzkosten in der Praxis häufig.
Für die Wirtschaftlichkeit zählt vor allem, wie viel Abstimmungszeit und Nacharbeit eingespart wird. Wenn ein Entwurf, der bisher zwei Wochen und mehrere Agenturrunden benötigt hat, in wenigen Tagen abgestimmt ist, rechnet sich ein Einzelplatz schnell. Wenn das Werkzeug dagegen nur gelegentlich genutzt wird oder die Ergebnisse regelmäßig komplett neu gebaut werden müssen, bleibt der Nutzen gering. Ein Pilot mit klaren Messgrößen schafft hier Klarheit.
Bei einem Anbieter mit Sitz in den USA ist der Drittlandtransfer der zentrale Prüfpunkt. Zu klären ist, wo Projekte, hochgeladene Bilder, Prompts und generierter Code gespeichert und verarbeitet werden, ob eine Verarbeitung in der EU möglich ist und welche Transfermechanismen genutzt werden, etwa eine Zertifizierung unter dem EU-US Data Privacy Framework oder Standardvertragsklauseln. Hinzu kommt die Frage nach den Modellpartnern: Die eigentliche Generierung erfolgt nach unserem Kenntnisstand über große Sprachmodelle externer Anbieter, die ebenfalls überwiegend in den USA sitzen. Damit wandern Inhalte unter Umständen über mehrere Stationen.
Ein Betrieb in eigener Infrastruktur oder eine garantierte EU-Region ist bei MagicPath nach unserem Kenntnisstand derzeit nicht vorgesehen. Für Unternehmen mit hohen Anforderungen an digitale Souveränität bedeutet das: Vertrauliche Inhalte gehören nicht hinein. Wer UI-Generierung dennoch für sensible Projekte nutzen möchte, sollte prüfen, ob sich vergleichbare Ergebnisse mit einem selbst betriebenen Coding-Assistenten und einem in der EU gehosteten oder lokal betriebenen Modell erzielen lassen. Das ist weniger komfortabel, hält Inhalte aber unter eigener Kontrolle.
Der Schutz personenbezogener Daten ist nur ein Teil der Betrachtung. Mindestens ebenso wichtig ist der Schutz von Geschäftsgeheimnissen. Ein unveröffentlichter Konfigurator, ein neues Serviceportal oder eine innovative Bedienoberfläche für eine Maschine sind Wettbewerbsvorteile, die nicht unkontrolliert bei Dritten liegen sollten. Gleiches gilt für Quellcode, der aus dem eigenen Projekt als Kontext in ein Werkzeug kopiert wird. Nach dem Geschäftsgeheimnisgesetz setzt der Schutz voraus, dass angemessene Geheimhaltungsmaßnahmen getroffen werden. Eine klare Regel, welche Inhalte in Cloud-Werkzeuge gelangen dürfen, gehört zu diesen Maßnahmen.
Beim generierten Ergebnis stellen sich zusätzliche Fragen. Die Nutzungsbedingungen räumen Rechte am Ergebnis meist dem Kunden ein, ob an KI-generierten Entwürfen und Code Urheberrechte entstehen, ist rechtlich aber nicht abschließend geklärt. Zudem können generierte Oberflächen bekannten Produkten ähneln, wenn mit Referenzen anderer Marken gearbeitet wird. Für Kundenanwendungen sollte deshalb bewusst geprüft werden, ob Entwürfe eigenständig genug sind und welche Bibliotheken mit welchen Lizenzen im exportierten Code stecken.
Sobald personenbezogene Daten verarbeitet werden, etwa Namen in Screenshots oder Konten der Mitarbeitenden, gehört die Nutzung in das Verzeichnis von Verarbeitungstätigkeiten. Da Cloud-Werkzeuge Nutzungsdaten erfassen, kann in Unternehmen mit Betriebsrat die Mitbestimmung bei technischen Einrichtungen berührt sein, die zur Leistungs- oder Verhaltenskontrolle geeignet sind. Eine frühzeitige Einbindung schafft Vertrauen. Hinzu kommen die Anforderungen des EU AI Act an die KI-Kompetenz der Mitarbeitenden, die sich mit einer Schulung zu Möglichkeiten, Grenzen und Regeln der UI-Generierung gut adressieren lassen.
