Kategorie: AI

Warum ernsthafte Enterprise-KI drei Säulen braucht – und das LLM die unwichtigste davon ist.

Wenn ich in den letzten Monaten mit CIOs, IT-Leitern oder Datenarchitekten gesprochen habe, dreht sich die Debatte fast immer um die falsche Achse. Welches Modell? GPT-5 oder Claude? Open Source oder Closed? Wie groß muss das Kontextfenster sein? Und wenn die Antworten halluzinieren – dann eben Fine-Tuning, vielleicht noch ein Reasoning-Layer obendrauf, oder einfach ein anderes Modell.

Das ist jedoch die falsche Diskussion.

Meine These, die wir mit neonet.AI seit zwei Jahren in den Markt tragen: Das Sprachmodell ist die austauschbare Komponente. Es ist die Commodity. Was wirklich zählt, ist das, was neben dem Modell steht, und ihm Bedeutung gegenüberstellt.

Warum LLMs alleine im Enterprise-Kontext nicht funktionieren

Ein Large Language Model ist im Kern ein statistisches Sprachmodell. Es weiß, welche Token mit welcher Wahrscheinlichkeit auf welche anderen folgen. Es hat ein gigantisches Weltwissen aus dem Trainingskorpus – aber es hat keinerlei strukturierte Vorstellung davon, was in deinem Unternehmen Wahrheit ist.

Diese Lücke ist die eigentliche Engineering-Aufgabe. RAG ist ein erster Workaround, aber RAG mit reinen Vektor-Embeddings bleibt unscharf – es liefert ähnlichen Text, nicht wahren Kontext. Für die meisten „Wo ist mein Urlaubsantrag“-Fragen reicht das. Für die Frage „Welche Investitionsentscheidung müssen wir treffen, wenn das Geräte-Inventar in Werk 3 unter dem Sicherheitsschwellwert unserer Compliance-Verpflichtung X liegt“ aber eben nicht.

„Mitarbeiter X hat 28 Resturlaubstage“ und „Mitarbeiter X hat 2,8 Resturlaubstage“ haben fast identische Embeddings und unterschiedliche arbeitsrechtliche Konsequenzen. Vektor-Ähnlichkeit ist nicht dasselbe wie semantische Wahrheit.

Hier kommen die drei Säulen ins Spiel.

Die drei Säulen

Alle drei Säulen für sich genommen sind alte Hüte – Knowledge Graphs kennt jeder Semantic-Web-Veteran seit zwanzig Jahren, Workflow-Engines gibt es seit den 90ern, und über Governance reden wir, seit der erste Compliance-Officer geboren wurde. Die These ist nicht, dass eines dieser Themen neu ist. Die These ist, dass erst ihr orchestriertes Zusammenspiel das LLM in die Lage versetzt, im Unternehmenskontext überhaupt verlässlich zu liefern.

Säule 1 – Daten: Knowledge Graph mit deterministischem Wahrheitsanker

Die Datenseite ist, technisch gesehen, der schwerste Teil. Wir bauen einen Property-Graph in Neo4j als zentralen semantischen Layer, in den wir Daten aus den Quellsystemen über RML/R2RML-Mappings einspielen. W3C-Ontologien definieren die Vokabulare, SHACL die Constraints.

SHACL ist der entscheidende Punkt. Ein Sprachmodell ist stochastisch: bei gleicher Eingabe können unterschiedliche Antworten herauskommen. SHACL ist deterministisch: gleiche Daten plus gleiche Shape ergeben immer dasselbe Ergebnis. Jede Verletzung produziert einen sh:ValidationReport mit exakter Begründung – welcher Knoten, welche Property, welche Regel. Das LLM darf raten. SHACL entscheidet, ob das Geratene konsistent ist.

Konkret laufen zwei Modi parallel auf demselben Graphen:

• Semantic Layer – request-getrieben. Eine eingehende Anfrage ans LLM wird durch den Graphen geerdet, das LLM bekommt strukturierte Fakten als Kontext, die Antwort wird vor Auslieferung gegen SHACL-Constraints validiert. Halluzinationen werden auf der Architekturebene abgefangen, nicht durch besseres Prompting.
• Pulse – event-getrieben. Änderungen in den Quellsystemen werden per Change Data Capture in den Graphen gespiegelt, gegen Ontologie-Patterns geprüft, auf Drift und Downstream-Impact analysiert. Eine Änderung in System A, die erst in drei Tagen zu falschen Antworten in System B führen würde, wird heute sichtbar.

