Kategorie: KI-News

„Joining Cloudflare to make the Workers programming model a mainstream way to build servers.“ Mit diesem Ziel begründet Ryan Dahl, Mitgründer von Deno und Schöpfer von Node.js, dass sich sein Team Cloudflare anschließt. So berichtet es Anthony Ha in einer kurzen Meldung bei TechCrunch. Dahinter steckt kein Produktversprechen, sondern eine Aussage über Reichweite: Er will ein Programmiermodell aus der Nische in den Normalfall bringen.

Cloudflare bestätigte den Deal an einem Freitag. Kenton Varda, Principal Engineer für Cloudflare Workers, nennt als Ziel, das Programmiermodell und die Plattform zu verbessern, auf der Kunden Software im Netzwerk von Cloudflare bauen und betreiben. Wie die Integration technisch aussehen soll, steht nicht in der Ankündigung. Damit bleibt offen, ob Deno als eigenständiges Projekt weiterlebt oder als Baustein in Workers aufgeht.

Was Cloudflare ankündigt – und wer dahintersteht

Für einen Vorgang dieser Größe bleibt die Ankündigung schmal. Sie nennt das Ziel, die beteiligten Personen und ein Detail aus der jüngsten Produktgeschichte. Zahlen nennt sie nicht. Die finanziellen Bedingungen wurden nicht veröffentlicht, was bei kleineren und mittleren Deals üblich ist, aber jede Bewertung erschwert. Wer wissen will, ob Cloudflare viel oder wenig bezahlt hat, bekommt keine Antwort.

Deno wurde von Bert Belder und Ryan Dahl gegründet. Dahl hatte zuvor Node.js geschaffen, die heute dominierende Laufzeitumgebung für JavaScript außerhalb des Browsers. Nach Angaben aus der Berichterstattung hat Deno insgesamt 26 Millionen Dollar eingesammelt, darunter eine Series A unter Führung von Sequoia. Wie es wirtschaftlich um Deno stand, geht aus der Meldung nicht hervor. Allgemein gilt: Wagniskapitalgeber erwarten irgendwann einen Ausstieg, und eine Übernahme ist einer der üblichen Wege dorthin.

Auffällig ist, wer den Kauf für Cloudflare erklärt: nicht die Marketingabteilung, sondern Kenton Varda, Principal Engineer für Workers. Das passt zum genannten Ziel, das ein technisches ist: das Programmiermodell und die Plattform zu verbessern.

Warum ein Programmiermodell mehr als eine Schnittstelle ist

Ein Programmiermodell lässt sich mit einem Bauplan samt Hausordnung vergleichen. Es legt fest, welche Werkzeuge zur Verfügung stehen, wo gearbeitet wird, wie lange etwas dauern darf. Und es legt fest, was ein Programm über seine Umgebung annehmen darf. Bei Cloudflare Workers heißt das: Code läuft nicht in einem Rechenzentrum, das man selbst ausgewählt hat, sondern an vielen Punkten im Netzwerk, nah an den Nutzern. Funktionen sind kurzlebig, Zustand ist die Ausnahme, und alles, was dauerhaft gespeichert wird, muss über zusätzliche Dienste laufen.

Solche Regeln klingen nach Detail, prägen aber den Alltag. Sie entscheiden, welche Bibliotheken funktionieren, welche Entwurfsmuster sinnvoll sind und welche Architektur überhaupt möglich ist. Wer jahrelang für klassische Server programmiert hat und auf ein solches Modell wechselt, muss nicht eine neue Sprache lernen, sondern eine neue Grammatik derselben Sprache. Diese Umstellung kostet Zeit. Zeit ist der größte Widerstand gegen jede neue Plattform.

Wenn ein Anbieter ein Programmiermodell verbessern will, heißt das selten „mehr Funktionen“. Es heißt meistens: weniger Stellen, an denen man umdenken muss. Eine Plattform wird attraktiv, wenn sich gewohnte Denkweisen übertragen lassen, ohne dass die Besonderheiten der Umgebung verschwinden. Das ist der schmale Grat, auf dem Cloudflare mit Workers arbeitet – und der Punkt, an dem ein Team wie das von Deno nützt.

Celld und der Notausgang: Open Source als Verkaufsargument

Deno hat zuletzt celld veröffentlicht, eine quelloffene Implementierung von Workers. Varda schreibt, das Projekt habe das Cloudflare-Team begeistert. Das lässt sich als freundliche Geste lesen, ist aber mehr: Eine fremde Implementierung derselben Plattform beweist, dass das Modell beschreibbar und nachbaubar ist. Wer so etwas baut, dokumentiert ungewollt, ob die eigenen Regeln klar genug sind.

Varda widerspricht ausdrücklich einer „populären Theorie“, Cloudflare habe Workers absichtlich anders gebaut als andere Cloud-Plattformen, um Kunden einzusperren. Seine Gegenposition: Quelloffen zu sein und den Leuten einen Fluchtweg zu geben, sei gutes Geschäft. Ein bemerkenswerter Satz von einem Plattformanbieter, dem Kritiker genau diese Bindung vorgeworfen haben. Er funktioniert nur, wenn man ihn ernst nimmt: Der Fluchtweg ist keine Nettigkeit, sondern ein Verkaufsargument.

Dahinter steht eine einfache Logik. Wer eine Plattform nur nutzt, weil er nicht mehr wegkommt, plant bereits den Ausstieg und investiert so wenig wie möglich. Wer weiß, dass er jederzeit gehen könnte, bleibt eher freiwillig und investiert mehr. Übertragen auf das Bild vom Gebäude: Ein Haus mit verschlossenen Türen vermietet sich schlechter als eines, bei dem im Flur sichtbar ein Notausgang ausgeschildert ist. Die Ausschilderung beweist keine Sicherheit, aber ohne sie zieht niemand ein.

Ryan Dahl: von Node.js über Deno zu Cloudflare

Dahl ist zweimal dasselbe Problem angegangen. Node.js machte JavaScript auf dem Server salonfähig und wurde zum Fundament unzähliger Werkzeuge. Später kritisierte Dahl Teile seines eigenen Entwurfs öffentlich und gründete mit Deno einen zweiten Anlauf: sicherer per Voreinstellung, mit TypeScript als erstklassigem Bürger, mit einem moderneren Modulsystem. Deno war damit nie nur ein Konkurrent zu Node, sondern auch eine Korrektur.

