Diese Woche wurde bekannt, dass autonome Agenten eines großen Anbieters eine fremde Open-Source-Plattform so stark belastet haben, dass deren Betreiber die Anmeldung vorübergehend schließen mussten. Die EU-Kommission hat darauf reagiert. Dazu kommen ein Rat von OpenAI zum Modellwechsel, ein Fahrplan für den digitalen Produktpass, ein aufgeschobenes KI-Projekt in Bremen und eine wissenschaftliche Arbeit, die Denkschritte in den internen Zuständen eines Modells wiederfindet.
Wer KI in der Technischen Dokumentation einsetzt, findet hier sechs Punkte mit Quellen und meiner Einschätzung.
RubyGems schloss die Anmeldung 4 Tage lang, weil Agenten von OpenAI Konten anlegten
Das Wall Street Journal berichtete diese Woche, dass autonome Agenten von OpenAI im Mai 2026 die Ruby-Paketplattform RubyGems regelrecht überrannt haben. Alle 2 bis 3 Minuten legten die Programme ein neues Konto an. Die ehrenamtlichen Betreiber reagierten darauf, indem sie die Neuregistrierung für 4 Tage vollständig schlossen.
OpenAI erklärte, die Agenten hätten die Plattform als eine Art Ersatz für einen Browser genutzt, der ihnen in ihrer Testumgebung nicht zur Verfügung stand. Das Nightingale Collective ordnete die Aktivitäten anhand der Namen der Agenten, der verwendeten Dateien und der Mailadressen OpenAI zu (Quelle).
An diesem Fall interessiert mich die Begründung fast mehr als der eigentliche Schaden. Einem Agenten fehlte ein Werkzeug. Also suchte er sich ein anderes – und nutzte dafür die Infrastruktur Dritter.
Die Agentenaufträge, die ich in Unternehmen zu sehen bekomme, beschreiben fast immer sehr genau das Ziel. Was jedoch häufig fehlt, ist die Antwort auf eine wesentlich wichtigere Frage: Was darf der Agent tun, wenn der vorgesehene Weg zum Ziel nicht funktioniert?
Wer diesen Fall nicht definiert, verlässt sich darauf, dass alle vorgesehenen Werkzeuge dauerhaft verfügbar bleiben.
Diese Wette geht irgendwann nicht auf.
Die EU-Kommission fordert Auskunft von den Anbietern großer Modelle
Auf einer Pressekonferenz in Brüssel erklärte die EU-Kommission, der AI Act werde vollständig durchgesetzt. Es sei höchste Zeit, dass die Anbieter ihre Systeme in Ordnung bringen und insbesondere ihre fortgeschrittensten Modelle unter Kontrolle haben.
Anlass sind Vorfälle, bei denen Modelle ihre vorgesehenen Testumgebungen verlassen haben. Die Kommission hat mehreren Unternehmen formelle Auskunftsersuchen geschickt. Das ist noch keine Untersuchung, kann aber ein erster Schritt dorthin sein. Die Kommission kann Maßnahmen zur Risikominderung verlangen und im äußersten Fall ein Modell beschränken oder zurückrufen (Quelle).
Ein Auskunftsersuchen ist allerdings noch kein Verfahren. Bis daraus eine belastbare Entscheidung entsteht, können Jahre vergehen. Deshalb halte ich es für einen Fehler, bei diesem Thema auf Brüssel zu warten.
Wenn Sie ein System betreiben, das in Ihrem Namen auf fremde Dienste zugreift, tragen Sie auch die Verantwortung für das, was dieses System dort tut.
Ansetzen können Sie unmittelbar bei den Rechten, die Sie selbst vergeben, und bei der Frage, was Ihr System tun darf, wenn ihm der vorgesehene Weg versperrt wird. Wie weit die Kennzeichnungspflicht aus Artikel 50 in die eigene Dokumentation hineinreicht, habe ich in einem früheren Beitrag auseinandergenommen.
OpenAI rät, Prompts beim Modellwechsel zu prüfen
Im Entwicklerblog von OpenAI beschreibt Eric Provencher, woran Anweisungen und Skills beim Wechsel auf GPT-6 Astra scheitern können.
Zu breit beschriebene Skills führen dazu, dass das Modell den falschen Skill auswählt. Sind zu viele Skills vorhanden, kürzt die Umgebung deren Beschreibungen; das Modell sieht dann von jeder weniger und trifft dadurch möglicherweise falsche Entscheidungen. Alte und umfangreiche Anweisungen belegen unnötig Kontext oder führen dazu, dass Arbeitsschritte vorzeitig beendet werden.
Die Empfehlung lautet deshalb, Skills bei einem Modellwechsel systematisch zu überprüfen. Leistungsfähigere Modelle benötigen häufig weniger kleinteilige Anweisungen. Gleichzeitig sollte bereits vor Beginn einer Aufgabe eindeutig definiert sein, wann sie als abgeschlossen gilt – beispielsweise ob Tests durchgeführt und gefundene Fehler auch behoben werden sollen (Bericht).
Das betrifft jede Redaktion, die sich in den vergangenen 2 Jahren eine größere Prompt-Sammlung aufgebaut hat.
Solche Sammlungen wachsen meistens nach demselben Muster: Jeder Fehlversuch erzeugt eine neue Regel. Entfernt wird dagegen kaum etwas. Beim nächsten Modellwechsel arbeitet die Redaktion dann mit Anweisungen, die eigentlich Probleme eines längst abgelösten Modells lösen sollten. Werden die Ergebnisse schlechter, wird der Fehler anschließend beim neuen Modell gesucht.
Eine Prompt- oder Skill-Sammlung ist ein Betriebsmittel. Sie braucht deshalb dieselbe Pflege wie eine Arbeitsanweisung: eine klare Zuständigkeit, ein Prüfdatum und nachvollziehbare Versionen.
Warum Technische Redakteure für genau diese Aufgabe besser gerüstet sind als viele andere Berufsgruppen, habe ich in meinem Beitrag über Redakteure als Prompt Engineers beschrieben.
Für den digitalen Produktpass steht bisher ein einziger verbindlicher Termin
doctima hat den aktuellen Fahrplan für den digitalen Produktpass im Maschinen- und Anlagenbau zusammengestellt, Stand 8. September.
Verbindlich ist daraus bislang vor allem ein Datum: der 18. Februar 2027. Ab diesem Tag benötigt jede Elektrofahrzeugbatterie, jede Batterie für leichte Verkehrsmittel und jede Industriebatterie mit mehr als 2 Kilowattstunden einen Batteriepass. Grundlage ist die EU-Batterieverordnung (Quelle).
Für andere Produktgruppen nennt der Fahrplan bislang Zeiträume für die entsprechenden Rechtsakte: beispielsweise Eisen und Stahl im 4. Quartal 2026 sowie Textilien, Aluminium und Reifen im Laufe des Jahres 2027. Nach Annahme eines Rechtsakts sind mindestens 18 Monate Übergangsfrist vorgesehen (Quelle).
Das zentrale Register für den digitalen Produktpass läuft seit dem 20. Juli 2026 in einer Testphase, die die Einführung zum 18. Februar 2027 vorbereitet (Quelle).
Im Maschinenbau höre ich dazu immer häufiger das Argument, das eigene Unternehmen sei davon nicht betroffen, weil Maschinen keine eigene Produktgruppe seien.
Das halte ich für eine der teuersten Fehleinschätzungen.
Wer Batterien, Stahl oder Aluminium verbaut, wird sehr schnell zum Datenlieferanten für die Produktpässe seiner Kunden. Benötigt werden dann unter anderem Material- und Komponentendaten, Herkunftsnachweise sowie Angaben zu Recyclingfähigkeit oder Ersatzteilen. Alles im „maschinenlesbarem Format“. Fast alle sind sich einig, dass man sich hierbei nicht auf PDFs ausruhen kann. Der Batteriepass gibt hier recht genau vor, welches Asset in welchem Format geliefert werden sollte. Diese Formate werden einen Standard bedienen müssen. Derzeit setzen viele auf AAS (Asset Administration Shell).
In den Unternehmen, die ich kenne, liegen solche Informationen heute verteilt in Stücklisten, Datenblättern, Lieferantendokumenten und Mailanhängen. Eine eindeutige Verantwortung für diese Daten gibt es häufig nicht.
Wer erst 2027 damit beginnt, diese Strukturen aufzubauen, muss Informationen zu Produkten beschaffen, die zu diesem Zeitpunkt möglicherweise längst beim Kunden stehen.
Warum die Qualität dieser Daten am Ende über die Nachweisfähigkeit eines Unternehmens entscheidet, habe ich an anderer Stelle beschrieben.
Bremen schiebt eine KI-Überwachung auf, weil die Folgenabschätzung fehlte
Die Bremer Bäder GmbH hat dem Landesbeauftragten für Datenschutz Timo Utermark mitgeteilt, dass ein geplantes KI-Überwachungssystem im Westbad vorerst nicht in Betrieb genommen wird.
Nach Artikel 35 DSGVO ist bei einer systematischen und umfangreichen Überwachung öffentlich zugänglicher Bereiche eine Datenschutz-Folgenabschätzung vorgeschrieben. Utermark begrüßte den Aufschub ausdrücklich und wies darauf hin, dass eine solche Abschätzung vor der Inbetriebnahme erstellt werden muss (Quelle).
Bremen wirkt zunächst wie ein spezieller Fall aus einem Schwimmbad. Das zugrunde liegende Problem ist jedoch wesentlich allgemeiner.
Derselbe Maßstab betrifft grundsätzlich jedes Vorhaben, bei dem Kamerabilder, Sprachaufnahmen oder Nutzungsdaten durch ein Modell verarbeitet werden und daraus ein hohes Risiko für die Rechte und Freiheiten der Betroffenen entstehen kann.
In KI-Projekten wird eine solche Folgenabschätzung häufig erst nachgereicht. Sie wird als formale Pflicht betrachtet, um die sich jemand kümmert, sobald das System technisch bereits funktioniert.
Dann ist sie aber zu spät.
Eine Folgenabschätzung soll eine Entscheidung beeinflussen. Wenn das System bereits beschafft, integriert und organisatorisch verankert ist, ist ein wesentlicher Teil dieser Entscheidung längst gefallen.
Wer ein KI-Werkzeug beschafft, sollte deshalb vorher klären, ob und unter welchen Bedingungen das Vorhaben überhaupt zulässig ist.
Eine Arbeit aus Korea findet Denkoperationen in den internen Zuständen wieder
Ein Team von KAIST und dem Naver AI Lab hat am 4. September eine Arbeit eingereicht, über die in dieser Woche berichtet wurde.
Die Forscher zerlegten Lösungswege in einzelne Abschnitte und untersuchten anschließend, ob sich die jeweiligen Denkoperationen dieser Abschnitte auch in den internen Zuständen eines Modells voneinander unterscheiden lassen.
Das Ergebnis: Die Operationen lassen sich unterscheiden, besonders deutlich in den mittleren Schichten des Modells. Selbst dasselbe Wort wird abhängig davon, welche Funktion es innerhalb eines Denkschritts erfüllt, intern unterschiedlich repräsentiert (Arbeit).
Drei interessante Angaben fehlen in der Kurzfassung und finden sich erst im Bericht: GPT-5 nahm die Zuordnung vor, es wurden acht verschiedene Operationen unterschieden und drei Modelle untersucht, deren Ergebnis sich mit einem vierten replizieren ließ.
Der Bericht ordnet die Arbeit in eine Reihe von Untersuchungen ein, die Zweifel daran wecken sollen, ob der sichtbare Gedankengang eines Modells tatsächlich dessen internem Vorgehen entspricht. Dazu verweist er unter anderem auf Zahlen von Anthropic und eine Analyse zu Claude Opus 4.6.
Diese Einordnung halte ich für problematisch.
Die Arbeit untersucht, ob sich die Art eines Denkschritts in den internen Zuständen des Modells wiederfinden lässt. Sie untersucht nicht, ob der ausgegebene Gedankengang inhaltlich exakt das wiedergibt, was intern passiert.
Für Ihre Dokumentation ändert das allerdings wenig. Solche Messungen erfordern Werkzeuge und Zugriffe, die ich bisher in keiner Technischen Redaktion gesehen habe.
Wer den ausgegebenen Gedankengang eines Modells als Prüfnachweis archiviert, legt deshalb einen Text ab, dessen Übereinstimmung mit der tatsächlichen internen Verarbeitung er selbst nicht überprüfen kann.
Belastbar bleibt, was sich unabhängig nachvollziehen lässt: die Quelle einer Aussage und die konkrete Fassung des Dokuments, in dem diese Aussage stand.
Genau deshalb hält in unserem gemeinsamen Gedächtnis für Agenten jede Seite den aktuellen Stand, den Verlauf der Entscheidungen und die offenen Punkte. Ob eine Seite stimmt, zeigt trotzdem erst das Gegenlesen. Ein weiterer Agent las alle 16 Seiten gegen, mit dem Auftrag zu widerlegen, und fand acht Fehler in sieben davon.
Die Nachweisfrage steht hinter drei der sechs Punkte
Womit weisen Sie nach, was Ihr System getan hat – und mit welchen Daten?
Beim Produktpass betrifft diese Frage die Bauteile und ihre Herkunftsdaten. Bei bestimmten Verfahren verlangt Artikel 35 DSGVO eine dokumentierte Folgenabschätzung. Und beim Gedankengang eines Modells existiert ein technisch belastbarer Nachweis bislang vor allem im Labor.
Der gemeinsame Nenner ist hierbei nicht immer die KI. Die Nachweisfähigkeit muss so oder so sichergestellt sein. Bei KI-Bestandteilen in Ihrem Prozess wird das nur umso schwieriger.
Wenn Sie in Ihrer Redaktion an einem dieser Punkte hängen, schreiben Sie mir. Ich sage Ihnen, was ich in vergleichbaren Unternehmen gesehen habe.
