Ein Sender ohne Redaktion, ohne Freigabe-Gate und ohne einen einzigen Menschen im Studio. Klingt nach Zukunftsmusik, ist bei mir aber seit heute im laufenden Betrieb, aktuell noch in der Beta-Phase. Ich habe ein KI-moderiertes Webradio gebaut, das nachts selbständig produziert, was am nächsten Tag läuft: Moderationen aus meinen eigenen Blogartikeln, dazwischen ausschließlich Musik aus eigener Produktion. Kein Techniker, kein Redakteur, keine tägliche Freigabe durch mich.
Als KI-Berater mit Wurzeln in der Kommunikationsbranche seit 1989 baue ich solche Systeme nicht zum Spaß, sondern weil ich verstehen will, wo Automatisierung trägt und wo sie kippt. Ich habe selbst geschrieben, dass die meisten EPU und KMU noch gar keinen KI-Agenten brauchen, und stehe zu diesem Satz. Ein Webradio, das sich selbst redigiert, gehört für mich zu den seltenen Fällen, in denen es sich wirklich lohnt. Was das konkret bedeutet, und welche Fehler mich dabei richtig Geld und Nerven gekostet haben, erzähle ich in diesem Artikel.
Der Anstoß kam von SARC-FM
Die Idee ist nicht bei mir entstanden. Arno Selhorst betreibt mit SARC-FM einen vollautonomen KI-Radiosender, und als ich zum ersten Mal reingehört habe, war mir klar: Das will ich auch versuchen, nur mit meinem eigenen Blog als Stoffquelle und meiner eigenen Musik als Klangbett. Arno hat mir großzügig Einblick in seine Erfahrungen gegeben, und ein Teil der Entscheidungen in meinem Setup basiert direkt auf dem, was bei ihm funktioniert oder eben nicht funktioniert hat. Trotzdem ist digitalhandwerk Radio kein Klon. Meine Sendung stellt Beiträge aus digitalhandwerk.rocks vor, moderiert von einer KI-Stimme, abwechselnd mit Musik, die ich selbst über Suno produziert habe. Dass Systeme heute nicht mehr nur reden, sondern selbständig handeln, habe ich zum Jahresbeginn ausführlicher eingeordnet, ein eigener Radiosender war für mich die konsequente Anwendung davon.
Wie die Sendung technisch entsteht
Kurz zusammengefasst: digitalhandwerk Radio ist ein vollautonomes, KI-moderiertes Webradio ohne redaktionelles Freigabe-Gate. Statt einer täglichen menschlichen Freigabe prüft ein zweites Modell jedes Moderationssegment gegen den Originaltext des Artikels. Besteht ein Segment diese Prüfung nicht, fällt es ersatzlos aus der Sendung. Lieber eine Lücke im Programm als eine falsche Zahl unter eigener Marke.
Ein Worker, geschrieben in FastAPI mit ffmpeg und SQLite, läuft als Container und erzeugt nachts die Skripte, die Sprachausgabe und den fertigen Mix. Meinem Blog eine Stimme zu geben (mittlerweile wieder eingestellt, das war zu „buggy“) war für mich der erste Schritt in diese Richtung, hier geht es aber nicht um einzelne Artikel zum Vorlesen, sondern um ein durchlaufendes Programm. Zur Laufzeit selbst braucht die Sendung dann gar keine Datenbank mehr. Sie besteht aus einem Manifest und den fertigen MP3-Dateien, und der Player im Browser rechnet seine eigene Position einfach aus der Wanduhr aus. Kein Stream im klassischen Sinn, trotzdem hören alle Zuhörer dieselbe Stelle im Programm. Das mag pragmatisch wirken, aber genau diese Einfachheit macht das System robust: Es gibt keinen Streaming-Server, der ausfallen kann.
Warum nicht jede Nacht alles neu?
Die erste Version hätte jede Nacht zehn Segmente komplett neu produziert. Bei ein bis zwei neuen Blogartikeln pro Tag waren acht oder neun davon aber inhaltlich unverändert, reine Doppelarbeit, die trotzdem Geld gekostet hat. Jetzt hält der Sender einen rollierenden Vorrat von zehn Moderationen. Ein Segment wird einmal produziert und danach wiederverwendet, bis ein neuer Artikel es verdrängt. Musik und Reihenfolge werden trotzdem jede Nacht neu gemischt, damit es nicht nach Konserve klingt. Der Effekt auf die Kosten war deutlicher als ich erwartet hätte: von rund 0,95 auf etwa 0,12 US-Dollar im Monat, gemessen mit echten Token-Werten.
Die teuerste Lektion: Zahlen gehören nicht ins Modell
Hier wird es interessant, und ehrlich gesagt auch ein bisschen ärgerlich, wenn ich an die Zeit denke, die ich mit Debuggen verbracht habe. Der ursprüngliche Plan sah vor, dass das Modell Zahlen für die Sprachausgabe direkt ausschreibt, aus „12,9 Milliarden“ sollte also „zwölf Komma neun Milliarden“ werden. Genau diese Regel war die dominierende Fehlerquelle im ganzen System. Gemessen über mehrere Läufe wurde aus „12,9 Milliarden“ zuverlässig „zwölfeinhalb“, aus „29 Märkten“ „zweiunddreißig“, aus „30 Billionen“ „fünfunddreißig“. In einem einzigen Lauf sind dadurch drei von fünf Segmenten komplett ausgefallen. Ich habe dem Prompt sogar das Gegenbeispiel wörtlich mitgegeben, geholfen hat es nichts.
Die Lösung war am Ende simpel, aber ich hätte früher draufkommen sollen: Das Modell schreibt die Ziffern exakt so, wie sie im Artikel stehen. Erst unmittelbar vor der Sprachausgabe wandelt ein deterministischer Nachbearbeitungsschritt über die Python-Bibliothek num2words die Zahlen in gesprochenen Text um. Die verallgemeinerte Regel, die ich nun auf jedes (passende) KI-Projekt anwende: Was sich deterministisch berechnen lässt, gehört nicht ins Modell. Eine zweite Beobachtung dazu, die ich so nicht erwartet hätte: Beispiele in Prompts wiegen schwerer als Regeln. Mein eigener Beispielsatz nannte „Milliarden Euro“, die Artikel sprachen aber von Dollar, und das Modell hat brav die falsche Währung aus meinem Beispiel übernommen statt der Regel zu folgen.
Der Prüfer, der sich selbst widerspricht
Der zweite Modellaufruf, der jedes Segment gegen den Artikeltext prüft, war anfangs selbst eine Fehlerquelle. Er hat Weglassungen beanstandet, obwohl eine Moderation naturgemäß nur einen Ausschnitt des Artikels herausgreift. Er hat Stellen als falsch markiert und in der Begründung gleichzeitig geschrieben, dass genau diese Stelle korrekt sei. Einmal hat er sogar wörtlich notiert, der Artikel spreche von 2026 und das Skript ebenfalls von 2026, das sei ein Widerspruch. Prompt-Regeln allein haben das nicht zuverlässig verhindert, sie greifen eben nur überwiegend.
Also filtert jetzt ein eigener Codeblock diese Scheinbeanstandungen deterministisch heraus, getestet gegen neun Fälle, die alle wörtlich aus echten Läufen stammen. Auch bei der Modellwahl war ich am Ende pragmatischer als geplant: Für Skript und Prüfung läuft ein einziges Modell, ein günstigeres wird nur als zweite Kaskadenstufe eingesetzt. Genau dieses günstigere Modell hat sich bei einfachen Zahlenvergleichen als ungeeignet erwiesen, bei einem Test mit „eine Million dreihunderttausend“ gegen „1,3 Millionen“ lag es dreimal von drei Versuchen falsch, während das Hauptmodell dreimal richtig lag. Eine kleine, aber teure Erkenntnis: Nicht jedes günstigere Modell in der Kaskade spart am Ende wirklich Geld, wenn es an der falschen Stelle sitzt.
Hosting-Fallen, über die ich gestolpert bin
Die Produktion läuft auf einem Container-Hosting, die Auslieferung dagegen rein statisch bei meinem bestehenden Webhoster, ganz bewusst getrennt. Zwischen beiden Welten lauern Fallstricke, die kein Tutorial erwähnt. Der Deploy-Pfad musste exakt stimmen, sonst sucht das System die Compose-Datei am falschen Ort, und der automatisch vergebene Containername ändert sich bei jedem neuen Deploy, taugt also nicht als feste Adresse für die Zeitsteuerung. Auf der Auslieferungsseite ist der Zugang bewusst eingeschränkt, ohne Kommandozeile, nur für den reinen Dateitransfer gedacht, und der Standard-Cache liegt bei einem Jahr. Ohne eine eigene Cache-Regel wäre das Sendungsmanifest schlicht eingefroren gewesen, und niemand hätte je eine Programmänderung gehört.
Eine zweite Falle beim Dateiabgleich: Ein reiner Größenvergleich reicht nicht, wenn sich nur ein Versionszähler in der Startseite ändert, ändert das kein einziges Byte an der Dateilänge, und die eigentliche Änderung würde stillschweigend liegen bleiben. Der Abgleich prüft deshalb zusätzlich den Zeitstempel. Und weil das einbettbare Widget auf einer anderen Adresse läuft als die Sendung selbst, musste ich auch bei den Zugriffsrechten im Webserver nacharbeiten, damit die Einbettung auf allen gewünschten Domainvarianten funktioniert.
Musik: viel Rock, ein bisschen Italien
Zwischen den Wortbeiträgen läuft ausschließlich eigene Musik, 59 Tracks aus meiner Suno-Produktion, zusammen 229 Minuten, alle einmalig auf minus 16 LUFS normalisiert, damit niemand mitten in der Nacht am Lautstärkeregler drehen muss. Der Stil ist primär Rock, was bei einem Sender, der unter dem Namen Prompt Rocker läuft, jetzt auch keine große Überraschung sein sollte. Daneben läuft aber auch einiges an italienischer Musik, und das hat einen ganz persönlichen Grund: Ich bin ein ziemlich großer Italien-Fan, und wenn ich schon meinen eigenen Sender baue, darf da auch meine eigene Vorliebe mit reinspielen. Die Auswahl der Titel läuft nicht komplett zufällig, sondern mit Rotation, damit dieselben Songs nicht ständig kurz hintereinander laufen. Und weil die Frage sicher kommt: Urheber im Manifest bin ich selbst mit meinem Namen, nicht das Suno-Pseudonym, unter dem die Tracks entstanden sind.
Kennzeichnung nach KI-Verordnung
Seit 2. August 2026 ist Artikel 50 der KI-Verordnung anwendbar, worüber ich damals ausführlich geschrieben habe. Ohne menschliches Freigabe-Gate entfällt für mich die Ausnahme für redaktionelle Kontrolle, es bleibt also bei der vollen Offenlegungspflicht, und das ist auch gut so. Ich habe die Kennzeichnung an drei Stellen fest eingebaut: als gesprochener Hinweis mindestens alle 15 Minuten im laufenden Programm, als dauerhaft sichtbares Feld im Player, und im einbettbaren Widget, wo sie sich nicht abschalten lässt. Der Text kommt direkt aus dem Sendungsmanifest und wandert bei jeder Einbettung automatisch mit. Eine eigene Prüfroutine misst laufend die größte Lücke zwischen zwei Kennzeichnungen, auch über den Übergang zwischen zwei Sendeschleifen hinweg. Das ist kein Nice-to-have, sondern für mich die Voraussetzung dafür, dass ich das Projekt überhaupt öffentlich betreiben kann.
Was passiert, wenn etwas kaputtgeht?
Von jedem Segment entsteht automatisch eine zeitlose Zweitfassung ohne Datum und Tageszeitangabe. Läuft das aktuelle Sendungsmanifest ab, schaltet der Player von selbst auf diese Ausweichversion um, die selbst kein Ablaufdatum trägt. Der Sender merkt seinen eigenen Ausfall also, ohne dass ich einen separaten Monitoring-Dienst betreiben müsste. Zusätzlich prüft eine Automatisierung alle sechs Stunden von außen über eine reguläre Web-Anfrage, ob die Sendung tatsächlich ausgeliefert wird. Das ist wichtig, weil ein fehlgeschlagener Upload sonst niemandem auffallen würde, der Worker selbst merkt das nämlich nicht.
Player und Widget: eine eigene kleine Design-Entscheidung
Der Player trägt bewusst dieselbe Optik wie der Blog, Amber als Akzentfarbe auf dunklem Grund, dieselben Schriften. Selbst gehostet, keine externen Schriftserver, aus DSGVO-Gründen, aber auch, weil ich Kontrolle über jedes einzelne Byte auf der Seite haben will, das an Besucher ausgeliefert wird. Für die beiden Sendungsarten habe ich mir bewusst gegen Fotos entschieden und stattdessen zwei einfache eingebettete Illustrationen gebaut, ein Mikrofon für Wortbeiträge, Notenlinien für Musik. Der kleine Equalizer im Player läuft ohne die Web Audio API, weil ein Analyser direkt in den Audiograph eingreift und im schlechtesten Fall die Wiedergabe stottern lässt. Für eine Optik, die nur schön aussehen soll, ist mir das Risiko schlicht zu hoch.
Das eigentliche Einbett-Widget ist mittlerweile mein liebstes Detail an dem ganzen Projekt. Es sitzt seit kurzem in der Sidebar jedes einzelnen Blogartikels auf digitalhandwerk.rocks, technisch als eigenes Custom Element im Shadow DOM, damit das WordPress-Theme der Seite ihm nicht ungefragt eigene Stile überstülpt. Bei schmalen Sidebar-Breiten zeigt das Widget bei Wortbeiträgen bewusst zuerst den Verweis zum jeweiligen Artikel und erst danach die verbleibende Sendezeit, damit bei wenig Platz der Link stehen bleibt und die Uhr verschwindet, nicht umgekehrt. Technisch war das eine kleine Herausforderung, weil das Widget zwar auf digitalhandwerk.rocks liegt, seine Daten aber von der eigenen Sender-Adresse holt. Ein einzelner fest eingetragener Zugriffsrechte-Header hätte nur die nackte Domain abgedeckt, eine Einbettung über die www-Variante wäre schlicht leer geblieben. Jetzt prüft die Serverkonfiguration den anfragenden Ursprung bei jeder Anfrage neu und spiegelt ihn zurück, wenn er zur erlaubten Liste gehört.
Wo das Projekt gerade steht
Der Worker läuft produktiv, Player und Widget sind live und in der Sidebar jedes Blogartikels eingebunden, alle 59 Musiktitel sind importiert und normalisiert, und die Automatisierungen für Zeitsteuerung und Überwachung sind gebaut und getestet. Was noch fehlt, bevor der Sender wirklich ganz allein läuft, ohne dass ich noch irgendwo manuell nachschauen muss: Die beiden Automatisierungs-Workflows müssen noch scharf geschaltet werden, aktuell starte ich die nächtliche Produktion und die Watchdog-Prüfung noch von Hand. Später will ich noch ein durchsuchbares Sendungsarchiv anbinden, dazu ein flüssiges Vorladen zwischen den Musiktiteln, damit auch bei einem langsamen Netz keine Lücke im Programm hörbar wird. Beides eilt nicht, die Beta läuft stabil genug, dass ich mir diesen Luxus leisten kann, in Ruhe zu priorisieren statt unter Druck zu reagieren.
Ich baue an diesem System weiter, in kleinen Schritten und mit der gleichen Regel, die ich bei jedem KI-Projekt anwende: erst verstehen, wo es kippt, dann automatisieren. Wer selbst mit einem ähnlichen Setup liebäugelt, sollte sich vor allem eine Frage stellen: Was in der eigenen Pipeline lässt sich deterministisch lösen, und was landet aus Bequemlichkeit im Modell, obwohl es dort nicht hingehört?
Testet mit, meldet was hakt
Die Beta läuft, aber Beta heißt Beta. Wenn dir eine falsch ausgesprochene Zahl auffällt, ein Musiktitel doppelt läuft oder das Widget in der Sidebar zickt, will ich das wissen. Über Fehler freue ich mich ehrlich gesagt nicht, aber genau diese Rückmeldungen sind es, die das System besser machen, ich kann nicht jede Ecke selbst ständig mithören. Meldet euch einfach über die Kontaktseite, am besten mit Uhrzeit und einer kurzen Beschreibung, was ihr gehört habt.
