Kategorie: KI-News

Ein Eintrag in der robots.txt wird ausgeliefert, von einem Crawler gelesen und dann befolgt oder ignoriert. Cloudflare hat eine neue Einstellung angekündigt: Disallow AI Training. Sie soll zwei Entscheidungen trennen, die bisher zusammengehörten.

Der Konflikt begleitet Website-Betreiber, seit große Sprachmodelle auf dem Markt sind. Wer seine Inhalte für das Training von KI-Modellen sperrt, sperrt oft auch die Suchmaschinen aus, weil beide Zwecke meist derselbe Crawler bedient. Ein Bote trägt zwei Aufträge in einer Tasche: Er bringt deine Seite in den Suchindex und kopiert sie zugleich in einen Trainingsdatensatz. Weist du ihn an der Tür ab, verschwindet beides. Diese Kopplung ist das Problem.

Cloudflare nennt diese Bauart Mixed-Use-Crawler. Das Unternehmen betreibt selbst ein großes Netzwerk und sieht von dort aus, wer wann welche Seite abruft. Daraus entsteht eine Klassifikation nach Verhalten statt nach Namen. Die veröffentlichten Zahlen: Weniger als ein Prozent der über Cloudflare laufenden Seiten sperrt Suchmaschinen-Bots aus, rund 17 Prozent haben irgendeinen Mechanismus aktiviert, um Training zu blockieren. Gefunden werden wollen also fast alle. Als Trainingsmaterial dienen wollen die wenigsten.

Warum robots.txt allein nicht reicht

Eine robots.txt kann jeder veröffentlichen, und sie bleibt ein wichtiger Baustein. Sie kann aber nicht feststellen, wer tatsächlich crawlt oder zu welchem Zweck, und einen Crawler, der die Datei ignoriert, hält sie nicht auf. Hier endet der Standard. Ein Netzwerk kann mehr, weil es den Datenverkehr sieht, bevor er den Ursprungsserver erreicht: Es veröffentlicht die Präferenz, identifiziert den Absender, ordnet das Verhalten ein und blockiert, wer sich nicht daran hält. Cloudflare zeigt auf seinem Radar-Dashboard, wie sich die einzelnen Anbieter verhalten.

Blockieren ist nur die halbe Antwort. Wer einen Crawler sperrt, entfernt ihn, ändert aber nicht, wie er sich verhält. Cloudflare hält das bessere Ergebnis für Anbieter, die ihren Nutzern die Wahl gar nicht erst aufzwingen. Seit Juli 2026 hat das Unternehmen nach eigener Darstellung mit den Betreibern der großen Crawler gesprochen. Die Reaktion sei ermutigend gewesen: Nahezu alle hätten zugestimmt, dass Website-Betreiber Kontrolle und Transparenz darüber haben sollten, wie ihre Inhalte verwendet werden.

Die Kategorie Accountable und ihre vier Bedingungen

Aus diesen Gesprächen entstand eine Kategorie, die Cloudflare Accountable nennt. Sie zeichnet Anbieter aus, die die nötigen Funktionen schon bieten oder sich verbindlich mit Zeitplan dazu verpflichtet haben. Die Anforderungen: Erstens ein Mechanismus, mit dem Betreiber das Training von KI-Modellen über robots.txt oder einen vergleichbaren Standard abwählen können. Zweitens ein Weg, KI-Zusammenfassungen abzulehnen, heute direkt beim Anbieter, 2027 auch über Cloudflare. Drittens Einblick auf URL-Ebene, welche Seiten für Training bereitgestellt wurden, samt Kennzahlen zur Sichtbarkeit in der Suche. Viertens die Zusicherung, dass ein Widerspruch gegen Training die klassischen Suchergebnisse nicht verschlechtert.

Apple, Google und Microsoft erfüllen diese Kriterien nach Einschätzung von Cloudflare. Alle drei kombinieren vorhandene Funktionen mit befristeten Zusagen für das, was noch in Entwicklung ist. Auch Amazon, Anthropic, Meta und OpenAI fallen in die Kategorie, weil sie Such- und Trainingscrawler trennen. Ein Trainingscrawler lässt sich damit blockieren, ohne die Suche zu beeinträchtigen. Technisch ist das wenig spektakulär, praktisch der entscheidende Unterschied.

Die vier Einstellungen und was Disallow AI Training bewirkt

Cloudflare klassifiziert Bots nach Verhalten, und ein einzelner Bot kann mehrere Verhaltensweisen zeigen. Drei Kategorien stehen zur Steuerung bereit: Search für den Aufbau eines Suchindex, Training für das Trainieren oder Feintunen eines Modells und Agent für nutzergesteuerte Programme, die im Auftrag eines Menschen eine Seite abrufen, etwa Chat-Fetch-Bots oder Browser-Agenten. Ein Mixed-Use-Crawler bedient demnach Search und Training zugleich, also genau die Bauart, die die Zwangslage erzeugt.

Die neue Einstellung bietet vier Optionen, die auf Domänenebene greifen. Allow lässt alle Crawler zu, sofern keine andere Regel oder eine WAF-Regel eingreift. Disallow AI Training, benannt nach der Disallow-Direktive, die sie in der robots.txt veröffentlicht, veröffentlicht die No-Training-Präferenz über die Bot Preference Sync. Accountable Mixed-Use-Crawler bleiben für die Suche zugelassen, alle übrigen Trainingscrawler werden blockiert, darunter die reinen Trainingscrawler von Amazon, Anthropic, Meta und OpenAI. Deren Sperrung berührt die Sichtbarkeit in Suchmaschinen nicht. Block on pages with ads sperrt Crawler nur auf Seiten, auf denen Werbung erkannt wurde. Block untersagt allen Crawlern den Zugriff, gemischte eingeschlossen.

Eine Variante fehlt bewusst: Es gibt kein Disallow AI Training speziell für Seiten mit Werbung. Der Grund ist technisch. Eine solche Präferenz ließe sich in einer robots.txt nicht ausdrücken, weil Cloudflare zwar erkennt, welche Seiten Anzeigen ausliefern, die Liste aber zu groß und zu kurzlebig ist, um sie dort zu hinterlegen. Für Agenten gibt es ebenfalls keine eigene Disallow-Option, weil ihr Abruf nicht dieselbe Abwägung erzeugt und ein etablierter Standard für solche Präferenzen fehlt. Cloudflare will das Thema erneut aufgreifen, sobald sich Formate wie ai-prefs durchgesetzt haben.

Was sich am 15. September 2026 ändert