Über 400 Konnektoren binden Quellsysteme an – sowohl für den Ingest in den Graphen als auch für den Write-Back. Das heißt: Wenn das LLM eine semantisch geprüfte Aktion bestimmt, schreibt die Plattform das Ergebnis direkt zurück in SAP, ServiceNow oder Workday. Kein „AI sagt dir was du tun sollst, klick dich dann selbst durch das ERP“.

Säule 2 – Prozesse: Vom Prompt zum produktiven Agenten

Statisches Wissen reicht nicht. Im Unternehmen passiert Wertschöpfung im Fluss und der Fluss braucht Prozesse, die etwas tun, nicht nur reden.

Die zentrale Komponente dieser Säule ist unser Process Designer: ein visueller Editor mit darunterliegender BPMN-Engine, in dem man aus natürlicher Sprache vollständige Agenten-Workflows generieren kann. Du beschreibst, was passieren soll – „wenn eine Krankmeldung im SuccessFactors eintrudelt und der Mitarbeiter im selben Quartal die fünfte ist, prüfe gegen das BEM-Regelwerk und erstelle bei Bedarf einen Vorgang in ServiceNow mit Eskalation an die zuständige Führungskraft“ – und der Designer baut den Workflow, mit MCP-Tool-Bindings zu den beteiligten Systemen, mit Entscheidungsknoten, mit Human-in-the-Loop-Approval-Gates an den richtigen Stellen.

Unter der Haube läuft das auf Temporal für Long-Running-Orchestrierung und DSPy für Prompt-Optimierung der einzelnen Reasoning-Schritte. Die Agenten sind durchgängig MCP-fähig – sie können nicht nur lesen („talk to your data“), sondern auch schreiben, Events auslösen, andere Agenten anstoßen, Aktionen in Drittsystemen ausführen. Das ist der Unterschied zwischen einem Chatbot und einem produktionsreifen Agenten.

Für Entwickler-Teams gibt es darüber hinaus eine Enterprise-Vibe-Coding-Schicht: MCP-Server, mit denen Claude Code, Cursor, Windsurf oder GitHub Copilot direkt gegen den semantischen Layer und die Governance-Schicht arbeiten. Wer im Konzern KI-gestützt entwickelt, bekommt den Unternehmens-Kontext und die Compliance-Constraints zur Build-Zeit ins eigene Tool, nicht erst beim Deploy.

Säule 3 – Governance: der oft vergessene Layer, der über Erfolg entscheidet

Über Daten und Prozesse spricht jeder. Über Governance fast niemand, bis der erste regulatorische Audit ansteht oder die BaFin Fragen zur KI-gestützten Entscheidungsfindung stellt. MaRisk, BAIT, EU AI Act, NIS2, DORA, CRA, CSRD: Die Liste der Frameworks, die direkt oder indirekt auf KI-Einsatz im Unternehmen einschlagen, wird länger, nicht kürzer.

Governance in neonet.AI ist kein PDF in SharePoint, sondern ausführbarer Code. Drei Bausteine greifen ineinander:

Der Compliance Agent ist ein MCP-Server, der direkt in der Entwicklungsumgebung läuft, Shift-Left, also bevor Code überhaupt gemerged wird. Beim Vibe-Coding bekommen Claude Code & Co. den regulatorischen Kontext in Echtzeit. Schreibst du einen Agenten, der auf personenbezogene Daten zugreift? Der Compliance Agent weist dich auf die Art-30-Pflicht hin, schlägt das passende RBAC-Pattern vor, generiert die DSFA-Vorlage. Beim Deploy prüft die Policy Engine deterministisch gegen die hinterlegten Regeln und blockt bei Verstößen am Code Security Gate.

Die Policy Engine verwaltet Regeln als YAML, git-versioniert, testbar, diffbar wie jeder andere Code-Artefakt. Dahinter liegt ein Regulatory Graph , auch das wieder Neo4j, der die Beziehungen zwischen Regulation → Anforderung → Policy → Control → Agent → Data Classification abbildet. Das ist der Grund, warum die Plattform für einen konkreten Agenten in Sekunden sagen kann, welche AI-Act-Anforderung greift, welche internen Policies das umsetzen und ob die aktuelle Implementierung konform ist.

Der Evidence Generator produziert die Artefakte, die du im Audit brauchst: Audit Trail, Lineage zwischen Antwort und Quelldaten, DSFA-Dokumente, Verfahrensverzeichnis nach Art. 30, AI-Act-Dokumentation, Betriebsrats-Anlagen. Alles reproduzierbar, alles aus dem gleichen Graphen abgeleitet, der den operativen Betrieb auch fährt.

