Ausgabe vom 7. April 2026

Unter dem Titel „Industrial Policy for the Intelligence Age: Ideas to Keep People First“ veröffentlichte OpenAI am 6. April ein Policy-Paper mit ambitionierten Vorschlägen: ein national verwalteter Public Wealth Fund, gespeist von Beiträgen der KI-Unternehmen, dessen Renditen direkt an US-Bürger ausgeschüttet werden sollen — vergleichbar mit Alaskas Permanent Fund. Dazu Roboter-Steuern, also eine Verlagerung der Steuerlast von Arbeit auf Kapital, subventionierte Pilotprojekte für eine Vier-Tage-Woche bei vollem Lohnausgleich und automatische Sicherheitsnetze, die aktiviert werden, wenn KI-bedingte Arbeitsplatzverluste vordefinierte Schwellenwerte überschreiten.

Das Timing ist kaum zufällig: Am selben Tag erschien eine 18 Monate lange Investigativ-Recherche von Ronan Farrow und Andrew Marantz im New Yorker, die schwere Vorwürfe gegen OpenAI erhebt. Demnach hat das Unternehmen seine Superalignment- und AGI-Readiness-Teams aufgelöst und „Safety“ von der Liste seiner wichtigsten Aktivitäten in den IRS-Unterlagen gestrichen. Als ein OpenAI-Vertreter nach Forschern für „existential safety“ gefragt wurde, soll er geantwortet haben: „What do you mean by ‘existential safety’? That’s not, like, a thing.“

Parallel kündigte OpenAI ein Safety Fellowship an: ein sechs­monatiges Stipendien­programm für externe Forscher, das am 14. September 2026 beginnt. Bewerbungsfrist ist der 3. Mai. Kritiker wie Gary Marcus bezeichneten sowohl das Policy-Paper als auch das Fellowship als „regulatory nihilism“ — ein Versuch, die Nachrichtenagenda vom negativen New-Yorker-Bericht abzulenken, während gleichzeitig die internen Safety-Kapazitäten abgebaut werden.

Die inhaltlichen Vorschläge des Papers sind dabei durchaus beachtenswert — wenn auch „intentionally early and exploratory“, wie OpenAI selbst schreibt. Die Idee, KI-Unternehmen in einen öffentlichen Vermögensfonds einzahlen zu lassen und die Effizienz-Dividende der KI über eine verkürzte Arbeitswoche an alle weiterzugeben, ist ein Signal an die Politik: Wir denken über die gesellschaftlichen Folgen nach. Ob diese Vision mehr ist als ein PR-Dokument, wird sich an konkreten Handlungen messen lassen.

Ein Forschungsteam der University of Cambridge unter Leitung von Andrea Marinoni hat über zwanzig Jahre Satellitendaten mit Standortdaten von mehr als 8.400 Rechenzentren weltweit verglichen — und erstmals systematisch belegt, was Anwohner längst ahnten: Rechenzentren erzeugen „lokale Datenhitzeinseln“, analog zu den bekannten städtischen Wärmeinseln. Die durchschnittliche Oberflächentemperatur stieg nach Inbetriebnahme eines Rechenzentrums um rund 2 Grad Celsius. Der höchste gemessene Wert lag bei 9,1 Grad um ein einzelnes Rechenzentrum.

Der Effekt ist auch in größerer Entfernung messbar: In 4,5 Kilometern Abstand beträgt die Erwärmung noch etwa ein Grad, in sieben Kilometern rund 30 Prozent der Maximalbelastung. Erst ab zehn Kilometern Entfernung wird der Effekt vernachlässigbar. Weltweit leben rund 340 Millionen Menschen innerhalb dieses Zehn-Kilometer-Radius — besonders betroffen sind Regionen in Mexiko, Spanien und Brasilien.

Die Ergebnisse sind im Kontext des KI-Booms besonders brisant: Während die Branche Hunderte Milliarden in neue Rechenzentren investiert, werden die lokalen Umweltauswirkungen selten thematisiert. Ein typisches 100-Megawatt-Rechenzentrum verbraucht zudem rund 1,1 Millionen Liter Kühlwasser pro Tag — so viel wie 2.600 Haushalte. Die Internationale Energieagentur schätzt den globalen Stromverbrauch von Rechenzentren auf rund 415 Terawattstunden im Jahr 2024 — bis 2026 könnten es über 1.000 Terawattstunden werden.

