These: Googles Gemini agent macht das Prompt-Fenster zum Gatekeeper – wer Agent-Identität und Modellwahl abgibt, gibt Kontrolle ab

Vergessen Sie den Chatbot. Wer bei „Gemini agent“ an ein weiteres Eingabefenster denkt, hat den Punkt verfehlt. Am 8. Oktober hat Google Cloud auf dem Event „Gemini at Work 2026“ etwas vorgestellt, das wie ein Assistent aussieht und meiner Ansicht nach ein Kontrollzentrum ist.

Der Gemini agent ist laut Google ein einziger, universeller Agent für die Arbeit, der Modellwahl, Kostenkontrolle und Governance mitbringt. These: Wer diese Schicht besitzt, besitzt die Arbeit. Das ist meine Einordnung, nicht Googles Aussage. Die Marge und das Risiko stecken nicht im Chatbot, sondern darin, wer Agent-Identität, Berechtigungen, Policy und Modell-Routing in der Hand hält. Und ob Ihre Firma das selbst orchestriert oder an einen Cloud-Gatekeeper abgibt.

Die Grundlage sind Googles Ankündigung und der ausführlichere Text von Google-Cloud-Chef Thomas Kurian. Alles, was ich Google zuschreibe, stammt aus diesen beiden Quellen. Alles andere ist ausdrücklich meine Meinung. Wir bei digital-magazin.de halten diese Trennung für Pflicht, gerade bei einem Thema, bei dem Marketing und Architektur so dicht beieinanderliegen.

Gemini agent: Ein universeller Agent für die Arbeit, laut Google

Beginnen wir mit dem, was Google behauptet. Laut Google beginnt Arbeit jetzt im Prompt-Fenster. Gemini habe den gesamten Geschäftskontext einer Organisation und lasse sich für alles nutzen, von Wissensarbeit über Fragen und Content bis zum Coding, alles aus einer einzigen Eingabebox. Der Agent plane die Arbeit, nutze Skills und Werkzeuge, verbinde sich mit den Geschäftssystemen der Cloud-Kunden und bringe etwas Fertiges zurück. Und zwar in den Dokumenten, im Postfach und in den Entwicklungsumgebungen, in denen die Leute ohnehin arbeiten (übersetzt).

Google-Cloud-Chef Thomas Kurian schreibt im Google-Cloud-Blog zur Keynote von „a single, universal agent for work“, außerdem von einem einzigen Agenten und einer einzigen API. Sein Kernsatz, sinngemäß übersetzt: Sie geben dem Agenten Ziele, nicht Anweisungen. Sie delegieren ein Ergebnis und kommen zu fertiger Arbeit zurück. Damit das funktioniere, müsse der Agent mit Ihren persönlichen Workflows, Ihren führenden Systemen und Ihren Unternehmenskontrollen verbunden sein.

Lesen Sie den letzten Halbsatz noch einmal. Unternehmenskontrollen. Das ist nicht das Vokabular eines Chatbots. Das ist das Vokabular einer Plattform.

Wie breit der Agent angelegt ist, zeigt der Zugang. Laut Kurian läuft er im Web, auf iOS, Android, Windows und Mac. Als Kanäle nennt er Kommandozeile, Google Workspace, Microsoft 365 oder Slack. Es gibt ihn auch als „headless agent“, also ohne eigene Oberfläche. Ein Agent, der keine Oberfläche braucht, ist kein Produkt zum Anschauen. Er ist Infrastruktur.

Dazu die Rollen. Laut Kurian kann der Agent persönlicher Assistent sein oder Teammitglied, etwa „like a project manager within a team“ oder, für eine Rolle, „like an analyst in your finance department“. Das Bild ist bewusst gewählt: Kollege statt Werkzeug.

Wir bei digital-magazin.de haben am 8. Oktober Routing zwischen großen und kleinen Modellen als Kosten-Hebel beschrieben – hier geht es um die Frage, wer den Router besitzt.

Das Kontrollzentrum ist das Produkt, nicht der Chatbot

Mythos: Der Wettbewerb dreht sich darum, wer das klügste Modell hat. Realität: Das Modell wird austauschbarer, die Schicht darüber nicht.