Das Gesamtbild

Das LLM in der Mitte? Austauschbar. Heute GPT-5, morgen Claude, übermorgen das, was wir noch nicht kennen. Eine Lizenzentscheidung, kein Architekturentscheid. Was nicht austauschbar ist: der semantische Kontext, in dem dieses Modell operiert. Das ist die Plattform-Schicht. Das ist die eigentliche Arbeit.

Was übrigens auch erklärt, warum wir mit Microsoft Copilot, SAP Joule und allen relevanten Frontends auf dem Markt sauber interoperieren. Wir konkurrieren nicht mit der UI-Schicht, wir liefern das, was darunter passieren muss, damit die UI-Schicht überhaupt produktionsreife Antworten bekommt.

Wo das Ganze läuft

Ein Punkt, der bei strategischen Gesprächen mit deutschen Konzernen, Behörden und kritischer Infrastruktur regelmäßig den Unterschied macht: die komplette Plattform läuft auf einem Kubernetes-Cluster. Deployment über ArgoCD im GitOps-Modus, alle Plattformdienste containerisiert, jede Komponente skaliert horizontal.

Das heißt in der Praxis: Wo der Cluster läuft, ist eine Entscheidung des Kunden, nicht von uns.

• AWS, Azure, GCP – wenn der Kunde ohnehin Hyperscaler-strategisch unterwegs ist
• STACKIT, Hetzner, Ionos, T-Systems – wenn EU-Hosting hart erforderlich ist
• Private Cloud auf VMware/OpenShift – wenn der Konzern eine eigene Plattform-Strategie fährt
• On-Prem im eigenen Rechenzentrum – wenn die Daten das Haus nicht verlassen dürfen
• Air-Gapped – wenn auch das Internet draußen bleiben muss

Dazu der LLM-Layer: Bring your own model. OpenAI über Azure, Anthropic über AWS Bedrock, Mistral über die eigene EU-Cloud, lokale Open-Source-Modelle auf eigenem GPU-Cluster. Die Plattform ist agnostisch — was zurück zur Anfangsthese führt: Das Modell ist die Commodity.

Wer Enterprise-KI als Modell-Wettrennen begreift, hat das Spiel nicht verstanden – oder verkauft Modelle 🙂

Fazit

Die echte Wertschöpfung liegt nicht im Sprachmodell, sondern in der semantischen Infrastruktur, die ihm Bedeutung gegenüberstellt. Drei Säulen: Daten, Prozesse, Governance. Orchestriert auf einer freien Runtime. Sonst funktioniert es nicht.

Genau dafür gibt es neonet.AI.

95 % aller Unternehmen, die gerade Generative AI ausprobieren, fahren ihre Projekte gegen die Wand. Das ist kein Bauchgefühl, sondern das Ergebnis einer MIT-Studie von August 2025. 95 von 100 Piloten bringen keinen echten Mehrwert, keinen messbaren ROI.

Das klingt dramatisch – und ist es auch. Aber es ist eben nicht die Schuld der Technologie. Die Modelle können viel. Das Problem liegt meistens bei den Unternehmen selbst: falscher Fokus, zu viel Spielerei, zu wenig Struktur.

Und genau hier liegt der Unterschied: Bei neonet.AI generieren über 87 % unserer Projekte einen nachweisbaren, wachsenden ROI. Was machen wir also anders? Und warum schaffen wir das, wo fast alle scheitern? Ich versuche das herzuleiten:

1. Was die MIT-Studie wirklich sagt

• 95 % der Projekte bringen keinen ROI – sie bleiben „Experimente“, die nie skalieren.
• Budgets fließen vor allem ins Marketing – genau da, wo es schwer ist, echten, kurzfristigen ROI zu messen.
• Der größte Nutzen von AI liegt laut Studie im Back-Office: Automatisierung, Kostenreduktion, Prozess-Effizienz.
• Wer externe Tools oder Partner nutzt, hat eine doppelt so hohe Erfolgsquote wie die, die alles selbst bauen.
• Viele Unternehmen kämpfen mit „Shadow AI“: Mitarbeiter nutzen Tools wie ChatGPT auf eigene Faust – ohne Governance, ohne Kontrolle.

Kurz gesagt: Die meisten Unternehmen verzetteln sich.

2. Warum Piloten scheitern (und wie man es besser macht)