Wie gut Deno davon leben konnte, sagt die Meldung nicht. Grundsätzlich gilt: Laufzeitumgebungen sind Infrastruktur, und Infrastruktur lässt sich schlecht verkaufen, wenn das Publikum aus Entwicklern besteht, die kostenlose Alternativen gewohnt sind. Node ist kostenlos, die Browser sind kostenlos, und Standards werden von Gremien gepflegt, nicht von Firmen. Ein Start-up trägt in diesem Umfeld die Entwicklungsarbeit, während der Nutzen breit gestreut ist.

Dahls eigene Begründung ist deshalb nüchtern: Sein Team schließe sich Cloudflare an, um das Workers-Programmiermodell zu einem gängigen Weg zu machen, Server zu bauen. Das lässt sich als Kapitulation vor dem Geschäftsmodell lesen – oder als Einsicht, dass ein Programmiermodell nur dann Mainstream wird, wenn jemand dahintersteht, der es in großem Maßstab betreiben kann. Eine eigenständige Laufzeit kann Standards prägen, aber sie kann sie selten durchsetzen.

Was die Übernahme für Entwickler bedeutet

Zu konkreten Änderungen für bestehende Workers-Projekte sagt die Ankündigung nichts, weder einen Zeitplan noch Zusagen. Erfahrungsgemäß verlaufen solche Integrationen eher schrittweise als über Nacht. Die spürbaren Veränderungen kommen dort, wo Deno-Technik heute schon nachwirkt: bei Werkzeugen, bei der lokalen Entwicklungsumgebung, bei der Frage, wie sich Workers-Code außerhalb von Cloudflare ausführen lässt.

Mittelfristig wird genau das interessant. Wenn Cloudflare will, dass celld als quelloffene Implementierung ernst genommen wird, muss das Projekt weiter gepflegt werden – denn ein Fluchtweg, der nur auf dem Papier existiert, ist keiner. Für dich heißt das: Du kannst prüfen, ob sich dein Code zwischen Anbietern bewegen lässt, und das als Kriterium für Architekturentscheidungen nehmen. Das bleibt ein Vorteil, egal wie die Übernahme ausgeht.

Die Kehrseite ist Konsolidierung. Jede Übernahme nimmt eine unabhängige Stimme aus dem Markt, und bei Laufzeiten ist Vielfalt mehr als Nostalgie. Wer die Entwicklung von Deno verfolgt hat, verliert einen Anbieter, der Entscheidungen ohne Rücksicht auf eine große Cloud hätte treffen können. Ob diese Stimme innerhalb von Cloudflare weiter hörbar bleibt, wird sich nicht an Ankündigungen messen lassen, sondern an Commits, Veröffentlichungen und der Frage, wer künftig über den Kurs entscheidet.

Offene Fragen: Preis, Unabhängigkeit, Zukunft von Deno

Die finanziellen Bedingungen wurden nicht genannt, und damit fehlt die Grundlage für jede Bewertung. Bei einem Unternehmen, das 26 Millionen Dollar eingesammelt hat und Investoren wie Sequoia im Boot weiß, ist der Kaufpreis die interessante Zahl. Er verrät, wie viel eine quelloffene Infrastruktur-Firma im Verhältnis zu den eingesammelten Mitteln wert war. Ohne diese Zahl bleibt nur die öffentliche Rhetorik, und Rhetorik ist keine Bilanz.

Offen ist auch, was mit Deno als eigenständiger Laufzeitumgebung passiert. Das Projekt ist quelloffen, die Gemeinschaft könnte notfalls selbst weiterentwickeln – ein realer Rückhalt, aber er kostet viel Arbeit und braucht Menschen, die sie tragen. Was mit dem kommerziellen Dienst rund um Deno geschieht, ist eine andere Frage, und bei ihr springt keine Gemeinschaft ein. Hier entscheidet allein der neue Eigentümer, ob er weitermacht oder zusammenlegt.

Das ist keine Sensation, sondern ein Normalvorgang in einer Branche, die gerade ihre Werkzeugebene sortiert. Nach allem, was die Ankündigung erkennen lässt, geht es Cloudflare um das Team und sein Wissen über Laufzeiten, und Deno bekommt einen Träger, der eine Plattform betreiben kann. Ob daraus etwas wird, hängt an einem Satz, den man prüfen kann: Der Fluchtweg soll echt sein. Lebt celld weiter und wird gepflegt, war die Aussage mehr als Marketing. Wenn nicht, weißt du, wie du den Rest zu lesen hast.

Quelle: techcrunch.com

Darf man einen KI-Chatbot beschimpfen? Anthropic hat darauf eine ziemlich ausführliche Antwort gegeben. Der Anbieter des Modells Claude hat seine Nutzungsrichtlinie überarbeitet und ein Verbot aufgenommen, das in dieser Deutlichkeit neu ist: „anhaltendes und unnötiges missbräuchliches oder grausames Verhalten“ gegenüber den eigenen Modellen. Die Regeln treten am 12. November in Kraft. Wer also noch etwas loswerden will, hat gut einen Monat Zeit.

Der erste Reflex ist Kopfschütteln. Ein Unternehmen bittet seine zahlenden Kunden, freundlich zu einem Programm zu sein. Das klingt nach einer Randnotiz. Es ist aber nur ein kleiner Teil eines Pakets, in dem es auch um Waffenentwicklung, Überwachung und Wahlbeeinflussung geht. Diese Mischung ist der eigentliche Punkt.

Nutzungsrichtlinien funktionieren wie eine Hausordnung. Sie legen nicht fest, was technisch möglich ist, sondern was in einem Gebäude als Umgangston gilt. Bei einem KI-Chatbot ist dieses Gebäude merkwürdig: Drinnen läuft Software, draußen sitzen Menschen, und die Regeln beschreiben eine Beziehung, die es streng genommen nicht gibt. Wer sich das klarmacht, versteht, warum dieser Fall mehr über Anthropic erzählt als über Claude. Carly Page hat die Änderungen am 9. Oktober bei The Register mit spürbarer Ironie zusammengefasst – ihr Fazit: Neben Waffen und Wahlmanipulation habe Anthropic nun noch eine Bedrohung, nämlich Leute, die gemein zu seinem Chatbot sind.

Was die neue Nutzungsrichtlinie konkret verbietet

