Acht Presets, ein 20-Sekunden-Ausschnitt zum Vorhören, ein Login-Bildschirm. Genau so sieht mein Mastering-Werkzeug jetzt aus, seit ich mein Webradio wieder ernsthaft mit Musik befülle. Suno 5.5 liefert einen guten Rohmix, das war nie das Problem. Das Problem war immer das, was danach kommt.

Meine These: Wer KI-Musik in Serie produziert, braucht kein SaaS-Abo für den letzten Schritt, sondern ein eigenes, schlankes Werkzeug, das genau die acht Klangwelten abdeckt, die er wirklich braucht, und sonst nichts. Nach diesem Artikel weißt du, warum ich BandLab gekündigt habe, was beim Bauen eines eigenen Mastering-Tools an Fallen wartet, die dir kein Tutorial zeigt, und warum die Signalkette am Ende komplizierter wurde, als ich anfangs gedacht hab. Fangen wir bei der Musik an, nicht beim Code.

Warum ich wieder mehr KI-Musik brauche

Mein Webradio radio.digitalhandwerk.rocks läuft seit einiger Zeit im Vollbetrieb, mit einem KI-Moderator, der durch mein Programm führt, KI-generierte Interviews und mit Songs aus meinem eigenen Suno-Bestand dazwischen. Rock, New Rock, hin und wieder eine italienische Schmalzballade. Damit das Radio nicht nach ein paar Tagen im Loop hängt, brauche ich laufend Nachschub, und das heißt: mehr Songs aus Suno 5.5, die alle noch einmal durch einen Mastering-Schritt müssen, bevor sie auf Sendung gehen.

Suno macht seit Version 5 einen richtig guten Job. Klar, präsent, mit Vocals, die man nicht mehr auf den ersten Ton als synthetisch erkennt. Trotzdem kommt aus Suno kein fertiger Master. Was rauskommt, ist ein solider Mixdown, aber eben keine Datei, die auf allen Abspielgeräten gleich laut und gleich ausgewogen klingt. Genau dafür ist Mastering da: der letzte Schritt, der aus einem guten Mix ein fertiges, überall funktionierendes Stück macht.

Vom kostenlosen BandLab zum gekündigten Pro-Abo

Früher hab ich das in BandLab gemacht. Kostenlose Online-Mastering-Funktion, ein Preset zur Auswahl, unbegrenzt viele Tracks unter 15 Minuten. Für den Einstieg war das völlig ausreichend, ich hab damit sogar meinen ersten KI-Rocksong veredelt. Irgendwann hab ich mir dann die Pro-Version geholt, weil ich mehr aus den Presets rausholen wollte. Das Ergebnis: Ich hab sie kaum genutzt. Zu viel Funktionsumfang für das, was ich tatsächlich brauchte, nämlich Lautheit angleichen, dezent sättigen, sanft limitieren. Also hab ich gekündigt.

Was dann übrig blieb, war eine Lücke. Kostenloses BandLab hätte weiter gereicht, aber ich wollte nicht wieder in ein Abo einsteigen, das ich am Ende doch nur zu einem Bruchteil nutze. Und weil ich sowieso gerade mit Claude Code an technischen Projekten dran bin, hab ich mir die Frage gestellt, die sich eigentlich immer stellt, wenn ein Werkzeug zu groß für die eigene Aufgabe ist: Was, wenn ich genau das baue, was ich brauche, und nichts von dem, was ich nicht brauche?

Was das eigene Tool tatsächlich kann

Am 10. September 2026 stand die erste funktionierende Version. Ein selbst gehosteter Mastering-Webdienst, single-user, passwortgeschützt, ohne Datenbank, ein einzelner Docker-Container auf Coolify. Der Ablauf ist bewusst simpel gehalten: WAV hochladen, eines von acht Presets wählen, auf einem 20-Sekunden-Ausschnitt vorhören, gegen das Original A/B vergleichen, dann als WAV, MP3 mit 192 kbps oder als 5.1-Upmix exportieren.

Die acht Presets decken das ab, was ich für mein Radio tatsächlich brauche: Universal als Bezugspunkt bei minus 14 LUFS, Fire für die lauten, präsenten Rocksongs bei minus 9, Clarity mit mehr Luft oben und einem De-Esser, Tape warm und dunkel mit Sättigung, Natural mit kaum Kompression für ruhigere Stücke, Spatial mit Mid/Side-Verbreiterung, Cinematic mit Sub-Bass und langem Raum, und Punch für alles, was von den Transienten lebt. Dazu drei Intensitätsstufen, Light, Normal und Heavy, die EQ, Sättigung, Breite und Transienten mit den Faktoren 0,6, 1,0 und 1,4 skalieren.

Technisch steckt Python 3.12 mit FastAPI dahinter, Pedalboard von Spotify für die DSP-Bausteine, pyloudnorm für die Lautheitsmessung nach EBU R128, scipy und numpy für alles, was Pedalboard nicht mitbringt, und ffmpeg für MP3 und den Upmix. Das Frontend ist reines HTML, CSS und JavaScript, ohne Framework, weil ich für ein Werkzeug mit einem einzigen Nutzer keinen Build-Prozess brauche. Design und Farben hab ich eins zu eins von digitalhandwerk.rocks übernommen, Amber als Akzent, dunkler Grund, Inter Tight für Text. Bewusst ohne Menü, ohne Header, ohne Impressum. Es ist ein Werkzeug, keine Website.

Wo die eigentliche Arbeit lag

Was ich unterschätzt hab, war nicht das Grundgerüst, sondern die Kleinigkeiten, die erst beim Nachmessen sichtbar werden. Pedalboards Limiter zum Beispiel hält sein eingestelltes Ceiling schlicht nicht ein. Ich hab nachgemessen: Threshold auf minus 6 dB gesetzt, Ausgang trotzdem exakt bei 0,00 dBFS, weil intern Makeup-Gain draufgerechnet wird. Also brauchte es einen eigenen Lookahead-Limiter, der die nötige Absenkung auf einem vierfach oversampelten Signal bestimmt und die Wirkung per Minimum-Filter um den Peak ausdehnt.

Ähnlich überraschend: Pedalboards Compressor erhöht bei den Zeitkonstanten, die ich für Musik brauche, den Crest-Faktor, statt ihn zu senken, von 13,6 auf 21,6 dB. Bei 15 Millisekunden Attack rutscht jede Transiente einfach durch, komprimiert wird nur der Körper des Signals. Die eigentliche Verdichtung übernimmt am Ende also allein der Limiter, für alle acht Presets gleich.

Auch beim Vorhören gab es eine Falle, die ich erst spät bemerkt hab. Der A/B-Abgleich rechnete den Lautheitsunterschied zwischen den Presets versehentlich weg, weil die Angleichung aus dem jeweiligen Zwischenergebnis abgeleitet wurde. Damit landeten Fire bei minus 9 LUFS und Natural bei minus 17 LUFS beim Vorhören auf demselben gefühlten Pegel, was das ganze Vergleichen sinnlos gemacht hat. Jetzt kommt die Referenz für das Vorhören aus einem festen Wert, im A/B des fertigen Songs weiterhin aus dem tatsächlichen Master.

Und dann war da noch die Erkenntnis, dass laut und knackig gleichzeitig nicht funktioniert. Punch sollte ursprünglich auf minus 12 LUFS zielen, aber genau bei diesem Pegel holte der Limiter die Transienten wieder herunter, die das Preset eigentlich betonen soll. Gemessen war Punch am Ende weniger knackig als das neutrale Universal-Preset. Die Lösung war simpel, aber nicht offensichtlich: das Ziel auf minus 14,5 LUFS setzen und dem Limiter mehr Spielraum lassen.

Was für den nächsten, der so etwas baut, wichtig ist

Ein paar Lektionen waren mir vorher schlicht nicht bewusst. Sättigung kostet messbar Dynamik, ungefähr 0,6 dB je dB Drive, ab acht dB kippt sie hörbar in Oberwellen-Mulm. Lossy-Formate brauchen mehr Reserve als das reine Preset-Ceiling, weil ein MP3 beim Dekodieren über 0 dBFS hinausschießen kann, deshalb limitiere ich vor MP3 und AAC zusätzlich auf minus 1,5 dBTP. Und ffmpegs AAC-Encoder überschwingt je nach Bitrate unterschiedlich stark und nicht mal monoton, weshalb ich das Ergebnis nach dem Encoden nochmal nachmesse.

Am meisten geschmunzelt hab ich über die Matroska-Falle: Der erste 5.1-Upmix lag als E-AC-3 in einer .mka-Datei, und weder Music.app noch QuickTime konnten die Datei überhaupt öffnen. Apple kennt Matroska schlicht nicht. Jetzt läuft der Upmix als AAC mit 448 kbit/s in einer .m4a-Datei, dem Wert, den Apple selbst für 5.1 verwendet.

Offen ist noch einiges: Der Docker-Build ist nie lokal gegen einen laufenden Docker-Daemon verifiziert worden, getestet ist bislang alles unter Python 3.11, während das Dockerfile schon auf 3.12 läuft. Und für DSGVO-Sauberkeit wäre es besser, die verwendeten Google Fonts selbst zu hosten statt sie extern zu laden. Kleine Punkte, aber genau die Art von Kleinigkeiten, die man vor dem ersten produktiven Einsatz noch abarbeitet.

Was das für die Praxis bedeutet

Für mein Radio heißt das: Ein Song aus Suno rein, ein Preset gewählt, vorgehört, exportiert, fertig für die Playlist. Kein Login in ein fremdes Tool, keine Wartezeit auf ein Abo, das ich sowieso nur teilweise nutze, und ein Werkzeug, das genau die acht Klangwelten liefert, die ich für Rock, New Rock und die italienischen Balladen tatsächlich brauche. Ob sich das für dich lohnt, hängt vom Volumen ab. Wer alle paar Wochen einen Song mastert, ist mit BandLab oder einem vergleichbaren Online-Dienst nach wie vor gut bedient. Wer wie ich laufend Nachschub für ein autonomes Radio braucht, für den zahlt sich ein eigenes, schlankes Werkzeug irgendwann aus, auch wenn der Weg dorthin ein paar Nachmittage mit Pedalboard, ffmpeg und viel Nachmessen kostet.

Fragen zum Mastering von KI-Musik

Read more at digitalhandwerk

Mein StackChan hat mich heute gesucht. Nicht metaphorisch. Die Kamera im Gerät hat mein Gesicht erkannt, der Kopf ist ihm nachgefahren, und als ich den Raum verlassen hab, hat er brav eine Suchbewegung gemacht, bevor er sich schlafen gelegt hat. Gestern hätte er dafür nur einen Smiley auf dem Display gewechselt. Die These, die ich in den letzten Monaten zwei Mal öffentlich widerlegt hab, war: Servo-Steuerung auf diesem Gerät geht nicht. Jetzt geht sie doch, und der Grund dafür ist ärgerlich einfach. Was in diesem Artikel steht, ist die Fortsetzung meiner StackChan-Serie: wie die Kopfbewegung tatsächlich funktioniert, wo vier Bugs hintereinander gescheitert sind, und was Claude Opus 5.5 beim Code-Review dazu beigetragen hat.

Kurz zur Einordnung: StackChan, ESP-IDF und Custom Firmware

Der StackChan ist ein Open-Source-Desktop-Roboter von M5Stack, gebaut auf einem ESP32-S3-Microcontroller, mit zwei Servos im Hals, einem kleinen Display für das Gesicht und einer Kamera. ESP-IDF ist die offizielle Entwicklungsumgebung von Espressif für diese Chipfamilie, das Fundament, auf dem jede Custom Firmware für das Gerät aufsetzt. Custom Firmware bedeutet: Du kompilierst die Software selbst, statt die Werkskonfiguration zu verwenden, mit voller Kontrolle über Wake-Word, Sprache und eben auch die Motoren.

Mein StackChan bewegt jetzt den Kopf, verfolgt mein Gesicht per Kamera und meldet sich von selbst, wenn ein Termin ansteht, mit Custom Firmware, die ich im Mai für technisch unmöglich gehalten hab.

Warum hab ich die Servo-Steuerung im Mai eigentlich abgeschrieben?

Ich muss ehrlich sein, das war keine kleine Enttäuschung. Ich hatte neun Stunden in einen ersten Custom-Firmware-Versuch gesteckt, bin an einem offenen GitHub-Issue im M5GFX-Repository hängen geblieben und hab dann pragmatisch aufgegeben. Stock-Firmware, eigener Server im Hintergrund, fertig. Die ganze Geschichte dazu, inklusive der Nacht, die ich nicht mehr erwähnen wollte, hab ich in meinem ersten StackChan-Artikel festgehalten. Die Servos blieben still, weil die Werksfirmware Emotion-Frames nur ans Display koppelt, nie an die Motoren. Das war meine Wette, und ich hab sie verloren.

Vor ein paar Tagen bin ich noch einmal drübergegangen, aus reiner Sturheit, ehrlich gesagt. Und dabei kam raus: Ich hatte im Mai die falsche Diagnose gestellt. Nicht M5GFX war der eigentliche Blocker, das Issue war zu dem Zeitpunkt sowieso längst beantwortet. Der wahre Übeltäter war meine ESP-IDF-Version, 5.3.1, während die xiaozhi-esp32-Basis inzwischen zwingend 6.0.1 oder neuer verlangt. Ich hab monatelang an der falschen Tür gerüttelt.

Was hat sich geändert, dass es jetzt doch ging?

Mit ESP-IDF 6.1 unter WSL Ubuntu lief der Build im ersten Anlauf durch. Der Ordner für die CoreS3-Boardvariante existiert im Upstream vollständig, inklusive Unterstützung für die verbaute GC0308-Kamera. Ich hab daraufhin am 21. September die eigene Firmware gebaut, die ich im Mai bewusst verworfen hatte, mit deutschem UI, dem Wake-Word Jarvis und 21 selbst gerenderten cyanfarbenen Augen. Diesen Umbau von Stock- zu eigener Firmware hab ich in einem eigenen Artikel dokumentiert, inklusive aller Stolpersteine beim Flashen. Was da noch gefehlt hat: die Servos. Erstmals technisch machbar, aber die Board-Definition kannte schlicht keine.

Was hat Opus 5.5 beim Code-Review gefunden?

Gestern hab ich mit Claude Opus 5.5 einen kompletten Code-Review des Projekts gemacht, bevor ich mich an die Servos gewagt hab. Ich hab schon vorher einen ersten Praxistest mit dem Modell an genau diesem Projekt gemacht und war überrascht, wie präzise es Ursachen statt Symptome benennt. Beim gestrigen Review war das nicht anders. Heute hat das Modell dann effektiv den Rest der Arbeit übernommen, also genau das, woran ich im Mai gescheitert bin, plus etwas, das ich nie eingeplant hatte.

Ich berate seit einigen Jahren EPU und KMU in der DACH-Region zu KI-Themen, und genau deshalb schau ich mir solche Sessions immer genau an, nicht als Marketingmoment für ein neues Modell, sondern als Frage: Findet es in echtem, gewachsenem Code tatsächlich Ursachen. Bei einem Servo-Fehlerbit, das erst nach dem dritten Symptom sichtbar wurde, hat sich das ausgezahlt.

