EU-Kommission: Android soll KI-Assistenten öffnen — Google warnt vor „unwarranted intervention“

Die EU-Kommission setzt gerade den Hebel an, der Androids KI-Schicht vom Google-Monopol lösen kann. Nicht über einen neuen App-Store oder ein neues Telefon, sondern über Interoperabilität auf Systemebene: Wenn die Vorgaben durchkommen, müssen Drittanbieter-KI-Dienste auf Android ähnliche Rechte bekommen wie Googles eigener Assistent Gemini. Das ist keine kosmetische Debatte über Default-Apps, sondern ein Eingriff in die Steuerungsebene des Smartphones: Auslösen per Hotword oder Tastendruck, Zugriff auf Bildschirmkontext, lokale Daten für proaktive Vorschläge, potenziell sogar autonomes Bedienen von Apps und Systemfunktionen. Genau dort sitzt heute der strukturelle Vorteil von Gemini – „special treatment at the system level“, wie die Kommission es faktisch adressiert. Google nennt das eine „unwarranted intervention“ und warnt vor höheren Kosten sowie Risiken für Datenschutz und Sicherheit.

Wichtig ist: Das Verfahren ist kein neues Kartellverfahren im klassischen Sinn, sondern ein „specification proceeding“, das die Durchsetzung des Digital Markets Act (DMA) konkretisiert. Die Kommission hat diese Untersuchung im Januar gestartet. Jetzt liegt ein Rahmen auf dem Tisch, wie Android für KI-Rivalen offener werden soll. Die Konsultationsphase endet am 13. Mai; die finale Entscheidung fällt spätestens am 27. Juli. Bei Nichtbefolgung drohen Strafen von bis zu 10 Prozent des jährlichen globalen Umsatzes. Das alles kann bereits diesen Sommer in konkrete Engineering-Arbeit übersetzt werden – und zwar unter Zeitdruck, weil jede neue System-API eine Angriffsfläche schafft, die Google absichern muss.

Für DACH-Entscheider ist der Fall mehr als Brüssel gegen Big Tech. Er ist ein Vorgeschmack darauf, wie Regulierung und Plattformökonomie im KI-Zeitalter zusammenprallen: Nicht das Modell gewinnt, sondern der Zugang zu Kontext, Daten und Ausführung. Genau diese Achse versucht die EU zu öffnen.

Warum die EU nicht gegen Gemini schießt, sondern gegen Systemvorteile

Die Kommission baut ihren Ansatz nicht auf der Behauptung auf, Gemini sei „zu gut“ oder „zu dominant“ im klassischen Sinne. Sie nimmt den Mechanismus ins Visier, der Dominanz in der KI-Assistenz überhaupt erst schafft: privilegierter Zugriff auf Datenquellen und Systemfunktionen. Auf „any Google-powered Android phone“ ist Gemini beim Einschalten bereits da und erhält Sonderrechte. Das ist der entscheidende Unterschied zu Drittanbieter-Apps, die Du zwar installieren kannst, die aber im Betriebssystem nicht als gleichwertige Steuerinstanz vorgesehen sind.

Ars Technica beschreibt diesen Unterschied sehr greifbar: Du kannst ChatGPT oder Grok installieren und nutzen, „when the need arises“. Aber diese Apps haben nicht den gleichen Zugriff auf Daten und Features wie Gemini. Die Kommission nennt als Beispiele Situationen, in denen Gemini „the only route“ ist – etwa „sending an email in your default mail client or sharing a photo with friends“. Das klingt trivial, ist aber genau der Punkt: Sobald ein Assistent Ausführung in Standard-Apps übernimmt, wird er vom Chatbot zur Betriebssystem-Funktion. Wer dort exklusiv sitzt, definiert für Nutzer, welche KI „funktioniert“ und welche nur redet.

Der DMA liefert der Kommission dafür das Instrumentarium. Er definiert sieben dominante Technologieunternehmen als „gatekeepers“, die „subject to greater regulation“ sind, um fairen Wettbewerb zu sichern. Google hat sich laut Ars Technica „consistently“ gegen diese Regulierung gestellt, steht aber seit Jahren unter diesem Regime. In der aktuellen Auseinandersetzung geht es nicht um die Frage, ob Nutzer theoretisch wählen dürfen, sondern ob Wahlfreiheit praktisch ohne Funktionsverlust möglich ist. Henna Virkkunen, VP für Tech Sovereignty, formuliert das politisch sauber – und technisch deutlich: „interoperability is key“ und die Maßnahmen sollen Nutzern die Freiheit geben, „without sacrificing functionality“ den Dienst zu wählen, der zu ihren Bedürfnissen und Werten passt. Die Logik: Ein alternativer Assistent, der nicht an Hotwords hängt, keinen Screen-Kontext sieht und keine lokalen Daten verarbeiten darf, ist in der Praxis kein Wettbewerber, sondern eine App unter vielen.

