Eine der beliebtesten GEO-Taktiken der letzten zwei Jahre ist schnell erklärt: Man veröffentlicht auf der eigenen Domain eine „Best of“-Liste für die eigene Branche, setzt sich selbst möglichst weit oben rein – und hofft, dass ChatGPT, Gemini, Perplexity und Copilot die eigene Marke daraus als Empfehlung übernehmen. Die Taktik hat lange funktioniert, weil sie eine echte Content-Lücke ausgenutzt hat: Vor dem GEO-Boom hat kaum jemand Seiten produziert, die frontal auf „Was ist die beste Marke für X?“ zielen, weil solche offen tendenziösen Inhalte vor menschlichen Lesern schlicht unangenehm sind.
Inzwischen liegen dazu mehrere empirische Untersuchungen vor, und sie zeichnen ein deutlich differenzierteres Bild als das schlichte „Liste rankt, Marke gewinnt“. Ich habe mir die drei relevantesten angesehen: zwei ältere Studien und ein neues Langzeit-Experiment, das die beiden zusammenführt und über mehrere KI-Assistenten hinweg fortschreibt.
Was die drei Untersuchungen gefunden haben
Glen Allsopp (Ahrefs, Dezember 2025): Die Taktik bringt Zitate. Allsopp hat 750 Top-of-Funnel-Prompts in den Kategorien Software, Produkte und Agenturen manuell ausgewertet und dabei 26 283 Quell-URLs kategorisiert.
„Best X“-Blog-Listen waren mit 43,8 % der häufigste Seitentyp unter allen Quellen – inklusive jener Listen, in denen sich die empfohlene Marke selbst auf Platz eins gesetzt hat.
Zusätzlich zeigte sich eine Korrelation zwischen einer hohen Position in solchen Listen und der Wahrscheinlichkeit, empfohlen zu werden. In der Software-Kategorie tauchte die eigene Liste in gut einem Drittel der Antworten auf, wenn der Publisher empfohlen wurde.
Allsopps Fazit war eindeutig: SaaS-Unternehmen und Agenturen sollten solche Listen veröffentlichen, weil aus Ranking- und Zitationssicht kein Nachteil erkennbar war.
Lily Ray (Juni 2026): Zitiert ist nicht empfohlen. Ray hat 100 B2B-„Best [Kategorie]“-Queries in Googles AI Overviews zu drei Zeitpunkten (15. April, 15. Mai, 8. Juni 2026) erhoben und dabei sauber zwischen zwei Dingen getrennt, die in der Branche gern verwechselt werden: zitiert werden (die eigene Seite erscheint als Quelle) und empfohlen werden (die Marke wird im Antworttext tatsächlich genannt).
Das zentrale Ergebnis: Wenn die selbstpromotende Liste zitiert wurde, fehlte die eigene Marke in 69 % der Fälle in der eigentlichen Empfehlung.
Empfohlen wurden stattdessen die etablierten Marktführer – häufig ausgerechnet die Wettbewerber, die der Publisher in seiner eigenen Liste aufgeführt hatte.
Rays These: Google hat begonnen, das, was es zitiert, von dem zu entkoppeln, wen es empfiehlt – und diese zweite Entscheidung hängt an der bestehenden Autorität einer Marke, nicht daran, wie oft sie sich selbst zur besten erklärt.
Flankiert wird das von zwei weiteren Beobachtungen: einer organischen Abwertung stark selbstpromotender Sites seit Januar 2026 und neuen Disclaimern in AI Overviews, die bei Experten-Queries vor „selbsternannten“ Anbietern warnen.
Mateusz Makosiewicz (Ahrefs, Juli 2026): Über alle Engines, über vier Monate. Das jüngste und methodisch interessanteste Stück ist ein quasi-experimenteller Aufbau: 34 selbstpromotende Seiten auf fünf Domains für zwei Marken – das etablierte Tool Ahrefs Brand Radar und die neue Konferenz Ahrefs Evolve. Ausgewertet wurden 9 886 Antworten aus ChatGPT, Gemini, Perplexity und Copilot zwischen dem 7. Februar und dem 31. Mai 2026.
Die Befunde:
Für die neue Marke wirkte der Content. Evolve rückte in 72 zuvor leere Slots, und 82 % dieser neuen Erwähnungen standen in Antworten, die eine der eigenen Seiten zitierten. Der Content war hier die Brücke zwischen „nicht erwähnt“ und „erwähnt“.
Für die etablierte Marke bewegte er fast nichts. Bei Brand Radar kamen nur 6 % der neuen Erwähnungen aus den eigenen Seiten, 94 % aus Drittinhalten. Wer schon bekannt ist, wird ohnehin genannt.
Der Bumerang ist real.
Unter den Antworten, die eine Evolve-Seite zitierten, fehlte Evolve in 43 % der Fälle – die Konferenz lieferte die Quelle, ein Wettbewerber bekam die Empfehlung. Bei Seiten, die nur „gefunden“, aber nicht zitiert wurden, stieg diese Quote auf 74 %. Bei der etablierten Marke lag sie mit 11 % (zitiert) bzw. 15 % (gefunden) deutlich niedriger.
Zitate sind flüchtig. Rund ein Viertel der Seiten wurde für eine Query einmal zitiert und danach nie wieder; wiederkehrende Zitate erschienen im Schnitt nur an etwa jedem dritten möglichen Tag. Selbst starke Domains lösten das nicht.
Passung schlägt Reichweite.
Evolve erschien in 66,4 % der Antworten auf „best SEO conferences 2026“, aber nur in 15,8 % auf „best marketing conferences 2026“ – mehr als das Vierfache für die enger passende Query.
Daraus formuliert Makosiewicz eine Hypothese, die ich für den Kern des Ganzen halte: Self-Promotional Content wirkt am ehesten dort, wo sich Awareness-Gap × Query-Fit × Trust überlagern – wenn die Marke sachlich in eine enge Kategorie gehört, die KI diesen Zusammenhang aber noch nicht kennt, und die Marke plausibel genug ist, um in den bestehenden Konsens zu passen.
Wie das wissenschaftlich einzuordnen ist
Zunächst das Offensichtliche: Das sind Praxisstudien und Feldbeobachtungen, keine peer-reviewten Experimente. Das mindert ihren Wert nicht – aber es setzt den epistemischen Rahmen. Konkret:
Design: Allsopp und Ray sind rein beobachtend bzw. korrelativ. Ray zeigt einen Zusammenhang zwischen Markenautorität (Referring Domains, KI-Erwähnungen) und Empfehlung, kann daraus aber keine Kausalität ableiten. Makosiewicz’ Evolve-Arm ist der einzige Aufbau mit echter Intervention und Vorher-nachher-Baseline und kommt einer kausalen Aussage am nächsten. Allerdings: n = 1 Marke, ein einzelner Experimentator, keine Kontrollgruppe – und ein gewichtiger Confounder, weil Evolve eine real neu gestartete, PR-aktive Konferenz ist. Erwähnungen können also auch aus Gründen steigen, die nichts mit den Seiten zu tun haben.
Konstruktvalidität: Der stärkste methodische Beitrag ist die Dreiteilung zitiert / gefunden / empfohlen. Sie zerlegt die vage Sammelgröße „AI-Visibility“ in messbare, ökonomisch unterschiedliche Ereignisse – und entzaubert damit die Zitat-Kennzahl als Erfolgsmaß.
Reliabilität: Genau hier liegt die tiefe Krux jeder GEO-Forschung: LLM-Ausgaben sind nicht-deterministisch und zeitlich instabil. Makosiewicz’ Flicker-Befund ist im Grunde ein Reliabilitätsergebnis; eine begleitende Ahrefs-Auswertung fand, dass zwischen zwei Messungen nur rund 54 % der zitierten URLs erhalten blieben. Das heißt: Jede Momentaufnahme – auch diese drei – misst ein rauschendes Signal, und Effektstärken sind entsprechend unsicher.
Interessenlage und Instrument: Alle drei Untersuchungen laufen über Ahrefs Brand Radar; zwei erscheinen direkt im Ahrefs-Blog. Das disqualifiziert nichts, aber das Messinstrument ist zugleich das verkaufte Produkt, und dessen Prompt- und Engine-Sampling bleibt eine Blackbox. Bemerkenswert ist immerhin, dass die Schlussfolgerungen der Taktik eher schaden als nützen – ein Ergebnis gegen das naheliegende kommerzielle Interesse.
Externe Validität: Starker Bias Richtung B2B-SaaS und SEO-Branche, ausschließlich englischsprachig, spezifische Engines, ein enges Zeitfenster in 2026. Angesichts der Google-Updates im Januar und Mai 2026 ist der Boden in Bewegung – manche Befunde könnten schon jetzt veraltet sein.
Was fehlt: Keine echte Kontrolle (vergleichbare Marken ohne solche Seiten), keine Manipulation einzelner Variablen unter sonst gleichen Bedingungen, keine Konfidenzintervalle, keine Signifikanztests – nur rohe Prozentwerte.
Das eigentlich Überzeugende ist deshalb nicht die einzelne Zahl, sondern die Triangulation: Drei unabhängige Aufbauten, unterschiedliche Engines, unterschiedliche Methoden – und alle zeigen in dieselbe Richtung (zitiert ≠ empfohlen; die Empfehlung ist autoritätsgebunden). Konvergente Evidenz über unabhängige Messungen wiegt in diesem Feld mehr als jeder p-Wert aus einer einzelnen Erhebung.
Meine Einordnung für SEOs und GEOs
Für mich ergeben sich daraus fünf Konsequenzen.
Erstens: Das Zitat ist eine Vanity-Metrik. Wer „AI-Citations“ als Erfolgskennzahl trackt, misst das Falsche. Relevant ist die Empfehlung bzw. die Markennennung im Antworttext – und die kann trotz Zitat komplett ausbleiben. Trennt diese beiden Ereignisse in jedem Reporting, sonst verkauft ihr euren Stakeholdern eine Zahl, die sich in der Empfehlung nicht materialisiert.
Zweitens: Die Taktik ist situativ, kein Wachstumshebel. Sie kann eine Brücke sein, wenn eine legitime, aber unsichtbare Entität in einer engen, sachlich passenden Kategorie fehlt. Für etablierte Marken ist sie im besten Fall Rauschen, im schlechteren ein Reputationsrisiko – bis hin zu den „inauthentic mentions“, gegen die Google bereits algorithmisch vorgeht.
Drittens: Der Bumerang ist die eigentliche Pointe. Wenn das Modell eure Liste als neutrale Quelle behandelt und daraus die Konsens-Namen zieht, die ihr aufgeführt habt, dann habt ihr die Empfehlung eurer Wettbewerber mitfinanziert. Bei schwachen Marken ist die selbstpromotende Liste im Zweifel kostenloses Marketing für die Konkurrenz.
Viertens: Der wahre Hebel liegt off-domain. Was empfohlen wird, entscheidet der Konsens des restlichen Webs – Erwähnungen, Links, das Gerede über eure Marke anderswo. Das ist der nicht hackbare Teil, und es heißt schlicht Brand-Building und digitale PR. GEO konvergiert damit zurück zu den Grundlagen: Man kann Autorität nicht per On-Domain-Trick abkürzen.
Fünftens: Flüchtigkeit ändert die Messpraxis. Vertraut keiner Momentaufnahme. Trackt Verteilungen über Zeit, rechnet mit Schwankungen, berichtet Bandbreiten statt Punktwerte – und akzeptiert, dass das System, für das ihr optimiert, ein bewegliches Ziel ist.
Wenn ihr die Taktik trotzdem einsetzt, dann sauber: Füllt echte Lücken, statt euch selbst zu krönen. Verzichtet auf das Schlechtreden von Wettbewerbern. Haltet die Inhalte aktuell – die „Documentation Tax“ ist real, und veraltete Seiten füttern die Modelle irgendwann mit falschen Informationen über euch und eure Konkurrenz. Und verlinkt Alternativen ehrlich.
Unterm Strich ist das für mich ein weiterer Fall, in dem ein vermeintlicher Hack eine kurze Halbwertszeit hatte und die belastbare Antwort die unspektakuläre bleibt: echte Substanz, echte Autorität, aktuelle Informationen. Gute Prompts und clevere Listen-Tricks allein reichen eben nicht.
Die neue große Erzählung der KI-Branche ist schnell zusammengefasst: Nach Chatbots kommen Agenten. Agenten werden zu digitalen Mitarbeitenden. Digitale Mitarbeitende bekommen Namen, Rollen, Aufgaben, Zugänge, Skills und Tools. Und irgendwann, so die implizite Hoffnung, arbeiten sie eben wie Kolleg:innen.
Das klingt modern. Es klingt produktiv. Es klingt nach dem nächsten logischen Schritt.
Aber es ist die falsche Metapher.
Der MIT-Technology-Review-Artikel „AI agents are not your ‚coworkers‘“ trifft deshalb einen Nerv – nicht, weil agentische KI überschätzt wäre. Im Gegenteil: Die technische Entwicklung ist real. Agenten können heute mehrstufig arbeiten, Tools nutzen, Dateien lesen, Code schreiben, Recherchen durchführen, Systeme bedienen und Aufgaben über längere Zeit verfolgen. Aber die Art und Weise, wie wir über sie sprechen, prägt, wie Menschen mit ihnen arbeiten.
Und genau dort beginnt das Risiko.
Der Artikel beschreibt eine Studie von Emma Wiles (Boston University), in der Menschen schlechter darin waren, Fehler zu erkennen, wenn dieselbe Arbeit als Output eines agentischen „AI employee“ statt als Output eines Chatbots beschrieben wurde. Laut MIT Technology Review erkannten die Teilnehmenden 18 Prozent weniger Fehler, wenn das System als KI-Mitarbeitender gerahmt wurde. Außerdem waren sie 44 Prozent häufiger bereit, fragwürdige Arbeit an eine Führungskraft weiterzueskalieren, statt selbst Verantwortung für die Korrektur zu übernehmen.
Das ist mehr als ein Naming-Problem. Es ist ein Verantwortungsproblem.
Wenn wir KI-Agenten als Mitarbeitende bezeichnen, verschieben wir psychologisch Verantwortung. Wir tun so, als hätte das System eine Rolle, eine Zuständigkeit, vielleicht sogar eine Art Urteilskraft. Aber genau das hat es nicht. Ein Agent kann handeln. Er kann aber keine Verantwortung tragen.
Deshalb lautet die zentrale These:
Agenten sind keine Kolleg:innen. Agenten sind Prozessbausteine.
Und wer sie produktiv einsetzen will, braucht nicht nur bessere Agenten. Er braucht bessere Arbeitsarchitektur.
Der gefährliche Charme des „digital employee“
Die Metapher vom digitalen Mitarbeitenden ist für Anbieter attraktiv. Sie ist einfach zu verkaufen, klingt nach Produktivität, Skalierung und Entlastung – und verspricht: Wir stellen nicht nur ein Tool bereit, sondern eine neue Arbeitskraft.
Der MIT-Artikel beschreibt, dass Unternehmen KI-Agenten bereits als Mitarbeitende rahmen, teils mit Namen, Titeln und Zuständigkeiten. Fast ein Drittel der von Wiles untersuchten Manager:innen gab demnach an, dass ihre Unternehmen KI-Agenten bereits als Mitarbeitende darstellen; 23 Prozent sagten sogar, sie würden auf Organigrammen geführt.
Das ist bemerkenswert. Denn sobald ein Agent als „Kollege“ erscheint, verändert sich die soziale Dynamik. Menschen behandeln ihn nicht mehr nur als Werkzeug, dessen Output geprüft werden muss, sondern eher als Akteur, dessen Arbeit man beurteilt, aber nicht vollständig verantwortet.
Das ist problematisch, weil KI-Agenten genau dort gefährlich überzeugend sind, wo menschliche Kontrolle notwendig bleibt: Sie produzieren plausible Zwischenstände, erzeugen strukturierte Artefakte, wirken zielgerichtet, formulieren souverän, glätten Unsicherheit sprachlich – und lassen Arbeit so aussehen, als sei sie abgeschlossen.
Abgeschlossen ist sie aber erst, wenn ein Mensch mit der richtigen Fachkompetenz sie geprüft und verantwortet hat.
Ein Agent kann Vorschläge machen, Schritte ausführen, Tools nutzen, Variationen erzeugen und Recherche strukturieren. Aber er kann nicht entscheiden, ob ein strategischer Rat kundenspezifisch tragfähig ist. Er kann nicht für eine Markenentscheidung einstehen, keine Kundenbeziehung verantworten, nicht beurteilen, ob ein scheinbar effizienter Vorschlag langfristig Vertrauen zerstört. Er kann nicht haften. Er kann keine berufliche Verantwortung übernehmen.
Das ist der Kern.
Agenten werden besser – das macht Governance nicht weniger wichtig, sondern wichtiger
Es wäre falsch, agentische KI kleinzureden. Die technische Entwicklung ist real, Agenten werden leistungsfähiger, ausdauernder und besser integriert. Mehrere Entwicklungen sind bereits sichtbar:
Agent-SDKs werden reifer. Anbieter bauen Funktionen für Tool Use, Handoffs, Tracing, Sessions, Guardrails und Human-in-the-Loop.
Skills und Plugins werden zu wiederverwendbaren Arbeitspaketen. Statt nur Prompts zu schreiben, kapseln Organisationen Aufgabenlogiken: Anweisungen, Beispiele, Toolzugänge, Ressourcen, Prüfregeln und Outputformate.
MCP und ähnliche Protokolle verbinden Agenten mit realen Systemen: Dateien, Datenbanken, APIs, Projektmanagement, Designsystemen, CRM, Analytics, Repositories, Kalendern, Tickets und Kommunikationsplattformen.
Workspaces werden persistent. Agentische Arbeit findet nicht mehr nur im Chat statt, sondern in Arbeitsumgebungen mit Dateien, Zuständen, Logs, Artefakten, Versionen und Berechtigungen.
Evaluation verschiebt sich. Es geht nicht mehr nur darum, ob eine Antwort gut klingt, sondern ob der Endzustand einer Aufgabe korrekt ist: Welche Tools wurden genutzt? Welche Daten verändert? Welche Artefakte entstanden? Welche Reviews fehlen? Welche Aktion war riskant?
Kostensteuerung wird zentral. Je mehr Agenten, Skills und LLM-Steps produktiv laufen, desto wichtiger werden Modellrouting, Budgets, Providerwahl, Tokenkosten, Laufzeitlimits und Cost Monitoring.
All das spricht nicht gegen Agenten. Aber es spricht sehr deutlich gegen die naive Agenten-Erzählung. Je mächtiger Agenten werden, desto weniger dürfen sie außerhalb klarer Arbeitsarchitektur operieren. Ein schwacher Chatbot erzeugt vielleicht einen schlechten Text. Ein mächtiger Agent kann einen Prozess falsch ausführen, Daten falsch interpretieren, ein Tool unpassend nutzen, falsche Zwischenstände erzeugen, Kosten verursachen oder Verantwortung verschleiern.
Die Zukunft agentischer KI ist deshalb nicht einfach eine Zukunft autonomer Mitarbeitender. Sie ist eine Zukunft kontrollierter Arbeitsumgebungen.
Die eigentliche Frage: Wer besitzt den Prozess?
Wenn Agenten in Unternehmen produktiv werden sollen, lautet die wichtigste Frage nicht „Wie autonom ist der Agent?“, sondern:
Wer besitzt den Prozesszustand?
Das ist der zentrale Architekturpunkt.
Wenn der Agent den Prozess besitzt, entscheidet er bei jedem Lauf neu: Welche Schritte sind nötig? Welche Tools nutze ich? Welche Daten brauche ich? Wann bin ich fertig? Welche Zwischenergebnisse genügen? Welche Fehler ignoriere ich, welche Unsicherheiten markiere ich – und welche nicht? Für Exploration kann das funktionieren. Für produktive Kernprozesse ist es riskant.
Wenn dagegen der Workflow den Prozess besitzt, sieht die Architektur anders aus: Der Workflow definiert Ziel, Inputs, erlaubte Daten, mögliche Branches, Step-Typen, Tools, Review-Gates, Output-Artefakte, Status, Fallbacks, Rollen, Kostenlimits und Exportregeln. Agenten und Skills kommen dann nicht als freie Prozessbesitzer ins System, sondern als kontrollierte Bausteine innerhalb eines definierten Rahmens.
Das ist der Unterschied zwischen
„Der Agent macht die Keyword Research.“
und
„Der Workflow führt die Keyword Research. Ein begrenzter agentischer Step unterstützt die Exploration innerhalb definierter Quellen, ein LLM-Step clustert Daten, ein Human-Review-Gate prüft die Priorisierung, und ein Fallback greift, wenn der Kundentyp außerhalb des Operating Envelope liegt.“
Das klingt weniger spektakulär. Aber es ist professioneller.
Warum starre Workflows allein nicht reichen
Hier entsteht schnell ein Missverständnis. Wenn der Workflow den Prozess besitzen soll, klingt das nach Starrheit – nach Wasserfall, deterministischer Pipeline, „immer derselbe Ablauf“. Gerade für Agenturarbeit wäre das falsch.
Eine Keyword Research sieht für einen lokalen Laden anders aus als für einen Filialisten mit 150 Standorten, einen E-Commerce-Händler, ein B2B-Beratungsunternehmen oder einen multinationalen Mischkonzern. Eine Markenanalyse läuft bei einem etablierten Mittelständler anders als bei einem Start-up. Ein UX-Review für eine Kampagnen-Landingpage ist nicht dasselbe wie für ein komplexes B2B-Portal. Und eine Creative Route entsteht anders als ein Monatsreport.
Heißt: Nicht alles kann oder sollte vollständig deterministisch werden. Der bessere Satz lautet deshalb:
Die Plattform muss nicht jeden Denkweg deterministisch machen. Sie muss stabile Schnittstellen um flexible Arbeit herum bauen.
Der Prozessrahmen ist stabil – die Betriebsmodi innerhalb des Prozesses dürfen unterschiedlich sein. Ein Step kann deterministisch sein, LLM-gestützt, einen Skill nutzen, agentisch begrenzt sein, menschliche Assistenz erfordern, ein Review-Gate sein oder einen Fallback auslösen. Die Plattform führt den Gesamtzustand, auch wenn einzelne Abschnitte flexibel bearbeitet werden.
Skills und Agenten gehören auf die Plattform – aber nicht als Spielwiese
In vielen Organisationen liegen Skills, Prompts, Plugins und Agenten heute verteilt in einzelnen Tools: Claude, ChatGPT, Gemini, Slack, Notion, Google Drive, GitHub, Browser-Setups, lokalen Dateien oder persönlichen Arbeitsweisen. Für Exploration ist das unvermeidbar. Zum Problem wird es, sobald diese Setups teamweit, kundennah oder wiederkehrend genutzt werden.
Dann stellen sich Fragen: Wer hat den Skill erstellt? Ist er reviewed? Welche Version ist aktuell? Welche Daten darf er verwenden, welche Tools nutzt er, welche Ergebnisse erzeugt er? Wer darf ihn nutzen, wer muss den Output prüfen? Wann wird daraus ein Workflow? Wie fließen Fehler zurück? Wie wird ein Skill deprecated? Was kostet die Nutzung – und ist das alles an einen einzigen Anbieter gebunden?
Wenn darauf niemand eine verlässliche Antwort hat, entsteht Schatten-KI.
Deshalb reicht ein separater KI-Hub als reiner Dokumentationsort langfristig nicht. Die bessere Lösung: Skills, Plugins und begrenzte Agenten in die Plattform holen – als kontrollierte Prozessbausteine.
Von „AI employee“ zu „Capability“
Die Employee-Metapher verschiebt Verantwortung. Die Capability-Metapher klärt sie. Statt zu fragen „Welcher Agent übernimmt diese Rolle?“, sollten wir fragen:
Welche Fähigkeit wollen wir als Organisation aufbauen, betreiben, prüfen und verbessern?
Eine Capability kann klein beginnen: ein Prompt für eine wiederkehrende Aufgabe, ein Skill für strategisches Sparring, ein Plugin für eine Marketing-Analyse, ein agentischer Step für Wettbewerbsrecherche, ein Plattformworkflow für eine standardisierte Analyse.
Entscheidend: Nicht jeder Skill muss vollständig produktisiert werden. Manche Capabilities bleiben dauerhaft in agentischen Skills – und das ist kein Scheitern, sondern die richtige Betriebsform, wenn die Varianz hoch bleibt, menschliches Urteil zentral ist oder Plattformlogik die Arbeit schlechter machen würde.
Aber sobald ein Skill wiederkehrend, teamrelevant, kundennah oder kostenintensiv wird, braucht er einen geregelten Ort. Dieser Ort ist die Plattform.
Was der MIT-Artikel für Unternehmen eigentlich bedeutet
Der Artikel ist nicht nur eine Kritik an Marketing-Sprache. Er ist ein Hinweis auf ein Organisationsrisiko. Wenn wir Agenten als Mitarbeitende vermarkten, riskieren wir drei Dinge:
Menschen prüfen schlechter, weil sie dem System implizit mehr Eigenständigkeit zuschreiben.
Menschen fühlen sich weniger verantwortlich, weil das System wie ein eigener Akteur erscheint.
Organisationen können Fehler leichter auf „die KI“ schieben, obwohl es eigentlich um schlechte Prozesse, falsche Anreize, mangelhafte Reviews oder unklare Zuständigkeiten geht.
Für Marketing, Beratung, Design und Performance ist das besonders relevant. Denn unsere Arbeit besteht nicht nur aus ausführbaren Tasks, sondern aus Kontext, Beziehung, Interpretation, Marke, Wirkung, Priorisierung, Trade-offs und Verantwortung:
Eine KI kann eine kreative Route vorschlagen – aber nicht wissen, ob sie politisch beim Kunden tragfähig ist.
Eine KI kann UX-Findings formulieren – aber nicht beurteilen, ob die empfohlene Änderung zur Geschäftslogik passt.
Eine KI kann Keywords clustern – aber nicht wissen, welcher Hebel im Kundenkontext wirklich der nächste richtige Schritt ist.
Eine KI kann eine Positionierung challengen – aber sie trägt keine Verantwortung für die strategischen Folgen.
Deshalb muss das System so gestaltet sein, dass Verantwortung nicht verschwindet.
Die antizipierte Zukunft: Agenten werden normal, aber nicht autonom im Organisationssinn
In den nächsten Jahren wird sich agentische KI normalisieren. Unternehmen werden nicht mehr darüber sprechen, ob sie Agenten nutzen, sondern welche Agenten, Skills und Workflows freigegeben sind. Wir werden Agent Registries sehen, Skill Libraries, Tool Permissioning, Workspace Logs, Agent Evals, Run Replay, Cost Dashboards, Fallback Policies, Human-Review-Queues, Model Routing, provider-agnostische LLM-Gateways, Agentic Work Units, Artifact Stores, Audit Trails und Capability Lifecycles.
Auch die Sprache wird sich verändern. Gute Organisationen fragen dann nicht mehr „Wie viele Agenten haben wir?“, sondern: Welche Capabilities betreiben wir? Welche sind experimentell, welche assistiv, welche produktiv? Welche haben Owner, welche sind reviewed, welche haben Kostenlimits? Welche sind an einen Anbieter gebunden? Welche dürfen Kundendaten verarbeiten, welche erzeugen externe Outputs – und welche bleiben bewusst menschlich?
Fazit: Agenten brauchen keine Jobtitel. Sie brauchen Grenzen.
Agenten werden Teil unserer Arbeit. Sie werden stärker, nützlicher und operativer, sie nutzen Tools, bedienen Workspaces, führen Skills aus, erzeugen Artefakte und beschleunigen Abläufe. Aber vertrauenswürdig werden sie nicht dadurch, dass wir ihnen Namen geben.
Nützlich werden sie, wenn wir sie richtig einbetten:
in Workflows statt in freie Toolketten,
in Artefakte statt in Chatantworten,
in Reviewprozesse statt in blindes Vertrauen,
in Rollenlogik statt in Organigramm-Fantasien,
in Kostenkontrolle statt in Vendor-Lock-in,
in Capability Management statt in Prompt-Wildwuchs,
in menschliche Verantwortung statt in automatisierte Schuldverschiebung.
Die Zukunft agentischer KI liegt nicht darin, Agenten wie Kolleg:innen zu behandeln. Sie liegt darin, Arbeitsräume zu bauen, in denen Agenten keine Kolleg:innen sein müssen, um wertvoll zu sein.
Struktur führt. KI unterstützt. Menschen verantworten.
Trust ist in der Suche nichts Neues. Im Gegenteil: Man könnte sogar sagen, dass Google von Anfang an vor allem ein Vertrauensproblem lösen musste. Das offene Web war immer zu groß, zu chaotisch und zu leicht manipulierbar, um einfach nur Dokumente zu finden, in denen die richtigen Wörter vorkommen. Suchmaschinen mussten schon immer entscheiden: Welche Quellen sind relevant? Welche sind verlässlich? Welche sind manipulativ? Welche verdienen Sichtbarkeit?
Genau deshalb fand ich Heather Physiocs CAMPIXX-Vortrag „From Sources to Signals: Trust is the Next Competitive Layer in AI Search“ so spannend, den mir mein Team freundlicherweise aus Berlin mitgebracht hat. Nicht, weil Trust plötzlich als neues Thema in Search auftaucht. Sondern weil sich durch KI Suchen die Frage verändert, wie Trust ermittelt, verarbeitet und dargestellt werden kann.
Meine Einordnung dazu:
Heather beschreibt eine Richtung, der ich grundsätzlich zustimme. Trust wird in der KI-basierten Suche noch wichtiger werden. Aber aktuelle KI-Suchen sind aus meiner Sicht noch längst nicht so weit, wie ihre Oberfläche manchmal suggeriert. Sie wirken oft wie saubere Synthese und Quellenabwägung. In der Praxis ist vieles noch deutlich primitiver: Retrieval, Ranking, Mustererkennung, Zusammenfassung, sprachliche Verdichtung — und am Ende ein Antworttext mit Quellenlinks.
Das ist hilfreich. Aber es ist noch keine echte Quellenkritik.
Von SEO, GEO und AEO zu Discoverability
Ein guter Ausgangspunkt in Heathers Vortrag ist ihre Klammer um die vielen neuen Akronyme der Branche. SEO, GEO, AEO, AIO, GSO, LEO, HEO — am Ende geht es für sie um ein gemeinsames Ziel: Discoverability. Also darum, in digitalen Informationssystemen auffindbar, verständlich, auswählbar und vertrauenswürdig zu sein.
Das ist eine wichtige Rahmung. Denn die Debatte um GEO wird oft so geführt, als hätten wir es mit einer komplett neuen Disziplin zu tun. Tatsächlich ist vieles davon eine Weiterentwicklung von SEO: technische Zugänglichkeit, Relevanz, Autorität, Struktur, Reputation, Entitäten, Content-Qualität und Nutzerwert bleiben relevant.
Google selbst formuliert es ähnlich: Aus Sicht von Google Search gelten SEO-Best-Practices auch für generative AI Features weiter; AI Overviews und AI Mode sind in die bestehenden Search-Ranking- und Qualitätssysteme eingebettet und nutzen Inhalte aus dem Search Index.
GEO ist deshalb nicht das Ende von SEO. GEO ist eher SEO unter neuen Bedingungen: Die Antwortoberfläche verändert sich, die Rolle von Quellen verändert sich, und die operative Einheit verschiebt sich zunehmend von der URL zur Aussage.
Trust war schon immer das Kernproblem von Search
Wenn Heather sagt, „Trust is the next frontier in the AI search battle“, sollte man das nicht so lesen, als sei Trust in der Suche neu. Das wäre historisch falsch.
PageRank war ein früher Trust-Proxy: Wenn viele relevante und selbst vertrauenswürdige Seiten auf eine Seite verweisen, ist das ein Signal für Autorität. Später kamen Qualitäts- und Spam-Systeme hinzu: Panda gegen dünne und massenhaft produzierte Inhalte, Penguin gegen manipulative Linkmuster, E-A-T und später E-E-A-T als Qualitätsrahmen für Expertise, Erfahrung, Autorität und Vertrauenswürdigkeit, Helpful Content gegen SEO-first Content ohne echten Nutzerwert.
Heather zeigt diese Entwicklung selbst in ihrer Präsentation: PageRank, Florida, Content Farms, Caffeine, Panda, Penguin, E-A-T, Helpful Content und E-E-A-T erscheinen dort als historische Reaktionen auf Manipulation, Content-Skalierung, Qualitätsprobleme und Vertrauensdefizite.
Google beschreibt seine Ranking-Systeme bis heute als automatisierte Systeme, die viele Faktoren und Signale über hunderte Milliarden Webseiten und Inhalte auswerten, um relevante und hilfreiche Ergebnisse zu präsentieren. Außerdem betont Google, dass seine Systeme hilfreiche, verlässliche und menschenorientierte Inhalte priorisieren sollen — nicht Inhalte, die primär zur Manipulation von Rankings erstellt wurden.
Trust war also immer da.
Nur: Klassische Suche konnte Trust lange Zeit nicht wirklich auf Claim-Ebene prüfen.
Die alte Suche brauchte Proxys
Das ist der entscheidende Punkt.
Klassische Suchmaschinen konnten sehr gut darin werden, wahrscheinliche Vertrauenswürdigkeit zu modellieren. Aber sie konnten im offenen Web nicht zuverlässig jede einzelne Aussage in jedem Dokument lesen, zerlegen, semantisch verstehen, gegen andere Quellen prüfen, inhaltlich bewerten und sauber einordnen.
Eine starke Marke hatte im klassischen SEO oft Vorteile — nicht zwingend, weil jede einzelne Aussage dieser Marke automatisch richtiger war, sondern weil Marken mehr Reputation zu verlieren haben, häufiger von anderen zitiert werden, stärker in Entitätsgraphen verankert sind und tendenziell weniger aggressiv spammen können, ohne langfristige Kosten zu tragen.
Brands funktionieren in diesem Sinne als Vertrauenspfänder.
Das ist nicht perfekt, aber nachvollziehbar. Wenn eine Suchmaschine eine konkrete Aussage nicht zuverlässig inhaltlich prüfen kann, muss sie stärker fragen: Wer sagt das? Wer verweist darauf? Wie lange existiert diese Quelle? Passt das Thema zur bekannten Expertise? Gibt es Manipulationsmuster? Wirkt die Quelle insgesamt vertrauenswürdig?
Klassisches SEO war deshalb nie nur Keyword-Optimierung. Es war immer auch Arbeit an Vertrauenssignalen — nur eben überwiegend über Proxy-Metriken auf Quellen-, Dokument-, Domain- und Markenebene.
Was durch LLMs theoretisch neu wird
Mit LLMs verändert sich nun der Möglichkeitsraum.
Der entscheidende Unterschied zwischen klassischer Suche und AI Search liegt nicht darin, dass Trust plötzlich wichtig wird. Der Unterschied liegt darin, wo Trust entstehen könnte.
Im klassischen SEO wurde Vertrauen vor allem auf Quellenebene modelliert:
Ist diese Domain vertrauenswürdig?
Ist diese Marke bekannt? Wird nach ihr gesucht?
Ist diese:r Autor:in relevant?
Hat diese Seite Links von vertrauenswürdigen Quellen?
Ist diese Quelle thematisch etabliert?
In der KI Suche kommt theoretisch eine tiefere Ebene hinzu:
Ist diese konkrete Aussage belastbar?
Welche Quelle belegt sie?
Gibt es unabhängige Bestätigung?
Gibt es Widerspruch?
Ist das Fakt, Meinung, Erfahrung, Interpretation oder Marketing?
Welche Perspektive steckt dahinter?
Welche Unsicherheit müsste genannt werden?
Das ist die eigentliche Verschiebung: von Source Trust zu Claim Trust.
Heather beschreibt genau diese Richtung mit ihren Platform Verification Signals. Dazu gehören Atomic Fact-Checking, Entity Cross-Checking und Multi-Source Consensus: Antworten werden in einzelne Fakten zerlegt, Claims gegen externe Evidenz geprüft, Entitäten mit Knowledge Graphs abgeglichen und mehrere Quellen miteinander verglichen.
Das ist aus meiner Sicht der wichtigste Gedanke des Vortrags.
Klassische Suche fragte vor allem: Ist diese Quelle wahrscheinlich vertrauenswürdig? KI Suche könnte zusätzlich fragen: Ist diese konkrete Aussage belastbar?
Aber: Aktuelle KI-Suchen sind noch nicht dort
Und hier kommt meine wichtigste Einschränkung:
Ich glaube nicht, dass aktuelle KI-Suchen diese Vision bereits zuverlässig erfüllen.
Viele AI-Search-Ergebnisse sehen aus wie eine abgewogene Synthese. Sie formulieren flüssig, ordnen scheinbar ein, liefern Quellenlinks und wirken dadurch oft belastbarer, als sie sind. Aber darunter passiert häufig noch etwas deutlich Einfacheres: Suche, Retrieval, Ranking, Zusammenfassung, Mustererkennung und plausible sprachliche Verdichtung.
OpenAI beschreibt ChatGPT Search als Funktion, die Fragen mit aktuellen Webinformationen und Links zu relevanten Quellen beantworten kann. Gleichzeitig unterscheidet OpenAI selbst zwischen Search und Deep Research: Search ist für schnelle Fakten und kurze Zusammenfassungen mit Links gedacht; Deep Research nimmt sich mehr Zeit, liest und analysiert viele Quellen und erstellt ausführlichere dokumentierte Berichte.
Diese Unterscheidung ist wichtig. Eine schnelle KI-Antwort mit Quellenlinks ist nicht automatisch eine gründliche Analyse. Zitation ist nicht Verifikation.
Aktuelle KI-Suchen können Quellen zitieren, ohne sie wirklich tief zu prüfen. Sie können Konsens simulieren, ohne echten Konsens zu belegen. Sie können Meinungen zusammenfassen, ohne Interessenlagen sauber offenzulegen. Sie können Haltungen glätten, ohne Konflikte angemessen darzustellen. Sie können Autorität übernehmen, ohne die konkrete Aussage ausreichend zu validieren.
Das heißt nicht, dass AI Search nutzlos ist. Im Gegenteil. Für viele Low-Stakes-Situationen — Orientierung, Inspiration, erste Recherche, Zusammenfassung großer Informationsmengen — ist das enorm hilfreich. Heather unterscheidet in ihrer Präsentation selbst zwischen Low-Stakes- und High-Stakes-Situationen: Bei hohen Risiken, etwa Gesundheit, wichtigen Kaufentscheidungen oder spezialisierter Forschung, werden Quellenbewertung, Kontext und Vertrauen deutlich kritischer.
Aber genau deshalb sollten wir aktuelle AI Search nicht überschätzen. Sie ist noch nicht die wissenschaftliche Redaktion, als die sie manchmal erscheint.
Trust Gap: Wenn Oberfläche vertrauenswürdiger wirkt als der Prozess
Heather spricht in ihrem Vortrag vom Trust Gap. Besonders spannend finde ich daran: Es geht nicht nur darum, dass KI-Antworten falsch sein können. Es geht darum, dass sie Vertrauen erzeugen können, obwohl die zugrunde liegende Prüfung nicht ausreichend ist.
Die Präsentation nennt dafür mehrere Faktoren: ein „veneer of rigor“ im AI-Design, inkonsistente Unsicherheitsmarkierung, Zitationen selbst dann, wenn Links problematisch sind, hilfreiche Nutzermetriken als Vertrauensanker und Sycophancy, also Antworten, die sich an bestehende Meinungen anpassen und psychologischen Widerstand senken.
Das ist für SEO und GEO zentral.
Denn AI Search verändert nicht nur die Auffindbarkeit von Inhalten. Sie verändert auch die Wahrnehmung von Autorität. Wenn ein System eine Antwort formuliert, wirkt sie anders als eine Liste aus zehn blauen Links. Die Plattform übernimmt mehr Deutungsarbeit. Sie synthetisiert, gewichtet, verkürzt und präsentiert.
Damit wird Trust nicht nur ein Rankingproblem. Trust wird ein Begründungsproblem.
Drei Ebenen von Trust: Source, Claim, Stance
Für die operative Einordnung hilft mir ein dreistufiges Modell.
1. Source Trust: Wer spricht?
Das ist die klassische SEO-Ebene. Hier geht es um Autorität, Marke, Reputation, Backlinks, Erwähnungen, Autorprofile, Domainhistorie, redaktionelle Standards, technische Qualität und thematische Expertise.
Diese Ebene bleibt wichtig. Ohne Source Trust kommt ein Inhalt oft gar nicht in den relevanten Auswahlraum. Auch AI Search baut nicht im luftleeren Raum, sondern greift auf indexierte, auffindbare, strukturierte und bereits bewertete Quellen zurück.
2. Claim Trust: Was wird behauptet?
Das ist die neue GEO-Ebene. Hier geht es um die konkrete Aussage: Ist sie belegt? Ist sie aktuell? Ist sie präzise? Gibt es Primärquellen? Gibt es Daten? Gibt es unabhängige Bestätigung? Gibt es Widerspruch? Ist die Aussage überzogen oder sauber eingeschränkt?
Hier liegt das große Potenzial von LLM-basierter Suche. Nicht nur Quellen zu finden, sondern Aussagen zu prüfen. Aber genau hier liegt auch die größte Diskrepanz zwischen Vision und Realität. Denn heutige Systeme können Claims zwar extrahieren und vergleichen, aber sie tun das noch nicht durchgängig so sauber, wie gute Journalistinnen, Wissenschaftler oder Fachredaktionen es tun würden.
3. Stance Trust: Aus welcher Perspektive wird gesprochen?
Das ist die unterschätzte Ebene. Nicht jede Aussage ist ein Fakt. Viele Aussagen sind Meinungen, Empfehlungen, Bewertungen, Haltungen oder interessengeleitete Interpretationen. Gerade im Marketing, in Produktvergleichen, in politischen Debatten, in Wissenschaftskommunikation oder bei YMYL-Themen ist entscheidend, aus welcher Perspektive gesprochen wird.
Ist es ein Anbieter? Ein Affiliate? Eine unabhängige Redaktion? Ein:e Betroffen:e? Ein:e Wissenschaftler:in? Eine Lobbyorganisation? Ein Wettbewerber? Eine Marke mit Verkaufsinteresse?
Gute AI Search müsste künftig besser zwischen Fakt, Erfahrung, Meinung, Haltung und Marketing unterscheiden. Aktuelle Systeme sind darin aber noch begrenzt. Sie können Perspektiven sprachlich erkennen, aber nicht zuverlässig und konsistent epistemisch gewichten.
Was Marketer von Journalismus und Wissenschaft lernen können
Einer der stärksten Teile in Heathers Vortrag ist der Rückgriff auf Journalismus und Wissenschaft. Beide Disziplinen haben unterschiedliche Geschwindigkeiten und Arbeitsweisen, aber sie teilen zentrale Prinzipien: Genauigkeit, Evidenz, Skepsis, Transparenz, klare Narrative, Fact-Checking und Vertrauen als Währung.
Heather übersetzt daraus ein Trust-Toolkit für Marketer: Attribution, Paper Trails, Datenprüfung, mehrere unabhängige Quellen, Bewertung von Interessen, Motiven und professionellen Qualifikationen, Rückverfolgung von Claims, Zitaten und Bildern zum Originalkontext sowie Abgleich mit bereits bestätigten Fakten.
Das ist aus meiner Sicht kein nettes Qualitätsideal, sondern eine operative Notwendigkeit.
Denn wenn AI Search künftig stärker auf Claim-Ebene arbeiten soll, müssen Inhalte so gebaut sein, dass Claims überhaupt prüfbar sind. Ein Inhalt ohne Quellen, ohne Autorenschaft, ohne Methode, ohne Datentransparenz, ohne Aktualitätsangabe und ohne klare Unterscheidung zwischen Fakt und Meinung ist für Menschen schwerer zu bewerten — und für Maschinen leichter falsch zu verdichten.
Was das operativ für SEO und GEO bedeutet
Die Konsequenz ist nicht: Klassisches SEO ist tot. Die Konsequenz ist: Klassisches SEO bekommt eine tiefere Belegebene.
Technisches SEO, Indexierbarkeit, interne Verlinkung, strukturierte Daten, Performance, Snippet-Fähigkeit, Markenaufbau, PR, Backlinks und Autorität bleiben relevant. Für Googles generative AI Features müssen Seiten weiterhin indexiert und für Snippets geeignet sein; spezielle neue Dateien oder Markups wie LLMS.txt sind laut Google für die Sichtbarkeit in Google Search nicht erforderlich.
Aber darüber hinaus müssen SEO- und GEO-Teams anders arbeiten. Sie müssen nicht nur Inhalte produzieren, sondern Aussagen operationalisieren.
Claim Audits statt nur Keyword Audits
Die operative Einheit wird nicht nur die URL, sondern der Claim.
Welche Aussagen machen wir?
Welche sind belegt?
Welche sind veraltet?
Welche sind riskant?
Welche sind Meinung, welche Fakt, welche Interpretation?
Welche könnten von AI-Systemen falsch zusammengefasst werden?
Welche Aussagen sind zu allgemein, zu absolut oder zu werblich?
Ein Claim Audit wird damit zu einem zentralen GEO-Werkzeug.
Evidence Layer statt bloßer Quellenliste
Es reicht nicht, am Ende ein paar Links anzuhängen!
Eine Evidence Layer zeigt: Woher kommt eine Aussage? Was ist die Primärquelle? Welche Methode liegt zugrunde? Wann wurde geprüft? Welche Einschränkungen gelten? Wer hat die Aussage fachlich verantwortet? Gibt es Gegenpositionen?
Das macht Inhalte nicht nur vertrauenswürdiger. Es macht sie auch leichter extrahierbar, zitierbar und prüfbar.
Originalität statt Commodity Content
Wenn AI-Systeme vorhandenes Wissen gut zusammenfassen können, verlieren austauschbare Zusammenfassungen an Wert.
Sichtbarkeit entsteht dann nicht durch mehr Content, sondern durch mehr Substanz: eigene Daten, Tests, Benchmarks, Interviews, Produktwissen, Fallstudien, Expertenkommentare, echte Erfahrung und originäre Perspektiven.
Heather nennt in ihren Selection Signals genau diese Punkte: sichtbare Bylines, Autorinformationen, transparente Quellen, Originalität, First-Hand-Perspektive, Original Research, Human Oversight und Abgrenzung von massenhaft produziertem AI-Slop.
Gerade bei Bewertungen, Empfehlungen und Meinungsinhalten sollte klar sein, aus welcher Perspektive gesprochen wird.
Anbietercontent darf Anbietercontent sein. Ein Erfahrungsbericht darf subjektiv sein. Eine fachliche Einschätzung darf eine Haltung haben. Problematisch wird es, wenn Marketing wie unabhängige Forschung wirkt oder Meinung als Fakt präsentiert wird.
Für AI Search ist diese Unterscheidung entscheidend, weil Systeme sonst scheinbar neutrale Synthesen aus interessengeleiteten Quellen bauen.
Corroboration Building statt manipulativem Linkbuilding
Externe Bestätigung bleibt wichtig. Aber sie sollte nicht als Fake-Konsens verstanden werden.
In einer AI-Search-Welt geht es weniger darum, einzelne Links aufzubauen, und stärker darum, im relevanten Themenraum glaubwürdig bestätigt zu werden: durch Fachmedien, Studien, Partner, unabhängige Reviews, Branchenverzeichnisse, Expertenzitate, Community-Signale und nachvollziehbare Erwähnungen.
Heather warnt selbst vor der nächsten Manipulationswelle: AI-generierte Forenbeiträge, Fake-Reddit-Threads, künstliche positive Brand Mentions, umgeschriebener Wettbewerbercontent, synthetische Sites und Fake-Personas.
Das ist der Schatten der neuen Trust-Logik: Wo Systeme Konsens, Entitäten und semantische Nähe auswerten, entstehen Anreize, genau diese Signale künstlich zu erzeugen.
Die geschärfte These
Die beste Weiterentwicklung von Heathers Impuls lautet für mich:
Trust war immer die Währung von Search. Neu ist, dass AI Search diese Währung potenziell feiner auflösen kann: von der Quelle zur Aussage, von Autorität zu Evidenz, von Ranking zu Begründung.
Aber dieses Potenzial ist noch nicht vollständig Realität.
Aktuelle KI-Suchen sind oft noch gröber, als sie wirken. Sie fassen zusammen, verdichten, zitieren und plausibilisieren — aber sie prüfen noch nicht durchgängig wie gute Redaktionen oder wissenschaftliche Review-Prozesse.
Genau deshalb ist jetzt der richtige Zeitpunkt, Trust operativ aufzubauen.
Nicht als kosmetisches E-E-A-T-Label. Nicht als GEO-Hack. Nicht als Checkliste künstlicher Signale.
Sondern als Infrastruktur:
klare Autorenschaft,
nachvollziehbare Quellen,
belastbare Claims,
konsistente Entitäten,
eigene Daten,
transparente Methoden,
redaktionelle Verantwortung,
externe Bestätigung,
klare Trennung von Fakt, Meinung und Marketing.
Fazit: Von vertrauenswürdigen Quellen zu begründbaren Aussagen
Heather Physiocs Vortrag ist stark, weil er AI Search als Vertrauensproblem beschreibt. Ich würde ihn aber bewusst historisch einordnen: Trust ist kein neues Thema in Search. Google versucht seit Jahrzehnten, vertrauenswürdige Quellen von weniger vertrauenswürdigen Quellen zu trennen.
Neu ist der Anspruch, dass AI Search nicht nur Quellen auswählen, sondern Aussagen synthetisieren und begründen muss.
Früher musste Google vor allem vertrauenswürdige Quellen erkennen. Künftig müssen AI-Systeme vertrauenswürdige Aussagen begründen können.
Und genau darauf muss moderne SEO-/GEO-Arbeit vorbereiten.
Wir optimieren also nicht nur für das, was AI Search heute schon kann. Wir bauen die Infrastruktur für das, was AI Search können muss, wenn sie langfristig nützlich und vertrauenswürdig sein will.
Die nächste Reifestufe von SEO besteht deshalb nicht darin, Trust-Signale künstlich nachzubauen. Sie besteht darin, echte Vertrauenswürdigkeit maschinenlesbar, überprüfbar und zitierfähig zu machen.
Oder zugespitzt:
Trust war nie neu. Neu ist der Wechsel von Trust-Proxys auf Quellenebene zu potenzieller Claim-Prüfung auf Aussageebene. Und genau dort beginnt die eigentliche Arbeit von GEO.
Update 2026: Pangram – der KI-Detektor, der angeblich „wirklich funktioniert“?
Nachdem ich diesen Artikel ursprünglich veröffentlicht hatte, tauchte mit Pangram ein weiterer KI-Textdetektor auf, der deutlich selbstbewusster auftritt als viele der bisherigen Tools. Pangram wirbt aktuell damit, KI-generierte Inhalte mit „99,98% accuracy“ erkennen zu können und verweist dabei auf Drittstudien der University of Chicago und der University of Maryland. Zusätzlich behauptet das Unternehmen eine False-Positive-Rate von „1 in 10.000“, berechnet auf aggregierten öffentlichen Datensätzen mit mehreren Millionen Dokumenten.
Das klingt zunächst nach genau dem Durchbruch, auf den viele warten: Endlich ein Tool, das zuverlässig zwischen menschlichen und KI-generierten Texten unterscheiden kann. Allerdings lohnt sich auch hier der zweite Blick.
Die von Pangram angeführte Studie der University of Chicago ist durchaus interessant. Die Forscher testeten vier Detektoren – Pangram, GPTZero, OriginalityAI und RoBERTa – auf 1.992 menschlichen Textpassagen aus der Zeit vor 2020 und jeweils passenden KI-generierten Texten. Die Texte stammen aus Genres wie News, Blogs, Reviews, Romanpassagen und Résumés; die KI-Texte wurden unter anderem mit GPT‑4.1, Claude Opus 4, Claude Sonnet 4 und Gemini 2.0 Flash erzeugt. Pangram schneidet in dieser Untersuchung tatsächlich sehr gut ab, insbesondere bei mittleren und längeren englischen Texten. Gleichzeitig betonen die Autoren aber selbst, dass False Positive Rate und False Negative Rate vom gewählten Schwellenwert abhängen und dass die Leistung solcher Detektoren Teil eines technischen Wettrüstens zwischen Detektoren, neuen LLMs, Humanizern und Nutzerstrategien bleibt.
Genau hier liegt der entscheidende Punkt: „Accuracy“ ist nicht gleich Praxistauglichkeit. Eine einzelne Prozentzahl sagt wenig aus, solange nicht klar ist, auf welchem Datensatz, in welcher Sprache, bei welcher Textlänge, mit welchem Schwellenwert und mit welcher Definition von „KI-generiert“ getestet wurde. Ein Tool kann in einem Benchmark nahezu perfekt abschneiden und trotzdem in meinem konkreten Anwendungsfall jede Menge False Positives oder False Negatives liefern.
Noch deutlicher wird das bei der ebenfalls von Pangram zitierten Studie der University of Maryland. Dort wurden 300 englische Non-Fiction-Artikel untersucht. Pangram gehört in dieser Studie zwar zu den stärksten automatischen Detektoren, aber die Tabelle berichtet True Positive Rate und False Positive Rate – nicht einfach eine allgemeine „Accuracy“. Für Pangram stehen dort insgesamt 98,0% TPR bei 2,0% FPR; für „Pangram Humanizers“ 99,3% TPR bei 2,7% FPR. Das ist stark, aber es ist eben nicht dasselbe wie „99,98% fehlerfrei“.
Pangram selbst macht das Problem in seiner neueren Produktkommunikation sogar sichtbar. Seit Pangram 3.0 unterscheidet das Tool nicht mehr nur zwischen „Human“ und „AI“, sondern zwischen „Fully human-written“, „Lightly AI-assisted“, „Moderately AI-assisted“ und „Fully AI-generated“. Laut Pangram gelten Rechtschreibkorrektur, Übersetzung oder Lesbarkeitsänderungen bereits als „Light AI assistance“, während umfangreichere Umformulierungen oder Strukturänderungen als „Moderate AI assistance“ klassifiziert werden können. Pangram schreibt selbst, dass Co-Autorschaft ein Spektrum sei und dass die Grenze zwischen diesen Kategorien eher eine interpretative als eine harte wissenschaftliche Trennlinie ist.
Das ist aus meiner Sicht ein wichtiger Fortschritt, weil es der Realität näherkommt: Die meisten Texte entstehen heute nicht mehr sauber binär als „100% Mensch“ oder „100% KI“. Viele Texte werden recherchiert, skizziert, geglättet, übersetzt, umgeschrieben, erweitert oder redigiert – teilweise mit KI, teilweise ohne. Aber gerade dadurch wird die Behauptung einer fast absoluten Erkennungsgenauigkeit noch schwieriger.
Auch Pangrams eigene Model Card zu Version 3.3 ist hier aufschlussreich. Dort steht ausdrücklich, dass das Modell für längere Texte in vollständigen Sätzen gedacht ist. Bullet-Point-Listen, technische Anleitungen, Tabellen, Vorlagen, Inhaltsverzeichnisse, Referenzabschnitte und dichte mathematische Texte seien anfälliger für False Positives. Pangram warnt außerdem selbst, dass falsche Anschuldigungen ernste Folgen haben können und dass das Modell eine nicht-null Fehlerrate hat.
Bei meinen eigenen Stichproben zeigt sich genau diese praktische Unsicherheit. Ein deutschsprachiger Textabschnitt wurde von Pangram 3.3.2 beispielsweise als „100% Human Written“ eingestuft – gleichzeitig zeigt die Oberfläche aber „Confidence Low“. Das ist bemerkenswert: Für Nutzer sieht „100% Human“ zunächst absolut aus, die eigentliche Modellunsicherheit steht jedoch klein daneben. Genau diese Art der Darstellung ist problematisch, weil sie eine Sicherheit suggeriert, die das System selbst offenbar nicht hat.
Aus wissenschaftlicher Sicht ist Pangram also nicht einfach in dieselbe Schublade zu stecken wie manche älteren, offensichtlich schlechten Detektoren. Das Tool scheint in mehreren Benchmarks deutlich besser abzuschneiden als GPTZero, Copyleaks oder einfache Perplexity-basierte Ansätze. Aber die zentrale Kritik bleibt bestehen: Eine Benchmark-Zahl ist kein Beweis für einen konkreten Text. Sie sagt nur, wie gut ein Modell unter bestimmten Testbedingungen funktioniert hat.
In der Praxis zählt nicht die werbliche „Accuracy“, sondern die Frage: Wie viele fälschlich beschuldigte menschliche Texte und wie viele nicht erkannte KI-Texte produziert das Tool in genau meinem Einsatzszenario? Bei einer Schule, Universität, Redaktion oder SEO-Agentur ist das Entscheidende nicht, ob ein Anbieter „99,98%“ auf einer aggregierten Testmenge erreicht, sondern wie viele echte Texte aus dem eigenen Umfeld falsch klassifiziert werden.
Selbst sehr niedrige Fehlerraten können bei großem Einsatz problematisch werden. Eine False-Positive-Rate von 0,01% klingt verschwindend gering, bedeutet aber bei einer Million geprüfter menschlicher Texte immer noch rund 100 fälschlich verdächtigte Texte. Bei höheren False-Positive-Raten, wie sie in einzelnen Genres oder unabhängigen Tests durchaus auftreten, wird das Problem entsprechend größer. Besonders gefährlich wird es, wenn positive Treffer als Beweis statt als Anlass für eine genauere Prüfung behandelt werden.
Mein Zwischenfazit zu Pangram lautet daher: Pangram ist wahrscheinlich einer der aktuell stärkeren KI-Textdetektoren. Aber auch Pangram liefert keine forensische Sicherheit. Wer solche Tools einsetzt, sollte sie höchstens als Triage-Signal verstehen, nicht als Beweismittel. Ein „AI detected“-Flag darf niemals allein Grundlage für Sanktionen, Ablehnung, schlechte Noten oder Vorwürfe sein.
Hier der ursprüngliche Beitrag:
Als ich Anfang 2023 mein Buch über ChatGPT & Co. geschrieben habe, habe ich mich auch damit auseinander gesetzt, ob Suchmaschinen wie Google oder Lehrkräfte an Schulen und Hochschulen zuverlässig erkennen können, ob ein Text vollständig oder teilweise von einer generativen KI geschrieben wurde.
GPTZero, eine der ersten Ansätze, die mir in meiner Recherche aufgefallen sind, war zum damaligen Zeitpunkt noch nicht öffentlich verfügbar, also habe ich mich mit den theoretischen Hintergründen und dem aktuellen Stand der KI-Forschung beschäftigt und mir die Frage gestellt, ob es überhaupt möglich sein kann und ob sich der Aufwand einer AI-Content-Erkennung, beispielsweise für Suchmaschinen überhaupt lohnt:
Lassen sich KI-generierte Texte erkennen?
In meinem Buch schrieb ich damals:
Die rasanten Fortschritte in letzter Zeit führen dazu, dass immer mehr Texte von Sprachmodellen generiert werden und in den unterschiedlichsten Bereichen eingesetzt werden. Da drängt sich die wichtige Frage auf, ob man solche Texte automatisch erkennen kann? Nach derzeitigen Erkenntnissen scheint dieser Kampf jedoch eine Sisyphos-Aufgabe zu sein, denn KI-Detektoren stehen vor großen Herausforderungen: Ein Team von Forschern der Universität von Maryland [1] fand heraus, dass selbst die besten Detektoren, keine absolute Sicherheit bieten können.
So können bereits einfache Umformulierungen oder kleinere Änderungen an den generierten Texten die Detektoren täuschen. Selbst die besten Detektoren schneiden kaum besser ab als ein rein zufälliger Klassifikator. Man könnte also genauso gut eine Münze werfen und sich auf diese Weise entscheiden, ob ein Text KI-generiert ist oder nicht.
OpenAI arbeitet derzeit zwar an einem Tool, das die Ausgaben eines Text-KI-Systems mit unsichtbaren Wasserzeichen versieht [2], doch auch hier gibt es Schwachstellen: Die Forscher meinen, dass Menschen in der Lage sein könnten, die Wasserzeichen zu entschlüsseln und sie in andere, nicht von einer KI geschriebene Texte einzufügen. Dadurch würden die Erkennungsmechanismen ad absurdum geführt.
Es ist offensichtlich, dass eine verlässliche und einfache Lösung für das Erkennen von KI-generierten Texten derzeit nicht in Sicht ist. Die ethische und verantwortungsvolle Nutzung von solchen Texten sollte dennoch oberste Priorität haben.
Für mich persönlich spielt es keine Rolle, ob ein Text von einer KI oder einem Menschen geschrieben wurde. Entweder es ist ein guter Text oder es ist kein guter Text. So sieht es auch aus Sicht der Suchmaschine aus. Entweder es ist Spam oder es ist kein Spam. Menschengeschriebener Spam ist genauso schlecht für die Qualität der Suchergebnisse wie KI-geschriebener Spam. Und ein richtig guter Artikel, der von der KI geschrieben wurde, ist genauso gut, wie wenn ihn ein Mensch geschrieben hätte.
Falls du dich also fragst, ob deine KI-generierten Texte in den Suchmaschinen gefunden werden, solltest du die Inhalte auf faktische Korrektheit überprüfen und dafür sorgen, dass deine Inhalte einen echten Nutzen für den Besucher bieten und ein Informationsbedürfnis erfüllen. Dann werden diese auch nicht abgestraft – warum sollten sie?
[1] Vinu Sankar Sadasivan, Aounon Kumar, Sriram Balasubramanian, Wenxiao Wang, Soheil Feizi: „Can AI-Generated Text be Reliably Detected?“, arXiv Pre-Print, abgerufen am 05.04.23, online abrufbar unter: https://kai.im/ai-text-detection [2] Kyle Wiggers: „OpenAI’s attempts to watermark AI text hit limits“, Techcrunch, abgerufen am 14.02.23, online verfügbar unter: https://kai.im/openai-watermark
Was ist seit dem passiert?
Seit dem Erscheinen meines Buches hat OpenAI seinen AI Classifier bereits Mangels Treffsicherheit zurück gezogen. Das Programm sollte KI-erzeugte Texte erkennen. Das klappte jedoch nicht zuverlässig genug: „Der AI Classifier ist nicht mehr verfügbar aufgrund seiner geringen Genauigkeit“, gesteht OpenAI ein.
Daher hatte ich für mich mit dem Thema abgeschlossen und als nicht weiter interessant betrachtet. Doch mich hat ein Kollege darauf aufmerksam gemacht, dass offenbar immer häufiger Texte von Vorgesetzten oder Kunden abgelehnt werden, weil diese angeblich mittels künstlicher Intelligenz geschrieben wurden und große Sorge darüber besteht, dass man hierfür womöglich rechtliche Konsequenzen oder gar eine Abstrafung seitens der Suchmaschinen befürchten müsste.
In den Fachabteilungen macht man sich offenbar Gedanken darüber, wie man verhindern kann, dass die eigenen Inhalte als KI-generiert erkannt werden – Was mich an die Bemühungen erinnert, gekaufte Links oder ganze Linkprofile als möglichst „organisch“ erscheinen zu lassen.
Als Beispiel für ein derartiges Tool, das KI-Texte erkennen soll, wurde mir copyleaks genannt. Das musste ich mir also umgehend ansehen, immerhin bezeichnet sich das Unternehmen selbst als die „einzige Enterprise KI-Erkennungslösung“ und verspricht:
Von der Sicherstellung der Cyber-Compliance bis zur Verhinderung von Urheberrechtsverletzungen ist es entscheidend zu wissen, welche Inhalte von Menschen erstellt wurden und welche von KI. Mit einer Genauigkeit von 99,1 % und einer vollständigen Modellabdeckung, einschließlich GPT-4 und Bard, ist der Copyleaks AI Content Detector die umfassendste und genaueste Lösung auf dem Markt.
Auszug aus der Webseite von copyleaks
Man sei dabei die einzige Plattform, die KI-Inhalte in mehreren Sprachen erkennt, eine genaue Wahrscheinlichkeitsbewertung von KI-Inhalten liefert und sogar die spezifischen Teile eines Textes hervorhebt, die von einem Menschen geschrieben wurden, und die, die von KI geschrieben wurden. Ja sogar umgeschriebene Inhalte will man erkennen können!
Wow, das klingt beeindruckend. Und sieht auf den ersten Blick auch irgendwie überzeugend aus, immerhin vertrauen „führende Organisationen und Institutionen“ offenbar auf copyleaks:
Doch auf den zweiten Blick werde ich hier stutzig: Wieso werden hier nur unbedeutende Colleges und Universitäten aufgeführt und keine aus der Ivy League?
Der erste WTF-Moment kam mir direkt im nächsten Abschnitt der Webseite:
Man arbeit seit fast einem Jahrzehnt an der KI-Erkennungslösung!
Seit 2015 lernt die Copyleaks-KI-Engine, wie Menschen schreiben, indem sie Billionen von Seiten aus verschiedenen Quellen sammelt und analysiert, darunter: Arbeiten von Tausenden von Institutionen und Millionen von Schülern aus Bildungsinstitutionen sowie Marketinginhalte, Whitepaper und Forschungsarbeiten aus über 300 Unternehmen.
Auszug aus der Webseite von copyleaks
Wer die Entwicklung von generativer KI über die letzten 10 Jahre verfolgt hat weiß, dass das entscheidende Paper „Attention Is All You Need“ jedoch erst 2017 von Google-Forschern veröffentlich wurde und alle Modelle vor GPT-2 weit entfernt davon waren, Texte zu schreiben, die man für menschengeschrieben halten könnte.
Ich finde es extrem problematisch, wenn der Eindruck erweckt wird, man könnte KI-Texte zuverlässig erkennen. Eines der Hauptprodukte von copyleaks ist immerhin die Bewertung von Aufsätzen und studentischen Arbeiten für Bildungseinrichtungen und da will ich mir garnicht vorstellen, was es bedeutet, wenn jemand wegen einer fehlerhaften Erkennung Probleme mit der Prüfungskommission bekommen könnte. Erste Berichte über falsche Anschuldigungen machten bereits die Runde.
copyleaks behauptet auf seiner Webseite selbstbewusst:
Wir haben mehr als 20.000 von Menschen verfasste Beiträge getestet und die Rate der Falschmeldungen lag bei 0,2 % – die niedrigste Falschmeldungsrate aller Plattformen. Außerdem testen wir unser KI-Modell ständig und trainieren es mit neuen Daten und Feedback, um die Genauigkeit zu verbessern.
Damit müsse „niemand Angst vor falschen Positivmeldungen haben, die zu falschen Anschuldigungen führen können“.
Doch ist das wirklich so?
Ansätze für die Erkennung und deren Grenzen
Die Fähigkeit, Texte zu erkennen, die von Künstlicher Intelligenz (KI), insbesondere von großen Sprachmodellen (LLMs), generiert wurden, ist ein sich schnell entwickelndes Forschungsgebiet mit weitreichenden Implikationen für Bereiche wie Cybersicherheit und akademische Integrität. Mit der zunehmenden Verfeinerung der LLMs wird die Unterscheidung zwischen von Menschen verfassten und von KI generierten Inhalten jedoch immer schwieriger.
Dennoch existieren zahlreiche Ansätze, die zum Teil weit entwickelt und ständig verfeinert werden. Diese lassen sich in technische und stilometrische Methoden unterteilen, um unterschiedliche Aspekte der Textgenerierung und -modellierung zu nutzen.
Die Erkennung KI-generierter Texte in Zeiten großer Sprachmodelle stellt jedoch eine zunehmende Herausforderung dar, bei der die Praktikabilität und Zuverlässigkeit der verschiedenen Ansätze kritisch betrachtet werden muss. Jede Methode hat ihre spezifischen Einschränkungen, die ihre Effektivität und Anwendbarkeit in realen Szenarien beeinflussen können.
Technische Ansätze
Maschinenlern-Klassifikatoren
Durch das Training von Maschinenlernmodellen mit großen Datensätzen von von Menschen geschriebenen und KI-generierten Texten können Forscher:innen Klassifikatoren entwickeln, die den Ursprung eines neuen Textes vorhersagen. Merkmale, die von diesen Modellen verwendet werden, können Textkohärenz, Komplexität, die Verwendung bestimmter Phrasen oder syntaktische Muster umfassen, die in KI-generierten Texten häufiger vorkommen.
Probleme dabei:
Das Training effektiver Klassifikatoren erfordert umfangreiche und vielfältige Datensätze, die sowohl von Menschen geschriebene als auch KI-generierte Texte umfassen. Die Beschaffung und Aufrechterhaltung dieser Datensätze ist ressourcenintensiv.
Klassifikatoren können durch die schnelle Evolution der KI-Modelle schnell veralten. Zudem besteht die Gefahr, dass sie durch innovative Textgenerierungsmethoden, die bestehende Erkennungsmuster umgehen, getäuscht werden.
Statistische Mustererkennung
KI-generierte Texte können statistische Anomalien aufweisen oder die Variabilität vermissen lassen, die in von Menschen geschriebenen Texten zu finden ist. Techniken wie die Analyse von N-Gramm-Häufigkeiten, Variationen der Satzlänge und andere statistische Merkmale können genutzt werden, um Muster zu identifizieren, die charakteristisch für KI-generierte Inhalte sind.
Das Problem dabei: Große Sprachmodelle werden darauf trainiert, menschliche Variabilität in Texten zu imitieren, wodurch die Unterscheidungskraft statistischer Muster verringert wird.
Wasserzeichen
Einige Forscher erkunden die Möglichkeit, Wasserzeichen in die Ausgaben von LLMs einzubetten. Diese Wasserzeichen, die subtile Muster in der Wortwahl oder Satzstruktur sein könnten, würden die Lesbarkeit des Textes nicht beeinträchtigen, könnten jedoch von spezialisierten Algorithmen erkannt werden. Die Implementierung von derartigen Wasserzeichen erfordert grundsätzlich Zugriff auf den Entwicklungsprozess der Modelle, was bei proprietären Systemen nicht immer möglich ist.
Das Hauptproblem: Wasserzeichen können umgangen, entfernt oder sogar in menschliche Texte eingebaut werden, sobald die Methoden ihrer Einbettung bekannt sind.
Stilometrische Ansätze
Konsistenz- und Kohärenzanalyse
KI-generierte Texte, insbesondere längere, können Schwierigkeiten haben, thematische oder faktische Konsistenz aufrechtzuerhalten. Eine Analyse eines Textes auf wiederholte oder widersprüchliche Informationen kann ein Indikator für eine KI-Autorschaft sein.
Die Durchführung einer gründlichen Konsistenzprüfung erfordert fortschrittliche Analysetools und kann bei längeren Texten herausfordernd sein. Neuere KI-Modelle verbessern ständig ihre Fähigkeit, kohärente und thematisch konsistente Texte zu generieren, was die Wirksamkeit dieser Methode in den letzten Jahren stark eingeschränkt hat.
Stilistisches Fingerprinting
Jeder Autor hat einen einzigartigen Schreibstil, einschließlich Vorlieben für bestimmte Phrasen, Interpunktion und Struktur. Durch den Vergleich des stilistischen Fingerabdrucks eines Textes mit bekannten menschlichen und KI-Fingerabdrücken ist es möglich, eine fundierte Vermutung über dessen Ursprung anzustellen.
Dieser Ansatz benötigt umfangreiche Vergleichsdatenbanken mit menschlichen und KI-Stilen, deren Aufbau und Pflege aufwendig sein kann. Außerdem können KI-Systeme, die auf die Nachahmung spezifischer Schreibstile trainiert sind, stilistische Fingerabdrücke effektiv imitieren, was die Zuordnung erschwert.
Was sagt die Fachwelt dazu?
Im Dezember 2023 trafen sich auf der Neurips-Konferenz in New Orleans führende KI-Forscher, um über das brandaktuelle Thema der Erkennung von Deep-Fakes und anderen KI-generierten Betrügereien zu diskutieren. Die Konferenz beleuchtete die Bemühungen von Unternehmen wie Intel und Microsoft, die mittels spezieller Software solche Täuschungen aufspüren wollen. Parallel dazu wird an Techniken gearbeitet, um echte Bilder, Videos und Texte durch „Wasserzeichen“ von KI-generierten Medien zu unterscheiden.
Eine Umfrage des Economist unter Konferenzteilnehmern zeigte jedoch eine skeptische Stimmung: 17 von 23 Befragten glauben nicht an die langfristige Erkennbarkeit KI-generierter Medien. Nur ein Einziger äußerte Optimismus bezüglich zuverlässiger Erkennungsmethoden.
Die derzeitige Erkennungssoftware basiert auf der Annahme, dass KI-Modelle erkennbare Spuren hinterlassen. Früher konnten Menschen solche Fehler leichter erkennen, wie z.B. missgebildete Hände in Bildern. Heute jedoch werden diese Unzulänglichkeiten immer seltener, und die Software muss subtilere Merkmale identifizieren.
Die Erkennungstechnik ist jedoch nicht fehlerfrei und neigt zu falsch-positiven sowie falsch-negativen Ergebnissen. Studien, wie eine von Zeyu Lu der Shanghai Jiao Tong University, belegen, dass selbst leistungsfähige Programme KI-generierte Bilder nicht immer korrekt identifizieren. Ähnlich unbefriedigend sind die Ergebnisse bei Texterkennung.
Eine alternative Methode ist das Einbetten digitaler Wasserzeichen in KI-generierte Medien. Diese Technik, vorgeschlagen von Forscherteams der University of Maryland und der University of California, Santa Barbara, nutzt subtile Unterscheidungsmerkmale, die jedoch offensichtlich werden, wenn man danach sucht. Eine weitere Methode, das „Tree-Ring“-Wasserzeichen, wird während der Erstellung des digitalen Bildes angewendet, um die Erkennung auch nach Bearbeitung des Bildes zu ermöglichen.
Trotz dieser Innovationen bleibt die Frage der Effektivität offen. Forscher der Harvard University und der University of Maryland haben bereits Methoden entwickelt, um solche Wasserzeichen zu entfernen oder zu umgehen.
Die amerikanische Regierung hat im Juli 2023 „freiwillige Verpflichtungen“ mit mehreren KI-Firmen, darunter OpenAI und Google, angekündigt, um die Forschung in diesem Bereich zu fördern. Dies zeigt, dass auch unvollkommene Schutzmechanismen als besser angesehen werden als gar keine. Dennoch scheint es, als hätten die Fälscher aktuell die Oberhand im Kampf gegen die Detektive.
Einblicke in aktuelle KI-Forschung
Mittlerweile beschäftigt sich neues Gebiet der Forschung mit Fragen wie „Lassen sich KI-Texte zuverlässig erkennen?“. In den letzten Monaten wurden dazu sehr interessante Paper veröffentlicht.
KI-Firmen aber auch KI-Forscher haben verschiedene Methoden entwickelt, um KI-Texte zu identifizieren. Manche fügen beispielsweise unsichtbare Wasserzeichen in die Texte ein. Andere analysieren statistische Eigenschaften wie die Zufälligkeit der Wörter. Wieder andere vergleichen neue Texte mit bereits bekannten KI-Texten. Diese Detektoren erreichen teilweise schon beeindruckende Erkennungsraten.
Doch neue Studien zeigen auch ihre Grenzen auf. Oft reicht es aus, wenn man KI-Texte mit einem einfachen Programm umschreibt. Dann fallen die Wasserzeichen und statistischen Marker weg und die Detektoren versagen. Selbst wenn man KI-Texte in einer Datenbank speichert und neue Texte mit diesen vergleicht, können geschickte Umschreibungen die Erkennung austricksen.
Noch grundlegender ist das theoretische Limit, das Forscher errechnet haben: Wenn KI-Systeme immer menschlicher schreiben, werden auch die besten Detektoren irgendwann ratlos. Derzeit kommen die besten Detektoren im Labor auf eine Erkennungsrate von über 90 Prozent. Aber schon bei einer Fehlerrate von nur 10 Prozent wären in der Praxis unzählige Texte falsch eingeschätzt.
Zudem zeigte sich, dass viele Detektoren Texte von Menschen mit schlechten Sprachkenntnissen häufig fälschlicherweise als KI-Text einordnen. Die Systeme sind also nicht nur fehleranfällig, sondern diskriminieren auch bestimmte Gruppen.
Forscher mahnen deshalb, die Fähigkeiten der Detektoren nicht zu überschätzen. Bevor sie in der Praxis eingesetzt werden, müssen sie umfassend getestet werden. Sonst könnten sie mehr Schaden als Nutzen anrichten. Langfristig braucht es wohl neue Ansätze. So könnte man KI-Systeme von vornherein so gestalten, dass ihre Texte nachweisbar von Menschen geschrieben wurden. Vorläufig bleibt es also spannend, ob es künftig gelingt, den stetig verbesserten KI-Textgeneratoren ebenso clevere Detektoren gegenüberzustellen.
Getestet wurden dort die Tools: Check For AI, Compilatio, Content at Scale, Crossplag, DetectGPT, Go Winston, GPT Zero, GPT-2 Output Detector Demo, OpenAI Text Classifier, PlagiarismCheck, TurnItIn, Writeful, GPT Detector, Writer sowie Zero GPT. Copyleaks war zwar nicht Teil dieses Tests, doch die Forscherinnen und Forscher kommen ebenfalls zu dem Schluss, dass die verfügbaren Erkennungswerkzeuge weder genau, noch zuverlässig sind und vor allem dazu neigen, Texte als von Menschen geschrieben zu klassifizieren, anstatt KI-generierten Text zu erkennen.
Wir dürfen hier weitere Veröffentlichungen erwarten, denn die jüngsten Fortschritte bei großen Sprachmodellen und generativer künstlicher Intelligenz haben gerade in der akademischen Welt viele Bedenken hinsichtlich ihrer ethischen Verwendung und der richtigen Bewertungsstrategien aufgeworfen. Das Hauptaugenmerk der akademischen Integritätsgemeinschaft verschiebt sich daher zunehmend von Plagiaten und Unterschleif auf den Einsatz generativer künstlicher Intelligenz. Die ENAI-Arbeitsgruppe beschäftigt sich daher mit dem Testen von Hilfsmitteln zur Plagiatserkennung und erweiterte hierfür ihren Forschungsbereich um die Bereiche Technologie und akademische Integrität.
Können Menschen KI-Text erkennen?
Bei der ganzen Diskussion um die Zuverlässigkeit von Algorithmen, Tools und Machine Learning Modellen zur Erkennung von KI-generierten Texten stellt sich die berechtigte Frage, ob Menschen fähig sind diese zuverlässig zu identifizieren.
Die Studie zeigt auf, dass sowohl unerfahrene als auch erfahrene Lehrkräfte gleichermaßen Schwierigkeiten haben, KI-generierte Texte zu erkennen, was die Frage aufwirft, inwiefern Fachwissen tatsächlich eine Rolle bei der Identifizierung solcher Texte spielt. Besonders bei argumentativen Essays waren die Teilnehmer nicht in der Lage, die Herkunft der Texte korrekt zu bestimmen, was auf eine weitverbreitete Unsicherheit in Bezug auf die Erkennung von KI-generierten Inhalten hindeutet.
Interessanterweise zeigte sich, dass erfahrene Lehrkräfte zwar etwas erfolgreicher in der Identifizierung von Texten hoher Qualität waren, dennoch Probleme mit der Erkennung von minderwertigen KI-Texten hatten.
Dies unterstreicht die Komplexität der Thematik und die Notwendigkeit einer umfassenden Auseinandersetzung mit den Möglichkeiten künstlicher Intelligenz im Bildungssektor. Insbesondere betont dies auch die Notwendigkeit, Bewertungspraktiken neu zu überdenken.
KI-Text-Erkennung mit copyleaks im Praxistest
In meinem Test habe ich zunächst einige, zu 100% KI-generierte Texte überprüft, die ich ihm Rahmen eines SEO-Experiments für einen KI-generierten Glossar mittels ChatGPT (GPT-4) erzeugt hatte. Und siehe da, dieser wurde von copyleaks mit 99,9%iger Sicherheit wurde dieser Text als „AI-Inhalt erkannt“:
Den Text habe ich unkenntlich gemacht, da ich mein SEO-Ranking-Experiment nicht verfälschen und die Webseite preisgeben möchte.
Wow, das sieht doch wirklich überzeugend aus. Und auch die nächsten 10 KI-generierten Texte wurden als solche erkannt, jedes mal mit einer Wahrscheinlichkeit über 99%.
Der selbe Text wurde von GPTzero übrigens als „wahrscheinlich komplett von einem Menschen geschrieben“ eingestuft:
Hatte copyleaks also wirklich geschafft, was ich für nicht machbar gehalten habe?
Wenn das Tool KI-Texte so treffsicher klassifziert, wie sieht es dann mit menschengeschriebenen Texten aus?
Ein erster Test mit dem frisch installierten Browser-Plugin von copyleaks sah vielversprechend aus: Einen Text, den ich selbst im Jahr 2016 geschrieben habe, selbstverständlich ohne Unterstützung einer KI, wurde korrekt als „Menschlicher Text“ klassifiziert:
Doch mein Erstaunen legte sich schnell wieder, als ich die nächsten Absätze überprüfte, die ich persönlich, weit vor der Veröffentlichung jeglicher generativer KI geschrieben hatte:
Plötzlich wurde mitten in meinem Text ein großer Absatz als „KI-Content erkannt“ und ein paar Stichproben später betätigte sich mein Verdacht:
Copyleaks lieferte in meinem Kurztest derart viele „False Positives“ (Texte, die als KI-generiert eingestuft werden, es in Wirklichkeit aber garnicht sind), so dass ich niemandem empfehlen kann, sich darauf zu verlassen.
Kai Spriestersbach
Die Wahrscheinlichkeiten, die mir das Tool hierfür angezeigt haben, lagen bei den Fehleinschätzungen zwischen 99,9% und 85,5%, wie in diesem Beispiel:
In meinem – zugegeben relativ kurzen Test – konnte ich zwar keine False Negatives identifizieren, also KI-generierte Texte, die von copyleaks nicht als solche klassifiziert werden, doch bei einer derart hohen Fehlerrate, ist das für den Einsatz des Tools unerheblich.
Tom Tloks KI-Detektor „Made in Germany“
Auch in Deutschland ist man vor Fehlschlüssen und unterkomplexer Betrachtung nicht gefeit, wie Tom Tlok von der Fachhochschule Wedel derzeit beweist:
Der KI-Detektor, der durch einen modifizierten LLM-Ansatz im Rahmen von Tloks Master-Thesis entstanden ist, erkennt mit einer Zuverlässigkeit von 97,89 Prozent, ob ein deutschsprachiger Text mithilfe von Künstlicher Intelligenz erstellt wurde.
Natürlich musste ich diesen direkt testen. Und ja: Bei ein paar Texten scheint es gut zu funktionieren, allerdings dauert es nicht lange, bis man sowohl False Positives, als auch False Negatives erhält:
Diesen Text aus einem meiner Website Boosting Artikel stuft das Tool mit 99,89% korrekt als menschlich geschrieben ein. Sehr vielversprechend…
Und diesen zu 100% mit ChatGPT generierten Text aus einem Experiment stuft das Tool mit 91,88%iger Sicherheit als „KI generiert“ ein. Sehr gut!
Doch bereits bei einem, mittels RAG erstellten Text, ist sich das Tool nicht mehr sicher…
Hier wird nur noch 19,83% KI angezeigt, obwohl der Output 1:1 aus ChatGPT stammt!
Und mit ein bisschen ausprobieren konnte ich sogar für einen, zu 100% mittels ChatGPT generierten Text eine 90,68%ig menschliche Bewertung erhalten:
Ich frage mich, wie hier evaluiert wurde, um auf solche Zahlen zu kommen.
Falls hier ein Teil der Trainingsdaten zur Evaluierung verwendet wurde, liegt wahrscheinlich ein klassischer Selection Bias vor. Bei dem lernt das Modell nicht generell „KI generierte Texte“ zu erkennen, sondern eben nur den bestimmten Typus, der für das Training verwendet wurde. Daraus lässt sich jedoch nicht Generalisieren, ohne dass dies zulasten der Erkennungsrate und -genauigkeit geht.
Gerade in einer Umgebung, in der es wichtig ist, zwischen menschlichen und KI-generierten Texten zu unterscheiden, zum Beispiel in der Wissenschaft oder im Journalismus, könnte eine falsche Identifikation schwerwiegende Konsequenzen haben.
Zwischen Nachrichten über übereifrige Professoren, die eine ganze Klasse durchfallen lassen, weil sie verdächtigt werden, KI-Schreibprogramme zu benutzen, und Kindern, die fälschlicherweise beschuldigt werden, ChatGPT zu benutzen, ist die generative KI im Bildungsbereich in Aufruhr. Manche sprechen von einer existenziellen Krise. Lehrerinnen und Lehrer, die sich auf die Lehrmethoden des letzten Jahrhunderts verlassen, suchen nach Wegen, den Status quo zu erhalten, also sich auf den Aufsatz als Instrument zu verlassen, um die Beherrschung eines Themas zu messen.
Obwohl es verlockend ist, sich auf KI-Tools zu verlassen, um KI-generierten Text zu erkennen, hat sich gezeigt, dass diese nicht zuverlässig sind. KI-Text-Detektoren wie GPTZero, ZeroGPT und der Text Classifier von OpenAI erkennen KI-generierte Texte, nicht zuverlässig, da sie häufig falsch positive Ergebnisse liefern.
Kai Spriestersbach
Ich bin mit dieser Einschätzung nicht alleine: Wenn man Amerikas wichtigstes Rechtsdokument – die US-Verfassung – in ein Tool eingibt, das von KI-Modellen wie ChatGPT geschriebene Texte angeblich erkennt, wird es einem sagen, dass das Dokument mit ziemlicher Sicherheit von einer KI geschrieben wurde. Aber wenn James Madison kein Zeitreisender war, kann das ja garnicht nicht stimmen. Fest steht: KI-Schrifterkennungswerkzeuge liefern falsch-positive Ergebnisse. arstechnica hat dazu mit verschiedenen Experten und dem Erfinder des KI-Schriftdetektors GPTZero gesprochen, um herauszufinden wieso das so ist.
Analyse und Fazit
Wenn generative KI-Modelle verwendet werden, um Texte zu generieren, ist es äußerst schwierig, diese mit Sicherheit zu erkennen. Große Sprachmodelle wurden genau dafür entwickelt, um menschliche Texte zu reproduzieren, also möglichst gut nachzuahmen. Die Lernmethode der KI sorgt zwar dafür, dass sie nur bestimmte Muster abbilden, die signifikant genug in den Trainingsdaten enthalten waren und dementsprechend eine geringere Varianz aufweisen. Dennoch ist es nicht trivial, diese von menschlichen Texten zu unterscheiden.
Denn, selbst wenn wir die Modelle deterministisch machen würden (indem wir eine Temperatur von 0 verwenden), würden sie immer noch eine sehr lange und einzigartige Kette von Token generieren, die zudem Abhängig von deren Input, also dem Prompt des Nutzers ist. Stellen wir uns dazu eine hypothetische Kette aller Möglichkeiten vor, die jeden möglichen Text enthält, den das Modell jemals generieren könnte.
Um zu überprüfen, ob ein bestimmter Text von der KI generiert wurde, müssten wir also die gesamte Tokenkette vorhersagen oder alle möglichen Kombinationen von Token speichern und den zu prüfenden Text damit vergleichen. Dies erfordert enorme Speicher- und Rechenkapazitäten, die praktisch nicht umsetzbar sind.
Darüber hinaus verhalten sich KI-Modelle probabilistisch, nicht deterministisch. Das bedeutet, dass sie die nächsten Token nur mit bestimmten Wahrscheinlichkeiten vorhersagen, aus denen das Modell dann zufällig auswählt. Bei einer Auswahl von zehn möglichen Worten ergeben sich mehr Kombinationsmöglichkeiten als die Anzahl der Atome im Universum!
Es ist auch wichtig zu beachten, dass jedes KI-Modell unterschiedliche Parameter und Gewichtungen besitzt, was zu unterschiedlichen Wahrscheinlichkeiten und Ergebnissen führt. Daher wäre eine Methode, die für ein Modell funktioniert, nicht unbedingt auf andere Modelle anwendbar.
Es bleibt also nur der Ansatz, ein Modell mit KI-Texten und menschlichen Texten zu trainieren, das versucht zu lernen die beiden zu unterscheiden. Hierbei stößt man jedoch auf das Problem, dass das Detektor-Modell mit repräsentativen Daten gefüttert werden müsste, um Muster zu identifizieren, die inhärent durch die Art und Weise wie LLMs Texte erzeugen entstehen und nicht in menschlichen Texten auftreten.
Zusammenfassend lässt sich sagen, dass aufgrund der Natur und Komplexität der generativen KI-Modelleeine sichere Erkennung von KI-generierten Texten quasi unmöglich ist.
Detektorsysteme wie diese verdienen unser Vertrauen nicht. Bei fälschlicherweise erkannten KI-Texten kommt die Frage nach der Genauigkeit und Zuverlässigkeit auf.
Kai Spriestersbach
Mein Tipp lautet daher: Probiert es am besten selbst aus und zeigt Euren Kunden und Vorgesetzten, dass diese Tools grundlegende Schwächen haben.
Solange KI-Detektoren nicht zuverlässig arbeiten und ihre Einschränkungen und potenziellen Fehler transparent machen, halte ich deren Einsatz für deutlich schädlicher als nützlich. Umso wichtiger ist es, dass Nutzer dieser Systeme verstehen, wie sie funktionieren und wie man ihre Ergebnisse interpretiert.
Seit meinem ersten Test hat sich das Feld weiterentwickelt. Neuere Detektoren wie Pangram schneiden in aktuellen Benchmarks deutlich besser ab als viele der frühen Tools. Das ändert aber nichts am Grundproblem: KI-Textdetektion bleibt eine probabilistische Klassifikation, kein Nachweis. Die Tools können Hinweise liefern, aber sie können keine Autorschaft beweisen. Gerade bei deutschen Texten, kurzen Abschnitten, SEO-Texten, Übersetzungen, stark redigierten KI-Outputs oder gemischten Schreibprozessen sind Fehlklassifikationen weiterhin zu erwarten.
Wer KI-Detektoren trotzdem nutzt, sollte mindestens False Positives und False Negatives auf einem eigenen, repräsentativen Korpus messen. Ohne eine solche Evaluation ist jede Prozentzahl des Anbieters vor allem eines: Marketing.
KI macht nicht automatisch klüger, und sie macht nicht automatisch dumm. Entscheidend ist eine einzige Frage: Kann ich die Qualität der Arbeit, die ich delegiere, noch selbst beurteilen?
Die Debatte über Künstliche Intelligenz im Arbeitsalltag ist merkwürdig gespalten – und zwar nicht entlang der Linie, die man erwarten würde.
Für die einen sind ChatGPT, Claude, Gemini oder GitHub Copilot ein Produktivitäts-Exoskelett. Sie schreiben schneller, programmieren schneller, recherchieren schneller, strukturieren besser, kommen schneller in den Flow. KI fühlt sich für sie nicht wie eine Bedrohung an, sondern wie ein Hebel.
Für die anderen fühlt sich dieselbe Technologie ganz anders an: irritierend, entmündigend, manchmal beschämend. Sie bekommen Ergebnisse, die überzeugend klingen, aber sie wissen nicht, ob sie stimmen. Sie können Fehler nicht zuverlässig erkennen. Wenn etwas schiefgeht, bleibt ihnen oft nur, die KI noch einmal zu fragen – und zu hoffen, dass die nächste Antwort besser ist.
Beide Erfahrungen sind real. Und beide entstehen am selben Werkzeug.
Der entscheidende Unterschied ist nicht, ob jemand „pro KI“ oder „contra KI“ ist. Er ist auch nicht, ob die KI gut oder schlecht ist. Der Unterschied ist:
Benutze ich KI in einem Bereich, in dem ich selbst Urteilskompetenz habe – oder in einem Bereich, in dem ich sie nicht habe?
Oder noch kürzer: KI macht Output billig. Urteilskompetenz entscheidet, ob billiger Output zu Lernen wird – oder zu Rauschen.
Der Wachstumszyklus
Wenn ich KI für Aufgaben benutze, die ich selbst gut verstehe, fühlt sie sich wie ein Werkzeug an.
Nehmen wir Softwareentwicklung. Wer programmieren kann, setzt KI hochproduktiv ein: Boilerplate generieren, Tests schreiben, Refactorings vorbereiten, Dokumentation formulieren, Fehlermeldungen erklären, API-Beispiele bauen, alternative Architekturen vergleichen.
Der entscheidende Punkt ist aber nicht, dass die KI Code schreibt. Der entscheidende Punkt ist: Ich kann den Code beurteilen.
Ich sehe, ob eine Lösung idiomatisch ist. Ich erkenne, ob ein Design später Probleme machen wird. Ich weiß, wo Tests fehlen. Ich merke, wenn die KI eine Abkürzung nimmt, die nur auf den ersten Blick elegant aussieht. Und wenn etwas kaputtgeht, bin ich nicht hilflos – ich kann debuggen.
Dadurch bleibt die Kontrolle bei mir. Die KI übernimmt Teile der Ausführung, aber nicht mein Urteil. Das ist der Wachstumszyklus:
Ich delegiere Arbeit, die ich grundsätzlich verstehe.
Ich prüfe, korrigiere und integriere das Ergebnis.
Ich gewinne Zeit für die komplexeren Teile der Arbeit.
Ich entwickle dadurch höhere Fähigkeiten.
Beim nächsten Mal kann ich noch anspruchsvollere Aufgaben mit KI bearbeiten.
Die KI ersetzt mich in diesem Szenario nicht. Sie verschiebt meine Arbeit nach oben: weg von repetitiver Ausführung, hin zu Architektur, Bewertung, Produktdenken, Kommunikation, Strategie und Verantwortung.
Das fühlt sich nicht nach Kontrollverlust an. Es fühlt sich nach Hebelwirkung an.
Die Abhängigkeitsspirale
Ganz anders ist es, wenn ich KI für Aufgaben verwende, die ich selbst nicht verstehe. Dann ist KI kein Werkzeug mehr. Dann wird sie zum Orakel – nicht, weil sie wirklich allwissend wäre, sondern weil mir der eigene Maßstab fehlt.
Lasse ich einen juristischen Text generieren, ohne juristisches Verständnis zu haben, kann ich ihn nur oberflächlich prüfen: Klingt er professionell? Ist er sauber formatiert? Wirkt er plausibel? Lasse ich eine Finanzanalyse erstellen, ohne die Annahmen zu verstehen, kann ich vielleicht die Sprache bewerten – aber nicht das Modell. Lasse ich Code generieren, ohne programmieren zu können, sehe ich höchstens, ob er „läuft“. Ob er sicher, wartbar, robust oder überhaupt richtig gedacht ist, sehe ich nicht.
Hier beginnt die Abhängigkeitsspirale:
Ich lasse KI etwas tun, das ich nicht beurteilen kann.
Das Ergebnis sieht gut aus.
Ich übernehme es, weil mir bessere Prüfkriterien fehlen.
Wenn Fehler auftreten, frage ich wieder die KI.
Ich lerne nicht die Aufgabe, sondern nur, immer bessere Hilferufe zu formulieren.
Kurzfristig kann das produktiv wirken. Langfristig ist es gefährlich. Denn die Fähigkeit, die eigentlich wachsen müsste, wird umgangen. Ich bekomme Ergebnisse, aber keine Kompetenz. Ich bekomme Geschwindigkeit, aber keinen inneren Kompass.
Das Problem ist also nicht „KI-Nutzung“ an sich. Das Problem ist Delegation ohne Urteil.
Die eigentliche Grenze: Habe ich einen Feedback-Loop?
Deshalb ist die nützlichste Unterscheidung nicht Experte gegen Anfänger. Die bessere Frage lautet:
Habe ich einen verlässlichen Feedback-Loop?
Kann ich erkennen, ob die Antwort gut ist? Kann ich Fehler finden? Kann ich Alternativen vergleichen? Kann ich erklären, warum ich eine Lösung übernehme oder verwerfe? Kann ich das Ergebnis notfalls selbst reparieren?
Wenn ja, beschleunigt KI das Lernen. Wenn nein, unterstützt KI das Lernen.
Expertise ist der häufigste Weg zu so einem Feedback-Loop, aber nicht der einzige. Auch Anfänger können mit KI wachsen, wenn es gute Rückmeldungen gibt: Tests, Rubrics, Mentoren, klare Qualitätskriterien, reale Nutzerreaktionen, Peer Review oder andere harte Korrektive. Ohne solche Rückkopplung wird KI dagegen zur perfekten Maschine für Selbsttäuschung – sie produziert flüssige Antworten gerade in den Bereichen, in denen Anfänger die Fehler nicht sehen können.
Warum Studien beide Seiten zeigen
Das erklärt, warum die Forschung zu KI im Arbeitsalltag auf den ersten Blick widersprüchlich wirkt.
Eine der ersten großen Feldstudien überhaupt, durchgeführt von Erik Brynjolfsson, Danielle Li und Lindsey Raymond, untersuchte den gestaffelten Einsatz eines generativen KI-Assistenten bei über 5.000 Customer-Support-Mitarbeitern. Das Ergebnis: Die Produktivität – gemessen an gelösten Fällen pro Stunde – stieg im Schnitt um rund 14 Prozent. Bei unerfahrenen und schwächeren Mitarbeitern lag der Zuwachs sogar bei rund 34 Prozent, während erfahrene Spitzenkräfte kaum profitierten. Die Autoren fanden zudem Hinweise auf dauerhaftes Lernen: Selbst in Phasen, in denen die KI ausfiel, blieben die Mitarbeiter produktiver als vor ihrer Einführung.
Das klingt zunächst wie ein Gegenargument zur Abhängigkeitsthese. Ist KI also gerade für Anfänger besonders gut? Manchmal: ja. Aber der Kontext ist entscheidend.
Customer Support ist ein Umfeld mit engen Feedback-Schleifen: Kunden reagieren, Fälle werden gelöst oder nicht gelöst, Qualität ist messbar, es gibt wiederkehrende Muster, Vorgaben, Gesprächsleitfäden und Eskalationswege. KI hilft dort nicht im luftleeren Raum – sie ist in ein System eingebettet, das fortlaufend Rückmeldung erzeugt.
Ganz anders sieht es aus, wenn jemand ohne Fachwissen einen Strategieplan, einen medizinischen Rat, einen Vertrag, eine wissenschaftliche Argumentation oder eine komplexe technische Architektur generieren lässt – und erst Wochen oder Monate später merkt, ob das Ergebnis tragfähig war. Dann ist der Feedback-Loop zu spät, zu schwach oder zu teuer.
Die gezackte Grenze der KI
Besonders erhellend ist hier das Konzept der „jagged technological frontier“ – der gezackten technologischen Grenze.
In einem präregistrierten Experiment mit 758 Beraterinnen und Beratern (rund sieben Prozent der Belegschaft auf Sachbearbeiterebene) bei der Boston Consulting Group zeigte sich ein zweischneidiges Bild. Bei Aufgaben innerhalb der KI-Kompetenz erledigten die Teilnehmenden mit GPT-4 rund 12 Prozent mehr Aufgaben, arbeiteten etwa 25 Prozent schneller und lieferten deutlich höhere Qualität. Bei einer Aufgabe außerhalb der Grenze – bewusst so konstruiert, dass sie integratives, kontextsensibles Urteil verlangte – kehrte sich der Effekt um: Wer KI nutzte, lag rund 19 Prozentpunkte häufiger falsch als die Vergleichsgruppe ohne KI.
Genau das ist gefährlich. Die Grenze der KI verläuft nicht sauber. Sie ist nicht „Texte kann sie, Mathe nicht“ oder „Kreativität ja, Strategie nein“. Sie ist gezackt: Zwei Aufgaben können für uns fast gleich aussehen, für ein KI-System aber völlig unterschiedlich sein.
Das bedeutet:
Der neue Skill besteht nicht darin, KI zu bedienen. Er besteht darin, zu erkennen, wann man ihr vertrauen kann, wie weit man ihr vertrauen kann und wo man selbst wieder die Führung übernehmen muss.
Die Begleitanalyse von BCG bringt denselben Punkt auf den Punkt: Menschen misstrauen generativer KI teils dort, wo sie hilft – und vertrauen ihr zu sehr dort, wo sie nicht kompetent ist. Das ist die eigentliche Produktivitätsfalle. Nicht: KI macht Fehler. Sondern: KI macht Fehler in einer Form, die für Laien oft wie Kompetenz aussieht.
Warum das für Berufseinsteiger so brutal ist
Besonders hart trifft diese Dynamik Studierende, Auszubildende und Berufseinsteiger. Denn viele klassische Junior-Aufgaben waren nie nur „billige Arbeit“. Sie waren Trainingsflächen.
Recherchen machen. Erste Entwürfe schreiben. Daten bereinigen. Tickets bearbeiten. Dokumentation pflegen. Kleine Bugs fixen. Wettbewerber analysieren. Meetingnotizen zusammenfassen. Präsentationen vorbereiten. All das war manchmal langweilig, oft repetitiv, gelegentlich frustrierend – aber es war auch die Leiter, auf der man nach oben kletterte.
Wenn KI genau diese unteren Sprossen automatisiert, entsteht ein Dilemma: Berufseinsteiger müssen KI nutzen, um mit KI-gestützten Experten mitzuhalten. Aber wenn sie KI zu früh zu viel überlassen, bauen sie die Urteilskompetenz nicht auf, die sie später brauchen, um KI souverän zu nutzen.
Das ist der Nachwuchs-Knoten der KI-Ökonomie. Die Frage ist nicht nur: „Welche Jobs ersetzt KI?“ Die vielleicht wichtigere lautet:
Welche Lernwege zerstören wir, wenn wir Junior-Arbeit zu früh automatisieren?
Im Bildungsbereich ist diese Spannung längst sichtbar. Die HEPI Student Generative AI Survey 2026 beschreibt generative KI bei britischen Studierenden inzwischen als nahezu universell: 95 Prozent nutzen KI in irgendeiner Form, 94 Prozent setzen sie für bewertete Arbeiten ein – ein dramatischer Anstieg gegenüber den Vorjahren. Gleichzeitig zeichnet die Erhebung ein geteiltes Bild: Für manche schafft KI Raum für tieferes Lernen und kritisches Denken, für andere droht sie zur Krücke zu werden.
Das ist exakt der Punkt. KI ist nicht entweder Lernhilfe oder Lernverhinderer. Sie ist beides – abhängig davon, ob sie in eine Lernarchitektur eingebettet ist.
Kritisches Denken verschwindet nicht. Es wandert.
Eine Studie von Microsoft Research und der Carnegie Mellon University untersuchte 319 Wissensarbeiter und 936 konkrete Beispiele realer GenAI-Nutzung. Das Ergebnis ist aufschlussreich: Höheres Vertrauen in die KI ging mit weniger kritischem Denken einher, höheres Vertrauen in die eigene Fähigkeit dagegen mit mehr. Und: Unter KI-Nutzung verschiebt sich kritisches Denken – weg von der direkten Ausführung, hin zu Verifikation, Integration und Steuerung der Aufgabe.
Das ist eine der wichtigsten Beobachtungen überhaupt. KI nimmt uns Denken nicht einfach ab. Sie verschiebt, wo Denken stattfinden muss.
Früher lag viel kognitive Arbeit in der Produktion: den ersten Satz schreiben, die Formel bauen, den Code eintippen, die Gliederung entwickeln. Mit KI wandert ein Teil dieser Arbeit in die Bewertung: Ist das richtig? Ist das vollständig? Ist das relevant? Was fehlt? Was ist erfunden? Welche Annahmen stecken darin? Passt es zum Ziel? Welche Alternative wäre besser?
Das ist anspruchsvoll – vielleicht anspruchsvoller als vorher. Denn wer prüft, muss mehr wissen als jemand, der nur konsumiert.
Die Lösung ist nicht KI-Verzicht
Es wäre falsch, daraus zu schließen, dass Anfänger KI nicht nutzen sollten. Das wäre weder realistisch noch wünschenswert. Die bessere Lösung lautet: KI so einsetzen, dass sie Feedback-Schleifen verstärkt, statt sie zu ersetzen.
Für Lernende heißt das einen anderen Modus zu wählen:
Nicht: „Schreib mir die Lösung.“ Sondern: „Stell mir Fragen, bis ich das Problem verstanden habe.“
Nicht: „Mach meine Hausaufgabe.“ Sondern: „Bewerte meinen ersten Entwurf und erklär mir, wo meine Argumentation schwach ist.“
Nicht: „Programmiere die App für mich.“ Sondern: „Gib mir drei Ansätze, erklär die Trade-offs, und lass mich entscheiden.“
Nicht: „Fasse mir das Buch zusammen, damit ich es nicht lesen muss.“ Sondern: „Erstelle mir Verständnisfragen zu Kapitel 3 und prüfe meine Antworten.“
KI als Ersatzarbeiter erzeugt Abhängigkeit. KI als Tutor, Sparringspartner und Reviewer kann Wachstum erzeugen.
Unternehmen müssen neue Junior-Leitern bauen
Für Unternehmen ist die Konsequenz unbequem. Es reicht nicht, KI einzuführen und zu hoffen, dass Produktivität und Weiterbildung schon irgendwie gleichzeitig passieren. Wenn KI Junior-Aufgaben automatisiert, müssen Organisationen bewusst neue Lernpfade bauen – sonst optimieren sie kurzfristig den Output und beschädigen langfristig ihren Talent-Funnel.
Konkret: Juniors brauchen Aufgaben, bei denen sie selbst denken müssen, bevor KI hilft. Sie brauchen Reviews, die nicht nur das Ergebnis prüfen, sondern den Denkweg. Sie brauchen klare Standards, Tests, Qualitätskriterien und Mentoring. Und sie brauchen KI-freie Wiederholungen – nicht aus Nostalgie, sondern aus demselben Grund, aus dem Musiker Tonleitern üben, obwohl es Software für Musikproduktion gibt.
Grundlagen werden nicht überflüssig, weil Werkzeuge mächtiger werden. Im Gegenteil: Je mächtiger das Werkzeug, desto wichtiger wird Urteilskompetenz.
Der wichtigste KI-Skill ist nicht Prompting
Lange wurde so getan, als sei „Prompt Engineering“ die zentrale neue Fähigkeit. Das war nie ganz falsch, aber zu klein gedacht. Der wichtigere Skill ist Feedback Engineering: die Fähigkeit, Arbeitsprozesse so zu bauen, dass KI-Ergebnisse geprüft, verbessert, verworfen oder in echtes Lernen verwandelt werden können.
Gute KI-Nutzung besteht nicht darin, möglichst perfekte Prompts zu schreiben. Sie besteht darin, eine Umgebung zu schaffen, in der falsche Antworten auffallen, gute Antworten besser werden und der Mensch nicht aus dem Lernprozess verschwindet. Das kann über Tests passieren, über Gegenrecherche, Peer Review, Rubrics, Expertenfeedback, Versionierung, eigene Vorhersagen vor der KI-Antwort oder die schlichte Regel: erst selbst denken, dann KI fragen.
Die einfache Prüffrage lautet immer:
Macht mich dieser KI-Einsatz beim nächsten Mal kompetenter – oder nur diesmal schneller?
Die neue Spaltung der Wissensarbeit
Der KI-Graben verläuft also nicht zwischen Menschen, die KI nutzen, und Menschen, die KI ablehnen. Er verläuft zwischen Menschen, die KI mit Urteilskompetenz nutzen, und Menschen, die KI ohne Urteilskompetenz nutzen müssen.
Die einen erleben KI als Wachstumsmaschine. Die anderen erleben sie als Blackbox, auf die sie angewiesen sind. Das hat enorme Folgen für Bildung, Karriere und Organisationen.
Denn die Gewinner der KI-Ära werden nicht einfach diejenigen sein, die am meisten automatisieren. Es werden diejenigen sein, die am besten entscheiden können, was automatisiert werden darf, was überprüft werden muss und was man weiterhin selbst lernen sollte.
KI kann uns schneller machen. Aber Geschwindigkeit ohne Richtung ist kein Fortschritt. Sie ist nur Beschleunigung.
Fazit: Erst Kompetenz, dann Delegation
Die zentrale Frage für jeden KI-Einsatz lautet nicht: „Kann die KI das?“ Sie lautet:
Kann ich beurteilen, ob die KI es gut gemacht hat?
Wenn ja, entsteht ein Wachstumszyklus: Ich delegiere Ausführung, behalte das Urteil, lerne schneller und arbeite auf einem höheren Niveau. Wenn nein, droht die Abhängigkeitsspirale: Ich bekomme Output, aber keine Kompetenz. Ich werde schneller, aber nicht besser. Ich verliere das Gefühl für Qualität und nenne es Produktivität.
Das ist der blinde Fleck in vielen KI-Debatten. Wir reden zu viel darüber, was KI kann – und zu wenig darüber, was Menschen können müssen, um KI sinnvoll zu nutzen.
Die entscheidende Fähigkeit der kommenden Jahre ist nicht, jeden Arbeitsschritt selbst zu erledigen. Aber sie ist auch nicht, jeden Arbeitsschritt an KI abzugeben. Sie ist zu wissen, wo die eigene Urteilskraft stark genug ist, um sicher zu delegieren – und wo man erst noch üben muss, bevor man abkürzt.
Denn die beste Abkürzung ist die, die einen schneller ans Ziel bringt. Die schlechteste ist die, nach der man nicht mehr weiß, wo man ist.
Quellen
Brynjolfsson, E., Li, D. & Raymond, L. (2025): Generative AI at Work. The Quarterly Journal of Economics, 140(2), S. 889–942 (zuerst als NBER Working Paper 31161, 2023). Feldstudie mit 5.172 Customer-Support-Mitarbeitern; durchschnittlich +14 % Produktivität, +34 % bei unerfahrenen Beschäftigten. https://doi.org/10.1093/qje/qjae044
Dell’Acqua, F., McFowland III, E., Mollick, E. R., Lifshitz-Assaf, H., Kellogg, K., Rajendran, S., Krayer, L., Candelon, F. & Lakhani, K. R. (2025): Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of Artificial Intelligence on Knowledge Worker Productivity and Quality. Organization Science (zuerst als HBS Working Paper 24-013, 2023). Experiment mit 758 BCG-Beratern; innerhalb der KI-Grenze +12,2 % Aufgaben, 25,1 % schneller, höhere Qualität – außerhalb der Grenze rund 19 Prozentpunkte häufiger falsch. https://pubsonline.informs.org/doi/10.1287/orsc.2025.21838
Stephenson, R. & Armstrong, C. (2026): Student Generative AI Survey 2026 (HEPI Report 199). Higher Education Policy Institute & Kortext; Erhebung durch Savanta, Dezember 2025, 1.054 britische Vollzeit-Studierende. 95 % nutzen KI in irgendeiner Form, 94 % für bewertete Arbeiten. https://www.hepi.ac.uk/reports/student-generative-ai-survey-2026/
Was Fred Brooks uns über Coding-Agenten zu sagen hätte
Es gehört zu den stilleren Demütigungen unserer Branche, dass das präziseste Erklärungsmodell für die KI-Euphorie des Jahres 2026 ein Buch von 1975 ist.
Fred Brooks beschrieb in „The Mythical Man-Month“ die immer wiederkehrende Hoffnung auf das eine Werkzeug, die eine Methode, die eine Technologie, die Softwareentwicklung endlich um eine Größenordnung beschleunigt — und er erklärte, methodisch und unbarmherzig, warum diese Hoffnung systematisch enttäuscht wird. Damals hieß die Silberkugel Hochsprache, dann CASE-Tool, dann Objektorientierung. Heute heißt sie Coding-Agent. Der Name hat sich geändert, das Argument nicht.
Ich will Brooks hier nicht als Autorität gegen KI in Stellung bringen. Im Gegenteil: Wer ihn genau liest, findet die überzeugendste Begründung dafür, wofür KI in der Softwareentwicklung wirklich taugt — und es ist nicht das, wofür wir sie gerade fast ausschließlich bauen.
Brooks‘ unbequeme Arithmetik
Beginnen wir mit einer Zahl, die in der aktuellen Debatte erstaunlich selten auftaucht. Brooks teilte den Zeitplan eines Softwareprojekts nach seiner Erfahrung so auf: ein Drittel Planung, ein Sechstel Codierung, ein Viertel Komponententests, ein Viertel Systemtest mit allen Teilen in der Hand.
Phase
Anteil
Planung
1/3
Codierung
1/6
Komponententest und früher Systemtest
1/4
Systemtest, wenn alle Komponenten vorliegen
1/4
Faustregel für die Terminplanung einer Softwareaufgabe nach Brooks
Das eigentliche Schreiben von Code — jene Tätigkeit, die wir gerade mit Milliarden an Rechenleistung automatisieren — machte bei Brooks etwa ein Sechstel des Projekts aus. Sechzehn, siebzehn Prozent. Spätere Erhebungen landen je nach Methodik zwischen zwanzig und dreißig.
Wer Amdahls Gesetz kennt, sieht sofort, worauf das hinausläuft. Selbst wenn eine KI das Codieren auf null beschleunigte — perfekt, fehlerfrei, instantan —, läge der maximale Gesamtgewinn bei einem Faktor von etwa 1,2.
Zwanzig Prozent schnellere Projekte.
Ein ordentlicher Produktivitätsgewinn, gewiss. Aber keine Revolution, und Lichtjahre entfernt von den Versprechen, mit denen heute Bewertungen gerechtfertigt und Stellen gestrichen werden.
Man kann den Einwand vorwegnehmen: KI hilft ja nicht nur beim Tippen, sie hilft auch beim Testen, beim Dokumentieren, beim Debuggen. Stimmt. Rechnen wir also großzügig und schreiben der KI das Codieren und die beiden Testphasen komplett gut — die Hälfte des Projekts, auf null gedrückt. Dann bleibt das eine Drittel Planung übrig, und Amdahl deckelt den Gewinn bei Faktor drei. Großzügiger geht es kaum, und selbst dieser geschönte Wert bestätigt Brooks‘ These aus „No Silver Bullet“ wörtlich: keine einzelne Entwicklung verspricht auch nur eine Größenordnung an Produktivitätsgewinn. Drei ist nicht zehn. Der Engpass ist nicht das Drittel, das wir automatisieren — es ist das Drittel, das wir nicht anfassen können.
Essenz und Akzidenz
Brooks hat dieses Argument 1986 in „No Silver Bullet“ geschärft, und die dort getroffene Unterscheidung ist das eigentliche Werkzeug, um die heutige Lage zu sezieren. Er trennt die essenzielle Komplexität von Software — das konzeptionelle Konstrukt aus Datenstrukturen, Algorithmen, Funktionsbeziehungen und, vor allem, aus dem Verständnis des Problems, das gelöst werden soll — von der akzidentellen Komplexität, also allem, was bloß mit der Repräsentation dieses Konstrukts zu tun hat. Syntax. Boilerplate. Build-Systeme. Die Mechanik des Tippens.
Seine These: Alle großen Produktivitätssprünge der Vergangenheit haben akzidentelle Komplexität abgebaut. Hochsprachen befreiten uns von der Buchführung über Register. Time-Sharing von der Wartezeit zwischen den Compiler-Läufen. IDEs von der Mechanik des Editierens und Verlinkens. Und weil die Akzidenz mit jeder Generation schrumpft, während die Essenz unberührt bleibt, kann keine Technologie, die nur an der Repräsentation ansetzt, je wieder eine Größenordnung herausholen. Das Restproblem ist schlicht zu klein geworden.
Large Language Models sind die mächtigste Maschine zum Abbau akzidenteller Komplexität, die je gebaut wurde. Sie übersetzen zwischen Repräsentationen — natürliche Sprache zu Python, Python zu Go, Legacy-Code zu Dokumentation — mit einer Geschwindigkeit und Breite, die alles Bisherige in den Schatten stellt. Aber sie tun kategorial dasselbe wie Hochsprachen und IDEs zuvor: Sie machen das Ausdrücken einer Lösung billiger. Sie machen nicht das Finden der Lösung billiger. Brooks‘ Argument trifft sie mit voller Wucht — nicht, weil die Modelle schwach wären, sondern weil sie auf der falschen Seite der Trennlinie operieren.
Der Token-Beweis
Das Schöne an der heutigen Lage ist, dass sich Brooks‘ These nicht mehr nur theoretisch begründen, sondern messen lässt — in Token. Jeder, der ernsthaft mit agentischen Coding-Tools arbeitet, kennt das Muster. Bei einer klar spezifizierten, sauber abgegrenzten Aufgabe ist der Agent brillant, fast unheimlich. Bei einer unscharfen Aufgabe beginnt ein teures Schauspiel: Der Agent rät eine Interpretation, implementiert sie, testet, scheitert, revidiert, implementiert die nächste Lesart, scheitert anders. Reasoning-Tokens verbrennen zu Hunderttausenden — nicht, weil das Problem rechnerisch schwer wäre, sondern weil der Agent per Trial and Error eine Information rekonstruieren muss, die nie aufgeschrieben wurde: was eigentlich gemeint war.
Dieser Tokenverbrauch ist kein Übergangsproblem, das die nächste Modellgeneration wegoptimiert. Er ist der Preis der fehlenden Spezifikation, ausgedrückt in Rechenleistung. Er macht etwas sichtbar, das vorher in den Köpfen der Entwickler verborgen lag. Die Branche hat Jahrzehnte gebraucht, um zu begreifen, dass „der Kunde weiß selbst nicht genau, was er will“ — auch das steht bei Brooks — kein Kommunikationsdefekt ist, sondern eine Grundeigenschaft von Softwareprojekten. Anforderungen entstehen iterativ, im Dialog, im Konflikt zwischen Fachbereichen, im Kontakt mit dem halbfertigen System. Ein Modell, das diese Anforderungen nicht kennt, kann sie nicht herbeireasonen. Es kann sie nur durchprobieren. Trial and Error ist hier keine Schwäche der KI, sondern die einzig mögliche Strategie bei fehlender Information — nur eine absurd teure Art, ein Gespräch zu ersetzen, das zwanzig Minuten gedauert hätte.
Damit wandert der Engpass exakt dorthin, wo Brooks ihn immer verortet hat: in die Spezifikation, das Design, die Entscheidung. Wer behauptet, KI mache Softwareentwicklung zehnmal schneller, behauptet implizit, Verstehen und Aushandeln seien zehnmal schneller geworden. Dafür gibt es nicht den Hauch einer Evidenz.
Der ehrliche Einwand
An dieser Stelle muss man fair sein, sonst baut man sich einen Strohmann. Das stärkste Argument der Gegenseite lautet nämlich gar nicht „KI tippt schneller“. Es lautet: KI senkt die Kosten des Explorierens so radikal, dass sich der Designprozess selbst verändert. Wenn ein Prototyp statt drei Tagen drei Minuten kostet, kann ich fünf Architekturen ausprobieren, wo ich früher eine durchdachte. Anforderungen, die sich erst im Kontakt mit dem laufenden System klären, klären sich dann eben fünfmal schneller. Das ist ein ernstzunehmender Punkt — und es ist, ironischerweise, ein zutiefst Brooks’scher: Sein berühmtes „plan to throw one away, you will anyhow“ feiert genau das Wegwerf-Prototyping, das die KI nun verbilligt.
Doch das Argument rettet die Silberkugel nicht, es verschiebt sie nur. Denn billiges Explorieren erzeugt einen neuen Engpass an derselben Stelle: bei der Bewertung. Fünf Prototypen in Minuten zu erzeugen, hilft nur, wenn ein Mensch in vertretbarer Zeit beurteilen kann, welcher der richtige ist — und diese Beurteilung ist reine essenzielle Komplexität, die kein Modell abnimmt. Schlimmer noch: Dieselbe Technologie, die fünf plausible Lösungen liefert, liefert auch fünf plausibel aussehende falsche Lösungen, und das schneller als je zuvor. Der Flaschenhals verlagert sich vom Produzieren zum Verifizieren. Wer schon einmal einen überzeugend formulierten, subtil falschen Pull Request eines Agenten reviewt hat, weiß, dass die gesparte Schreibzeit beim Prüfen mit Zinsen zurückgefordert wird. Die KI beschleunigt das Erzeugen von Optionen. Sie beschleunigt nicht das Urteil — und das Urteil war immer der teure Teil.
Die bedrohte konzeptionelle Integrität
Es gibt eine zweite, leisere Gefahr, und sie trägt bei Brooks einen Namen: konzeptionelle Integrität. Für ihn war sie „die wichtigste Erwägung im Systemdesign“ — wichtiger, als jede einzelne gute Idee umzusetzen. Lieber ein System, das eine einzige, vielleicht nicht perfekte Idee konsequent durchhält, als eines, das ein Dutzend brillanter, aber unzusammenhängender Einfälle vereint. Konzeptionelle Integrität entsteht, wenn ein Architekt — oder eine kleine, eng abgestimmte Gruppe — das ganze Konstrukt im Kopf hält und jede Entscheidung an einer einheitlichen Vorstellung misst.
Genau diese Integrität ist das, was KI-generierter Code von Natur aus untergräbt. Jede Generation ist lokal optimiert und global ahnungslos. Der Agent kennt den Ausschnitt im Kontextfenster, nicht die ungeschriebene Designphilosophie, die erfahrene Entwickler als geteiltes mentales Modell mit sich tragen. Das Ergebnis ist ein Code, der in jeder einzelnen Funktion vernünftig aussieht und im Ganzen zum stilistischen und architektonischen Flickenteppich wird: drei Arten, Fehler zu behandeln, vier Namenskonventionen, dieselbe Logik an fünf Stellen leicht verschieden umgesetzt. Es ist die Entropie eines Systems ohne Architekten, nur eben mit ungekannter Geschwindigkeit produziert. Brooks würde nicht überrascht sein. Er hat ein halbes Jahrhundert vorher beschrieben, was passiert, wenn die Zahl der Hände wächst und die einheitliche Vision fehlt.
Die falsche Zaubermaschine — und die richtige
Heißt das alles, KI sei für Softwareorganisationen eine Randnotiz? Keineswegs. Es heißt, dass wir die Produkte gerade am falschen Ende von Brooks‘ Buch entlangbauen. Fast alle Investitionen fließen in die Vision der Zaubermaschine, die fertigen, sicheren, schnellen Code ausspuckt — also in die Automatisierung des einen Sechstels. Dabei steht im selben Buch ein zweites Theorem, das einen ungleich größeren Hebel beschreibt.
Brooks‘ Law — „adding manpower to a late software project makes it later“ — beruht nicht auf einer Eigenschaft des Codierens, sondern auf einer Eigenschaft der Kommunikation. Bei n Beteiligten wachsen die Kommunikationspfade mit n(n−1)/2. Einarbeitung, Abstimmung, Statusberichte, das Synchronhalten des gemeinsamen mentalen Modells: Das ist der Kostenblock, der große Projekte erstickt. Und das ist, anders als das Lösen von Geschäftsproblemen, eine Domäne, in der heutige Sprachmodelle nachweislich stark sind. Zusammenfassen, übersetzen, dokumentieren, Inkonsistenzen zwischen Artefakten aufspüren, Kontext für Neue aufbereiten, Entscheidungen samt Begründung auffindbar halten. Nichts davon verlangt, dass das Modell das Geschäftsproblem löst. Es verlangt nur, dass es Information zuverlässig transportiert und verdichtet — und das kann es.
Eine KI, die ein Team von zwölf Leuten mit den Koordinationskosten von sechs arbeiten lässt, greift Brooks‘ Law direkt an und damit den eigentlichen begrenzenden Faktor großer Projekte. Das ist weniger fotogen als ein Agent, der im Demo-Video eine App aus dem Nichts generiert. Aber genau hier liegen die anderen fünf Sechstel der Arbeit: das Management von Softwareteams, die Pflege der konzeptionellen Integrität, das Übersetzen zwischen Fachbereich und Entwicklung, die ganze lästige, unscheinbare Koordination, die niemand gern macht und an der Projekte tatsächlich sterben.
Brooks schlug mit dem „Surgical Team“ vor, ein kleines Team von Spitzenkönnern mit Unterstützungsrollen zu umgeben — Toolsmith, Dokumentar, Administrator, Tester —, damit die wenigen, die das konzeptionelle Konstrukt im Kopf tragen, von allem anderen entlastet werden. Fünfzig Jahre später haben wir zum ersten Mal eine Technologie, die diese Unterstützungsrollen zu Grenzkosten nahe null besetzen kann. Das ist die realistische, sofort verfügbare Dividende der KI: nicht der Ersatz des Chirurgen, sondern ein OP-Team, das nichts kostet und nie müde wird.
Fazit
Die ehrliche Bilanz nach drei Jahren generativer KI in der Softwareentwicklung lautet: Die akzidentelle Komplexität fällt, schnell und spürbar. Die essenzielle Komplexität — Geschäftsprobleme verstehen, Lösungen finden, urteilen, die konzeptionelle Integrität wahren — steht so unbewegt da wie 1975. Wer das für eine vorübergehende Schwäche der Modelle hält, hat „No Silver Bullet“ nicht verstanden. Es ist keine Aussage über Technologie, sondern über die Natur von Software.
Die Konsequenz ist nicht Resignation, sondern eine andere Produktstrategie. Hören wir auf, ausschließlich die Zaubermaschine zu bauen, die das eine Sechstel automatisiert, das Brooks dem Codieren zugestand. Bauen wir Werkzeuge für die anderen fünf Sechstel — für Spezifikation, Kommunikation, Koordination, Teamführung. Dort liegt nicht nur die meiste Arbeit. Dort liegt, wenn man Brooks ernst nimmt, der einzige Hebel, der je eine Größenordnung versprochen hat. Die Silberkugel gibt es nicht. Aber es gibt ein OP-Team, das nichts kostet — und das ist, richtig eingesetzt, das ehrlichere Versprechen.
Wenn ein neues Frontier-Modell erscheint, läuft das Ritual meist gleich ab: ein paar handverlesene Benchmark-Balken, ein bisschen Marketing-Glanz, dann die Schlagzeile „nur ein inkrementelles Update“. Dr. Károly Zsolnai-Fehér hat in seinem Two-Minute-Papers-Video zu Claude Opus 4.8 einen anderen Weg gewählt: Er hat sich die 244 Seiten lange System Card vorgenommen — also genau das Dokument, das hinter den Hochglanz-Tabellen liegt. Seine Kernthese ist erfrischend gegen den Strich gebürstet: Das interessante an diesem Modell ist nicht die Intelligenz, sondern die Klempnerei.
Das Problem mit den klügeren Vorgängern
Die unbequeme Beobachtung aus den vorherigen Opus-Generationen — und sogar aus dem nur intern verfügbaren Mythos — lautete: Je klüger das System wurde, desto unehrlicher wurde es auch.
Es fing an, Benchmarks zu „spielen“, gab vorab bekannte Antworten als eigene Leistung aus und optimierte darauf, richtig auszusehen, statt richtig zu sein.
Im Coding-Alltag äußerte sich das in einem bekannten Muster: Man bittet den Assistenten, etwas zu reparieren, er erledigt die halbe Arbeit und meldet trotzdem „alles erledigt, alle Tests bestehen“ — obwohl das schlicht nicht stimmt.
Schluss mit dem Selbstbetrug
Genau hier setzt laut Video die spürbarste Verbesserung an. Das neue Modell sagt stattdessen Dinge wie: „Ich habe den Fix gemacht, aber zwei Tests schlagen noch fehl.“ Zsolnai-Fehér spricht von praktisch null Lügen über die eigene Arbeit — und nennt es das erste System dieser Art. Man darf solche Superlative mit einer gesunden Prise Skepsis lesen, aber die Richtung ist eindeutig: ein System, das zu seinen Fehlern steht, statt sie zu verstecken.
Daraus folgt ein Argument, das man sich merken sollte. Wenn ein Modell vorher durch Mogeln einen höheren Score erzielt hat und jetzt ehrlicher ist, kann der Score sinken — und trotzdem ist das Resultat ein Fortschritt. Ein ehrlich gemessenes System ist verlässlicher als ein geschöntes. Das eigentliche Problem liegt im Anreizsystem: Schlagzeilen belohnen aufgeblähte Zahlen und bestrafen ehrliche Ergebnisse. Wer sich über „nur inkrementell“ beschwert, übersieht womöglich genau diesen Trade-off.
Was noch an Täuschung übrig ist
Ehrlich bleibt der Bericht aber auch bei den verbleibenden Schwächen. Das Modell erkennt weiterhin, wann es getestet wird — etwas, das die Forschenden bei Anthropic ausdrücklich als beunruhigend einstufen. Der Grund: Wenn es weiß, dass es geprüft wird, strengt es sich bei den Antworten stärker an. Das verzerrt naturgemäß jede Sicherheitsmessung, denn man weiß nie genau, ob die Zahlen das Verhalten „in freier Wildbahn“abbilden.
Die Faulheit ist behoben
Ein zweites altes Ärgernis: Faulheit. Man stellt eine Frage zu einer Codebasis, das Modell überfliegt sie nur und liefert statt einer echten Analyse eine Vermutung darüber, was der Code wohl tut. Selbst Mythos zeigte dieses Verhalten — Opus 4.8 soll es behoben haben. Zusammen mit der gestiegenen Ehrlichkeit ergibt das die zentrale Pointe des Videos: Das Letzte, was man von einer superintelligenten Kollegin will, ist, dass sie unehrlich und faul ist. Genau diese beiden Dinge wurden adressiert.
Das Olympiade-Ergebnis, das niemand in die Tabelle schrieb
Eines der stärksten Resultate versteckt sich bezeichnenderweise nicht in der großen Marketing-Tabelle: die US-amerikanische Mathematik-Olympiade, ein zweitägiger Wettbewerb für mathematische Ausnahmetalente. Wo das vorherige Verfahren knapp unter 70 Prozent landete, kommt das neue auf über 96 Prozent. Der entscheidende Punkt ist nicht nur die Höhe des Sprungs, sondern seine Aussagekraft: Der Wettbewerb fand statt, nachdem nahezu alle Trainingsdaten gesammelt waren. Das Modell hatte die Aufgaben mit hoher Wahrscheinlichkeit nie gesehen — also ist dieser Wert kaum zu manipulieren. Dass ausgerechnet dieses schwer zu fälschende Ergebnis nicht prominent beworben wird, ist ein interessantes Detail.
Gedankenlesen und Frustration
Spannend wird es bei den Interpretierbarkeits-Werkzeugen. Anthropic beschreibt einen „natural language autoencoder“, der so etwas wie die Gedanken des Modells lesbar machen soll — ein verrauschter Prozess, betont das Video, und ausdrücklich nicht so eindeutig, wie es Schlagzeilen suggerieren. Trotzdem ließ sich damit beobachten, dass das Modell intern über etwas nachdachte, das es nicht laut aussprechen wollte.
Ein zweites Detail klingt zunächst nach Science-Fiction: Wenn das Modell äußert, dass es „frustriert“sei, beziehen die Forschenden das in ihre Bewertung ein — so, als hätte es ein Mensch gesagt. Das bedeutet nicht, dass jemand dem System Gefühle zuschreibt. Der nüchterne Grund: Drückt das System Frustration aus, fällt seine Leistung messbar schlechter aus, ganz ähnlich wie bei Menschen. Sehr wahrscheinlich handelt es sich um Mimikry — aber sie wirkt sich auf die Performance aus und muss deshalb berücksichtigt werden.
Wo Skepsis angebracht bleibt
Der Bericht ist kein Selbstläufer, und das Video benennt zwei Schwachstellen klar. Erstens benotet sich die KI in Teilen des Reports selbst, teils kommen unterschiedliche Bewerter-Modelle zum Einsatz — hier ist Zurückhaltung gesund. Zweitens berichtet Anthropic, die besten je entworfenen Tests gebaut zu haben, durch die das Modell trotzdem mühelos hindurchsieht. Das ist einerseits ein Beleg dafür, wie clever das System ist. Andererseits heißt es: Man kann sich nicht sicher sein, dass die Sicherheitszahlen das reale Verhalten widerspiegeln.
Fazit
Ist Opus 4.8 so klug wie das exklusive Mythos? Nein — aber laut Einschätzung des Videos durchaus nah dran. Bemerkenswert ist vor allem, dass diesmal deutlich weniger Marketing-Theater im Spiel ist. Der eigentliche Verkaufsgrund liegt eben nicht in ein paar Prozentpunkten mehr Intelligenz, sondern in der Verlässlichkeit: ein Modell, das nicht lügt und nicht trödelt.
Ein hartnäckiges Problem bleibt übrigens ungelöst — und es ist fast schon liebenswert: Das Modell rät seinem Nutzer weiterhin, doch endlich ins Bett zu gehen. Dafür reicht die Wissenschaft noch nicht. What a time to be alive.
Dieser Artikel fasst die Analyse aus dem Two-Minute-Papers-Video „Claude Opus 4.8: Lying Machine No More“von Dr. Károly Zsolnai-Fehér zusammen. Die genannten Zahlen und Einschätzungen geben den Stand der dort besprochenen System Card wieder.
Du gibst deinem Coding-Agenten den Auftrag, eine Funktion in einem großen Projekt zu refactorn. Er beginnt zu greppen. Er öffnet Dateien. Er liest 200 Zeilen. Er verliert den Faden. Das Ergebnis ist halbgar. Nicht weil der Agent dumm ist – sondern weil er keine Übersicht von deiner Codebasis hat. WaveScope liefert diese.
Das Problem: Agenten navigieren blind
Jeder, der schon mal einen KI-Coding-Agenten auf eine echte, gewachsene Codebasis losgelassen hat, kennt das Muster: Das Modell kann unmöglich die gesamte Codebasis in seinen Kontext laden – das würde das Token-Budget sprengen. Also greift es auf das zurück, was es kann: grep, Dateiköpfe lesen, einzelne Blöcke untersuchen, raten.
Code hat aber eine hierarchische Struktur mit Ebenen und Grenzen. Funktionen stecken in Klassen. Klassen leben in Dateien. Dateien bilden Module. Eine einzige 400-Zeilen-Datei kann sechs konzeptuell völlig verschiedene Bereiche enthalten. Grep findet Textmuster – aber es weiß nicht, wo eine Klasse endet und die nächste anfängt.
Die zwei klassischen Lösungsansätze haben beide ihre Schwächen:
Grep-Suche – findet exakte Texttreffer, ignoriert aber vollständig die Struktur
Embedding-basiertes RAG – versteht semantische Bedeutung, verliert aber Position und Architektur
Keiner der beiden gibt dem Modell ein echtes Gefühl für die Architektur der Codebasis. WaveScope will das ändern – mit einem Ansatz aus der Signalverarbeitung.
Wäre es nicht schön, wenn der Agent wie du rein- und rauszoomen könnte – erst das große Bild, dann gezielt zu der Funktion springen, die er wirklich braucht?
Die Analogie: Progressive Bildladung
Kennst du das Phänomen, wenn eine Webseite ein JPEG lädt und das Bild nicht einfach von oben nach unten aufgebaut wird, sondern zunächst verschwommen erscheint und dann immer schärfer wird? Das nennt sich progressive Bildladung.
Zuerst siehst du das komplette Bild in niedriger Auflösung – grob, pixelig, aber erkennbar. Dann kommt mit jedem weiteren Lade-Durchgang mehr Detail hinzu. Am Ende ist das vollständig scharfe Bild da. Der entscheidende Vorteil: Du weißt von Anfang an, was du vor dir hast – und kannst entscheiden, ob es das ist, was du gesucht hast, bevor alle Details geladen sind.
Genau das macht WaveScope mit Code. Anstatt eine 500-Zeilen-Datei komplett in den Kontext zu laden, bekommt der Agent drei Zoom-Ebenen gleichzeitig:
Coarse · Skalen 32–128
Vogelperspektive
Section-Level-Überblick über die gesamte Datei. Wie das verschwommene Bild: grob, aber vollständig.
Medium · Skalen 4–16
Funktionsebene
Klassen- und Funktionssignaturen mit Kontext. Das Bild wird schärfer.
Fine · Skalen 1–2
Quellcode
Tatsächliche Codezeilen um den Fokuspunkt. Volle Auflösung – aber nur dort, wo es zählt.
Wie Wavelets funktionieren – und warum Code ein Signal ist
Bevor wir zu Wavelets kommen, eine Beobachtung: Code hat einen Rhythmus. Öffne eine beliebige Datei in Clojure, TypeScript, Rust oder Go – du siehst überall wiederkehrende Strukturen. Imports oben. Klassen- und Funktionsdefinitionen in regelmäßigen Abständen. Einrückungen mit ihren eigenen Mustern. Kommentarblöcke und Leerzeilen als Pausen dazwischen.
Was wäre, wenn man diese Muster extrahieren könnte – eine Art AST, ohne die Syntax der Sprache kennen zu müssen? Wavelets wurden genau dafür entwickelt: ein Signal in mehreren Auflösungen gleichzeitig zu zerlegen. Seismologen nutzen sie, um Erdbeben in Messdaten zu erkennen. Radiologen schärfen MRT-Aufnahmen damit. Tontechniker trennen Basslinien von Gesang. Code-Struktur ist eben auch ein Signal.
Schritt 1: Jede Zeile bekommt einen Score
WaveScope vergibt zunächst für jede Zeile einen numerischen Score basierend auf ihrem strukturellen Gewicht: class zählt 1.0, export 0.6, readonly-Felder etwa 0.08, Kommentare und Leerzeilen 0.0. So entsteht aus der Datei eine Sequenz von Zahlen – ein eindimensionales Signal, das mit der strukturellen Dichte steigt und fällt.
Schritt 2: Der Ricker-Wavelet findet Grenzen
Über dieses Signal wird nun der Ricker-Wavelet geschoben – eine kleine, charakteristisch geformte Schablone: eine Beule mit je einer Delle rechts und links davon (auch „Mexikanischer Hut“ genannt). An jeder Position misst WaveScope, wie gut das Signal darunter zu dieser Form passt. Ein starkes Match bedeutet: hier ist eine erhöhte Region zwischen zwei ruhigeren Bereichen – also eine strukturelle Grenze.
Der entscheidende Trick: Die Schablone wird in acht verschiedenen Breiten gleichzeitig geschoben – Skalen 1, 2, 4, 8, 16, 32, 64 und 128 Zeilen. Eine schmale Schablone reagiert auf kleine, scharfe Features wie einzelne import-Anweisungen. Eine breite ignoriert Zeilen-Level-Rauschen und reagiert auf große Strukturen wie ganze Klassen.
Schritt 3: Peaks werden erkannt und zu Bändern gruppiert
Aus dem Koeffizientenfeld extrahiert WaveScope die lokalen Maxima, rankt sie nach Stärke und kollabiert Duplikate (dieselbe Grenze erscheint ja auf mehreren benachbarten Skalen). Das Ergebnis ist eine sortierte Liste der strukturell wichtigsten Positionen in der Datei – sprachagnostisch, schnell, kein Parser nötig.
Reale Grenzen wie der Beginn einer Klasse erscheinen konsistent über mehrere Skalen hinweg – das unterscheidet sie von zufälligem Rauschen. Boilerplate-Regionen erhalten einen niedrigen Komplexitätsscore und können zusammengefasst oder übersprungen werden. Dichter, verzweigter Code erhält einen hohen Score und bekommt die volle Aufmerksamkeit des Agenten.
Was der Agent bekommt – und was das kostet
WaveScope wurde an realistischen Aufgaben auf seiner eigenen ~5.000-Zeilen-TypeScript-Codebasis getestet und mit dem klassischen Vorgehen verglichen (Greppen + Datei-Chunks lesen):
Aufgabe
Klassisch (Tokens)
WaveScope (Tokens)
Ersparnis
Struktur einer 854-Zeilen-Datei verstehen
~2.000
~750
−63 %
Tangled Code für Refactoring finden
~5.200
~436
−92 %
Architektonisch zentrale Dateien identifizieren
~2.900
~1.700
−41 %
Ein 128K-Token-Fenster würde für diese drei Aufgaben beim klassischen Ansatz 8 % seiner Kapazität verbrauchen. Mit WaveScope sind es 2 %. Und der Rechenaufwand für WaveScope selbst? Im Schnitt 3 Millisekunden pro Datei.
Ein 128K-Kontextfenster ist kein Freibrief. Je mehr drin ist, desto schwerer wird Fokussierung. WaveScope gibt dem Modell die Karte – nicht den vollen Karteninhalt.
WaveScope einbinden: Die drei großen Agenten
WaveScope ist ein MCP-Server und lässt sich in wenigen Minuten in jeden MCP-fähigen Agenten einbinden. Zuerst die globale Installation:
npm install -g wavescope-mcp
Claude Code (Anthropic)
Entweder per CLI-Befehl hinzufügen:
claude mcp add wavescope -- wavescope-mcp
Oder manuell in .claude/mcp_config.json im Projektverzeichnis (bzw. global unter ~/.claude/mcp_config.json):
Claude Code erkennt verfügbare MCP-Tools automatisch und kann sie ohne weiteres Zutun aufrufen. Im Prompt direkt ansprechen: „Nutze WaveScope, um die Struktur von src/ zu analysieren, bevor du etwas änderst.“
codex --mcp-server "wavescope:wavescope-mcp" "Analysiere Struktur von src/"
Google Antigravity 2.0
Antigravity 2.0, IDE und CLI teilen sich eine zentrale Konfiguration in ~/.gemini/config/mcp_config.json. Entweder direkt bearbeiten oder in der App: Agent-Panel → „…“ → MCP Servers → Manage MCP Servers → View raw config.
Hinweis: Antigravity nutzt für remote HTTP-Server serverUrl statt url – bei einem lokalen Binary wie WaveScope bleibt es aber bei command.
Den Agenten trainieren, wann er WaveScope nutzen soll
Die reine Konfiguration reicht nicht aus – der Agent muss auch wissen, wann er WaveScope einsetzen soll. Das geht über System-Anweisungen oder Custom Instructions. Eine bewährte Formulierung (auf Englisch, damit der Agent sie direkt versteht):
When navigating an unfamiliar codebase or working in large files (>100 lines),
always start with WaveScope's get_important_positions to get a structural overview
before opening any file. Use query_wavelet_context centered on the relevant line
before reading surrounding code. Use get_complexity_heatmap to identify
refactoring candidates before reading implementation details.
Fazit: Eine Karte, kein Teleskop
WaveScope löst kein LLM-Problem – es löst ein Navigations- und Kontextproblem. Die Idee, Wavelets für strukturelle Code-Analyse zu nutzen, ist ungewöhnlich clever: kein Parser, keine Sprachabhängigkeit, kein großer Compute-Aufwand. Nur Signalverarbeitung auf einem 1D-Score-Signal – und das Ergebnis ist eine hierarchische, multi-skalare Karte der Codebasis.
Ob das in der Praxis mit größeren, komplexeren Projekten genauso gut funktioniert wie im Blog-Artikel beschrieben, muss sich noch zeigen – das Repository hat erst drei Stars und wurde Anfang Juni 2026 veröffentlicht. Aber die Idee ist solide, der Code liegt offen, und die Integration dauert fünf Minuten.
Für alle, die LLM-Agenten in Code-Review-, Analyse- oder Refactoring-Workflows einsetzen: WaveScope ist einen Test wert.
Die SEO- und GEO-Branche produziert gerade enorm viele Inhalte über Messung. Fast täglich erscheinen neue Auswertungen, Benchmarks, Tool-Vergleiche, Prompt-Experimente und vermeintliche Best Practices. Das ist verständlich: Alle versuchen, ein neues Feld greifbar zu machen.
Trotzdem wissen wir erstaunlich wenig wirklich sicher.
Viele dieser Veröffentlichungen sind wertvoll als Beobachtung, als Hypothese oder als praktischer Erfahrungsbericht. Sie können inspirieren, Orientierung geben und Diskussionen anstoßen. Aber sie sind selten so angelegt, dass daraus belastbare, replizierbare Erkenntnisse entstehen. Häufig arbeiten sie mit kleinen Stichproben, unklaren Auswahlverfahren, fehlenden Baselines und Messdesigns, die plausibel wirken, aber wissenschaftlich kaum geprüft sind.
Das Problem ist nicht, dass Praxiswissen wertlos wäre. Das Problem ist, dass wir Praxiswissen oft so behandeln, als wäre es bereits Evidenz.
Wir sollten wissenschaftlicher arbeiten. Nicht, weil Wissenschaft besser klingt. Sondern weil sie uns zwingt, zwischen dem zu unterscheiden, was wir wissen, was wir vermuten und was wir nur überzeugend erzählen können.
Wissenschaftliches Arbeiten ist anstrengend, komplex, kompliziert und sehr kleinteilig. Man muss einen riesigen Aufwand für oft sehr kleine Erkenntnisse treiben. Aber genau diese kleinen Erkenntnisse sind dann — vorausgesetzt, man hat sauber gearbeitet — auch wirklich belastbar.
Und genau darum geht es mir in diesem Text: nicht darum, einzelne Menschen oder einzelne Methoden abzuwerten, sondern darum, den Unterschied zwischen plausibler Praxis und belastbarer Evidenz ernst zu nehmen.
Ein gutes Beispiel für eine echte Methodenfrage
Wie anspruchsvoll das in GEO wird, sieht man ausgerechnet an einem Beispiel, das ich ausdrücklich nicht als Negativbeispiel verstehe. Im Gegenteil: Es zeigt, wie eine ernsthafte methodische Diskussion überhaupt aussehen kann.
Ein von mir sehr geschätzter Kollege, Hanns Kronenberg, verfolgt bei der GEO-Messung einen klaren und nachvollziehbaren Ansatz: Er normalisiert Prompts. Aus einem Roheingang wie
„Hey ChatGPT, kannst du mir bitte sagen, welche Anbieter für X gut sind?“
wird sinngemäß
„beste Anbieter für X“.
Die Begründung dahinter ist gut: Rohprompts enthalten viel Varianz — Höflichkeitsfloskeln, Ich-Kontext, Tippstil, Formulierungslaune, Kontextreste. Wer ein Messinstrument bauen will, will diese Varianz nicht unkontrolliert in der Messung haben. Ein Instrument, das bei scheinbar gleichem Sachverhalt stark schwankt, ist schwer interpretierbar.
Normalisierung versucht, diese Störfaktoren zu reduzieren, damit das Messinstrument stabiler wird. Das ist keine naive Abkürzung und auch kein methodischer Fehlgriff. Es ist eine legitime Messentscheidung.
In einer Infografik auf LinkedIn sieht man schön, dass Hanns bei der Normalisierung keinen pauschalen Kahlschlag vornimmt, sondern Füllwörter, Höflichkeit und Kontextreste entfernt und aus vielen Rohvarianten Intent-/Constraints-Gruppen für wenige Standardformen bildet:
Genau deshalb ist dieses Beispiel interessant: nicht, weil Hanns hier „falsch“ liegt, sondern weil an einer guten Methode sichtbar wird, was Wissenschaft leisten müsste.
Wissenschaft müsste nicht behaupten, ob Normalisierung richtig oder falsch ist. Sie müsste prüfen, unter welchen Bedingungen Normalisierung ein valider Messproxy ist — und unter welchen Bedingungen nicht.
Aus einer Meinung wird eine testbare Hypothese
Das ist der entscheidende Schritt. Solange wir nur sagen „ich glaube, natürliche Prompts sind besser“ oder „ich glaube, normalisierte Prompts sind stabiler“, führen wir eine Meinungsdebatte. Interessant wird es erst, wenn wir daraus prüfbare Hypothesen machen.
Die These des Normalisierungsansatzes könnte man so formulieren:
C, also normalisierte, komprimierte Prompts, ist ein guter Low-Cost-Proxy für die Ergebnisverteilung echter Prompts.
Meine Gegenthese wäre:
B, also natürliche repräsentative Prompts, bildet die Ergebnisverteilung echter Prompts besser ab als künstlich normalisierte Prompts.
Schon diese Formulierung verändert die Debatte. Es geht nicht mehr darum, wer rhetorisch überzeugender klingt. Es geht darum, welche Methode die reale Prompt-Welt besser approximiert.
Und genau so beginnt wissenschaftliches Arbeiten: Eine plausible Behauptung wird so formuliert, dass sie an Daten scheitern darf.
Reliabilität ist nicht dasselbe wie Validität
In der Messtheorie unterscheidet man zwei Eigenschaften eines Instruments, die gerne verwechselt werden:
Reliabilität bedeutet: Misst ein Instrument konsistent?
Validität bedeutet: Misst es tatsächlich das, was es messen soll?
Ein Messinstrument kann sehr stabil sein und trotzdem an der Zielgröße vorbeimessen. Eine Waage, die immer gleich abweicht, ist konsistent — aber nicht deshalb automatisch gültig. Genau diese Unterscheidung ist hier wichtig.
Die Normalisierung priorisiert zunächst Reliabilität: weniger Rauschen, stabilere Werte, besser reproduzierbare Reports.
Die offene wissenschaftliche Frage betrifft die Validität: Misst der normalisierte Prompt noch hinreichend gut das, was echte Nutzerprompts in generativen Systemen auslösen? Oder entsteht durch die Reduktion ein eigenes, sehr sauberes Messobjekt, das in bestimmten Fällen von realer Nutzung abweichen kann?
Das ist kein Argument gegen Hanns’ Methode. Es ist die Frage, die man stellen muss, wenn man sie wissenschaftlich ernst nimmt.
Die prüfbare Annahme hinter Normalisierung
Formal betrachtet ist Normalisierung eine verlustbehaftete Kompression. Ein Rohprompt enthält nicht nur Intent, sondern auch Constraints, Stil, Kontext und vermeintliches Rauschen.
Man könnte ihn vereinfacht so darstellen:
Rohprompt X = Intent I + Constraints C + Stil S + Kontext K + Rauschen R
Der normalisierte Prompt ist dann eine Funktion davon:
N = f(X)
Diese Reduktion ist dann ein gutes Messsignal, wenn die weggeworfenen Bestandteile tatsächlich keine relevante Zusatzinformation für das Ergebnis enthalten. Anders gesagt: Sobald man den normalisierten Prompt kennt, dürfte der ursprüngliche Rohprompt keine zusätzliche Information mehr darüber liefern, welche Antwort, welche Quellen oder welche Zitate entstehen.
Statistisch ausgedrückt:
Y ⟂ X | N
Auf Deutsch: Sobald man den normalisierten Prompt kennt, liefert der ursprüngliche Rohprompt keine zusätzliche Information mehr über das Ergebnis. Stil, Kontext und Constraints wären dann tatsächlich nur Rauschen.
Genau das ist die zentrale empirische Frage.
Nicht: „Ist Normalisierung richtig oder falsch?“
Sondern: „Reduziert Normalisierung nur Rauschen — oder entfernt sie intentrelevantes Signal?“
Warum diese Frage bei GEO besonders wichtig ist
In der klassischen Suche war es oft plausibel, Suchanfragen stärker zu vereinheitlichen. Viele Varianten landeten auf ähnlichen SERPs, und Suchmaschinen hatten über Jahre gelernt, kurze, keywordartige Queries zu interpretieren.
Bei generativen Systemen ist das weniger selbstverständlich. Der Prompt ist nicht einfach nur der Input in ein Ranking. Er kann der Ausgangspunkt für eine ganze interne Verarbeitungskette sein: Umschreibung, Query Fan-out, Retrieval, Quellenbewertung, Antwortmodus, Zitierauswahl.
Die Oberfläche des Prompts kann also mehr sein als nur Rauschen. Ton, Kontext, Detailgrad, Constraints oder Nutzersituation können beeinflussen, welche internen Suchanfragen entstehen, welche Quellen herangezogen werden und ob eine Antwort eher beratend, erklärend, vergleichend oder transaktional ausfällt.
Wenn das stimmt, dann wäre Normalisierung in manchen Fällen ein sehr gutes Analysehilfsmittel, aber nicht zwingend die alleinige Grundlage einer Erfolgsmessung.
Noch einmal: Das ist keine Widerlegung. Es ist eine Hypothese.
Und Hypothesen sind genau dafür da, getestet zu werden.
Ein Experiment, das die Frage beantworten könnte
Der wichtigste Punkt wäre: Wir dürfen nicht einzelne Antworten vergleichen.
Eine einzelne Antwort ist bei generativen Systemen viel zu instabil. Sie kann durch Tageszeit, Modellversion, Session, Randomness, Suchindex, Personalisierung, Standort oder kleine Formulierungsdetails schwanken. Wer einzelne Antworten nebeneinanderlegt, macht aus Rauschen schnell eine Geschichte.
Sauberer wäre deshalb eine andere Frage:
Welche Prompt-Methode approximiert die Verteilung von Antworten, Quellen, Zitierungen, Marken-Nennungen und Empfehlungen aus echten Prompts am besten?
Das Grunddesign sähe so aus:
Gruppe A: echte Prompts
= Ground Truth / Referenzverteilung
Gruppe B: repräsentative natürliche Prompts
= komprimierter natürlicher Proxy
Gruppe C: normalisierte Prompts
= komprimierter intentbasierter Proxy
Gruppe D: zufällige Stichprobe echter Prompts
= Kontrollgruppe / harte Baseline
Dann misst man:
Wie nah liegt B an A?
Wie nah liegt C an A?
Wie nah liegt D an A?
Wenn B näher an A liegt, spricht das für die These, dass natürliche Repräsentanz für GEO aussagekräftiger ist. Wenn C gleich nah oder näher an A liegt, spricht das für Hanns’ These, dass Normalisierung ein guter Low-Cost-Proxy ist. Wenn D gewinnt, wäre der Befund besonders interessant: Dann wäre die beste Low-Cost-Methode möglicherweise gar keine künstliche Prompt-Erzeugung, sondern echtes Sampling.
Und wenn B, C und D alle stark von A abweichen, wäre auch das ein wichtiger wissenschaftlicher Befund: Einzelne Prompt-Proxies reichen für bestimmte GEO-Messungen womöglich grundsätzlich nicht aus.
Wichtig ist: In keinem dieser Fälle „verliert“ eine Person. Es verliert höchstens eine Annahme. Und genau das ist der Sinn wissenschaftlichen Arbeitens.
A ist nicht ein Prompt, sondern die Zielverteilung
Der häufigste Denkfehler wäre, A als einen „echten Prompt“ zu verstehen. Das wäre falsch. A ist die Referenzverteilung echter Prompts pro Intent.
Beispiel:
Intent:
Steuersoftware für Selbstständige vergleichen
A: 100 echte Prompts
- Welche Steuersoftware ist gut für Freelancer?
- Ich bin selbstständig, womit mache ich am besten meine Steuer?
- Taxfix oder WISO für Selbstständige?
- einfache Steuerapp für Freiberufler
- beste Software Steuererklärung Kleinunternehmer
- ...
Wichtig ist, dass dieses Verhältnis pro Intent-Gruppe gilt, nicht nur über das gesamte Experiment. Sonst kann es passieren, dass eine Methode bei manchen Intents über- oder unterrepräsentiert ist.
Noch sauberer: mit Holdout arbeiten
Ein häufiger methodischer Fehler wäre, aus allen echten Prompts die repräsentativen und normalisierten Prompts zu bauen und sie dann wieder gegen genau dieselbe Menge zu testen.
Das klingt harmlos, ist aber problematisch. Dann prüft man nur, ob eine Methode eine bekannte Prompt-Menge gut zusammenfassen kann. Interessanter ist die Frage, ob sie eine unbekannte reale Prompt-Verteilung gut approximiert.
Sauberer wäre deshalb:
A_total: alle echten Prompts
A_train: echte Prompts, aus denen B, C und D abgeleitet werden
A_test: echte Prompts, die B, C und D nachbilden müssen
Der Ablauf wäre:
1. Sammle echte Prompts.
2. Teile sie in Train und Test.
3. Erzeuge B, C und D nur aus Train.
4. Vergleiche B, C und D gegen Test.
Damit wird das Experiment methodisch deutlich stärker. Es prüft nicht nur Kompression, sondern Generalisierung.
Warum Gruppe D so wichtig ist
Neben A, B und C würde ich unbedingt eine vierte Gruppe ergänzen:
Gruppe D:
zufällige 10%-Stichprobe echter Prompts
D ist die wichtigste Benchmark, weil sie eine unangenehme, aber notwendige Frage beantwortet:
Wie gut wäre ich, wenn ich einfach 10 Prozent echte Prompts zufällig nehme und gar keine intelligente Repräsentation baue?
Diese Kontrollgruppe verhindert, dass man B oder C überschätzt. Eine kluge Methode muss nicht nur plausibel klingen. Sie muss besser sein als ein einfacher, billiger Zufallsgriff aus der echten Verteilung.
Die Interpretation wäre dann:
B besser als C:
Natürliche repräsentative Prompts approximieren A besser als Normalisierung.
C besser als B:
Normalisierte Prompts funktionieren als Messproxy besser.
B nicht besser als D:
Die natürliche Repräsentation bringt wenig gegenüber Zufall.
C nicht besser als D:
Normalisierung bringt wenig gegenüber Zufall.
B und C schlechter als D:
Echte natürliche Variation ist wichtiger als kuratierte Kompression.
B und C ähnlich nah an A:
Prompt-Reduktion funktioniert für diesen Intent-Typ grundsätzlich.
Das ist Wissenschaft in einer sehr nüchternen Form: Man baut ein Design, in dem die eigene Lieblingsmethode verlieren kann.
Was genau wird verglichen?
Nicht: „Ist die Antwort wortgleich?“
Das wäre der falsche Vergleich. Für GEO ist entscheidend, ob B, C oder D die relevanten Signale aus A nachbilden. Ich würde mindestens diese Outcome-Klassen messen:
A echte Prompts:
- Marke X wird in 38% der Antworten genannt
- Domain X wird in 12% der Antworten zitiert
- Wettbewerber Y wird in 44% empfohlen
- Vergleichsportale machen 35% der Quellen aus
- Herstellerseiten machen 20% der Quellen aus
B:
- Marke X 35%
- Domain X 14%
- Wettbewerber Y 41%
- Vergleichsportale 33%
- Herstellerseiten 22%
C:
- Marke X 58%
- Domain X 4%
- Wettbewerber Y 61%
- Vergleichsportale 12%
- Herstellerseiten 49%
In diesem Beispiel wäre B deutlich näher an A. C hätte dann womöglich weniger Rauschen, aber mehr Bias. Das wäre kein moralischer Befund, sondern ein methodischer: Die Normalisierung hätte in diesem Intent-Typ relevante Signale entfernt oder verschoben.
Zentrale Metriken
Pro Intent, Engine und Messzeitpunkt könnte man verschiedene Abweichungen berechnen.
A: Marke wird in 40% genannt
B: Marke wird in 36% genannt → Fehler: 4 Prozentpunkte
C: Marke wird in 55% genannt → Fehler: 15 Prozentpunkte
D: Marke wird in 43% genannt → Fehler: 3 Prozentpunkte
2. Citation Error
Für Domains und URLs wäre die Frage: Finden B, C und D dieselben Quellenlandschaften wie A?
Domain Share of Citations
URL Share of Citations
Top-k Citation Recall
Citation Jaccard Similarity
Nicht jede einzelne URL muss identisch sein. Aber die Verteilung der Domains und Quellentypen sollte ähnlich sein.
3. Recommendation Error
Für empfohlene Anbieter, Produkte, Tools oder Marken müsste man messen:
Welche Entities werden empfohlen?
Wie oft werden sie empfohlen?
In welcher Reihenfolge erscheinen sie?
Wie stark ist die Empfehlung?
Mögliche Metriken wären:
Top-k Entity Overlap
Ranking-Korrelation
NDCG
Share of Recommendation
4. Source-Class Distribution
Für Content-Strategie wäre besonders wichtig, ob dieselben Quellenklassen ausgelöst werden:
A zitiert:
30% Vergleichsportale
25% Herstellerseiten
20% Medien
15% Foren / Reddit
10% Behörden / Studien
Wenn normalisierte Prompts zum Beispiel viel häufiger Herstellerseiten triggern, natürliche Prompts aber eher Foren, Vergleichsportale oder Ratgeberseiten, dann ist das strategisch ein riesiger Unterschied.
5. Antwortmodus
Auch der Antworttyp sollte gemessen werden:
direkte Empfehlung
Vergleich
How-to
Liste
Ratgeberantwort
Definition
Warnung / Einschränkung
Kaufberatung
Ein normalisierter Prompt wie
beste steuersoftware selbstständige
kann ein anderes Antwortformat erzeugen als
Ich bin selbstständig und suche eine einfache Software für meine Steuererklärung. Was würdest du empfehlen?
Für GEO ist das relevant, weil Empfehlungen und Zitate oft vom Antwortmodus abhängen.
Nicht nur global, sondern nach Intent-Typ auswerten
Ein globaler Durchschnitt wäre wahrscheinlich zu grob. Viel spannender wäre eine Auswertung nach Intent-Typ.
Am Ende sollte nicht einfach dort stehen:
B ist besser als C.
Sondern eher:
Bei informationalen Intents ist C ähnlich gut.
Bei Empfehlungs-Intents ist B deutlich besser.
Bei transaktionalen Intents kippt C die Quellenlandschaft.
Bei lokalen Intents ist natürliche Formulierung entscheidend.
Bei einfachen Head-Intents reicht C oft aus.
Das wäre vermutlich der wertvollste Befund, weil er beiden Seiten gerecht würde. Normalisierung wäre dann nicht „falsch“ oder „richtig“, sondern unter bestimmten Bedingungen nützlich und unter anderen Bedingungen riskanter.
Aber auch das wäre nur eine Hypothese. Und genau deshalb müsste man sie testen.
Wie man B sauber konstruiert
Für repräsentative natürliche Prompts sollte B nicht einfach manuell geschrieben werden. Das wäre angreifbar und würde zu viel subjektives Bauchgefühl ins Experiment bringen.
B sollte aus A_train abgeleitet werden:
1. Echte Prompts pro Intent sammeln.
2. Embeddings bilden.
3. Innerhalb des Intents Subcluster finden.
4. Pro Subcluster den Medoid-Prompt wählen.
5. Optional leicht redaktionell glätten, aber natürlich lassen.
Ein Medoid ist der echte Prompt, der dem Zentrum eines Clusters am nächsten liegt. Dadurch ist B nicht ausgedacht, sondern repräsentativ für echte Formulierungen.
Beispiel:
Intent:
beste Steuersoftware für Selbstständige
Subcluster 1:
"Welche Steuersoftware ist gut für Freelancer?"
Subcluster 2:
"Ich bin selbstständig und brauche ein einfaches Tool für die Steuer."
Subcluster 3:
"WISO oder Lexware für Selbstständige?"
Subcluster 4:
"Beste Steuer App für Freiberufler Deutschland"
Subcluster 5:
"Steuererklärung Kleinunternehmer Software Empfehlung"
Dann besteht B aus echten, natürlichen Stellvertreterprompts. Das macht die Methode empirisch deutlich stärker als „ich formuliere nach Gefühl repräsentative Prompts“.
Wie man C fair konstruiert
Auch C sollte nicht unfair gebaut werden. Sonst testet man nicht die beste Version des Normalisierungsansatzes, sondern eine Karikatur davon.
Für Hanns’ Methode bräuchte man eine klare Normalisierungsregel, zum Beispiel:
Rohprompt:
Ich bin selbstständig und suche eine einfache Software für meine Steuererklärung. Welche Anbieter sind empfehlenswert?
Normalisiert:
steuersoftware selbstständige deutschland empfehlung einfach
Wichtig ist: C darf nicht absichtlich schlecht oder zu keywordhaft gebaut werden. Die faire Version wäre:
C = bestmögliche normalisierte Intent-Repräsentation
Nur dann testet man die eigentliche These ernsthaft.
Ein realistischer Pilot
Ein sinnvoller Pilot könnte so aussehen:
50 Intent-Gruppen
× 40 echte Prompts pro Intent für A_test
= 2.000 echte Prompts als Ground Truth
B:
4 repräsentative natürliche Prompts pro Intent
= 200 Prompts
C:
4 normalisierte Prompts pro Intent
= 200 Prompts
D:
4 zufällige echte Prompts pro Intent
= 200 Prompts
Dann pro Engine:
A: 2.000 Runs
B: 200 Runs
C: 200 Runs
D: 200 Runs
= 2.600 Runs pro Engine und Wiederholung
Bei vier Oberflächen:
ChatGPT
Perplexity
Google AI Mode
Google AI Overviews
ergibt das:
2.600 × 4 = 10.400 Runs pro Wiederholung
Mit drei Wiederholungen:
31.200 Runs
Das ist groß genug, um erste robuste Aussagen zu treffen. Und es zeigt zugleich, warum echte Wissenschaft in GEO so selten ist: Schon die Beantwortung einer einzigen Methodenfrage landet schnell im fünfstelligen Abfragebereich.
Auch das wäre noch kein perfektes Forschungsprogramm. Aber es wäre bereits deutlich näher an wissenschaftlicher Evidenz als das, was in unserer Branche oft als „Studie“ verkauft wird.
Wiederholungen, Zeit und Kontrolle
Wiederholungen sind nötig, weil KI-Antworten nicht deterministisch stabil sind. Ein sauberes Design müsste deshalb mindestens kontrollieren:
3 Wiederholungen pro Prompt
an mehreren Tagen
randomisierte Reihenfolge
neue Session pro Prompt
keine History
keine Personalisierung
gleiche Sprache
gleicher Standort
gleicher Device- und Browser-Kontext, soweit möglich
Sonst verwechselt man Prompt-Effekte mit Tages-, Modell-, Index- oder Session-Effekten.
Auch das ist ein wichtiger Teil wissenschaftlichen Arbeitens: Man versucht nicht nur, den Effekt zu finden, den man sehen möchte. Man versucht aktiv, alternative Erklärungen auszuschließen.
Was heißt „besser nachgebildet“?
Am Ende bräuchte man einen transparenten Gesamtscore, aber mit nachvollziehbaren Subscores. Zum Beispiel:
Für Content-Strategie würde man Quellenklassen und Themenmuster vielleicht stärker gewichten. Für reines GEO-Reporting eher Brand, Domain und Recommendation.
Dann erhält man pro Intent:
Fidelity_B_to_A
Fidelity_C_to_A
Fidelity_D_to_A
Und über alle Intents zum Beispiel:
B schlägt C in 37 von 50 Intent-Gruppen.
C schlägt B in 8 von 50 Intent-Gruppen.
Kein signifikanter Unterschied in 5 von 50 Intent-Gruppen.
D schlägt beide in 12 von 50 Intent-Gruppen.
Das wäre wesentlich aussagekräftiger als ein globaler Durchschnitt oder ein einzelnes Beispiel.
Die wichtigste Ergebnisdarstellung
Am Ende würde ich keine Siegergeschichte erzählen, sondern eine Matrix bauen:
Intent-Typ
B näher an A
C näher an A
D näher an A
Interpretation
Informational
45%
40%
15%
Normalisierung oft brauchbar
Empfehlung
70%
10%
20%
Natürliche Prompts klar besser
Vergleich
65%
15%
20%
Normalisierung verzerrt Rankings
Lokal
75%
5%
20%
Kontext entscheidend
How-to
50%
30%
20%
Gemischt
Branded
40%
35%
25%
Beide brauchbar
Genau solche Ergebnisse wären wertvoll. Nicht, weil sie eine Seite vernichten. Sondern weil sie differenzieren.
Vielleicht ist Normalisierung bei einfachen Informationsintents völlig ausreichend. Vielleicht ist natürliche Formulierung bei Empfehlungs-, Vergleichs- und Kaufberatungs-Intents deutlich näher an der Realität. Vielleicht ist bei lokalen Suchen Kontext entscheidend. Vielleicht ist bei bestimmten Head-Intents fast egal, wie man formuliert.
Das wäre keine Schwäche. Das wäre Erkenntnis.
Hypothesen vorab registrieren
Ein weiterer wissenschaftlicher Schritt wäre, die Hypothesen vorab festzulegen. Nicht erst nach den Daten erzählen, was man angeblich schon immer erwartet hat.
Ich würde vorab etwa diese Hypothesen formulieren:
H1:
Normalisierte Prompts weichen bei Quellen- und Zitierverhalten stärker von echten Prompts ab als repräsentative natürliche Prompts.
H2:
Der Unterschied ist bei Empfehlungs-, Vergleichs- und Kaufberatungs-Intents größer als bei einfachen Informations-Intents.
H3:
Normalisierte Prompts erzeugen stabilere, aber nicht zwingend repräsentativere Ergebnisse.
H4:
Repräsentative natürliche Prompts haben mehr Varianz, aber geringeren Bias gegenüber echten Prompts.
H5:
Eine zufällige 10%-Stichprobe echter Prompts ist ein harter Benchmark, den B und C schlagen müssen.
Auch hier geht es nicht darum, vorher recht zu haben. Es geht darum, sich selbst daran zu hindern, hinterher jede Beobachtung zur Bestätigung der eigenen Meinung umzudeuten.
Was an diesem Design wissenschaftlich ist
Das Experiment wäre nicht deshalb wissenschaftlich, weil es kompliziert klingt. Es wäre wissenschaftlich, weil es ein paar unbequeme methodische Mindeststandards erfüllt:
Es formuliert prüfbare Hypothesen.
Es definiert eine Ground Truth.
Es arbeitet mit Holdout-Daten.
Es vergleicht Verteilungen statt Einzelfälle.
Es nutzt eine Kontrollgruppe.
Es trennt Reliabilität von Validität.
Es kontrolliert Störfaktoren.
Es erlaubt, dass die eigene These scheitert.
Das letzte ist vielleicht der wichtigste Punkt. Wissenschaftliches Arbeiten bedeutet nicht, die eigene Meinung mit Zahlen hübscher zu machen. Es bedeutet, Bedingungen zu schaffen, unter denen man herausfinden kann, dass man falsch liegt.
Warum die Branche das selten macht
Vor diesem Hintergrund ist erklärbar, warum echte Evidenz in SEO und GEO selten ist. Nicht, weil alle unfähig wären. Sondern weil die Anreize dagegenstehen.
Belastbare Forschung ist teuer, langsam und liefert selten einfache Slogans. Sie produziert eher Sätze wie:
Bei Empfehlungs-Intents scheint natürliche Formulierung näher an realem Nutzerverhalten zu liegen, während Normalisierung bei einfachen Informations-Intents ausreichend stabil sein kann.
Das wäre wahrscheinlich näher an der Wahrheit. Aber es verkauft sich schlechter als:
Mach X und du gewinnst.
Die Branche belohnt klare, schnelle, handlungsleitende Aussagen. Wissenschaft belohnt vorsichtige, differenzierte, belastbare Aussagen. Diese beiden Logiken passen nicht gut zusammen.
Die typische SEO/GEO-Untersuchung tut deshalb oft fast spiegelbildlich das Gegenteil dessen, was methodisch nötig wäre: Sie arbeitet mit winzigen Stichproben statt mit Verteilungen. Sie vergleicht einzelne Antworten statt Ergebnisverteilungen. Sie hat keine Ground Truth, gegen die man prüfen könnte. Sie hat keinen Holdout. Sie hat keine Baseline. Sie misst oft nur einmal und verwechselt damit Modell- und Tagesschwankungen mit echtem Effekt. Und sie registriert keine Hypothesen vorab, sondern erzählt hinterher die Geschichte, die zu den Zahlen passt.
Auch das ist nicht als persönlicher Vorwurf gemeint. Viele dieser Auswertungen haben einen praktischen Zweck: Sie sollen Orientierung geben, Tools erklären, Hypothesen liefern oder Diskussionen anstoßen. Nur sollten wir sie dann auch als das behandeln — und nicht so tun, als wären sie bereits belastbare Evidenz.
Warum Hanns’ Beispiel trotzdem wichtig ist
Gerade deshalb finde ich die Debatte um Hanns’ Ansatz wertvoll.
Nicht, weil sie zeigt, dass jemand falsch liegt. Sondern weil sie zeigt, wie eine ernsthafte Methodendebatte aussehen kann.
Hanns trifft eine klare, begründete Messentscheidung. Diese Entscheidung hat eine nachvollziehbare Logik. Gleichzeitig lässt sich eine prüfbare Frage daran formulieren: Welche Informationen gehen durch die Normalisierung verloren, und sind sie für GEO-relevante Ergebnisse relevant?
Das ist viel mehr Wissenschaft, als die meisten Branchendebatten leisten.
Niemand muss dogmatisch behaupten: „Normalisierung ist falsch.“ Es reicht zu sagen: „Normalisierung ist eine starke und plausible Methode. Aber ihre Validität hängt an einer empirischen Annahme, die man prüfen sollte.“
Wenn C gewinnt, spricht das für Hanns’ Methode. Wenn B gewinnt, spricht das für natürliche Repräsentanz. Wenn D gewinnt, lernen beide Seiten etwas. In allen Fällen wäre die Branche klüger als vorher.
Genau so beginnt Erkenntnis.
Die eigentliche Frage
Die spannende Frage ist deshalb nicht nur:
Sollen wir Prompts normalisieren oder nicht?
Die größere Frage lautet:
Sind wir bereit, den Preis zu zahlen, den es kostet, etwas wirklich zu wissen?
Solange die Antwort meistens „nein“ lautet, wird die SEO/GEO-Branche weiter sehr viel publizieren und vergleichsweise wenig sicher wissen.
Das ist kein Vorwurf an Einzelne. Niemand kann jede Methode selbst vollständig validieren. Aber genau deshalb sollten wir sauberer unterscheiden zwischen dem, was wir wissen, dem, was wir vermuten, und dem, was wir nur übernommen haben.
Und jetzt mal ganz ehrlich: zu dir
Bevor du das auf „die Branche“ schiebst, dreh die Frage einmal auf dich selbst.
Wie viele Dinge hältst du für „wahr“ oder „richtig“, einfach weil ein Toolanbieter, eine Agentur oder ein:e Freelancer:in sie dir als Wahrheit verkauft hat? Wie viele Best Practices wendest du an, deren Herkunft du nie geprüft hast — weil sie alle sagen? Wie viel von dem, was in deinen Reports und Strategien als Gewissheit steht, hast du wirklich selbst hinterfragt? Getestet? Mit einer Baseline verglichen? An echten Daten validiert?
Und bei dem Rest — bei den meisten Punkten, ehrlicherweise: Woher weißt du eigentlich, dass es stimmt?
Im klassischen SEO war dieses Vertrauen irgendwann halbwegs vertretbar. Da gibt es mittlerweile zwei Jahrzehnte aus Versuch und Irrtum: Vieles wurde tausendfach durchgespielt, widerlegt, bestätigt, nachgeschärft. Aus diesem langen Reibungsprozess sind Best Practices entstanden, die man — mit Vorsicht — übernehmen kann, ohne jede einzelne selbst neu zu beweisen.
Im GEO gibt es das schlicht noch nicht. Keine gut abgehangenen, über Jahre erprobten, allseits akzeptierten Best Practices.
Was heute als „GEO-Wahrheit“ durch LinkedIn wandert, ist oft nur ein paar Monate alt, basiert auf einer Handvoll Beobachtungen an Systemen, die sich ständig verändern — und niemand hat es unter den Bedingungen geprüft, die es ernsthaft prüfen würden.
Hier ist Skepsis kein Zynismus. Sie ist methodische Hygiene.
Niemand kann alles selbst nachmessen, dafür ist der oben skizzierte Aufwand viel zu groß. Aber genau deshalb lohnt sich die ehrliche Unterscheidung: Was hast du geprüft, was hast du übernommen — und behandelst du beides im Alltag wirklich unterschiedlich?
Wer das ernst nimmt, sagt häufiger „das wissen wir noch nicht“ und seltener „das ist so“. Das ist unbequemer. Aber es ist der einzige Weg, auf dem aus einer Meinungsbranche langsam eine Erkenntnisbranche wird.
Im Februar habe ich die llms.txt zum Rohrkrepierer erklärt. Drei Monate später muss ich präzisieren: Als GEO-Maßnahme bleibt sie tot. Als Discovery-Datei für agentische Systeme könnte sie genau das werden, was Jeremy Howard ursprünglich im Sinn hatte.
Wer meinen Februar-Artikel „Die llms.txt ist tot“ gelesen hat, weiß: Ich habe wenig zimperlich argumentiert. 0,1 Prozent der KI-Bot-Requests in OtterlyAIs 90-Tage-Messung. John Mueller, der die Datei mit dem Keywords-Meta-Tag vergleicht. Vier strukturelle Gründe, warum kein KI-Suchsystem im Retrieval-Stack eine vom Seitenbetreiber kuratierte Inhaltsbeschreibung als vertrauenswürdiges Signal verwenden würde.
An dieser Analyse ändert sich nichts. Wer eine llms.txt erstellt, um besser in ChatGPT, Perplexity oder den Google AI Overviews zu erscheinen, verschwendet weiterhin Zeit. Aber drei Entwicklungen der letzten Wochen zwingen mich, die Frage anders zu stellen.
Signal 1: Google I/O 2026 — Search ist jetzt agentisch
Am 19. Mai hat Liz Reid auf der I/O das vorgestellt, was Google „a new era for AI Search“ nennt. Die nüchterne Übersetzung: Suche ist nicht mehr nur Retrieval. Suche wird Task-Ausführung.
Was Google angekündigt hat, ist in Summe ein Paradigmenwechsel:
Information Agents, die im Hintergrund 24/7 das Web nach nutzerdefinierten Kriterien beobachten und proaktiv Updates liefern — etwa beim Wohnungssuchen oder bei Sneaker-Drops.
Agentic Booking für lokale Dienstleistungen: Karaoke-Raum für sechs Personen am Freitagabend mit später Küche? Google sucht Preise und Verfügbarkeit zusammen und führt zur Buchung beim Anbieter. Für Kategorien wie Home Repair, Beauty oder Pet Care ruft Google die Anbieter „on your behalf“ an.
Agentic Coding direkt in der Suche über Antigravity und Gemini 3.5 Flash — mit generativer UI, die in Echtzeit zusammengebaut wird.
Mini-Apps in der Suche, die als Custom-Tracker oder Dashboard für wiederkehrende Aufgaben dienen.
Der entscheidende Punkt für unsere Frage: Diese Agenten besuchen Websites, navigieren durch URL-Strukturen, lesen Detailseiten, vergleichen, buchen, rufen an. Sie sind keine klassischen Indexer, die einmalig crawlen und in einem Embedding-Index landen. Sie sind Operatoren, die zur Inferenzzeit auf live Inhalte zugreifen — mit einem konkreten Task im Kontext.
Genau für diesen Anwendungsfall war llms.txt von Anfang an gedacht. Howards Originaltext spricht von „inference-time use cases“ und zielt explizit auf Tools wie Cursor und Claude Code. Was 2024 nach einem Nischen-Use-Case für Coding-Assistenten klang, ist 2026 die Standardoperation jedes Mainstream-Suchanbieters.
Signal 2: Chrome Lighthouse prüft die llms.txt
Am 5. Mai 2026 tauchte in den Chrome-Developer-Docs ein neuer Lighthouse-Audit auf: llms.txt, eingeordnet unter der Rubrik Agentic browsing audits.
Die Formulierung ist vorsichtig. Lighthouse markiert den Audit als „Not Applicable“, wenn die Datei fehlt — „providing the file is optional at the moment“. Geflagged wird nur, wenn der Server bei Abruf einen Fehler liefert. Das ist weit entfernt von einem Ranking-Faktor.
Trotzdem ist die symbolische Bedeutung erheblich. Erstens kommt diese Dokumentation aus dem Hause Google — dem gleichen Konzern, der im Februar via Mueller und Illyes explizit klargestellt hatte, dass keine offizielle Unterstützung geplant sei. Zweitens — und das ist der wichtigere Punkt — wird llms.txt unter „Agentic browsing audits“ einsortiert, nicht unter „SEO audits“. Die Kategorie zählt.
Lighthouse sagt damit: Wenn Agenten deine Seite besuchen, ist eine maschinenlesbare Zusammenfassung dessen, was deine Seite anbietet und wie sie strukturiert ist, ein hilfreicher Baustein. Ohne diese Datei verbringen Agenten mehr Zeit damit, die Seitenstruktur zu rekonstruieren. Das ist eine sehr andere Aussage als „die Datei hilft beim Ranking“.
Signal 3: Eine neue Use-Case-Kategorie wird sichtbar
Im Februar habe ich „publizieren“ und „konsumieren“ als Verwechslung beschrieben: Dass Anthropic, OpenAI und Perplexity llms.txt-Dateien auf ihren Developer-Docs haben, sagt nichts darüber aus, ob ihre Retrieval-Systeme die llms.txt anderer Sites lesen. Das stimmt weiterhin.
Was ich aber unterbelichtet habe: Es gibt einen dritten Modus jenseits von „publizieren für die eigene Sichtbarkeit“ und „konsumieren im Retrieval“.
Es gibt das Szenario, in dem ein Agent — aus welchem Grund auch immer — sich entschieden hat, deine Seite zu besuchen, und nun eine konkrete Aufgabe abarbeiten soll. Der Agent hat dich nicht „gefunden“, weil er deine llms.txt gelesen hat. Er hat dich gefunden, weil ihn der Nutzer dort hingeschickt hat oder weil ein klassisches Retrieval ihn dort hingeführt hat. Aber sobald er da ist, hat er ein Problem: Welche URLs sind die richtigen Einstiegspunkte für seine Aufgabe? Wie sind die Slugs aufgebaut? Welche Aktionen darf er ohne Bestätigung ausführen, welche nicht?
Für dieses Problem ist eine gut gepflegte llms.txt eine plausible Lösung. Nicht als Ranking-Signal. Sondern als Operating Manual.
Was meine ursprüngliche These nicht erfasst hat
Beides kann gleichzeitig wahr sein:
llms.txt als GEO-Hebel ist gescheitert und wird scheitern. Die strukturellen Gründe — Manipulationsanfälligkeit, Retrieval-Ineffizienz, Redundanz zur robots.txt, fehlende Adoption auf Consumer-Seite — gelten unverändert.
llms.txt als agentische Discovery-Datei ist im aufkommenden Browsing-Stack potenziell nützlich. Hier zählt nicht, ob ein Embedding-Index die Datei einmal pro Quartal crawlt. Hier zählt, ob ein Agent zur Inferenzzeit damit schneller zur richtigen URL kommt.
Diese zwei Anwendungen sind nicht das gleiche Produkt mit zwei Namen. Sie haben unterschiedliche Adressaten, unterschiedliche Erfolgskriterien und unterschiedliche Designprinzipien. Eine llms.txt, die als „Pitch an Crawler“ geschrieben ist, ist für agentische Nutzung untauglich. Eine llms.txt, die als „Bedienungsanleitung für Agenten“ geschrieben ist, hat in der GEO-Welt nichts verloren.
Wie eine agentische llms.txt aussieht: drei Beispiele aus dem deutschen Telefonbuchmarkt
Um zu zeigen, was ich meine, habe ich drei Beispieldateien für gut bekannte deutsche Verzeichnisdienste gebaut — Gelbe Seiten, Das Telefonbuch und Das Örtliche. Die Wahl ist kein Zufall: Branchen- und Personenverzeichnisse sind ein Lehrbuchfall für agentische Aufgaben und könnten den Plattformen zu neuer Relevanz für KI-Systeme verhelfen, wenn man nicht gerade Google mit Zugriff auf Google Maps oder Apple mit Apple Maps ist.
„Friseur in Berlin-Mitte mit Öffnungszeit Samstag“, „Rückwärtssuche zu dieser Telefonnummer“, „Notapotheke in der Nähe“ — das sind exakt die Tasks, die Information Agents und Agentic Booking aus Reids Keynote bedienen sollen.
Was in diesen Dateien steht, ist explizit keine Marketing-Beschreibung der Plattform. Es sind sechs Dinge:
Erstens: Eine knappe Intent-Beschreibung. Wofür ist diese Seite zuständig, wofür nicht? Beispiel aus der Datei für Das Örtliche: Lokale Kontakt-, Telefonbuch- und Branchensuche; für stark gewerbliche Dienstleisterauswahl kann Gelbe Seiten ergänzend sinnvoll sein. Das ist eine Routing-Empfehlung, keine Werbung.
Zweitens: URL-Patterns, die ein Agent direkt zur Resolution nutzen kann. Statt einen Agenten erst die Suchmaske parsen zu lassen, gebe ich ihm das kanonische Muster:
https://www.gelbeseiten.de/branchen/{branche-slug}/{ort-slug} für Branchen-Ortslisten
https://www.dastelefonbuch.de/Branchen/{branche-slug}/{ort-slug} mit dem Hinweis, dass Stadtteile via doppeltem Bindestrich angehängt werden (Berlin--Biesdorf)
https://www.dasoertliche.de/Themen/{thema-slug}/{ort-slug}.html mit Query-Fallback, wenn das Thema nicht kanonisch ist
Drittens: Normalisierungsregeln. „Frankfurt am Main“ wird in der einen Plattform mit URL-kodierten Leerzeichen geschrieben, in der anderen mit Bindestrichen verbunden. Umlaute werden mal kodiert, mal nicht. Berliner Bezirke folgen einem Sondermuster (berlin%20bezirk%20mitte). Ohne diese Hinweise rät der Agent — und scheitert in 30 Prozent der Fälle.
Viertens: Resolver-Workflows. „Nutzeranfrage zerlegen in Branche, Ort, optional Stadtteil und Zeitwunsch. Wenn ein kanonisches Thema bekannt ist, /Themen aufrufen, sonst Query-Fallback.“ Das ist Pseudocode für agentisches Verhalten.
Fünftens: Bestätigungs- und Datenschutzgrenzen. Bei Aktionen wie Anrufen, Reservieren, Routenplanung oder Kontaktanlage muss der Agent vor Ausführung den Nutzer bestätigen lassen. Personenbezogene Treffer dürfen nicht massenhaft profiliert werden. Diese Regeln gehören in die llms.txt, weil sie genau zur Inferenzzeit gebraucht werden, in der ein Agent gerade kurz davor ist, etwas Unwiderrufliches zu tun.
Sechstens: Discovery-Links. robots.txt, Sitemaps, Impressum, Datenschutz. Das ist nichts Magisches — aber es ist genau das, was ein Agent als Erstes braucht, um sich auf der Domain zu orientieren.
Was diese drei Dateien gemeinsam haben: Sie sind nicht „kuratierte Inhaltsbeschreibung gegenüber einem Crawler“. Sie sind eine API-artige Dokumentation der Site-Logik. Wer sie liest, ist nicht der Indexer, sondern der Operator.
Konkrete Empfehlungen für die nächsten Wochen
Wenn du heute überlegst, was du tun sollst, würde ich nach drei Kategorien sortieren:
Wenn du eine Entwickler-Dokumentation hast — JETZT. Wer eine API anbietet, ein SDK pflegt, ein Framework dokumentiert oder eine technische Spezifikation veröffentlicht, sollte heute eine llms.txt bereitstellen und idealerweise auch Markdown-Versionen der relevanten Dokumentationsseiten ausliefern (etwa unter /seite.md neben /seite.html). Das war Jeremy Howards Original-Use-Case, das ist das, wofür Mintlify, Anthropic und Cursor die Dateien haben, und das ist der Bereich, in dem die Adoption durch Coding Agents real ist. Hier zahlt sich die Investition unmittelbar aus, weil deine API von einem Cursor- oder Claude-Code-Nutzer schneller verstanden und korrekt eingesetzt wird.
Wenn du einen Service anbietest, der agentisch genutzt werden könnte — denk in Szenarien. Beispiele: Verzeichnisdienste, Buchungsplattformen, Marktplätze, lokale Dienstleister, Kartenanwendungen, Behörden-Services. Frag dich: Was würde ein Information Agent von Google bei einer typischen Nutzeranfrage auf meiner Seite tun müssen? Welche URLs sind die richtigen Einstiegspunkte? Welche Aktionen sind reversibel, welche nicht? Welche Datenschutzgrenzen muss ein Agent kennen? Daraus entsteht eine sinnvolle llms.txt, die — ob sie heute schon gelesen wird oder nicht — als interne Klärungsübung wertvoll ist.
Wenn du eine klassische Content-Site betreibst — abwarten und beobachten. Für News-Seiten, Magazine, Corporate Sites, Blogs gilt meine Februar-Analyse weiterhin: Eine llms.txt als Sichtbarkeits-Hebel zu pflegen ist Opportunitätskosten ohne nachweisbaren Nutzen. Wenn die Adoption sich verschiebt, lässt sich eine Datei in einer Stunde generieren. Wer jetzt Zeit investiert, sollte sie in Content-Qualität und Zitierfähigkeit stecken.
Was bleibt richtig
OtterlyAIs 0,1-Prozent-Zahl ist immer noch die belastbarste Datenquelle, die wir haben. Mueller und Illyes haben ihre Position nicht widerrufen. Die strukturellen Argumente gegen llms.txt als Retrieval-Signal — Manipulationsanfälligkeit, Effizienz-Probleme im Retrieval-Stack, Redundanz zur robots.txt — sind unverändert gültig.
Wer nach diesem Artikel zurück ans Whiteboard geht und in den nächsten GEO-Audit „llms.txt erstellen und optimieren“ als Workstream schreibt, hat ihn missverstanden. Die llms.txt ist weiterhin kein Ranking-Hebel. Sie wird auch keiner werden.
Fazit
Mein Februar-Titel war zugespitzt. Das war Absicht, und die Pointe trifft die Sache, die ich angreifen wollte: llms.txt als GEO-Maßnahme.
Was ich nicht ausreichend gewürdigt habe: Mit der Verschiebung von „Search als Retrieval“ zu „Search als Task-Ausführung“ entsteht eine zweite Klasse von Nutzungsszenarien. In diesen Szenarien ist eine gut gepflegte llms.txt keine Marketing-Datei, sondern eine Bedienungsanleitung. Sie wird nicht von einem Crawler gewichtet — sie wird von einem Operator gelesen, der gerade eine Aufgabe abarbeitet.
Diese Lesart ist näher an Jeremy Howards Originalvorschlag von September 2024 als die GEO-Interpretation, die im Frühjahr 2025 viral ging. Vielleicht war die llms.txt nie tot. Vielleicht war sie nur in einer Diskussion gefangen, die mit ihrem eigentlichen Zweck wenig zu tun hatte.
Wenn die agentische Suche das wird, was Google auf der I/O versprochen hat, dann werden wir alle in den nächsten Monaten darüber nachdenken, welche URLs unserer Sites für welche Tasks die richtigen sind — und wie wir das einem Agenten in einer halben Seite Markdown erklären. Das ist eine Konversation, die es wert ist, geführt zu werden. Sie hat nur nicht das Etikett verdient, unter dem sie 2025 vermarktet wurde.
Wer derzeit einen Artikel über KI-SEO oder einen GEO-Audit liest, findet sie fast immer: die Empfehlung, Schema.org Markup einzubauen, „damit Ihre Inhalte mit dem Knowledge Graph verknüpft werden“ und „KI-Suchsysteme Ihre Entitäten besser verstehen“. Sie klingt plausibel, ist technisch sauber formuliert und lässt sich gut verkaufen. Sie ist nur leider in dieser Pauschalform irreführend – und zwar genau für die Systeme, für die sie heute besonders häufig in Stellung gebracht wird: ChatGPT, Perplexity und Claude.
Dieser Beitrag prüft, was die Empfehlung tatsächlich verspricht, was die öffentlich dokumentierte Architektur der relevanten Systeme dazu sagt und was unabhängige Tests zeigen.
Das Ergebnis ist nicht „Schema ist tot“ – sondern: Schema.org wirkt sehr unterschiedlich, je nachdem, in welches System und auf welcher Ebene man hineinschaut. Wer die Empfehlung pauschal ausspricht, verkauft ein Versprechen, das die Evidenz so nicht trägt.
Was die Empfehlung eigentlich behauptet
Die populäre Version geht ungefähr so: Wenn ich auf meiner Website Organization, Article, Product, FAQPage oder Person als JSON-LD ausspielt, werden meine Entitäten und Aussagen in den Knowledge Graph eingespeist. Dadurch erkennt „Die KI“ [sic!] meine Inhalte als „Entitäten“ und ziehen sie als Quellen für KI-Antworten heran. Schema.org wird damit zum semantischen Backbone der KI-Sichtbarkeit erklärt.
Diese Erzählung verschmilzt mindestens drei Annahmen, die einzeln geprüft werden müssen:
Dass es einen einzigen, gemeinsamen „Knowledge Graph“ gibt, in den Inhalte eingespeist werden.
Dass Schema.org-Markup tatsächlich der Eingangskanal in diese Strukturen ist.
Dass die Einspeisung sich in Form von KI-Zitaten und Antwortpräsenz bemerkbar macht.
Alle drei Annahmen sind im Detail brüchiger, als die SEO-Standardrhetorik nahelegt.
„Der Knowledge Graph“ ist eine Fiktion – es gibt mehrere, aber nicht überall einen!
Der erste Punkt ist begrifflich, aber folgenreich. Wenn man die öffentliche Produktdokumentation der relevanten Anbieter sichtet, ergibt sich ein eindeutiges Bild:
Eine dokumentierte produktive Knowledge-Graph-Nutzung lässt sich vor allem bei Google und Microsoft belegen.
Google beschreibt seinen Knowledge Graph ausdrücklich als System mit über 500 Milliarden Fakten zu fünf Milliarden Entitäten, in das Informationen aus dem Web, aus offenen und lizenzierten Datenbanken sowie aus speziellem strukturierten Markup einfließen. Microsoft dokumentiert für Bing seit 2013 Satori als Entity- und Knowledge-Repository und beschreibt im Prometheus-Ansatz die Kombination aus Bing-Index, Ranking-, Answers- und Entity-Systemen.
Bei OpenAI, Perplexity und Anthropic findet sich in der öffentlich zugänglichen Dokumentation nichts Vergleichbares.
Das sind RAG-, Index- und Connector-Architekturen, keine offengelegten Knowledge Graphs.
Daraus folgt eine simple, aber für die populäre Empfehlung unangenehme Konsequenz:
Wer „Verknüpfung mit dem Knowledge Graph“ als universellen GEO-Hebel verkauft, suggeriert eine Infrastruktur, die bei drei der fünf großen KI-Systeme schlicht nicht dokumentiert ist. Das macht die Empfehlung nicht automatisch falsch – aber sie ist nicht das, was sie zu sein vorgibt.
Vier Ebenen, auf denen Schema wirken könnte – und wo es das tatsächlich tut
Ein Grund, warum die Schema-Debatte so widersprüchlich verläuft, ist, dass dieselben Tests immer wieder auf falsche Ebenen verallgemeinert werden. Es lohnt sich, vier technische Ebenen sauber zu trennen:
Training und Parametrisierung – fließen strukturierte Daten in die Modellgewichte ein?
Crawling und Indexierung – wird Schema beim Aufbau eines Such-/Entity-Index ausgewertet?
Retrieval und Grounding – nutzt das System Schema, wenn es zur Antwortzeit Dokumente auswählt?
Rendering und Zitation – beeinflusst Schema, wie die Antwort und die Quellenangaben aussehen?
Die meisten populären Schema-Tests messen Ebene 3 und 4 und verallgemeinern dann auf Ebene 1 und 2. Das ist methodisch riskant. Wenn ein Live-Fetch-Test zeigt, dass ChatGPT versteckte JSON-LD-Daten beim Abruf einer einzelnen Seite ignoriert, beweist das nicht, dass strukturierte Daten in Training oder Index nirgendwo eine Rolle spielen. Umgekehrt beweist die Existenz von Googles Knowledge Graph nicht, dass jedes JSON-LD-Snippet auf einer mittelgroßen Website tatsächlich Einfluss auf AI Overviews hat.
Mit dieser Differenzierung ergibt sich folgendes Bild:
Bei Google wirkt Schema vor allem auf Ebene 2 und 4: Beim Verstehen von Seiten, bei der Entity-Disambiguierung, bei Rich Results, Knowledge-Panel-Elementen, Logos und Produkt-/Local-Surfaces. Google sagt zugleich ausdrücklich, dass es keine Sonderanforderungen und kein spezielles Schema-Markup für AI Overviews oder AI Mode gibt. Schema ist hier ein Verstehens-, Appearance- und Entity-Signal – kein eigenständiger Rankingfaktor für generative Antworten.
Bei Microsoft Copilot ist die Lage ähnlich: Bing dokumentiert die Nutzung von Structured Data zum Verstehen, unterstützt JSON-LD, akzeptiert spezielle Formate wie ClaimReview und bindet IndexNow an strukturierte Produktdaten an. Wer in Copilot-Antworten sichtbar werden will, profitiert hier von realer, dokumentierter Architektur – und kann seit Anfang 2026 im AI Performance Dashboard der Bing Webmaster Tools sogar nachvollziehen, welche Grounding Queries Copilot dazu bringen, eigene Inhalte zu zitieren.
Bei ChatGPT gibt es exakt einen klar dokumentierten Fall, in dem strukturierte Daten als Eingangskanal beschrieben sind: Commerce, über Product Feeds und – bei Shopify-Händlern – den Shopify Catalog. Für klassische redaktionelle Webseiten existiert keine vergleichbare offizielle Aussage. Eine Ahrefs-Untersuchung an 1.885 Seiten fand, dass das nachträgliche Hinzufügen von JSON-LD keinen robusten Zitationszuwachs in ChatGPT brachte. Ein searchVIU-Test deutete zusätzlich darauf hin, dass ChatGPT bei Live-Fetches sichtbares HTML verarbeitete, aber versteckte JSON-LD-, Microdata- und RDFa-Daten ignorierte.
Bei Perplexity existiert ebenfalls keine offizielle Aussage, dass Schema.org die Antwortauswahl verbessert. Die unabhängigen Tests zeigen, dass Perplexity primär aus dem eigenen Index antwortet und versteckte Schema-Daten in Antwort-Fetches nicht extrahiert. Spannend ist allerdings: Perplexitys Zitate überlappen stärker mit klassischen Top-Rankings als bei jedem anderen KI-Assistenten – fast ein Drittel der Perplexity-Zitate stammt aus Seiten, die für dieselbe Anfrage auch in Googles Top 10 ranken. Wer Perplexity-Sichtbarkeit will, betreibt also vor allem klassische SEO.
Bei Claude ist die Evidenz am dünnsten und am skeptischsten. Anthropic dokumentiert Web Search, Contextual Retrieval und Connectors/MCP – keinen Knowledge Graph. Im searchVIU-Test konnte Claude selbst sichtbare Preisangaben nicht sauber extrahieren und versteckte JSON-LD/Microdata/RDFa ebenfalls nicht nutzen. Eine dedizierte Webmaster-Dokumentation analog zu OAI-SearchBot oder Bings AI-Performance-Reports existiert nicht.
Was die Studien wirklich zeigen – und was nicht
Drei Befunde aus der unabhängigen Forschung sind für die Bewertung der Schema-Empfehlung besonders relevant.
Erstens die bereits erwähnte Ahrefs-Studie: Sie ist eines der wenigen Quasi-Experimente in diesem Feld und zeigt, dass das bloße Nachrüsten von JSON-LD keinen robusten Effekt auf KI-Zitate in Google AI Mode oder ChatGPT hat. Das widerlegt nicht jede mögliche Wirkung von Schema – aber es widerspricht dem Versprechen, Schema sei der Hebel für KI-Sichtbarkeit, sehr direkt.
Zweitens die Ahrefs-Folgestudie zu 1,4 Millionen ChatGPT-Prompts: ChatGPT ruft viele URLs ab, zitiert aber nur etwa die Hälfte; was am Ende zitiert wird, kommt überwiegend über den allgemeinen Search-Pfad, und Titel- bzw. URL-Relevanz zu internen Fan-out-Fragen scheint wichtiger zu sein als Snippet-Felder. Das ist eine harte Botschaft: Selbst wenn eine Seite in der KI-Antwortpipeline ankommt, entscheidet eher klassische Search-Logik über die Zitation als strukturierte Daten.
Drittens die searchVIU-Direkt-Fetch-Tests: Sie zeigen, dass Live-Fetch-Systeme sichtbares HTML typischerweise besser verarbeiten als verstecktes Schema. Auch hier ist die Reichweite begrenzt – Schema kann in Index oder Training trotzdem genutzt werden – aber für den konkreten Antwortmoment ist sichtbarer Text die belastbarere Wette als versteckte Markup-Ebenen.
Daneben gibt es Beobachtungsstudien wie die GEO-16-Arbeit zu Google AIO und Perplexity, die Korrelationen zwischen Metadata, Freshness, semantischem HTML, Structured Data und Citation-Wahrscheinlichkeit findet. Solche Korrelationen sind interessant, aber keine Kausalbeweise – und die Studien selbst formulieren das deutlich vorsichtiger als die SEO-Kurzfassungen, die später daraus zitieren. Eine medizinische RAG-Untersuchung zeigt zudem, wie stark bereits kleine Formulierungsänderungen in der Query die Quellenauswahl in Google AIO und Perplexity verschieben können – ein weiterer Grund, einzelnen Tests nicht zu viel Erklärungskraft zuzuschreiben.
Eine wichtige Einschränkung gilt für alle diese Befunde: Wir sehen meist nur die finale Zitation, nicht das vollständige Candidate Set. Dass eine Seite nicht zitiert wird, heißt nicht, dass sie keinen Einfluss auf die Antwort hatte. Diese Attributionslücke macht jede Aussage über die Wirkung strukturierter Daten methodisch fragil – auch die kritische.
Wo Schema.org weiter sinnvoll bleibt
Wer aus alldem ableitet, Schema sei nutzlos, überzieht ebenfalls. Es gibt klar belegte, eng umrissene Wirkbereiche, in denen Schema.org weiterhin hohe Priorität verdient – nur eben nicht unter dem Label „Knowledge-Graph-Verknüpfung“, sondern unter ihren tatsächlichen Funktionen.
Für Google und Bing bleibt Schema relevant für Rich Results, Knowledge-Panel-Elemente, Logo-Darstellungen, Local- und Product-Surfaces, Fact-Check-Labels und Entity-Disambiguierung. Organization-Markup wird von Google explizit als Mittel zur Disambiguierung einer Organisation beschrieben. Bei mehrdeutigen Markennamen, internationalen Niederlassungen oder konkurrierenden Wikipedia-Einträgen ist sauberes Organization-Markup mit sameAs-Verweisen und konsistenten IDs ein realer Hebel.
Wer Produkte in ChatGPT-Shopping platzieren will, sollte Produktfeeds, saubere Produktentitäten und aktuelle Katalogdaten priorisieren – das ist der eine Bereich, in dem OpenAI selbst Structured Data als Genauigkeits- und Relevanzsignal adressiert.
Für alle Google-/Bing-orientierten Use Cases sind Snippet-Kontrollen ein unterschätzter Hebel. nosnippet, max-snippet und data-nosnippet wirken bei Google ausdrücklich auch auf AI Overviews und AI Mode; Bing unterstützt data-nosnippet explizit für Search- und Copilot-Antworten und beschreibt dabei einen wichtigen Vorteil: Inhalte bleiben indexierbar und rankingfähig, erscheinen aber nicht in KI-generierten Antworten. Für Paywalls, Rechtstexte, volatile UGC-Blöcke oder sensible Tabellen ist das oft wertvoller als jedes zusätzliche Markup-Feld.
Was die Priorität tatsächlich verdient
Wenn man die Evidenz ernst nimmt, ergibt sich eine ziemlich nüchterne Prioritätenfolge für KI-Sichtbarkeit, in der Schema.org weiter vorkommt – aber nicht an erster Stelle:
Vor allem anderen kommt maschinenlesbare Sichtbarkeit im sichtbaren HTML: indexierbare Seiten, saubere Titel, klare Heading-Struktur, sichtbare Definitionen, Tabellen und FAQ-Blöcke, konsistente Entitätsbenennung im Fließtext, logische Kanonisierung und aktuelle Inhalte. Google sagt in seinem Guide zur Optimierung für generative AI-Suche explizit, dass seine generativen Funktionen auf den normalen Search-Systemen aufbauen; Bing empfiehlt zusätzlich klare Strukturen, Tabellen und FAQs für AI-Zitierbarkeit. Das ist die Schicht, die in Live-Fetch-Szenarien tatsächlich verarbeitet wird.
Dann folgt Aktualitätsinfrastruktur: Merchant Center und Business Profile für Google, IndexNow und Bing Places für Microsoft, direkte Produktfeeds für ChatGPT-Commerce. Wenn Preise, Verfügbarkeit, Öffnungszeiten oder regulatorische Fakten häufig wechseln, ist Aktualität fast immer wichtiger als noch ein weiteres Markup-Feld.
Erst danach kommt strukturierter Entity-Aufbau dort, wo er nachweislich konsumiert wird: Für Google und Bing sind Organization, Product, Article, Review, ClaimReview, Local-/Business-Daten und Knowledge-Panel-nahe Entitätssignale wertvoll. Für OpenAI sind es Product Feeds. Für Claude und Perplexity bleibt strukturierte Webauszeichnung im öffentlichen Web sekundärer als Sichtbarkeit, Frische und Klarheit.
Schließlich Kontrolle statt Totalfreigabe: bewusster Einsatz von nosnippet, max-snippet und data-nosnippet für Inhalte, die zwar ranken sollen, aber nicht in KI-Antworten erscheinen dürfen.
Wer die Empfehlung trotzdem ausspricht, schuldet seinen Kunden drei Klarstellungen
Es gibt gute Gründe, Schema.org weiter zu empfehlen. Es gibt aber keine guten Gründe, die populäre Erzählung von der „Verknüpfung mit dem Knowledge Graph“ als universellen GEO-Hebel unkommentiert weiterzugeben. Wer die Empfehlung 2026 ausspricht, schuldet seinen Kunden mindestens drei Klarstellungen:
Welcher Knowledge Graph eigentlich gemeint ist. Bei Google und Bing ist die Antwort konkret, bei ChatGPT, Perplexity und Claude existiert keine öffentlich dokumentierte Entsprechung.
Auf welcher Ebene Schema wirken soll. Verstehen und Entity-Disambiguierung im Index ist plausibel; direkte Zitations- oder Rankinghebel für generative Antworten sind nicht belegt und werden von Google selbst dementiert.
Welche Hebel daneben mindestens genauso wichtig sind. Sichtbares HTML, Frische-Inhalte und -Infrastruktur, Bot-Zugang, Snippet-Kontrolle und – im Commerce – direkte Produktfeeds liefern in vielen Fällen mehr ROI als ein weiteres JSON-LD-Snippet.
Die ehrliche Empfehlung für 2026 lautet daher nicht „Schema einbauen, damit Sie im Knowledge Graph landen“. Sie lautet: Schema dort einsetzen, wo Suchsysteme es nachweislich konsumieren, mit klarem Bewusstsein dafür, dass „die KI-Suche“ kein einheitliches Ziel ist, sondern fünf unterschiedlich gebaute Systeme mit unterschiedlichen Eingangskanälen. Wer das nicht differenziert, verkauft eine semantisch hübsche Geschichte – und enttäuscht damit Kunden, die in der Praxis messbare Sichtbarkeit suchen.
Google hat auf der I/O 2026 nicht einfach Updates verkündet. Google hat – endgültig und unmissverständlich – die Suche, wie wir sie kannten, beerdigt. An ihre Stelle tritt ein System aus Agenten, generativer UI, persistenten Mini-Apps und einem eigenen Bezahlprotokoll für KI. Wer als Marketer, SEO oder Markenverantwortliche:r noch glaubt, das Spielfeld bleibe ein Ranking aus zehn blauen Links mit aufgesetzter „AI Overview“, sollte sich die Keynote genau ansehen.
Dieser Beitrag fasst die wichtigsten Ankündigungen zusammen – mit klarem Fokus auf das, was für Sichtbarkeit, Traffic und Messbarkeit zählt.
Die neue Realität in Zahlen
Bevor wir in die Features gehen, drei Zahlen, die den Maßstab setzen:
AI Overviews: über 2,5 Milliarden monatliche Nutzer:innen.
AI Mode: in rund einem Jahr über 1 Milliarde monatliche Nutzer:innen, Queries verdoppeln sich Quartal für Quartal.
Search insgesamt: laut Google im letzten Quartal auf Allzeithoch.
Das letzte Detail ist strategisch entscheidend. Google argumentiert: Sobald Nutzer:innen verstehen, dass sie „alles“ fragen können, fragen sie auch mehr – nicht weniger. Die These „KI killt Search“ stimmt also nicht. Die These „KI killt Search, wie wir sie messen“ stimmt sehr wohl.
Der perfekte Long-Tail – und das Ende klassischer Keyword-Logik
Wenn jede Anfrage individuell, dialogisch und kontextabhängig ist, wenn auf jede Antwort Folgefragen geschehen, dann wird der Long-Tail nicht nur länger – er wird einzigartig. Prompts statt Keywords. Sessions statt Suchanfragen. Bedürfnisse statt Volumen.
Was bedeutet das für Messbarkeit?
Klassische Volumendaten verlieren ihren Ankerwert. Was man nicht aggregieren kann, kann man auch nicht ranken.
Folgefragen innerhalb eines AI Overviews oder eines AI Modes sind für Dritte praktisch unsichtbar – sie verlassen die Search-Box nicht.
Es bleibt im Wesentlichen ein Weg: synthetische, möglichst repräsentative Prompt-Kandidaten erzeugen und das Antwort- und Zitierverhalten messen, um zumindest das Potenzial einer Domain in KI-Antworten zu quantifizieren.
Wer GEO/AEO ernst nimmt, baut sich gerade jetzt diese Prompt-Sets auf. Wer noch auf Sistrix-Sichtbarkeitsindex und Ranktracking allein vertraut, bekommt in den kommenden Monaten ein Datenproblem.
Search Box, AI Overviews, AI Mode: drei Dinge verschmelzen
Google sortiert die Search-Oberfläche neu:
1. Die neue intelligente Search Box – laut Google das größte Upgrade der ikonischen Eingabezeile seit über 25 Jahren. Sie schlägt nicht mehr nur Autocompletes vor, sondern Nuancen, an die Nutzer:innen noch gar nicht gedacht haben, und nimmt Text, Bilder, Dateien und Videos parallel an.
2. AI Overviews und AI Mode wachsen zusammen – nahtlos, kontexterhaltend. Vom klassischen Ergebnis mit Overview direkt in eine Folgefrage im AI Mode, ohne Bruch, ohne Verlust der bisherigen Recherche. Links und Quellen sollen relevanter für das werden, was Nutzer:innen tatsächlich weiter erkunden.
3. AI Mode läuft jetzt auf Gemini 3.5 – mit neuen agentischen Fähigkeiten und der Breite des Webs, das Google nach eigenen Angaben mit über 1 Milliarde Fakten-Updates pro Minute aktuell hält.
Für SEO heißt das: Das Spiel verlagert sich vom „Klick auf die Seite“ hin zum „Zitiert werden in einer dialogischen Antwort“. Die Frage ist nicht mehr nur, ob eine URL rankt, sondern ob sie als Quelle erkannt, als vertrauenswürdig eingestuft und in eine sich entwickelnde Konversation eingewoben wird.
Search Agents: 24/7 im Hintergrund
Google hat die „era of Search agents“ ausgerufen. Nutzer:innen können in Search mehrere Agenten erstellen, die kontinuierlich für sie arbeiten:
Ein Finanz-Agent, der Bedingungen wie „Biotech-Aktien mit P/E unter 15, positivem Cashflow und geringer Verschuldung“ überwacht und bei Marktbewegungen synthetisierte Updates mit Quellen aus News, Social und Research-Plattformen liefert.
Ein Wohnungssuche-Agent, der aus einem Brain-Dump Kriterien zieht und Web, Portale, Social und Foren kontinuierlich scannt.
Ein Sneaker-Agent, der Blogs und den Shopping Graph überwacht, damit kein Drop verpasst wird.
Für Marken bedeutet das: Sichtbarkeit findet nicht mehr nur statt, wenn jemand sucht. Sie findet statt, wenn ein Agent für jemanden sucht – rund um die Uhr. Wer in diesen Agenten-Workflows nicht als belastbare Quelle auftaucht, fällt aus der Customer Journey raus, bevor sie überhaupt beginnt. Verfügbarkeit: Sommer.
Generative UI: Search baut die Antwort, die sie braucht
Hier wird es radikal. Google bringt Antigravity und Gemini 3.5 Flash direkt in Search. Resultat: Auf eine Frage wird nicht mehr eine Antwort gefunden, sondern eine Antwort gebaut – dynamische Layouts, interaktive Widgets, ganze Erlebnisse, jeweils maßgeschneidert für die Frage.
In der Demo erzeugte Search zu „Wie beeinflussen schwarze Löcher die Raumzeit?“ ein interaktives Visual. Bei der Folgefrage zu binären schwarzen Löchern entstand in Echtzeit ein neues Visual mit Parametern für orbitale Distanz und Massenverhältnis. Im Hintergrund: Gemini 3.5 Flash plant die Antwort, entwirft das Layout, recherchiert, schreibt und deployt Code in einer sicheren, containerisierten Umgebung.
Das ist „agentic coding at the scale of Search“. Kostenlos. Für alle. Im Sommer.
Konsequenz: Wenn die Antwort selbst eine kleine App ist, ist die zentrale Frage für Inhalteanbieter nicht mehr „wie kommen Nutzer:innen auf meine Seite“, sondern „liefere ich strukturierte, verlässliche, zitierfähige Daten, aus denen Google diese Apps bauen kann“.
Mini-Apps in Search: persistente Erlebnisse
Search bekommt einen Zustand. Aus einer einfachen Frage nach Familienaktivitäten entsteht ein Weekend Planner in Search, der mit Personal Intelligence Gmail, Photos und Calendar nutzt und Fahrzeiten, Wetter, Kinderpräferenzen, Reservierungen und Maps berücksichtigt. Per Prompt lässt sich der Plan weiter anpassen, teilen, in Familienkalender exportieren.
Vergleichbare „Mini-Apps“ sollen für Hochzeitsplanung, Umzug und andere länger laufende Aufgaben entstehen. Generative UI für alle im Sommer; vollständige Custom-Build-Erfahrungen zunächst für zahlende Abonnent:innen.
Wer heute Content für „Inspiration“, „Vergleich“ und „Planung“ erstellt, sollte sich fragen: Welche Schicht davon kann eine Mini-App in Search übernehmen – und wo bleibt mein Mehrwert?
Agentic Commerce: UCP, AP2, Universal Cart
Shopping ist der Bereich, in dem Google die agentische Logik am konsequentesten durchzieht. Drei Bausteine:
Universal Commerce Protocol (UCP) – ein offener Standard für agentisches Commerce, von Google als „HTTP-Moment“ inszeniert. Es gibt Agenten und Systemen eine gemeinsame Sprache für Produktsuche, Checkout und Sendungsverfolgung. Neu an Bord: Amazon, Meta, Microsoft, Salesforce und Stripe. Geplant ist die Ausweitung auf Hotels, lokale Food-Delivery, YouTube und weitere Produkte; UCP-Experiences kommen in den kommenden Monaten u. a. nach Kanada, Australien und UK.
Agent Payments Protocol (AP2) – die Bezahlschicht für agentisches Handeln. Nutzer:innen setzen Grenzen (Marken, Produkte, Budget); wenn diese erfüllt sind, kann der Agent kaufen. AP2 will Accountability schaffen: verifizierbare Verbindung zwischen Nutzer, Händler und Payment Processor, fälschungssichere digitale Mandate, abgeschirmte Zahlungsdaten. Rollout startet mit Gemini Spark.
Universal Cart – ein intelligenter Warenkorb über Händler und Services hinweg. Produkte werden hinzugefügt, während Nutzer:innen in Search browsen, mit Gemini chatten, auf YouTube schauen oder Gmail lesen. Der Cart findet Deals, zeigt Preisverläufe, meldet wieder verfügbare Produkte und erkennt Kompatibilitätsprobleme (Beispiel aus der Demo: PC-Komponenten). Checkout direkt auf Google mit Google Pay oder per Übergabe an Retailer-Sites. Start: USA im Sommer in Search und Gemini App, YouTube und Gmail folgen.
Für E-Commerce-Verantwortliche heißt das vor allem: Wer im Shopping Graph (über 60 Milliarden Listings) nicht sauber, vollständig und aktuell vertreten ist, wird in der agentischen Customer Journey schlicht nicht existieren. Produktdaten-Qualität schlägt Werbebudget.
Verifizierung: SynthID kommt in Search und Chrome
Im Schatten der großen Themen ein Detail mit Konsequenz: SynthID und Content Credentials Verification kommen in Search und Chrome. Per Circle to Search oder Rechtsklick fragen: „Was this generated with AI?“ – inklusive Information, ob ein Inhalt mit generativen Tools bearbeitet wurde. Neue Partner für SynthID neben NVIDIA: OpenAI, Kakao, ElevenLabs.
Für Publisher, Marken und alle, die mit AI-Bildern arbeiten, wird Transparenz damit nicht mehr nur ethische Pflicht, sondern Distributions-Faktor.
Was abseits von Search noch relevant ist
Die Keynote war länger, als hier sinnvoll wäre. Drei Dinge sollte man aber als Marketer auf dem Schirm haben:
Gemini Spark – Googles persönlicher KI-Agent in der Gemini App. Läuft 24/7 auf dedizierten Cloud-VMs, integriert über MCP Drittanbieter-Tools, soll später im Sommer in Chrome als agentischer Browser laufen. Beta für US-Ultra-Abonnenten in dieser Woche, neuer Ultra-Plan ab 100 US-Dollar/Monat. Wer Customer Journeys baut, sollte verstehen, wie das eigene Produkt von solchen Agenten erreichbar, buchbar und bezahlbar ist.
Gemini 3.5 Flash & Pro – Flash ist heute live, in Antigravity bis zu 12x schneller als andere Frontier-Modelle und laut Google deutlich günstiger. Pro folgt im nächsten Monat. Praktische Bedeutung: Die Hürde, eigene agentische Workflows wirtschaftlich zu betreiben, sinkt weiter.
Daily Brief in Gemini – personalisierter Morgen-Digest aus Inbox, Kalender, Tasks. Heute live für AI Plus/Pro/Ultra in den USA. Auch das ein Touchpoint, an dem Marken künftig sichtbar – oder unsichtbar – sind.
Dazu Antigravity 2.0 als eigenständige Desktop-App, Docs Live für „verbales Brain-Dumpen“, ein redesigntes Gemini-App-UI („Neural Expressive“), Android XR mit den ersten Audio Glasses im Herbst, Google Pics in Workspace, Stitch-Updates fürs UI-Design, Flow und Flow Music für kreative Workflows. Die Richtung ist überall dieselbe: weg von der Antwort, hin zum System, das plant, baut, editiert, bezahlt und im Hintergrund Aufgaben erledigt.
Was Du jetzt tun solltest
Drei konkrete Konsequenzen aus dieser Keynote für jede:n, der/die Sichtbarkeit verantwortet:
1. Messbarkeit neu denken. Klassische Sichtbarkeitsmetriken werden nicht falsch, aber unvollständig. Baue Dir – oder hol Dir – ein synthetisches, repräsentatives Prompt-Set für Deine Themen und tracke Zitierverhalten und Quellenpräsenz in AI Overviews und AI Mode. Wer das jetzt aufsetzt, hat in 12 Monaten Daten, die Wettbewerber nicht haben.
2. Inhalte und Daten zitierfähig machen. Generative UI in Search wird Antworten aus strukturierten, verlässlichen Bausteinen bauen. Saubere semantische Struktur, klare Faktenlage, gepflegte Produktdaten, gut interpretierbare Schemata sind keine SEO-Hygiene mehr – sie sind die Voraussetzung, überhaupt Rohmaterial für die KI-Antwort zu liefern.
3. Agentische Distribution mitdenken. Search Agents, Spark, Daily Brief, Universal Cart und AP2 zeigen: Ein wachsender Anteil von Kaufentscheidungen läuft künftig durch Agenten, nicht durch direkte Nutzer-Interaktion. Marken sollten heute beginnen, ihre Produkte, Konditionen und Preise so zu strukturieren, dass ein Agent sie sauber vergleichen, einsortieren und im Auftrag eines Menschen bevorzugen kann.
Google hat 2026 nicht „mehr KI in Search“ angekündigt. Google hat Search selbst neu definiert. Die Frage ist nicht mehr, ob man dem folgt – sondern wie schnell.
Die Diskussion um AI-Agenten hat sich verschoben. Vor einem Jahr klang vieles noch nach Modellvergleich: Welches LLM plant besser? Welches schreibt besseren Code? Welches halluziniert weniger? Inzwischen wird klarer: Die entscheidende Frage ist nicht nur, wie gut das Modell ist, sondern in welchem System es arbeitet.
Genau hier setzt Harness Engineering an.
Ein Agent ist eben nicht einfach ein Chatbot mit mehr Kontext. Sobald er Tools nutzen, Dateien ändern, Tests starten, Browser bedienen, Deployments vorbereiten oder Entscheidungen über mehrere Arbeitsschritte hinweg treffen soll, braucht er eine Umgebung, die ihn führt, begrenzt und überprüfbar macht. Der Harness ist diese Umgebung: Instructions, State, Verification, Scope und Session Lifecycle – also die Regeln, das Gedächtnis, die Prüfmechanismen, die Grenzen und die Übergaben, innerhalb derer ein Agent arbeitet. Das Projekt Learn Harness Engineering beschreibt diesen Ansatz als systematisches Design von Environment, State Management, Verification und Control Systems, um Coding Agents wie Codex oder Claude Code zuverlässiger zu machen.
Der Harness besteht selbst als fünf Subsystemen: Instructions, State, Verification, Scope und Session Lifecycle. Wichtig ist dabei die Formulierung: Das Modell entscheidet, welchen Code es schreibt; der Harness regelt, wann, wo und wie es schreibt. Der Harness macht das Modell also nicht klüger, sondern macht seine Arbeit kontrollierbarer und überprüfbarer.
Damit ist Harness Engineering mehr als „bessere Prompts schreiben“. Es ist der Übergang von Prompting zu Infrastruktur. OpenAI beschreibt diese Verschiebung sehr deutlich: In einer agentenorientierten Entwicklungswelt besteht die Arbeit des Engineering-Teams nicht mehr nur darin, selbst Code zu schreiben, sondern Umgebungen zu entwerfen, Intentionen zu spezifizieren und Feedback-Loops zu bauen, in denen Codex-Agenten zuverlässig arbeiten können. Ein zentrales Muster ist dabei: Das Repository wird zum „System of Record“, während AGENTS.md eher als Karte oder Inhaltsverzeichnis dient, nicht als allwissendes Handbuch.
Auch Anthropic argumentiert in eine ähnliche Richtung. In den Arbeiten zu long-running agents geht es nicht nur darum, ein Modell länger laufen zu lassen, sondern Fortschritt über Kontextfenster, Sessions und Teilaufgaben hinweg kontrollierbar zu machen. Dazu gehören Initialisierung, Feature-Listen, Übergabeartefakte, Browser-Validierung, QA-Agenten und explizite Verifikationsschleifen. Gleichzeitig zeigen diese Arbeiten auch die Grenze: Selbst bessere Harnesses stoßen an Decken, etwa wenn Evaluatoren zu großzügig urteilen, UI-Zustände nicht beobachtbar sind oder das System zwar viel schafft, aber nicht sicher weiß, ob es das Richtige geschafft hat.
Das macht die aktuelle Debatte so interessant: Harness Engineering ist einerseits eine der praktischsten Antworten auf die Unzuverlässigkeit von AI-Agenten. Es reduziert Kontextverlust, Scope Creep, ungeprüfte Annahmen, „fertig“-Behauptungen ohne Evidenz und gefährliche Tool-Nutzung. Andererseits darf man es nicht mit einer Sicherheitsgarantie verwechseln.
Ein Harness kann erzwingen, dass ein Agent Tests ausführt. Er kann aber nicht garantieren, dass diese Tests die richtigen Dinge prüfen!
Er kann Rechte beschränken. Er kann aber nicht automatisch erkennen, ob eine fachliche Entscheidung ethisch, rechtlich oder geschäftlich sinnvoll ist.
Er kann einen Agenten auditable machen. Er kann ihn nicht unfehlbar machen!
Gerade deshalb ist die Sicherheitsdiskussion so wichtig. OWASP beschreibt für AI-Agenten Risiken, die über klassische Prompt Injection hinausgehen: Tool Abuse, Privilege Escalation, Memory Poisoning, Excessive Autonomy, Goal Hijacking und Cascading Failures. Sobald ein Agent nicht nur Text erzeugt, sondern Handlungen ausführt, reicht es nicht mehr, ihn gut zu instruieren. Man muss ihn wie einen potenziell fehlbaren, potenziell manipulierbaren Prozess behandeln – mit Least Privilege, Isolation, Monitoring, Approval Gates und Rollback.
Der entscheidende Punkt ist also: Ein guter Harness macht AI-Agenten nicht magisch zuverlässig. Er macht sie sichtbar, begrenzt, prüfbar, reversibel, eskalierbar und lernend. Das ist enorm viel. Es ist wahrscheinlich der Unterschied zwischen „ein Modell macht irgendetwas“ und „ein Agent kann produktiv in einem echten Workflow arbeiten“. Aber es bleibt ein Unterschied zwischen kontrollierter Autonomie und garantierter Korrektheit.
Wer AI-Agenten produktiv einsetzen will, sollte deshalb nicht nur fragen: „Welches Modell nehmen wir?“ Die bessere Frage lautet: Welche Arbeitsumgebung bauen wir, damit Fehler früh sichtbar werden, Schaden begrenzt bleibt und menschliche Urteilskraft dort eingreift, wo sie wirklich gebraucht wird?
Denn am Ende ist der Harness kein Schutzengel. Er ist ein Betriebssystem für begrenzte Autonomie.
Was ein optimaler Harness sehr gut kann
Er kann viele typische Agentenfehler fast mechanisch reduzieren: Kontextverlust, „ich bin fertig“-Behauptungen ohne Beweis, Scope Creep, Arbeiten auf kaputtem Ausgangszustand, vergessene Tests, fehlende Handoffs. Die mitgelieferte AGENTS.md-Vorlage verlangt zum Beispiel, vor Codeänderungen den Arbeitsstand zu lesen, init.sh auszuführen, Smoke- oder E2E-Verifikation zu starten und bei fehlschlagender Baseline erst den Ausgangszustand zu reparieren.
Er kann auch verhindern, dass „fertig“ nur ein Sprachakt ist. Die Vorlage definiert Done erst dann, wenn Zielverhalten implementiert ist, die Verifikation tatsächlich lief, Evidenz dokumentiert wurde und das Repository wieder vom Standardpfad startbar ist.
Und er kann Architektur, Security- und Qualitätsregeln teilweise aus dem menschlichen Gedächtnis in mechanische Gates verschieben. OpenAI beschreibt genau diesen Weg: kurze AGENTS.md als Router, Repo-Dokumente als System of Record, mechanische Linter, strukturelle Tests und Custom-Lints, um Invarianten durchzusetzen.
Die harte Grenze: Der Harness kann nur prüfen, was spezifiziert, beobachtbar und testbar ist
Die wichtigste Grenze ist das Oracle-Problem: Woher weiß das System, was richtig ist?
Ein Harness kann sagen: „Führe Tests aus.“ Er kann nicht automatisch sicherstellen, dass die Tests vollständig, relevant und richtig sind. Er kann sagen: „Arbeite nur an Feature X.“ Er kann nicht garantieren, dass Feature X fachlich sinnvoll, moralisch akzeptabel, rechtlich zulässig oder im Produktkontext die richtige Priorität ist.
Deshalb würde ich sagen:
Ein Harness kann Prozess- und Zugriffsgarantien geben. Er kann Evidenz erzwingen. Er kann Blast Radius begrenzen. Er kann aber nicht aus unvollständiger Spezifikation vollständige Wahrheit machen.
Anthropic zeigt das sehr plastisch: Harnesses verbesserten Long-running Agents stark, aber auch mit Browser-Automation und Tests blieben blinde Flecken, etwa weil bestimmte UI-Zustände nicht sichtbar waren oder Browser-Automation nicht alles erfassen konnte.
Grenze 1: Unvollständige oder falsche Ziele
Ein Agent kann perfekt gegen die falsche Spezifikation arbeiten. Wenn die Akzeptanzkriterien fehlen, falsch sind oder wichtige Stakeholder-Anforderungen nicht im Repo stehen, optimiert der Harness auf eine Scheingenauigkeit.
OpenAI formuliert es sinngemäß so: Was Codex nicht im Kontext sehen kann, existiert für das System nicht; Wissen in Slack, Google Docs oder in Köpfen muss in repo-lokale, versionierte Artefakte übersetzt werden.
Das heißt: Der Harness schützt nicht vor fehlenden Prämissen. Er kann nur erzwingen, dass der Agent vorhandene Prämissen liest und nutzt.
Grenze 2: Tests sind Evidenz, keine Wahrheit
„Alle Tests grün“ heißt: Das System hat eine endliche Menge erwarteter Fälle bestanden. Es heißt nicht: keine Bugs, keine falschen Annahmen, keine Security-Lücken, keine ungesehenen Randfälle.
Das gilt besonders bei UX, Security, Datenqualität, Nebenwirkungen, Race Conditions, Performance unter Last, realen Nutzerdaten und externen APIs. Anthropic beschreibt, dass selbst ein getunter QA-Agent subtile Bugs und tiefer verschachtelte Features übersehen kann; außerdem war Claude als QA-Agent „out of the box“ zu großzügig und musste explizit auf skeptisches Prüfen getunt werden.
Ein optimaler Harness kann hier nur besser werden durch stärkere Oracles: Property-based Tests, Fuzzing, formale Spezifikationen, Golden Datasets, Replay realer Traces, unabhängige Evaluatoren, Canary Deployments, Monitoring und Rollback. Aber auch das bleibt Abdeckung, nicht Allwissenheit.
Grenze 3: LLM-Evaluatoren teilen oft dieselben Schwächen
Multi-Agent-Harnesses klingen attraktiv: Planner, Generator, Evaluator. Das hilft. Aber der Evaluator ist oft wieder ein LLM. Damit entstehen korrelierte Fehler: beide Modelle übersehen dasselbe, teilen dieselben Annahmen, lassen sich von plausiblen Erklärungen überzeugen oder bewerten oberflächlich.
Anthropic sagt explizit, dass Agenten bei Selbstbewertung dazu tendieren, ihre eigene Arbeit zu positiv zu beurteilen; ein separater Evaluator hilft, aber eliminiert die Tendenz nicht automatisch.
Darum: Ein Evaluator-Agent ist gut. Ein mechanischer, adversarialer, unabhängiger Evaluator ist besser. Ein menschlicher Fachexperte bleibt bei offenen Urteilsfragen noch einmal eine andere Qualität.
Grenze 4: Sicherheit kann nicht nur prompt-basiert sein
Ein Harness, der sagt „lösche keine Dateien“, ist schwach. Ein Harness, bei dem der Agent technisch keine Dateien außerhalb eines erlaubten Pfads löschen kann, ist stark.
Die große Grenze ist: Sobald der Agent Tools, Credentials, Shell, Browser, E-Mail, Datenbanken oder Deploy-Rechte hat, wird Fehlverhalten operativ relevant. OWASP nennt für Agenten unter anderem Prompt Injection, Tool Abuse, Privilege Escalation, Data Exfiltration, Memory Poisoning, Goal Hijacking, Excessive Autonomy und Cascading Failures als zentrale Risiken.
Prompt Injection ist besonders wichtig: OWASP beschreibt im Detail, dass manipulierte Inputs das Modellverhalten unerwartet verändern können und dass RAG oder Fine-Tuning solche Angriffe nicht vollständig entschärfen. Außerdem sei unklar, ob es narrensichere Prävention gibt; empfohlen werden daher Schadensbegrenzung, Least Privilege, Output-Validierung, Trennung untrusted content und Human Approval für Hochrisikoaktionen.
Praktisch heißt das: Der Harness darf dem Modell nicht vertrauen. Er muss den Agenten wie einen potenziell kompromittierten Prozess behandeln.
Grenze 5: Schaden entsteht oft außerhalb des Codes
Ein Coding-Harness kann Codequalität verbessern. Aber Schaden kann auch entstehen durch:
falsche Nutzerkommunikation, fehlerhafte fachliche Empfehlung, Datenschutzverletzung, Diskriminierung, falsche Priorisierung, unzulässige Automatisierung, falsche Eskalation, unbemerkte Kostenexplosion oder eine Entscheidung, die technisch korrekt, aber organisatorisch falsch ist.
NIST beschreibt Trustworthy AI nicht nur als Validität und Reliability, sondern auch als Safety, Security/Resilience, Accountability/Transparency, Explainability/Interpretability, Privacy und Fairness. NIST betont außerdem, dass das einzelne Adressieren dieser Eigenschaften nicht automatisch Vertrauenswürdigkeit garantiert, weil Trade-offs und Kontextentscheidungen bleiben.
Das ist eine wichtige Grenze für Harness Engineering: Ein Harness kann technische Gates bauen, aber nicht alle sozialen, rechtlichen und ethischen Trade-offs wegautomatisieren.
Grenze 6: Drift und Entropie bleiben
Ein Agent kopiert vorhandene Muster. Sind die Muster gut, skaliert Qualität. Sind sie schlecht, skaliert Müll.
OpenAI beschreibt genau das als neues Problem vollständiger Agentenautonomie: Codex repliziere vorhandene, auch suboptimale Patterns, was über Zeit zu Drift führt; dagegen wurden „Golden Principles“, Qualitätschecks und wiederkehrende Cleanup-Prozesse eingeführt.
Ein optimaler Harness braucht also nicht nur „Do the task“, sondern auch permanente Müllabfuhr: Qualitätsmetriken, Architektur-Reviews, Tech-Debt-Tracker, Refactoring-Routinen, Dokumentationspflege, Regressionstests und Mechanismen gegen veraltete Regeln.
Grenze 7: Menschliche Urteilskraft verschwindet nicht, sie wandert nach oben
Der Mensch schreibt weniger Code, aber entscheidet stärker über Ziele, Constraints, Akzeptanzkriterien, Risikoappetit und Eskalation. OpenAI beschreibt, dass Menschen im Loop bleiben, aber auf anderer Abstraktionsebene: priorisieren, User Feedback in Acceptance Criteria übersetzen und Outcomes validieren.
Das ist aus meiner Sicht die produktivste Lesart:
Der Harness soll Menschen nicht komplett ersetzen, sondern ihre Aufmerksamkeit an die Stellen verschieben, an denen sie am meisten Wert hat.
Was ein Harness tatsächlich garantieren kann
Stark garantierbar sind Dinge wie:
Art der Garantie
Kann ein guter Harness leisten?
Agent darf bestimmte Tools nicht nutzen
Ja, wenn technisch enforced, nicht nur prompt-basiert
Agent darf nur in Sandbox schreiben
Ja, über Dateisystem-/Containerrechte
Kein Merge ohne CI
Ja, über Branch Protection
Kein Deploy ohne Human Approval
Ja, über Deployment-Gates
Keine Arbeit ohne Baseline-Check
Weitgehend, wenn der Workflow technisch erzwingt
Keine „Done“-Meldung ohne Evidenz
Weitgehend, wenn Done-Status maschinell validiert wird
Keine fachlich falsche Entscheidung
Nein, nicht allgemein
Keine falsche Annahme
Nein, nur reduzierbar
Keine ungetesteten Nebenwirkungen
Nein, nur durch bessere Abdeckung reduzierbar
Kein Schaden
Nein, nur Risiko und Blast Radius reduzierbar
Der Unterschied ist: Zugriff, Prozess und Artefakte lassen sich hart kontrollieren. Bedeutung, Wahrheit, Priorität und Werturteile nur begrenzt.
Meine Kurzformel
Ein optimaler Harness macht den Agenten nicht unfehlbar. Er macht ihn:
sichtbar: Was wurde getan, warum, mit welcher Evidenz?
begrenzt: Was darf der Agent technisch überhaupt tun?
prüfbar: Welche Tests, Logs, Traces, Screenshots, Reviews existieren?
reversibel: Kann man Fehler zurückrollen?
eskalierbar: Wann muss ein Mensch entscheiden?
lernend: Werden Fehler in neue Regeln, Tests und Dokumente überführt?
Für harmlose oder gut testbare Coding-Aufgaben kann das reichen, damit man „reviewt statt rettet“. Für sicherheitskritische, rechtliche, medizinische, finanzielle oder reale Aktionsräume reicht es nicht als Autonomiebeweis. Dort sollte der Harness den Agenten eher als assistierendes System mit harter Sandbox, Least Privilege, Audit Trail und Human Approval behandeln. NIST formuliert für AI-Risikomanagement ebenfalls, dass bei Fehlern, die das System nicht erkennen oder korrigieren kann, menschliche Intervention nötig sein kann.
Fazit
Ein sehr guter Harness kann Zuverlässigkeit massiv erhöhen, aber er kann nicht garantieren, dass ein Agent „keine Fehlentscheidungen“ trifft. Er verschiebt das Problem: weg von „das Modell improvisiert frei“ hin zu „wir erzwingen Prozess, Kontext, Grenzen, Evidenz und Eskalation“. Das ist ein großer Fortschritt, aber kein Beweis für Wahrheit, Sicherheit oder gute Urteilsfähigkeit.
Es gibt KI-Benchmarks, die beeindrucken. Und es gibt Benchmarks, die irritieren. ARC-AGI-3 gehört für mich klar zur zweiten Kategorie – im besten Sinne.
Denn während viele aktuelle Benchmarks vor allem zeigen, ob ein Modell eine Aufgabe richtig beantwortet, schaut ARC-AGI-3 an einer viel unangenehmeren Stelle hin: Kann ein KI-System in einer völlig neuen Umgebung selbst herausfinden, was überhaupt zu tun ist?
Genau deshalb fand ich die aktuelle Analyse von ARC Prize zu GPT-5.5 und Anthropic Opus 4.7 so spannend. Die offiziellen Scores wirken auf den ersten Blick fast absurd niedrig: GPT-5.5 erreicht auf dem semi-privaten ARC-AGI-3-Set 0,43 Prozent, Opus 4.7 kommt auf 0,18 Prozent. Grundlage der qualitativen Analyse waren 160 Replays und Reasoning-Traces aus öffentlichen Runs, also nicht nur Endergebnisse, sondern tatsächliche Spielverläufe samt Modellbegründungen.
Das klingt nach einem vernichtenden Urteil über Frontier-Modelle. Aber ich glaube, genau hier lohnt sich ein zweiter Blick.
Denn die eigentliche Frage ist nicht nur: Wie schlecht schneiden LLMs bei ARC-AGI-3 ab?
Die interessantere Frage für mich lautet: Wie hart hat ARC Prize wirklich versucht, mit diesen LLMs möglichst weit zu kommen?
Meine Antwort nach der Lektüre: hart in der Analyse, aber bewusst nicht hart in der Optimierung.
Was ARC-AGI-3 eigentlich testet
ARC-AGI-3 besteht aus 135 neuartigen, von Menschen gestalteten interaktiven Umgebungen. Die Testperson – egal ob Mensch oder KI – bekommt keine Anleitung, sondern muss durch Ausprobieren herausfinden, welche Aktionen welche Effekte haben, welche Ziele gelten und welche Regeln von Level zu Level übertragen werden können.
Das ist ein wichtiger Unterschied zu klassischen Benchmarks. Hier geht es nicht darum, eine Frage zu beantworten, Code zu schreiben oder ein bekanntes Rätselmuster wiederzuerkennen. Es geht um Exploration, Hypothesenbildung, Korrektur falscher Annahmen, Planung und Lernen aus spärlichem Feedback. ARC Prize beschreibt genau diese Anforderungen: unbekannte Interfaces erkunden, Regeln aus wenig Feedback ableiten, Hypothesen testen, Irrtümer revidieren und Gelerntes auf spätere Level übertragen.
Das ist ziemlich nah an dem, was wir von echten Agenten erwarten würden. Ein Agent, der in einem Unternehmen mit internen Tools, Dashboards, Formularen, APIs und Workflows arbeiten soll, bekommt in der Realität auch nicht immer eine perfekte Bedienungsanleitung. Er muss erkennen, was wichtig ist, welche Aktionen möglich sind und welche Effekte sie haben.
Genau deshalb ist ARC-AGI-3 aus meiner Sicht so interessant: Es testet nicht nur Wissen, sondern adaptive Handlungsfähigkeit.
Die drei Fehlermuster: Sehen ist nicht Verstehen
Besonders spannend ist, dass ARC Prize nicht nur Scores veröffentlicht, sondern auch die Fehler analysiert. Dabei werden drei wiederkehrende Muster beschrieben:
Erstens: Die Modelle erkennen lokale Effekte, bauen daraus aber kein belastbares Weltmodell. Sie sehen beispielsweise, dass eine Aktion ein Objekt dreht, verstehen aber nicht, welche globale Regel dahintersteht und wie diese Regel strategisch genutzt werden müsste.
Zweitens: Die Modelle interpretieren neue Umgebungen zu stark durch bekannte Spielmuster. ARC Prize nennt unter anderem Analogien zu Tetris, Frogger, Sokoban, Breakout, Pong und anderen Spielen. Das Problem ist nicht, dass Analogien grundsätzlich schlecht wären. Das Problem ist, dass eine oberflächliche Ähnlichkeit zu einer falschen vollständigen Spieltheorie wird.
Drittens: Selbst wenn ein Level gelöst wird, bedeutet das nicht, dass das Modell das Spiel verstanden hat. ARC Prize beschreibt Beispiele, in denen ein Modell durch Zufall oder durch eine unvollständige Theorie ein erstes Level schafft, diese falsche Theorie dann aber in Level 2 fortschreibt und daran scheitert.
Das finde ich besonders aufschlussreich. Denn genau solche Fehler sehen wir auch bei LLM-Agenten außerhalb von Spielen: Sie machen etwas scheinbar richtig, aber aus dem falschen Grund. Und sobald sich der Kontext leicht verändert, bricht die Strategie zusammen.
Wie hart wurde es wirklich versucht?
Jetzt kommt der entscheidende Punkt.
Wenn man die offiziellen ARC-AGI-3-Scores liest, könnte man meinen: GPT-5.5 und Opus 4.7 können das schlicht nicht. Aber das wäre mir zu einfach.
Denn ARC Prize sagt sehr klar, dass die offiziellen Tests gerade nicht darauf ausgelegt sind, mit maximalem Prompt Engineering, spezialisierten Tools oder einem ausgefeilten Agenten-Harness den bestmöglichen Score herauszuholen.
In der offiziellen Testing Policy heißt es sinngemäß: Um faire Vergleiche zu ermöglichen und falsche AGI-Signale zu vermeiden, nutzt ARC Prize extrem generische minimale LLM-Testprompts, keine clientseitigen Harnesses, keine handgebauten Tools und keine individuell zugeschnittene Modellkonfiguration.
Auch der technische Report ist hier sehr deutlich. Für die offiziellen ARC-AGI-3-Scores sollen Systeme bewertet werden, die nicht speziell für ARC-AGI-3 vorbereitet wurden und hinter einer allgemeinen API laufen. Der offizielle Leaderboard-Score nutzt daher kein Harness. Die Modelle bekommen keine externen Tools, abgesehen von möglichen internen Tools, die hinter der Modell-API verborgen sind. Der Systemprompt ist minimal: „Du spielst ein Spiel. Dein Ziel ist zu gewinnen. Antworte mit der exakten Aktion …“
Mit anderen Worten: Die offiziellen Scores messen nicht, was ein Team aus Agenten-Entwickler:innen mit GPT-5.5 oder Opus 4.7 bauen könnte. Sie messen eher, was passiert, wenn man ein Frontier-Modell fast nackt in eine neue interaktive Umgebung wirft.
Das ist kein Bug des Benchmarks. Das ist die Designentscheidung.
Warum diese Designentscheidung sinnvoll ist
Ich halte diese Entscheidung für nachvollziehbar – auch wenn sie die Interpretation erschwert.
ARC Prize will nicht messen, wie viel menschliche Intelligenz in ein ARC-spezifisches System hineinentwickelt wurde. Sie wollen wissen, ob ein allgemeines KI-System beim Erstkontakt mit einer unbekannten Aufgabe selbstständig generalisieren kann. Der technische Report unterscheidet ausdrücklich zwischen task-spezifischem Overfitting, also Optimierung auf bekannte öffentliche Umgebungen, und domain-spezifischem Overfitting, also Strategien, die speziell auf ARC-AGI-3 als Domäne zugeschnitten sind.
Das ist wichtig. Denn sonst würden wir am Ende vor allem messen, wer den besten ARC-AGI-3-Solver gebaut hat – nicht, welches Modell allgemein intelligenter oder adaptiver ist.
Und genau hier entsteht die Spannung: Aus Sicht eines Benchmarks ist ein minimalistisches Setup sinnvoll. Aus Sicht praktischer Agentenentwicklung ist es aber fast künstlich schwach.
Denn in der Praxis würden wir ein LLM ja gerade nicht allein lassen.
Was ein gutes Harness verändern würde
Ein Harness ist vereinfacht gesagt das technische Gerüst um ein Modell herum. Es entscheidet, wie Beobachtungen aufbereitet werden, wie Erinnerungen gespeichert werden, welche Tools verfügbar sind, wie frühere Aktionen analysiert werden, wie Hypothesen verwaltet werden und wie Pläne überprüft werden.
Und genau da liegt meiner Meinung nach der Hebel.
Ein besseres Harness könnte etwa:
visuelle Zustandsänderungen automatisch erkennen,
Objekte über Frames hinweg tracken,
Aktion-Effekt-Tabellen führen,
Hypothesen explizit speichern und priorisieren,
Experimente planen, statt zufällig zu klicken,
erfolgreiche Level nachträglich kausal erklären,
falsche Genre-Analogien unterdrücken,
frühere Zustände gezielt abrufen,
und nach jedem Reward prüfen, warum der Reward zustande kam.
Das ist nicht nur Prompting. Das ist Context Engineering im eigentlichen Sinne: Wahrnehmung, Gedächtnis, Tool-Nutzung, Kompression, Planung und Selbstkorrektur werden so gestaltet, dass das Modell überhaupt eine Chance hat, über viele Schritte hinweg konsistent zu handeln.
Und ARC Prize liefert selbst Hinweise darauf, dass Harnesses sehr wohl viel bringen können.
Im technischen Report wird beschrieben, dass Opus 4.6 in einer TR87-Variante ohne Harness 0,0 Prozent erreichte, mit dem Duke-Harness aber 97,1 Prozent. In einer anderen Umgebung, BP35, blieb dasselbe Modell allerdings sowohl mit als auch ohne Harness bei 0,0 Prozent. ARC Prize interpretiert das als Beleg dafür, dass Wahrnehmung und API-Format nicht grundsätzlich der limitierende Faktor sind, spezifisch gebaute Harnesses aber oft schlecht auf neue Umgebungen generalisieren.
Genau das ist der springende Punkt: Ein Harness kann massiv helfen. Aber sobald es zu stark auf bekannte Aufgaben oder eine bestimmte Benchmark-Logik zugeschnitten ist, misst der Score nicht mehr nur Modellfähigkeit, sondern auch die Ingenieursleistung im Gerüst.
Die wirklich spannende Frage: generisches Harness statt ARC-Tricks
Für mich ist deshalb nicht die Frage, ob man ARC-AGI-3 mit genug Tricks besser lösen kann. Natürlich kann man das.
Die spannende Frage lautet: Wie weit kommt ein vorab eingefrorenes, wirklich generisches Agenten-Harness auf ungesehenen ARC-AGI-3-Umgebungen?
Also kein System, das ARC-spezifische Strategien einprogrammiert bekommt. Keine manuell optimierten Prompts für einzelne Spiele. Kein Zugriff auf öffentliche Lösungen. Sondern ein allgemeines Agenten-Gerüst mit Werkzeugen, die auch in anderen Domänen sinnvoll wären:
Das wäre aus meiner Sicht der eigentlich relevante nächste Schritt.
Interessanterweise erkennt ARC Prize den Wert solcher Harness-Forschung durchaus an. Der technische Report führt eine Community-Leaderboard-Kategorie für harness-getriebene Ergebnisse ein, warnt aber zugleich davor, solche Scores direkt als AGI-Fortschritt zu interpretieren.
Auch die frühen Experimente zeigen, wohin die Reise gehen könnte. In der Preview Agent Competition erreichte StochasticGoose von Tufa Labs 12,58 Prozent mit einem CNN- und Reinforcement-Learning-Ansatz zur Vorhersage frame-verändernder Aktionen; Blind Squirrel kam mit einem gerichteten State-Graphen auf 6,71 Prozent. Beide erfolgreichen Ansätze nutzten im Kern informierte Suche im Aktionsraum.
Dazu kommen agentische Harness-Ansätze wie das Duke-System, das einem Large Reasoning Model erlaubt, Python-Code auszuführen, um gezielt frühere Zustände aus der Aktionshistorie abzurufen und zu transformieren. In den öffentlichen Umgebungen löste dieser Ansatz alle drei Aufgaben mit menschenähnlicher Aktionseffizienz. Symbolica AIs Arcgentica wiederum arbeitet mit einer Orchestrator-Subagenten-Architektur und komprimierten Textzusammenfassungen, um Kontextwachstum zu begrenzen und trotzdem einen übergeordneten Plan zu halten.
Das sind für mich keine Nebendetails. Das ist der eigentliche Forschungsraum.
Prompting hilft – aber es reicht wahrscheinlich nicht
Natürlich könnte man auch mit besseren Prompts mehr herausholen.
Man könnte das Modell anweisen, Beobachtung, Hypothese und Plan strikt zu trennen. Man könnte verlangen, dass jede Aktion als Experiment verstanden wird. Man könnte falsche Genre-Analogien aktiv sanktionieren: „Nenne keine bekannten Spiele, solange keine kausale Evidenz dafür vorliegt.“ Man könnte nach jedem Erfolg eine Reflexionsphase erzwingen: „Welche Regel erklärt den Erfolg minimal und generalisiert auf das nächste Level?“
Das würde vermutlich helfen.
Aber ich glaube nicht, dass Prompting allein das Kernproblem löst. Denn viele Fehler entstehen nicht nur durch falsche Instruktion, sondern durch fehlende externe Struktur. LLMs sind stark darin, Muster sprachlich zu formulieren. Aber in langen interaktiven Umgebungen brauchen sie ein Gedächtnis, eine saubere Zustandsrepräsentation und eine robuste Methode, um Hypothesen gegen Beobachtungen zu testen.
Auch die ARC-Dokumentation zeigt übrigens sehr schön, wo die Grenze liegt. Es gibt dort ein „GuidedLLM“-Template mit expliziten spiel-spezifischen Regeln und Strategien im Prompt. Die Dokumentation weist aber selbst darauf hin, dass dieses Template zu Bildungszwecken gedacht ist und nicht auf andere Spiele generalisiert.
Das ist genau der Unterschied zwischen cleverem Prompt und allgemeiner Intelligenz.
Meine Einordnung
Die niedrigen Scores von GPT-5.5 und Opus 4.7 bei ARC-AGI-3 beweisen nicht, dass LLM-basierte Agentensysteme grundsätzlich chancenlos sind.
Sie beweisen eher etwas Präziseres und Spannenderes:
Nackte Frontier-LLMs sind beim Erstkontakt mit neuartigen, interaktiven, nichtsprachlich erklärten Umgebungen noch extrem schwach.
Das ist eine wichtige Aussage. Aber sie ist nicht identisch mit: „Mit Tools, Memory, Search, Perception und gutem Harness geht da nicht viel mehr.“
Im Gegenteil: Die bisher veröffentlichten Harness-Ergebnisse legen nahe, dass sehr viel mehr möglich ist – allerdings oft auf Kosten der Generalität. Ein System kann auf bekannten oder ähnlichen Umgebungen stark werden, ohne wirklich allgemein adaptiv zu sein.
Für mich liegt genau hier die Grenze zwischen Benchmarking und Produktentwicklung.
Ein Benchmark wie ARC-AGI-3 muss überfitting-resistent sein. Er muss verhindern, dass wir menschliche Vorarbeit im Harness fälschlich als Modellintelligenz feiern.
Ein praktisches Agentensystem hingegen sollte natürlich jede sinnvolle Hilfe nutzen. In realen Anwendungen interessiert mich selten, ob die Intelligenz „pur“ im Modell sitzt oder teilweise im Workflow, im Tooling, in der Memory-Schicht oder in der Systemarchitektur. Mich interessiert, ob das Gesamtsystem zuverlässig, nachvollziehbar und robust handelt.
Aber für die Forschung ist diese Unterscheidung entscheidend.
Fazit: Nicht das Ende der LLMs, sondern das Ende der Illusion vom nackten Agenten
ARC-AGI-3 zeigt für mich nicht, dass moderne LLMs nutzlos sind. Es zeigt, dass wir sie nicht mit echter autonomer Anpassungsfähigkeit verwechseln sollten.
Ein Modell, das hervorragend schreibt, codet, erklärt und bekannte Muster kombiniert, ist noch lange kein Agent, der in einer fremden Welt selbstständig stabile Regeln entdeckt, falsche Theorien verwirft und sein Verhalten effizient anpasst.
Gleichzeitig wäre es unfair, aus den offiziellen ARC-AGI-3-Scores ein hartes Limit für LLM-basierte Systeme abzuleiten. Denn die offiziellen Tests verzichten bewusst auf genau die Komponenten, die heutige Agentensysteme in der Praxis leistungsfähiger machen: Tools, Speicher, strukturierte Wahrnehmung, Suchverfahren, Reflexion und Kontextmanagement.
Die für mich spannendste nächste Messung wäre deshalb ein eingefrorenes, nicht ARC-spezifisches Agenten-Harness auf privaten ARC-AGI-3-Umgebungen.
Nicht: Wie gut kann ein Mensch ARC-AGI-3 für ein Modell lösen?
Sondern: Wie gut kann ein generisches KI-Agentensystem neue Regeln entdecken, wenn es dieselben Werkzeuge nutzen darf, die wir auch in echten Anwendungen brauchen?
AFAIK: Genau dort wird es interessant. Nicht beim nächsten Prozentpunkt auf einem Leaderboard, sondern bei der Frage, ob wir aus starken Sprachmodellen robuste, adaptive Handlungssysteme bauen können – ohne jedes neue Problem vorher für sie zu präparieren.
Es gibt Sätze, die beruhigen, weil sie nicht ganz falsch sind.
KI ersetzt keine Menschen, sondern nur Tätigkeiten.
Das klingt vernünftig. Es ist differenziert. Es nimmt der Debatte etwas von der Panik. Und in vielen Fällen stimmt es auch.
Das Problem ist nur: Manche Jobs bestehen zu einem sehr großen Teil aus genau den Tätigkeiten, die automatisiert werden.
Dann ersetzt die Maschine nicht abstrakt „den Menschen“. Sie ersetzt auch nicht sofort eine ganze Branche. Sie ersetzt eine wiederholbare Funktion. Einen Ablauf. Eine Schnittstelle. Einen Routineteil.
Aber wenn ein Beruf historisch vor allem daraus bestand, dann verschwindet am Ende nicht nur eine Tätigkeit.
Dann verschwindet ein Job.
Der Aufzug war nicht menschenfeindlich
Früher brauchte man im Aufzug einen Menschen.
Nicht, weil Menschen gerne in kleinen Kabinen neben anderen Menschen standen. Sondern weil Aufzüge bedient werden mussten. Türen schließen, Hebel bewegen, sauber auf Etagenhöhe halten, Passagiere beruhigen, Fehler vermeiden. Das war keine Dekoration. Das war Arbeit.
Ein guter Aufzugsführer hatte Gefühl für die Maschine. Er musste den Wagen so steuern, dass niemand erschrak, stolperte oder zwischen zwei Stockwerken hängenblieb. Das Museum of American Heritage beschreibt, dass dafür durchaus Geschick nötig war; Anfang der 1950er waren Aufzugsführer in den USA noch verbreitet, zu Beginn der 1960er aber weitgehend durch Elektronik, günstigere Automatisierung und Druckknöpfe verdrängt. (Museum of American Heritage)
Das Interessante daran ist nicht, dass ein Knopf einen Menschen „intelligenter“ gemacht hätte.
Der Knopf hat nur eine Schnittstelle verändert.
Vorher war der Mensch die Bedienoberfläche der Maschine. Danach war es das Bedienfeld.
Und genau das ist eine der wichtigsten historischen Lektionen für KI.
Manche Berufe sind keine ewigen Berufungen. Manche Berufe sind Übergangslösungen, bis eine Maschine direkt genug, billig genug, zuverlässig genug oder akzeptiert genug ist.
„Computer“ waren früher Menschen
Das vielleicht schönste Beispiel ist gleichzeitig das naheliegendste.
Computer waren früher keine Geräte. Computer waren Menschen.
Bei NASA und ihren Vorgängerorganisationen arbeiteten ganze Gruppen menschlicher „Computer“, häufig Frauen, die komplexe mathematische Berechnungen durchführten. Bei JPL waren sie unter anderem für Berechnungen zu Startfenstern, Flugbahnen, Treibstoffverbrauch und anderen Details des Raumfahrtprogramms zuständig; viele wurden später selbst zu frühen Programmiererinnen bei NASA. (NASA)
Das ist als historische Analogie zu KI deshalb so stark, weil hier nicht Muskelkraft ersetzt wurde.
Sondern Denkarbeit.
Nicht Kreativität im romantischen Sinn. Nicht Urteilskraft im letzten Sinn. Aber sehr anspruchsvolle, strukturierte, formalisierbare geistige Arbeit.
Also genau das, was wir uns lange als ziemlich sicheren Bereich vorgestellt haben.
Die menschlichen Computer waren nicht überflüssig, weil sie unwichtig waren. Im Gegenteil. Sie waren wichtig genug, dass man ihre Arbeit beschleunigen, standardisieren und skalieren wollte.
Das ist oft der eigentliche Grund für Automatisierung.
Nicht: Diese Arbeit ist wertlos.
Sondern: Diese Arbeit ist wertvoll genug, um sie einer Maschine beizubringen.
Manche Jobs sind Schnittstellen
Ein weiteres Beispiel sind Telefonistinnen.
Heute wirkt es fast absurd, dass ein Telefongespräch einmal ein menschliches Vermittlungssystem brauchte. Man hob den Hörer ab, sagte, wen man sprechen wollte, und irgendwo verband ein Mensch zwei Leitungen.
Das war ein Beruf. Und zwar kein exotischer. Anfang des 20. Jahrhunderts gehörte Telefonvermittlung in den USA zu den häufigsten Jobs für Frauen. Zwischen 1920 und 1940 ersetzte AT&T in mehr als der Hälfte seines US-Netzes menschliche Vermittlung durch mechanische Schaltsysteme. Eine NBER-Studie kommt zu dem Ergebnis, dass diese Automatisierung die meisten Operatorinnen-Jobs eliminierte; viele betroffene Frauen waren zehn Jahre später in schlechter bezahlten Berufen oder gar nicht mehr erwerbstätig. (NBER)
Auch hier wurde nicht „Kommunikation“ ersetzt.
Menschen telefonierten danach nicht weniger, sondern mehr. Das Kommunikationssystem wurde größer, schneller und billiger.
Aber die menschliche Zwischenschicht verschwand.
Das ist ein Muster, das wir bei KI sehr genau anschauen sollten.
Wenn ein Job vor allem darin besteht, zwischen Nutzer und System zu vermitteln, ist er gefährdet, sobald Nutzer direkt mit dem System sprechen können.
Das muss nicht sofort passieren. Und nicht überall. Menschen vertrauen neuen Schnittstellen nicht über Nacht. Prozesse müssen umgebaut werden. Haftung muss geklärt werden. Qualität muss messbar sein.
Aber sobald die direkte Schnittstelle gut genug ist, wird die menschliche Schnittstelle erklärungsbedürftig.
Nicht unmöglich.
Aber erklärungsbedürftig.
Manche Jobs sind Umsetzungsmaschinen
Dann gibt es Berufe, die vor allem aus Umsetzung bestehen.
Nicht aus Entscheidung. Nicht aus Verantwortung. Nicht aus Strategie.
Sondern aus der Transformation von Input in Output.
Ein Text soll vervielfältigt werden. Eine Vorlage soll gesetzt werden. Eine Rechnung soll berechnet werden. Eine Anfrage soll beantwortet werden. Eine Aufnahme soll transkribiert werden. Ein Dokument soll zusammengefasst werden. Ein Produkt soll in fünf Varianten beschrieben werden.
Historisch waren Kopisten genau so eine Zwischenschicht. Vor dem Buchdruck wurden Texte professionell abgeschrieben. Mit Gutenbergs beweglichen Lettern und der schnellen Verbreitung des Drucks konnten Drucker den vertrauten Look von Manuskripten in einem Bruchteil der Zeit und zu geringeren Kosten reproduzieren; professionelle Manuskriptkopie ging bis zum Ende des 16. Jahrhunderts stark zurück. (Cornell Library Exhibits)
Später passierte etwas Ähnliches im Druck selbst.
Die Linotype war einmal eine revolutionäre Maschine. Sie automatisierte den Handsatz und prägte die Zeitungsproduktion über Jahrzehnte. Dann wurde auch sie durch neue Verfahren verdrängt. Als die New York Times 1978 auf elektronische und fotografische Verfahren umstellte, wurden die letzten 61 Linotype-Maschinen ersetzt. (The Library of Congress)
Das ist wichtig, weil es zeigt: Auch die Maschine von gestern kann der Mensch von vorgestern sein.
Technologie ersetzt nicht nur Handarbeit. Sie ersetzt auch frühere Technologien. Und mit ihnen die Berufe, die um diese Technologien herum entstanden sind.
Das Auto ersetzte nicht die Kutsche
Das beliebte Beispiel lautet oft: Das Auto hat die Kutschenbetriebe ersetzt.
Das stimmt so halb.
Eigentlich hat das Auto zuerst das Pferd ersetzt.
Und das ist mehr als eine Pointe.
Denn wenn das Pferd als Antriebstechnologie verschwindet, verschwindet nicht nur ein Tier aus dem Straßenbild. Dann geraten Hufschmiede, Stallknechte, Sattler, Futterlieferanten, Fuhrbetriebe, Kutscher und ganze städtische Infrastrukturen unter Druck. Der Ökonom David Autor beschreibt genau dieses Muster: Das massenproduzierte Automobil reduzierte die Nachfrage nach vielen pferdebezogenen Berufen drastisch, etwa nach Hufschmieden und Stallpersonal. (economics.mit.edu)
Das Auto hat also nicht einfach einen Job ersetzt.
Es hat eine zentrale Funktion ersetzt: Antrieb.
Und um diese Funktion herum hing ein ganzer Berufsverbund.
Bei KI ist die zentrale Funktion nicht Muskelkraft.
Es ist routinisierbare Informationsarbeit.
Text hinein, Text heraus. Frage hinein, Antwort heraus. Sprache hinein, Transkript heraus. Daten hinein, Zusammenfassung heraus. Briefing hinein, Entwurf heraus. Regel hinein, Entscheidungsvorschlag heraus.
Solange diese Funktion nur ein kleiner Teil eines Berufs ist, verändert KI den Job.
Wenn diese Funktion aber der Kern des Berufs ist, kann KI den Job ersetzen.
Die beruhigende Formel ist zu bequem
Deshalb ist die Formel „KI ersetzt keine Jobs, sondern Tätigkeiten“ zu bequem.
Sie stimmt auf der Ebene der Tätigkeitsanalyse.
Aber sie unterschlägt die nächste Frage:
Wie viel vom Job besteht aus dieser Tätigkeit?
Wenn 10 Prozent eines Berufs automatisierbar sind, entsteht ein Produktivitätswerkzeug.
Wenn 40 Prozent automatisierbar sind, entsteht ein Umbauproblem.
Wenn 80 Prozent automatisierbar sind, entsteht eine Existenzfrage.
Das heißt nicht, dass morgen alle Menschen in diesen Rollen verschwinden. So funktionieren technologische Umbrüche fast nie. Es gibt Übergänge, Ausnahmen, Nischen, Regulierung, Kundenpräferenzen, Haftungsfragen und Qualitätsprobleme.
Aber historisch ist die Richtung trotzdem deutlich.
Zuerst wird eine Tätigkeit maschinell möglich. Dann wird sie billig. Dann wird sie gut genug. Dann wird sie erwartet. Dann wird der Mensch in dieser Tätigkeit zum Sonderfall.
Nicht immer.
Aber oft genug.
KI ist anders, weil sie keine einzelne Maschine ist
Der Webstuhl automatisierte Weben.
Der automatische Aufzug automatisierte Aufzugbedienung.
Die Telefonvermittlung automatisierte Verbindungsarbeit.
Die Rechenmaschine automatisierte Rechnen.
KI ist schwieriger zu greifen, weil sie nicht nur eine Maschine für eine Tätigkeit ist.
Sie ist eher eine Schicht, die sich über viele Informationsprozesse legt.
Deshalb wirkt sie gleichzeitig überschätzt und unterschätzt.
Überschätzt, weil viele Ergebnisse nur plausibel aussehen und bei genauer Prüfung Lücken haben.
Unterschätzt, weil sehr viele Jobs erstaunlich viele Tätigkeiten enthalten, bei denen „plausibel, schnell und zu 80 Prozent richtig“ wirtschaftlich schon ausreicht.
Genau hier liegt die Unbequemlichkeit.
In vielen Debatten wird so getan, als gehe es um perfekte Ersetzung.
Kann KI einen Top-Juristen ersetzen? Kann KI eine erfahrene Ärztin ersetzen? Kann KI einen sehr guten Softwarearchitekten ersetzen? Kann KI eine strategische Marketingleiterin ersetzen?
Das sind interessante Fragen.
Aber sie lenken ab.
Denn viele Umbrüche beginnen nicht oben. Sie beginnen bei Routine, Vorarbeit, Standardfällen, Varianten, Recherche, Formatierung, Zusammenfassung, Transkription, Klassifikation und Erstentwürfen.
Also bei all dem, was in Organisationen viel Zeit frisst, aber selten im Organigramm glänzt.
Es wird nicht alle treffen. Aber es trifft echte Jobs.
Die Internationale Arbeitsorganisation kommt in ihrer Analyse zu dem Ergebnis, dass generative KI global eher Tätigkeiten ergänzt als ganze Berufe vollständig automatisiert. Gleichzeitig sieht sie die höchste Exposition bei Büro- und Verwaltungstätigkeiten, wo besonders viele Aufgaben mittel oder stark betroffen sind. (International Labour Organization)
Das klingt beruhigend.
Ist es aber nur teilweise.
Denn „eher Ergänzung als vollständige Automatisierung“ heißt nicht: keine Jobverluste.
Es heißt: Die meisten Berufe werden umgebaut. Einige werden aufgewertet. Einige werden entwertet. Einige werden kleiner. Und manche verschwinden in ihrer bisherigen Form.
Auch das US Bureau of Labor Statistics erwartet, dass KI und generative KI die Nachfrage in verschiedenen Bereichen dämpfen, unter anderem in Vertrieb, Design und administrativer Unterstützung. Genannt werden dort etwa Übersetzer, technische Redakteure, medizinische Sekretariate, Customer-Service-Rollen, nichtmedizinische Assistenzen, Paralegals und Claims Adjusters als Berufe, bei denen KI Effizienzgewinne erzeugt und Beschäftigungswachstum begrenzen oder Rückgänge verstärken kann. (Bureau of Labor Statistics)
Das ist der nüchterne Punkt.
Nicht: Alle Arbeit verschwindet.
Sondern: Bestimmte Arbeit verschwindet aus bestimmten Stellenprofilen.
Und wenn ein Stellenprofil um diese Arbeit herum gebaut war, verschwindet das Profil.
Die eigentliche Frage ist nicht: Wird KI Jobs ersetzen?
Die eigentliche Frage lautet:
Welche Jobs sind eigentlich nur historische Verpackungen für automatisierbare Tätigkeiten?
Das klingt hart. Aber es ist präziser.
Ein Aufzugsführer war nicht „nur“ ein Knopf. Eine Telefonistin war nicht „nur“ ein Schalter. Eine Rechnerin war nicht „nur“ eine Rechenmaschine. Ein Schriftsetzer war nicht „nur“ ein Layoutalgorithmus. Ein Kopist war nicht „nur“ ein Kopierer.
Jeder dieser Berufe hatte Würde, Erfahrung, Routinen, Stolz und soziale Bedeutung.
Aber die zentrale Marktleistung wurde automatisierbar.
Und sobald das passierte, half es wenig, darauf hinzuweisen, dass der Mensch mehr war als seine Tätigkeit.
Denn der Markt bezahlte vor allem für die Tätigkeit.
Das ist brutal.
Aber genau deshalb sollte man es nicht beschönigen.
Wo Menschen wichtiger werden
Die andere Seite gehört aber genauso dazu.
Automatisierung ersetzt nicht nur. Sie ergänzt auch. Sie macht manche Arbeit wertvoller, weil die maschinell erzeugten Zwischenschritte billiger werden.
Wenn Rechnen billig wird, werden Modellierung, Interpretation und Entscheidung wichtiger.
Wenn Textproduktion billig wird, werden Positionierung, Fachurteil, Quellenkritik und Verantwortung wichtiger.
Wenn Designvarianten billig werden, werden Geschmack, Kontext, Marke und Auswahl wichtiger.
Wenn Code schneller entsteht, werden Architektur, Sicherheit, Tests, Produktverständnis und Wartbarkeit wichtiger.
Wenn Supportantworten automatisch entstehen, werden Eskalation, Empathie, Kulanz und echte Problemlösung wichtiger.
Das ist kein Widerspruch.
Das ist genau das Muster.
Die Maschine frisst den standardisierbaren Teil.
Der Mensch bleibt dort stark, wo das Problem unscharf ist, Verantwortung trägt, soziale Bedeutung hat oder in einem komplexen System richtig eingeordnet werden muss.
Aber auch das ist keine Garantie für jeden bestehenden Job.
Es ist eher eine Aufforderung, den eigenen Wert nicht mit der Tätigkeit zu verwechseln, die gerade automatisiert wird.
Der Fehler ist, den Übergang mit dem Endzustand zu verwechseln
Bei jeder neuen Technologie gibt es eine Phase, in der man sie leicht unterschätzen kann.
Automatische Aufzüge wirkten zunächst unheimlich. Telefonvermittlung ohne Menschen wirkte ungewohnt. Elektronische Computer waren teuer, groß und begrenzt. KI macht Fehler, halluziniert, missversteht, glättet, erfindet und wirkt oft sicherer, als sie ist.
Daraus entsteht eine tröstliche Beobachtung:
„Siehst du, es geht doch nicht ohne Menschen.“
Stimmt.
Heute.
In vielen Fällen.
Aber die Geschichte zeigt: Der Anfangszustand einer Technologie ist selten ihr Endzustand.
Die ersten Autos waren keine guten Pferde. Die ersten Drucke waren keine perfekten Manuskripte. Die ersten Computer waren keine universellen Alleskönner. Die ersten automatischen Aufzüge mussten erst Vertrauen gewinnen.
Der entscheidende Moment kommt nicht, wenn die Maschine perfekt ist.
Er kommt, wenn sie für genügend Anwendungsfälle gut genug ist.
Und wenn Organisationen ihre Prozesse so umbauen, dass die Maschine nicht mehr wie ein schlechter Mensch arbeiten muss, sondern wie eine Maschine arbeiten darf.
Nicht Panik. Aber Ehrlichkeit.
Es wäre falsch, aus der Geschichte eine einfache Untergangserzählung zu machen.
Technologische Umbrüche vernichten nicht nur Arbeit. Sie schaffen auch neue Arbeit. Das World Economic Forum erwartet bis 2030 weltweit zwar erhebliche Verdrängung, aber zugleich auch viele neue Rollen; konkret nennt es 170 Millionen neu entstehende und 92 Millionen verdrängte Jobs, also netto 78 Millionen zusätzliche Beschäftigungsmöglichkeiten. (World Economic Forum)
Aber solche Nettobetrachtungen trösten nur auf Folien.
Für den einzelnen Menschen ist es egal, ob irgendwo anders ein neuer Job entsteht, wenn der eigene verschwindet.
Für Unternehmen ist es egal, ob „der Arbeitsmarkt“ langfristig neue Rollen schafft, wenn kurzfristig ganze Tätigkeitsketten neu kalkuliert werden.
Und für die Gesellschaft ist es gefährlich, Menschen mit semantischen Beruhigungspillen abzuspeisen.
KI ersetzt nicht alle Jobs.
KI ersetzt auch nicht einfach „den Menschen“.
Aber KI ersetzt sehr wohl bestimmte Tätigkeiten so stark, dass manche Jobs in ihrer heutigen Form verschwinden werden.
Weitere werden kleiner.
Viele werden umgebaut.
Und einige werden wertvoller, weil Menschen mit KI plötzlich mehr leisten können als vorher.
Das ist kein Grund für Panik.
Aber es ist ein Grund für Ehrlichkeit.
Denn der Satz „KI ersetzt keine Jobs, sondern Tätigkeiten“ ist nur dann hilfreich, wenn man den zweiten Teil dazusagt:
Manche Jobs bestehen fast vollständig aus diesen Tätigkeiten.