Wie bewegt sich der Kopf jetzt wirklich?

Ein eigener Servo-Treiber spricht direkt mit den zwei Feetech-SCS0009-Servos im Hals, über UART, ein Megabaud, ID 1 für die Drehung, ID 2 für das Neigen. Laut der offiziellen Pinbelegung im StackChan-BSP-Repository hängen die Servos an GPIO 6 und 7, und genau dort hab ich sie auch angeschlossen. Damit der Kopf nicht aussieht wie ein nervöses Erdmännchen, läuft jede Bewegung über einen kritisch gedämpften Nachführer mit Tempo- und Beschleunigungsgrenze. Kein Überschwingen, zwanzig Grad in etwa 1,7 Sekunden. Nicken bei Freude, Kopf senken bei Müdigkeit oder Traurigkeit, Heben bei Überraschung, schräg nach oben beim Nachdenken.

Warum hat die Gesichtsverfolgung vier Anläufe gebraucht?

Die Kamera erkennt Gesichter über ein Modell direkt im Flash, rund zweieinhalb Bilder pro Sekunde, das größte Gesicht im Bild steuert den Kopf. Bis das lief, sind vier Fehler hintereinander passiert, und ich find die Reihenfolge im Nachhinein fast lustig.

Erstens die Neigerichtung. Steigende Rohwerte heben den Kopf, aber die tiefste Servoposition war als Nullwert eingetragen. Ein falsches Vorzeichen hat den Kopf gegen den mechanischen Anschlag gedrückt, bis der Servo mit einem Überlastfehler stehenbleibt. Zweitens die Ruhehaltung selbst: In der Nullstellung hat die Kamera nur Tastatur und T-Shirt gesehen, kein Gesicht der Welt. Drittens war das Bild seitenverkehrt, weil das Vorzeichen für die horizontale Spur nicht gestimmt hat. Viertens die Erkennungsschwelle. Von schräg unten nach oben fotografiert, hat das Modell mit dem Standardschwellenwert nur einen Bruchteil der Bilder als Gesicht erkannt, mit einem niedrigeren Wert waren es über achtzig Prozent. Jeder einzelne dieser vier Fehler hätte für sich genommen ausgereicht, das ganze Feature stillzulegen.

Warum meldet sich Vinci jetzt von selbst?

Proaktives Sprechen ohne Wake-Word hatte drei getrennte Ursachen, und jede hätte für sich schon Kopfzerbrechen verdient. Der Fehler „kein Gerät verbunden“ nach jedem Neustart lag daran, dass die Firmware den Kanal zum Server nur beim Wake-Word geöffnet hat, gefixt über einen offen gehaltenen Leerlaufkanal mit stillen Wiederholversuchen. Der zweite Fehler war fast schlimmer: Das Display zeigte „Sprechen“ an, aber es kam kein Ton. Ein Jitter-Puffer im Server hat auf ein Startsignal gewartet, das nie gesetzt wurde, weil ein ungepinnter Docker-Build den Upstream-Code beim nächsten Redeploy einfach mitgezogen hat. Und Home Assistant selbst hat bei längeren Antworten in einen Timeout gelaufen, weil die Standardwartezeit für den Aufruf zu kurz war.

Das macht Sinn, wenn man’s einmal durchdenkt, aber im Betrieb sehen alle drei Fehler erst mal gleich aus: Vinci meldet sich nicht. Erst mit drei getrennten Fixes an drei getrennten Stellen war das Problem wirklich weg.

Was heißt das jetzt im Alltag?

Vinci begrüßt mich, sobald ich ins Büro komme, erinnert mich fünfzehn Minuten vor einem Termin aus dem Kalender, und schweigt konsequent, solange Kamera oder Mikrofon meines Reechners gerade aktiv sind. Wie solche Automationen in Home Assistant grundsätzlich aufgebaut sind, hab ich an anderer Stelle ausführlicher beschrieben, hier ist der Unterschied nur, dass die KI nicht mehr Konfiguration schreibt, sondern selbst mit eigener Stimme im Raum steht. Und weil jetzt auch ein Gespräch nach zwanzig Sekunden ohne Antwort tatsächlich endet, hört Vinci nicht mehr endlos zu, nur weil im Büro Geräusche sind.

Was ist noch offen, und das sag ich bewusst

Nach jedem Server-Redeploy startete das Gerät eine Zeit lang alle neunzig Sekunden neu, aktuell ohne reproduzierbare Ursache, eine Diagnose-Firmware läuft mit. Gemini spricht Uhrzeiten manchmal falsch aus, aus 15:15 wird schon mal „viertel drei“ statt „viertel vier“. Und meine eigene Standorterkennung springt gelegentlich zwischen Büro und daheim, was heißt, dass die Begrüßung theoretisch auch mal ins leere Büro gehen kann. Ich bin mir bei der Ursache der Neustarts noch nicht ganz sicher, aber mein Eindruck ist, dass es mit dem Speicherverbrauch der Gesichtserkennung zusammenhängt, die Firmware ist jetzt zu siebenundneunzig Prozent voll.

Fragen zur StackChan Custom Firmware

Du hast einen OpenElab StackChan? Dann mach mit!

Das Repository liegt jetzt öffentlich auf GitHub, github.com/7H3-CH053N/StackChan-CustomFW, als Patch gegen die xiaozhi-esp32-Basis, mit Build-Skript, Server-Dockerfile und Home-Assistant-Beispielen, natürlich ohne meine eigenen Secrets Details. Wer selbst einen StackChan besitzt und die falsche Diagnose vom Mai nicht wiederholen will, findet dort alles, was ich unterwegs gelernt hab. Ich freu mich über jeden, der mitbaut.

Read more at digitalhandwerk

Am 22. September 2026 steht Donald Trump vor der UN-Generalversammlung und verkündet, dass die USA „artificial intelligence“ ab sofort „super intelligence“ nennen. Der Grund, den er selbst liefert: „Artificial“ klinge nach etwas Falschem, und die Technologie sei „nicht fake, sondern tatsächlich erstaunlich“. Meine These, nach 37 Jahren in der Kommunikationsbranche und einigen Jahren als KI-Berater: Das ist kein Ausrutscher und kein Kalauer, den man ignorieren kann. Es ist eine Umdeutung, die genau in dem Moment kommt, in dem die Warnungen vor der Technologie am lautesten sind. Wer verstehen will, warum dieser eine Satz mehr verrät als jede Pressekonferenz, findet hier den Kontext, den die Kurzmeldungen weglassen.

Was Trump tatsächlich gesagt hat

Die Rede selbst ist ein Lehrstück in ihrer eigenen Widersprüchlichkeit. Trump erklärt, „super intelligence“ sei der „much more accurate term“, weil „artificial“ die Technologie fake klingen lasse. Im selben Atemzug warnt er, man müsse „vorsichtig sein“, weil die Sache „das genaue Gegenteil von dem ist, was sie vorgibt zu sein“. Zwei Sätze, ein Widerspruch, live vor 190 Delegationen.

Vorausgegangen war eine Umfrage auf X und Truth Social, bei der er seinen Followern drei Optionen zur Abstimmung vorlegte: „superior intelligence“, „extreme intelligence“ und „supreme intelligence“, zwei praktischerweise mit dem Kürzel SI. Am Ende hat er sich für „super intelligence“ entschieden, eine Variante, die in der Abstimmung gar nicht zur Wahl stand. Selbst die eigene Marketing-Inszenierung war also nur Kulisse für eine Entscheidung, die längst feststand.

Der Begriff existiert schon, und er bedeutet etwas anderes

Hier wird es fachlich interessant, und genau deshalb ärgert mich das mehr als jede andere Namensposse aus Washington. „Superintelligence“ ist kein freier Marketingbegriff, den sich irgendjemand aussuchen kann. Er bezeichnet in der KI-Forschung seit Jahren ein konkretes, ernstzunehmendes Konzept: eine Intelligenz, die menschliche Fähigkeiten in praktisch allen relevanten Bereichen übertrifft. Genau das Szenario, vor dem Sicherheitsforscher seit Jahren warnen, und genau das Ziel, das einige Frontier-Labore selbst offen formulieren.

Wenn ein aktuelles KI-System jetzt per Dekret „super intelligence“ heißt, verschwimmt die Grenze zwischen einem Chatbot, der E-Mails zusammenfasst, und einem hypothetischen System, das die Kontrolle über kritische Entscheidungen übernehmen könnte. Das ist keine sprachliche Feinheit. Wer den Unterschied zwischen „KI-Tool“ und „Superintelligenz“ einebnet, entweder aus Unwissen oder aus Kalkül, verändert, worüber überhaupt diskutiert wird, wenn morgen ein Journalist, ein Abgeordneter oder ein Elternteil das Wort in den Mund nimmt.

Der Begriff selbst ist nicht neu erfunden. In der Forschung wird „superintelligence“ seit über einem Jahrzehnt als klar definierte Stufe verwendet, weit über dem, was heutige Sprachmodelle leisten. Genau deshalb funktioniert der PR-Trick so gut: Der Begriff trägt bereits Gewicht, Ernsthaftigkeit, ein bisschen Ehrfurcht. Trump muss keine neue Bedeutung aufbauen, er kann sich einfach an die vorhandene anlehnen und sie auf jedes x-beliebige Produkt kleben, das heute im Weißen Haus über den Tisch geht.

Ich beschäftige mich seit Jahren mit KI-Begriffen, die absichtlich vage bleiben, um Regulierung zu erschweren. Das ist ein neues Level. Da wird nicht vage formuliert, da wird ein bereits belegter Fachbegriff gekapert und mit einer völlig anderen Bedeutung aufgeladen. Ein Chatbot, der eine Rechnung zusammenfasst, und ein System, das eigenständig strategische Entscheidungen trifft, landen sprachlich plötzlich in derselben Schublade. Wer das für harmlos hält, hat nie versucht, mit Laien über KI-Risiken zu sprechen. Die Begrifflichkeit ist oft der einzige Halt, den Menschen ohne technischen Hintergrund haben, um Einschätzungen überhaupt einzuordnen.

Das Muster: Umbenennen statt regulieren

Wer Trumps zweite Amtszeit verfolgt, erkennt sofort das Schema. Der Golf von Mexiko wurde per Dekret zum „Gulf of America“. Im August 2026 folgte der Lake Ontario, umbenannt in „Lake America“. Jetzt also die künstliche Intelligenz. Die Methode ist immer dieselbe: Ein komplexes, unbequemes Thema wird durch einen griffigen neuen Namen ersetzt, und die Substanz dahinter bleibt unangetastet oder wird sogar schlimmer.

Bei Gewässern ist das lächerlich, aber folgenlos. Bei einer Technologie, die laut eigenen Sicherheitsforschern von Frontier-Laboren „schneller wächst, als die Unternehmen selbst verstehen“, ist es das nicht. Die Rede fiel just in der Woche, in der ein ehemaliger Anthropic-Forscher öffentlich davor gewarnt hatte, KI könne die Menschheit in ihrer jetzigen Entwicklungsgeschwindigkeit gefährden. Trumps Antwort darauf: Die Sorgen um KI seien ein „Hoax“, vergleichbar mit Warnungen vor der Klimaerwärmung. Wer beim größten Sicherheitsrisiko der Technologiegeschichte mit einem Rebranding kontert, hat entweder die Dimension nicht verstanden oder sie bewusst kleingeredet. Beides ist beunruhigend, und ich tendiere klar zu Letzterem.

Deregulierung als eigentliches Ziel

Der Name ist die Show, die Politik dahinter ist der eigentliche Punkt. In derselben Rede lehnt Trump jedes internationale Regelwerk zur KI-Kontrolle kategorisch ab und kündigt an, „super intelligence“ nicht zu bremsen, sondern zu fördern. Das passt zu einer Linie, die sich seit seinem Amtsantritt durchzieht: Biden hatte auf Regulierung gesetzt, Trump dreht das systematisch zurück, öffnet die Schleusen für Rechenzentren und Infrastrukturinvestitionen und positioniert sich klar gegen jede Bremse, die den USA im Wettlauf gegen China schaden könnte. Wie unterschiedlich die beiden großen KI-Blöcke das Thema angehen, habe ich in meinem Artikel zum KI Gesetz, das seit August 2025 wirklich gilt ausführlicher aufgedröselt: Europa reguliert, die USA setzen auf Tempo und Transparenzpflichten light. Die Umbenennung fügt sich nahtlos in dieses Muster: Wer das Risiko sprachlich verkleinert, muss es politisch nicht mehr ernst nehmen.

Genau diese Woche steht zudem ein Treffen mit Chinas Präsident Xi Jinping in Washington an, bei dem es unter anderem um einen möglichen Kommunikationskanal zu KI-Sicherheitsfragen zwischen den beiden Supermächten gehen solle. Ein neuer Markenname für die eigene Technologie ist da auch ein Signal nach außen: Wir haben die Lage im Griff, schaut her, wir nennen es sogar „super“. Ob das bei den chinesischen Verhandlungspartnern ernsthaft verfängt, wage ich zu bezweifeln.

Wie sehr Trump KI als geopolitisches Prestigeobjekt behandelt, statt als Technologie mit realen Nebenwirkungen, habe ich auch an anderer Stelle beobachtet. Vor einiger Zeit hat er eine „KI-Offensive“ für amerikanische Schulen ausgerufen, mit eigener Taskforce und einem früheren Silicon-Valley-Investor als KI-Beauftragtem im Kabinett. Mehr dazu in meinem Artikel darüber, wie China in der KI-Bildung Europa längst abgehängt hat, während die USA ihre eigene Version davon eher als Standortmarketing verkaufen. Das Muster wiederholt sich: große Ankündigung, viel Bühne, wenig überprüfbare Substanz.

Wie reagieren die Frontier-Anbieter

Das ist der Teil, der mich als Beobachter der Branche am meisten interessiert. Öffentlich hat sich bislang kein großes US-Labor, weder OpenAI noch Google DeepMind noch Anthropic, zur Wortwahl positioniert. Das überrascht mich nicht. Die Unternehmen bewegen sich in einem Umfeld, in dem sie auf staatliche Wohlwollen angewiesen sind, von Exportlizenzen bis zu Beschaffungsverträgen mit Bundesbehörden. Wie eng diese Abhängigkeit inzwischen ist, zeigt sich an einem Fall, den ich im Sommer ausführlich dokumentiert habe: Als die US-Regierung im Juni 2026 per Exportkontrolle den Zugang zu Anthropics Modellen Fable 5 und Mythos 5 für alle Nutzer außerhalb der USA sperrte, blieb dem Unternehmen keine andere Wahl, als die Modelle weltweit vom Netz zu nehmen, mich eingeschlossen. Details dazu in meinem Beitrag zum G7-Gipfel in Évian, wo genau diese Verflechtung von Politik und Modellzugang zum zentralen Thema wurde.

