Eigene Android-Apps per KI: Chance und Risiko für KMU
Was Google hier tatsächlich ändert
Die Meldung ist auf den ersten Blick schlicht. Google vereinfacht das sogenannte Vibe-Coding, also das Erstellen von Software, indem man der KI in normaler Sprache beschreibt, was die Anwendung können soll. Eigene Android-Apps lassen sich damit per Prompt erzeugen. Das Ganze kostet nichts, und der Weg über den Play Store ist nicht nötig. Als Eintrittskarte genügt ein Google-Konto, wie heise online berichtet.
Drei Dinge sind daran bemerkenswert.
Erstens der Preis: null. Bisher waren zumindest Zeit und Fachwissen nötig, oft auch eine Entwicklerlizenz oder ein externer Dienstleister. Fällt das weg, probieren plötzlich viel mehr Menschen etwas aus, nicht nur die technikaffinen Kollegen.
Zweitens der fehlende Play Store. Dort durchläuft eine App Prüfungen, es gibt Richtlinien, Meldewege und eine gewisse Aufsicht. Wer ohne den Store auskommt, spart Aufwand, verzichtet aber auf diese Kontrollinstanz. Das ist praktisch für interne Werkzeuge und zugleich der Punkt, an dem man selbst Verantwortung übernehmen muss.
Drittens die Eintrittsschwelle. Ein Google-Konto hat praktisch jeder, auch in Ihrer Belegschaft. Es braucht keine Freigabe der IT-Abteilung, keine Software-Installation, keinen Einkauf. Genau das macht die Sache für Geschäftsführer und IT-Verantwortliche interessant: Die Technik kommt nicht mehr über den offiziellen Weg ins Unternehmen, sondern über die Hintertür des Browsers.
Was in der Meldung nicht steht, und was ich deshalb auch nicht behaupte: wie leistungsfähig die erzeugten Apps im Detail sind, welche Funktionen sie unterstützen oder wie sie sich im Dauerbetrieb verhalten. Das müssen Sie selbst ausprobieren und bewerten. Die folgende Einordnung gilt unabhängig von den technischen Details, weil sie sich aus der Grundkonstellation ergibt: einfache Erstellung, geringe Hürde, wenig Kontrolle.
Vibe-Coding in Kürze: Was dahintersteckt
Der Begriff klingt flapsig, beschreibt aber ein ernstes Arbeitsprinzip. Sie schreiben, was Sie brauchen: "Eine App, in der meine Monteure nach dem Einsatz Fotos und eine kurze Notiz zum Auftrag ablegen." Die KI erzeugt daraus Programmcode, Oberfläche und Logik. Sie schauen sich das Ergebnis an, sagen, was fehlt oder stört, und die KI baut nach. Man steuert also eher nach Gefühl und Ergebnis als nach Zeilen im Quelltext. Daher das "Vibe".
Für Menschen ohne Programmierkenntnisse ist das ein Quantensprung beim Zugang. Aber genau hier liegt auch die Falle. Wer den Code nicht lesen kann, kann auch nicht beurteilen, ob er sauber ist. Die App läuft, sie sieht gut aus, sie tut scheinbar, was sie soll. Ob sie nebenbei Daten an Stellen schickt, wo sie nicht hingehören, ob Zugangsdaten offen im Code stehen, ob sie bei ungewöhnlichen Eingaben zusammenbricht: Das sieht man ihr nicht an.
Aus Erfahrung mit Webprojekten kenne ich das Muster. Ein Prototyp, der in einer Stunde steht, wirkt fertig. Der Weg von "funktioniert beim Vorführen" zu "funktioniert zuverlässig, sicher und auch noch in einem Jahr" ist meist länger als der Weg bis zum Prototyp. KI verkürzt den ersten Teil enorm, den zweiten Teil nur bedingt.
Wo Eigen-Apps im Mittelstand wirklich helfen können
Bevor wir zu den Risiken kommen, lohnt ein fairer Blick auf den Nutzen. Es gibt in fast jedem Betrieb kleine Prozesse, für die sich keine Standardsoftware lohnt und für die ein Entwickler zu teuer wäre. Genau dort können einfach erzeugte Apps etwas bewegen. Einige Beispiele, die ich für realistisch halte:
Mobile Erfassung im Außendienst. Ein Handwerksbetrieb will, dass Monteure vor Ort ein paar Felder ausfüllen und ein Foto anhängen. Heute passiert das per Zettel, WhatsApp oder nachträglich im Büro. Eine schlanke App, die genau diese Felder abfragt, kann Doppelarbeit sparen.
Checklisten und Rundgänge. Hausmeisterdienste, Gastronomiebetriebe oder Werkstätten arbeiten mit wiederkehrenden Prüflisten: Hygiene, Fahrzeugkontrolle, Geräteprüfung. Eine einfache Abhak-App ersetzt Papier und macht Abläufe nachvollziehbar.
Kleine interne Nachschlagewerke. Preislisten, Ansprechpartner, Anleitungen für Maschinen: Dinge, die Mitarbeiter schnell auf dem Handy brauchen und die sonst in einer verstreuten Ablage liegen.
Prototypen für spätere Projekte. Das ist vielleicht der wertvollste Nutzen. Wer eine Idee für eine Kunden-App oder ein Servicewerkzeug hat, kann sie in kurzer Zeit als Skizze bauen lassen und damit Kollegen oder Kunden zeigen, was gemeint ist. Das spart Missverständnisse im späteren Pflichtenheft. Ein Prototyp ist dabei ausdrücklich ein Gesprächsmittel, kein Produkt.
Einmalige oder zeitlich begrenzte Aufgaben. Eine Messeaktion, eine Inventur, ein Event: Für Dinge, die nach ein paar Wochen wieder verschwinden, ist der Wartungsaspekt weniger kritisch.
Was diese Beispiele verbindet: Es geht um überschaubare Aufgaben mit wenig sensiblen Daten und klarem Nutzerkreis. Je weiter Sie sich davon entfernen, etwa Richtung Kundendaten, Zahlungen oder Anbindung an Ihr Warenwirtschaftssystem, desto schneller wird aus der netten Spielerei ein ernstes Projekt.
Das Sicherheitsproblem: Schnell gebaut ist nicht sicher gebaut
Kommen wir zum unbequemen Teil. Eine App, die ein Mitarbeiter in einer Mittagspause erzeugt hat, ist aus Sicht der IT zunächst einmal eine unbekannte Software, die niemand geprüft hat. Das hat konkrete Folgen.
Unklare Codequalität. KI-generierter Code kann Schwachstellen enthalten, genauso wie Code von Menschen. Der Unterschied: Bei professioneller Entwicklung gibt es Reviews, Tests und Erfahrung, die solche Fehler abfangen. Bei einem Prompt-Experiment schaut meist niemand mehr drauf. Typische Schwächen sind unsichere Datenübertragung, fehlende Prüfung von Eingaben, zu großzügige Berechtigungen oder Zugangsdaten, die direkt im Programm stehen. Ob und wie häufig das bei den Google-Apps vorkommt, geben die vorliegenden Informationen nicht her. Als Grundregel für jede ungeprüfte Software gilt es trotzdem.
Verbreitung außerhalb des Stores. Wenn Apps nicht über den Play Store laufen, werden sie auf anderem Weg verteilt, zum Beispiel per Link oder Datei. Dann müssen Mitarbeiter auf ihren Geräten Dinge zulassen, die sie sonst aus gutem Grund gesperrt haben. Wer sich daran gewöhnt, Apps aus beliebigen Quellen zu installieren, öffnet auch Schadsoftware die Tür. Ein Betrieb, der seinen Leuten monatelang erklärt hat, nichts aus unbekannten Quellen zu installieren, sendet mit Hauskulturen wie "Installier mal meine App" ein widersprüchliches Signal.
Schatten-IT. Das ist der Kernbegriff für das, was hier droht. Gemeint sind Anwendungen, die ohne Wissen der IT im Unternehmen entstehen und im Alltag genutzt werden. Sie tauchen in keinem Inventar auf, werden nicht aktualisiert, nicht gesichert und nicht überwacht. Wenn dann etwas passiert, weiß niemand, dass es diese App überhaupt gibt, geschweige denn, welche Daten darin liegen.
Konten als Schwachstelle. Wenn der Zugang zur Erstellung ein Google-Konto ist, stellt sich die Frage: Welches? Das private Konto eines Mitarbeiters? Das Firmenkonto? Wer im privaten Konto Firmenwerkzeuge baut, hat bei Kündigung oder Krankheit ein Problem, bei einem gekaperten Konto ein noch größeres. Eine saubere Absicherung der Konten mit zweitem Faktor und klaren Regeln gehört zum Mindeststandard, den wir unter IT-Sicherheit für Betriebe immer wieder als ersten Hebel nennen.
Kurz gesagt: Das Risiko liegt weniger in der Technik von Google als in der Kombination aus einfacher Erstellung und fehlender Governance. Wo jeder alles bauen kann und keiner Bescheid weiß, entsteht Wildwuchs.
Datenschutz: Wohin fließen die Daten?
Der zweite große Block ist der Datenschutz, und er wird in der Praxis gern unterschätzt, weil er nicht so spektakulär klingt wie ein Hackerangriff.
Sobald eine selbstgebaute App personenbezogene Daten verarbeitet, gelten dieselben Pflichten wie bei jeder anderen Software. Das betrifft Kundendaten, Mitarbeiterdaten, Fotos von Personen, Standortdaten, Terminlisten. Sie müssen wissen, welche Daten erhoben werden, wo sie gespeichert sind, wer Zugriff hat und wie lange sie bleiben. Außerdem muss die Verarbeitung dokumentiert sein, und gegebenenfalls braucht es Verträge mit beteiligten Dienstleistern.
Hier stellen sich bei Apps, die per KI entstehen, mehrere Fragen:
- Was geben Sie der KI preis? Wer beim Prompt echte Kundendaten, Preislisten oder interne Abläufe als Beispiel eintippt, gibt diese Informationen an einen externen Dienst. Das sollte vorher bewusst entschieden werden. Echte Namen und Adressen gehören nicht in einen Prompt, Platzhalter reichen für den Zweck völlig.
- Wo liegen die Daten der fertigen App? Wenn die App Daten speichert, dann irgendwo. Auf dem Gerät, in einem Cloud-Dienst, bei einem Dritten? Wer das nicht beantworten kann, kann auch keine Auskunft geben und keine Löschung durchführen.
- Wer ist verantwortlich? Verantwortlich im Sinne des Datenschutzes ist das Unternehmen, nicht der Mitarbeiter, der die App gebaut hat. Das Unternehmen haftet also für etwas, das es womöglich gar nicht kennt.
Ich will hier nicht schwarzmalen. Für eine Checkliste ohne personenbezogene Daten ist das alles unkritisch. Aber die Grenze ist schneller überschritten, als man denkt: Ein Feld "Name des Kunden" in einer Monteur-App genügt.
Wartung und Betrieb: Die vergessene Hälfte
Wer schon einmal eine Excel-Lösung geerbt hat, die ein Kollege vor zehn Jahren gebaut hat und die nun das halbe Unternehmen trägt, kennt das Problem. Bei Apps ist es nicht anders, eher schlimmer, denn mobile Betriebssysteme ändern sich regelmäßig.
Eine App ist kein einmaliges Ergebnis, sondern ein laufender Betrieb. Es braucht Updates, wenn sich die Plattform verändert, Anpassungen, wenn sich der Prozess ändert, Fehlerbehebung, wenn etwas klemmt, und Sicherheitskorrekturen, wenn Lücken bekannt werden. Eine per Prompt erzeugte App hat diese Pflege nicht automatisch eingebaut. Wenn der Ersteller das Unternehmen verlässt, steht niemand mehr da, der sie versteht. Und weil der Code nicht von einem Menschen mit Konzept geschrieben wurde, ist auch der Einstieg für Nachfolger mühsam.
Dazu kommen Fragen, an die man beim Erstellen nicht denkt:
- Datensicherung. Werden die Daten der App gesichert? Wenn nicht, ist ein verlorenes oder defektes Gerät im schlimmsten Fall der Verlust aller Einträge. Zur Absicherung solcher Fälle gehört immer auch ein Plan für die Datenrettung, bevor etwas schiefgeht.
- Abhängigkeit vom Anbieter. Wenn die App an einem Dienst hängt, der sich ändert, eingeschränkt oder beendet wird, steht Ihr Prozess still. Das ist kein Vorwurf an Google, sondern gilt für jedes kostenlose Angebot: Was nichts kostet, hat keinen Vertrag, der Ihnen etwas zusichert.
- Support. Wenn morgens um sieben im Betrieb die App nicht startet, wer hilft? Bei Standardsoftware gibt es eine Hotline oder einen Dienstleister. Bei der Eigenkonstruktion gibt es den Kollegen, der gerade im Urlaub ist.
Hier schließt sich der Kreis zu etwas, das viele Betriebe unterschätzen: Software ist nur dann ein Gewinn, wenn sie über Jahre zuverlässig läuft. Der Zeitgewinn beim Bauen darf nicht durch Mehraufwand im Betrieb aufgefressen werden.
Eigenbau, Standardsoftware oder Profi: Eine Faustregel
Wann lohnt sich was? Eine grobe Orientierung, die ich Kunden gebe:
Eigenbau per KI passt, wenn die Aufgabe klein ist, nur wenige Personen die App nutzen, keine oder kaum sensible Daten verarbeitet werden und ein Ausfall nicht wehtut. Dazu zählen Prototypen, Checklisten und Hilfswerkzeuge für ein einzelnes Team.
Standardsoftware passt, wenn es für Ihr Problem bereits ein erprobtes Produkt gibt. Zeiterfassung, Auftragsverwaltung, Terminplanung und Ähnliches sind gelöste Probleme. Hier lohnt sich Eigenbau selten, weil Sie Funktionen, Updates und Support mitkaufen.
Individuelle Entwicklung durch Profis passt, wenn die Anwendung geschäftskritisch ist, an Ihre Warenwirtschaft, Ihren Shop oder Ihre Kundendaten angebunden werden soll oder viele Menschen sie nutzen. Auch hier können KI-Werkzeuge im Einsatz sein, aber mit Review, Tests, sauberer Dokumentation und einem Betriebskonzept.
Der Prototyp-Gedanke ist übrigens der beste Brückenschlag: Lassen Sie intern eine Skizze bauen, klären Sie damit, was Sie wirklich brauchen, und geben Sie diese Erkenntnis dann an einen Dienstleister oder in eine Standardlösung weiter. So nutzen Sie die Geschwindigkeit der KI, ohne das Risiko in den Alltag zu tragen.
Was das für den Mittelstand bedeutet
Aus der Einordnung ergeben sich konkrete Schritte. Sie müssen nicht alle auf einmal umsetzen, aber die ersten drei sollten Sie zeitnah angehen.
1. Klären Sie, ob und wie Eigen-Apps erlaubt sind. Schreiben Sie eine kurze, verständliche Regel auf: Was darf ein Mitarbeiter selbst bauen, was nicht? Eine Seite genügt. Wichtig ist, dass sie existiert und dass Ihre Leute sie kennen. Ein Verbot ohne Alternative treibt das Thema nur in den Untergrund, eine klare Erlaubnis mit Leitplanken schafft Transparenz.
2. Legen Sie eine Meldepflicht fest. Jede App, die im Betrieb tatsächlich genutzt wird, kommt in eine einfache Liste: Name, Zweck, Ersteller, Nutzerkreis, welche Daten, wer ist Ansprechpartner. Damit schlagen Sie die Schatten-IT mit den einfachsten Mitteln.
3. Trennen Sie Test und Echtbetrieb. Experimente mit erfundenen Beispieldaten sind unkritisch. Sobald echte Kunden- oder Mitarbeiterdaten ins Spiel kommen, wird die App geprüft, bevor sie produktiv läuft. Das gilt auch für die Prompts: keine echten personenbezogenen Daten als Beispiel eingeben.
4. Verwenden Sie Firmenkonten statt privater Konten. Wenn Mitarbeiter etwas für den Betrieb bauen, dann im Firmenkonto, abgesichert mit zweitem Faktor. So bleibt das Ergebnis im Unternehmen, auch wenn jemand geht.
5. Prüfen Sie die Geräteverwaltung. Wenn Ihre Mitarbeiter Firmenhandys nutzen, legen Sie fest, ob und woher Apps installiert werden dürfen. Wer Installationen aus unbekannten Quellen generell sperrt, sollte für genehmigte interne Apps einen geordneten Weg anbieten, statt Ausnahmen im Einzelfall zu dulden.
6. Planen Sie Datensicherung und Verantwortlichkeit mit. Für jede App, die bleibt: Wer pflegt sie, wo liegen die Daten, wie werden sie gesichert, was passiert bei Ausfall? Ist das nicht beantwortbar, bleibt es ein Prototyp.
7. Behalten Sie Pflichten im Blick. Je nach Branche und Größe gelten für Sie erhöhte Anforderungen an die IT-Sicherheit und an die Kontrolle über eingesetzte Software. Wie sich das konkret auswirkt, haben wir auf der Seite zu NIS2 & IT-Sicherheit für kleine und mittlere Unternehmen aufbereitet. Selbstgebaute Anwendungen, von denen niemand weiß, passen zu solchen Anforderungen schlecht.
8. Nutzen Sie die Chance bewusst. Suchen Sie sich ein bis zwei kleine, unkritische Anwendungsfälle und probieren Sie es aus, am besten mit einer Person, die Prozesse gut kennt und sich für Technik interessiert. Sie werden schnell merken, wo die Grenzen liegen, und das ist wertvoller als jede theoretische Bewertung.
9. Holen Sie sich Rat, wenn es ernst wird. Wenn aus einem Experiment ein Werkzeug wird, das Ihr Geschäft trägt, lohnt sich ein Blick von außen. Gerade für Betriebe in unserer Region begleiten wir solche Fragen gern im Rahmen unseres IT-Service Friesland, vom Sicherheitscheck bis zur Entscheidung, ob eine Eigenlösung reicht oder besser eine solide Entwicklung her muss.
Das Grundprinzip dahinter ist einfach: Die Technik wird zugänglicher, die Verantwortung bleibt dieselbe. Wer die Möglichkeiten nutzt und gleichzeitig ein Mindestmaß an Ordnung hält, kann von dieser Entwicklung profitieren. Wer sie laufen lässt, sammelt Altlasten.
Häufige Fragen
Muss ich als Unternehmen jetzt reagieren, obwohl ich gar keine Apps bauen will?
Ja, zumindest mit einer kurzen Regel. Sie müssen nicht selbst bauen, aber Ihre Mitarbeiter können es jetzt sehr leicht tun. Eine knappe Vorgabe, was erlaubt ist und was gemeldet werden muss, verhindert, dass unbemerkt Software entsteht.
Sind kostenlos erstellte Apps automatisch unsicher?
Nein, das lässt sich pauschal nicht sagen. Das Risiko entsteht vor allem dadurch, dass niemand den Code prüft und die App ohne Kontrolle verteilt wird. Für unkritische Anwendungen mit unbedenklichen Daten ist das vertretbar, bei sensiblen Daten sollte eine Prüfung Pflicht sein.
Darf ich Kundendaten in eine selbstgebaute App eingeben?
Nur, wenn die Verarbeitung datenschutzkonform geregelt ist: Sie wissen, wo die Daten liegen, wer zugreifen kann und wie sie gelöscht werden. Ohne diese Klarheit sollten Sie mit erfundenen Beispieldaten arbeiten und die App erst nach einer Prüfung produktiv nutzen.
Ersetzt das Vibe-Coding künftig meinen Dienstleister?
Für kleine Hilfswerkzeuge und Prototypen kann es den Aufwand deutlich senken. Für geschäftskritische, vernetzte oder stark genutzte Anwendungen bleiben Qualitätssicherung, Betrieb und Support nötig. Die Rolle des Dienstleisters verschiebt sich eher, als dass sie verschwindet.
Was mache ich, wenn bei uns schon solche Apps im Einsatz sind?
Verschaffen Sie sich zuerst einen Überblick: Welche Apps gibt es, wer nutzt sie, welche Daten stecken drin? Danach entscheiden Sie pro App, ob sie bleibt, überarbeitet oder ersetzt wird. Bei Unsicherheit hilft ein externer Blick, gern auch per Fernwartung, ohne dass jemand vor Ort sein muss.