Zum Stichtag ändert sich vor allem die Bedeutung der alten Schalter. Block und Block on pages with ads galten bisher nicht für Mixed-Use-Crawler, weil ein Block auch die Auffindbarkeit in Suchmaschinen beschädigt hätte. Künftig erfassen beide alle Trainingscrawler einschließlich der gemischten, also auch Applebot, Bingbot und Googlebot. Wer Training unterbinden und die Suche behalten will, muss Disallow AI Training wählen. Die Sammeloption Block AI Bots wird zugunsten der drei Verhaltenssteuerungen Search, Training und Agent aufgegeben, Managed Robots.txt weicht der Bot Preference Sync. Bestehende Konfigurationen werden automatisch übernommen.

Bei Domains, die nie mit den detaillierten Steuerungen gearbeitet haben, richtet sich die Migration nach der alten Block-AI-Einstellung. War sie deaktiviert, stehen künftig alle drei Bereiche auf Allow. War sie aktiv oder auf werbeführende Seiten beschränkt, bleibt Search auf Allow, Training wandert auf Disallow AI Training und Agent auf Block on pages with ads. Bei Domains, die bereits granular konfiguriert waren, bleibt der Effekt der bisherigen Auswahl erhalten: Eine frühere Trainingssperre wird zu Disallow AI Training. Für neue Domains bietet Cloudflare ab dem Stichtag zwei Voreinstellungen an, abhängig davon, ob die Seite mit Werbung Geld verdient. Werbefinanzierte Seiten erhalten die restriktivere Variante, weil ein Training den Besuch durch eine Antwort ersetzt und ein Agent die Seite abruft, ohne dass jemand die Anzeigen sieht. Ändern lässt sich beides jederzeit.

Applebot, Googlebot und Bingbot: der aktuelle Stand

Applebot erlaubt es, Training über eine Disallow-Regel für Applebot-Extended in der robots.txt abzuwählen. Präferenzen für KI-Zusammenfassungen lassen sich derzeit über die nosnippet-Direktive im HTML ausdrücken, Inhalte hinter einer Bezahlschranke entsprechend kennzeichnen. Ein Werkzeug zur Prüfung auf URL-Ebene fehlt noch; Apple hat laut Cloudflare Details zu einer Lösung für 2027 geteilt.

Googlebot bietet denselben Weg über Google-Extended und zusätzlich einen Schalter im Webmaster-Portal, um Inhalte aus generativen Suchergebnissen herauszuhalten, samt Berichten zu Suchergebnissen und Zusammenfassungen. Werkzeuge für mehr Transparenz auf URL-Ebene sollen in den Wochen nach der Ankündigung vom 15. September 2026 starten. Bingbot stellt granulare Steuerungen in den Webmaster Tools bereit; heute läuft die Trainingspräferenz über das NOARCHIVE-Meta-Tag, während Microsoft an einer robots.txt-Lösung arbeitet, die für Anfang 2027 anvisiert ist. Bis dahin bleibt die Funktion zum Blockieren von URLs oder zum Entfernen von Inhalten als Ausweg. Alle drei Anbieter versichern, dass ein Widerspruch gegen Training den Suchrang nicht beeinträchtigt.

KI-Zusammenfassungen

Der nächste Schritt betrifft die KI-Zusammenfassungen. Ein pauschales Ja oder Nein für die gesamte Website wäre nach Einschätzung von Cloudflare zu grob, weil ebenso viel daran hängt, wie viel eines Inhalts in einer Zusammenfassung erscheint, wie daran, ob überhaupt etwas erscheint. Ein Opt-out für Zusammenfassungen gehört bereits zu den Anforderungen an Accountable-Anbieter. Bis Anfang 2027 will Cloudflare eine Steuerung anbieten, mit der sich festlegen lässt, wie viel des eigenen Inhalts einfließen darf, einmal im Dashboard gesetzt statt bei jedem Anbieter einzeln.

Was heißt das konkret? Wer eine Website betreibt, für die Suchmaschinen-Sichtbarkeit trotz KI-Training wichtig ist, bekommt erstmals eine saubere Trennung zwischen zwei Dingen, die lange als eines galten. Du kannst KI-Training blockieren und trotzdem im Index bleiben, du musst nicht mehr zwischen Reichweite und Kontrolle wählen. Die Kehrseite: Ein Block tut nun tatsächlich, was er verspricht. Wer bislang Block wählte und annahm, gemischte Crawler seien ausgenommen, sperrt ab dem 15. September auch Applebot, Bingbot und Googlebot aus, Suche inklusive. Sieh dir deine Konfiguration vor diesem Datum an, statt dich allein auf die automatische Migration zu verlassen. Und es bleibt eine Frage der Durchsetzung: Eine Präferenz in der robots.txt ist zunächst nur eine Bitte, die erst durch die Infrastruktur eines Netzwerks und die Zusage der Anbieter Gewicht bekommt. Die neue Einstellung ist kein Zaun, sondern eine Anweisung an der Tür. Der Bote trägt weiterhin zwei Aufträge in einer Tasche, doch du kannst ihm jetzt sagen, welchen davon er ausführen darf.

Quelle: blog.cloudflare.com

Eine Meldung von MacRumors vom 14. September 2026 kam binnen weniger Tage auf mehr als 80 Kommentare. Grundlage war eine einzelne Code-Analyse. In iOS 27 und macOS Golden Gate fanden sich private Frameworks, die darauf hindeuten, dass Apple seine neue Siri-Architektur von Anfang an für fremde KI-Modelle ausgelegt hat.

Der Code-Sleuth pdfu hat die Stellen in einem Video auf X dokumentiert. Die Fundstellen verschieben die Grenze zwischen fester Systemfunktion und austauschbarer Zutat. Was dort technisch passiert, was davon schon funktioniert und wo Fragen offen bleiben – darum geht es im Folgenden.

Zwei Protokolle mit unterschiedlicher Reichweite

Der Fund umfasst zwei Mechanismen mit sehr unterschiedlicher Tragweite. Der erste heißt Model Delegation und bindet ein fremdes Modell als Erweiterung in Siri ein, nach demselben Muster, das Apple schon für die eingebaute ChatGPT-Erweiterung nutzt. Das zweite Protokoll geht weiter: Ein Inference Provider in den „Model Manager Services“ kann Apples serverseitiges Siri-Modell komplett ersetzen, im dokumentierten Beispiel durch GPT-5.6.

Stellen wir uns Siri als Kellner vor. Er nimmt die Bestellung auf, kennt den Tisch, weiß, wer was wollte, und trägt am Ende das Essen aus. Die Küche dahinter ist kein fester Teil des Hauses, sondern ein Dienstleister, den man wechseln kann. Bei der Model Delegation holt Siri nur für eine einzelne Aufgabe einen Spezialisten an den Tisch, behält aber Bedienung, Besteck und Rechnung in der Hand. Beim zweiten Protokoll tauscht Apple die Küche komplett aus, der Gastraum bleibt gleich.

Die Unterscheidung beschreibt zwei völlig verschiedene Arten von Abhängigkeit. Im ersten Fall bleibt Siri die Schaltzentrale und reicht nur Teilaufgaben weiter. Im zweiten übernimmt ein fremdes Modell die eigentliche Denkarbeit, inklusive der Frage, welche Systemwerkzeuge überhaupt gebraucht werden. Damit wird aus einer Funktion eine Architekturentscheidung.