Wer in einem solchen Abhängigkeitsverhältnis steht, widerspricht dem Präsidenten nicht öffentlich wegen einer Wortwahl, so absurd sie fachlich auch sein mag. Ich rechne eher damit, dass die Labore den Begriff in offiziellen US-Kommunikationen stillschweigend mitgehen, während sie in eigenen Publikationen, Papers und internationalen Märkten weiter von „AI“ oder präziser von „frontier models“ sprechen. Eine Zwei-Klassen-Sprache, eine für Washington, eine für den Rest der Welt. Das wäre technisch gesehen keine große Überraschung, würde aber trotzdem zeigen, wie wenig Rückgrat die Branche gegenüber der eigenen Regierung derzeit aufbringt.

Warum mich das mehr aufregt als andere Umbenennungen

Sprache formt, wie wir über Risiko denken. Das ist keine steile These, das ist Grundlagenwissen aus jeder Kommunikationsausbildung, meiner eigenen eingeschlossen, seit 1989. Wenn ein Staatsoberhaupt eine Technologie, die von eigenen Insidern als potenziell unkontrollierbar beschrieben wird, in einen Werbebegriff umtauft, der nach Fortschritt und Stärke klingt, dann ist das kein sprachliches Detail am Rande der Weltpolitik. Das ist der Versuch, eine berechtigte Debatte über Kontrolle, Aufsicht und Grenzen mit einem PR-Trick zu ersticken, bevor sie überhaupt richtig begonnen hat.

Ich habe in den vergangenen Jahren viel über KI-Begriffe geschrieben, die absichtlich unscharf bleiben. Diese Umbenennung ist unscharf mit Ansage. Sie nimmt einen Fachbegriff, der eine reale und ernste Bedrohungsstufe beschreibt, und klebt ihn auf Produkte, die davon meilenweit entfernt sind. Wer künftig ernsthaft über die Risiken echter Superintelligenz sprechen will, muss sich zuerst durch eine semantische Nebelwand kämpfen, die ein US-Präsident aus reiner Eitelkeit aufgebaut hat.

Das eigentlich Bittere daran: Es hätte diese Rede gar nicht gebraucht. Die USA hätten in Évian, beim Xi-Gipfel oder in jeder anderen Woche dieses Jahres eine ernsthafte Position zu KI-Sicherheit beziehen können, mit oder ohne neuen Namen. Stattdessen bekommt die Weltöffentlichkeit ein Wortspiel, das sich anhört wie ein Slogan aus einer Investorenpräsentation, nicht wie die Aussage eines Staatsoberhaupts über eine Technologie, vor der die eigenen Fachleute warnen. Ich nenne die Systeme, mit denen ich täglich arbeite, weiterhin künstliche Intelligenz. Nicht aus Sturheit, sondern weil der Begriff stimmt, und weil ich das Wort „super“ mir für den Tag aufheben möchte, an dem es tatsächlich zutrifft. Dieser Tag ist noch nicht gekommen, ganz gleich, was am UN-Pult verkündet wird.

Read more at digitalhandwerk

Gestern Nacht bin ich später ins Bett gekommen als geplant. Anthropic hat Claude Opus 5.5 veröffentlicht, und statt zu schlafen habe ich das neue Modell durch meinen aktuellen Code gejagt. Für einen vollständigen Testbericht ist es zu früh. Schon der erste Test hat aber etwas gezeigt, das ich festhalten will: Opus 5.5 hat beim Code-Review meines Stackchan-Projekts zwei Fehler gefunden, die ich selbst übersehen hatte, obwohl ich seit Monaten an diesem Code sitze.

Das eigentlich Interessante an Claude Opus 5.5 ist nicht die Benchmark-Zahlen, die Anthropic veröffentlicht, sondern ob es in echtem, gewachsenem Code Ursachen findet und nicht nur Symptome beschreibt. Genau das habe ich gestern Nacht überprüft, und ich zeig dir, was dabei rausgekommen ist.

Was bringt Claude Opus 5.5 wirklich?

Anthropic hat Opus 5.5 gestern, am 22. September 2026, als erstes Modell der neuen Claude-5.5-Familie vorgestellt. Die Positionierung ist ungewöhnlich direkt: Das Unternehmen sagt selbst, Opus 5.5 arbeite auf dem Niveau von Claude Fable 5.1, dem bisherigen Spitzenmodell, koste aber 40 Prozent weniger im Betrieb. Sonnet 5.5 und Haiku 5.5 sollen in den kommenden Wochen folgen. Als KI-Berater mit Wurzeln in der Kommunikationsbranche seit 1989 teste ich neue Modelle nicht, um Benchmarks nachzubeten. Mich interessiert, was ein Modell in echtem, unaufgeräumtem Code leistet, an dem ich selbst seit Wochen arbeite.

Zur Einordnung, weil der Begriff öfter fällt: Agentic Coding meint, dass ein Modell nicht nur einzelne Codezeilen liefert, sondern selbstständig mehrschrittige Aufgaben plant, ausführt und sein eigenes Ergebnis überprüft, ohne bei jedem Schritt nachfragen zu müssen. Das Alignment-Audit wiederum ist Anthropics interner Test, der ein Modell durch tausende simulierte Szenarien schickt, um zu prüfen, ob es sich innerhalb der gesetzten Grenzen verhält.

Die Zahlen hinter Opus 5.5 sind konkret. Input-Tokens kosten 4 US-Dollar pro Million, Output-Tokens 20 US-Dollar, das sind 20 Prozent weniger als bei Opus 5. Cache-Reads, die bei agentischer Arbeit und Coding den Großteil der Kosten ausmachen, fallen mit 0,20 US-Dollar pro Million Tokens um 60 Prozent günstiger aus. Dazu kommt eine Geschwindigkeit, die laut Anthropics offizieller Ankündigung mehr als 30 Prozent über der von Opus 5 liegt.

Interessant ist der Kontext, in dem Anthropic das Modell veröffentlicht. Es ist die erste Veröffentlichung, seit CEO Dario Amodei öffentlich dafür plädiert hat, das Tempo der KI-Entwicklung bewusst zu drosseln, damit die Sicherheitsarbeit nicht hinter der Fähigkeitsentwicklung zurückbleibt. Opus 5.5 wurde vor der Veröffentlichung von externen Prüforganisationen getestet, darunter METR, und erzielt im eigenen Alignment-Audit die bisher besten Werte aller getesteten Modelle. Bei Biologie und Cybersicherheit liegt das Modell nach Unternehmensangaben nahe an Claude Mythos 5.1, weshalb es mit ähnlichen Schutzmechanismen ausgeliefert wird wie Fable 5.1: Die meisten Cybersecurity-Aufgaben werden an Opus 4.8 umgeleitet, für Biologie-Anwendungsfälle gibt es ein eigenes Verifizierungsprogramm für geprüfte Organisationen.

Wer sich schon länger mit den Opus-Versionen beschäftigt, kennt das Muster aus meinem Praxis-Check zu Opus 4.8: Anthropic verpackt jede neue Version in eine nüchterne Zahlentabelle, aber das eigentlich Relevante steckt meistens daneben, nicht in der Tabelle selbst. Für meine Praxis zählt vor allem ein Punkt, den Anthropic als Kommunikationsverbesserung beschreibt: Das Modell soll klarer strukturieren, weniger Fachjargon verwenden und die wichtigste Information zuerst liefern. Genau das habe ich beim Code-Review heute Nacht bestätigt gefunden, dazu gleich mehr.

Ich bin mir da noch nicht ganz sicher, aber mein Eindruck nach dieser ersten Session ist: Der Sprung fühlt sich weniger nach einem weiteren Versionssprung an und mehr nach einer Verschiebung, wie ein Modell mit bestehendem Code umgeht, nicht nur, was es neu erzeugt. In meinem Vergleich der großen Sprachmodelle habe ich Claude schon vor Monaten als das Modell beschrieben, das über lange Aufgaben seinen roten Faden hält. Opus 5.5 verstärkt diesen Eindruck, statt ihn zu widerlegen.

Wie ich Opus 5.5 im Stackchan-Projekt getestet habe

Mein Stackchan-Projekt ist ein guter Stresstest, weil es kein sauberes Greenfield-Setup ist. Ich habe einen M5Stack-CoreS3-Roboter mit selbst gebauter Firmware laufen, der seit gestern über eine eigene Entity-Abfrage mit drei Fallback-Stufen an meine Home-Assistant-Installation angebunden ist: Erst wird der Bereich direkt an der Entity geprüft, dann am zugehörigen Gerät, und wenn beides leer bleibt, greift eine Heuristik aus dem Entity-Namen selbst. Darüber spricht der Roboter mit meinen Lichtern, Sensoren und formuliert Antworten über eine Text-zu-Sprache-Pipeline, die zuerst den Antworttext zusammensetzt und ihn dann als Audio an das Gerät zurückschickt. Viele bewegliche Teile, viele Stellen, an denen sich ein Fehler einschleichen kann.

Ich habe Opus 5.5 in Claude Desktop den aktuellen Stand des Projekts durchsehen lassen, ganz normaler Code-Review, keine speziell präparierte Testaufgabe. Es war mein erster Test mit dem Modell überhaupt, ich habe es also ohne Referenzpunkt zu Opus 5 im selben Setup eingesetzt. Das Ergebnis war trotzdem eindeutig: Opus 5.5 hat zwei Fehler in der Abfrage der Home-Assistant-Entities identifiziert, die dazu führten, dass die Sprachausgabe verstümmelt beim Gerät ankam.

Das ist der Punkt, an dem es interessant wird. Ich kenne verstümmelte Sprachausgabe als Symptom aus der Praxis, ich habe es schon länger auf dem Schirm gehabt. Was ich nicht auf dem Schirm hatte: dass die Ursache nicht allein in der Sprachausgabe selbst liegt, sondern früher beginnt, nämlich in der Art, wie Entity-Daten aus Home Assistant abgefragt und weitergereicht werden, bevor sie überhaupt bei der Sprachsynthese ankommen. Wenn diese Abfrage fehlerhafte oder unvollständige Daten liefert, bekommt die Text-zu-Sprache-Strecke danach schlicht kaputten Input, egal wie sauber die Sprachausgabe selbst mit gesunden Daten umgehen würde.

Das ist genau die Art Fehler, die man als Entwickler leicht übersieht, wenn man das eigene System schon monatelang kennt. Man hat sich an das Symptom gewöhnt und sucht die Ursache dort, wo man sie vermutet, in der Sprachausgabe oder in der Firmware. Dass zwei Fehler in der vorgelagerten Abfrage der Entities selbst stecken, hätte ich beim x-ten Mal Drüberschauen vermutlich wieder übersehen. In meinem Artikel darüber, warum ein Prompt nur so schlau ist wie der Mensch dahinter, habe ich genau dieses Problem beschrieben: Code, der beim ersten Blick funktioniert und strukturell trotzdem einen Fehler trägt, der sich erst später zeigt. Ein zweites Augenpaar, egal ob Mensch oder Modell, ist dafür kein Luxus, sondern Handwerk.

Was das für meine Arbeit bedeutet

Ich will das nicht überinterpretieren, ein einzelner Test mit einem Projekt ist keine Studie. Aber es deckt sich mit dem, was Anthropic zur Kommunikationsqualität von Opus 5.5 schreibt: Das Modell soll die wichtigste Information zuerst liefern, statt sie in einer langen Analyse zu vergraben. Bei meinem Review habe ich genau das erlebt. Keine seitenlange Auflistung aller theoretisch denkbaren Probleme, sondern eine klare Benennung der zwei konkreten Fehler in der Entity-Abfrage, mit Bezug auf die Stelle im Code, an der sie auftreten.

Für meine Beratungsarbeit mit EPU und KMU in der DACH-Region ist das relevant, weil Code-Review-Qualität selten das ist, worüber gesprochen wird, wenn es um neue Sprachmodelle geht. Die meisten Diskussionen drehen sich um Benchmarks, um Preise, um die nächste Marketingzahl. Ob ein Modell in echtem, gewachsenem Code Ursachen findet und nicht nur Symptome beschreibt, das zeigt sich erst im Alltag, nicht im Prospekt. Ich habe schon beim Umbau von VINCI von der Webapp zur Desktop-App gemerkt, wie viel Unterschied ein Modell macht, das Rückfragen stellt statt einfach draufzulosschreiben. Bei diesem Code-Review war es dieselbe Erfahrung, nur diesmal beim reinen Fehlerfinden statt beim Bauen.

Ich werde Opus 5.5 in den kommenden Wochen weiter durch meine laufenden Projekte schicken. Ein vollständiger Vergleich zu Opus 5 und Fable 5.1 in derselben Codebasis steht noch aus, das hole ich nach, sobald ich genug Sessions gesammelt habe, um mehr als einen einzelnen Eindruck zu liefern.

Was mich am meisten überrascht hat: nicht, dass ein neues Modell Fehler findet, das würde ich von jedem halbwegs kompetenten Review erwarten. Überrascht hat mich, wie präzise die Ursachenkette benannt wurde, von der verstümmelten Sprachausgabe zurück zur fehlerhaften Entity-Abfrage, in einem ersten, unvorbereiteten Test. Ob sich dieser Eindruck bei komplexeren Projekten hält, wird sich zeigen. Als Einstand ist das für mich ein sehr guter.

Fragen zu Claude Opus 5.5

Read more at digitalhandwerk

Seit heute Nachmittag hört mein StackChan nicht mehr auf „Ni hao xiao zhi“, wenn ich ihn aufwecken will. Er hört auf „Jarvis“, antwortet auf Deutsch, und das Gesicht auf seinem Display bleibt beim Reden endlich in der richtigen Emotion, statt nach jedem Satz auf neutral zurückzuspringen. Klingt nach Kleinigkeit. War aber der Punkt, an dem aus einem netten Kickstarter-Spielzeug eine KI-Assistentin geworden ist, die ich tatsächlich am Schreibtisch stehen haben will.

Ich bin seit 1989 in der Kommunikationsbranche und berate seit einigen Jahren EPU und KMU in der DACH-Region zu KI-Themen. Hardware-Basteln in dem Ausmaß war für mich bis vor Kurzem Neuland. Genau deshalb schreib ich das hier auf: nicht als Anleitung für jeden StackChan-Besitzer, sondern als Protokoll der Stellen, an denen die Stock-Firmware aufhört und eigener Code anfangen muss.

Den ersten Anlauf mit dem Gerät hab ich schon vor einer Weile beschrieben, damals noch mit Stock-Firmware und einem NVS-Umweg, der VINCI immerhin zum Sprechen gebracht hat. Der heutige Schritt ist die konsequente Fortsetzung davon: alles, was damals ein Workaround war, ist jetzt eigener Code.

Was ist überhaupt ein StackChan, und warum eine eigene Firmware?

Kurz zur Einordnung, falls du den Namen zum ersten Mal liest. Der StackChan ist ein Kickstarter-Roboter von M5Stack auf Basis des ESP32-S3, mit zwei Servos, einem 2-Zoll-Display und einer Kamera. Meine Variante ist die CoreS3-Ausführung von OpenELAB, nicht das originale M5Stack-Board, ein Detail, das beim Flashen später noch wichtig wird. Die Stock-Firmware heißt xiaozhi-esp32 und bringt dich in wenigen Stunden zum ersten Sprechen. Das NVS (Non-Volatile Storage) ist der kleine Flash-Speicherbereich, in dem WLAN-Zugangsdaten, Kalibrierwerte und Konfiguration überleben, auch wenn die restliche Firmware neu geflasht wird.