Warum? Weil ein Agent, der wirklich Arbeit erledigt, vier Dinge braucht, die mit Intelligenz wenig zu tun haben. Eine Identität. Berechtigungen. Eine Policy, die sagt, was nie passieren darf. Und eine Entscheidung, welches Modell welchen Job bekommt. Genau diese Punkte stellt Google selbst in den Mittelpunkt: Identität, Berechtigungen, Policy samt Agent Gateway, Observability und Modellwahl samt Kostenkontrolle.

Ich finde das bemerkenswert. Nicht, weil Google es erfindet, sondern weil es so offen auf den Tisch kommt. So lese ich die Botschaft an Entscheidende: Das Interessante ist nicht, was der Agent sagt, sondern was er darf.

Meine These dazu: Wer diese Schicht besitzt, besitzt die Arbeit. Denn wenn Aufgaben über einen Agenten laufen, der sich im Auftrag Ihrer Mitarbeitenden bewegt, dann entscheidet die Schicht darunter, wer welchen Zugriff bekommt, was protokolliert wird und welche Rechenleistung welchen Vorgang bearbeitet. Das ist keine IT-Nebensache. Das ist Betriebsführung.

Hand aufs Herz: Wie viele Firmen haben diese Schicht heute überhaupt als eigene Schicht gedacht? Viele haben, so mein Eindruck, Agenten-Inseln. Ein Bot in der Kundenabteilung, ein Skript in der Finanzabteilung, ein Experiment im Entwicklungsteam. Jede Insel mit eigenem Zugang, eigener Logik, eigener Lücke.

Da liegt der Reiz eines zentralen Angebots. Meiner Einschätzung nach ist es für viele Firmen bequemer und vermutlich sicherer als die Summe selbst gebauter Insellösungen. Das sage ich ohne Zahl, weil ich keine belegen kann. Es ist ein Eindruck aus der Praxis, keine Messung.

Aber bequem ist nicht gratis. Es ist eine Abhängigkeitsentscheidung. Dazu gleich mehr.

Agent-Identität: Der Coworker mit eigener Personalakte

Jetzt wird es konkret, und es ist der Teil, den ich am spannendsten finde. Laut Kurian kann der Agent dynamisch eine Liste von Sub-Agenten anlegen, temporäre, auftragsspezifische Agenten, jeder mit eigener Identität (übersetzt). Daneben gibt es Coworker-Agenten. Zitat sinngemäß übersetzt: Sie haben dedizierte Identitäten samt eigener E-Mail-Adresse der Form @agents.company.com, eigenen dauerhaften Speicher, und sie haben nur Zugriff auf den Kontext, den Sie oder Ihre Teammitglieder ihnen geben.

In Workspace, so Kurian, erhält der Agent ein eigenes Workspace-Konto mit E-Mail-Adresse, Kalender, Drive und einem Eintrag im Firmenverzeichnis. Und: Ein Coworker-Agent handle unter seiner eigenen Identität statt unter Ihrer, und er sehe nur, was Sie mit ihm teilen (übersetzt).

Mein Bild dazu, ausdrücklich meins: Stellen Sie sich einen Coworker-Agenten wie einen neuen Kollegen mit Personalakte vor. Eigene Adresse, eigener Kalender, eigener Verzeichniseintrag. Und wie bei jedem Menschen stellt sich sofort die Frage: Wer hat ihn eingestellt, wer führt die Akte, wer kann ihm kündigen?

Ein hypothetisches Szenario. Ihre Einkaufsabteilung legt einen Coworker-Agenten an, der Lieferantenanfragen vorbereitet. Er bekommt ein Postfach, einen Ordner und Zugriff auf die Vertragsablage der Abteilung. Drei Monate später verlässt die Teamleiterin die Firma. Wem gehört der Agent? Wer hat seine Rechte freigegeben? Wer weiß überhaupt noch, dass er existiert?

Das ist kein Gedankenspiel für Paranoide. Das ist der normale Lebenszyklus von Zugängen, nur eben mit einem neuen Typ von Konto. Wir bei digital-magazin.de haben die Grundlagen dazu im Stück über Regeln, Rechte, Logs und Not-Aus für Agenten im Unternehmen beschrieben. Dort geht es um die Fragen, die eine Firma klären sollte, bevor der erste Agent produktiv geht. Googles Ansatz beantwortet vieles davon auf Plattformebene. Die Frage bleibt, auf wessen Plattform.