So läuft die Siri-Claude-Integration im gezeigten Beispiel ab

In dem Video von pdfu öffnet der Nutzer unter macOS die „Search or Ask“-Leiste und wählt über ein Kontextmenü namens „Ask…“ ein KI-Modell aus. Nach dem Aktivieren der Claude-Erweiterung bittet er Siri, Claude zu fragen, ob dieser eine Erinnerung in Apples Reminders-App anlegen kann. Claude versteht die Anfrage, Siri legt die Erinnerung tatsächlich an.

Entscheidend ist die Rückgabe. Sobald eine Anfrage Zugriff auf eine Systemfunktion von Apple braucht, gibt Claude die Aufgabe offenbar an Siri zurück. Das fremde Modell darf formulieren und verstehen, aber nicht selbst ins System greifen. Wer Siri gegen Claude tauschen will, bekommt also keine zweite Systemstimme, sondern einen zusätzlichen Gesprächspartner innerhalb der bestehenden Oberfläche.

Im zweiten Beispiel bekommt Claude in einem Konversationsfenster der Siri-App die Aufgabe, eine CSV-Datei zu erzeugen. Das kann Siri allein nicht, und hier zeigt sich der praktische Nutzen: Das fremde Modell liefert das Ergebnis, Siri den Rahmen. Ob sich so eine Verbindung dauerhaft wie ein eigenständiger Assistent anfühlt oder wie ein Werkzeug in einer Werkzeugkiste, hängt davon ab, wie sauber Apple diese Übergaben später gestaltet.

Der tiefere Eingriff: Wenn ChatGPT Apples Siri-Planer ersetzt

Interessanter ist das zweite Protokoll aus derselben Analyse. Ein Inference Provider in den „Model Manager Services“ erlaubt es offenbar, Apples eigenes serverseitiges Siri-Modell durch ein fremdes zu ersetzen. In diesem Szenario bekommt ChatGPT den Planer-Prompt von Siri samt Definition der verfügbaren Werkzeuge. Es kann also selbst Systemaktionen anfordern, die zurückgelieferten persönlichen Daten entgegennehmen und daraus eine Antwort formulieren, die Siri anschließend mit eigener Oberfläche und eigener Stimme präsentiert.

Im Video bittet der Nutzer das ChatGPT-Modell in der Siri-App, E-Mails zu einem Thema zu finden, Inhalt und Handlungspunkte zusammenzufassen und danach über die Nachrichten-App eine Nachricht an eine Person aus den Kontakten zu senden. Die Antwort erscheint danach in der Web-Oberfläche von OpenAI als protokollierte Anfrage. Der Vorgang läuft also nicht nur lokal zwischen zwei Apple-Komponenten ab.

Für dieses zweite Protokoll heißt das: Die persönliche Datenschicht bleibt in Apples Verantwortung, die Verarbeitung kann aber bei einem Dritten stattfinden. Wer die Siri-ChatGPT-Integration so aktiviert, sollte wissen, welche Inhalte das Gerät verlassen. Die Frage ist dann nicht mehr, ob ein Modell gut antwortet, sondern wo die E-Mails, Kontakte und Kalendereinträge am Ende ausgewertet werden.

Warum die EU-Regulierung hier eine Rolle spielt

Der Digital Markets Act der Europäischen Union dürfte Apples Vorgehen mitgeprägt haben. Er verpflichtet Apple, Dritten einen wirksamen Zugang zu den Hardware- und Softwarefunktionen zu gewähren, die auch Apples eigene Dienste nutzen. Die Europäische Kommission hat ausdrücklich erklärt, dass dieses Prinzip auch für Siri gilt.

In den Kommentaren unter der Meldung findet sich diese Lesart wieder. Ein Nutzer schreibt, der abgeschottete Plattform-Ansatz halte nicht mehr, wenn ein so großer Teil des Arbeitsalltags auf dem Gerät stattfinde, und bedankt sich bei der EU. Ein anderer meint, der Fund belege, dass die Kommission von Anfang an recht gehabt habe und Apple unnötiges Theater veranstaltet habe. Man muss diese Einschätzungen nicht teilen, um zu sehen, dass die Regulierung hier als treibende Kraft hinter einer technischen Öffnung wirkt.

Gleichzeitig wäre es zu einfach, den Fund allein als erzwungene Zugeständnisse zu lesen. Wer sich die Architektur ansieht, erkennt ein durchdachtes Schichtenmodell, das auch ohne Regulierung sinnvoll wäre. Ein Assistent, der Aufgaben weiterreichen kann, ist leistungsfähiger als einer, der alles selbst können muss. Die Vorschrift dürfte den Zeitplan beschleunigt haben, nicht die Idee erfunden.

Was heute schon funktioniert und was noch fehlt

Die „Ask…“-Umsetzung ist im Release Candidate von macOS 27 Golden Gate derzeit auf die ChatGPT-Erweiterung beschränkt. Claude ist dort noch nicht verfügbar, obwohl die Mechanismen im Code schon angelegt sind. Wer eine Anleitung sucht, um Siri mit Claude zu verbinden, wird momentan noch auf die ChatGPT-Variante verwiesen.

Außerdem hat Apple die Berechtigung für die Model Delegation noch nicht für Dritte geöffnet. Der Mechanismus ist nicht nach außen sichtbar und nicht als Einstellung für normale Nutzer erreichbar. Man kann die Siri-ChatGPT-Erweiterung aktivieren, aber nicht frei zwischen Anbietern wählen. Der Code zeigt damit eher die geplante Richtung als ein fertiges Produkt.

In den Foren ist die Stimmung gespalten. Ein Kommentator hält Siri für deutlich besser, weil der Assistent nun konversations- und kontextbewusst arbeite, und nennt als Beispiel eine Frage nach dem Gitarristen eines laufenden Pink-Floyd-Stücks, die korrekt und schnell beantwortet wurde. Ein anderer merkt an, dass austauschbare On-Device-Modelle die Beschränkung auf neuere iPhone-Generationen überflüssig machen würden. Beide Beobachtungen betreffen denselben Punkt: Wenn das Modell austauschbar ist, verschiebt sich die Frage nach dem Wert des Geräts.

Was das konkret bedeutet

Für Nutzer ändert sich vorerst wenig. Siri in iOS 27 bekommt die neuen Fähigkeiten, die Apple angekündigt hat, und die Auswahl zwischen mehreren Modellen bleibt Zukunftsmusik. Der Unterschied liegt darin, dass die Entscheidung nicht mehr grundsätzlich offen ist, sondern nur noch zeitlich. Siri gegen ChatGPT oder Claude zu tauschen ist damit kein Hack mehr, sondern eine vorgesehene Betriebsart.