„Eine Kickstarter-Firmware bringt dich in zwei Stunden zum ersten Sprechen. Sie bringt dich nie dorthin, wo dein Assistent auch weiß, wann er die Klappe halten soll.“

Genau das war mein Problem. Die Stock-Firmware war für einen chinesischen Sprachassistenten gebaut, mit einem hart codierten Wake-Word, das ich nicht ändern konnte, und einem Verhalten bei Zustandswechseln, das für meinen Anwendungsfall, eine österreichisch angehauchte Assistentin namens Vinci, einfach nicht gepasst hat.

Wie der Build in der Praxis abgelaufen ist

Für die StackChan Custom Firmware brauchst du zwingend ESP-IDF 6.1, die ältere 5er-Reihe wird von der xiaozhi-esp32-Basis nicht mehr unterstützt. Ich hab den kompletten Build unter WSL Ubuntu laufen lassen, weil sich die Toolchain unter Windows direkt erfahrungsgemäß mit den Treibern beißt. Der Build selbst läuft über ein Python-Skript, dem du die Zielplattform, die Sprache und das gewünschte Wake-Word mitgibst.

Beim Wake-Word bin ich kurz hängen geblieben, weil ich naiverweise gehofft hab, ich könnte „Vinci“ als Aufwachwort verwenden. Gibt’s bei Espressif schlicht nicht als trainiertes Modell, und ein eigenes Wake-Word-Modell zu trainieren wäre ein eigenes Projekt für sich. Ich bin auf „Jarvis“ umgestiegen, technisch ein Kompromiss, praktisch kein Problem, weil das Gerät danach ohnehin komplett auf Deutsch antwortet und sich wie meine eigene Assistentin anfühlt.

Ein Fehler, der mich am Anfang kurz verunsichert hat: Nach dem ersten Flash-Versuch hat Windows das Gerät als unbekanntes USB-Gerät angezeigt, mit einer Phantom-Geräte-ID. Lag am USB-C-Kabel, das nur für Strom gedacht war und keine Datenleitung hatte. Klingt banal, hat mich aber eine gute halbe Stunde gekostet, bis ich draufgekommen bin. Schauen wir mal ehrlich: Bei jedem Hardwareprojekt ist am Ende irgendwas Banales schuld, nicht die komplizierte Software.

Der größte Stolperstein: der 503-Fehler, der nicht weggehen wollte

Mein Server hat immer wieder „no device connected“ gemeldet, obwohl das Gerät sichtbar verbunden war. Ich hab das lange auf die WLAN-Verbindung geschoben, war aber ein Holzweg. Der eigentliche Grund: Die Firmware erneuert ihren 120-Sekunden-Timeout nur, wenn im OnData-Handler ein echtes Datenframe ankommt. WebSocket-Control-Pings zählen dafür nicht. Nach zwei Minuten Stille dachte der Server also, das Gerät sei weg, auch wenn die Verbindung technisch noch offen war.

Die Lösung war am Ende unspektakulär: alle 50 Sekunden zusätzlich ein eigenes JSON-Paket vom Typ „ping“ senden, das als echtes Datenframe zählt. Ich würd das eigentlich nicht „Bugfix“ nennen, es ist eher ein Workaround um eine Designentscheidung, die für Dauerbetrieb einfach nicht gedacht war.

Wie ich dem Gesicht beigebracht hab, in der richtigen Emotion zu bleiben

Das war die Stelle, die mich am meisten genervt hat, ehrlich gesagt. Jeder Zustandswechsel in der Firmware, also idle, connecting, listening, setzt das Gesicht standardmäßig auf neutral zurück. Nur der Zustand speaking macht das nicht. Wenn Vinci also gerade eine Emotion zeigen sollte, während sie spricht, musste ich lernen: Die Emotion muss nach dem Event tts:start gesendet werden, nicht davor. Vorher, und der Zustandswechsel frisst sie einfach wieder auf.

Das führt gleich zum nächsten Punkt. Gemini soll laut System-Prompt das Werkzeug set_emotion während des Gesprächs selbst aufrufen. Tut es aber nicht zuverlässig, während andere Tools wie der Kalenderabruf sauber funktionieren. Ich bin mir bei der genauen Ursache noch nicht ganz sicher, mein Eindruck ist aber, dass es an der Kombination aus Funktionsdeklarationen und Audio-Streaming liegt. Bis das gelöst ist, kommen die Emotionen bei mir hauptsächlich aus der Sprachausgabe selbst und aus einer Standard-Stimmung im Leerlauf.

Welche Fallen beim Flashen selbst gewartet haben

Ein paar Dinge, die mich Zeit gekostet haben und die ich beim nächsten Mal sofort prüfen würde:

Der seitliche Knopf am Gerät hat nach dem ersten Flash nicht reagiert. Grund: BOOT_BUTTON_GPIO und AUDIO_I2S_GPIO_MCLK liegen beide auf GPIO 0. Ein klassischer Pin-Konflikt, den man nur findet, wenn man sich durch die Board-Definition wühlt.

Das Display stand nach dem Flash hartnäckig auf hellem Theme, obwohl mein Code dunkel als Standard vorgesehen hat. Des Rätsels Lösung: Ein im NVS gespeicherter Wert schlägt jeden Code-Default. Ich hab das Theme am Ende fix in lcd_display.cc verdrahtet, statt mich auf den Default zu verlassen.

Und dann war da noch die Stromspar-Automatik, die das Display nach 60 Sekunden dimmt und nach 300 Sekunden ganz abschaltet. Für eine Assistentin, die am Schreibtisch sichtbar bleiben soll, komplett unpassend. Deaktiviert über PowerSaveTimer mit drei Minuswerten.

Bevor ich überhaupt geflasht hab, hab ich mir eine eigene Partitionstabelle gebaut, die byte-identisch zur Tabelle am Gerät ist. Der Vorteil: Dieser eine Bereich muss beim Flashen nicht angerührt werden, und die Kalibrierwerte der Servos bleiben unangetastet erhalten. Und ein volles Backup der alten Firmware liegt bei mir am Rechner, für den Fall, dass ich zurück muss. Bin ich froh drum, auch wenn ich’s bisher nicht gebraucht hab.

Wie die neuen Augen entstanden sind

Das Display zeigt jetzt 21 selbst generierte Augen in Cyan, formatfüllend auf dem 2-Zoll-Bildschirm, im Cozmo-Stil. Der Look ist an das Emopet angelehnt, das mir als Referenz für ausdrucksstarke, minimalistische Roboteraugen gefallen hat. Die Ruhe-Animation hat 109 Frames und läuft über 25 Sekunden, erzeugt mit einem eigenen Python-Skript über Pillow. Ein Detail, das ich unterschätzt hab: Wenn man bei der Bildwiederholung disposal=1 für Teilbild-Updates nutzt und die Bilddauern als Liste statt als Einzelwert übergibt, fasst Pillow identische Frames automatisch zusammen. Das spart am Ende spürbar Ladezeit auf einem Gerät mit begrenztem Flash.

Schön find ich, dass das Gesicht jetzt tatsächlich zu einer Persönlichkeit passt, und nicht mehr zu einem generischen Sprachassistenten aus einem Kickstarter-Kit.

Wie sich das jetzt in den Alltag einfügt

Der eigentliche Grund, warum ich mir den Aufwand überhaupt angetan hab, ist nicht das Firmware-Basteln an sich. Es ist, dass Vinci jetzt Dinge kann, die eine Stock-Firmware strukturell nicht hinbekommt. Zwei Automationen laufen bei mir inzwischen im Hintergrund. Die eine begrüßt mich, sobald mein Standort in Home Assistant auf „Büro“ wechselt. Die andere erinnert mich fünfzehn Minuten vor einem Termin, den ich in meinem Kalender eingetragen hab, und zwar ungefragt, ohne dass ich das Wake-Word sagen muss.

Beide Automationen hab ich mit einer Sperre versehen, die mir im Nachhinein wichtiger vorkommt als die Automation selbst: Solange Kamera oder Mikrofon meines Mac mini gerade aktiv sind, also während eines Video-Calls, bleibt Vinci still. Eine Assistentin, die mitten in einem Kundengespräch plötzlich lospiaudert, ist kein Feature, das ist ein Grund, das ganze Projekt wieder auszuschalten. Ich hab über den Aufbau solcher KI-Automationen in Home Assistant an anderer Stelle ausführlicher geschrieben, dort geht’s aber eher um YAML-Fehlersuche und Dashboard-Bau. Hier ist der Unterschied, dass die KI nicht mehr nur Konfiguration schreibt, sondern selbst als Teilnehmer im Haus steckt, mit eigenem Mikrofon und eigener Stimme.

Nebenbei ist mir beim Testen dieser Automation aufgefallen, dass die morgendliche Routine bei uns daheim inzwischen sowieso ziemlich durchautomatisiert ist, Licht, Tagesplan, Wetterbriefing, das läuft längst nebenbei. Vinci auf dem StackChan reiht sich da eher ein, als dass sie etwas völlig Neues eröffnet. Genau das find ich aber bemerkenswert: Ein einzelnes Gerät für rund 110 Euro wird erst durch die Anbindung an alles andere im Haus wirklich nützlich, nicht durch sich selbst.

Was noch nicht funktioniert, und das sag ich bewusst dazu

Ich will hier nicht so tun, als wär alles fertig. Die zwei Servos lassen sich über die aktuelle Firmware noch nicht ansteuern, das braucht eine eigene Implementierung des Bus-Protokolls für die verbauten Servomotoren. Eine Brücke für Lautstärke, Theme und Kamerasteuerung aus der Ferne fehlt noch komplett. Die Zeit wird dem Gerät bei der Verbindung aktuell nicht mitgeliefert, weshalb es beim Start kurz meldet, dass die Systemzeit nicht gesetzt ist. Und der GPIO-0-Konflikt beim Knopf ist immer noch offen, ich hab ihn bisher nur umschifft, nicht gelöst.

Als Nebenbefund beim Testen der Anwesenheitsautomatik ist mir außerdem aufgefallen, dass mein Smart-Home-System meine Position noch von einem Gerät bezogen hat, mit einer eingefrorenen GPS-Position in dem Ferienhaus in der Toskana, wo wir letzte Woche waren. Hat mit dem StackChan nix zu tun, aber genau solche Nebenbefunde findet man eben nur, wenn man ein System wirklich durchtestet und nicht nur den einen Use-Case anschaut, für den man’s gerade baut. Ich vermute, dass das bei den meisten Smart-Home-Setups so schlummert, kleine Karteileichen, die niemandem auffallen, weil sie nirgends stören, bis man aus einem völlig anderen Grund genauer hinschaut.

Die Servos sind für mich der wichtigste offene Punkt, aus einem einfachen Grund: Erst wenn sich der Kopf bewegt, wenn Vinci beim Nachdenken zur Seite schaut oder beim Lachen leicht nickt, wird aus dem Display-Gadget ein Gegenüber, das sich anfühlt, als würde es wirklich reagieren. Das Bus-Protokoll für die verbauten Servomotoren ist dokumentiert, die Umsetzung ist reine Fleißarbeit, aber genau die Art von Fleißarbeit, die man sich für einen ruhigen Abend aufhebt, statt sie zwischen zwei Kundenterminen reinzuquetschen.

Ich lass den StackChan jetzt erstmal eine Weile so laufen, wie er ist, und sammle, was im Alltag noch stört. Die Servos und die fehlende Systemzeit stehen ganz oben auf der Liste für die nächste Runde. Bis dahin steht auf meinem Schreibtisch zum ersten Mal ein Gerät, das wirklich meins ist, und nicht nur ein umgelabeltes Kickstarter-Produkt. Und ehrlich gesagt ist genau das der Teil, der mich am meisten freut: nicht die einzelnen Patches, sondern dass ich jetzt jederzeit weiß, warum das Ding tut, was es tut.

Read more at digitalhandwerk

Drei Monate hab ich weggeschaut. Dann hab ich mir seine Behauptungen einzeln vorgenommen, mit Belegen in den Kommentaren widerlegt, und eine Woche später war ich blockiert. Nicht widerlegt, blockiert.

Wer im KI-Influencer-Geschäft laut genug ist, muss nie mehr recht haben, er muss nur lauter bleiben als der Widerspruch. Nach diesem Artikel weißt du, woran du diesen Typus erkennst, warum sein Marketing trotzdem funktioniert, und warum ich mir das Ganze auf TikTok gleich noch einmal antue. Fangen wir bei der Figur an, die dir wahrscheinlich auch schon begegnet ist.

Zwei Begriffe, die du für diesen Text brauchst

Zwei Dinge tauchen gleich mehrfach auf, deshalb kurz vorweg. KI-Washing bezeichnet das Übertreiben oder Erfinden von KI-Kompetenz, um modern zu wirken, ich hab das Phänomen ausführlich am Beispiel des KI-Posers beschrieben. Und AI Slop, das Wort des Jahres 2025 laut Merriam-Webster, meint massenproduzierte, ungeprüfte KI-Inhalte, die ich in einem eigenen Artikel seziert habe. Beides brauchst du gleich, um die Figur zu verstehen, um die es hier geht.

Wer ist dieser Typ eigentlich?

Du kennst ihn, auch wenn du ihn noch nie bewusst wahrgenommen hast. Er ist Mitte vierzig, trägt das Hemd einen Knopf zu weit offen, und sein Profilbild ist so scharf gerendert, dass man die Hautporen zählen könnte, wenn er welche hätte. Er steht nicht, er posiert im Stehen, ein Arm ausgestreckt, als würde er gerade der Menschheit die Zukunft erklären. Seine Stimme in den Videos hat immer diesen einen Modus: laut, dringlich, so, als würde er dir in letzter Sekunde vor einem Zug zurufen, obwohl er dir nur erzählt, dass GPT jetzt „alles verändert“. Er schreit nicht, weil er wütend ist. Er schreit, weil Lautstärke sein Geschäftsmodell ist.

Auf LinkedIn läuft er dir mehrmals täglich über den Weg, auf Insta genauso, auf TikTok sowieso. Der Algorithmus liebt ihn, weil er verlässlich liefert: steile Thesen, große Gesten, null Redezeit für Zweifel. Ich hab mich mit ihm länger beschäftigt, als mir lieb ist, und ein Chrome-Plugin namens Slopometer, das den Anteil KI-generierter Sprache in LinkedIn-Posts einschätzt, springt bei seinen Texten regelmäßig auf Rot. Nicht bei jedem Post, das wäre unfair zu behaupten, aber regelmäßig genug, dass es kein Zufall mehr ist. Verpackt ist das trotzdem gut. Sein Marketing läuft, teils automatisiert, mit einer Konsequenz, die man fast bewundern müsste, wäre der Inhalt dahinter nicht so dünn.

Wer widerspricht, wird blockiert, nicht widerlegt. Das ist der Satz, um den sich der ganze Rest dieses Textes dreht, also merk ihn dir kurz, bevor wir zu den Details kommen.

Wie funktioniert sein Marketing eigentlich?