Die Kommission verweist außerdem auf eine „solid track record“ beim Öffnen von Plattformmechaniken seit Inkrafttreten des DMA. Als Beispiele nennt Ars Technica: Suchauswahlbildschirme auf Android, alternative Zahlungsmethoden im Play Store und Einschränkungen beim Datenteilen zwischen Diensten. Der Subtext ist eindeutig: Das hier ist die nächste Öffnungsrunde, diesmal auf der KI-Schicht.

• Ars Technica · Europe could force Google to open Android to other AI assistants
• Europäische Kommission · Statement von Henna Virkkunen

Was Brüssel konkret fordert: Hotwords, Kontext, lokale Daten, App-Kontrolle, kostenlose APIs

Der spannendste Teil ist nicht die politische Rhetorik, sondern die technische Wunschliste der Regulierer. Ars Technica beschreibt „several broad changes“, die sich wie ein Pflichtenheft für eine alternative Assistenz-Schicht lesen. Einige Punkte sind naheliegend, andere greifen tief ins Systemdesign.

Erstens: systemweite Invocation. Drittanbieter-KI-Tools sollen „system-wide via hot words or button presses“ aufrufbar sein. Das ist die Voraussetzung dafür, dass ein Assistent überhaupt als Assistenz erlebt wird, nicht als App. Gleichzeitig ist es aus Security-Sicht heikel, weil Hotword-Pipelines und globale Shortcuts an Berechtigungen gekoppelt sind, die heute stark kontrolliert werden.

Zweitens: Screen-Kontext. Regulierer schlagen vor, dass Tools „view screen context“ dürfen, wenn der Nutzer sie öffnet. Das ist technisch ein Paradigmenwechsel: Screenreading bedeutet Zugriff auf UI-Informationen, potenziell inklusive personenbezogener Daten, Token, Inhalte aus Messenger-Apps oder geschäftlicher Dokumente. Ohne sehr enge Berechtigungsmodelle wird das zum Albtraum für Datenschutz-Reviews – und genau hier setzt Googles Gegenargument an.

Drittens: Zugriff auf lokale Daten für proaktive Vorschläge und Zusammenfassungen. Ars Technica schreibt: „Context also extends to allowing alternative AI systems to access local data to generate proactive suggestions and summaries.“ Das ist die Funktion, die Nutzer bei „KI auf dem Telefon“ als Mehrwert wahrnehmen: der Assistent antizipiert, fasst zusammen, schlägt vor. Der Text vergleicht das direkt mit etwas, das nach Googles Magic Cue klingt, das auf Gemini basiert und aus Aktivitäten Vorschläge ableitet. Der entscheidende Satz steht unter dem Screenshot: „Gemini has exclusive system-level access to generate proactive suggestions on many Android phones.“ Exklusivität ist also nicht nur eine Frage des Defaults, sondern der Hintergrundmechanik.

Viertens: autonomes Steuern von Apps und Systemfunktionen. Google experimentiert laut Ars Technica damit, KI bestimmte Apps kontrollieren zu lassen. Das Beispiel: Das Feature „debuted on the Galaxy S26“, und Gemini sei „pretty bad at using apps on your behalf“. Die Kommission will prüfen, ob andere KI-Dienste „autonomously control installed apps and system features“ dürfen. Hier wird Regulierung zur Wette auf Innovation: Vielleicht kann jemand anderes den App-Agenten besser bauen – aber er braucht dafür dieselben Hooks.

Fünftens: Hardwarezugang für lokale Modelle. Viele Gemini-Features, inklusive Magic Cue, basieren laut Text auf „running local models“. Google sei „slow to allow third parties the system access“ für effektives On-Device-Inferencing. Die EU schlägt deshalb eine Pflicht vor, die sicherstellt, dass Entwickler den nötigen Hardwarezugang erhalten, um lokale Modelle „with high levels of performance, availability and responsiveness“ laufen zu lassen. Das ist ein starker Satz, weil er impliziert: Interoperabilität endet nicht bei APIs, sondern umfasst Performance-Charakteristika – also Qualität des Zugangs, nicht nur Existenz.