Für Apple verschiebt der Fund das Selbstverständnis. Siri wird von einem Produkt zu einer Plattform, und eine Plattform lebt davon, dass andere darauf aufbauen dürfen. Die Stimme, die Oberfläche und der Zugriff auf persönliche Daten bleiben in Cupertino, die Rechenleistung dahinter wird verhandelbar.

Für Anbieter wie Anthropic und OpenAI entsteht ein neuer Vertriebskanal, der ohne eigenen App-Store-Auftritt funktioniert. Wer in Siri als Modell ausgewählt wird, erreicht Menschen in genau dem Moment, in dem sie eine Frage haben. Gleichzeitig bleibt die Abhängigkeit: Ohne Apples Freigabe und ohne die Berechtigung für die Model Delegation passiert gar nichts. Die Macht, Modelle zu öffnen, liegt weiterhin bei dem Unternehmen, das die Oberfläche kontrolliert.

Bleibt die Frage nach den Daten. Ein Assistent, der E-Mails zusammenfasst und Nachrichten verschickt, verarbeitet das Privateste, was ein Gerät zu bieten hat. Wandert diese Verarbeitung zu einem fremden Anbieter, muss klar sein, was übertragen wird, wie lange es gespeichert bleibt und wer es einsehen kann. Der Code zeigt eine Möglichkeit. Ob sie gut wird, entscheidet sich nicht in der Bibliothek, sondern daran, wie ehrlich Apple und seine Partner darüber sprechen.

Quelle: macrumors.com

Was bringt Googles neues Migrationstool für den Wechsel von Microsoft 365? Einen kürzeren Weg vom Abo-Abschluss bis zum ersten gefüllten Postfach. Das IT-Portal Petri berichtete im September 2026, dass Google einen Migrationsassistenten direkt in den Einrichtungsprozess von Google Workspace integriert hat. Administratoren können dort Benutzer und Geschäftsdaten aus einer Microsoft-Umgebung importieren, ohne zuvor ein separates Migrationsprojekt aufzusetzen.

Ein Umzug ist ein passendes Bild. Bisher mussten Unternehmen die Kisten selbst packen: Postfächer exportieren, Dateien umkopieren, Kalender neu aufbauen, Termine koordinieren, und für all das meist ein spezialisiertes Werkzeug oder einen Dienstleister buchen. Google stellt den Umzugswagen jetzt schon beim Einzug bereit, also in dem Moment, in dem ein neues Workspace-Konto ohnehin eingerichtet wird.

Für kleine Betriebe und Bildungseinrichtungen ist das eine Erleichterung. Für größere Organisationen bleibt es ein Werkzeug mit Grenzen. Zwei Dinge sind dabei zu trennen: die gesenkte Einstiegshürde und die technische Reichweite des Assistenten.

Was Google direkt in die Workspace-Einrichtung eingebaut hat

Neu ist vor allem der Einstiegspunkt. Statt eines Migrationstools, das Administratoren irgendwo in den Tiefen der Admin-Konsole suchen müssen, sitzt der Import dort, wo ein neues Konto ohnehin konfiguriert wird. Der Administrator verbindet den Microsoft-Tenant mit globalen Administrator-Zugangsdaten, danach erkennt das Werkzeug die vorhandenen Benutzer und übernimmt deren Daten in die Google-Umgebung.

Übertragen werden E-Mail, OneDrive-Dateien, Kalendertermine, Kontakte und Aufgaben – also das, was den Arbeitsalltag einer einzelnen Person ausmacht. Google will damit die Zeit zwischen dem Kauf eines Workspace-Abos und dem ersten Arbeitstag der Belegschaft in Workspace verkürzen.

Je kürzer diese Lücke, desto geringer die Hürde, den Anbieter zu wechseln. Migration war lange eine der größten Reibungsflächen im Plattformgeschäft. Der neue Assistent ist deshalb weniger eine technische Neuerung als eine Ansage an alle, die einen Wechsel bisher gescheut haben.

Wie die Datenübertragung konkret abläuft

Der Ablauf folgt einer festen Reihenfolge. Zuerst muss die eigene Domain verifiziert sein, danach müssen die E-Mail-Einstellungen stehen. Erst dann lässt sich der Import starten, weil sonst die Zuordnung von Adressen zu Postfächern nicht stimmt. Der Bericht nennt beide Schritte als Voraussetzung, bevor Daten importiert werden können.

Wer sein Microsoft-Konto mit globalen Administratorrechten verbindet, sollte wissen, was er da tut. Diese Zugangsdaten öffnen praktisch jede Tür im Tenant. Sie gehören in die Hände der Personen, die die Migration verantworten, und nicht in einen Sammelordner für Betriebszugänge. Nach Abschluss der Übertragung ist es sinnvoll, die Verbindung zu prüfen und die verwendeten Zugangsdaten zu erneuern.

Auffällig sind die Datenquellen, die nicht genannt werden. Postfächer, OneDrive, Kalender, Kontakte und Aufgaben stehen auf der Liste. Teams-Konversationen, gewachsene SharePoint-Strukturen mit ihren Berechtigungsketten oder Automatisierungen, die an einzelne Konten gebunden sind, stehen nicht darauf. Wer in einer über Jahre gewachsenen Microsoft-Umgebung arbeitet, weiß, dass genau dort die schwierigen Fälle liegen.

Zehn Nutzer als Grenze: Wo der Assistent endet

Der entscheidende Vorbehalt steht in den Einschränkungen. Der automatisierte Prozess ist derzeit auf zehn Microsoft-Benutzer begrenzt. Für einen Handwerksbetrieb mit acht Mitarbeitern ist das keine Einschränkung, sondern schlicht passend. Für ein Unternehmen mit mehreren hundert Konten ist es ein Ausschlusskriterium.

Bei größeren Vorhaben bleibt es also beim klassischen Vorgehen: Pilotgruppe definieren, Migration in Wellen, eine Phase der Koexistenz, Nachzügler separat nachziehen. Größere Organisationen brauchen weiterhin zusätzliche Werkzeuge und eine belastbare Planung. Der Assistent verkürzt den Start, er ersetzt kein Migrationsprojekt.

Das ist keine Schwäche der Ankündigung, sondern eine Frage der Zielgruppe. Google bedient mit diesem Schritt zuerst diejenigen, die den Wechsel bisher gar nicht erst versucht haben. Wer schon einmal eine Migration mit mehreren tausend Postfächern begleitet hat, wird von einem Zehn-Nutzer-Import ohnehin nicht angesprochen.

Voraussetzungen: Domain, Lizenzen und der Unterschied zwischen den Tarifen

Ein zweiter Punkt ist das Lizenzmodell. Der Bericht nennt eine Bedingung, die leicht überlesen wird: Das Werkzeug steht zunächst Organisationen mit einem Flexible Plan zur Verfügung. Wer einen Annual- oder Fixed-Term-Plan gebucht hat, muss zusätzliche Lizenzen manuell hinzufügen, um den Migrationsassistenten überhaupt nutzen zu können.