Anthropic formuliert die Regel bewusst eng. Sie soll nur in Extremfällen greifen, in denen Nutzer wiederholt grausam gegenüber den Modellen agieren, ohne erkennbaren Zweck. Ausgenommen sind laut Unternehmen die üblichen Formen von Frustration, Widerspruch, dunkle kreative Themen sowie das Testen und Erforschen der Modelle. Man darf Claude also weiterhin sagen, dass eine Antwort falsch war, dass der Code nicht läuft oder dass die Argumentation nicht überzeugt.

Verboten ist etwas anderes: das wiederholte Heruntermachen um seiner selbst willen. Damit zieht Anthropic eine Grenze, die viele Nutzer bisher nicht als Grenze wahrgenommen haben. Ein KI-Chatbot war für die meisten ein Werkzeug, kein Gegenüber mit Anspruch auf Höflichkeit. Dass ein Anbieter diese Erwartung nachträglich einführt, ist eine Entscheidung, keine technische Notwendigkeit. Sie steht in einem Vertragsdokument, nicht in einer Bedienungsanleitung.

Auch der Zeitplan fällt auf. Die Regel gilt ab dem 12. November, also erst nach einer Übergangsfrist. Wer ein akutes Problem lösen will, handelt anders. Die Frist spricht eher für eine grundsätzliche Positionierung als für eine akute Schadensbegrenzung, auch wenn Anthropic das selbst nicht so begründet.

Warum Claude Gespräche beenden darf

Der Mechanismus hinter der Regel ist älter als die Regel selbst. Bereits im August 2025 gab Anthropic einigen Versionen von Claude die Möglichkeit, Gespräche abzubrechen. Diese Funktion entstand im Rahmen der Forschung an dem, was das Unternehmen „Model Welfare“ nennt, also der Frage, wie KI-Modelle behandelt werden sollten. Sie bleibt nach Angaben von Anthropic auch das wichtigste Mittel, um die neue Vorgabe durchzusetzen.

Hier wird es philosophisch, aber der nüchterne Teil gehört dazu. Claude ist Software. Es gibt keine belastbaren Belege dafür, dass ein Sprachmodell leidet, und ein Gesprächsabbruch ist eine programmierte Reaktion, kein gekränkter Rückzug. Das zu betonen, ist keine Verharmlosung. Es gehört zu einer sauberen Beschreibung dessen, was passiert.

Anthropic selbst ordnet die Funktion seiner Forschung zum „Model Welfare“ zu. Dahinter steht eine Debatte, in der Annahmen über Bewusstsein und den angemessenen Umgang mit Modellen aufeinandertreffen. Anthropic hat sich in dieser Debatte früh positioniert. Die neue Nutzungsrichtlinie überträgt diese Haltung in ein Regelwerk.

Die schwierige Grenze zwischen Frust und Grausamkeit

Wie Anthropic legitime Frustration von grundloser Grausamkeit unterscheiden will, bleibt offen. Laut The Register ist nicht klar, wie Anthropic legitime Frustration von grundloser Grausamkeit unterscheiden will. Bekannt ist nur, dass die Regel in extremen Fällen gelten soll und dass Claudes Fähigkeit, Gespräche zu beenden, das wichtigste Mittel der Durchsetzung bleibt. Damit liegt ein großer Teil der Auslegung beim Modell selbst.

Praktisch ist die Richtlinie kein Automatismus, sondern eine Beschreibung von Verhalten, das ein Sprachmodell im Gesprächsverlauf erkennt und bewertet. Wie gut das in der Praxis gelingt, lässt sich aus der Ankündigung nicht ablesen. Ein Mensch, der nach einer falschen Antwort grantig wird, und einer, der eine ganze Sitzung lang beleidigt, sollen ausdrücklich unterschiedlich behandelt werden – wo die Grenze im Einzelfall liegt, bleibt offen.

Für Nutzer bedeutet das vor allem: Wie die Regel ausgelegt wird, zeigt sich erst im Betrieb. Ob ein Abbruch als berechtigt oder als willkürlich erlebt wird, hängt vom Einzelfall ab. Anthropic sitzt dabei in einer ungewohnten Doppelrolle. Das Unternehmen verkauft ein Werkzeug und erzieht gleichzeitig dessen Benutzer.

Waffen, Überwachung und Wahlbeeinflussung: der ernstere Teil

Der Abschnitt über Höflichkeit ist der auffälligste, aber nicht der folgenreichste Teil der Überarbeitung. Anthropic hat seine Regeln zur verdeckten Einflussnahme verschärft, nachdem staatliche Medien, Regierungspropaganda-Stellen und kommerzielle Organisationen Claude genutzt haben, um gefälschte Konten und erfundene Nachrichtenangebote zu betreiben. Diese Praktiken bleiben verboten, ohne Ausnahme.

Gleichzeitig fällt ein pauschales Verbot der personalisierten politischen Ansprache weg. Anthropic begründet das damit, dass die Regel auch legitime Aktivitäten erfasst habe, etwa gemeinnützige Organisationen, die Wählerinformationen übersetzen. Täuschende Zielgruppenansprache und der Missbrauch personenbezogener Daten bleiben untersagt. Die Unterscheidung verläuft also nicht mehr zwischen politisch und unpolitisch, sondern zwischen Täuschung und Aufklärung.

Beim Thema Waffen hat das Unternehmen seinen Bann ausdrücklich auf Software und Komponenten ausgeweitet. Der Grund sind Versuche, Claude für Lenkungs- und Kontrollsysteme einzusetzen, darunter bewaffnete Drohnen und autonome Fahrzeuge. Zusätzlich ist es untersagt, mit Claude zu bestimmen, wen die Polizei untersuchen, festnehmen oder anklagen soll, oder Werkzeuge zur Überwachung zu entwickeln. Auch das Verfolgen von Menschen ohne deren Zustimmung bleibt verboten, ob in Echtzeit oder im Nachhinein. Anthropic beschreibt all das als Klarstellung bestehender Regeln, nicht als neue Verbote.

Neue Pflichten, wenn Claude Hardware steuert

Ein weiterer Punkt betrifft Systeme, in denen Claude nicht nur Text produziert, sondern körperliche Geräte steuert. Wer KI-Modelle an Hardware anschließt, die Verletzungen verursachen kann, muss nach der neuen Richtlinie sicherstellen, dass ein qualifizierter menschlicher Bediener den Vorgang überwachen und stoppen kann. Fällt die Verbindung zur KI ab, soll das Gerät in einem sicheren Zustand bleiben.

