Die Idee dahinter ist einfach und zugleich weitreichend. Viele kleine Software-Bedürfnisse in Unternehmen werden nie umgesetzt, weil der Aufwand in keinem Verhältnis zum Nutzen steht. Ein Rechner für Zuschläge, eine Checkliste für die Wareneingangskontrolle, ein Formular zur Erfassung von Verbesserungsvorschlägen, ein kleines Dashboard für die Schichtplanung: Solche Anwendungen landen bislang in Excel-Tabellen, in E-Mail-Verteilern oder bleiben schlicht unerledigt. Eine eigene Entwicklung lohnt sich nicht, eine Standardsoftware passt nicht. GitHub Spark zielt genau auf diese Lücke. Es soll den Weg von der Idee zur nutzbaren Anwendung so kurz machen, dass auch sehr kleine Vorhaben realisiert werden können.
Spark ist Teil des wachsenden Copilot-Ökosystems von GitHub und damit auch Teil der KI-Strategie von Microsoft, zu dem GitHub seit 2018 gehört. Während GitHub Copilot vor allem professionelle Entwicklerinnen und Entwickler beim Schreiben von Code unterstützt, richtet sich Spark an einen breiteren Kreis: an Menschen mit Ideen, die keine oder nur wenig Programmiererfahrung haben, ebenso wie an Entwicklungsteams, die schnell einen Prototyp brauchen. Drei Merkmale prägen das Angebot:
GitHub Spark entstand bei GitHub Next, der Forschungs- und Prototypenabteilung von GitHub, aus der auch frühe Versionen von Copilot und andere Experimente hervorgegangen sind. Vorgestellt wurde Spark auf der Entwicklerkonferenz GitHub Universe im Herbst 2024, zunächst als Forschungsprojekt mit Warteliste. Die zentrale Frage lautete damals: Was wäre, wenn jeder Mensch sich eigene kleine Programme so selbstverständlich bauen könnte, wie er heute eine Tabelle oder ein Dokument anlegt? Die Forscherinnen und Forscher sprachen von „persönlicher Software“, die nicht für einen Massenmarkt, sondern für eine Person, eine Familie oder ein kleines Team gemacht ist.
Im Jahr 2025 wurde Spark nach unserem Kenntnisstand als öffentliche Vorschau für zahlende Copilot-Kundinnen und -Kunden geöffnet, zunächst für die höchsten Einzeltarife und anschließend schrittweise auch für Unternehmenskunden. Mit diesem Schritt hat sich der Charakter verändert: Aus dem Experiment wurde ein Produktbaustein, der mit Abonnements, Kontingenten und Unternehmensrichtlinien verbunden ist. Der genaue Status, also ob Spark in Ihrem Tarif als Vorschau oder allgemein verfügbar angeboten wird und welche Funktionen enthalten sind, ändert sich laufend und sollte aktuell bei GitHub geprüft werden.
Der Begriff Micro-App beschreibt eine Anwendung mit klar begrenztem Zweck. Typisch sind wenige Ansichten, überschaubare Datenmengen, ein kleiner Nutzerkreis und eine Lebensdauer, die von einem Nachmittag bis zu einigen Jahren reichen kann. Beispiele sind ein Rechner, eine Erfassungsmaske, ein Quiz für eine Schulung, ein Zähler, ein Planungshelfer oder eine kleine Übersicht über Termine und Aufgaben. Micro-Apps ersetzen keine Warenwirtschaft, kein CRM und kein Kundenportal. Sie füllen die Räume dazwischen, in denen heute häufig Tabellen, Notizzettel oder Medienbrüche herrschen.
Werkzeuge wie GitHub Spark senken die Einstiegshürde noch einmal deutlich. Eine Produktionsleiterin kann in einem Gespräch mit der KI einen Prototyp für eine digitale Rüstliste entwickeln und ihn der IT zeigen. Ein Vertriebsmitarbeiter kann einen Konfigurator für ein Standardprodukt ausprobieren, bevor jemand ein Lastenheft schreibt. Das verändert die Zusammenarbeit zwischen Fachbereich und IT: Anforderungen werden nicht mehr nur beschrieben, sondern vorgeführt. Gleichzeitig entstehen neue Fragen nach Datenschutz, Sicherheit und Verantwortung, die dieser Leitfaden in den folgenden Kapiteln aufgreift.
Anders als viele eigenständige App-Builder ist GitHub Spark kein separates Produkt mit eigenem Abonnement, sondern Bestandteil der Copilot-Tarife. Nach unserem Kenntnisstand stand Spark in der öffentlichen Vorschau zunächst nur Nutzerinnen und Nutzern des höchsten Einzeltarifs zur Verfügung und wurde danach auch für Unternehmenskunden geöffnet, wobei Administratoren die Nutzung über Richtlinien steuern können. Ob Spark in den Tarifen Business oder Enterprise enthalten ist, ob es dort standardmäßig aktiviert oder deaktiviert ist und welche Einstellungen eine Organisation vornehmen kann, sollte vor einer Einführung anhand der aktuellen Dokumentation geprüft werden.
Für Unternehmen hat diese Kopplung Vor- und Nachteile. Positiv ist, dass Spark in bestehende Verträge, Abrechnungen und Verwaltungsoberflächen eingebettet ist. Wer GitHub bereits nutzt, muss keinen neuen Anbieter prüfen, sondern nur einen weiteren Dienst desselben Anbieters bewerten. Zugleich bedeutet die Kopplung, dass Spark-Nutzung die gleichen Kontingente beansprucht wie andere Premium-Funktionen von Copilot. Wer intensiv mit Spark arbeitet, kann Kontingente schneller aufbrauchen als erwartet. Zudem ist Spark ohne Copilot-Lizenz nicht nutzbar, was die Zielgruppe der Fachanwenderinnen und Fachanwender ohne Entwicklerkonto einschränkt.
GitHub baut Copilot seit einigen Jahren von einer Autovervollständigung zu einer Familie von KI-Funktionen aus: Chat in Editor und Browser, Code-Review in Pull Requests, ein Agentenmodus im Editor, der Copilot Coding Agent, der Aufgaben aus Issues selbstständig bearbeitet, und eine Kommandozeilenvariante. Spark ergänzt diese Familie am Anfang des Entwicklungsprozesses. Während die anderen Funktionen voraussetzen, dass es bereits ein Repository und eine Codebasis gibt, beginnt Spark bei der leeren Seite.
GitHub positioniert Spark bewusst nicht als Low-Code-Plattform für Unternehmensanwendungen, sondern als Werkzeug für persönliche und kleine gemeinsame Anwendungen. Das zeigt sich an vielen Details: Die Anmeldung erfolgt über GitHub-Konten, Berechtigungen sind einfach gehalten, der Datenspeicher ist auf überschaubare Datenmengen ausgelegt, und Anbindungen an Unternehmenssysteme sind nicht der Kern des Angebots. Im Microsoft-Ökosystem übernimmt die Rolle der Unternehmens-Low-Code-Plattform weiterhin die Power Platform mit Power Apps, Power Automate und Dataverse.
Der Einstieg in Spark ist bewusst niedrigschwellig. Auf einer leeren Seite beschreibt man in einigen Sätzen, was die Anwendung tun soll, etwa: eine App, in der Mitarbeitende Verbesserungsvorschläge mit Kategorie, Beschreibung und Foto erfassen und in der die Teamleitung den Status pflegen kann. Spark interpretiert diese Beschreibung, entwirft eine Struktur, erzeugt den Code und zeigt nach kurzer Zeit eine funktionierende Vorschau. Häufig schlägt das Werkzeug dabei auch Details vor, an die man selbst nicht gedacht hat, zum Beispiel Filter, Sortierungen oder leere Zustände.
Technisch entstehen moderne Webanwendungen auf Basis von TypeScript und React, ergänzt um eine Bibliothek gestalteter Oberflächenelemente. Für Nutzerinnen und Nutzer ohne Programmierkenntnisse ist das unerheblich, für die IT aber wichtig: Der erzeugte Code folgt verbreiteten Standards und ist damit für Entwicklerinnen und Entwickler lesbar und weiterverwendbar. Er ist allerdings auf die Laufzeitumgebung von Spark zugeschnitten, insbesondere bei Datenspeicher, Anmeldung und KI-Aufrufen. Wer die App später außerhalb von Spark betreiben will, muss diese Stellen ersetzen.
Nach der ersten Version bietet Spark mehrere Wege, die App anzupassen. Der wichtigste bleibt die natürliche Sprache: Man beschreibt, was sich ändern soll, und Spark setzt es um. Ergänzend gibt es visuelle Bearbeitungsmöglichkeiten, mit denen sich etwa Farben, Schriften, Abstände oder Erscheinungsbild über Themes anpassen lassen, ohne jedes Detail in Worte fassen zu müssen. Nach unserem Kenntnisstand lassen sich einzelne Elemente der Vorschau auch gezielt auswählen, um Änderungen auf einen bestimmten Bereich zu beschränken.
Jede Änderung in Spark erzeugt einen neuen Stand im Versionsverlauf. Wer mit einer Anweisung ein unerwünschtes Ergebnis erzielt, kann auf eine frühere Version zurückspringen und einen anderen Weg probieren. Dieser Verlauf ist eine wichtige Sicherheitsleine, denn KI-gestützte Änderungen betreffen manchmal mehr Stellen als beabsichtigt. Er ersetzt allerdings keine Versionsverwaltung im Sinne von Git mit Branches, Reviews und Nachvollziehbarkeit über Teams hinweg.
Fertige Apps lassen sich teilen. Je nach Einstellung können andere die App nur nutzen oder auch bearbeiten. Ein besonderes Konzept ist das Remixen: Andere Nutzerinnen und Nutzer können eine geteilte App als Vorlage übernehmen und in einer eigenen Kopie weiterentwickeln. Im privaten Umfeld führt das zu einer lebendigen Sammlung kleiner Werkzeuge. Im Unternehmen sollte man genau hinschauen, mit wem Apps geteilt werden, wer sie sehen kann und ob in der Kopie auch Daten mitwandern. Die genauen Sichtbarkeitsoptionen, etwa die Beschränkung auf Mitglieder einer Organisation, hängen vom Tarif und den Richtlinien ab und sollten vor dem Einsatz geprüft werden.
Im Hintergrund des Spark-Editors arbeiten große Sprachmodelle, die aus natürlicher Sprache Code erzeugen. Nach unserem Kenntnisstand setzt GitHub dafür Modelle von Anthropic aus der Claude-Sonnet-Familie ein, die im Bereich der Codegenerierung als besonders leistungsfähig gelten. Welches Modell genau zum Einsatz kommt, kann sich mit neuen Versionen ändern und ist für Anwenderinnen und Anwender in der Regel nicht frei wählbar. Für die Datenschutzbewertung ist das relevant, weil damit neben GitHub und Microsoft weitere Unterauftragsverarbeiter in die Verarbeitung eingebunden sein können. Die aktuelle Modellausstattung und die zugehörigen Subprozessoren sollten Sie bei GitHub prüfen.
Eine Besonderheit von Spark ist, dass erzeugte Apps selbst KI-Funktionen nutzen können, ohne dass sich jemand um API-Schlüssel, Abrechnung bei einem Modellanbieter oder eine eigene Schnittstelle kümmern muss. Beschreibt man etwa eine App, die eingegebene Kundenanfragen automatisch zusammenfasst oder Verbesserungsvorschläge nach Themen sortiert, baut Spark die notwendigen Modellaufrufe ein. Die Anbindung erfolgt nach unserem Kenntnisstand über die Modellinfrastruktur von GitHub, die verschiedene Modelle mehrerer Anbieter bereitstellt.
Diese Bequemlichkeit hat zwei Seiten. Auf der einen Seite entstehen sehr schnell nützliche Anwendungen, die vor wenigen Jahren ein eigenes Projekt gewesen wären. Auf der anderen Seite gehen dabei Inhalte, die Nutzerinnen und Nutzer in die App eingeben, an ein Sprachmodell. Wenn diese Inhalte personenbezogene Daten, Kundendaten oder Geschäftsgeheimnisse enthalten, gelten dieselben Anforderungen wie für jede andere KI-Verarbeitung: Rechtsgrundlage, Transparenz, Auftragsverarbeitung, Speicherdauer und Trainingsausschluss müssen geklärt sein. Gerade weil die Einbindung so mühelos ist, wird diese Prüfung leicht übersehen.
Wenn eine Spark-App mit einem GitHub-Repository verbunden ist, öffnet sich der Weg zu den übrigen Agentenfunktionen von Copilot. Aufgaben lassen sich dann als Issue formulieren und dem Copilot Coding Agent zuweisen, der in einer abgeschotteten Umgebung arbeitet, Änderungen vornimmt und einen Pull Request zur Prüfung vorlegt. Nach unserem Kenntnisstand ist eine solche Übergabe auch direkt aus dem Spark-Kontext heraus vorgesehen. Damit verschiebt sich die Arbeitsweise vom Dialog im Editor zu einem geregelten Prozess mit Review, Tests und Freigabe.
Die Verbindung mit einem Repository ist der Punkt, an dem Spark vom Spielzeug zum Werkzeug wird. Nach unserem Kenntnisstand lässt sich eine Spark-App mit einem neuen Repository verknüpfen, wobei Änderungen in beide Richtungen synchronisiert werden: Was im Spark-Editor entsteht, landet im Repository, und Änderungen im Repository werden in Spark sichtbar. Damit stehen alle Mechanismen der GitHub-Plattform zur Verfügung, von Branches und Pull Requests über Code-Review und Issues bis zu Actions für automatisierte Prüfungen. Wer tiefer eingreifen will, öffnet die App in GitHub Codespaces, einer Entwicklungsumgebung im Browser auf Basis von Visual Studio Code, und arbeitet dort mit Copilot weiter.
Die verwaltete Laufzeit ist das, was Spark von reinen Codegeneratoren unterscheidet. Veröffentlichte Apps laufen auf Infrastruktur, die GitHub betreibt, nach unserem Kenntnisstand auf Basis von Microsoft Azure. Für Nutzerinnen und Nutzer bedeutet das: kein Server, kein Zertifikat, keine Datenbankinstallation, keine Wartung. Für die IT bedeutet es: Daten der App liegen in einer Umgebung, deren Standort, Sicherung und Zugriffskontrolle nicht selbst bestimmt werden. Den genauen Speicherort sollten Sie bei GitHub erfragen.
Die Anmeldung an veröffentlichten Apps erfolgt über GitHub-Konten. Das ist für Entwicklungsteams selbstverständlich, für Fachbereiche aber eine Hürde: Mitarbeitende in Produktion, Vertrieb oder Verwaltung haben in der Regel kein GitHub-Konto. Ob sich die Anmeldung an ein bestehendes Unternehmenskonto mit Single Sign-on koppeln lässt, hängt davon ab, wie das GitHub-Konto der Organisation eingerichtet ist, etwa mit verwalteten Benutzerkonten im Enterprise-Tarif. Der eingebaute Datenspeicher ist auf einfache Schlüssel-Wert-Paare ausgelegt. Für Listen, Einstellungen oder kleine Sammlungen reicht das, für komplexe Abfragen, große Datenmengen oder gleichzeitige Bearbeitung durch viele Personen nicht.
Spark ist nicht als Integrationsplattform gedacht. Anders als Power Apps mit seinen zahlreichen Konnektoren gibt es keine fertigen Bausteine für ERP, CRM, Dokumentenmanagement oder Microsoft 365. Grundsätzlich kann der erzeugte Code externe Schnittstellen aufrufen, etwa eine öffentliche API. Sobald dafür Zugangsdaten nötig sind, stellen sich aber Fragen: Wo werden Schlüssel gespeichert, wer kann sie sehen, und wie wird verhindert, dass eine geteilte oder geremixte App Zugangsdaten preisgibt?
Lovable, Bolt.new und v0 verfolgen einen ähnlichen Grundgedanken wie Spark: Aus einer Beschreibung entsteht eine laufende Anwendung, die man im Dialog verfeinert. Die Unterschiede liegen im Anspruch. Lovable und Bolt.new zielen auf vollständige Anwendungen bis hin zu marktfähigen Produkten und binden dafür externe Dienste für Datenbank, Anmeldung und Zahlungen ein. v0 von Vercel kommt aus der Oberflächengestaltung und ist besonders stark, wenn es um Frontends auf Basis verbreiteter Komponentenbibliotheken geht, mit nahtloser Bereitstellung auf der Vercel-Plattform. Replit verbindet einen KI-Agenten mit einer vollständigen Cloud-Entwicklungsumgebung und eigenem Hosting.
Spark ist im Vergleich bewusst schlanker. Es verzichtet auf eine Vielzahl externer Dienste und bringt stattdessen die nötigsten Bausteine in einer integrierten Laufzeit mit. Das macht den Einstieg einfacher und reduziert die Zahl der beteiligten Anbieter, begrenzt aber die Möglichkeiten bei größeren Anwendungen. Der wichtigste Vorteil von Spark ist die Einbettung in GitHub und Copilot. Für Unternehmen, die bereits Copilot-Lizenzen haben, entfallen ein weiterer Vertrag und eine weitere Lieferantenprüfung. Für Unternehmen ohne GitHub-Bezug ist dieser Vorteil dagegen nicht vorhanden.
Microsoft Power Apps ist die naheliegende Vergleichsgröße, weil beide Produkte aus dem Microsoft-Konzern stammen. Die Ausrichtung unterscheidet sich jedoch deutlich. Power Apps ist eine Unternehmensplattform mit Verwaltung, Umgebungen, Datenrichtlinien, Rollen, Anbindung an Microsoft 365 und Dataverse sowie einer großen Zahl an Konnektoren zu anderen Systemen. Auch Power Apps bietet inzwischen KI-Unterstützung, mit der sich Apps aus Beschreibungen erzeugen lassen. Spark arbeitet dagegen mit echtem Code, ist schneller und freier in der Gestaltung, aber deutlich weniger in die Verwaltungsstrukturen eines Unternehmens eingebunden.
Für den Mittelstand ergibt sich daraus eine einfache Faustregel. Geht es um Anwendungen für Fachbereiche, die mit Daten aus Microsoft 365, SharePoint, Dynamics oder anderen Unternehmenssystemen arbeiten und von der IT dauerhaft verwaltet werden sollen, ist Power Apps oder eine reguläre Entwicklung meist die bessere Wahl. Geht es um schnelle Prototypen, persönliche Helfer oder kleine Werkzeuge für Entwicklungsteams, spielt Spark seine Stärken aus. Beide Ansätze schließen sich nicht aus: Ein in Spark gebauter Prototyp kann auch helfen, die Anforderungen für eine spätere Power-App zu klären.
GitHub Copilot, Cursor, Windsurf, Claude Code und vergleichbare Werkzeuge unterstützen Entwicklerinnen und Entwickler in ihrer gewohnten Umgebung bei bestehenden Codebasen. Sie setzen voraus, dass jemand ein Projekt aufsetzt, Abhängigkeiten verwaltet, Code versteht und Verantwortung für den Betrieb übernimmt. Spark nimmt einen Großteil dieser Voraussetzungen ab, verlangt dafür aber, dass man sich auf seine Laufzeit und seine Grenzen einlässt.
Für die meisten Unternehmen bietet sich ein gestuftes Modell an. In der Spark-Laufzeit bleiben Apps, die keine personenbezogenen Daten, keine Kundendaten und keine Geschäftsgeheimnisse verarbeiten, etwa Rechner, Lernhilfen, Demonstratoren oder Prototypen mit Beispieldaten. Sobald eine App echte Daten verarbeiten soll oder von vielen Personen dauerhaft genutzt wird, wird sie in ein Repository übernommen und von der IT bewertet. Im Ergebnis bleibt sie entweder in der Spark-Laufzeit, wenn die Datenschutzprüfung das zulässt, oder sie wird exportiert und auf eigener Infrastruktur betrieben.
Die Spark-Laufzeit selbst lässt sich nicht selbst hosten. Der Export ist deshalb der Weg zu mehr Datenhoheit. Weil der erzeugte Code auf Spark-spezifische Funktionen für Speicher, Anmeldung und KI-Aufrufe zugreift, müssen diese Stellen beim Umzug durch eigene Lösungen ersetzt werden: eine Datenbank im eigenen Rechenzentrum oder bei einem Cloud-Anbieter mit EU-Region, eine Anmeldung über das Unternehmensverzeichnis und, falls KI-Funktionen benötigt werden, ein Modellzugang mit Rechenzentrum in der EU oder ein lokal betriebenes Modell. Für eine kleine App ist das meist in überschaubarer Zeit machbar, sollte aber eingeplant werden.
Die größte Gefahr beim Einsatz von Spark ist nicht ein technischer Fehler, sondern die unkontrollierte Ausbreitung kleiner Anwendungen. Wenn jede Abteilung eigene Apps baut, die niemand kennt, die auf unklaren Daten beruhen und deren Ersteller das Unternehmen irgendwann verlässt, entsteht eine neue Form von Schatten-IT. Das Problem ist aus der Welt der Excel-Makros und Access-Datenbanken bekannt, wird durch KI-Werkzeuge aber beschleunigt, weil die Hürde zum Bau einer App sinkt.
Ein Hersteller von Industrieanlagen möchte seinen Kunden ein Portal anbieten, über das sie Serviceeinsätze anfragen, Wartungshistorien einsehen und Ersatzteile bestellen können. Das Vorhaben ist groß, die Anforderungen sind unklar, und die Geschäftsführung will vor einer Investition sehen, wie das Portal aussehen könnte. Die Leiterin des Kundendienstes baut in Spark an zwei Nachmittagen einen Prototyp mit erfundenen Beispieldaten, der die wichtigsten Abläufe zeigt. Dieser Prototyp wird in Workshops mit Kunden und Technikern diskutiert und mehrfach angepasst.
Das Ergebnis ist kein fertiges Portal, sondern eine präzise Vorlage. Die eigentliche Entwicklung erfolgt anschließend auf der Infrastruktur des Unternehmens, mit Anbindung an das ERP, einer Anmeldung über das Kundenverzeichnis und einem Betrieb in einem Rechenzentrum in Deutschland. Der Spark-Prototyp hat aber Wochen an Abstimmung gespart und dafür gesorgt, dass alle Beteiligten von Anfang an dasselbe Bild vor Augen hatten. Wichtig war, dass zu keinem Zeitpunkt echte Kundendaten in die Spark-App gelangt sind.
In einem metallverarbeitenden Betrieb berechnet die Arbeitsvorbereitung Rüstzeiten und Materialbedarf bislang mit einer über Jahre gewachsenen Tabelle, die nur ein Mitarbeiter wirklich versteht. Mit Spark entsteht eine kleine App, die dieselben Formeln in einer übersichtlichen Oberfläche abbildet, Eingaben prüft und Ergebnisse nachvollziehbar darstellt. Die App enthält keine personenbezogenen Daten und keine Kundendaten, sondern nur technische Parameter, und kann daher nach einer kurzen Prüfung durch die IT in der Spark-Laufzeit bleiben.
Ein Softwarehaus mit zwölf Mitarbeitenden nutzt GitHub und Copilot bereits intensiv. Spark wird dort gezielt als Ideenwerkstatt eingesetzt: Bevor ein neues Modul für die Branchensoftware geplant wird, entsteht ein schneller Entwurf, der intern und mit ausgewählten Kunden besprochen wird. Wenn die Idee trägt, wird der Entwurf ins Repository übernommen, das Team ersetzt die Spark-spezifischen Bausteine durch die eigene Architektur und entwickelt das Modul regulär weiter. Spark ersetzt hier keine Entwicklung, sondern verkürzt die Phase zwischen Idee und Entscheidung.
Kostenmodell realistisch einschätzen. GitHub Spark ist nach unserem Kenntnisstand nicht separat lizenziert, sondern in bestimmten Copilot-Tarifen enthalten. Die Nutzung verbraucht Kontingente sogenannter Premium-Anfragen, die auch für andere fortgeschrittene Copilot-Funktionen gelten. Jede Anweisung im Spark-Editor beansprucht einen Teil dieses Kontingents, und zusätzliche Anfragen können je nach Tarif und Einstellung kostenpflichtig hinzugebucht werden. Hinzu kommen möglicherweise Kosten oder Grenzen für Hosting, Speicher und KI-Aufrufe in den veröffentlichten Apps. Konkrete Preise, Kontingente und Verbrauchsregeln ändern sich häufig und sollten aktuell bei GitHub geprüft werden.
GitHub ist ein Unternehmen mit Sitz in den USA und gehört zu Microsoft. Spark-Apps, ihre Daten und die Prompts im Editor werden nach unserem Kenntnisstand auf Infrastruktur verarbeitet, die GitHub auf Basis von Microsoft Azure betreibt, und für die Codegenerierung sowie KI-Funktionen in den Apps an Modellanbieter weitergegeben. Damit liegt in aller Regel eine Übermittlung personenbezogener Daten in ein Drittland vor, sobald solche Daten betroffen sind. Grundlage dafür kann das EU-US Data Privacy Framework sein, sofern die beteiligten Unternehmen zertifiziert sind, ergänzt um Standardvertragsklauseln. Zusätzlich unterliegen US-Anbieter dem US CLOUD Act, der Behörden unter bestimmten Voraussetzungen Zugriff auf Daten ermöglicht, unabhängig vom Speicherort.
GitHub bietet für Unternehmenskunden Optionen zur Datenresidenz, etwa eine Variante von GitHub Enterprise Cloud mit Speicherung in der EU. Ob Spark in diesen Umgebungen verfügbar ist und ob dann auch Laufzeit, Datenspeicher und Modellverarbeitung in der EU stattfinden, ist eine Frage, die Sie vor dem Einsatz ausdrücklich bei GitHub klären sollten. Ebenso wichtig ist die Trainingsnutzung: Für Copilot in Unternehmens-Tarifen gibt GitHub an, Kundendaten nicht zum Training von Modellen zu verwenden. Ob und wie diese Zusage für Spark-Prompts, App-Code und App-Daten gilt, sollte schriftlich bestätigt werden, insbesondere bei Nutzung über Einzeltarife. Die datenschutzfreundlichste Option bleibt der Export bewährter Apps und deren Betrieb auf eigener Infrastruktur oder bei einem Anbieter mit Rechenzentrum in der EU, mit einem EU-gehosteten oder lokal betriebenen Modell für KI-Funktionen.
Nach den Nutzungsbedingungen von GitHub verbleiben die Rechte an Inhalten, die Nutzerinnen und Nutzer einbringen oder erzeugen lassen, grundsätzlich bei ihnen. Bei KI-generiertem Code stellen sich aber zusätzliche Fragen: Ob ein Werk ohne nennenswerten menschlichen Beitrag urheberrechtlich geschützt ist, ist rechtlich nicht abschließend geklärt, und generierter Code kann in seltenen Fällen Ähnlichkeiten mit öffentlich verfügbarem Code aufweisen. Für Micro-Apps mit überschaubarer Logik ist das Risiko meist gering. Bei Apps, die zu Produkten werden oder Kunden angeboten werden, sollte der Code vor der Übernahme geprüft und der eigene Anteil an Konzeption und Weiterentwicklung dokumentiert werden.
Bedeutsamer als die Rechte am Code sind meist die Daten in den Apps. Eine scheinbar harmlose App zur Urlaubsplanung enthält Namen und Abwesenheiten, eine Erfassungsmaske für Verbesserungsvorschläge eventuell Hinweise auf Personen oder Kunden. Solche Daten landen im Datenspeicher der Spark-Laufzeit und gegebenenfalls in Modellaufrufen. Unsere klare Empfehlung lautet: In Spark-Apps, die in der Laufzeit von GitHub betrieben werden, nur Beispieldaten, technische Parameter oder ausdrücklich freigegebene, nicht personenbezogene Informationen verarbeiten. Zugangsdaten, Kundendaten und Geschäftsgeheimnisse gehören nicht in Prompts und nicht in den App-Speicher.
Sobald eine Spark-App personenbezogene Daten verarbeitet, handelt es sich um eine Verarbeitungstätigkeit, die im Verzeichnis nach der DSGVO dokumentiert werden muss, mit Zweck, Datenkategorien, Empfängern, Drittlandtransfer und Löschfristen. Bei vielen kleinen Apps kann das schnell unübersichtlich werden, weshalb der in Kapitel 07 beschriebene App-Katalog auch für den Datenschutz wertvoll ist. Werden Apps genutzt, mit denen sich Verhalten oder Leistung von Beschäftigten auswerten lassen, ist in Unternehmen mit Betriebsrat zudem die Mitbestimmung zu beachten. Eine Rahmenvereinbarung für KI-Werkzeuge kann hier viel Einzelabstimmung ersparen.
Der EU AI Act verpflichtet Unternehmen, die KI-Systeme einsetzen, unter anderem dazu, für ausreichende KI-Kompetenz ihrer Beschäftigten zu sorgen. Wer Mitarbeitenden Spark zur Verfügung stellt, sollte daher eine kurze Schulung zu Möglichkeiten, Grenzen und Datenschutzregeln anbieten. Micro-Apps mit KI-Funktionen, die mit Menschen interagieren, können außerdem Transparenzpflichten auslösen, etwa den Hinweis, dass Antworten von einer KI erzeugt werden. Für die üblichen Einsatzszenarien von Spark ist eine Einstufung als Hochrisiko-System unwahrscheinlich, sollte aber bei Apps zu Personalentscheidungen oder ähnlich sensiblen Themen ausdrücklich geprüft werden.
