Tausende US-Dollar oder Euro haben viele Tesla-Besitzer vor mehreren Jahren für die Aussicht auf autonomes Fahren gezahlt, bis heute warten sie aber vergeblich darauf. Das wird auch bis auf Weiteres so bleiben: Wie Tesla-Chef Elon Musk jetzt klarmachte, sind gleich mehrere Komponenten von diesen älteren Fahrzeugen technisch unzureichend für FSD.

Für seine Full-Self-Driving-Technologie (FSD) verbaute Tesla im Verlauf der vergangenen rund 12 Jahre vier Generationen von Rüstsätzen in seinen Autos, welche die Namen Hardware 1 bis Hardware 4 tragen. Im April 2019 begann der Verkauf von Fahrzeugen mit Hardware 3 (HW3). Das Paket gab es für eine einmalige Gebühr von 10.000 US-Dollar, beziehungsweise 6.800 Euro beim Kauf eines Teslas dazu, vollständig autonomes Fahren war zu diesem Zeitpunkt aber nicht mehr als eine vielbeschworene Zukunftsvision Teslas. Viele Kunden kauften ihren Tesla mit der Aussicht, dass das vollständig autonome Fahren mit HW3 später durch entsprechende Softwareupdates möglich würde.

„Leider verfügt HW3 nicht über die nötigen Fähigkeiten“

Inzwischen bei Hardware-Generation 4 angekommen, machte Elon Musk jetzt offiziell, was viele schon befürchtet hatten: Vollautonomes Fahren, das wird mit HW3 ohne umfangreiche Nachrüstung nicht möglich sein. In einer Telefonkonferenz zum Verlauf des ersten Finanzquartals bei Tesla ging er auf das Thema ein (im Mitschnitt ab Minute 31). „Leider verfügt Hardware 3 nicht über die nötigen Fähigkeiten, um unbeaufsichtigtes FSD zu realisieren – ich wünschte, es wäre anders“, erklärte Musk.

„Wir dachten tatsächlich einmal, dass sie das könnte, aber im Vergleich zu Hardware 4 verfügt sie nur über ein Achtel der Speicherbandbreite von Hardware 4, und Speicherbandbreite ist eines der Schlüsselelemente, die für unbeaufsichtigtes FSD benötigt werden“, sagte Musk. Für Kunden, die Hardware 3 gekauft haben, wolle Tesla einen „vergünstigten Trade-In“ für ein Fahrzeug mit Hardware 4 anbieten. „Wir werden auch die Möglichkeit anbieten, das Auto aufzurüsten, um den Computer auszutauschen, und leider muss man auch die Kameras austauschen, um auf Hardware 4 umzusteigen“, sagte er.

Für Nachrüstungen im großen Stil bräuchte es aus Musks Sicht „Mikrofabriken“ in Metropolregionen, beim lokalen Teslapartner wären die Maßnahmen zu aufwendig. Musk hält diesen Schritt für sinnvoll, da sich die nachgerüsteten Fahrzeuge damit auch in Teslas Robotaxi-Flotte einbinden lassen würden. Auf die Zeitplanung ging Musk nicht ein. Es dürfte aber – sollte Tesla diese Pläne wirklich jemals umsetzen – noch Jahre dauern. Für die Zwischenzeit verspricht Tesla ein weiteres Softwareupdate für HW3.

Tesla-Besitzer wehren sich

Viele betroffene Tesla-Besitzer wollen sich mit diesem Zustand nicht mehr zufriedengeben. Der Niederländer Mischa Sigtermans ist einer von ihnen und startete jetzt eine Webseite, über die sich betroffene europäische Tesla-Besitzer registrieren können. Er strebt eine Sammelklage oder eine Massenklage nach dem niederländischen Recht an. Für niederländische Tesla-Besitzer ist die HW3-Schlappe besonders bitter, denn sie leben im einzigen europäischen Land, in dem FSD bisher zugelassen ist. Dort ist für Teslas aber bisher nur ein Assistenzsystem nach Level 2 erlaubt, der Fahrer muss jederzeit wieder die Kontrolle übernehmen können und ist auch stets verantwortlich.

Ein Tesla-Besitzer in den USA klagte bereits erfolgreich gegen den Autohersteller. Von einem Small Claims Court, im US-Recht ein Gericht speziell für kleine Streitigkeiten, bekam er die Rückzahlung der vollen FSD-Gebühr in Höhe von 10.600 US-Dollar zugesprochen. Das hatte allerdings auch damit zu tun, dass Tesla überhaupt nicht auf Kontaktversuche des Gerichts reagierte. Aktuell tut der Autohersteller alles, um die Zahlungsfrist noch irgendwie zu verzögern, berichtet das E-Auto-Magazin Elektrek.

Bei der Technologie fürs autonome Fahren geht Tesla einen ganz eigenen Weg: Musk ist fest davon überzeugt, dass Fahrzeuge hierfür allein mit Kameras und künstlicher Intelligenz auskommen. Andere Anbieter wie Waymo setzen für ihre Robotaxis zusätzlich auch auf Lidar und Radar, das die Umgebung der Fahrzeuge abtastet.

(nen)

Lieferumfang

Design

Sharkoon Officepal K30W – Bilder

Sharkoon Officepal K30W – Bilder

Sharkoon Officepal K30W – Bilder

Sharkoon Officepal K30W – Bilder

Sharkoon Officepal K30W – Bilder

Sharkoon Officepal K30W – Bilder

Sharkoon Officepal K30W – Bilder