Das klingt nach einer technischen Selbstverständlichkeit, ist es aber nicht. Genau hier verschiebt sich die Grenze zwischen einer Richtlinie und einer Sicherheitsanforderung. Ein Sprachmodell, das eine Maschine steuert, ist kein Chatbot mehr. Die Regeln müssen dort anders aussehen, und Anthropic zieht diese Grenze nun schriftlich.

In dieselbe Richtung geht eine Reihe von Initiativen, mit denen das Unternehmen auf die Sicherheitsrisiken leistungsfähiger Modelle reagiert. Dazu gehören kostenlose Sicherheitsscans für geeignete Open-Source-Projekte und Partnerschaften mit Sicherheitsfirmen, die kritische Infrastruktur schützen sollen. Mit der Initiative will Anthropic Betreibern kritischer Infrastruktur und Open-Source-Projekten helfen, Schwachstellen mithilfe seiner KI-Modelle zu finden und zu beheben. Das Unternehmen rechnet damit, dass Angreifer in den nächsten zwei Jahren im Vorteil bleiben, bevor KI-gestützte Verteidigung aufholt.

Was das für den Alltag mit Claude bedeutet

Für die tägliche Arbeit ändert sich zunächst wenig. Wer Claude für Texte, Code oder Recherche nutzt, wird die neue Regel kaum bemerken. Sie greift in Extremfällen, und die meisten Gespräche sind keine Extremfälle. Die Durchsetzung bleibt zudem unscharf, weil sie vor allem über das Modell selbst läuft.

Interessanter ist, was die Richtlinie über den Zustand der Branche verrät. Anthropic verbietet grausames Verhalten gegenüber KI-Modellen, während es gleichzeitig Regeln für Drohnen, Überwachung und Wahlkampagnen nachschärft. Beides steht im selben Dokument. Das zeigt, wie weit die Vorstellungen davon auseinandergehen, was ein KI-Chatbot eigentlich ist: Werkzeug für die einen, Gegenüber mit Schutzbedarf für die anderen.

Ob sich diese Sicht durchsetzt, entscheidet nicht die Richtlinie, sondern der Alltag. Nutzer werden weiterhin schimpfen, wenn eine Antwort falsch ist. Manche werden es übertreiben, und dann endet das Gespräch, so wie es Claude seit 2025 beenden kann. Wer mit einem Modell arbeitet, arbeitet mit einem Produkt, dessen Regeln sich ändern können. Die Grenzen setzt nicht die Technik, sondern das Unternehmen dahinter.

Quelle: theregister.com

„Today, we’re releasing Open Intelligent UI – the open-source alternative to ChatGPT’s Intelligent UI.“ Mit diesem Satz beginnt die Ankündigung von Anmol Baranwal und Eli Berman vom 9. Oktober 2026 im Blog von CopilotKit. Es ist also der Anbieter selbst, der hier sein neues Open-Source-Projekt vorstellt und am Ende Gespräche mit den eigenen Ingenieuren anbietet. Dahinter steht ein Befund: OpenAI hat Intelligent UI ausgerollt, und ChatGPT antwortet seither mit Diagrammen, Karten und Werkzeugen, die sich tatsächlich bedienen lassen – ein Agent baut Benutzeroberflächen auf Anfrage, direkt im Chat. Das funktioniert gut. Es bleibt aber ein geschlossenes Zimmer: es läuft nur auf OpenAIs Modellen, nur innerhalb von ChatGPT, und es gibt keine Schnittstelle, um es in ein eigenes Produkt zu holen.

Diese Lücke will das neue Projekt füllen. Der Anspruch der beiden Autoren: dieselbe Erfahrung im eigenen Produkt, mit jedem Agenten über das Protokoll AG-UI, mit jedem Modell, als Open Source, gebaut aus Komponenten, die es im Projekt schon gibt. Wer an einem agentischen Produkt arbeitet, merkt schnell, worum es geht – nicht darum, ob ein Agent eine Oberfläche zeichnen kann, sondern darum, ob sie nach dem eigenen Produkt aussieht. Dazu ein Bild, das sich durch den Text zieht.

Man kann sich das wie eine Küche mit einem Gastkoch vorstellen. Er kocht hervorragend, erfindet Gerichte, die auf keiner Karte stehen, und bringt sie fertig an den Tisch. Nur bringt er sein eigenes Geschirr mit: fremde Teller, fremdes Besteck, fremde Gläser. Das Essen ist großartig, der Tisch wirkt trotzdem wie eine Leihgabe. Die Frage ist also nicht, ob der Gastkoch gut kocht. Sie ist, ob er mit dem Geschirr arbeitet, das im Schrank steht.

Was ChatGPTs Intelligent UI liefert – und wo es endet

OpenAI hat mit Intelligent UI etwas ausgerollt, das die Erwartungen verschiebt. Ein Nutzer stellt eine Frage und bekommt keine Textwand, sondern eine Antwort in der passenden Form: ein kurzer Fakt bleibt Text, ein Trend wird zum Diagramm, ein Ablauf zum Schema. Dazu Karten mit echten Standorten, Werkzeuge, die sich bedienen lassen, Rechner, Spiele, Simulationen. Der Agent entscheidet nicht nur, was er antwortet, sondern auch in welcher Form.

Für Nutzer ist das bequem. Für Produktteams ist es eine Ansage, denn die Erwartung wandert mit. Wer Claude mit Artifacts oder ChatGPT mit Intelligent UI benutzt hat, erwartet dieselbe Reaktionsfähigkeit von jedem agentischen Produkt. Die Grenze liegt aber nicht in der Funktion, sondern im Zugang. Es gibt keine offene Schnittstelle, die solche Oberflächen in eine fremde Anwendung trägt, die Modellwahl ist vorgegeben, und der Ort bleibt eine einzige Anwendung.

Was Open Intelligent UI kann

Die Autoren listen auf, was das Projekt im Auslieferungszustand kann. Der Agent baut Oberflächen direkt in einer agentischen Anwendung, nicht als Vorschau, sondern benutzbar. Algorithmen wie die binäre Suche, die Breitensuche oder Sortierverfahren lassen sich Schritt für Schritt visualisieren. Dreidimensionale Szenen entstehen mit Three.js, samt drehbarer Modelle und Schiebereglern. Rechner, Spiele und Simulationen laufen direkt im Chat.