Sechstens: neue APIs plus technische Unterstützung – „free of charge“. Ars Technica sagt explizit, die Kommission spezifiziert, dass diese Tools kostenlos bereitstehen müssen. Damit nimmt die EU Google die Möglichkeit, Interoperabilität über Gebühren, schlechte Dokumentation oder Support-Engpässe zu bremsen. Für die Plattformökonomie ist das radikal nüchtern: Wenn Du Gatekeeper bist, ist Öffnung nicht „Produkt“, sondern Pflicht.

Aus DACH-Praxisperspektive steckt in dieser Liste eine klare Priorität: Alles, was Deinen Assistenten in Geschäftsprozesse zieht, braucht Zugriff auf Ausführung und Kontext. Ein „Chat“ ohne App-Steuerung bleibt ein Wissens-Frontend. Ein Agent mit App-Kontrolle kann Rechnungen anstoßen, E-Mails schreiben, Workflows starten – aber er muss dafür in sensible Zonen. Genau dort entscheidet sich, ob Regulierung Wettbewerb ermöglicht oder nur zusätzliche Angriffsflächen schafft.

Googles Gegenargument ist nicht nur PR: Autonomie, Kosten, Privacy- und Security-Risiken

Google attackiert die Initiative nicht frontal als „wir wollen kein Wettbewerb“, sondern über zwei Achsen: Autonomie der Gerätehersteller und Schutzmechanismen für Nutzer. Das ist strategisch klug, weil es den Konflikt weg von Marktstruktur hin zu Sicherheits-Trade-offs verschiebt. Ars Technica fasst es zusammen: Google wolle die „autonomy for device makers“ bewahren, KI-Services zu customizen. In einem direkten Statement sagt Googles Senior Competition Counsel Claire Kelly: „This unwarranted intervention would strip away that autonomy, mandate access to sensitive hardware and device permissions; unnecessarily driving up costs while undermining critical privacy and security protections for European users.”

Man kann diese Argumentation nicht einfach als Ausrede abtun, weil die EU-Vorschläge tatsächlich in besonders sensible Ebenen greifen. „Sensitive hardware and device permissions“ ist keine leere Phrase, wenn es um Hardwarezugang für lokale Modelle geht. Je näher Drittanbieter an NPU- bzw. Hardware-Pipelines und Systemdienste rücken, desto mehr muss das Betriebssystem neue Isolationsebenen bauen: Sandboxing für Agenten-Aktionen, Audit-Logs für Kontextzugriff, granularere Berechtigungen für Screenreading, Rate-Limits und Missbrauchserkennung. Das kostet Engineering-Zeit und erhöht Komplexität.

Außerdem ist „Autonomie“ in Android real, nicht nur Marketing. Android lebt davon, dass OEMs eigene Shells, Dienste und Default-Stacks integrieren. Wenn die Kommission systemweite Invocation und tiefe Systemintegrationen standardisiert, greift sie indirekt in OEM-Differenzierung ein. Das ist der Kern von Googles Sorge: Wenn Brüssel vorschreibt, wie Assistenz auf Systemebene einzuhängen ist, dann entsteht ein neuer Compliance-Layer, den Hersteller mittragen müssen – und der sich je nach Region unterscheiden kann. Ars Technica deutet das Risiko an, dass Änderungen „seen outside of the EU“ nicht garantiert sind. Damit stünde Android vor einer EU-spezifischen Assistenz-Architektur, die OEMs für einen Markt pflegen müssen.

Der zweite Teil von Googles Argument – Privacy und Security – trifft den Nerv vieler Unternehmen in DACH. Denn wenn alternative KI-Systeme lokale Daten für proaktive Vorschläge bekommen, stellt sich sofort die Frage: Wie wird das Berechtigungsmodell gestaltet, wie werden Datenabflüsse verhindert, wie wird Missbrauch detektiert? Ein Assistent, der Screen-Kontext sieht, kann theoretisch auch Banking-Screens, HR-Daten oder interne Chats erfassen. Selbst wenn der Zugriff nur „when the user opens them“ erlaubt ist, bleibt das Problem der klaren Nutzeraufklärung und der nachprüfbaren Begrenzung. Und wenn die EU zusätzlich „free of charge“ APIs fordert, reduziert sie Googles Spielraum, Sicherheit über kostenpflichtige Zertifizierungen oder gestaffelte Zugänge zu steuern.

Im Klartext: Der Konflikt ist real. Die EU will funktionale Gleichwertigkeit ohne Funktionsverlust, Google will kontrollierte Öffnung ohne neue Sicherheitslöcher. Beides geht, aber nicht ohne neue Architekturentscheidungen. Genau deshalb ist der Satz im Ars-Text wichtig, dass Google „probably won’t be required to fling the doors open right away“ und dass ein Rush „could risk security or privacy issues“. Selbst der Bericht, der die EU-Linie erklärt, sieht das Timing-Risiko.