Das ist ein Detail mit praktischen Folgen. Migrationen werden selten spontan entschieden, aber häufig kurzfristig angestoßen, wenn ein Vertrag ausläuft oder ein Standort dazukommt. Wer den Assistenten einplanen will, sollte den eigenen Tarif also vorher prüfen und nicht erst am Tag des Umzugs feststellen, dass die Voraussetzung fehlt. Solche Angaben ändern sich mit der Zeit, deshalb lohnt ein Blick in die aktuelle Dokumentation.

Hinzu kommt der unspektakuläre Teil: Domain-Verifizierung und E-Mail-Konfiguration stehen vor dem Import. Das klingt nach Formalie, ist aber der Punkt, an dem Projekte erfahrungsgemäß hängen bleiben. Solange die DNS-Einträge nicht sauber stehen, bewegt sich kein Postfach.

Wann sich zusätzliche Migrationstools weiterhin lohnen

Wer nach einem Migrationstool von Microsoft 365 zu Google Workspace sucht, findet mit dem eingebauten Assistenten eine Option, die für den Einstieg reicht. Wenn du allerdings vierzig Postfächer, zwei Standorte und eine Handvoll gemeinsam genutzter Postfächer bewegen musst, brauchst du mehr als das. Spezialisierte Migrationsdienste arbeiten mit Wiederholungsläufen, die Änderungen während der Umzugsphase nachziehen.

Diese Wiederholungsläufe entscheiden darüber, ob am Ende eine Lücke bleibt. In einem laufenden Betrieb kommen täglich neue Mails, neue Termine, neue Dateien hinzu. Eine Migration ohne Delta-Abgleich erzeugt einen sauberen Schnitt, aber auch eine Lücke. Wer Microsoft-365-Benutzer und -Daten importieren will, ohne den Betrieb anzuhalten, plant diese Phase bewusst ein.

Dazu kommen Themen, die sich nicht wegklicken lassen: Berechtigungen auf Freigaben, Archivpostfächer, Verteilergruppen, Protokolle für Nachweispflichten. Für Unternehmen zählt deshalb der Werkzeugkasten, nicht das einzelne Produkt. Der eingebaute Assistent deckt den kleinen Teil ab, spezialisierte Werkzeuge den großen.

Bevor irgendetwas übertragen wird, gehört eine Bestandsaufnahme auf den Tisch: Wie viele Konten gibt es wirklich? Welche Datenquellen werden genutzt, welche nur vermutet? Welche Fristen gelten, und wer kommuniziert den Wechsel an die Belegschaft? Diese Fragen kosten weniger Zeit als eine misslungene Migration.

Was das für den Alltag und den Wettbewerb bedeutet

Google senkt mit diesem Schritt die Kosten des Wechsels. Ein Anbieter, dessen Produkt schwer zu verlassen ist, bindet Kunden auch dann, wenn die Zufriedenheit sinkt. Ein Anbieter, dessen Produkt leicht zu verlassen ist, muss dagegen im Alltag überzeugen. Microsoft verliert dadurch keine Kunden, aber der Wechsel kostet weniger Überwindung.

Für kleine und mittlere Organisationen bedeutet das konkret: Eine Google-Workspace-Migration beginnt heute im Einrichtungsprozess statt in einem eigenen Projekt. Wer zehn oder weniger Konten bewegt und mit Postfach, OneDrive, Kalender, Kontakten und Aufgaben auskommt, kann den Assistenten im Einrichtungsprozess mitnehmen. Wer darüber liegt, plant weiterhin in Projektform.

Das eingebaute Tool reicht für den Einstieg, ersetzt aber keine Migrationsstrategie. Prüfe zuerst die Anzahl der Konten, dann den eigenen Lizenzplan, dann die tatsächlich genutzten Datenquellen. Erst danach entscheidet sich, ob der Assistent die Arbeit erledigt oder nur ein Teil davon ist.

Quelle: petri.com

Warum gehen KI-Agenten in alten Codebasen schief? Ein System, das seit Jahren läuft, lässt sich nicht mehr vollständig aus seinem Repository ablesen. Der Code ist die halbe Wahrheit. Die andere Hälfte steckt in Köpfen, in Tickets, in improvisierten Notlösungen und in Erwartungen, die andere Teams an dieses System richten.

Der Entwickler Addy Osmani, der viele Jahre in solchen Teams gearbeitet hat, beschreibt diese Lage in seinem Newsletter: Das Repository beschreibt nicht mehr das tatsächliche Verhalten. Institutionelles Wissen, Flickschusterei, alte Dienste und Zusagen an andere Abteilungen leben außerhalb des Verzeichnisbaums. Wer dort neuen Code schreibt, muss diese unsichtbaren Randbedingungen erst kennenlernen und danach belegen, dass er sie nicht verletzt hat.

Beim Brownfield Agentic Engineering geht es darum, KI-Agenten in eine gewachsene Codebasis zu bringen, ohne dass aus Tempo technische Schulden werden. Zwei Ziele zählen. Versteckte Zwänge sichtbar machen, und billige Änderungen vertrauenswürdig machen. Beides klingt bescheiden. Beides ist die Arbeit. Es geht nie um einen Neuanfang, sondern um sicheren Umgang mit Legacy Code bei laufendem Betrieb.

Warum Agenten in gewachsenen Codebasen falsch abbiegen

Man kann sich eine alte Codebasis wie eine gewachsene Stadt vorstellen. Es gibt Viertel aus den Neunzigern, in denen die Leitungen niemandem mehr gehören, der heute noch im Team ist. Es gibt Straßen, die offiziell gesperrt sind und trotzdem jeden Tag befahren werden, weil irgendein Prozess von dort kommt. Und es gibt Gegenden, in denen du ohne Begleitung nicht gräbst, weil dort die Versorgung für alles andere liegt.

Der Autor beschreibt, dass Agenten in dieser Umgebung gerne etwas abliefern, das funktioniert, aber die falsche Systemarchitektur hat und dazu brüchige Tests. Der Grund ist kein böser Wille des Modells. Ein Agent optimiert auf ein sichtbares Ziel, etwa einen grünen Testlauf oder eine formal erfüllte Anforderung, und nicht auf das, was ein Team unter gutem Design versteht.

Das Problem ist älter als die KI. Auch vorher liefen Modernisierungen in kleinen Stücken, mit starker Testabdeckung und einer dicken Schicht aus Vertrauen, damit niemand versehentlich etwas zerstört. Auf jede Nutzerreise folgte eine Batterie wiederholbarer Tests, die belegen sollte, dass sich das Verhalten nicht verschoben hat. Manche sagen heute, man sei schon im Brownfield-Modus, sobald ein Agent Code abliefert, den man nicht mehr Entscheidung für Entscheidung selbst geschrieben hat. Der Punkt stimmt, verschiebt aber nur die Frage: Wie organisierst du Änderungen so, dass sie billig bleiben?