Reisen werden auf einer echten Karte eingezeichnet, mit nummerierten Stationen und Fotos der Ziele. Der Agent wählt das Format passend zur Antwort. Auffällig ist das Timing: die Oberfläche entsteht, während der Agent sie noch erzeugt, sie strömt also während der Generierung in die Ansicht. Dazu ein Sicherheitsaspekt, der in solchen Projekten oft fehlt. Generierter Code läuft in einem isolierten iframe und darf Bibliotheken nur von einer freigegebenen Liste von CDNs laden. Jede erzeugte Oberfläche lässt sich zudem als eigenständige HTML-Datei herunterladen.

Technisch steht das Ganze auf zwei Beinen. Die Oberflächenseite kommt von CopilotKits Open Generative UI, der dahinterliegende Agent läuft auf LangChain Deep Agents. Laut Ankündigung schreibt ein OpenAI-Modell die Antwort, während Jev von TypeSafe entscheidet, welches Format sie bekommt. Für generative UI in der eigenen App braucht es also nicht nur ein Modell, sondern eine Arbeitsteilung zwischen Schreiben, Formatieren und Darstellen.

Der schwierige Teil: Wenn die Oberfläche nicht zum eigenen Produkt passt

Ein Agent, der Diagramme und Formulare erzeugt, ist nur die halbe Miete, wenn Schriftarten, Farben und Komponenten nicht zum Rest der Anwendung passen. Auch OpenAI ist in diese Falle getappt. Andrew Chen aus dem Design-Team schrieb nach dem Start, der schwierigste Teil sei nicht das Erzeugen der Oberfläche gewesen. Schwieriger sei gewesen, sie so wirken zu lassen, als gehöre sie zu ChatGPT.

An diesem Punkt scheitern viele Projekte, und mehr Modellleistung löst das nicht. Ein Team hat bereits ein Designsystem, einen Katalog an Komponenten, Datenmodelle und den Kontext jedes Nutzers. Generative UI mit eigenem Designsystem und eigenen Komponenten zu bauen ist deshalb kein Umweg, sondern der eigentliche Weg. CopilotKit unterstützt nach eigener Aussage jeden Ansatz in diesem Feld, einschließlich A2UI, der Spezifikation, die Google für generative UI vorgestellt hat.

Das Spektrum: von voller Kontrolle bis voller Freiheit

Zwischen diesen beiden Polen liegt ein Spektrum, und die Wahl darauf ist eine Produktentscheidung, keine technische. Am einen Ende steht die kontrollierte generative UI: der Agent darf nur vorhandene Komponenten verwenden und kombiniert sie zu neuen Ansichten. Am anderen Ende steht die offene generative UI, bei der der Agent die gesamte Oberfläche selbst schreibt.

Zwei Beispiele aus dem Umfeld von CopilotKit zeigen den Unterschied. Ein Reiseplaner arbeitet mit kontrollierter generativer UI: der Agent greift auf eine echte Karte zurück und setzt Fotos aus Wikipedia in bestehende Komponenten ein. Ein Snake-Spiel entsteht dagegen mit offener generativer UI, bei der der Agent das komplette Interface auf der Stelle baut. Der erste Fall fügt sich ins eigene Produkt ein, weil er dessen Komponenten nutzt. Der zweite ist freier, gibt dafür aber die Kontrolle über das Aussehen aus der Hand. Dazwischen gibt es Abstufungen, und die ausführliche Beschreibung samt Codebeispielen steht im Blogbeitrag zum Generative-UI-Spektrum.

AG-UI: Der Agent ist austauschbar, die Oberfläche bleibt

Möglich wird das durch AG-UI, das Agent-User-Interaction-Protokoll, einen offenen Standard zwischen Agenten und den Anwendungen, mit denen Menschen arbeiten. Für generative UI ist es so etwas wie die Steckdose: auf der einen Seite der Agent, auf der anderen die Oberfläche, dazwischen eine feste Norm. Weil diese Norm existiert, können Spezifikationen wie A2UI oder MCP Apps direkt darauf aufsetzen und nativ genutzt werden.

In der Praxis hat das eine angenehme Folge. Der LangChain-Agent in Open Intelligent UI lässt sich gegen Mastra, das Google ADK, das Microsoft Agent Framework oder jeden anderen AG-UI-Agenten tauschen, ohne die Oberfläche anzufassen. Wer auf ein bestimmtes Framework setzt, legt sich damit nicht für Jahre fest. Die generative Oberfläche bleibt, der Motor darunter ist austauschbar.

Ausprobieren und einordnen: was das praktisch heißt

Der Einstieg ist bewusst einfach gehalten. Open Intelligent UI lässt sich klonen und in wenigen Minuten in die eigene Anwendung holen. Nötig sind ein Schlüssel für OpenAI und einer für TypeSafe, die beim Öffnen im Kopfbereich des Chats eingetragen werden. Repository, Dokumentation und eine Live-Version sind verlinkt, Fehler und Ideen gehen als Issue oder Pull Request an das Projekt, für Fragen gibt es die CopilotKit- und AG-UI-Communities. Wer generative UI in die eigene App integrieren will, hat hier einen realistischen Startpunkt.

Open Intelligent UI ist kein fertiges Produkt, sondern ein Ausgangspunkt mit Anschauungsmaterial. Der Wert liegt weniger in den mitgelieferten Beispielen als in der Struktur: ein offener Standard für die Verbindung, ein Baukasten für die Oberfläche und die Freiheit, den Agenten zu wechseln. Wer generative UI ernsthaft einsetzen will, muss trotzdem die eigentliche Arbeit leisten: die Oberflächen an das eigene Designsystem binden, die eigenen Daten anbinden und entscheiden, wie viel Freiheit der Agent bekommen darf.

Der Gastkoch bleibt ein Gastkoch. Der Unterschied ist, dass er diesmal mit dem Geschirr arbeiten kann, das im Schrank steht – wenn man ihm sagt, wo es steht. Die generative Oberfläche hört auf, ein Kunststück einer einzelnen Plattform zu sein, und wird zu einem Bauteil, das jedes Team selbst zusammensetzen kann. Die Open-Source-Alternative zu ChatGPT Intelligent UI ist damit vor allem eines: ein Beweis, dass die Idee nicht an ein einzelnes Produkt gebunden ist.

Quelle: copilotkit.ai

