Kategorie: AI

Letztens saß ich zum Dinner mit einem Ex-CEO eines DAX Unternehmens, pitchte unsere Enterprise AI Plattform neonet.AI und schwadronierte von den eingesparten FTE bei unseren Kunden, die mit unseren Agenten und der Dataengine komplexe Businessprozesse im Supply Chain Tech abbilden.

Ich bin da echt stolz drauf, aber der CEO fragte mich, „und was ist Euer Geschäftsmodell“? „Licensefee per User Per month“ war meine kurze Antwort. Ich wolle schon weiter zum nächsten Thema, weil das ein so kurz abzuhakender Punkt war, den jeder sofort versteht, aber er hakte nach: „Macht keinen Sinn!“.

Ich brauchte einen Moment um zu verstehen, was er meinte. Dann fiel es mir wie Schuppen von den Augen: „Wenn ihr FTE einspart, wieso rechnet ihr dann pro User ab? Das macht für Euch auf Dauer keinen Sinn“. Boom, er hatte einen Punkt.

Die Frage, die sich uns gestellt hat ist: wie kann man die „Arbeit“, die früher Menschen erledigt haben und heute durch Agents abgedeckt wird, so quantifizieren, dass Kunden „gerne“ dafür bezahlen – und zwar so viel, wie sie auch herausbekommen?

Wir haben dafür eine neue Abrechnungseinheit entwickelt: SVU.

SVU steht für Semantic Valdiation Unit und bezeichnet eine gegen eine Ontologie/Knowledge Graph validierte Operation. In TruthGuard, der Datensäule in neonet, mappen wir Datenpipelines gegen Standard- oder individualiserte Ontologien, um die Daten semantisch zu beschreiben und über Bridges in Relation zu setzen. Dabei gibt es eine vielzahl an autoamtiserten Optimierung die dafür sorgen, dass das Datenmodell über die Zeit hinweg sich selbst optimiert und damit immer komplexere Fragen valide und ohne zu halluzinieren beantowrten kann. Dabei ist das Modell eher sekundär – hauptsache es kann Sprache 😉

Jede validierte Anfrage bringt also einen echten Mehrwert für den Kunden, sei es durch Agenten, die auf Basis der validerten Daten echte autonome Aktionen durchführen können, oder in validierten komplexen Antworten für Menschen, die die Informationen dann weiterverarbeiten. Immer aber ist eine Werthalitgkeit zu Grunde gelegt, für die der Kunde bereit ist, zu zahlen. Dabei kann die Menge der SVUs an die Komplexität der Abfrage oder die Geschwindigkeit der Antowrt gekoppelt und somit gesteuert werden.

Hier dazu mal ein kleines Rechenbeispiel aus dem Bereich HR, Urlaubs-Inanspruchname und verschiedene Fälle dazu:

Die Progression einer Abfrage

1. Einfacher Lookup · „Wie viel Resturlaub hat Anna Schmidt?“ → 1 Op × Basic (1,0×) = 1 SVU
2. Gefilterte Abfrage · „Wer im Team hat noch >20 Tage offen?“ → 4 Ops × Basic (1,0×) = 4 SVU
3. Reasoning · „Wer riskiert Verfall – und welche Regelung greift?“ (Joins + Inferenz gegen Policy-Ontologie) → 4 Ops × Reasoning (3,0×) = 12 SVU
4. Komplexes Reasoning · „Verfall-Risiko über alle DE-Entitäten inkl. Tarif-Sonderfälle“ → 6 Ops × Reasoning (3,0×) = 18 SVU
5. Agent, lesend · prüft autonom jeden betroffenen MA gegen Policy + Tarif → 8 Ops × Agent (5,0×) = 40 SVU
6. Agent, schreibend/triggernd · erstellt Genehmigungs-Workflow, benachrichtigt Führungskräfte, triggert Freigaben → 12 Ops × Agent (5,0×) = 60 SVU

Der Punkt: Vom simpelsten zum reichsten Schritt sind es 1 → 60 SVU – Faktor 60 für eine Aufgabe. Mensch und Agent leben dabei in unterschiedlichen Zonen: der Mensch fragt und denkt (Stufen 1–4), der Agent handelt end-to-end (Stufen 5–6). Genau dort, wo die Wertschöpfung autonom wird, springt das Klassengewicht auf 5,0×.

Key Takeaway: mit SVUs wird die Leistung einer AI fair und transparent bepreist und macht für den Kunden den Mehrwert deutlich und bepreisbar.

Hinweis: ja, der CFO wird natürlich immer Packages oder Quotas verlangen – die kann man aber, zumindest bei neonet.ai, dynamisch pro user / Agent / Abteilung / Org vergeben 😉

Was Apples „Illusion of Thinking“ über Reasoning Modelle aussagt, und warum die Antwort nicht im nächsten Frontier-Release liegt.

---