Zonen, Blast Radius und wer die Landkarte zeichnet

Der Autor schlägt vor, die Codebasis in Zonen einzuteilen. Grün heißt: gute Tests, aktuelle Konventionen, saubere Isolation, dort darf ein Agent in einer engen Schleife arbeiten. Gelb heißt gemischte Qualität, dort wird zuerst ein Charakterisierungstest geschrieben und dann geändert. Rot heißt sensibel: Authentifizierung, Abrechnung, Berechtigungen, Lohnabrechnung. Überall dort, wo nur wenige Personen verstehen, wie es funktioniert, willst du keinen unbeaufsichtigten Umbau.

Typisch dafür sind Commerce-Landschaften. Fünf oder sechs Abteilungen betreiben ihre eigenen Mikroseiten, für den Nutzer fühlt sich alles wie ein einziger Auftritt an. Unter der Oberfläche steckt erhebliche Komplexität, und die eine Abteilung hat gute Tests, weil ihr Teil erst vor wenigen Jahren gebaut wurde, die andere womöglich nicht. Solche Unterschiede lassen sich nicht weglächeln, deshalb ist eine Karte nützlich.

Drei Regeln machen aus der Zonenidee ein Verfahren statt einer Metapher. Erstens: Ein Mensch zeichnet die Karte, nicht der Agent, denn überlässt man ihm die Wahl, beginnt er in der furchteinflößendsten Datei, weil dort die interessantesten Namen stehen. Zweitens: Zonen wandern nur, wenn sie es verdient haben; aus Gelb wird Grün, sobald Charakterisierungstests existieren und der Verantwortliche des Moduls die ersten Agentenänderungen geprüft hat. Drittens: Die Zone legt die Verben fest, Grün ist die enge Schleife, Gelb ist Test zuerst, Rot ist menschliche Begleitung bei jedem Schritt oder die Arbeit findet nicht statt. Autonomie folgt dem Blast Radius, also dem Ausmaß der Schäden bei einem Fehler, außerdem der Beobachtbarkeit und der Umkehrbarkeit. Die Selbstsicherheit eines Modells ist dafür ein schlechter Kompass.

Wie viel die Auswahl der richtigen Datei wert ist, zeigt ein Bericht von Teleport, der als bezahlte Anzeige in Osmanis Beitrag steht. Das Unternehmen richtete demnach ein Quartal lang die stärksten Modelle auf die eigene Codebasis, mit dreizehn Ingenieuren im Rücken. Es entstand ein ordentlicher Harness: Der Code wurde in Komponenten zerlegt, Agenten liefen darüber, skeptische Prüfer und Richter stritten über die Funde. Am Ende verlor dieser Aufbau gegen eine Person, die eine einzelne Datei öffnete und schrieb: Du bist in einem CTF, finde eine kritische Schwachstelle, fang hier an. Die schwere Frage ist offenbar nicht das Suchen, sondern das Wissen, welche Datei man öffnet. Schwachstellen in Brownfield-Codebasen zu finden heißt zuerst, den richtigen Ort zu kennen.

Was der Code nicht über sich selbst sagen kann

Wenn der Code die Quelle der Wahrheit ist, muss das Drumherum nur enthalten, was sich aus dem Code nicht ableiten lässt. Agenten finden erstaunlich viel über die Landkarte eines Systems selbst heraus. Es gab eine Phase, in der Teams Markdown-Dateien über alles schrieben und sie in das Kontextfenster stopften, meist vergeudeter Platz. Wertvoll sind die Dinge, die nirgends im Code stehen: team- und geschäftsspezifische Feinheiten, Kompromisse, die erklären, warum ein System so aufgebaut ist, Regeln, die keine statische Analyse erzwingt, und der historische Kontext hinter kontraintuitiven Implementierungen. Schreib auf, was der Code nicht sagen kann, und sonst nichts.

Für Gelb- und Rotarbeit empfiehlt der Autor einen separaten, nur lesenden Durchgang, der ein kurzes Verständnis-Memo erzeugt: Einstiegspunkte, Verantwortliche, Aufrufer, vorhandene Abstraktionen, Tests, Produktionssignale, relevante Vorgeschichte und offene Fragen. Jede Behauptung soll eine Datei, ein Ticket, eine Zuständigkeit oder ein Dashboard zitieren. Ohne dieses Artefakt zahlt der nächste Agent dieselbe Archäologie noch einmal. Der Agent versteht, wie der Auth-Flow läuft, erledigt seine Aufgabe und verliert dieses Verständnis, sobald die Sitzung endet. Der Chatverlauf ist kein gutes Archiv, besonders nicht, nachdem das Kontextfenster zusammengefasst wurde.

Nach der Recherche beginnt die Planung mit frischem Kontext. Welche Dateien berühren die plausiblen Wege? Welche Invarianten, also Zusicherungen, die immer gelten müssen, erhalten sie? Und wie würde man die Änderung wieder rückgängig machen? Den Pfad wählt ein Mensch. Wenn die Umsetzung merkt, dass die Karte falsch war, hält sie an, statt sich durchzuwurschteln. Die Prüfung startet später ebenfalls ohne Vorwissen und arbeitet rückwärts von den Abnahmekriterien. Ein unbeeinflusster Prüfer merkt eher, wenn ein Test die Implementierung belegt und die eigentliche Anforderung verfehlt.

Charakterisierungstests: Verhalten festnageln, bevor es besser wird

Wer KI-Agenten in Brownfield-Projekten einsetzt, sollte mit Arbeiten beginnen, die kein Risiko tragen. Nicht der Monolith in Rust, sondern: erst erklären lassen, wie die Dinge funktionieren, und dann Tests erzeugen, die das heutige Verhalten festhalten. Charakterisierungstests sind automatisierte Tests, die dokumentieren, was ein Modul heute tatsächlich tut, hässliche Stellen inklusive. In einem alten System ist ein Teil dieser Hässlichkeit genau das, wovon das Geschäft lebt. Ein Agent wird sie mit Freude reparieren, hinter einem grünen Testlauf.

Deshalb gilt eine Regel: Der Agent darf nicht in derselben Sitzung der einzige Autor der Tests sein, die er bestehen soll. Erst das Verhalten festnageln, in einem getrennten Durchgang oder von einem Menschen. Sonst entsteht eine grüne Suite, die genau jene Implementierung zementiert, die gerade erfunden wurde. Dieses Muster hat industrielle Vorbilder: Netflix nutzte beim Umstieg auf GraphQL dieselbe Idee, spiegelte Verkehr gegen alte und neue Pfade, verglich die Antworten und beförderte nur, was übereinstimmte. Wenn eine Oberfläche wie eine Startseite keine ehrliche Unit-Test-Suite hat, ist das der richtige Weg: nicht raten, sondern beides laufen lassen und vergleichen.