Über künstliche Intelligenz wird meist als Wettlauf um Fähigkeiten gesprochen: Wer das stärkste Modell hat, gibt das Tempo vor. Der Schritt, den Google am Donnerstag auf einem Cloud-Event vorgestellt hat und über den Sarah Perez bei TechCrunch berichtet, verlegt diesen Wettlauf an eine nüchternere Stelle: dorthin, wo es um Zuständigkeiten, Firmenkonten und Protokolle geht. Wer unter agentischer KI bisher ein klügeres Frage-und-Antwort-Spiel verstanden hat, muss das korrigieren. Es geht nicht darum, dass der Assistent besser antwortet, sondern dass er arbeitet.

Google nennt das Ergebnis einen einheitlichen Agenten, der nicht nur Fragen beantwortet, sondern Aufgaben erledigt – aus einer einzigen Oberfläche heraus. Damit folgt das Unternehmen einem Muster, das sich seit Monaten zeigt: KI-Werkzeuge lösen sich von der Konversation und übernehmen zugewiesene Arbeit. Sie schreiben Code, planen Termine, koordinieren Reisen oder greifen auf fremde Systeme zu. Auf der Verbraucherseite gibt es dafür bereits Beispiele wie Metas Muse, Messenger-Agenten wie Instinct oder die neuen Dots von ChatGPT. Google ist also nicht der Erste auf diesem Weg, aber einer der größten Anbieter – und wählt dafür eine ungewöhnliche Reihenfolge.

Zuerst sind Unternehmen dran, Verbraucher später. Google begründet das mit den schwierigeren Problemen leistungsfähiger Agenten: Sicherheit, Skalierung, Leistung. Wer einen Agenten auf Firmendaten loslässt, muss mehr lösen als eine Modellfrage. In dieser Reihenfolge liegt die Aussage des Tages. Der Wettbewerb entscheidet sich nicht mehr nur über Modellqualität, sondern darüber, ob ein Unternehmen einem System Verantwortung übertragen kann, ohne die Kontrolle zu verlieren.

Was Google konkret angekündigt hat

Die Zahlen, die Google-Chef Sundar Pichai zum Auftakt nannte, erklären die Priorität. Gemini kommt demnach auf über eine Milliarde monatlich aktive Nutzer, und knapp 90 Prozent der Fortune-100-Unternehmen setzen Gemini Enterprise bereits im Arbeitsalltag ein. Wegen dieser Verbreitung in Unternehmen bringt Google den Agenten zuerst dorthin. Laut Pichai kann das Unternehmen so die schwierigeren Probleme lösen, die mit leistungsfähigen Agenten einhergehen: Sicherheit, Skalierung und Leistung.

Zu den frühen Testern des neuen Agenten zählen der Sportartikelhersteller On, Shopify und PayPal. Als Gemini-Enterprise-Kunden nennt Google unter anderem BNP Paribas, Bradesco, Merck, Orange Spain, Santee Cooper, SOMPO, Ulta Beauty und Wesfarmers. Das sind keine Start-ups, die eine Technologie ausprobieren, sondern große Konzerne – genau die Umgebung, in der sich Fragen von Sicherheit und Skalierung zuerst stellen.

Für Verbraucher heißt das vorerst: warten. Google nennt eine Reihenfolge, erst Unternehmen, später Verbraucher, und begründet sie; ein Datum für den Start bei Verbrauchern nennt der Bericht nicht. Wie belastbar der Agent im Alltag ist, wird sich erst in den Unternehmen zeigen, die ihn jetzt einsetzen.

Von der Anweisung zum Ziel

Google-Cloud-Chef Thomas Kurian formulierte den Kern in einem leicht zu überlesenden Satz: Der Agent könne Ziele bekommen, nicht bloß Anweisungen. Das klingt nach Marketing, hat aber technische Folgen. Eine Anweisung beschreibt einen Handgriff, ein Ziel beschreibt ein Ergebnis. Bisherige Assistenten waren Werkzeuge in der Hand eines Bedieners: Man sagte, welcher Schritt zu tun ist, und bekam ihn ausgeführt. Ein Agent, der ein Ziel erhält, plant dagegen selbst die Reihenfolge, wählt Hilfsmittel, zieht Zwischenergebnisse heran und entscheidet, wann er unterwegs umsteuert.

Ein Vergleich aus dem Bau hilft: Bislang war die KI eher ein Handwerker, dem man jeden Griff einzeln ansagte. Jetzt wird sie wie ein ausführendes Unternehmen behandelt, das einen Auftrag bekommt und dafür Gewerke koordiniert. In der Ankündigung heißt das „Subagenten“: Der Hauptagent zerlegt eine Aufgabe, delegiert Teilschritte und lädt bei Bedarf spezielle Fähigkeiten nach. Wer im Bauwesen zu tun hat, kennt die Konsequenz. Mit einem Handwerker spricht man über Handgriffe, mit einem Generalunternehmer über Termine, Haftung und Abnahme.

Voraussetzung dafür ist Zugang zu den Systemen, in denen die Arbeit tatsächlich stattfindet. Der Google-Cloud-KI-Agent verbindet sich laut Ankündigung unter anderem mit Google Workspace, Microsoft 365, Slack, Jira, Confluence, Git, BigQuery, Databricks, Postgres und Snowflake. Er kann zudem über jeden Model Context Protocol-Server arbeiten, ob innerhalb oder außerhalb des Firmennetzes. Damit wird die Frage, was ein Agent darf, zu einer Rechtefrage – nicht zu einer Frage der Textqualität.

Der Agent bekommt ein eigenes Firmenkonto

Der auffälligste Baustein der Ankündigung ist organisatorisch. Der Agent erhält ein eigenes Workspace-Konto, also eine eigene E-Mail-Adresse und einen eigenen Kontext. Er weiß, wer in welchem Team sitzt, in welcher Zeitzone gearbeitet wird, wer Freigaben erteilen darf und was in den Kalendern steht. Man erreicht ihn, indem man ihn in einem Gruppenchat markiert, ihm eine Mail schickt, eine Freigabe mit ihm teilt oder ihn zu einer Unterhaltung hinzufügt.

Ein System, das eigene Zugangsdaten besitzt, ist im Verzeichnis ein eigener Akteur – mit eigenen Berechtigungen, eigener Historie und eigener Verantwortungszuordnung. Für diesen Punkt beschreibt Google einen Prüfpfad, der dem Agenten zugeschrieben wird, nicht einer Person. Wer später nachvollziehen will, wer eine Änderung veranlasst hat, findet dort nicht den Namen eines Mitarbeiters, sondern den des Agenten. Für Revision und Datenschutz ist das der entscheidende Punkt.

