n8n, Make oder eigene Symfony-Integration: Wann Middleware bei KI-Automatisierung reicht

Inhalt

1. Ausgangslage: Welche Entscheidung ansteht
2. Drei Optionen im wirtschaftlichen Vergleich
3. Entscheidungskriterien: Woran Sie die richtige Option erkennen
4. Der AI Act als zusätzlicher Prüfpunkt
5. Was jetzt sinnvoll ist

Ein KI-Workflow in n8n ist an einem Nachmittag gebaut. Er liest neue Anfragen aus dem Postfach, lässt sie von einem Sprachmodell zusammenfassen und legt das Ergebnis im Ticketsystem ab. Das funktioniert, die Fachabteilung ist zufrieden und niemand hat dafür ein Entwicklerticket geschrieben. Verständlich, dass der nächste Gedanke lautet: Warum nicht auch die Produktbeschreibungen im Shop so erzeugen, oder die Übersetzungen im Kundenportal?

An dieser Stelle lohnt ein Schritt zurück. Die Frage ist selten, ob Middleware technisch kann, was Sie brauchen. Meistens kann sie es. Die Frage ist, wer den Ablauf verantwortet, wenn er Kunden erreicht, wenn er personenbezogene Daten verarbeitet oder wenn er nachts um drei ausfällt. Dieser Artikel ordnet ein, wann Middleware reicht und wann die Integration in den eigenen Code die bessere Investition ist.

Ausgangslage: Welche Entscheidung ansteht

Die meisten Teams stehen nicht vor einer Grundsatzentscheidung, sondern vor einer konkreten Funktion. Ein Shop soll Produkttexte vorschlagen. Ein Portal soll Inhalte automatisch übersetzen. Ein internes Tool soll Supportanfragen klassifizieren. Für jede dieser Funktionen gibt es zwei Wege: Der KI-Aufruf läuft über eine externe Automatisierungsplattform oder er liegt im Code der Anwendung, bei Symfony-Projekten etwa als Service mit Symfony AI oder einem direkten API-Client.

Beide Wege nutzen am Ende dasselbe Sprachmodell. Der Unterschied liegt darin, wo die Logik lebt. Bei Middleware liegt sie in einem grafischen Workflow außerhalb Ihres Repositorys. Bei der eigenen Integration liegt sie im Code, mit Tests, Versionierung und Deployment wie der Rest der Anwendung. Das wirkt auf den ersten Blick wie eine reine Geschmacksfrage. In der Praxis entscheidet es darüber, wer Fehler bemerkt, wer sie behebt und wer erklären kann, warum ein bestimmter Text beim Kunden gelandet ist.

Drei Optionen im wirtschaftlichen Vergleich

Option 1: Middleware als Cloud-Dienst (Make, Zapier, n8n Cloud)

Der schnellste Start. Die Plattform übernimmt Hosting, Updates und die Anbindung an viele gängige Dienste. Eine Fachabteilung kann einfache Abläufe selbst bauen und anpassen.

Die Kehrseite: Die Daten laufen über einen weiteren Anbieter. Das bedeutet einen zusätzlichen Auftragsverarbeitungsvertrag und eine weitere Stelle, an der Sie Speicherort und Aufbewahrung prüfen müssen. Die Kosten steigen mit der Anzahl der Ausführungen, was bei wachsendem Volumen schwer vorherzusagen ist. Und die Logik liegt außerhalb Ihrer Versionskontrolle. Wer einen Workflow ändert, ändert ihn sofort und ohne Review.

Wirtschaftlich passend für interne Abläufe mit überschaubarem Volumen, bei denen ein Ausfall ärgerlich, aber nicht teuer ist.

Option 2: n8n selbst gehostet

Self-Hosting holt die Daten zurück in die eigene Infrastruktur. Die laufenden Kosten hängen nicht mehr an der Zahl der Ausführungen. Dafür übernehmen Sie Betrieb, Updates, Backups und Überwachung einer weiteren Anwendung.