Auch die Persistenz gehört hierher. Laut Kurian läuft der Agent in der Cloud mit einem einzigen Satz aus Erinnerungen, Kontext und einem Personalisierungsgraphen. Die Arbeit laufe weiter, wenn Sie den Laptop schließen (übersetzt). Dazu nennt Google vier Arten von Gedächtnis: Session, semantisch, prozedural und episodisch. Ein Agent mit so einem Gedächtnis ist wertvoll. Und genau deshalb ist die Frage nach dem Besitz dieses Gedächtnisses keine Detailfrage.

Gemini-Governance: Die vier Fragen laut Google

Kurian ordnet das Thema Governance über vier Fragen. Ich gebe sie sinngemäß übersetzt wieder, es sind Googles Fragen:

1. Wer ist der Agent, und welche Identität hat er?
2. Was darf er tun, beziehungsweise welche Berechtigungen hat er erhalten?
3. Was hat er getan, und wo kann ich nachsehen, was er getan hat?
4. Was soll er niemals anfassen?

Laut Kurian beantworten Identität, Policy und Observability die ersten drei Fragen. Die vierte beantworte der Agent Gateway. Gehen wir das durch.

Frage 1: Wer ist der Agent?

Laut Google bekommt jeder Agent eine eigene Identität, kryptografisch beglaubigt und wie ein Mitarbeitender verwaltet, mit minimalen Rechten (übersetzt, „least privilege“). Diese Identität werde in die Logs gestempelt, die seine Arbeit festhalten, und in jede virtuelle Maschine, die in seinem Auftrag Code ausführt.

Meine Gegenfrage: Und wer beantwortet sie, wenn Sie den Anbieter wechseln?

Frage 2: Was darf er?

Laut Kurian gibt es fein abgestufte, rollenbasierte Zugriffsrechte, die von der Sicherheitsadministration Ihrer Organisation freigegeben werden. Verbindet sich der Agent mit einem externen System, werde seine Identität über Industriestandards wie OAuth abgebildet und weitergereicht (übersetzt).

Das ist ein guter Punkt für Google, denn OAuth ist kein Geheimnis. Trotzdem: Und wer beantwortet sie, wenn Sie den Anbieter wechseln?

Frage 3: Was hat er getan?

Laut Kurian wird jede Aktion von Gemini in einen Audit-Trail geschrieben und dem Agenten zugeordnet, nicht einer Person (übersetzt). Ich halte das für sauber gedacht. Es trennt „der Mensch hat es getan“ von „der Agent hat es getan“. Wer je ein Protokoll nach einem Vorfall lesen musste, weiß, wie viel Wert diese Trennung hat.

Aber auch hier: Und wer beantwortet sie, wenn Sie den Anbieter wechseln? Wo liegt die Historie, in welchem Format, und wie lange kommen Sie daran?

Frage 4: Was darf er nie anfassen?

Hier kommt der Agent Gateway ins Spiel. Laut Kurian laufen alle Gemini-Agenten in einer Agent Sandbox mit eigener Netzwerkgrenze. Sämtlicher Verkehr, hinein, hinaus und zwischen Agenten, gehe durch den Agent Gateway, eine KI-Netzwerk-Firewall, die die Richtlinien Ihrer Organisation in Echtzeit durchsetze. Man schreibe die Policy einmal, zum Beispiel „Agenten dürfen keine Dokumente öffnen, die als Need to Know klassifiziert sind“. Gemini wende sie auf jeden Agenten im Unternehmen an, statt einen Agenten nach dem anderen zu prüfen (übersetzt).

Ich halte das für den elegantesten Teil des Konzepts. Eine Regel, überall wirksam. Und genau deshalb der heikelste: Wer die Regel schreibt und durchsetzt, bestimmt, was Arbeit überhaupt sein darf. Und wer beantwortet das, wenn Sie den Anbieter wechseln?

Eine ehrliche Anmerkung: Google sagt nicht, ob der Agent Gateway auch Agenten anderer Anbieter kontrolliert. Aus den Quellen geht nur hervor, dass er für Gemini-Agenten gilt. Mehr dazu weiter unten.

Modellwahl und Smart Routing: Wer entscheidet, wer rechnet?