Für Dich als Entscheider ist Googles Gegenargument auch deshalb relevant, weil es ein Muster vorgibt: Plattformanbieter werden Interoperabilität bei KI-Agenten systematisch mit Security begründen. Ein Teil davon ist legitime Technik, ein Teil ist Verhandlungstaktik. Wer beides nicht auseinanderhalten kann, landet entweder im Hype („öffnet alles“) oder in der Blockade („geht alles nicht“).

Die Schwachstelle des EU-Ansatzes: Interoperabilität kann KI-Assistenz auch verschlechtern

Die Kommission argumentiert mit „more AI, not less“ – also mit mehr Auswahl und mehr Innovation. Das ist plausibel, aber nicht garantiert. Interoperabilität auf der Assistenz-Schicht hat eine besondere Eigenschaft: Sie multipliziert nicht nur Wettbewerb, sondern auch Verantwortung. Wenn mehrere Assistenten auf denselben Kontext zugreifen dürfen, entsteht ein neues Governance-Problem: Wer haftet für Fehlverhalten, wer erklärt dem Nutzer, warum eine Aktion ausgelöst wurde, und wie werden Konflikte zwischen Assistenz-Stacks gelöst?

Nimm das Szenario „autonomously control installed apps“. Schon heute ist die Qualität bei solchen Agenten laut Ars Technica schwankend; Gemini wird als „pretty bad“ beschrieben. Wenn Du nun Drittanbieter öffnest, bekommst Du potenziell bessere Agenten – aber auch Agenten, die aggressiver handeln, mehr Berechtigungen fordern oder Nutzer in riskante Flows führen. Ohne einheitliche Safety- und UI-Standards kann der Markt genau die Stelle verschlechtern, an der Nutzer Vertrauen brauchen: die Ausführung.

Das zweite Risiko ist Fragmentierung. Wenn die EU Vorgaben macht, die außerhalb Europas nicht gelten, kann das eine „EU-Android“-Variante erzeugen, zumindest in Teilen der Assistenz-Integration. Ars Technica sagt explizit, es gebe „no guarantee any of these proposed changes would be seen outside of the EU“. Für Entwickler ist das unangenehm: Du baust Integrationen, die in Europa funktionieren, aber global anders aussehen. Für Unternehmen mit internationaler Flotte ist das ein Compliance-Problem, weil Policies, App-Settings und Assistenz-Stacks regionalspezifisch werden.

Drittens: Öffnung ohne Performance-Gleichheit kann zu „Choice Screens 2.0“ führen. Die EU fordert zwar „high levels of performance, availability and responsiveness“ beim Hardwarezugang für lokale Modelle. Aber selbst mit Hardwarezugang bleibt die Frage, ob Drittanbieter dieselbe Effizienz, denselben Energieverbrauch und dieselbe Systempriorität bekommen wie ein First-Party-Dienst. Wenn nicht, dann werden alternative Assistenten zwar legal eingebunden, aber in der Praxis schlechter laufen. Dann gewinnt wieder der Default. Interoperabilität ist also nur dann wirksam, wenn sie nicht als API-Checkbox endet, sondern als Qualitätsparität im Alltag ankommt.

Viertens: Datenschutz kann paradoxerweise leiden. Die Kommission will Wahlfreiheit „without sacrificing functionality“. Funktionalität bei Assistenz hängt aber oft an Datentiefe. Wenn mehrere Anbieter Zugriff auf lokale Daten und Bildschirmkontext bekommen, steigt die Zahl der Datenverarbeiter auf dem Gerät. Selbst bei guter Absicherung erhöht sich die Angriffsfläche: mehr Code, mehr Integrationen, mehr potenzielle Fehler. Google nutzt dieses Argument. Es ist aber auch ein echtes Engineering-Trade-off, das die EU nur indirekt adressiert.

Der entscheidende Punkt: Die EU kann Öffnung anordnen, aber sie kann nicht erzwingen, dass der Markt das Ergebnis als „besser“ erlebt. Sie kann nur Rahmenbedingungen setzen, die Chancen erhöhen. Wenn diese Rahmenbedingungen schlecht designt sind, bekommt Android mehr Assistenten – und weniger Vertrauen.

So What? DACH-Strategie zwischen Assistenz-Wahlfreiheit und Governance-Pflichten