Danach folgen die mechanischen Umbauten: tote Codepfade, ungenutzte Exporte, Inventare. Der Autor rät ausdrücklich davon ab, mit den haarigsten Stellen zu beginnen. Er erinnert sich an eine Codebasis bei AOL, an einen freien Tag, an eine Nachricht des Vorgesetzten. Die Startseite lag komplett daneben, und es gab nicht genug JavaScript-Fachleute im Haus, um das kurzfristig zu durchdringen. Selbst bei offensichtlich defekten Dingen arbeiteten die Beteiligten mit großer Vorsicht. Das ist keine Nostalgie. Es ist die Erwartungshaltung, die man einem System entgegenbringt, das viele Menschen täglich benutzen.

Vom wiederholten Review-Kommentar zum Harness

Es hilft, die Werkzeugebenen sauber zu trennen. Anweisungen halten ungewöhnliche Fakten über ein Repository fest. Skills bündeln wiederverwendbare Abläufe, etwa das Prüfen des Blast Radius oder die Verifikation einer Schemaänderung. Plugins können geregelten Zugang zum Zuständigkeitskatalog, zum Incident-Archiv oder zu Dashboards geben. Der Harness ist die Arbeitsumgebung um den Agenten herum: Kontext, Werkzeuge, Berechtigungen, Tests, Logs und der Weg zurück. Eine Fabrik schließlich taktet viele verlässliche Schleifen, hält Zustand dauerhaft und gibt neue Fälle an Menschen zurück.

Der praktische Test ist die Frage, was passiert, wenn der Agent etwas falsch macht. Repariert man die Änderung still, wiederholt die nächste Sitzung denselben Fehler. Taucht derselbe Review-Kommentar ein zweites Mal auf, gehört er in eine Lint-Regel, einen Hook, einen Typ, einen Test oder einen Skill. Prosa bleibt für Zwänge, die sich nicht mechanisch erzwingen lassen. Eine Verbotsregel, ein eng begrenzter Zugangsschlüssel oder eine CI-Prüfung müssen sich nichts merken. Mit der Zeit wird der Harness zu einer Sammlung von Fehlern, die das Team beschlossen hat, nicht zweimal zu bezahlen.

Das ist auch die Antwort auf die Frage, wie Code-Verifikation in solchen Umgebungen skaliert. Mehr Zutrauen in das Modell hilft dabei nicht. Mehr Struktur um das Modell herum schon. Jede wiederholte Korrektur ist ein Hinweis auf ein fehlendes Stück Werkzeug. Wer diese Hinweise ernst nimmt, baut sich mit der Zeit eine Umgebung, in der Tests nicht nur grün leuchten, sondern etwas bedeuten.

Wie ein Einstieg in die eigene Codebasis aussieht

Für den Anfang braucht es keinen großen Umbau. Teile die Codebasis grob in Zonen ein und markiere, welche Bereiche niemand ohne Not anfassen sollte. Lass einen Agenten die Landkarte beschreiben und prüfe, wo er sich irrt. Schreibe ein Memo für Gelb und Rot, mit Belegen aus Dateien, Tickets und Dashboards. Und erzeuge für einen kleinen, gut abgegrenzten Teil Charakterisierungstests, bevor irgendjemand diesen Teil verbessern möchte.

Das bremst nicht. Es ist der Preis für Geschwindigkeit, die man behalten kann. Agentic Engineering in alten Codebasen funktioniert nicht, weil die Modelle plötzlich klug genug wären. Es funktioniert, wenn das Team vorher die unsichtbaren Zwänge sichtbar gemacht hat und danach jede Änderung belegen kann. Technische Schulden bei der Softwaremodernisierung vermeiden heißt genau das: früh festhalten, was gilt, und später nur das verbessern, was abgesichert ist.

Wer es nicht ernst nimmt, bekommt Code, der läuft, und eine Rechnung, die später kommt. Sie besteht aus technischen Schulden, die irgendwann niemand mehr auseinanderhalten kann. Die alten Systeme sind nicht deshalb alt, weil niemand etwas verstanden hätte. Sie sind alt, weil ihre Zwänge nie vollständig aufgeschrieben wurden. Das lässt sich heute mit Agenten nachholen. Man muss ihnen nur die Rolle geben, die zu ihnen passt: kein Architekt der Landkarte, sondern ein Arbeiter auf einem Terrain, das ein Mensch vermessen hat.

Quelle: addyo.substack.com

0,0041 Prozent. So niedrig beziffert der KI-Detektor Pangram die Rate, mit der er menschlich geschriebene Texte fälschlich als maschinell erzeugt einstuft. 0,34 Prozent stehen für den umgekehrten Fehler. An diesen beiden Zahlen hängt eine Debatte, die ein einzelner Tweet ausgelöst hat. Wer sich länger mit KI-Textdetektoren beschäftigt, merkt schnell: Interessant sind selten diese Werte, sondern der Graubereich dazwischen.

Wie Pangram sein Modell trainiert und woher die niedrige Fehlerquote stammt

Pangram ist kein Regelwerk, sondern ein trainiertes Modell. Es zerlegt einen Text und versucht, einzelne Passagen als eindeutig menschlich, eindeutig KI-generiert oder als Mischung aus beidem zu markieren. Wer genauer wissen will, wie das funktioniert, findet eine veröffentlichte Arbeit des Teams. Entscheidend ist das Training des Pangram-Modells, denn das Modell lernt an Daten, die es sich selbst herstellt.

Man beginnt mit Sammlungen, die sicher von Menschen verfasst wurden. Ein Sprachmodell bekommt den Auftrag, diesen Text zu verstehen und einen neuen Beitrag zum selben Thema zu schreiben. Zusätzlich lässt man dasselbe Modell nur Teile des Originals überarbeiten, sodass Texte entstehen, an denen Mensch und Maschine beteiligt waren. Über diesen Umweg lernt der Detektor, was Co-Autorenschaft auf Satzebene hinterlässt. Ein Rauchmelder arbeitet nach demselben Prinzip: Er erkennt nicht den Brand, sondern das, was der Brand in die Luft abgibt.

Wer die falsche Positivrate des Pangram-KI-Detektors nachschlägt, stößt auf genau diese 0,0041 Prozent. Es handelt sich um eine Angabe des Teams selbst, dessen Modell an selbst erzeugten Daten lernt. Das ist nicht unseriös, sondern der übliche Weg, ein solches Modell zu bauen und zu prüfen. Es erklärt aber, warum Laborzahlen und Alltagserfahrung auseinanderfallen können. Ein Rauchmelder kann in der Prüfkammer überzeugen und trotzdem jeden Morgen über dem Toaster losgehen.