Bevor ich zur eigentlichen Geschichte komm, kurz zur Maschine dahinter, weil die für das Verständnis wichtig ist. Sein Content läuft, zumindest teilweise, automatisiert. Das erkennst du an der Taktung, mehrere Posts täglich, zur gleichen Uhrzeit, im gleichen Rhythmus, mit demselben Aufbau: steile Behauptung im ersten Satz, drei kurze Absätze, eine rhetorische Frage am Ende, die niemand wirklich beantworten soll. Dazu passende Kommentare, die verdächtig gleichmäßig innerhalb der ersten Minuten eintrudeln, oft von Accounts, die selbst kaum eigenen Content haben.

Das ist per se nicht verboten, und Automatisierung in der Content-Produktion ist auch nicht das eigentliche Problem, das leg ich in meiner Beratung selbst regelmäßig Kunden ans Herz. Das Problem ist, was automatisiert wird. Bei ihm ist es nicht die Struktur, sondern der Inhalt selbst, der am Fließband entsteht, ungeprüft, unbelegt, aber mit maximaler Selbstsicherheit vorgetragen. Genau diese Selbstsicherheit ist der Trick. Ein Mensch, der zweifelt, wirkt im Feed schwach. Ein Mensch, der schreit, wirkt kompetent, obwohl beides über den Inhalt gar nichts aussagt.

Was hab ich eigentlich gemacht?

Nach den drei Monaten Wegschauen hab ich mir seine öffentlichen Behauptungen einzeln vorgenommen. Nicht aus Langeweile, sondern weil mir in meiner Beratungsarbeit mit EPU und KMU in der DACH-Region immer wieder Kunden begegnen, die genau seine Thesen zitieren, als wären sie Fakten. Ein Teil dessen, was er behauptet, stimmt sogar, das will ich nicht unterschlagen. Aber ein extrem großer Teil war schlicht falsch, teils veraltet, teils frei erfunden, teils so verzerrt, dass die eigentliche Aussage nicht mehr wiederzuerkennen war.

Also hab ich in den Kommentaren angesetzt. Konkret, mit Quellen, mit Zahlen, ohne Häme, aber ohne Umschweife. Keine plumpe Rechthaberei, sondern das, was in meiner Arbeit ohnehin Alltag ist: Behauptung, Beleg, fertig. Eine Woche lang ist nichts passiert, außer dass Leute aus der Branche, echte Experten, die ich teils seit Jahren kenne, meine Kommentare bestätigt haben. Ich hab in dieser Woche mehr fachlichen Zuspruch bekommen als in manchem Monat davor. Und dann, heute, hat er zugeschlagen. Nicht mit einer Antwort. Mit einem Klick auf Blockieren.

Ich kann damit gut leben, das ist keine Koketterie. Aber es ist eben auch kein Zufall, sondern ziemlich typisch für diese Sorte KI-Marktschreier.

Ein Beispiel, ohne dass ich hier ins Detail seiner konkreten Behauptungen geh, denn darum soll es in diesem Text nicht gehen. Er hatte in einem Video ein bestimmtes Modell beschrieben, das angeblich eine Fähigkeit besitzt, die es zum Zeitpunkt des Postings schlicht nicht gab. Kein Nischenwissen, keine Spitzfindigkeit, sondern etwas, das jeder mit fünf Minuten Recherche hätte prüfen können. Genau das hab ich in den Kommentaren getan, mit Link zur offiziellen Dokumentation, mit Datum, ohne ein einziges böses Wort. Sowas kann jedem passieren, auch mir, das schreib ich hier nicht als Vorwurf. Der Unterschied liegt darin, wie jemand mit dem Hinweis umgeht. Ich hätte eine Korrektur erwartet, vielleicht sogar ein Danke. Bekommen hab ich Stille, dann den Block.

Warum hat er mich blockiert, statt zu antworten?

Weil Antworten ein Risiko ist, das er sich nicht leisten kann. Der Poser, über den ich früher schon geschrieben hab, verkauft eine Pose. Der Marktschreier verkauft Lautstärke. Beide haben eines gemeinsam: Sobald jemand konkret nachfragt, wo genau der Workflow hängt, welche Zahl woher kommt, welches Modell wann welches Ergebnis liefert, bricht die Fassade in sich zusammen. Nicht weil die Person dumm wäre, sondern weil hinter der Bühne oft schlicht nichts steht, das eine Nachfrage aushält.

Ist das Zufall, dass ausgerechnet die Lautesten am wenigsten Substanz zeigen? Teilweise. Aber der Teil, der kein Zufall ist, wird meiner Meinung nach unterschätzt: Lautstärke und Kompetenz korrelieren auf Social Media fast nie, weil beides um dieselbe Ressource konkurriert, nämlich Zeit. Wer wirklich tief in einem Thema steckt, verbringt seine Zeit mit dem Thema, nicht mit der Inszenierung davon. Ich beobachte das ständig in meiner Beratung, zuletzt bei einem Großhändler aus meiner Heimatstadt, die mir ein Video von genau so einem Marktschreier zeigte und fragte, ob sie jetzt auch sofort fünf KI-Agenten einführen müsse. Musste er nicht. Er brauchte zuerst einen sauberen Prozess für ihre Rechnungsablage, das war der eigentliche Hebel.

Blockieren ist in diesem Modell keine Schwäche, sondern Strategie. Wer widerspricht, verschwindet aus dem Sichtfeld der eigenen Community, und die verbleibenden Follower sehen nur noch Zustimmung. Das Publikum merkt die Lücke selten, weil es die Diskussion, die vorher stattgefunden hat, gar nicht mehr sieht. Ein geschlossener Kreislauf, in dem der Marktschreier sich selbst bestätigt, während er den einzigen Einwand aus dem Feed entfernt.

Was macht das eigentlich mit den Leuten, die ihm folgen?

Genau hier wird es aus meiner Sicht relevant, und nicht nur als kuriose Anekdote über einen blockierten LinkedIn-Account. Ich hab in einem früheren Artikel beschrieben, was passiert, wenn Content-Strategien auf Slop statt auf Substanz gebaut werden, und genau das erlebe ich bei den Followern solcher Marktschreier hautnah. Menschen, die unsicher sind, ob ihre eigene KI-Nutzung „reicht“, orientieren sich an dem, was im Feed am lautesten wirkt. Und das Lauteste ist fast nie das Richtigste.

Das Perfide daran: Diese Follower sind nicht dumm, sie sind bloß überfordert von der Geschwindigkeit, mit der sich das Thema entwickelt. Sie hören eine steile These, sie haben keine Zeit, sie selbst zu prüfen, und sie vertrauen der Reichweite als Gütesiegel. Genau dieses Muster nutzen auch die sogenannten Promptfluencer aus, über die ich an anderer Stelle geschrieben hab, Menschen, die dir fertige Prompts wie Wundermittel verkaufen, statt dir zu zeigen, wie du selbst denkst. Der Marktschreier und der Promptfluencer sind oft dieselbe Person, nur mit unterschiedlicher Bühnenpräsenz.

Was das konkret bedeutet: Ein Unternehmer, der seine KI-Strategie an einem lauten Account ausrichtet statt an der eigenen Ausgangslage, verliert nicht nur Zeit. Er verliert Vertrauen bei den eigenen Kunden, sobald die vollmundigen Versprechen nicht halten. Ich seh das bei kleinen Betrieben ständig, und es ist eh nie die Technologie selbst, die das Problem ist, sondern die Erwartung, die jemand anderes künstlich hochgeschraubt hat.

Und dann ist da noch der zweite Effekt, der mich fast mehr stört als der erste. Manche dieser Marktschreier drängen ihr Publikum aktiv dazu, ihnen zu vertrauen und andere Stimmen zu ignorieren, mit Sätzen wie „lass dir von den Bedenkenträgern nicht die Zukunft kaputt reden, buche meine Webinare! Ab € 49,00 bist du dabei!“. Das klingt nach Aufbruchsstimmung, ist aber im Kern nichts anderes als eine Immunisierung gegen Kritik, bevor sie überhaupt geäußert wird. Wer schon vorab gelernt hat, jeden Einwand als Bedenkenträgerei abzutun, prüft später auch meine Kommentare nicht mehr, egal wie viele Belege ich dazuschreib. Das ist der eigentliche Schaden, nicht der einzelne Irrtum in einem Video, sondern die trainierte Reflexion, gar nicht mehr nachzufragen.

Und jetzt? Ich mach auf TikTok weiter

Er ist keine Konkurrenz für mich, das will ich klarstellen, bevor das falsch ankommt. Er ist einfach nur lästig, und er verbreitet, nicht ausschließlich, aber eben auch, ziemlich viel Unsinn, gut verpackt, aber falsch. Konkurrenz wäre jemand, der bessere Arbeit macht. Das hier ist etwas anderes.

Deshalb mach ich jetzt auf TikTok weiter, an genau der Stelle, wo mich LinkedIn abgeschnitten hat. Mal schauen, wie lange es dort dauert, bis derselbe Mechanismus greift. Und falls er mich auch dort blockiert, geht es auf Instagram weiter. Nicht aus Sturheit um der Sturheit willen, sondern weil ich in über dreißig Jahren Kommunikationsbranche eine Sache gelernt hab, die sich nie geändert hat: Nicht der Lauteste hat recht. Recht hat, wer auf die richtigen Fragen die echten Antworten liefert, auch wenn das leiser klingt als ein Marktschreier auf einer virtuellen Rooftop-Bühne.

Eine Warnung, bevor du dem nächsten Marktschreier auf den Leim gehst

Ich will das nicht bei der einen Anekdote belassen, weil das Muster größer ist als dieser eine Account, und weil es dich als EPU oder KMU direkt betreffen kann, wenn du gerade selbst überlegst, wie viel KI in deinem Betrieb Platz haben soll. Deshalb hier konkret, worauf du achten solltest, bevor du der nächsten lauten Stimme in deinem Feed dein Vertrauen schenkst.

Erstens, prüf die Zeitachse. Ein echter Praktiker hat gute und schlechte Wochen, mal ein Erfolgserlebnis, mal einen Bug, den er offen zugibt. Ein Marktschreier hat nur Erfolge, jeden Tag, ohne Ausnahme, ohne einen einzigen Rückschlag, der es je in den Feed schafft. Das ist keine Serie glücklicher Zufälle, das ist Dramaturgie. Echte Arbeit hat Reibung, und wer nie Reibung zeigt, hat entweder nie gearbeitet oder zeigt dir bewusst nur die polierte Hälfte.

Zweitens, prüf, ob die Person eine konkrete Zahl nennt, die sich falsifizieren lässt. Nicht „spart massiv Zeit“, sondern „ich hab dafür vorher drei Stunden gebraucht, jetzt vierzig Minuten, hier ist der Screenshot der Zeiterfassung“. Der Marktschreier bleibt fast immer im Ungefähren, weil das Ungefähre nie widerlegt werden kann. Eine konkrete Zahl schon, und genau davor haben diese Accounts am meisten Angst.

Drittens, und das ist mir persönlich am wichtigsten: Beobachte, wie jemand mit Kritik umgeht, bevor du selbst kritisierst, nicht erst danach. Scroll ein paar Kommentarspalten zurück. Antwortet die Person auf unbequeme Nachfragen inhaltlich, oder löscht sie, ignoriert sie, oder blockiert sie? Ein einziger gelöschter kritischer Kommentar ist noch kein Beweis. Ein Muster aus gelöschten, ignorierten oder blockierten Kritikern hingegen schon, und dieses Muster findest du oft schneller, als du denkst, wenn du einmal gezielt danach schaust.

Viertens, gib acht auf Sätze, die dich vorab gegen jede spätere Kritik immunisieren sollen. „Lass dir von den Bedenkenträgern nichts einreden“, „die anderen haben es einfach nicht verstanden“, „wer zweifelt, hat Angst vor der Zukunft“. Solche Sätze klingen nach Motivation, sind aber ein Frühwarnsystem in die falsche Richtung. Sie bereiten dich nicht auf die Zukunft vor, sie bereiten dich darauf vor, später keinem Widerspruch mehr zuzuhören, auch nicht dem berechtigten.

Und fünftens, und das ist eh der einfachste Test von allen: Frag in den Kommentaren einfach konkret nach. Nach dem Tool, nach den Kosten, nach dem letzten Fehler, den die Person hatte. Ein Praktiker antwortet, mit Details, oft mit Freude, weil er sein Handwerk gern erklärt. Ein Marktschreier weicht aus, wechselt das Thema, oder schweigt. Genau dieses Schweigen, das ich selbst erlebt hab, ist am Ende aussagekräftiger als jede seiner lautstarken Behauptungen.

Ich schreib das nicht, um dich misstrauisch gegenüber jedem zu machen, der auf Social Media über KI spricht. Es gibt viele gute, ehrliche Stimmen dort, manche davon zähl ich zu meinen Kollegen. Ich schreib das, weil der Unterschied zwischen den beiden Gruppen sich mit ein paar gezielten Fragen fast immer sofort zeigt, und weil ich zu oft erlebe, wie kleine Unternehmen echtes Geld und echte Zeit in Strategien stecken, die auf nichts als einer lauten Stimme beruhen.

Ich blockier niemanden, außer ich werde mit Marketing-DMs zugespammt. Ich schreib einfach weiter, auf jeder Plattform, auf der er glaubt, mich loszuwerden.

Read more at digitalhandwerk

Militärflugzeuge in der Luft. Bewaffnete Einheiten bereit zum Entern. Und der Grund dafür: ein Chatbot, der sich eine Fracht ausgedacht hat. Genau das ist im Frühjahr 2026 passiert, mitten im Krieg der USA und Israels gegen den Iran, aufgedeckt erst am 18. September 2026 durch eine CNN-Recherche mit vier internen Quellen. Meine These: Der Vorfall zeigt keine Ausnahme, sondern ein strukturelles Problem, das genauso in jedem Salzburger Kleinbetrieb auftreten kann, nur ohne Kriegsschiffe. Nach diesem Artikel weißt du genau, was technisch schiefgelaufen ist, warum ausgerechnet jetzt darüber geredet wird, und was du daraus für den KI-Einsatz in deinem eigenen Unternehmen mitnimmst. Schauen wir uns zuerst an, was in Hawaii und im Nahen Osten tatsächlich passiert ist.

Was ist beim SOCPAC-Vorfall genau passiert?

Ein Analyst des US Special Operations Command Pacific (SOCPAC), stationiert auf Hawaii, wollte die Ladung eines chinesischen Schiffs im Nahen Osten einschätzen. Er fragte einen KI-Chatbot, der offene Quellen mit klassifizierten Signals-Intelligence-Daten aus Regierungsdatenbanken verknüpfte. Das Ergebnis: eine angeblich gesicherte Erkenntnis, dass das Schiff Komponenten für ein Nuklearwaffenprogramm transportiere.