Dazu kommt die Lizenz. n8n steht unter der Sustainable Use License. Sie erlaubt Nutzung und Änderung für eigene interne Geschäftszwecke sowie für nicht-kommerzielle oder private Zwecke. Laut FAQ von n8n ist der Einsatz als Backend-Verarbeitung im eigenen Produkt erlaubt, solange nur Ihr eigenes Backend mit n8n kommuniziert. Endnutzer dürfen die n8n-Oberfläche weder nutzen noch Workflows konfigurieren. Sobald Ihre Kunden Automatisierungen selbst zusammenstellen sollen, verlassen Sie diesen Rahmen. Diese Grenze sollten Sie vor dem Projektstart mit einer Rechtsberatung klären, nicht danach.

Wirtschaftlich passend für Teams mit eigenem Betrieb, die viele interne Abläufe automatisieren und Daten nicht an weitere Cloud-Anbieter geben wollen.

Option 3: Integration im eigenen Symfony-Code

Der KI-Aufruf wird ein Service wie jeder andere. Er durchläuft Code-Review, Tests und Deployment. Fehlerbehandlung, Wiederholungsversuche und Protokollierung folgen denselben Regeln wie der Rest der Anwendung. Ein kurzes Beispiel zeigt, warum das für geschäftskritische Abläufe den Unterschied macht:

// Übersetzung läuft asynchron über Symfony Messenger.
// Schlägt der KI-Aufruf fehl, greift die konfigurierte Retry-Strategie.
// Nach dem letzten Versuch landet die Nachricht in der Failure-Queue
// und ist dort für das Team sichtbar, statt still zu verschwinden.
#[AsMessageHandler]
final class TranslateContentHandler
{
    public function __construct(
        private TranslatorClient $ai,
        private ContentRepository $contents,
    ) {}

    public function __invoke(TranslateContent $message): void
    {
        $content = $this->contents->get($message->contentId);

        $translation = $this->ai->translate($content->text(), $message->locale);

        // Ergebnis wird als Entwurf gespeichert und als KI-generiert markiert.
        // Die Freigabe erfolgt redaktionell, nicht automatisch.
        $content->addDraftTranslation($message->locale, $translation, aiGenerated: true);
        $this->contents->save($content);
    }
}

Der Code selbst ist unspektakulär. Entscheidend sind zwei Dinge, die in einem grafischen Workflow schwerer abzubilden sind: Fehlgeschlagene Aufträge gehen nicht verloren. Und die Kennzeichnung als KI-Ausgabe hängt direkt am Datensatz, nicht an einem separaten Schritt, den jemand vergessen kann.

Die Kosten liegen am Anfang. Die erste Funktion braucht Entwicklungszeit, Tests und eine saubere Schnittstelle. Jede weitere Funktion nutzt diese Basis mit. Wer sich mit dem Aufwand solcher Vorhaben beschäftigt, findet in den Kosten für PHP-Freelancer eine Einordnung der Beauftragungsmodelle.

Wirtschaftlich passend für Funktionen, die Kunden sehen, die regelmäßig große Mengen verarbeiten oder bei denen ein Fehler direkt Umsatz oder Vertrauen kostet.

Entscheidungskriterien: Woran Sie die richtige Option erkennen

In der Beratung haben sich vier Fragen bewährt. Sie lassen sich ohne technisches Detailwissen beantworten und führen meist zu einer klaren Richtung.

Sieht der Kunde das Ergebnis?

Interne Zusammenfassungen, Klassifizierungen oder Entwürfe für das eigene Team vertragen kleine Fehler. Ein Mitarbeiter liest gegen und korrigiert. Produkttexte im Shop, Übersetzungen im Portal oder automatische Antworten an Kunden vertragen sie deutlich schlechter. Je direkter die KI-Ausgabe beim Kunden ankommt, desto mehr spricht für die Integration im eigenen Code.

Fließen personenbezogene Daten durch den Ablauf?