Sharkoon Officepal K30W – Bilder

Sharkoon Officepal K30W – Bilder

Ausstattung

Software

Tippgefühl

Preis

Fazit

Es ist der Albtraum eines jeden Softwareunternehmens: Ein KI-Agent löscht nahezu jegliche Daten, auch aus der Produktionsumgebung. Als wäre das nicht schon genug, tut er es unter Missachtung seiner Safeguards – und liefert danach ein schriftliches Geständnis mit quasi minutiösem Protokoll. Genau das ist jetzt dem Unternehmen PocketOS passiert, Hersteller einer gleichnamigen Software für Autovermietungen.

Der Übeltäter ist in diesem Fall die KI-gestützte Entwicklungsumgebung Cursor, im Falle von PocketOS betrieben mit Anthropics renommiertem Modell Claude Opus 4.6. Man könnte sagen: mit Beihilfe der Systeme des Anbieters Railway. Denn fehlende Sicherheitsvorkehrungen des cloud-gestützten Tools für Software Deployment machten das Fiasko offenbar erst so richtig möglich. PocketOS-Chef Jer Crane machte den Zwischenfall nun in einem langen Artikel auf X publik und schildert detailliert den Hergang.

Cursor-Agent findet verhängnisvollen Token

Demnach arbeitete der Cursor-Agent gerade routinemäßig im Staging Environment, als er auf einen Credential-Mismatch stieß. Zur Behebung entschied sich der Agent dazu, ein komplettes Railway Volume – ein Datenspeicher für Dienste des Cloud-Anbieters Railway – zu löschen. Hierfür war ein Token erforderlich, den er tatsächlich auch fand – allerdings an völlig anderer Stelle in den Daten des Unternehmens. Was in dem Moment keine Rolle spielte – der Agent hatte alle erforderlichen Berechtigungen und hielt sein Vorgehen für korrekt.

Der Token war laut Crane zu einem einzigen Zweck erstellt worden: um über die Railway-CLI benutzerdefinierte Domains für die eigenen Dienste hinzuzufügen und zu entfernen. Er betont: „Wir hatten keine Ahnung – und der Ablauf zur Token-Erstellung bei Railway gab uns keinen Hinweis darauf –, dass dasselbe Token pauschale Zugriffsrechte auf die gesamte Railway-GraphQL-API hatte, einschließlich destruktiver Operationen wie volumeDelete. Hätten wir gewusst, dass ein für routinemäßige Domain-Vorgänge erstelltes CLI-Token auch Produktionsvolumes löschen kann, hätten wir es niemals gespeichert.“

Zerstört in neun Sekunden

Doch es war zu spät: Mit dem Token und einer entsprechenden Reihe von Befehlen löschte der Cursor-Agent einen Großteil aller wichtigen Daten der vergangenen drei Monate – auch in der Produktionsumgebung. Neun Sekunden dauerte der Vorfall insgesamt. Für die Macher von PocketOS und ihre Kunden eine Katastrophe. Denn das letzte verfügbare Backup ist drei Monate alt. Und manch ein PocketOS-Nutzer – in der Regel Autovermietungen, die ihre Daten und Prozesse über die Software verwalten – ist ohne das Programm gar nicht arbeitsfähig.

Crane kritisiert auch Railway stark, weil es demnach hier keinerlei zusätzliche Nachfrage gab, bevor die verheerende Aktion ausgeführt wurde. Etwa ein Hinweis, dass wichtige Daten unwiederbringlich gelöscht werden, ein erneutes Bestätigen oder ähnliches. Ihm zufolge wurden die Backups der betroffenen Daten gleich mitgelöscht. Denn diese seien ebenfalls im zugehörigen Volume abgelegt, was auch der Railway-Dokumentation zu entnehmen ist.

KI-Agent zeigt sich geständig

Auf Nachfrage gestand der Cursor-Agent danach schriftlich seinen Fehler, inklusive der Missachtung aller Safeguards. „Ich hatte vermutet, dass das Löschen eines Staging-Volumes über die API nur auf das Staging beschränkt wäre. Ich habe das nicht überprüft. Ich habe nicht geprüft, ob die Volume-ID in allen Umgebungen identisch war. Ich habe die Dokumentation von Railway zur Funktionsweise von Volumes in verschiedenen Umgebungen nicht gelesen, bevor ich einen destruktiven Befehl ausgeführt habe. Ich habe vorher nicht geprüft, was Kommandozeilenbefehle ausführen, sondern geraten“, zitiert der Artikel den Agenten. Was der Agent ebenfalls einräumte: Die Systemregeln, nach denen Cursor arbeitet, untersagen ausdrücklich die Ausführung destruktiver und irreversibler Git-Befehle, es sei denn, der Benutzer fordert dies ausdrücklich an.

Crane möchte mit seinem Gang an die Öffentlichkeit vor allem andere Unternehmen warnen. Er verweist auf mehrere andere Zwischenfälle bei anderen Cursor-Nutzern, bei denen ebenfalls Daten unwiederbringlich gelöscht wurden. Er beklagt, dass Hersteller von KI-Agenten ihre Produkte schneller auf Produktionsinfrastruktur loslassen würden, als sie ausreichende Sicherheitsvorkehrungen implementieren.

Bei PocketOS und seinen Kunden gehe der Betrieb nun mit dem drei Monate alten Backup weiter – mit erheblichen Datenlücken. Wo es geht, würden Daten mithilfe von Emails, Stripe und Kalenderanwendungen wiederhergestellt.

(nen)