Es gibt ein paar ganz klassische Muster, die wir immer wieder sehen:

1. Falscher Fokus – „Wir machen was mit AI im Marketing.“ Klingt cool, bringt aber selten ROI.
2. Showcases statt Prozesse – es wird ein Demo-Projekt gebaut, das hübsch aussieht, aber nicht im Alltag funktioniert.
3. Alles selbst entwickeln – interne Teams unterschätzen Aufwand und Governance. Ergebnis: teure Prototypen, die niemand nutzt.
4. Keine Skalierung – das Projekt bleibt Pilot, weil es niemand sauber in die Organisation integriert.

Das Spannende: Genau diese Fehler lassen sich vermeiden, wenn man den ROI als Kompass nimmt.

3. Wie wir mit der Plattform neonet.AI rangehen

Unser Ansatz ist bewusst anders:

• Platform first: neonet.AI nimmt die Komplexität aus der AI Landschaft. Bewährte Modelle, Technologien und Prozesse sowie die „Magie“ der Plattform sorgen für sofortigen Mehrwert.
• ROI first: Wir starten nie mit „Was könnte man mit AI machen?“, sondern immer mit „Wo lässt sich der ROI heben?“.
• Back-Office first: Wir automatisieren repetitive Prozesse, reduzieren Kosten und schaffen messbare Effekte.
• Externe Power nutzen: Wir setzen auf bewährte Bibliotheken und Komponenten, die wir perfekt in Kundenprozesse integrieren. Kein Reinventing the Wheel.
• Governance by Design: Es gibt keine Schattenwelten – alles ist transparent, dokumentiert und sicher eingebunden.
• Skalierung im Blick: Wir denken schon beim Pilot daran, wie man ihn in den Regelbetrieb bringt.

Das Ergebnis: über 87 % der Projekte bringen einen klar messbaren ROI – und der wächst über die Zeit sogar noch. Damit sind sie reif für den produktiven RollOut.

4. Ein Beispiel aus der Praxis

Nehmen wir ein klassisches Szenario: Rechnungsverarbeitung.
Viele Unternehmen haben da Outsourcing- oder Shared-Service-Strukturen. Wir bieten mit unserer Plattform einen Agent, der Rechnungen automatisch liest, validiert und einsortiert. Ergebnis:

• 70 % weniger manuelle Eingaben
• Verarbeitungsgeschwindigkeit x4
• Fehlerquote sinkt deutlich
• Return on Investment innerhalb von 6–12 Monaten

Und das ist nur ein kleines Beispiel „out of the box“. Genauso funktioniert es in HR-Prozessen, in Compliance, bei Supportanfragen. Immer da, wo Routine und Volumen herrschen.

5. Was andere als Risiko sehen, ist für uns der Hebel

• „Shadow AI“? Wir kanalisieren diese Energie. Mitarbeiter sollen AI nutzen – aber kontrolliert, integriert, mit klaren Leitplanken.
• „Jobverlust?“ In Wahrheit verschwinden Jobs selten abrupt. Rollen verändern sich, Positionen werden nicht nachbesetzt, Teams werden effizienter. Wir sehen das als evolutionären Wandel, nicht als radikale Zäsur
• „Pilotfalle?“ Wir umgehen das, weil wir schon in der Konzeptphase auf Skalierung achten.

6. Agentic AI

Wir sind längst an dem Punkt, wo AI nicht nur reagiert, sondern eigenständig agiert:

• Erinnern
• Planen
• Handeln innerhalb definierter Grenzen

Man nennt das Agentic AI – und das ist der nächste Schritt, den wir bei neonet.AI schon anbieten. Hier entsteht echter Business Impact.

Fazit

Die MIT-Studie ist ein Weckruf: 95 % der Projekte scheitern, weil sie ohne Strategie und ROI-Fokus laufen. Aber sie zeigt auch: Wer es richtig macht, hat eine gigantische Chance.

neonet.AI gehört zu den erfolgreichsten Plattformen, weil wir genau diesen Weg gehen: ROI-orientiert, prozessorientiert, skalierbar. Unsere happy Kunden spüren das in über 87 % der Projekte – messbar, nachweisbar, nachhaltig.

Am Ende ist es nicht nur die Technologie, die entscheidet, sondern auch die Art, wie man sie einbettet. Und genau da liegt unsere Stärke.