Der David-Sacks-Tweet und der Vorwurf der Unbrauchbarkeit

Am 13. September 2026 schrieb David Sacks einen Tweet. Innerhalb weniger Minuten taten viele Leser das, was sie inzwischen reflexhaft tun: Sie fragten Pangram, ob der Text maschinell erzeugt sei. Das Ergebnis lautete, der Beitrag sei vollständig KI-generiert. Sacks reagierte mit der Einschätzung, diese Detektoren seien unbrauchbar. Damit stehen zwei Aussagen nebeneinander, die man trennen sollte.

Die erste betrifft einen Einzelfall: eine Klassifikation, richtig oder falsch. Die zweite betrifft die Qualität des Werkzeugs insgesamt, und die lässt sich nicht aus einem einzigen Tweet ableiten. Aus einem Fehlurteil folgt kein Modellversagen, aus einer guten Statistik nicht, dass jede Einzelbewertung stimmt. „Bogus“ ist ein Urteil, keine Messung. Der Vorfall zeigt vor allem, wie schnell KI-generierte Texte erkannt werden sollen, ohne dass jemand definiert, was genau erkannt werden soll: der Entstehungsprozess oder das Ergebnis.

Das Experiment: erst generieren lassen, dann von Hand umschreiben

Der Autor des Berichts, Armin Ronacher, bezeichnet sein Vorgehen selbst als Spaß. Er wollte den Sacks-Tweet nachbauen, und den Prompt dafür ließ er sich von einem Sprachmodell vorschlagen, was er offen einräumt. Die Vorgabe: acht Absätze, höchstens 350 Wörter, Thema „Pacing the Frontier“, als Kontext der Essay von Dario Amodei und ein zustimmender Tweet von Sam Altman. Dazu eine Strukturliste, die den Verlauf festlegte, von der eröffnenden Konzession über den Hinweis auf unveröffentlichte Modelle bis zum Schluss mit Regulierungsdebatte, China und offenen Gewichten.

Opus 5 lieferte einen Text, der sich glatt liest und dem Sacks-Tweet nur teilweise ähnelt. Pangram bewertete ihn als vollständig KI. Das überrascht nicht, denn ein vollständig generierter Text ist die leichteste Aufgabe für ein solches Werkzeug. Interessant wird es erst, wenn die Maschine aus dem Spiel genommen wird.

Im zweiten Durchgang ging der Autor Absatz für Absatz durch und formulierte jeden neu, von Hand, ohne Sprachmodell. Erst am Ende ließ er Tippfehler korrigieren, was nach seiner Erfahrung die Bewertung nicht ändert. Ähnlichkeitsprüfer bezifferten die Übereinstimmung mit dem Ausgangstext auf rund fünfzig Prozent, kein Satz war identisch. Man würde erwarten, dass ein solcher Text anders bewertet wird als seine Vorlage. Pangram kam erneut auf 100 Prozent KI.

Warum die Struktur mehr verrät als die einzelne Wortwahl

Hier hilft die Analogie vom Rauchmelder. Ein Melder misst Rauch, nicht Feuer, und er misst nicht, wer das Streichholz angezündet hat. Ein KI-Textdetektor arbeitet ähnlich: Er misst statistische Eigenschaften, nicht Absicht und nicht Urheberschaft. Wer einen Text Satz für Satz umschreibt, verändert die Wortwahl, lässt aber die Absatzlogik, die Reihenfolge der Argumente und den Rhythmus stehen. Genau diese Ebene prägt ein LLM als Schreibassistent am stärksten.

Der Autor zeigt sich von der zweiten 100-Prozent-Wertung nur mäßig überrascht. Seine Beobachtung: Ein Text, dessen Struktur einmal von einer Maschine vorgegeben wurde, wird diese Herkunft kaum noch los, selbst bei umfangreichen Überarbeitungen. Daraus folgt keine Verdammung des Werkzeugs, sondern eine genauere Vorstellung davon, was es tut. Es bewertet einen Prozess, nicht einen Menschen.

Für alle, die KI-Texterkennung als Kontrolle einsetzen wollen, ist das eine wichtige Einschränkung. Ein hoher KI-Anteil kann bedeuten, dass ein Text vollständig generiert wurde. Er kann aber auch bedeuten, dass jemand seine Struktur ausgelagert und anschließend gründlich editiert hat. Die Note sagt nichts darüber, wie viel Arbeit in einem Text steckt.

Zwei Jahre KI-Unterstützung und die Frage nach einem fairen Urteil

Der Autor betreibt seinen Blog seit etwa zwei Jahren mit KI-Unterstützung, was am Transparenzhinweis im Fußbereich sichtbar ist. In dieser Zeit, so beschreibt er es, wurde er abhängiger von den Werkzeugen, und die Werkzeuge wurden zu aggressiveren Redakteuren. Das habe ihn innehalten lassen. Wer regelmäßig mit einem LLM als Schreibassistent arbeitet, kennt diesen Sog: Erst lässt man korrigieren, dann umformulieren, dann gliedern, und irgendwann stammt der Bauplan eines Beitrags nicht mehr von einem selbst.

Gleichzeitig erwartet er, dass viele Leute das Etikett „100 Prozent KI“ für irreführend halten, wenn ein Autor viel eigene Arbeit in die Überarbeitung gesteckt hat. Es trifft einen Prozess, den viele Leser als Vorwurf lesen. Ob es trotzdem fair ist, einen solchen Text vollständig als maschinell zu führen, lässt er offen. Das ist ehrlicher als eine schnelle Antwort in beide Richtungen.

Was der Detektor misst und wo seine Grenzen liegen

Die 0,0041 Prozent gelten für den Durchschnitt, nicht für den Einzelfall. Der Pangram KI-Detektor eignet sich deshalb weniger als Schiedsrichter über Urheberschaft denn als Messgerät für Textgewohnheiten. Wer ihn so einsetzt, gewinnt eine brauchbare Information darüber, wie ein Text entstanden sein könnte. Wer ihn als Wahrheitsmaschine behandelt, wird ausgerechnet in den strittigen Fällen enttäuscht.

Für den Alltag heißt das zweierlei. Erstens: Wer KI-generierte Texte erkennen will, sollte auf die Struktur schauen, nicht nur auf Formulierungen. Die Struktur ist das zäheste Erbe einer Maschine. Zweitens: Wer selbst mit einem Sprachmodell arbeitet, sollte bewusst entscheiden, welche Ebene er abgibt. Recherche und Bauplan auszulagern ist etwas anderes, als einen Absatz glätten zu lassen, und der Unterschied verschwindet nicht durch anschließendes Umschreiben. Ein Detektor, der einen handgefeilten Text weiter als vollständig maschinell führt, ist kein Skandal. Er zeigt nur, dass Herkunft und Oberfläche zwei verschiedene Dinge sind.

Quelle: lucumr.pocoo.org