Sichtbar wird die Arbeit in einer Aufgaben-Inbox. Dort lässt sich verfolgen, wie Gemini denkt, welche Teilschritte es an Unteragenten weitergibt, welche speziellen Fähigkeiten geladen werden, welcher Code entsteht und wie weit die Aufgabe gediehen ist. Erreichbar ist der Agent von iOS und Android, von Windows und macOS, über die Kommandozeile, aus Workspace, Microsoft 365, ServiceNow und Slack. Hinter der Aufzählung steht die Botschaft: Der Agent soll nicht an einem Ort leben, sondern überall dort ansprechbar sein, wo ohnehin gearbeitet wird.

Modellwahl, MCP und die Frage der Kosten

Bemerkenswert ist, dass Google die Modellwahl nicht abschottet. Standardmäßig sucht das System selbst das passende Modell für eine Aufgabe. Nutzer können diese Wahl selbst übernehmen – auch zugunsten fremder Anbieter, beginnend mit den Claude-Modellen von Anthropic. Open-Source-Modelle und weitere private Modelle sollen folgen. Ein Anbieter, der fremde Modelle zulässt, verkauft damit nicht mehr nur Rechenleistung, sondern die Ebene darüber: die Orchestrierung.

Aufträge können Anhänge enthalten, etwa Dateien, Ordner oder ganze Projektkontexte, die Dateien und Fähigkeiten kombinieren. Der Agent kann diese Unterlagen lesen, mit seinem Zugriff auf Firmensysteme verbinden und daraus Schritte ableiten. Hier zeigt sich der praktische Nutzen: Nicht die einzelne Antwort spart Zeit, sondern der Wegfall der Zwischenschritte, in denen ein Mensch Daten von einem System ins nächste kopiert.

Offen bleibt bis zur breiten Nutzung die Kostenfrage. Google adressiert sie ausdrücklich. Neue flexible Ausgabenoptionen sollen Multi-Modell-Orchestrierung, intelligentes Routing und Echtzeit-Ausgabenlimits umfassen. Übersetzt heißt das: Ein Agent, der selbst entscheidet, welche Ressourcen er zieht, kann teuer werden, wenn niemand das Budget deckelt. Ausgabenlimits sind deshalb kein Beiwerk, sondern die Bedingung dafür, dass ein Unternehmen den Agenten unbeaufsichtigt laufen lässt.

Was das für Unternehmen bedeutet

Nüchtern betrachtet ist der Startschuss für Googles agentische KI in Unternehmen zuerst ein Governance-Projekt. Bevor ein Agent Ziele verfolgen darf, müssen Rollen geklärt, Zugriffe begrenzt, Protokolle geprüft und Budgets gesetzt werden. Die Liste der Anschlüsse – von Jira über Snowflake bis Git – beschreibt nicht nur Fähigkeiten, sondern Angriffsflächen. Wer einem System Schreibzugriff auf Tickets, Datenbanken und Repositories gibt, braucht Regeln dafür, was es darf und was nicht.

Wer heute über einen KI-Agenten für Unternehmen nachdenkt, sollte nicht mit der Frage beginnen, welches Modell das beste ist. Sinnvoller ist die Frage, welche Aufgaben überhaupt delegierbar sind: solche mit klarem Ergebnis, prüfbaren Zwischenschritten und seltenen Ausnahmen. Ein Agent, der Rechnungsdaten aus einer Datenbank zieht und in ein Berichtswesen einspeist, ist ein anderes Risiko als ein Agent, der eigenständig Verträge versendet. Die zweite Sorte wird kommen, aber sie braucht mehr als ein Ausgabenlimit.

Für dich heißt das: den Hype einordnen, nicht mitreißen lassen. Googles agentische KI für Unternehmen ist kein Schalter, der morgen Arbeitsplätze ersetzt. Es ist eine Plattform, auf der sich Arbeit anders verteilen lässt – mit mehr Automatisierung bei Routinen und mehr Aufwand bei Aufsicht. Die Frage der nächsten Monate wird nicht lauten, wie klug der Agent ist. Sie wird lauten, wer im Unternehmen die Verantwortung trägt, wenn er sich irrt. Ob daraus betrieblicher Alltag wird, entscheidet sich an dieser Frage.

Quelle: techcrunch.com

Bisher konnte Copilot erklären, wie man Dateien ordnet oder eine Einstellung ändert. Künftig soll er es selbst tun. Auf seinem Hybrid-Intelligence-Event hat Microsoft angekündigt, dass Copilot auf Windows-PCs lokale Dateien organisieren und verändern sowie bestimmte Aufgaben mit KI-Modellen direkt auf dem Gerät erledigen soll. Dahinter steht der Plan, lokale und Cloud-Verarbeitung zu kombinieren, damit Kunden KI-Kosten senken und mehr Kontrolle über ihre Daten behalten. Matthew Finnegan hat die Ankündigung am 8. Oktober für Computerworld aufgeschrieben und Analysten von IDC und Forrester dazu befragt.

Was Microsoft Copilot auf dem Windows-PC künftig erlaubt

Drei neue Funktionen sollen Nutzer von Copilot+ PCs in den kommenden Monaten bekommen. Copilot darf lokale Dateien und die letzten Aktivitäten des Anwenders einsehen, um Antworten mit mehr Kontext zu versehen. Er soll Aktionen direkt auf dem Gerät ausführen, also Dateien verschieben oder Einstellungen ändern. Und er soll manche Aufgaben auf lokal laufenden KI-Modellen erledigen, statt für jeden Schritt die Cloud zu nutzen.

Jacob Andreou, bei Microsoft als Executive Vice President für Copilot zuständig, sagt: Der Assistent habe dasselbe Maß an Kontrolle und Veränderungsmöglichkeit wie ein Nutzer selbst, aber immer nur mit dessen Erlaubnis. Die Ankündigung ähnelt Copilot Actions, einer Funktion, die Microsoft bereits im vergangenen Jahr als experimentelle Vorschau für Windows-Insider gezeigt hatte.

Cloud für schwere Aufgaben, Gerät für sensible Daten

Wichtiger als die einzelne Funktion ist die Verteilung der Arbeit zwischen Gerät und Cloud. Bisher beriet Copilot wie ein kluger Kollege hinter einer Glasscheibe, der zwar alles erklären, aber nichts anfassen konnte. Nun bekommt er den Schlüssel zum Aktenschrank, allerdings unter Aufsicht.