Laut Kurian ist Gemini der Agent, und das Modell darunter eine getrennte Wahl. Der Agent führe jeden Job auf dem Modell aus, das am besten passt. Heute orchestriere er über die Gemini-Modellfamilie und Claude-Modelle von Anthropic, künftig kämen andere führende private und offene Modelle hinzu (übersetzt). Sinngemäß ebenfalls: Das beste Modell für eine Aufgabe sei nicht immer das größte. Und das führende Modell wechsle alle paar Monate, weshalb eine offene Wahl dafür sorge, dass Kontext, Skills und Daten bleiben, wenn es sich ändert. Zudem könne man verschiedene Modelle für bestimmte Aufgaben in größeren Projekten kombinieren.

Das klingt vernünftig. Es ist auch genau die Logik, die wir im Routing-Beitrag als Kostenhebel beschrieben haben. Aber lesen Sie, was dahintersteht: Eine Instanz entscheidet pro Aufgabe, welches Modell läuft. Google nennt sie selbst „our routing tool“, also Googles eigenes Werkzeug.

Dazu das Kostenargument. Kurian schreibt, zwei Faktoren entschieden, ob ein Agentenprogramm im Unternehmen gelingt oder stockt: ob man es steuern kann und ob man es bezahlen kann (übersetzt). Das Routing-Werkzeug sortiere Unternehmenslasten automatisch, sodass jede auf dem Modell laufe, das die höchste Leistung zu den geringstmöglichen Kosten liefere (übersetzt).

Dann die Spend Caps. Laut Google können Sie in der Cloud Billing Console ein hartes Limit für die KI-Ausgaben eines Projekts setzen. Gemini setze es durch. Wird es ausgelöst, pausiert der Agent des Projekts, und Sie setzen ihn per Klick fort. Weil pro Projekt gemessen wird, können Firmen KI-Kosten einzelnen Abteilungen zurechnen, Stichwort Chargeback.

Für Controllende ist das ein gutes Signal. Ein harter Deckel pro Projekt ist besser als eine Überraschung am Monatsende. Ich finde das ausdrücklich sinnvoll.

Aber die harte Wahrheit: Ein Router, der automatisch entscheidet, ist eine Black Box, solange Sie nicht wissen, nach welchen Kriterien er entscheidet. Google sagt nichts darüber, wie gut die automatische Modellwahl in der Praxis arbeitet. Es gibt in den Quellen keine Messung. Und Google sagt auch nicht, ob Kunden die automatische Wahl erzwingen oder abschalten können.

Ein hypothetisches Beispiel. Ihre Rechtsabteilung braucht für eine bestimmte Vertragsprüfung ein bestimmtes Modell, aus Gründen, die Ihre Compliance festgelegt hat. Der Router findet ein günstigeres, das laut seiner Logik gut genug ist. Wer gewinnt? Wenn die Antwort „es kommt auf die Konfiguration an“ lautet, dann ist das genau die Frage, die Sie vor dem Einkauf klären müssen.

Skills, Tools, Memory: Wo die Arbeit eingeschlossen wird

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptPhotorealistic close photo of a hand holding a plain white access card without any print in front of a generic card reader with a small green light, modern office in the background, shallow depth of field, no logos, no brand marks, no readable text, no letters, no watermarks, 16:9

Laut Kurian gibt es Konnektoren unter anderem zu Microsoft Office, Teams, Slack, Salesforce, ServiceNow, Jira, BigQuery und Snowflake sowie zu jedem MCP-Server (Model Context Protocol), innerhalb oder außerhalb des Firmennetzes (übersetzt). Dazu kommen ein Enterprise-Tools-Registry und ein Skills-Registry für die Firma.

Das ist die eigentliche Bindung. Nicht das Modell, nicht die Oberfläche. Sondern die angesammelte Arbeit: Skills, die Ihre Teams schreiben, Prozesse, die der Agent lernt, Erinnerungen, die er aufbaut. Mit jedem Monat wird dieser Bestand wertvoller. Und mit jedem Monat wird ein Wechsel teurer.

Google sagt nicht, ob und wie sich Skills und Memory exportieren lassen. Die Quellen schweigen dazu. Das ist keine Unterstellung, sondern eine Lücke, die Sie in jedem Gespräch mit dem Anbieter schließen sollten.