Jede zusätzliche Plattform im Datenfluss ist eine weitere Stelle für Verträge, Löschkonzepte und Prüfungen. Bei Self-Hosting bleibt das überschaubar. Bei Cloud-Middleware kommt ein weiterer Dienstleister dazu, zusätzlich zum Anbieter des Sprachmodells. Wenn Kundendaten, Bestellungen oder Supportverläufe verarbeitet werden, lohnt sich ein kurzer Datenflussplan, bevor Sie sich festlegen.

Was kostet ein Ausfall?

Stellen Sie sich vor, der Ablauf steht einen Tag still und niemand merkt es. Ist das ärgerlich oder geschäftskritisch? Middleware zeigt Fehler in der Regel in ihrer eigenen Oberfläche an. Ob das Ihr Team rechtzeitig erreicht, hängt davon ab, wer dort regelmäßig hineinschaut. Im eigenen Code laufen Fehler in dasselbe Monitoring wie alle anderen Fehler der Anwendung.

Wer pflegt den Ablauf in einem Jahr?

Ein Workflow, den eine Person aus der Fachabteilung gebaut hat, ist so lange wartbar, wie diese Person verfügbar ist. Das ist dieselbe Frage wie bei jeder Eigenentwicklung, nur weniger sichtbar. Der Artikel zum Bus-Faktor bei Eigenentwicklungen beschreibt, worauf es dabei ankommt. Liegt die Logik im Code, gelten Dokumentation und Review automatisch mit.

Wenn Sie zwei oder mehr dieser Fragen mit „ja“ oder „teuer“ beantworten, ist die Integration im eigenen Code meist die bessere Wahl. Bei keiner oder einer Frage ist Middleware ein guter, schneller Weg. Viele Teams fahren auch beide Wege parallel: interne Helfer in n8n, kundennahe Funktionen in der Anwendung.

Der AI Act als zusätzlicher Prüfpunkt

Art. 50 AI Act regelt Transparenzpflichten für bestimmte KI-Ausgaben. Für Systeme, die bereits vor Geltung der Regeln in Betrieb waren, läuft die Übergangsfrist nach aktuellem Stand am 02.12.2026 aus. Welche Ihrer Funktionen konkret betroffen sind, ist eine rechtliche Bewertung im Einzelfall.

Technisch lässt sich daraus eine einfache Regel ableiten. Eine Kennzeichnung ist dort am verlässlichsten, wo die KI-Ausgabe entsteht und an den Nutzer weitergegeben wird. Liegt dieser Weg in Ihrer Anwendung, können Sie die Kennzeichnung am Datensatz festhalten und im Frontend zuverlässig ausgeben. Läuft die Erzeugung in einer Middleware und das Ergebnis wird per Schnittstelle in Ihr System geschrieben, müssen beide Seiten zusammenspielen. Das ist machbar, aber eine zusätzliche Stelle, an der etwas verloren gehen kann.

Für bestehende Workflows heißt das nicht, alles umzubauen. Es heißt, vor Dezember einmal durchzugehen, welche Abläufe KI-Ausgaben an Kunden liefern und wie dort die Kennzeichnung entsteht.

Was jetzt sinnvoll ist

Middleware ist ein gutes Werkzeug für interne Abläufe und für schnelle Versuche. Sie hilft, herauszufinden, ob eine KI-Funktion im Alltag überhaupt trägt. Wenn ein Workflow sich bewährt hat und Richtung Kunde wandert, ist er die beste Spezifikation, die Sie für eine Umsetzung im eigenen Code bekommen können: Prompts, Datenzuordnung und Sonderfälle sind dann schon erprobt. Der Wechsel ist kein Scheitern der Middleware, sondern der nächste Schritt. Wer bei der Umsetzung Unterstützung sucht, findet auf der Seite zum Symfony-Entwickler für Integrationen den Einstieg.

Wer heute eine Liste seiner KI-Workflows anlegt und jeden mit den vier Fragen oben durchgeht, hat bis Dezember eine klare Aufteilung. Den Rest erledigt man dann Workflow für Workflow.