HYBRID SYSTEMS - KI bauen im DACH

n8n als souveräne AI-Automatisierungs-Plattform: Selbstgehostete AI-Agents & Workflows ohne Big-Tech-Abhängigkeit | AI Engineering DACH

Tim Reiz

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 18:22

🚀 In dieser neuen Folge von „AI Engineering DACH“ tauchen wir tief in n8n ein – die mächtigste Open-Source-Workflow-Automatisierungs-Plattform, die 2026 zur echten Alternative zu Zapier, Make und Co. für KI-Engineers in Deutschland, Österreich und der Schweiz geworden ist.

n8n läuft komplett selbstgehostet (Docker, on-prem oder bei Hetzner/IONOS), ist quelloffen und lässt dich echte AI-Agents bauen: mit Memory, Tools, Reasoning, Multi-Model-Support (OpenAI, Claude, Groq, Ollama, IBM watsonx & Co.) und dem neuen AI Workflow Builder, der aus natürlicher Sprache komplette Workflows generiert.

Themen der Folge:

  • Warum n8n perfekt zu Nextcloud, Ollama und deiner souveränen DSGVO-Infrastruktur passt
  • Praktische Beispiele: AI-gestützte Dokumentenverarbeitung aus Nextcloud, RAG-Pipelines, autonome Agents für Support, Lead-Gen oder interne Prozesse
  • AI Workflow Builder + Agent Builder – vom Prompt zum lauffähigen Workflow in Minuten
  • Self-Hosting vs. Cloud: volle Datensouveränität und Kostenkontrolle
  • Integrationen mit über 500 Tools + custom Code (JS/Python)

Perfekt für alle AI-Engineers und Tech-Leads, die keine Lust mehr auf teure Cloud-Automatisierungen und Datenabfluss haben und stattdessen ihre eigenen intelligenten Workflows souverän betreiben wollen.

📌 Folge #n8nAI
💬 Schreib in die Kommentare: Welchen AI-Workflow möchtest du als nächstes mit n8n bauen? Nutzt du n8n schon zusammen mit Nextcloud?

Abonniere den Kanal & aktiviere die Glocke für dein tägliches 10-Minuten-Update zu KI, AI Engineering und digitaler Souveränität in der DACH-Region!

#n8n #AI #KI #n8nAI #SelfHostedAI #AIWorkflow #AIAgents #Automation #DSGVO #Datensouveränität #Nextcloud #Ollama #AIEngineering #DACH #OpenSource #LocalAI #AIOrchestrierung

SPEAKER_01

Willkommen bei Hybrid Systems. Wir arbeiten mit dem Dachsystem. Und handeln.

SPEAKER_00

Liebe Zuhörer, heute ein neues Thema, eine neue Episode von Hybrid System. Heute wieder das Thema KI und Infrastruktur. Wir beschäftigen uns mit dem Thema NATN. Was ist das, Tim?

SPEAKER_01

Ja, hallo Klaus. NAN ist im Prinzip ein Automatisierungstool, wo ihr festgelegte Prozesse oder festgelegte Reihenfolgen im Prinzip hinterlegen könnt. Dadurch könnt ihr dann komplette Prozesse automatisieren, sie automatisch ablaufen lassen. Wichtig ist dabei immer, dass es immer wiederkehrende Prozesse sein sollten. Das heißt, es ist jetzt nicht vergleichbar mit einem Open Claw-Agent oder anderen Agenten, die wir so in der Vergangenheit genutzt haben, sondern rein dafür da, um wiederkehrende Aufgaben systematisch zu erledigen.

SPEAKER_00

Da wir heute einen besonderen Gast dabei haben, einen Experten zu NAN, würde ich gerne auch von Jasin nochmal einen kleinen Kommentar zu dem Thema bekommen, was NATN für ihn leisten kann. Jasin.

SPEAKER_02