Ein ähnliches Muster haben wir bei den ERP-Systemen beschrieben. Unser Stück Wer den ERP-Agent-Gateway kontrolliert, besitzt die Workflows trägt die These schon im Titel. Beim Gemini agent sehe ich die gleiche Logik, nur eine Ebene höher: nicht im ERP, sondern über den Werkzeugen insgesamt.

Und Microsoft? Dessen Ansatz mit dem Copilot Autopilot ist ein Gegenmodell, über das wir bereits geschrieben haben. Mehr braucht es hier nicht. Der Punkt ist: Der Wettbewerb um die Kontrollschicht hat begonnen, und er findet nicht im Chatfenster statt.

Was Sie bauen, bleibt Ihres – das Gegenversprechen laut Google

Fairness gehört dazu. Google gibt Versprechen ab, und die sollte man ernst nehmen. Laut Kurian gilt: „What you build stays yours: Your people and your data do not need to move, and your proprietary inputs and outputs remain entirely your own.“ Übersetzt: Was Sie aufbauen, bleibt Ihres. Ihre Leute und Ihre Daten müssen nicht umziehen, und Ihre proprietären Eingaben und Ausgaben bleiben vollständig Ihre eigenen.

Außerdem verspricht Google, Komplexität zu beseitigen: Google baue und integriere den gesamten Stack, von Silizium über Modelle, Skills und Werkzeuge bis zur Sicherheit (übersetzt). Und das Angebot unterstütze Ihre Wahl der Modelle.

Das ist kein leeres Versprechen. Dass Eingaben und Ausgaben Ihnen gehören, ist ein wichtiger Satz, und dass die Modellwahl offen gehalten wird, zeigt sich schon daran, dass Claude-Modelle von Anthropic laut Google bereits dabei sind. Ein Anbieter, der einen Konkurrenten ins eigene Produkt lässt, signalisiert Offenheit. Das würdige ich.

Jetzt mein Einwand. Beachten Sie die Spannung zwischen zwei Sätzen. Bei Modellen ist Google offen. Beim Stack ist Google integriert. Beides steht im selben Text. Offen ist die Auswahl dessen, was im Motorraum läuft. Integriert ist alles, was das Auto zusammenhält: Identität, Policy, Gateway, Registry, Gedächtnis, Abrechnung.

Dass Ihre Daten Ihnen gehören, heißt nicht, dass Ihre Prozesslogik portabel ist. Daten sind das eine. Die Art, wie Agenten mit Ihren Daten arbeiten, ist das andere. Und die steckt in Skills, Policies und Erinnerungen.

Seien wir ehrlich: Kein Anbieter schreibt „Wir wollen Sie binden“ in einen Blogpost. Die Bindung entsteht nicht durch Absicht, sondern durch Bequemlichkeit. Und Bequemlichkeit ist in der IT ein verdammt guter Klebstoff.

Was Google nicht sagt: Die Lücken im Gemini-agent-Pitch

Klartext: Aus den beiden Quellen lässt sich vieles nicht beantworten. Das ist kein Vorwurf, sondern eine Einkaufsliste mit offenen Fragen.

• Preis und Lizenz: Es gibt weder einen Preis noch eine Lizenzstufe.
• Verfügbarkeit: Ein Termin für die allgemeine Verfügbarkeit fehlt.
• Region: Keine Angabe zur Verfügbarkeit in der EU oder in Deutschland, und keine Aussage zur EU-Datenresidenz.
• Claude-Modelle: Welche konkret eingebunden sind, steht nirgends. Ich spekuliere hier bewusst nicht.
• Qualität des Routings: Es gibt keine Messung, wie gut die automatische Modellwahl entscheidet.
• Steuerbarkeit: Unklar bleibt, ob Kunden die automatische Modellwahl erzwingen oder abschalten können.
• Wirtschaftlichkeit: Es gibt keine ROI-Zahl.
• Fremde Agenten: Unklar ist, ob der Agent Gateway Agenten anderer Anbieter kontrolliert.
• Portabilität: Ob und wie sich Skills und Memory exportieren lassen, bleibt offen.

Eine Sache muss ich noch geraderücken, weil sie leicht verwechselt wird. Laut Google sind die Branchen-Spezialisierungen für Finanzdienstleistungen und Recht jetzt in der Preview, für Behörden, Gesundheitswesen und Handel kommen sie bald. Das beschreibt den Status der Branchenvarianten. Es sagt nichts darüber, wann der Gemini agent selbst verfügbar ist.

