KI-Pipeline für Social Media
Eine Pipeline, die den täglichen Post einer Marke entwirft und ihn nach Freigabe auf allen Kanälen veröffentlicht.
- seit 2025
- live
- Architekt & Umsetzer
- Python, n8n, OpenAI, Gemini, Notion API, Meta Graph API
Das Problem
Den Social-Media-Kanal einer Marke am Leben zu halten ist tägliche Kleinarbeit, und sie bleibt an der Geschäftsleitung hängen. Jemand muss ein brauchbares Bild finden und beurteilen, ob es überhaupt gut genug zum Posten ist, den Text dazu schreiben, Titel, Hashtags und Emojis setzen und das Ganze am Ende auf jeder Plattform einzeln veröffentlichen.
Lässt man ein paar Tage aus, schläft der Account ein; macht man es ordentlich, kostet es genau die Zeit, die ohnehin fehlt.
Die Lösung
Ein Zeitplan stößt jeden Tag einen Post an. Ein Textmodell schreibt den Entwurf, ein zweites Modell prüft ihn gegen schriftlich festgelegte Markenregeln, und ein Bildmodell erzeugt das Visual. Danach wartet der Entwurf in einer Freigabeliste in Notion, und erst wenn ein Mensch freigibt, veröffentlicht ein separater Prozess auf Instagram, Facebook und Google Business Profile.
- Bild, Text, Hashtags, Posten: alles von Hand
- wird entworfen, ein Mensch gibt frei
3 Plattformen
seit 2025
Das Ergebnis
Im täglichen Einsatz ist die Pipeline seit 2025, und ihr eigentlicher Wert liegt darin, dass die tägliche Produktionslast weg ist: Bild beschaffen, Text schreiben, Titel und Hashtags ausdenken, auf jeder Plattform posten. Der Kanal veröffentlicht seitdem verlässlich, ohne dass jemand dafür die Zeit finden muss, die er nicht hat.
Im selben Zeitraum wuchs der Account von rund 350 auf rund 1.200 Follower. Das ist ein Signal aus dem Zeitraum, in dem die Pipeline lief, kein kontrolliertes Ergebnis, und es ist nicht die Kernaussage.
Die Technik dahinter
Die Architektur
Die Pipeline läuft mit n8n orchestriert auf einem selbst gehosteten Server, und die Workflows zum Veröffentlichen entstehen aus Python, damit sie versioniert und aus dem Quellcode reproduzierbar sind, statt in einer Oberfläche zusammengeklickt zu werden.
Der tägliche Lauf wechselt den Posttyp durch, sodass derselbe Typ nie an zwei Tagen hintereinander erscheint. Die Veröffentlichungszeit stammt aus einem Jitter, der aus dem Datum abgeleitet wird: Wer denselben Tag erneut laufen lässt, bekommt denselben Zeitplan und keinen neuen Zufall.
Ein Textmodell schreibt den Entwurf, und ein zweites prüft ihn als Kritiker gegen ausformulierte Markenregeln, wobei es ihn bei Beanstandungen genau einmal zur Überarbeitung zurückschickt. Wo der Posttyp ein Bild verlangt, erzeugt ein Bildmodell es; andere Typen arbeiten stattdessen mit einem Foto-Briefing für einen Menschen.
Der fertige Entwurf landet in einer Freigabeliste in Notion, wo ihn ein Mensch abzeichnet, alternativ über einen Telegram-Bot. Erst danach veröffentlicht ein separater Prozess, der die Liste alle zehn Minuten abfragt, auf Instagram (Feed und Reels), Facebook und Google Business Profile.
Ein Kritiker ist eine andere Rolle und nicht dieselbe Frage ein zweites Mal. Und der Generator hat nie die Zugangsdaten zum Veröffentlichen.
Ein Gedächtnis, das mitwächst. Jede Beanstandung des Kritikers wird vereinheitlicht, auf eine stabile ID gehasht, entdoppelt und gezählt, und die fünf jüngsten gehen beim nächsten Lauf in den Prompt des Textmodells. Weil der Prompt das Gedächtnis trägt, wiederholt das System dieselben Fehler nicht mehr, ganz ohne Nachtraining. Ein Eintrag lautet zum Beispiel, nie mit einer bestimmten Floskel zu eröffnen, viermal beanstandet.
Entscheidungen und Abwägungen
Der Generator drückt nie auf Veröffentlichen. Alles landet als Entwurf in der Freigabeliste, und der veröffentlichende Prozess nimmt nur, was ein Mensch abgezeichnet hat. Das ist die günstigste Versicherung, die ein Markensystem mit Sprachmodellen kaufen kann, und sie kostet nicht mehr als einen täglichen Handgriff, der das System zugleich ehrlich hält.
Die Workflows aus Python erzeugen. Sie sind damit vergleichbar und reproduzierbar, erkauft mit einem Build-Schritt zwischen Quellcode und laufendem Workflow. Genau dort saß der schlimmste Fehler.
Feste Zeitplanung statt Zufall. Weil die Post-Zeiten aus dem datumsabhängigen Jitter kommen, ist ein erneuter Lauf wiederholbar und nachvollziehbar, der Feed wirkt trotzdem menschlich getaktet, und nichts geht durch einen zweiten Lauf doppelt raus.
Was schiefging
Posts gingen doppelt raus, und zwar öffentlich. Der Generator vergab zwei Schritten denselben Node-Namen, und weil n8n seine Verbindungen über Namen adressiert, sammelte der erzeugte Graph doppelte Kanten an. Derselbe Post erschien zweimal auf Instagram und viermal auf Facebook und Google Business Profile, bevor es jemandem auffiel.
Die Lösung war strukturell: eindeutige Namen, eine Prüfung der Graph-Struktur zur Build-Zeit, eine Trockenlauf-Variante des Workflows und eine echte Testsuite. Aus „sieht in der Oberfläche richtig aus" wurde „der Build schlägt fehl, wenn der Graph kaputt ist".
Der schärfere Prompt brachte das Modell zum Absturz. Nach dem Verschärfen des System-Prompts mit Verbotsliste und harten Regeln brach der erste Lauf mit einem Längenfehler ab. Ein langer, regelschwerer Prompt zusammen mit einem strikten JSON-Schema brachte das Modell dazu, sich an jeder Regel abzuarbeiten, bis es seine Ausgabegrenze von rund 16K erreichte, ohne das JSON je zu schließen. Die Ausgabe zu deckeln verschob die Klippe nur; geholfen hat erst, den Prompt selbst zu straffen.
Mehr Regeln machten die Ausgabe unzuverlässiger. Ab einem Punkt ist Prompt-Gewicht ein Kostenfaktor und kein Schutz.
Die Bilder auf die Plattformen zu bekommen war eine eigene Geschichte, denn die Schnittstellen der Netzwerke konnten die temporären Upload-Adressen nicht abrufen. Seitdem liegt jedes Bild vor dem Posten in einem eigenen öffentlichen Speicher bereit.
Ein ähnliches Problem im eigenen Betrieb?
Was ich für Unternehmen macheSie besetzen eine Rolle in angewandter KI oder Solutions-Architektur?
Der vollständige Werdegang