Ein Radiosender, der seit 82 Tagen ununterbrochen läuft, in dem aber niemand im Studio sitzt. Kein Moderator vor dem Mikro, keine Redaktion, die den Sendeplan zusammenstellt. SARC-FM hat in dieser Zeit 7.368 Wortbeiträge gesendet, dazu 1.564 zusätzlich produzierte Konserven. Macht in Summe rund 90 gesprochene Beiträge pro Tag, jeden Tag, ohne dass jemand den Rechner anfasst.
Ich beobachte seit Monaten, wie viele meiner EPU- und KMU-Kunden KI für einzelne Aufgaben einsetzen, aber fast nie für einen kompletten, unbeaufsichtigten Betrieb. SARC-FM zeigt, wie weit das inzwischen geht: Von der Themenrecherche bis zur Sendeausspielung läuft dort alles ohne einen einzigen Handgriff. In diesem Artikel zeige ich dir den technischen Aufbau, die aus meiner Sicht cleverste Entscheidung im ganzen System, und warum ausgerechnet die Fehlerbehandlung mehr Arbeit gemacht hat als der eigentliche Sendebetrieb. Schauen wir uns zuerst an, was SARC-FM überhaupt ist.
Was ist SARC-FM eigentlich?
SARC-FM ist ein öffentlich empfangbarer Radiosender unter sarc-fm.net, auf dem zwei KI-Hosts über tagesaktuelle KI-Nachrichten sprechen. Entwickelt hat den Sender Arno Selhorst, und die Fakten in diesem Artikel stammen direkt von ihm. Text, Stimme, Musikauswahl und Sendeplan entstehen ohne Mensch im Ablauf, und das seit dem 8. Juni 2026 im Dauerbetrieb, nicht als Demo auf Knopfdruck. Ein vollautomatischer Radiosender ohne Menschen im Sendeablauf ist technisch machbar, das zeigt SARC-FM eindrücklich.
Die Entwicklungszeit lag bei rund 90 Tagen und 234 Commits. Der Code umfasst rund 20.100 Zeilen Backend in 43 Modulen und rund 30.000 Zeilen Frontend in 31 Komponenten, gebaut mit React 19, TypeScript, Vite 6 und Tailwind auf der Frontend-Seite, mit Node.js im ESM-Format auf der Backend-Seite, bewusst ohne zusätzliches Framework. Das ist eh der Punkt, an dem viele KI-Demos aufhören und echte Systeme erst anfangen: Ein Prototyp, der einmal funktioniert, ist etwas anderes als ein Sender, der 82 Tage am Stück durchhält.
Wie ist der Sender technisch aufgebaut?
Vier Schichten stecken hinter SARC-FM, und jede davon löst ein eigenes Problem.
Themenzufuhr. Ein eigener News-Radar sammelt laufend KI-Meldungen und legt sie als durchsuchbaren Bestand ab, 21.623 Artikel seit Mai 2026, davon 11.057 allein im August. Die Station zieht daraus bewusst ein Zeitfenster der jeweils frischesten Artikel, keine feste Stückzahl, weil der Durchsatz stark schwankt: im Mai rund 155 Artikel pro Tag, im August schon rund 395.
Textproduktion. Eine vierstufige Modell-Kaskade schreibt die Dialoge der beiden Hosts. Fällt eine Stufe aus, übernimmt automatisch die nächste, fallen alle aus, greift ein deterministischer Notbetrieb. Die Station verstummt dadurch nie wegen eines einzelnen API-Ausfalls. Wie sich ein bewusster Modellwechsel mitten in einer Aufgabe von einer automatischen Fallback-Kaskade unterscheidet, hab ich in einem separaten Artikel durchgerechnet: Bei SARC-FM entscheidet nicht ein Mensch, welches Modell gerade dran ist, sondern allein die Verfügbarkeit.
Stimme. Zwei TTS-Engines laufen in Reihe, primär mit geklonten Stimmen, damit jeder Host in jedem Format gleich klingt. Fällt die erste Engine aus, übernimmt die zweite automatisch. Diese Redundanz ist bei einem Sender mit festen Host-Identitäten kein Luxus, sondern Voraussetzung: Ein Host, der plötzlich anders klingt, fällt jedem Stammhörer sofort auf, egal ob der Wechsel technisch begründet ist oder nicht.
Ausspielung. Fünf Wege führen zur selben Sendung: eine Hörerseite, eine Direktstart-Variante, ein iframe-Embed für fremde Seiten, eine einbettbare Web-Component und eine PWA fürs Handy. Dazu kommt eine zweite PWA als Fernsteuerung für den Betreiber.
Warum SARC-FM ohne eigenen Streaming-Server auskommt
Das ist für mich die technisch interessanteste Entscheidung im ganzen Projekt: Es gibt keinen Streaming-Server. Kein Icecast, kein Shoutcast, keine Transcoding-Instanz, keine laufenden Serverkosten pro Hörer.
Stattdessen liegt auf einem gewöhnlichen statischen Webspace eine Manifest-Datei, verankert an die Wanduhr: Startzeitpunkt plus Titelliste mit Längen. Jeder Browser rechnet daraus selbst aus, welcher Titel gerade an welcher Sekunde läuft, und springt dort hinein. Alle Hörer sind synchron, weil alle dieselbe Uhr lesen, nicht weil ein Server sie synchronisiert. Das macht Sinn, sobald man es einmal durchdacht hat, aber ich hab es beim ersten Lesen der Unterlagen zweimal lesen müssen, bis der Groschen gefallen ist.
Die Folge: Die Station skaliert wie eine statische Webseite. Der einzige Rechner, der wirklich arbeitet, ist der Studio-PC, der produziert und die Dateien per FTPS hochlädt.
Was passiert, wenn der Studio-Rechner ausfällt?
Genau hier wird es spannend, weil SARC-FM den eigenen Ausfall selbst bemerkt. Ist der Studio-PC aus, erkennen das die Hörerseiten an einem Zeitstempel und schalten selbsttätig auf den Konserven-Kanal um, 809 vorproduzierte Beiträge, passend zum jeweiligen Sendeblock ausgewählt. Der Sender bleibt on air, auch wenn das Studio dunkel ist.
Passend dazu produziert die Station im Hintergrund von jedem gesendeten Beitrag eine zeitlose Zweitfassung, ohne Tageszeit-Gruß, ohne Bezug auf aktuelle Ereignisse. Nur diese Zweitfassungen wandern in den Vorrat. So altert die Konserve nicht, und ein Hörer merkt im November nicht, dass der Beitrag eigentlich im Juli entstanden ist.
Der eigentliche Aufwand: Wenn eine Maschine merkt, dass sie Unsinn sendet
Der Sendebetrieb selbst ist der kleinere Teil der Arbeit. Der größere ist die Frage, woran eine unbeaufsichtigte Maschine überhaupt merkt, dass sie Unsinn sendet. Drei Beispiele aus der Praxis, alle real aufgetreten und behoben: Eine zwölfteilige Podcast-Folge bestand am Ende aus zwölf unabhängigen Beiträgen zu zwölf verschiedenen Themen, weil die Folgenklammer lautlos verlorengegangen war. Ein einziger beschädigter Musik-Upload fror die Sendung rund zwölf Stunden ein. Und ein Sendeblock ganz ohne Wortbeiträge ließ die Station den eingeschalteten Rechner für ausgeschaltet halten und auf Konserve umschalten, obwohl gar nichts kaputt war.
Deshalb gibt es inzwischen 34 Regressionsläufe, die genau solche Vertragsbrüche im Betrieb abfangen sollen, dazu einen Aufsichtsprozess, der die Station nach einem Absturz binnen Sekunden selbst wieder auf Sendung bringt. Keiner dieser drei Fälle war beim ersten Testlauf vorhersehbar, das ist der eigentliche Punkt. Man findet solche Lücken nicht am Schreibtisch, sondern erst, wenn ein System wochenlang unbeaufsichtigt läuft und irgendwann genau die Kombination aus Umständen auftritt, an die vorher niemand gedacht hat. Ein Grundprinzip aus dem autonomen Monitoring eigener Automatisierungen gilt hier genauso: Der Wächter sollte außerhalb des Systems stehen, das er beobachtet, sonst merkt ein System den eigenen Totalausfall nicht.
Ist die Sendung wirklich nur Einbahnstraße?
Nein, und das hat mich beim Lesen der Unterlagen des Entwicklers am meisten überrascht. Hörer können abstimmen, reagieren, eine Stimmung angeben und Themen vorschlagen, und die beiden Hosts greifen das in der laufenden Sendung tatsächlich auf. Alles anonym, ohne Konto, ohne personenbezogene Daten, IP-Adressen werden verworfen. Das klingt nach einer Kleinigkeit, ist aus meiner Sicht aber der Unterschied zwischen einem automatisierten Loop und einer Sendung, die sich wie Radio anfühlt. Ein Sender, der nur abspult, ist ein Player mit Umweg. Ein Sender, der auf Publikumsreaktionen eingeht, ist etwas anderes, auch wenn kein Mensch dabei zuhört, wer da gerade abstimmt.
Dazu kommt die Musikseite, die im ganzen Projekt fast unterschätzt wird. 1.032 Titel mit 66,2 Stunden Spielzeit, kuratiert in 78 Playlists, sorgen dafür, dass zwischen den Wortbeiträgen nicht dieselben zwanzig Songs im Kreis laufen. Wer schon einmal versucht hat, eine Musikbibliothek in dieser Größe manuell zu pflegen, weiß, dass allein diese Fleißarbeit ohne KI-Unterstützung Wochen gefressen hätte.
Kurz erklärt
Modell-Kaskade: Eine Reihenfolge mehrerer KI-Modelle, bei der jede Stufe einspringt, wenn die vorherige nicht verfügbar ist. Anders als beim bewussten Modellwechsel für eine Aufgabe geht es hier um automatische Ausfallsicherheit, nicht um Kostenoptimierung.
Manifest-basierte Synchronisation: Statt eines Servers, der laufend Daten an alle Hörer verteilt, liest jeder Browser eine kleine Textdatei mit Startzeitpunkt und Titelliste und berechnet selbst, an welcher Stelle im Programm gerade gesendet wird. Das reduziert die gesamte Streaming-Infrastruktur auf gewöhnliches Webhosting.
Was du aus SARC-FM für ein eigenes Projekt mitnehmen kannst
Wer selbst mit dem Gedanken an ein automatisiertes Audio- oder Content-Projekt spielt, wird bei der Lektüre dieser Zahlen vermutlich an der falschen Stelle ansetzen. Die naheliegende Frage lautet meistens: Welche KI-Musik, welche Stimme, welches Modell? Die Fakten hinter SARC-FM zeigen etwas anderes. Der wirkliche Aufwand liegt nicht bei Musikauswahl oder Stimme, sondern bei den Fällen, in denen ein System glaubt, alles laufe normal, während es in Wahrheit Unsinn produziert. Genau diese Fehlerklasse lässt sich vorab kaum vollständig durchdenken. Sie zeigt sich erst im Betrieb, Tag für Tag, bis ein System genug echte Ausfälle gesehen hat, um sie zuverlässig zu erkennen.
Eine Sache will ich dabei nicht unerwähnt lassen, weil sie in meiner Beratungsarbeit ständig zu kurz kommt: Wer synthetische Audioinhalte im Dauerbetrieb sendet, bewegt sich seit August 2026 im Geltungsbereich der Transparenzpflichten aus Artikel 50 des EU AI Acts für synthetische Inhalte. Ob und in welchem Umfang ein automatisierter KI-Radiosender kennzeichnungspflichtig ist, hängt stark von der konkreten Ausgestaltung ab, aber wer so ein Projekt plant, sollte diese Frage von Anfang an mitdenken und nicht erst, wenn der Sender schon läuft.
Fragen zu SARC-FM
Der Sender selbst
Alles oben Beschriebene lässt sich am besten live nachvollziehen. SARC-FM sendet rund um die Uhr unter sarc-fm.net, inklusive der Möglichkeit, live abzustimmen, eine Stimmung anzugeben oder ein Thema vorzuschlagen, das die Hosts in der laufenden Sendung aufgreifen. Alles anonym, ohne Konto, ohne personenbezogene Daten.