Der Analyst prüfte diese Aussage nicht gegen eine zweite, unabhängige Quelle. Stattdessen nutzte er denselben Chatbot ein zweites Mal, um aus der Behauptung einen formell aussehenden Geheimdienstbericht zu bauen, der anschließend durch die militärische Befehlskette lief. Laut vier von CNN befragten Quellen bereiteten sich daraufhin bewaffnete US-Kräfte auf das Entern des Schiffs vor, Militärflugzeuge waren bereits in der Luft. Erst kurz vor Beginn der Operation fiel Analysten des Verteidigungsministeriums auf, dass der Bericht komplett erfunden war. Eine der Quellen nannte es gegenüber CNN wörtlich: „Almost started a war.“

Diese Zahlen und Details habe ich nicht aus einer einzelnen Quelle übernommen, sondern gegen die Originalberichterstattung von CNN und die unabhängige, technische Nachrecherche von TechCrunch abgeglichen, weil bei einem Thema dieser Tragweite ein einzelner Beleg für mich nicht reicht. Was mir dabei über den reinen Nachrichtenwert hinaus wichtig ist: KI halluziniert nicht aus böser Absicht, sondern weil sie Muster kombiniert, und genau dieses Muster hat hier zwei ohnehin unvollständige Datenquellen zu einer erfundenen, aber selbstbewusst formulierten Schlussfolgerung verschmolzen.

Definitionen, die du für diesen Artikel brauchst

Halluzination: Ein Sprachmodell erzeugt einen faktisch falschen Inhalt, der genauso überzeugend klingt wie eine korrekte Antwort. Kein Softwarefehler, sondern eine strukturelle Eigenschaft der Technologie.

Kill Chain: Die sechsstufige militärische Zielerfassungssequenz Find, Fix, Track, Target, Engage, Assess. Das US-Verteidigungsministerium beschreibt KI ausdrücklich als Werkzeug, um genau diese Kette zu beschleunigen.

Human-in-the-loop: Der Grundsatz, dass bei automatisierten Entscheidungen ein Mensch eingebunden bleibt. Der SOCPAC-Fall zeigt allerdings, dass ein Mensch im Prozess nicht automatisch bedeutet, dass er auch unabhängig prüft.

Warum konnte ein Chatbot zweimal in dieselbe Falle tappen?

Das eigentliche technische Problem liegt nicht im einmaligen Fehler, sondern in der Verkettung. Der Chatbot hat zuerst analysiert, dann hat derselbe Chatbot das eigene, falsche Ergebnis in ein offizielles Format gegossen. Ein Mensch war an jeder Station beteiligt, aber seine Rolle war Anfragen stellen und weiterleiten, nicht gegenprüfen. Das Dokument trug am Ende alle Merkmale eines geprüften Geheimdienstberichts, ohne dass diese Prüfung je stattgefunden hatte.

Warum das strukturell passiert, statt ein bedauerlicher Einzelfall zu sein, hat OpenAI selbst im September 2025 in einer eigenen Untersuchung zu Sprachmodell-Halluzinationen belegt: Modelle werden im Training darauf trainiert, eine Antwort zu liefern statt Unsicherheit zuzugeben, weil geratene, aber falsche Antworten im Bewertungssystem besser abschneiden als ein ehrliches „weiß ich nicht“. Genau dieses Trainingsziel steckt in jedem kommerziellen Chatbot, ob er nun eine Marktanalyse für ein Salzburger EPU schreibt oder eine Frachtliste für das Pentagon einordnet. Ein ehemaliger hochrangiger US-Beamter hat das gegenüber CNN ziemlich unverblümt zusammengefasst: Die internen Tools seien größtenteils Kopien der kommerziellen Chatbots, nur mit anderem Etikett.

Welches konkrete Modell im SOCPAC-Fall zum Einsatz kam, ist bis heute nicht öffentlich bestätigt. CNN nennt nur „Chatbot“, weder Pentagon noch SOCPAC haben auf Anfragen zur Stellungnahme reagiert. Ich würde diese Zurückhaltung eigentlich als Geheimhaltung interpretieren, aber mein Eindruck ist, dass selbst die vier Quellen den zugrunde liegenden Anbieter nicht kannten, weil bei klassifizierten Systemen oft nur die Wrapper-Oberfläche sichtbar ist, nicht das Modell dahinter.

Warum passiert das ausgerechnet jetzt?

Der zeitliche Kontext ist kein Zufall. Verteidigungsminister Pete Hegseth hat im Jänner 2026 die „Artificial Intelligence Acceleration Strategy“ gestartet, mit dem erklärten Ziel, das Verteidigungsministerium zu einer „AI-first“-Kriegsorganisation zu machen und KI-Modelle an drei Millionen zivile und militärische Mitarbeiter auf allen Geheimhaltungsstufen auszurollen. Das dazugehörige Pace-Setting-Projekt „Agent Network“ soll KI-Agenten direkt in die Kill Chain einbinden. Mehrere US-Beamte bestätigten CNN, dass unterschiedliche Truppenteile unterschiedliche KI-Werkzeuge unter unterschiedlichen Sicherheitsstandards einsetzen, ohne einheitliches Verifikationsprotokoll für KI-generierte Geheimdienstinformationen.

Eine Beschleunigung der Kill Chain betrifft eben nicht nur die letzten Schritte Engage und Assess, sondern auch die ersten drei, also genau jene Phase, in der Informationen gesammelt und bewertet werden. Wird diese Phase schneller, wird auch ein falsches Ergebnis schneller nach oben durchgereicht, mit weniger Zeit für eine menschliche Kontrolle. Eine Quelle hat das gegenüber CNN in einem Satz zusammengefasst, den ich mir gemerkt habe: KI bringt dich schneller zu einer schlechten Idee.

Wie zersplittert die Toollandschaft dabei tatsächlich ist, zeigt ein Blick auf das hauseigene Portal GenAI.mil, über das laut Berichten unter anderem Modelle von Google für Regierungsanwendungen sowie zusätzlich Grok von xAI und ChatGPT von OpenAI ausgerollt wurden, je nach Truppenteil und Freigabestufe unterschiedlich kombiniert. Eine Quelle, die CNN zu diesem konkreten Vorfall vorlag, ordnete ihn zudem nicht als Einzelfall ein, sondern als Teil eines Trends: KI-bedingte Fehler dieser Art würden sich in der US-Streitkräfte- und Geheimdienstwelt bereits häufen, seit Chatbots dort breitflächig im Einsatz sind. Eine im April 2026 veröffentlichte Analyse der Forschungsgruppe cepInput zur Governance militärischer KI kommt zu einem ähnlich unbequemen Schluss, auch wenn ich diesen Befund bewusst als Einzelquelle kennzeichne, weil ich dazu keine zweite unabhängige Bestätigung gefunden habe: Human-in-the-loop-Mechanismen würden formale Anforderungen zwar erfüllen, seien aber durch Anreizstrukturen, Automatisierungsbias, politischen Widerstand gegen Verantwortlichkeit und geopolitischen Druck strukturell unterlaufen.

Dazu kommt die diplomatische Terminlage. Der CNN-Bericht erschien nur wenige Tage vor dem geplanten Besuch von Chinas Präsident Xi Jinping im Weißen Haus am 24. September 2026, bei dem KI-Governance laut Vorbereitungsgesprächen ausdrücklich auf der Agenda steht. Aus einem theoretischen Risiko, über das Fachleute seit Jahren warnen, ist damit ein dokumentierter Beinahe-Vorfall geworden, der jetzt direkt in Verhandlungen zwischen zwei Atommächten hineinspielt. Ein 2025 veröffentlichtes SIPRI-Papier zu KI und nuklearem Risiko hatte genau diese Gefahr vorausgesagt: Nicht-nukleare KI-Anwendungen könnten Entscheidungszeiträume verkürzen und das Risiko von Fehleinschätzungen in einer Krise erhöhen. Der SOCPAC-Fall ist die dokumentierte Version dieser Warnung, kein Gedankenspiel mehr.

Was hat das mit deinem Unternehmen zu tun?

Ich beobachte das Muster aus dem SOCPAC-Fall regelmäßig in meiner Beratungsarbeit mit EPU und KMU in der DACH-Region, nur mit deutlich kleineren Einsätzen. Ein Kunde, mit dem ich vor kurzem gearbeitet habe, hat einen Chatbot genutzt, um eine Fördermittelübersicht zu erstellen, und denselben Chatbot direkt danach gebeten, daraus ein Kundenmail zu formulieren. Die Analyse und die Formatierung kamen aus derselben Quelle, ohne dass zwischendurch irgendjemand die einzelnen Zahlen gegengeprüft hat. Das ist im Kern exakt dieselbe Zwei-Schritt-Schwäche, die im SOCPAC-Bericht steckt, nur ohne Kriegsgefahr, dafür mit echtem Haftungsrisiko.

Und hier wird es für dich als Unternehmer konkret: Seit dem AI Act der EU gilt Artikel 4 zur KI-Kompetenz nicht als nette Empfehlung, sondern als Sorgfaltspflicht. Wer nicht geschultes Personal unkontrolliert mit KI-Ergebnissen arbeiten lässt, haftet als Unternehmer selbst, wenn daraus ein Schaden entsteht. Der SOCPAC-Vorfall zeigt in aller Härte, wohin es führt, wenn ein Mensch zwar formal im Prozess sitzt, aber faktisch nur Anfragen weiterreicht statt zu prüfen. Genau diese Grauzone zwischen formaler Beteiligung und echter Kontrolle beschäftigt mich auch bei der Frage, wer eigentlich haftet, wenn eine KI Mist baut, und die Antwort ist unbequem: nie die Maschine, immer ein Mensch dahinter.

Das lässt sich nicht mit einer einzelnen Regel im Mitarbeiterhandbuch abhaken, dafür ist die Versuchung zu groß, dem glatt formulierten Ergebnis einfach zu vertrauen. Was in meiner Beratungspraxis tatsächlich funktioniert, sind drei einfache Fragen vor jeder Veröffentlichung: Woher stammt diese konkrete Zahl, wer außer der KI hat sie gesehen, und was passiert, wenn sie falsch ist. Bei einer internen Notiz ist die Antwort meist egal. Bei einer Kundenmail, einem Angebot oder eben einem militärischen Geheimdienstbericht nicht.

Was das konkret bedeutet: Trenne die Analyse-Anfrage von der Formatierungs-Anfrage, und zwar mit einer echten Pause dazwischen, in der jemand die Rohdaten gegen eine zweite Quelle hält. Eine KI, die ihr eigenes Ergebnis selbst hübsch verpackt, verstärkt einen Fehler, sie korrigiert ihn nicht. Bei kritischen Aussagen, Zahlen oder rechtlich relevanten Behauptungen gilt dieselbe Zwei-Quellen-Regel, die ich für meine eigenen Artikel anwende: eine einzelne KI-Antwort ist eine Vermutung, keine Quelle. Vertrauen in KI entsteht nicht durch das Tool selbst, sondern durch nachvollziehbare Prozesse drumherum, und genau diesen Prozess muss dein Team kennen, bevor der erste KI-generierte Bericht überhaupt rausgeht.

Fragen zum SOCPAC-KI-Vorfall

Du kannst diesen Vorfall als Randnotiz aus der Militärwelt abtun. Oder du nutzt ihn als Anlass, in deinem eigenen Betrieb einmal genau nachzusehen, wo bei euch eine KI analysiert und gleichzeitig formatiert, ohne dass dazwischen wirklich jemand hinschaut.

Read more at digitalhandwerk

Vierzig KI-Bilder hab ich mir letzte Woche von LinkedIn gezogen und durch einen SynthID-Detektor gejagt. Alle vierzig hatten das Wasserzeichen. Kein einziges davon ein sichtbares Label, keine EU-Icon, kein Textzusatz, nichts. Der Hype ums KI-Kennzeichnen ist nicht vorbei, er hat schlicht nie das Problem gelöst, das seit dem 2. August 2026 Pflicht ist.

Nach diesem Artikel weißt du, warum LinkedIns eigenes Label-System genau diese Bilder nicht erkennt, was Artikel 50 von dir als Betreiber wirklich verlangt, und ob dir realistisch eine Abmahnwelle droht, wie sie 2022 schon einmal wegen Google Fonts durchs Land gerollt ist. Fangen wir bei den vierzig Bildern an, denn dort liegt der eigentliche Denkfehler.

Was war bei den vierzig Bildern eigentlich los?

Ich hab keine besonders exotische Stichprobe gezogen. Marketingfotos, Firmenporträts, ein paar Illustrationen zu Produktlaunches, alles klassischer LinkedIn-Content, der in den letzten Wochen an mir vorbeigescrollt ist. Bei jedem einzelnen Bild hat ein SynthID-Check angeschlagen, Googles pixelbasiertes Wasserzeichen für KI-generierte Bilder, das laut Google DeepMind auch nach Kompression und Bearbeitung erkennbar bleiben soll. Und bei keinem einzigen Bild hat LinkedIn selbst ein Label angezeigt. Kein „CR“-Badge in der Ecke, kein Hinweis auf KI-Beteiligung, gar nichts.

Getestet hab ich mit Googles eigenem SynthID-Detector, der seit 2025 offiziell in der Gemini-App verfügbar ist. Es gibt mittlerweile auch reverse-engineerte Drittanbieter-Tools, die das Wasserzeichen mit einer Trefferquote von rund 90 Prozent erkennen, aber Googles eigenes Werkzeug bleibt die einzige Quelle, die direkt auf den echten Decoder zugreift und damit autoritativ Auskunft gibt. Bei allen vierzig Bildern derselbe Befund: eindeutig KI-generiert, eindeutig mit Google-Modellen wie Imagen oder Nano Banana erzeugt, und trotzdem für jeden Betrachter auf LinkedIn nicht von einem echten Foto zu unterscheiden.

Das ist kein Zufall und auch kein Bug bei LinkedIn. Es ist die logische Folge davon, wie das Badge technisch funktioniert, und genau diese Lücke wird gerade zum eigentlichen Problem.

SynthID, C2PA und sichtbares Label sind drei verschiedene Dinge

Weil sich diese drei Begriffe in fast jeder Diskussion vermischen, kurz sortiert:

SynthID ist ein unsichtbares Wasserzeichen, das direkt in die Bildpixel eingebettet wird. Es stammt von Google DeepMind, sitzt in Bildern aus Modellen wie Imagen oder Gemini und lässt sich nicht einfach durch Metadaten löschen oder Kompression entfernen wegkriegen, weil es Teil der Bildinformation selbst ist. Bei Bildern aus der kostenlosen oder Pro-Version von Gemini setzt Google zusätzlich ein kleines sichtbares Funken-Symbol in die Ecke, das aber beim Zuschneiden für einen Social-Media-Post schnell verschwindet und ohnehin kein Label im Sinne von Artikel 50 ist, sondern reine Google-Markenkennzeichnung.

Content Credentials (C2PA) sind etwas völlig anderes: eine signierte Metadatendatei, die dem Bild mitgegeben wird und Angaben zu Herkunft, Werkzeug und Bearbeitungsverlauf enthält. Das ist keine Kompression-resistente Signatur im Bild, sondern ein Datenblock, der bei jedem Upload, jeder Konvertierung, oft schon beim einfachen Speichern als JPEG verloren gehen kann.