Hallo erstmal an dieser Stelle. Ich bin Jasin und ich nutze NATN schon seit längerem. Vielleicht mal kurz als Introduction, wie ich auf NATN gekommen bin. Bei uns in der Firma haben wir ein bisschen den Fokus darauf gesetzt, eben gewisse Workflows zu automatisieren. Wir haben initial mit Microsoft 365 gearbeitet. Auch dem Power Automate, den Inbuild. Und was mir so ein bisschen aufgefallen ist, ist, dass man halt sehr limitiert war. Also wir hatten versucht, gewisse Workflows eben zu automatisieren. Und irgendwann kommst du halt an deine Grenzen. Und dann schaust du halt im Internet, was gibt's, was benutzen die anderen Leute. Und lustigerweise hatten wir einen Kollegen, der arbeitet bei uns, immer noch, der ist aus Argentinien und der hat einen Freund, der kannte mal jemanden. Also er ganz werde die Geschichte. Und der hat gesagt, hey, der kennt sich irgendwie mit solchen Sachen aus. Und dann dachte ich mir so, okay, das hört sich schon mal sehr skurril an. Aber okay. Dann hat er irgendwie die Nummer von dem Kollegen geklärt und dann hatten wir mal so ein Gespräch und der meinte, dass er relativ viel mit NEN arbeitet. Und ich hatte davon schon mal gehört, aber wie gesagt, also wir hatten eher auf Power Automate fokussiert gehabt zu dem Zeitpunkt. Und dann habe ich ihm mal gesagt, zeig mir mal, was das alles kann. Und dann hat er einen Satz gedroppt, der hat mich dann auf jeden Fall, ja, ich sag jetzt mal, überzeugt und er hat gesagt, du kannst auch deinen eigenen Code in JavaScript oder in Python mit rein implementieren. Wieso das für uns für mich immer wichtig ist, ist, meistens hast du halt immer das Problem, dass du gewisse, also wenn du jetzt von mehreren Plattformen zum Beispiel Daten ziehst, hast du oft öfters das Problem, Datenkompatibility, beziehungsweise Data Pre-Processing and der Sachen, sind halt meistens immer auf gut Englisch Pain in the S. And LEDN Lys ist relativ solide, indem du halt mehr oder weniger A einmal die Möglichkeit hast, die ganzen Automatisierungen wie bei Lego zusammenzubauen. Und dass du natürlich auch deine Code-Snippet da mit reinbringen kannst. Ein anderer Vorteil ist zum Beispiel, dass es relativ günstig ist. Also effektiv ist es eigentlich wie SEPI. Deutlich günstiger, viel mächtiger. Und wie gesagt, eben dieses Lego-Bausystem, das hat mich einfach überzeugt.

SPEAKER_00

Gut, Tim, vielleicht nochmal ein Thema dazu. Wie verwendest du NETN an der Stelle auf einem lokalen Rechner in einer Cloud-Version? Wie verwendest du das da?

SPEAKER_01

Ja, also das ist, glaube ich, so der größte Unterschied zwischen uns. Ich meine, der Jasin ist ja auch relativ international unterwegs. Ihr habt ja auch in Afrika einige Projekte und auch in den arabischen Ländern habt ihr ja Kunden und Projekte, die ihr bedienen müsst. Ich glaube, da ist auch das Thema Datenschutz, Grundverordnung, ich meine, wir haben ja schon oft drüber gesprochen, Jassin, ist ja nicht so euer Key-Thema wie jetzt bei uns oder wie bei mir und Klaus. Wir müssen da immer ein bisschen aufpassen, was für Lösungen wir implementieren, wie wir das Ganze umsetzen. Ich habe jetzt auch schon rausgehört, du nutzt ja das ganz normale NATN, was es online verfügbar, was es online verfügbar gibt. Ich tatsächlich nutze das wirklich immer auf einem Hetzner-Server. Das heißt, wir installieren dort NADN direkt auf unserem eigenen Server, um da auch den DSGVO-Norm zu entsprechen. Aber vom Prinzip her ist es das Gleiche, wobei ich glaube, beziehungsweise ich weiß, die Prozesse, die der Jassin baut, wo er auch wirklich tagelang daran gearbeitet wird, sind halt einfach um einiges komplexer und länger im Vergleich zu den Prozessen, die wir umsetzen. Also wir nutzen N8N als Tool, um Prozesse zu vereinfachen, zu automatisieren, aber lange nicht in dem Maßstab, wie es der Jasin macht.

SPEAKER_00