Im Juni 2025 hat Apple ein Paper veröffentlicht das in der AI-Community einige Diskussionen ausgelöst hat. „The Illusion of Thinking“ heisst es. Die Autoren um Parshin Shojaee und Mehrdad Farajtabar untersuchen systematisch was die neuen Reasoning Modelle (OpenAI o1/o3, DeepSeek R1, Claude 3.7 Sonnet Thinking, Gemini Thinking) eigentlich leisten, wenn sie ihre Chain-of-Thought ausrollen.

Ich finde das Paper auch heute, im Mai 2026, noch lesenswert. Die spezifischen Benchmark-Zahlen sind durch neuere Modellgenerationen überholt, das ist klar. Aber die methodische und strukturelle Beobachtung hält. Und sie ist relevant für jeden der über Enterprise AI nachdenkt: LLMs und LRMs als alleinige Lösung tragen nicht weit genug.

Was Apple gemacht hat

Statt der üblichen Math-Benchmarks (MATH-500, AIME etc.) die alle mit Datenkontamination kämpfen, haben die Researcher vier kontrollierbare Puzzles verwendet: Tower of Hanoi, Checker Jumping, River Crossing und Blocks World. Der Vorteil ist methodisch: die Komplexität lässt sich exakt parametrisieren (Anzahl Disks, Blöcke etc.), und ein Simulator kann jeden einzelnen Zwischenschritt validieren, nicht nur die finale Antwort.

Damit lässt sich beobachten was bei normalen Benchmarks unsichtbar bleibt. Also nicht nur ob ein Modell richtig liegt, sondern wo in der Gedankenkette es tatsächlich falsch abbiegt.

Der zentrale Befund: es lassen sich drei klar unterscheidbare Stufen identifizieren wenn die Komplexität steigt.

Bei niedriger Komplexität sind die Standard-LLMs (ohne Thinking-Modus) genauer und vor allem deutlich token-effizienter. Die Reasoning-Modelle zeigen hier ein Phänomen das die Autoren als „overthinking“ beschreiben: sie finden die korrekte Lösung früh, probieren danach aber weiter falsche Alternativen aus. Das kostet Compute ohne Nutzen.

Bei mittlerer Komplexität dreht sich das Bild. Hier zahlt der lange Chain-of-Thought sich aus, das Reasoning-Modell gewinnt im Vergleich zur Standard-Variante. Das ist auch der Bereich der in typischen Demos und Vergleichen gezeigt wird.

Bei hoher Komplexität kollabieren beide Modelltypen auf nahe null Prozent Accuracy. Das Reasoning-Modell verzögert den Kollaps, verhindert ihn aber nicht. Die Autoren schreiben dazu nüchtern, dass die Modelle „complete accuracy collapse beyond certain complexities“ erleiden. Komplett, nicht graduell.

Aufschlussreicher als der Kollaps selbst ist was kurz davor passiert:

Die Modelle reduzieren ihren Reasoning-Aufwand wieder, bevor sie kollabieren. Sie haben noch Token-Budget zur Verfügung, sie könnten weiterdenken. Sie tun es aber nicht. Apple nennt das ein „counterintuitive scaling limit“ und es ist tatsächlich nicht ohne weiteres erklärbar. Das Modell scheint irgendwo zu erkennen dass es nicht weiterkommt, und reduziert daraufhin seinen Aufwand.

Ebenso relevant ist ein weiterer Test im Paper. Die Forscher haben den Modellen den Lösungsalgorithmus explizit in den Prompt gegeben, also den rekursiven Hanoi-Algorithmus als Pseudocode. Das Modell muss ihn nicht mehr finden, sondern nur noch ausführen. Das Ergebnis: Kollaps an derselben Stelle. Keine Verbesserung.

Das ist methodisch wichtig. Es deutet darauf hin dass das Problem nicht primär im Auffinden der Strategie liegt, sondern in der konsistenten Ausführung logischer Schritte. Search ist nicht der Engpass, Execution ist es.

Wie zu erwarten ist relativ schnell eine Antwort gekommen. Im Juni 2025 veröffentlichten „C. Opus“ (der Co-Autor ist tatsächlich Claude Opus als Sprachmodell 😃) und Alex Lawsen von Open Philanthropy ein Gegenpaper mit dem Titel „The Illusion of the Illusion of Thinking“. Ihr Argument: ein Teil der beobachteten Kollapse seien Artefakte des Experimental-Setups. Token-Limits, fehlerhafte Auswertungsskripte, River-Crossing-Konfigurationen die bei N≥6 mit Bootskapazität 3 mathematisch nicht lösbar sind.

Diese Kritikpunkte sind teilweise berechtigt. Lawsen selbst hat das Paper im Nachhinein als halb-ironisch bezeichnet und war von der Reichweite überrascht. Inhaltlich bleibt aber unter anderem die Beobachtung dass „solution length poorly predicts problem difficulty“, also dass die Anzahl der nötigen Schritte ein unzureichender Komplexitätsindikator ist. Eine valide methodische Anmerkung.