Welcome RocketPoster.
RocketPoster lebt in der Macos Menüleiste und ist ein AI gestützter WordPress client.
Meine Idee war: ich blogge eingentlich total gerne, aber der Aufwand mit Überschriften, Kategorisierungen, Bildersuche etc. war mir einfach zu hoch – enter neonet.AI
Mit einem Agent, der zu verschiedenen Code-Repositories connected, habe ich in knapp 2,5 Stunden eine Swfit Anwendung erstellt, die einen “AI Turbomodus” und einen Manuellen Modus hat.
Der AI-Mode hat eigentlich nur ein Textfeld (in dem ich gerade schreibe) und nimmt den Text hier, erzeugt automatisch:
1. eine Überschrift
2. matcht den Text in eine vorhandene Kategorie
3. Sucht auf Pixabay und Unsplash nach einem passenden Beitragsbild
4. holt auch automatisch die copyrightnotice vom pic provider ab und postet die

Dadurch kann ich mich aufs einfache Texten konzentrieren und den rest erledigt RocketPoster für mich – also eine ideale Verbindun aus Microblogging und Langtext 🙂

Next Up wäre dann eine iOS App und, sofern möglich, eine Apple Watch app mit Spracheingabe.

Update:
Und hier ist übrigens der Link zum Projekt – wer möchte, kann es sich gerne selber kompilieren, weiterentwickeln, nutzen 🙂

RocketPoster auf GitHub[RocketPoster](https://github.com/ibornholz/RocketPoster/tree/main)

Foto von Lorenzo Herrera auf Unsplash

AI ist ja mittlerweile aus dem Arbeitsalltag gar nicht mehr wegzudenken und wird auch noch so viel weiter in die komplexesten Businessprozesse einziehen. Warum? Weil es an allen Stellen der Geschäftsprozesse einzelne Prozessstationen mit manuellen, wiederkehrenden und aufwändigen Schritten gibt, weil überall Steps mit Datenanalysen und Inhaltsgenerierungern gibt, die so viel schneller und effizienter mit AI umzustezten sind, als manuell.

Um das zu Koordinieren und zu planen, benötigt es eine Weiterentwciklung des klassischen Enterprise Architekten hin zum AI Architect. Wenn man sich einmal die Suchergebnisse bei Stepstone Deutschland aktuell anschaut, finden sich zwar noch 340 Treffer zum Enterprise Architekten und nur 65 Treffer zum AI Architekten, aber das wird sich über die Zeit annhähern. Zumindest ist ein Enterprise Architekt, der sich nicht mit AI auskennt, bald aus dem Spiel.

Foto von Mika Ruusunen auf Unsplash

Manchmal lernt man von Kaffee mehr über Technologie als von jedem Whitepaper.

Neulich stand ich da, Handfilter in der Hand, heißes Wasser in kreisenden Bewegungen über frisch gemahlenen Kaffee gießend. Und mir wurde klar: Das ist im Grunde „Orchestrierung“.

Der Filter entscheidet, was durchkommt. Das Timing, die Temperatur, der Mahlgrad – alles beeinflusst das Ergebnis.

Und bei KI?
Genau so funktioniert Modellorchestrierung: Nicht jedes Modell bekommt jede Datenquelle ungefiltert. Manche Modelle sind besser für Text, andere für Bilder, wieder andere für hochstrukturierte ERP-Daten.

Ohne Orchestrierung hat man am Ende eine bittere Brühe: zu viele Daten, falsche Formate, langsame Abläufe.

Mit neonet.AI orchestrieren wir diese Prozesse – wir filtern, leiten weiter, kombinieren. So entsteht am Ende nicht einfach nur „irgendein Output“, sondern ein Ergebnis, das schmeckt – im Business-Kontext bedeutet das: hochqualitative Daten, die Wert schaffen.

Also ja: Vielleicht ist die wichtigste Lektion meiner letzten Kaffee-Session, dass KI wie guter Kaffee ist. Das Modell ist die Bohne – aber die Orchestrierung ist der Filter, der den Unterschied macht.

Credit: Foto von Ketut Subiyanto

As I mentioned previously, ChatGPT is quite good (but not only at) at SQL. I think its a great opprotunity to really learn to code (if you want to call SQL querying „coding“ but that’s another discussion). I mean, only this information is SO valuable, I would have searched stackoverflow for hours finding the reason for my SQL bug:

I now can change the query or update mysql.

So here is my lazy setup to create complex SQL queries:

1. I am using the graphical query builder of metabase for all the complex joining of data

2. I then review the result and convert the results to SQL.

3. For the lazy mode I then paste the sql to ChatGPT, and asking it to add modifications, adjust it – and all in natural language.