Jassin, kannst du uns vielleicht einen kleinen Einblick in ein Mini-Projekt an der Stelle sehen? Nicht direkt im Detail, sondern dass unsere Zuheurer ein bisschen verstehen, was ein komplexer Bereich, zum Beispiel im Bereich des Researches oder sowas, möglich macht mit NE.

SPEAKER_02

Ja, ich kann euch mal so unser letztes Projekt ein bisschen näher ranbringen. Was wir, also Tim hat es schon ein bisschen angedeutet, wir sind relativ international unterwegs. Datenschutzverordnung sind jetzt eher, ja, ich sag jetzt mal, zweitrangig. Natürlich für uns jetzt, da wir jetzt auch in Europa operieren, teilweise relativ wenig, aber da wir aus Europa rausgekommen sind, würde ich sagen, für uns ist das natürlich auch sehr wichtig. Die Eigenschaft, dass man selbst hosten kann, in den Zeiten, wo du halt auch relativ mit viel mit Agenten arbeitest, wie Open Clore Co., ist natürlich ein Feature, das ist halt unschlagbar. Was wir halt gebaut hatten, war, oder beziehungsweise was wir für eine Challenge hatten, war, wir haben halt immer wieder mal neue Projekte von unseren Kontakten, die halt mehr oder weniger Investoren suchen. Und die Investorsuche, es gibt natürlich gewisse Tools, wo du mehr oder weniger Investoren suchen kannst, auch Webpages, wo du halt Subscription hast, die, ich sage jetzt mal, relativ teuer sind und wo du halt schon irgendwo zum Ziel kommst, aber mir persönlich so ein bisschen die Individualisierung gefehlt hat. Was wir damals gemacht hatten, war ein bisschen mit Large Language Models, versuchen, Leads zu generieren, was relativ kompliziert war, weil du halt viele öffentliche Daten natürlich und viele der E-Mails, also wenn du zum Beispiel jetzt das CTO brauchst oder Head of Investments or Funds, deren E-Mails zum Beispiel nicht öffentlich zugänglich waren, da hatten wir uns überlegt, okay, wie können wir das, weil es war ein Task, der immer wieder, also der immer wieder bei uns auf dem Tisch lag. Und da hatten wir uns gefragt, okay, wie können wir das am besten automatisieren? Dann haben wir uns mal die überlegt, wie wir das am besten realisieren. Wir haben dann gesagt, hey, können wir das nicht mit Nedan bauen? Was wir dann gemacht haben, war eigentlich relativ cool. Wir haben mehr oder weniger eine Webpage gebaut, wo eigentlich nur die Leute Zugang haben, die bei uns in der Firma registriert sind, wo du dich einloggst, wo du sehen kannst, wen du schon kontaktiert hast und co. Und das ganze Backend läuft eigentlich über Nedan. Wie gesagt, also die Tatsache, dass du halt relativ viel wie Lego aufbauen kannst, ohne wirklich zu programmieren zu können, was ein Vorteil ist, wenn du mehrere Leute hast, die halt noch ein paar, ja, die auch an dem Projekt arbeiten und jetzt keine Programmierer sind oder für die das halt ein bisschen aussieht wie Mandarin, das ist ein relativ großer Vorteil. Was wir dann gemacht haben, war mehr oder weniger, wir haben dann mehrere Large Language Models zusammenkombiniert, Strategien ausgearbeitet, die eben über NADN laufen. Personalisierte E-Mails werden geschrieben, es werden Metriken erstellt. Was auch noch passiert, ist zum Beispiel, wir verwenden API-Calls, was auch relativ easy ist in NADN. Über gewisse Datenbanken, die jetzt zum Beispiel private E-Mails, Namen, Unternehmen kennen und haben da mehr oder weniger so ein Tool gebaut, das uns im Alltag relativ nicht nur relativ, sondern dass uns wirklich von Nutzen ist. Und ich denke, NATN kann bei sowas wirklich helfen, wenn du halt mit relativ wenig Zeitaufwand einen relativ komplexen Task zu erledigen hast.

SPEAKER_00

Jesin, vielleicht nochmal eine Frage dazu. Das heißt, warum benutzt du NATN für den Sachen und nicht reine Agents an der Stelle? Liegt es daran zum Beispiel, dass der Prozess immer wieder derselbe ist, dass er immer wieder gleich wie einen Prozess aufgebaut werden muss und im Gegensatz zu einem LLM oder Agent-System da keine Variationen dann möglich sind oder weswegen explizit NN an der Stelle?