Was die Kritik nicht leistet ist die Widerlegung der Kernbeobachtung. Eine Replikationsstudie aus dem CSIC in Madrid (Dellibarda Varela et al., Juli 2025, „Rethinking the Illusion of Thinking“) hat das Setup nachgebaut und um „agentic dialogue“ sowie „incremental stepwise prompting“ erweitert. Ergebnis: ein Teil der Effekte lässt sich auf Token-Limits zurückführen, das stimmt. Aber bei moderater Komplexität, etwa bei N=8 in Hanoi, „still stumble“ die LRMs trotzdem. Der grundlegende Befund hält also.

Apple hat in der dritten Version des Papers (November 2025) zudem einen Abschnitt mit Antworten auf die Hauptkritikpunkte eingefügt. River Crossing wurde auf N<6 eingeschränkt, Sampling-Effekte über Temperature Zero ausgeschlossen, zusätzliche Modellpaare aufgenommen (QwQ-32B / Qwen2.5-32B als Validierung). Die drei Regime und der Kollaps reproduzieren sich auch unter den verschärften Bedingungen.

In Kundengesprächen begegnet mir regelmässig die Annahme dass das aktuelle Modell-Verhalten ein temporäres Problem sei, das mit der nächsten Generation gelöst wird. „wenn wir erstmal Claude xx nuzten, dann geht alles viel einfacher“. Das Apple-Paper und die seitherige Diskussion legen nahe das das nicht so ist.

Das Modell alleine ist nicht der primäre Engpass. Mehr Tokens lösen es nicht, mehr Parameter offenbar auch nicht, und selbst der explizit gegebene Lösungsalgorithmus löst es nicht. Es ist ein architektonisches Problem, nicht primär ein Skalierungsproblem.

Das hat Konsequenzen für die Frage wie man Enterprise AI sinnvoll aufsetzt. Wer eine produktive AI-Lösung in regulierten Umgebungen aufbauen will kann sich nicht ausschliesslich auf das Modell verlassen. Es braucht eine Schicht drumherum.

Genau hier setzt neonet.AI an. Wenn das Modell selbst die korrekten Schritte weder zuverlässig finden noch ausführen kann, muss die Korrektheit aus der Umgebung kommen. Strukturiert, validiert, auditierbar.

Die drei Säulen:

Daten. Hier sitzt unsere TruthGuard®-Komponente als semantische Validierungsschicht. Ein Knowledge Graph in Neo4j mit formalen Constraints in SHACL, ergänzt um Ontology Alignment via Jaccard Similarity. Der Unterschied zu rein statistischem RAG ist konzeptionell: Aussagen werden gegen eine formale Ontologie geprüft, also als konsistent oder inkonsistent klassifiziert, nicht als wahrscheinlich oder unwahrscheinlich. Für Enterprise-Anwendungen ist das ein relevanter Unterschied.

Prozesse. Ein Process Designer der natürliche Sprache in ausführbare MCP-Agentenketten übersetzt, plus Pulse als Anomalie-Erkennung im Live-Betrieb. Was die LRMs laut Apple nicht zuverlässig leisten (lange konsistente Sequenzen ausführen) übernimmt eine Architektur die genau dafür ausgelegt ist. Das Apple-Paper beschreibt diese Schwäche klar: selbst mit gegebenem Algorithmus scheitert die Ausführung am selben Punkt wie ohne.

Governance. Ein Compliance-Agent dokumentiert Entscheidungen, prüft gegen die jeweiligen Regularien (EU AI Act, DSGVO, NIS2, DORA, BAIT je nach Sektor) und macht die Entscheidungswege auditierbar. In regulierten Branchen ist das keine Option sondern Voraussetzung.

Das Foundation Model ist in dieser Architektur die unterste Schicht. Wichtig, aber austauschbar. Das eigentliche Produkt liegt darüber.

Schluss

Das Apple-Paper ist nicht ohne berechtigte Kritik, und die konkreten Benchmark-Zahlen sind durch neuere Modelle überholt. Die strukturelle Aussage hält allerdings: Reasoning Modelle sind ein wichtiger Baustein, aber kein vollständiges Werkzeug. Wer Enterprise AI baut und auf das Modell alleine setzt, baut auf einer Schicht die laut der bisherigen Befunde an klar identifizierbaren Komplexitätsschwellen nachgibt.

Die Konsequenz daraus ist eine Architektur die das Modell stützt, ergänzt und kontrolliert. Daten, Prozesse, Governance. Das Modell als Commodity, die Architektur als Produkt. Das war die These im letzten Post auch schon, das Apple-Paper liefert dafür eine zusätzliche empirische Begründung.

---

Referenzen

Shojaee, P., Mirzadeh, I., Alizadeh, K., Horton, M., Bengio, S., Farajtabar, M. (2025). The Illusion of Thinking: Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexity. arXiv:2506.06941v3 (November 2025).

Opus, C., Lawsen, A. (2025). The Illusion of the Illusion of Thinking: A Comment on Shojaee et al. (2025). arXiv:2506.09250.

Dellibarda Varela, I., Romero-Sorozabal, P., Rocon, E., Cebrian, M. (2025). Rethinking the Illusion of Thinking. arXiv:2507.01231, CSIC Madrid.

Vorheriger Post in dieser Linie: Das Modell ist die Commodity (13. Mai 2026)

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