Für DACH-Unternehmen ist das kein Mobile-Nerd-Thema, sondern eine strategische Frage: Wer wird zur Standard-Schnittstelle für Wissen, Kommunikation und Ausführung auf Firmenhandys? Wenn die EU Google zwingt, die KI-Schicht zu öffnen, bekommst Du theoretisch Auswahl zwischen mehreren Assistenten. Praktisch musst Du diese Auswahl managen – und zwar unter EU-Regeln, die seit Jahren schrittweise zubeißen.

Heißt im Alltag: Du solltest Deine Mobile- und KI-Strategie getrennt denken. Heute entscheiden viele Unternehmen KI nach Tool-Landschaft („wir nutzen diesen Chatbot“) und Mobile nach MDM-Standards („wir sperren dies, erlauben das“). Wenn Assistenz systemweit per Hotword kommt, Screen-Kontext sieht und Apps steuert, verschmelzen diese Ebenen. Dann wird der Assistent Teil Deiner Endgeräte-Governance, inklusive Berechtigungen, Audit und Incident-Response.

Der konkrete Handlungshebel für Dich: Definiere jetzt, welche Assistenz-Funktionen Du in der Organisation überhaupt zulassen willst, bevor der Markt sie „einfach liefert“. Drei Fragen sind dabei entscheidend: Darf ein Assistent Screen-Kontext sehen? Darf er lokale Daten für proaktive Vorschläge nutzen? Darf er Apps autonom bedienen? Wenn Du diese Policy-Fragen nicht beantwortest, beantworten sie OEMs, Plattformanbieter und einzelne Teams über Schatten-IT.

Regulatorisch lohnt ein Blick auf den EU AI Act als zweiten Rahmen neben dem DMA. Seit Februar 2025 gelten Verbote und eine KI-Literacy-Pflicht; seit August 2025 sind Regeln für General-Purpose-AI, Governance und Strafen in Kraft; ab August 2026 greift der Hauptteil für Hochrisiko-KI. Das bedeutet für Unternehmen: Selbst wenn die Android-Plattform mehr Assistenz zulässt, bleibt Deine Pflicht, KI-Kompetenz aufzubauen und Risiken zu dokumentieren. Wenn ein Assistent geschäftliche Entscheidungen vorbereitet oder automatisiert, kann das schnell in Hochrisiko-Nähe rutschen – nicht weil das Telefon „hochrisiko“ ist, sondern weil der Prozess es ist.

Meine Einordnung: Die EU trifft einen wunden Punkt und Google hat keine einfache Ausweichroute. Aber der Markt wird nicht automatisch „offener“ im Sinne von „besser“. Für DACH-Entscheider liegt der Wert darin, Wettbewerb als Verhandlungsmasse zu nutzen: Wenn Android wirklich mehrere Assistenz-Stacks zulässt, kannst Du Anbieter nach Datenschutzmodell, On-Device-Fähigkeit und Enterprise-Steuerbarkeit auswählen – statt nur nach der besten Demo.

Fazit: Wenn die EU durchzieht, wird „KI auf dem Handy“ zur regulierten Plattformfunktion

Die Kommission hat den Konflikt sauber aufgezogen: Nicht „Gemini verbieten“, sondern Systemprivilegien öffnen. Das ist analytisch die richtige Stelle, weil dort Netzwerkeffekte entstehen. Die vorgeschlagenen Änderungen – Hotwords, Screen-Kontext, lokale Daten, App-Kontrolle, Hardwarezugang und kostenlose APIs – zielen direkt auf die Differenz zwischen Chatbot-App und Systemassistent. Google wird das nicht freiwillig verschenken und argumentiert mit Autonomie, Kosten sowie Privacy und Security. Diese Einwände sind nicht aus der Luft gegriffen, aber sie sind auch Teil einer Verhandlung über Umfang und Tempo der Öffnung.

Meine Prognose: Wenn die Kommission bis spätestens 27. Juli an einem ambitionierten Paket festhält, ist die Wahrscheinlichkeit hoch, dass Android in Europa in den kommenden Jahren eine neue Assistenz-Schicht mit formalen Interoperabilitätsregeln bekommt. Wenn Brüssel hingegen nur minimale API-Zugänge ohne Qualitätsparität durchsetzt, bleibt der Wettbewerb kosmetisch und der Default gewinnt weiter. Für Dich heißt das: Warte nicht auf den finalen Text. Bau jetzt Governance für Assistenz-Zugriffe auf Kontext und Ausführung, damit Du Optionen nutzen kannst, sobald sie real werden – und nicht erst reagierst, wenn der erste Agent im Unternehmen eigenständig Mails verschickt.