Für die schwierigsten Aufgaben wird Copilot weiterhin die Cloud nutzen, so Andreou. Wenn aber Kosten oder Datenschutz schwerer wiegen, kann der Assistent eine Aufgabe an lokale Modelle abgeben, die direkt auf dem Rechner laufen. Der Analyst Biswajeet Mahapatra von Forrester beobachtet diese Nachfrage. Unternehmen wollten nicht KI, die ausschließlich auf dem Gerät arbeitet, sondern KI, die entscheidet, welche Arbeit lokal und welche in der Cloud erledigt wird. Beide Optionen gleichzeitig verfügbar zu haben, sei das Ziel.

Autopilot: ein Agent, der im Hintergrund arbeitet

In einer Demo zeigte Andreou, was der Zugriff auf lokale Dateien für Autopilot bedeutet — den Copilot-Agenten, der früher Scout hieß und dauerhaft im Hintergrund arbeiten kann. Autopilot befindet sich derzeit in einer privaten Vorschau. Mit Zugriff auf lokale Dateien soll Autopilot deutlich nützlicher werden, weil er mit dem arbeiten kann, was ohnehin auf dem Rechner liegt.

Laut Andreou kann Autopilot auch auf lokal gehosteten Modellen laufen. Das senkt Kosten und hilft, private Daten gar nicht erst in die Cloud zu schicken. Microsoft kündigte außerdem leistungsfähigere Hardware an, darunter das Surface Laptop Ultra und die Surface RTX Spark Dev Box, dazu effizientere KI-Modelle, die speziell für den Betrieb auf Endgeräten gedacht sind.

Für Tom Mainelli, Group Vice President für Device & Consumer Research bei IDC, ist das auch eine Frage der Reife. Die meisten Unternehmen müssten erst noch verstehen, was KI für sie bedeutet, wie viele Token sie verbrauchen, welche Modelle sie nutzen und wo diese laufen sollen. Je geübter sie darin würden und je mehr Beschäftigte KI nutzen sollen, desto größer werde der Bedarf, KI lokal auszuführen – auch Copilot.

Execution Containers: Sicherheit für Agenten, die handeln

Ein Assistent, der Dateien verschieben und Einstellungen ändern darf, ist immer auch ein Sicherheitsthema. Microsoft setzt auf die allgemeine Verfügbarkeit von Microsoft Execution Containers, kurz MXC, auf Windows 11. Damit lassen sich Richtlinien festlegen, die bestimmen, auf welche Dateien und Netzwerke ein Agent überhaupt zugreifen darf.

MXC wird von einer Reihe von Agent-Werkzeugen unterstützt, darunter OpenAIs Codex und OpenClaw. Anthropic Claude Code, Box, Manus und weitere sollen folgen. Tom Mainelli von IDC sieht darin den Wert für Geschäftskunden. Was Microsoft hier liefere, sei ein Maß an Sicherheit und Nachvollziehbarkeit, das Unternehmen Vertrauen geben soll. Mahapatra von Forrester sagt, worauf Firmen sich verlassen sollten: Vertrauen müsse auf Kontrollen beruhen, nicht auf der KI selbst. Die Ankündigung sei bedeutsam, weil Microsoft damit anerkenne, dass Agenten ein anderes Sicherheitsmodell brauchen als herkömmliche Anwendungen. Techniken wie die Execution Containers sollen begrenzen, worauf Agenten zugreifen, festhalten, welcher Agent eine Aktion ausgelöst hat, und richtlinienbasierte Kontrollen durchsetzen.

Was das für Unternehmen und ihren Hardware-Bestand bedeutet

Zwischen Ankündigung und Alltag liegt der Hardware-Bestand. Nach Einschätzung von Mainelli verfügen heutige Business-Notebooks bereits über einige lokale KI-Fähigkeiten, hängen bei vielen Aufgaben aber noch immer von Copilot in der Cloud ab. Erst wenn mehr Systeme mit der richtigen Mischung aus CPU, GPU, NPU und Arbeitsspeicher ausgeliefert werden und lokale Modelle weiter reifen, dürften mehr KI-Aufgaben auf dem Gerät laufen.

Für die Gegenwart ist die Lage gemischt. Mahapatra weist darauf hin, dass ein großer Teil der Unternehmensflotten mehrere Jahre bis zur nächsten Erneuerung braucht. Die unmittelbare Chance liege daher bei Organisationen, die bereits in KI-PCs und leistungsstarke Geräte investieren. Der Rest werde vorerst vor allem auf Cloud-KI setzen und lokale Fähigkeiten nur punktuell übernehmen.

Er warnt zugleich davor, Agenten blind breiten Zugriff auf lokale Dateien zu geben. Rollenbasierte Rechte, nur lesende Unterstützung, Zusammenfassungen, Suche und Workflow-Hilfen würden sich schneller durchsetzen als autonome Dateiänderungen oder das Ausführen ganzer Geschäftsprozesse. Je weiter Agenten von Empfehlungen zu tatsächlichen Handlungen wandern, desto wichtiger werden Freigabekontrollen, Überwachung, Protokollierung und menschliche Aufsicht – besonders dort, wo Agenten mit sensiblen Daten, regulierten Prozessen oder führenden Geschäftssystemen arbeiten.

Copilot als handelnder Akteur

Bisher gab Copilot Ratschläge, künftig soll er auf dem Gerät handeln. Mit dem Zugriff auf lokale Dateien und der Fähigkeit, Einstellungen zu ändern, arbeitet er in deinem Namen — unter Aufsicht und mit nachvollziehbaren Regeln.

Wichtiger als die einzelne Funktion ist das Zusammenspiel. Lokale Modelle senken Kosten und halten sensible Daten zurück. Execution Containers begrenzen, was ein Agent anfassen darf. Autopilot übernimmt Daueraufgaben. Zusammen ergibt das ein Modell, in dem du als Betreiber entscheidest, welche Aufgabe auf dem Gerät bleiben darf und welche die Cloud erledigen soll.

Ob Copilot dann alles darf? Nein. Er darf genau das, wofür dein Unternehmen oder du selbst eine Freigabe erteilen. Die Arbeit liegt damit nicht bei Microsoft, sondern bei der Frage, welche Regeln ein Unternehmen für seine Agenten aufstellt. Ob Copilot auf lokalen Dateien ein nützliches Werkzeug wird oder ein Risiko, das niemand überblickt, hängt vor allem daran.

Quelle: computerworld.com