In Irland, einem europäischen Hotspot für Rechenzentren, könnten diese laut IEA bereits 2026 rund 32 Prozent des nationalen Stromverbrauchs ausmachen. Die Cambridge-Forscher fordern bessere Kühlsysteme und effizientere Software-Optimierung — doch strukturell stellt sich die Frage, ob die derzeitige Standortwahl für Rechenzentren die lokalen Auswirkungen ausreichend berücksichtigt. In bereits heißen Regionen wie Mexiko oder Spanien kann eine zusätzliche Erwärmung von 2 Grad die Lebensqualität und Gesundheit erheblich beeinträchtigen.

AGENTS.md ist eine Initiative der Open-Source-Community: eine standardisierte Datei im Repository-Root, die KI-Coding-Agenten Kontext gibt — Build-Steps, Test-Befehle, Architektur-Richtlinien, Coding-Konventionen. Quasi eine „README für Agenten“. Die Idee klingt einleuchtend: Wer einem neuen Teammitglied ein Onboarding-Dokument gibt, sollte das auch für KI-Agenten tun, die sich sonst mühsam durch den Code kämpfen müssen.

Doch eine aktuelle Studie der ETH Zürich liefert ein differenzierteres Bild: LLM-generierte Kontext-Dateien — also AGENTS.md-Dateien, die von einer KI statt von Menschen geschrieben wurden — reduzieren die Erfolgsrate im Durchschnitt leicht: um etwa 0,5 Prozentpunkte bei SWE-bench Lite und 2–3 Prozentpunkte bei AgentBench. Die Erklärung ist naheliegend: In gut dokumentierten Projekten ist die Information redundant, der Agent kann den Kontext bereits aus dem Code erschließen. Die zusätzlichen Token verbrauchen Kontextfenster, ohne Mehrwert zu liefern.

Die entscheidende Ausnahme: In dokumentationsarmen Projekten verbessern generierte Kontext-Dateien die Erfolgsrate um durchschnittlich 2,7 Prozentpunkte. Die ETH-Forscher empfehlen daher einen pragmatischen Ansatz: Kontext-Dateien sollten ein „lean, precise operating manual“ sein — menschlich geschrieben, auf genuinely nicht-ableitbare Details beschränkt (spezifische Tooling-Konfigurationen, Custom-Build-Befehle) und keine Kopie der bestehenden Dokumentation.

Gegenläufige Studien zeigen allerdings auch positive Effekte: 28,6 Prozent niedrigere Median-Laufzeit und 16,6 Prozent reduzierter Token-Verbrauch mit gut strukturierten AGENTS.md-Dateien. Die Debatte spiegelt ein grundlegendes Dilemma der KI-gestützten Software­entwicklung: Der Nutzen von Kontext hängt entscheidend von der Qualität des Kontexts ab — und davon, ob er von einem Menschen oder einer Maschine stammt.

Am 6. April erschien „Google AI Edge Eloquent“ ohne jede Ankündigung im iOS App Store — eine Diktier-App, die auf Googles Gemma-Modellen basiert und Sprache vollständig lokal auf dem Gerät verarbeitet. Keine Cloud, keine Datenübertragung, keine API-Keys. Die App transkribiert Gesprochenes in Echtzeit und geht dabei über klassische Spracherkennung hinaus: Füllwörter wie „ähm“ und „ah“ werden automatisch entfernt, Selbstkorrekturen geglättet, und der Output als lesbarer Fließtext formatiert.

Bemerkenswert ist die Plattformwahl: Google startet eine KI-App zuerst auf Apples iOS — nicht auf dem eigenen Android. Das signalisiert, dass Google sein „AI Edge“-Ökosystem aggressiv verbreiten will, jenseits der eigenen Plattformgrenzen. Die App demonstriert die Leistungsfähigkeit der Gemma-Modellfamilie als On-Device-KI — ein strategisches Argument für Entwickler, die lokale Spracherkennung in ihre Apps integrieren wollen.

Neben der Kernfunktion bietet Eloquent Textbearbeitungs-Tools: „Kernpunkte“ (automatische Aufzählungen), „Formal“, „Kurz“ und „Lang“ als Formatierungsoptionen, Nutzungsstatistiken und ein persönliches Wörterbuch mit Gmail-Import. Ein optionaler Cloud-Modus ermöglicht Textbereinigung über Gemini-Modelle — die Spracherkennung selbst bleibt aber immer lokal.

In Zeiten wachsender Datenschutz-Sensibilität ist eine App, die Audio vollständig lokal verarbeiten kann, ein starkes Argument — besonders im europäischen Markt. Die Konkurrenz durch Tools wie Wispr Flow und SuperWhisper ist allerdings bereits etabliert. Der Stealth-Launch ohne Blogpost oder Pressekonferenz ist ungewöhnlich für Google und deutet darauf hin, dass die App noch im frühen Stadium ist — ein öffentliches Experiment mit Googles On-Device-KI-Strategie.