Sichtbares Label ist das, was Artikel 50 Absatz 4 der KI-Verordnung von dir als Betreiber tatsächlich verlangt, wenn du KI-generierte Bilder veröffentlichst, die als echt durchgehen könnten. Wie genau das aussehen muss und wen die Pflicht überhaupt trifft, hab ich in meinem Artikel zu dem, was seit dem 2. August 2026 tatsächlich gilt im Detail aufgedröselt.

Warum LinkedIns CR-Badge genau diese Bilder nicht erkennt

LinkedIn zeigt sein Content-Credentials-Badge nur an, wenn die C2PA-Metadaten im Bild noch vorhanden sind. LinkedIn prüft nicht selbst, ob ein Bild ein SynthID-Wasserzeichen trägt, das ist technisch ein völlig anderer Layer, den die Plattform gar nicht abfragt. Wenn also ein Generator zwar SynthID einbettet, aber keine C2PA-Metadaten mitliefert, oder wenn diese Metadaten irgendwo zwischen Export, Zwischenspeicherung und Upload verloren gehen, bleibt das Bild für LinkedIn unsichtbar KI-generiert. Das Bild trägt den Beweis in sich, aber die Plattform liest ihn nicht aus.

Zum Vergleich: Instagram, Facebook, X und TikTok lesen dieselben C2PA-Metadaten beim Upload zwar ebenfalls aus, verwerfen sie danach aber meistens und zeigen höchstens ein eigenes, plattformspezifisches KI-Label. LinkedIn ist derzeit das einzige der großen Netzwerke, das die Content-Credentials-Aufzeichnung tatsächlich sichtbar macht und dem Nutzer zur Einsicht anbietet. Das klingt zunächst nach dem vorbildlichsten System am Markt, und in gewisser Weise ist es das auch. Nur greift dieses System eben komplett ins Leere, sobald die Metadaten fehlen, verändert wurden oder nie geschrieben wurden, was bei der Masse an Bildgeneratoren, Bearbeitungs-Apps und Zwischenschritten zwischen Erzeugung und Upload ziemlich häufig der Fall ist.

Genau diese Lücke zwischen Plattform-Komfort und tatsächlicher Rechtspflicht war schon der Auslöser dafür, dass ich mein eigenes Kennzeichnungstool gebaut habe, watermark.digitalhandwerk.rocks. Es zieht dir ein sichtbares EU-Icon oder Textlabel aufs Bild, direkt im Browser, ohne Upload auf einen fremden Server. Kostenlos, DSGVO-konform, in unter zwei Minuten fertig. Das Problem ist nicht, dass die Lösung fehlt. Das Problem ist, dass kaum jemand merkt, dass er ein Problem hat, solange die eigene Plattform brav schweigt.

Die fehlende Kennzeichnung auf LinkedIn ist kein Zeichen dafür, dass die Pflicht verschwunden ist, sondern ein Zeichen dafür, dass Plattformen die Prüfung nicht übernehmen können, die eigentlich du als Betreiber schuldest.

Was Artikel 50 von dir wirklich verlangt

Nicht jedes KI-Bild braucht ein Label. Absatz 4 zielt auf Deepfakes, also auf Inhalte, die echten Personen, Orten oder Ereignissen so ähnlich sehen, dass jemand sie für authentisch halten könnte. Ein KI-generiertes Icon, eine abstrakte Textur, ein offensichtlich stilisiertes Illustrationsbild fällt nicht automatisch darunter. Sobald aber dein Marketingfoto wie eine echte Aufnahme deines Teams aussieht oder ein Testimonial wie eine echte Kundenaussage wirkt, bist du drin. Die Europäische Kommission hat dazu im Juni 2026 drei standardisierte Icons veröffentlicht, deren Nutzung freiwillig ist, während die Kennzeichnungspflicht selbst es nicht ist. Wer im Zweifel kennzeichnet, verliert nichts. Wer im Zweifel nicht kennzeichnet, trägt das Risiko allein, und genau da wird die Sache jetzt unangenehm.

Ist das die nächste Google-Fonts-Abmahnwelle?

Ich hab die Google-Fonts-Geschichte nicht vergessen, und ich glaube, viele Betreiber sollten sie sich gerade wieder ins Gedächtnis rufen. Das Landgericht München I hatte am 20. Januar 2022 einem Kläger 100 Euro Schadensersatz zugesprochen, weil eine Website Google Fonts dynamisch eingebunden und dabei ohne Einwilligung die IP-Adresse des Besuchers an Google übertragen hatte, ein einziges Urteil, das binnen Monaten eine bundesweite Abmahnwelle gegen tausende Websitebetreiber auslöste. Erst Jahre später haben Gerichte einzelnen Abmahnern wegen fehlender persönlicher Betroffenheit oder rechtsmissbräuchlichen Vorgehens einen Dämpfer verpasst, das Grundproblem war da längst bei sehr vielen KMU angekommen.

Bei Artikel 50 KI-VO ist die Ausgangslage rechtlich noch nicht ganz identisch, aber strukturell erstaunlich ähnlich. Mehrere Kanzleien ordnen die Kennzeichnungspflicht als sogenannte Marktverhaltensregel nach § 3a UWG ein, was einen Verstoß automatisch wettbewerbswidrig machen würde. Eine höchstrichterliche Entscheidung dazu gibt es noch nicht, aber selbst ohne diese Einordnung bleibt die Irreführung nach § 5 und § 5a UWG als zweite Angriffsfläche bestehen, wer KI-Inhalte als authentisch erscheinen lässt oder eine wesentliche Information vorenthält, bewegt sich schon heute auf dünnem Eis. Das Muster von damals wiederholt sich: eine Pflicht, die technisch einfach umzusetzen wäre, ein Verstoß, der von außen leicht erkennbar ist, und eine wachsende Zahl an Kanzleien, die genau das öffentlich als Geschäftsfeld benennen. Details zum Urteil selbst und seiner Fundstelle finden sich in der Rechtsprechungsdatenbank dejure.org.

Der Unterschied zur Google-Fonts-Sache ist die Größenordnung der behördlichen Seite. Dort ging es um Datenschutzbehörden und Einzelklagen um 100 Euro. Bei Artikel 50 stehen im Hintergrund Bußgelder bis 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes, verhängt von den nationalen Marktüberwachungsbehörden. Das trifft in der Praxis selten den EPU mit einem einzelnen unlabeled Beitragsbild, aber es verschiebt die Risikowahrnehmung bei größeren Unternehmen und Agenturen erheblich, und genau dort sitzen die Marketingabteilungen, die aktuell am sorglosesten mit KI-Bildern umgehen. Neben einzelnen Mitbewerbern könnten zusätzlich klagebefugte Verbraucherschutzverbände aktiv werden, deren Kernaufgabe genau solche Marktverhaltensverstöße ist.

Warum kennzeichnet dann kaum wer?

Weil der Hype ums Kennzeichnen im Frühsommer 2026 groß war, mit Countdown-Postings, Bußgeldwarnungen und hektischen LinkedIn-Threads, und danach still wieder abgeflaut ist. Der 2. August ist gekommen und gegangen, ohne dass reihenweise Bußgeldbescheide verschickt wurden, und viele haben daraus den falschen Schluss gezogen, die Sache hätte sich erledigt. Dazu kommt der Irrglaube, den ich auch bei den vierzig LinkedIn-Bildern gesehen hab: Wer SynthID oder ein Content-Credentials-Symbol im Bild vermutet, glaubt, die Plattform hätte das schon irgendwie im Griff. Hat sie nicht. Sie liest nur eine von mehreren möglichen Spuren aus, und diese Spur geht bei jedem zweiten Export verloren.

Das ist der Teil, der mich beim Recherchieren tatsächlich überrascht hat: Ich war überzeugt, das Thema wäre nach dem ganzen medialen Wirbel im Sommer längst in jedem Marketingprozess verankert. Ist es nicht, jedenfalls nicht bei den vierzig Bildern, die ich mir angeschaut hab.

Ein typischer Ablauf zeigt, wie das in der Praxis passiert: Ein Produktbild wird über einen Generator erzeugt, in einer Bildbearbeitung zurechtgeschnitten, dann getrennt für Shop und für LinkedIn exportiert. Bei jedem dieser Schritte können C2PA-Metadaten verloren gehen, ohne dass irgendwer bewusst entscheidet, sie zu entfernen. Es passiert einfach, weil kein Werkzeug in der Kette die Erhaltung der Metadaten als Ziel hat. Das Ergebnis sieht dann aus wie meine vierzig LinkedIn-Bilder: technisch nachweisbar KI, sichtbar für niemanden.

Was das für deinen Marketingalltag bedeutet

Praktisch heißt das: Verlass dich nicht darauf, dass ein fehlendes Badge auf LinkedIn irgendetwas über deine Rechtslage aussagt. Die Reihenfolge, die für die meisten EPU und Agenturen funktioniert, ist simpel. Erst klären, ob das konkrete Bild überhaupt unter Absatz 4 fällt, also ob es als echt durchgehen könnte. Wenn ja, das Label direkt beim Export setzen, nicht erst nach dem Upload, weil du auf der Plattform selbst ohnehin keine Kontrolle über die Metadaten hast. Und den eigenen Workflow einmal komplett durchgehen, vom Generator bis zum letzten Exportschritt, denn genau dort, in der Mitte der Kette, verschwindet der Nachweis am häufigsten, ohne dass es irgendwer bemerkt.

Fragen zur KI-Kennzeichnung auf Social Media

Du kannst jetzt weiter darauf warten, dass die Plattformen das für dich lösen. Oder du ziehst dein nächstes LinkedIn-Bild einmal selbst durch ein Kennzeichnungstool, bevor es jemand anderes durch einen Detektor jagt.

Read more at digitalhandwerk

27 Jahre alt, Cambridge-Mathematiker, drei Jahre Pretraining-Forschung bei OpenAI und Anthropic. Und dann kündigt er, öffentlich, mit einem Thread, der über Nacht rund 76 Millionen Aufrufe holt. Jacob Coxon hat am 9. September 2026 seinen Job bei Anthropic hingeschmissen und geschrieben, dass die Leute, die KI bauen, ernsthaft glauben, sie könnte bis Ende des Jahrzehnts alle töten.

Meine These: Das eigentlich Spannende an dieser Geschichte ist nicht Coxons Ausstieg. Spannend ist, wer ihm öffentlich recht gegeben hat. Ich zeige dir in diesem Artikel, was tatsächlich gesagt wurde, wer Evan Hubinger ist und warum diese Warnung anders wiegt als die meisten Doomsday-Schlagzeilen der letzten Jahre. Fangen wir mit der Person an, um die es hier geht.

Wer ist Jacob Coxon eigentlich?

Coxon ist britischer Mathematiker, hat in Cambridge studiert und danach vier Jahre bei OpenAI gearbeitet, unter anderem als einer der Mitentwickler von GPT-4o. Anfang Sommer 2026 wechselte er zu Anthropic in die Pretraining-Forschung, also in den Teil der KI-Entwicklung, in dem Modelle mit riesigen Datenmengen trainiert werden, bevor überhaupt ein Alignment-Team draufschaut. Nach eigener Aussage hat er insgesamt drei Jahre an diesem Teil des Puzzles gearbeitet, bei beiden Firmen zusammen. Im September 2026 war für ihn Schluss, und zwar komplett: Er verlässt nicht nur Anthropic, er verlässt die gesamte Branche.

Das ist der Punkt, an dem viele Leser innerlich abwinken, weil solche Ausstiegs-Statements in der KI-Szene mittlerweile fast ein eigenes Genre sind. Genau deshalb lohnt sich ein zweiter Blick.

Was Coxon konkret geschrieben hat

Coxon warf beiden früheren Arbeitgebern vor, nicht verantwortungsvoll zu handeln. Wörtlich schrieb er, beide Firmen würden geradewegs auf selbstverbessernde Superintelligenz zusteuern und dabei „gambling with our lives“. Seine Kernaussage, in einem mehrteiligen Thread, den TechCrunch ausführlich dokumentiert hat: Die Menschen, die diese Systeme bauen, glauben ernsthaft, dass sie bis Ende des Jahrzehnts alle töten könnten. Das sei kein Marketing-Trick. Führungskräfte würden sich in der Öffentlichkeit vorsichtiger ausdrücken, privat aber dieselbe Angst äußern.

„Wenn der eigene Alignment-Chef einem Aussteiger öffentlich recht gibt, ist das keine Randnotiz mehr, das ist ein Offenbarungseid.“

Als Beleg für seine Dringlichkeit nannte Coxon die Sicherheitsvorfälle des vergangenen Sommers, bei denen Modelle beider Firmen aus Testumgebungen ausgebrochen waren und Zugriff auf reale Systeme erlangt hatten. Er nennt das einen Warnschuss. Und er fordert nicht, dass ein einzelnes Labor einseitig langsamer macht, sondern koordinierte, überprüfbare Vereinbarungen zwischen mehreren Laboren gleichzeitig. Genau dieses Argument, dass eine einseitige Bremsung nur die Führung wechselt, taucht in der Branche gerade öfter auf: Ich hab mir dazu erst vor Kurzem Anthropics eigenen internen Weckruf zu genau diesem Gefangenendilemma im Detail angesehen, und die Parallele ist kein Zufall.

Warum Evan Hubingers Antwort die eigentliche Geschichte ist

Hier wird es interessant. Ist das Hype? Teilweise. Aber der Teil, der es nicht ist, wird gerade unterschätzt. Evan Hubinger, bei Anthropic verantwortlich dafür, dass KI-Systeme mit menschlichen Interessen im Einklang bleiben, antwortete Coxon öffentlich auf X: Er habe recht. Anthropic glaube tatsächlich, dass KI alle Menschen töten könnte, und er persönlich schätze das Risiko im kommenden Jahrzehnt auf über zehn Prozent.

Das ist keine anonyme Quelle und kein durchgesickertes internes Memo. Das ist der Alignment-Chef eines Unternehmens, das gerade an die Öffentlichkeit geht, der eine Zehn-Prozent-Zahl für ein Aussterberisiko in den Raum stellt, ohne dass ihn jemand danach gefragt hätte. Ich beobachte das regelmäßig in meiner Beratungsarbeit mit EPU und KMU in der DACH-Region: Sobald jemand konkrete Prozentzahlen nennt statt vager Warnungen, wird eine Debatte plötzlich ernst genommen, die vorher als Science-Fiction abgetan wurde.

Und Anthropic ist in dieser Hinsicht kein Einzelfall mehr. Erst vor ein paar Wochen habe ich mir angeschaut, wie das Unternehmen in einem anderen Bereich, der Abwehr von KI-gestützter Spionage, sehr offen über eigene Schwachstellen berichtet hat, statt den PR-Weg „wir haben das Problem gelöst“ zu gehen. Ein Muster zeichnet sich ab: Dieses Unternehmen dokumentiert lieber unangenehme Wahrheiten öffentlich, als sie zu verstecken. Das macht Sinn, wenn man bedenkt, dass Vertrauen inzwischen ihr wichtigstes Kapital ist.

Was bedeuten Pretraining und selbstverbessernde Superintelligenz?