Für deutsche Unternehmen sind besonders die Regionsfrage und die Datenresidenz entscheidend. Ohne Antwort darauf können Datenschutzbeauftragte und Betriebsräte nicht sinnvoll entscheiden. Sie sollten diese Fragen stellen, bevor ein Pilotprojekt startet, nicht danach.

Was CIOs und CISOs jetzt tun sollten

Genug analysiert. Hier ist, was ich an Ihrer Stelle ganz oben auf dem Zettel hätte.

1. Klären Sie Agent-Identitäten im eigenen IAM, bevor es ein Anbieter für Sie tut. Wenn Ihr Identitätsmanagement nicht weiß, was ein Agentenkonto ist, wird es das Konto des Anbieters definieren. Legen Sie fest: Wer darf Agenten anlegen, wer genehmigt Rechte, wer löscht sie?
2. Schreiben Sie Policies portierbar. Formulieren Sie Regeln wie „keine Need-to-Know-Dokumente“ zuerst in Ihrer eigenen Sprache und in Ihrem eigenen Regelwerk. Dann übersetzen Sie sie in das Format des Gateways, nicht umgekehrt.
3. Fragen Sie nach dem Export von Skills und Memory. Schriftlich, vor dem Vertrag. Die Quellen sagen dazu nichts, also verlangen Sie eine Antwort.
4. Führen Sie ein Inventar Ihrer Agenten. Jeder Agent mit Namen, Zweck, Verantwortlichen, Rechten und Ablaufdatum. Ohne Inventar gibt es keine Governance, nur Hoffnung.
5. Nutzen Sie Spend Caps und Chargeback. Aus Controlling-Sicht ist ein hartes Limit pro Projekt samt Zurechnung auf Abteilungen ein gutes Werkzeug, solange Sie die Schwellen selbst festlegen.
6. Verlangen Sie Klarheit über das Routing. Können Sie ein Modell für sensible Aufgaben festschreiben? Wenn nicht, wissen Sie, wo die Grenze Ihrer Kontrolle liegt.

Und eine Frage an die Geschäftsleitung, nicht nur an die IT: Wollen Sie diese Schicht selbst orchestrieren oder abgeben? Beides ist legitim. Falsch ist nur, es nicht zu entscheiden.

Selbst orchestrieren oder abgeben: Eine Abhängigkeitsentscheidung

Beide Wege haben Preise, und keiner ist kostenlos.

Wer selbst orchestriert, behält die Hoheit über Identität, Policy und Routing. Bezahlt wird mit Aufwand. Es braucht Leute, die Agenten-Identitäten verstehen, Gateways bauen, Logs auswerten und Modelle wechseln können. Mehr Freiheit, mehr Arbeit. Und die Gefahr bleibt, genau die Inselbildung zu produzieren, vor der ich gewarnt habe: viele kleine Lösungen, die keiner überblickt.

Wer abgibt, bekommt ein integriertes Paket. Weniger Aufwand, einheitliche Regeln, ein Gegenüber. Bezahlt wird mit Abhängigkeit: von den Preisen, die der Anbieter später setzt, von den Modellen, die der Router wählt, von den Formaten, in denen Ihr Gedächtnis liegt.

Mein Eindruck, wieder ausdrücklich Meinung: Für viele mittlere und große Firmen wird der zentrale Weg der realistischere sein. Nicht weil er ideal ist, sondern weil die Alternative, nämlich selbst gebaute Agenten-Inseln mit je eigener Sicherheitslogik, in der Praxis oft schlechter gepflegt wird. Ein sauber betriebener Gatekeeper schlägt einen Zoo vergessener Bots.

Aber das ist kein Freibrief. Wer abgibt, sollte vertraglich und technisch dafür sorgen, dass er wieder gehen kann. Ein Ausstieg, der nur auf dem Papier existiert, ist keiner.

Ein Mittelweg lautet: Identität und Policy im eigenen Haus führen, Ausführung und Modelle beim Anbieter. Ob das mit dem Gemini agent geht, lässt sich aus den Quellen nicht ablesen. Es ist aber die Frage, die ich als Erstes stellen würde.

Genau.

Wer den Router besitzt, besitzt die Arbeit. Punkt.