SPEAKER_02

Also der Vorteil liegt eigentlich ein bisschen darin, dass du halt die Struktur vorgibst. Also wenn du jetzt zum Beispiel jetzt in dem speziellen Fall einen Investor suchst, dann hast du natürlich deine Metriken, die du im Anfang mehr oder weniger definierst, also welchen Sektor du hast, welchen Subsektor, Minimal Funds, Maximum Funds, welche Art von Investoren du suchst, Project Descriptions. All diese Metriken, da haben wir uns natürlich Gedanken gemacht, das sind mehrere Felder, die du halt mehr oder weniger ausfüllen kannst, beziehungsweise in dem Fall sogar dann auch mit einem Large Language Model generieren kannst, wenn du zum Beispiel einen Project Deck oder Project Summary einfügst. Wir haben natürlich an gewissen Stellen schon Large Language Model Connections drin. Unter anderem auch bei der Strategie, also wie der Workflow so mehr oder weniger abläuft, ist eigentlich, da gibt es die ganzen Metriken weiter und das Large Language Model schaut sich diese Metriken nebenan. Wir haben dann auch noch Gewichtungen, die wir jetzt momentan noch statisch gesetzt haben, die aber auch angepasst werden können. Also wir fahren momentan relativ gut damit. Und dann wird in mehr oder weniger eine Strategie ausgesucht oder beziehungsweise vom Large Language Model eben berechnet. Und dann wird eben dieser Workflow getriggert. Und an sich ist es ja immer wieder immer wieder der gleiche Task, bloß die Variablen ändern sich. Also die Gleichung mehr oder weniger ist immer die gleiche, plus die Parameter sind ein anderer.

SPEAKER_00

Wie unterscheidest du Jason? Hast du einen Testrechner, der in der Cloud ist, oder machst du NATN auf zwei verschiedenen Basen, dass du einmal ein Testsystem hast und einmal ein Produktivsystem oder wie gehst du mit dieser Programmierung um?

SPEAKER_02

Also wie wir das implementiert haben, war folgendes. Wir haben auf NATN, also wir benutzen hauptsächlich die Cloud-Version. Die Cloud-Version ist relativ handy, deswegen benutzen wir die momentan. Was man machen kann, ist, du kannst ja relativ viele Workflows machen. Du kannst auch Test-Workflows machen. Also zum Beispiel, der Workflow ist relativ lang, triggert auch relativ viele Actions. Was wir gemacht haben, ist, du kannst ihn auch zerschneiden, sage ich jetzt mal, in den Teil rausnehmen, dann in eine Testumgebung in der Cloud ausführen und schauen, was der Output ist. Wichtig war am Anfang natürlich erstmal, dass der ganze Output passt, dass die ganze Kompatibilität passt. Und dann natürlich musst du gewisse Testruns machen, auch in der Production Phase, dass du dann halt mehr oder weniger dann auch siehst, okay, ist das auch wirklich das, was du willst? Auch mit realen Daten.

SPEAKER_00

Das hört sich ziemlich spannend an, das Ganze. Kommen wir nochmal zu dir, Tim. Wie sieht genau diese Fragestellung, also testen und produktiv sein? Du arbeitest ja auf dem Hetzner-Server. Wie machst du das mit dem Testsystem an der Stelle?

SPEAKER_01