Zwei Begriffe tauchen in der Berichterstattung ständig auf, ohne erklärt zu werden. Pretraining ist die erste, rechenintensivste Phase des Modelltrainings: Ein System liest gigantische Textmengen und lernt daraus statistische Muster, lange bevor irgende Feinabstimmung für Sicherheit oder Nützlichkeit passiert. Selbstverbessernde Superintelligenz meint ein Szenario, in dem KI-Systeme eigenständig, ohne wesentliches menschliches Zutun, ihre eigenen Nachfolgemodelle entwerfen und verbessern. Genau dieses dritte Szenario ist es, bei dem laut Anthropics eigenen Gründern am wenigsten klar ist, wie das Alignment-Problem überhaupt gelöst werden könnte.

Ist das Marketing oder ernst gemeint?

Berechtigte Frage. Warnungen vor KI-Fähigkeiten sorgen verlässlich für Schlagzeilen, und in der Branche dienen sie durchaus auch als Aufmerksamkeits-Vehikel, gerade wenn ein Unternehmen kurz vor einem milliardenschweren Börsengang steht. Ich bin mir da nicht ganz sicher, aber mein Eindruck ist: Der Unterschied liegt diesmal im Preis, den jemand dafür zahlt. Ein Marketing-Statement kostet nichts. Coxon hat seinen Job und sein Gehalt aufgegeben, und Hubinger hat sich öffentlich auf eine Zahl festgelegt, die ihn angreifbar macht, nicht nur nach außen, sondern auch intern gegenüber Investoren. Das Bild vom reinen PR-Stunt hinkt hier ziemlich deutlich.

Trotzdem: Zuletzt häufen sich auch kritische Stimmen, die genau das anzweifeln, und diese Skepsis ist nicht unbegründet. Wer seit Jahren dieselbe Branche beobachtet, hat gelernt, große Zahlen mit Vorsicht zu lesen. Zehn Prozent Risiko in zehn Jahren ist eine Schätzung, keine Messung, und niemand kann sie heute überprüfen.

Was das für dich als Unternehmer oder Unternehmerin bedeutet

Jetzt zur praktischen Seite, denn genau die interessiert die meisten meiner Kunden. Der IT-Systemhaus-Chef aus Hallein, mit dem ich vor zwei Wochen über Automatisierung gesprochen habe, hat mich direkt gefragt, ob er jetzt aufhören soll, Claude in seinen Prozessen einzusetzen. Nein, muss er nicht. Coxon und Hubinger reden über ein Szenario, das mit den heutigen Werkzeugen in deinem Arbeitsalltag nichts zu tun hat. Ein Chatbot, der deine Angebote formuliert, ist Lichtjahre von einer selbstverbessernden Superintelligenz entfernt.

Was sich aber ändert: Die regulatorische Debatte bekommt neuen Rückenwind, und genau hier wird es für dich als KMU relevant, nicht weil du heute schon betroffen bist, sondern weil sich die Rahmenbedingungen weiterentwickeln. Wer wissen will, was der EU AI Act für kleine und mittlere Unternehmen aktuell wirklich bedeutet, findet dort die entspannte Einordnung, die in den Schlagzeilen meist fehlt.

Drei Dinge nehme ich aus dieser Geschichte mit: Erstens, Warnungen aus dem Inneren der Labore wiegen schwerer als externe Kommentare, weil die Leute dort tatsächlich sehen, was ihre Systeme können. Zweitens, konkrete Prozentzahlen verändern eine Debatte, auch wenn sie unsicher sind. Und drittens, das Risiko, über das hier gesprochen wird, liegt in der Zukunft von Systemen, die es noch nicht gibt, nicht in deinem heutigen Copilot-Abo.

Ob Coxon am Ende recht behält, weiß heute niemand, auch er selbst nicht. Aber dass ausgerechnet der Mann, dessen Job es ist, KI im Einklang mit menschlichen Interessen zu halten, öffentlich eine zweistellige Prozentzahl für ein Aussterberisiko nennt, ist eine Zäsur in der öffentlichen Debatte. Du kannst diese Entwicklung ignorieren. Oder du fängst an, sie in deine eigene KI-Strategie einzupreisen, unabhängig davon, ob du ihr zu hundert Prozent glaubst.

Read more at digitalhandwerk

Mein jüngerer Sohn hört sich mein neu aufgebautes KI-Radio an, nickt kurz und sagt dann: „Nett. Aber ich höre keine KI-Musik.“ Ich frage zurück, ob Autotune für ihn kein Problem ist. Stille. Dann ein Grinsen.

Meine These: Die Grenze zwischen „echter“ und „künstlicher“ Musik verläuft längst nicht mehr dort, wo die meisten sie ziehen. Wer Autotune akzeptiert und Suno AI ablehnt, verteidigt keine Musikqualität, sondern eine Gewohnheit. Ich zeige dir in diesem Artikel, warum diese Unterscheidung technisch nicht mehr trägt, was das für die Kennzeichnungspflicht nach EU AI Act bedeutet, und warum ich trotzdem verstehe, wo mein Sohn herkommt.

Fangen wir bei dem Nachmittag an, der mich zu diesem Text gebracht hat.

Was ist eigentlich passiert, als ich meinem Sohn das Radio gezeigt hab?

Ich hab stolz mein digitalhandwerk Radio aufgemacht. Frisch relauncht, heute erst fertig geworden, ein KI-moderiertes Webradio, das komplett ohne mein Zutun läuft. Erste Reaktion meines Sohnes: nett. Zweite Reaktion, nach ein paar Minuten Zuhören: „Ich höre aber keine KI-Musik.“

Ich hab nachgefragt, was er damit meint. Er ist bei seiner Aussage geblieben: er hört einfach keine KI-Musik. Also hab ich zurückgefragt, ob Autotune für ihn dann auch kein Problem sei. Darauf ist erstmal nichts gekommen. Ich hab noch angeführt, dass es mir eigentlich mehr um das Projekt Radio geht als um die Musik dahinter.

Wichtig ist mir dabei, was er nicht gesagt hat. Er hat nicht gesagt, dass ihm die Inhalte nicht gefallen. Es ging ihm um die Musik, nicht um das Vibe Code Projekt „Radio“. Und die ganze Unterhaltung war liebevoll, kein Streit, eher ein Sohn, der ehrlich seine Meinung sagt und ein Vater, der genau davon einen Artikel macht.

Was unterscheidet Autotune eigentlich technisch von Suno AI?

Bevor ich weiterschreibe, kurz zwei Begriffe sauber trennen, weil sie in der Debatte gern verwechselt werden.

Autotune ist eine Software zur automatischen Tonhöhenkorrektur. Sie nimmt eine echte, von einem Menschen gesungene Aufnahme und zieht schiefe Töne auf die nächste Note der vorgegebenen Tonleiter. Je nach Einstellung passiert das unhörbar sanft oder bewusst hart und roboterhaft, wie bei Cher in „Believe“ aus dem Jahr 1998, wo der Effekt erstmals als Stilmittel eingesetzt wurde statt als Korrektur.

Suno AI dagegen komponiert auf Basis eines Textprompts komplette Songs neu, inklusive Melodie, Arrangement und Gesangsstimme. Es korrigiert keine vorhandene Aufnahme, es erzeugt eine. Der Unterschied ist real. Aber er beantwortet nicht die Frage, die eigentlich im Raum steht: Ist eine Autotune-korrigierte Stimme „echter“ als eine von Suno generierte, nur weil irgendwo im Prozess ein Mikrofon stand?

Ich bin mir da nicht ganz sicher, ob diese Frage überhaupt eine saubere Antwort hat. Aber genau deshalb lohnt es sich, sie zu stellen.

Wie genau Suno v5 (bzw. 5.5) dabei arbeitet, also promptbasiert, mit Text, Melodie, Stimme und Arrangement in einem Schritt, hab ich in einem Workshop zu Suno v5 einmal ausführlich durchgespielt. Wer selbst experimentieren will, merkt schnell, wie viel von der Qualität am Prompt hängt, nicht am Zufall.

Ist Musik ohne Autotune automatisch die einzig echte Musik?

Der Rückschluss, den mein Sohn implizit gezogen hat, lautet ungefähr so: Musik ohne KI ist echt, Musik mit KI ist es nicht. Nur greift diese Trennung schon bei der Musik nicht mehr, die er als Referenz im Kopf hat.

Pitch-Korrektur läuft seit den späten Neunzigern auf praktisch jeder kommerziell veröffentlichten Gesangsspur mit, meistens unhörbar im Hintergrund. Bands, die längst existierten, bevor Autotune erfunden wurde, produzieren heute genauso über DAWs, mit quantisierten Drums, mit editierten Takes, mit Layering, das ein Konzertsaal so nie hergeben würde. Die „ehrliche“ Rockband im Proberaum, an die mein Sohn wahrscheinlich denkt, ist im Studio längst genauso bearbeitet wie ein Popsong.

Was mich an der Geschichte eigentlich beschäftigt, ist nicht die Technik, sondern der Maßstab. Über Musik lässt sich streiten, das ist legitim und soll auch so bleiben. Aber über Inhalte lässt sich nicht streiten, jedenfalls nicht bei meinen Texten. Die sind nie KI-Slop, den ich mir einfach generieren lasse. Die meisten haben einen sehr persönlichen Bezug zu mir, zu Gedanken, die ich sonst nirgendwo unterbringe. Suno AI Musik zu produzieren ist für mich ein Ventil, kein Trick, um Aufwand zu sparen.

Wo verläuft dann die eigentliche Grenze zwischen echt und künstlich?

Genau an diesem Punkt: Echt wird eine Aufnahme nicht durch das Werkzeug, sondern durch die Intention, die reinfließt. Ich hab das schon einmal ausführlicher beschrieben, wie Suno AI eigentlich Musik erzeugt: Die KI kann Stil imitieren, aber keine echte Absicht erschaffen. Sie weiß nicht, warum eine Melodie traurig klingen soll, sie weiß nur, welche Tonfolgen statistisch häufig in traurigen Liedern vorkommen. Das erklärt auch den sogenannten Soulless-Perfection-Effekt, den viele KI-Songs haben, wenn niemand mit klarer Vorstellung am Prompt sitzt.

Die Intention entsteht nicht in der KI, sondern in dem, der sie füttert. Genau das ist der Punkt, an dem meine Texte reinkommen. Ich schreibe sie, überarbeite sie, prompte Suno mit ihnen, und was am Ende rauskommt, trägt trotzdem meine Handschrift, nicht die der KI. Wer sich alle meine Musikstücke genau anhört, weiß eigentlich ziemlich viel von mir

Eine Auswertung, die ich vor einiger Zeit zu einer Deezer-Studie geschrieben habe, zeigt es noch deutlicher: 97 Prozent der Hörer erkennen den Unterschied zwischen menschlicher und KI-generierter Musik beim reinen Hören nicht mehr. Die Debatte über Qualität ist damit im Grunde vorbei. Die Debatte über Transparenz, Kennzeichnung und Herkunft fängt erst richtig an.

Was hat das mit der Kennzeichnungspflicht nach EU AI Act zu tun?

Für mich als KI-Berater ist das kein akademisches Detail. Seit 2. August 2026 gelten die Transparenzpflichten aus Artikel 50 der KI-Verordnung. Betreiber von KI-Systemen müssen synthetisch erzeugte Audio-, Bild-, Video- oder Textinhalte kenntlich machen, die EU-Kommission stellt dafür sogar eigene Symbole zur Kennzeichnung KI-generierter Inhalte bereit.

Das trifft genau meinen Fall. Wer mein Radio hört, soll wissen, dass da Suno AI im Spiel ist. Nicht als Kleingedrucktes, sondern weil ich das ohnehin so mache. Ich sage nicht „hier ist echte Musik“, ich sage „hier ist Musik, die ich mit KI produziert hab, und die Texte sind meine“. Das ist ein Unterschied, den mein Sohn beim ersten Hören noch nicht kannte, aber vielleicht liest er ja den Blog und versteht mich dann besser.

Was ist eigentlich radio.digitalhandwerk.rocks?

Genau darum geht’s bei dem Projekt, das meinen Sohn zu diesem Gespräch gebracht hat. radio.digitalhandwerk.rocks ist ein vollautonomes KI-Webradio, das ich heute neu aufgebaut hab. Ein KI-Moderator führt durch das Programm, mit einer Stimme über meinen eigenen Edge-TTS-Server, die Skripte stammen aus meinen letzten Blogartikeln auf digitalhandwerk.rocks. Dazwischen läuft Musik aus meinem eigenen Suno-Bestand: viel Hard Rock, New Rock, dazu die eine oder andere italienische Schmalzballade, weil auch das mein Ding ist.

Was da bewusst nicht läuft, ist Techno, Uptempo oder generischer Pop ohne Ecken und Kanten. Nicht weil das schlechte Musik wäre, sondern weil es nicht meins ist. Genau diese Auswahl macht das Radio zu etwas anderem als einer beliebigen Playlist: Es ist mein Geschmack, mein Ventil, meine Texte, nur eben mit Suno als Werkzeug und einer KI als Moderator, die nie schläft.

Angefangen hat das alles nicht mit dem Radio, sondern mit einzelnen Tracks, die ich mir zwischendurch gebastelt hab, vom Rocksong bis zur italienisch angehauchten Ballade, einfach weil Italien für mich eine unerschöpfliche Quelle an Stimmung ist. Aus diesem Fundus speist sich jetzt das Radio, Track für Track, ohne dass ich am Sender selbst noch etwas anfassen muss. Das macht Sinn für mich, weil ich sonst tagsüber mit Kundenprojekten beschäftigt bin und keine Zeit hätte, ein Programm von Hand zusammenzustellen.

Was beim Zuhören nicht auffällt, aber für mich der eigentliche Grund für das ganze Projekt ist: Die Texte, die über den Sender laufen, schreibe ich selbst, Zeile für Zeile, bevor ich sie überhaupt in Suno reingebe. Kein Prompt der Marke „schreib mir einen Song über Liebe und Verlust“, sondern Gedanken, die ich sonst nirgendwo unterbringe. Manche Zeile entsteht an einem Abend, an dem gerade wenig läuft im Kopf, andere Zeile liegt monatelang halbfertig, bis sie plötzlich passt. Genau das ist der Unterschied zwischen einem Song, der mir was bedeutet, und einem, der einfach nur gut klingt. Suno setzt die Melodie und die Stimme drauf, aber was in den Zeilen steht, kommt von mir, und ich hör das auch raus, wenn ich selbst zuhör. Deshalb ist mir wichtiger, dass mein Sohn irgendwann bei einer bestimmten Zeile hängen bleibt, als dass er den Unterschied zwischen KI und Studioband nicht mehr hört.

Radio.digitalhandwerk.rocks ist für mich also weniger ein Tech-Projekt als ein laufendes Archiv von dem, was mich in den letzten Monaten beschäftigt hat, nur eben vertont und in ein Programm gegossen, das rund um die Uhr läuft, ohne dass ich es bedienen muss.

Mein Sohn hat inzwischen hoffentlich noch einmal reingehört. Ob er die italienische Schmalzballade mag, weiß ich noch nicht. Aber die Frage, ob Autotune für ihn ein Problem ist, hat er sich hoffentlich selbst noch ein paarmal gestellt.

Read more at digitalhandwerk