Ja, Klaus, das ist eine gute Frage. Also wir machen das grundsätzlich immer so. Bei jedem Projekt, beziehungsweise gerade bei Kundenprojekten und auch bei den wirklich großen Projekten, haben wir eigentlich alle Server doppelt, teilweise sogar dreifach. Das bedeutet, wir haben wirklich auch Testserver. Das bedeutet, im Umkehrschluss, wenn wir jetzt ein Projekt haben, für was wir tatsächlich sechs, sieben Server parallel brauchen fürs Monitoring, für diese ganzen Applikationen wie N8N, Nextcloud und so weiter, was alles dazugehört, dann gibt es noch Frontend, Backend, Landingpage und was auch je nach Projekt immer unterschiedlich ist, gibt es das Ganze einmal als Endprodukt bzw. als finalen Server und dann nochmal gespiegelt als Test-Server. Und da ist dann im Prinzip immer das, wo wir dann mit den jeweiligen Versionen arbeiten. Das heißt, wir testen, bis wir wirklich mal bei Version 1 sind, dass wir sagen können, okay, jetzt können wir in eine Beta-Phase gehen oder können in den Rollout gehen. Und parallel, weil die Projekte ja einfach wachsen, es kommen neue Funktionen dazu und so weiter, werden wir natürlich dann anfangen, auf den Test-Servern im Prinzip an Version 2 zu arbeiten, sobald Version 1 online ist. Und so gehen wir eigentlich immer vor, dass wir wirklich Erweiterungen bauen können, testen können, ohne jetzt wirklich unser laufendes Projekt, was vielleicht schon online ist, was schon deployed ist, zu beeinflussen.

SPEAKER_00

Vielleicht nochmal das Thema NDN-Prozesse. Wird diese Möglichkeit NRN in Zukunft noch weiter existieren müssen oder wird es ergänzt oder ersetzt werden durch Agent-Systeme? Vielleicht erstmal die Frage an dir.

SPEAKER_02

Also ich denke, on the long run wird es auf jeden Fall ersetzt werden durch Agent-Systeme, weil du ja auch gewisse Workflows mehr oder weniger vor konfigurieren kannst, eine gewisse Statik auch brauchst. Du kannst ja nicht immer alles von neu eben aufbauen. Wie wenn du jetzt zum Beispiel einfach einem LLM schreiben würdest, hey, ich baue mir meine Strategie, dann sieht das ja wieder ganz anders aus, wenn du jetzt einen Tag später nochmal die gleiche Frage stellst. Aber bis dahin denke ich, NLN wird auf jeden Fall oder sollte auf jeden Fall halt benutzt werden, weil du halt A einmal die Struktur vorgeben kannst, wo du sie brauchst, aber auch noch diese Möglichkeit hast, wirklich gewisse andere Tools mit zu integrieren. Also jetzt LLM oder irgendwelche anderen API-Cores. Und ich glaube, da ist eben der große Vorteil.

SPEAKER_00

Sehr gut. Die gleiche Frage nochmal an dich, Tim.

SPEAKER_01

Ja, ich habe da ein bisschen eine andere Meinung. Also ich habe halt einfach das Gefühl, dass diese ganzen wiederkehrenden Aufgaben, das dafür NET Aiden wirklich stark ist und wirklich gut ist. Und auch langfristig glaube ich, dass man komplexe Prozesse damit besser abbilden kann. Gerade wenn sie häufiger vorkommen, fährt man eigentlich besser, wenn man einen automatisierten Prozess hat. Und was auch noch ein ganz wichtiger Punkt ist, und das weiß ich auch einfach aufgrund der Arbeit mit den ganzen Agenten, wenn du jetzt wirklich einen sehr, sehr langen Prozess hast, dann hast du auch irgendwann dieses Timeout-Problem. Das heißt, dein Agent stoppt irgendwann. Du kannst nicht warten, bis irgendeine API-Schnittstelle dir eine Auswertung fertiggestellt hat, damit der Prozess weitergeht. Also ich glaube, da sind wir noch weit weg von. Deswegen denke ich auch, dass NETN wirklich noch lange, lange benutzt werden muss und auch eingerichtet werden muss, um gerade diese komplexen Prozesse abzubilden, die wirklich teilweise ja auch, wie das denn du kennst das, wirklich viel Zeit in Anspruch nehmen, wo es wirklich mal um Stunden auch gehen kann.

SPEAKER_02

Genau, genau, da gebe ich dir recht. Also bei uns zum Beispiel ist es auch so, also der Prozess, den ich vorher beschrieben habe, der geht auch über eine längere Zeit, weil du halt einfach relativ viele Sources hast, viele Webpages gescrapt werden, viele Datenbanken aufgerufen werden und das alles eben unter einen Hut zu bringen am Ende des Tages, dafür ist halt dann momentan relativ gut, ja.

SPEAKER_00

Ja, danke für die Einschätzung und danke für das Gespräch heute zum Thema NN und noch einen schönen Tag an unsere Zuschauer und Zuhörer. Bis dann. Ciao.