AI dort, wo sie nachweisbar Geschäftsnutzen schafft — nicht als Selbstzweck, nicht als Pilot-Theater.
Sie hören seit zwei Jahren von AI-Transformation. Sie sehen beeindruckende Demos. Und Sie haben den Verdacht, dass die meisten Initiativen im Pilot-Stadium stecken bleiben — ohne dass jemand sagt warum. Was Sie suchen: jemanden, der AI nicht als nächsten Chatbot-Prototyp behandelt, sondern als integralen Teil Ihrer Systeme — mit klaren Grenzen, messbarem Nutzen und der Frage 'wer trägt Verantwortung' an den richtigen Stellen geklärt.
Der typische Verlauf: Eine Abteilung experimentiert mit ChatGPT, baut einen beeindruckenden Prototyp, präsentiert intern, alle sind begeistert. Drei Monate später ist nichts in Produktion — weil niemand geklärt hat, wer haftet, wenn die AI halluziniert, wie Token-Kosten pro Abfrage zu Buche schlagen, was passiert wenn der LLM-Anbieter sein Modell tauscht, und wer Eval-Tests gegen Regressionen schreibt.
Demo-zu-Produktion-Lücke
Beeindruckender Prototyp ohne Architektur-Plan landet im Pilot-Limbus. Token-Kosten, Halluzinations-Rate, Modell-Migration, Eval — das entscheidet Produktion vs. Demo, nicht die Wow-Demo.
Oder noch häufiger: Es gibt zwei parallele AI-Initiativen, eine im Marketing mit einem Chatbot, eine im IT mit einem RAG-Prototyp. Beide nutzen unterschiedliche LLMs, unterschiedliche Vektor-Datenbanken, unterschiedliche Embedding-Modelle. In sechs Monaten haben Sie zwei Insel-Lösungen, drei API-Abrechnungen und keine kohärente AI-Strategie.
Das hat eine gemeinsame Ursache: AI wird als Tool-Thema behandelt statt als Architektur-Thema. Demo-Geschwindigkeit wird belohnt, Produktions-Tauglichkeit selten honoriert, Eval-Pipelines fast nie sichtbar verkauft. Multi-Agent-Architekturen klingen modern — bis Sie versuchen, einen Bug in einer agentic Pipeline zu debuggen, in der drei LLMs miteinander gesprochen haben.
Multi-Agent-Magie
Architekturen mit drei plaudernden LLMs sehen futuristisch aus — und sind nicht debuggbar, wenn die Ergebnisse driften. Konservativ vor Magic ist hier Architektur-Disziplin, nicht Innovations-Bremse.
Mein Ansatz: AI als integrierte Schicht in Ihre Systeme denken, nicht als isolierter Prototyp. Modular, sodass LLM-Wechsel keine Architektur-Brüche auslösen. Beobachtbar, sodass Token-Kosten pro Request, Latenz und Halluzinations-Rate transparent sind. Konservativ — RAG vor Fine-Tuning, Tool-Use vor Multi-Agent, deterministisch wo immer möglich. Und mit klarer menschlicher Verantwortung dort, wo Entscheidungen Konsequenzen haben.
Vier Prinzipien, an denen ich AI-Architektur ausrichte — entstanden aus 25 Jahren verteilten Systemen und produktivem Einsatz aktueller AI-Architekturen:
Ehrliche Bewertung Ihrer AI-Initiativen: wo bringt AI nachweisbar Wert, wo ist klassische Software die saubere Antwort, wo lohnt sich ein RAG-System statt eines Chatbots. Sie bekommen eine priorisierte Liste mit erwartetem Nutzen, Aufwand und Risiko pro Use-Case — kein Pauschal-'AI macht alles'.
Document-Ingestion, Chunking-Strategien, hybride Suche (Vektor + Keyword), Re-Ranking. Bewährt produktiv mit Dify und Weaviate auf eigener Infrastruktur — diese Webseite ist die Live-Demo. Hands-on auch mit pgvector und Qdrant für Bestandsumgebungen.
Mehrere produktive MCP-Server entwickelt, unter anderem für Enterprise-DataHub-Abfragen bei der Hoffmann Group. Claude, GPT-4 und lokale Modelle kontrolliert mit echten Tools verbunden — mit Boundaries, Auth-Schicht, Audit-Trail.
Eigene AI-Agents, die Entwicklungsaufgaben autonom übernehmen und über das Ticketing-System mit dem Team kommunizieren — als Werkzeug-Verstärker, nicht als Ersatz. Automatisierte Code-Reviews in GitLab, GitHub und Azure DevOps. Architekt definiert Boundaries und Quality-Gates.
Eval-Pipelines gegen Modell-Drift, Cost-Monitoring pro Request, Rate-Limiting, Input-Validation, Prompt-Injection-Protection. Fallback-Chains bei Modell-Ausfall. Das alles als Architektur-Schicht, nicht als Bolt-on nach dem ersten Production-Incident.
MCP-Server hat das DataHub-Backend erstmals direkt für AI-Tools zugänglich gemacht. Entwickler:innen formulieren Queries seitdem in natürlicher Sprache, statt GraphQL-Schemata auswendig zu lernen. AI-Assistenz im Playground beschleunigt das Onboarding neuer Use-Cases und Konsumenten spürbar — ohne dass das Data-Modell oder die bestehende GraphQL-Federation davon weiß.
Diese Webseite ist nicht nur Portfolio, sondern selbst eine produktive RAG-Architektur: Dify als Orchestrierung, Weaviate als Vektor-Datenbank, eigene Knowledge-Base, GPT-4 für Antwort-Generierung mit Streaming. Self-hosted auf Kubernetes-Cluster mit GitOps. Wer wissen will, wie sich eine produktiv betriebene RAG-Pipeline anfühlt, kann hier rechts unten chatten.
Eigenentwickelte AI-Agents übernehmen Entwicklungsaufgaben autonom und kommunizieren über GitLab-Tickets mit den menschlichen Teammitgliedern. Zusätzlich automatisierte Code-Reviews über GitLab, GitHub und Azure DevOps. Brückentechnologie zwischen klassischen Microservice-Landschaften und LLM-gestützten Werkzeugen — Architekt definiert Aufgaben, AI führt aus, Mensch reviewt.
„... outstanding mind with excellent skills in development; great software architect. Highly recommended if you need to find a professional fast and scalable solution. We've been working together on a project that was rated by Microsoft professionals as "not possible". Together with Christian our team managed to deliver a great working solution/product!"
Wenn Determinismus zählt (Buchhaltung, Compliance, Abrechnung) — regelbasierte Systeme schlagen LLMs in jedem Audit. Wenn der Korpus ins Context-Window passt — direkt ins Prompt ist deterministischer und beweisbarer als RAG. Wenn der Output nicht überprüfbar ist — LLM-Antworten ohne Eval-Pipeline sind ein Compliance-Risiko, kein Feature. Wenn Konsequenzen irreversibel sind (medizinische, finanzielle, sicherheitskritische Entscheidungen) gehört der Mensch in den Loop.
Das entscheidet der Use-Case, nicht die Anbieter-Präferenz. Cloud-LLMs (OpenAI, Anthropic) sind oft die schnellere und für viele Workloads die wirtschaftlichere Antwort. Self-Hosted (Llama, Mistral, eigene Modelle) lohnt bei Daten-Souveränität-Anforderungen, regulierten Branchen oder hohem Volumen mit Kostenkontrolle. Häufig: Hybrid — sensitive Pfade self-hosted, Rest in der Cloud.
Eval-Pipelines mit definierten Testsets pro Use-Case. Hallucination-Rate, Faktenkonsistenz, Token-Cost pro Request, Latenz-Profil. Bei RAG zusätzlich: Retrieval-Precision (werden die richtigen Dokumente gefunden?) und Answer-Faithfulness (steht die Antwort tatsächlich in den abgerufenen Dokumenten?). Ohne diese Schicht ist 'AI-Qualität' eine Behauptung, keine Messung.
Token-Kosten plus Infrastruktur (Vektor-DB, Compute, Monitoring). Bei kleinen Volumina dominieren Token-Kosten, bei hohen Volumina die Infrastruktur. Konkret: ein produktives RAG-System mit ~10k Anfragen/Monat liegt typisch im niedrigen drei- bis vierstelligen Euro-Bereich pro Monat — abhängig von Modell-Wahl, Chunk-Größe und ob Caching genutzt wird. Cost-Monitoring pro Request gehört von Anfang an in die Architektur, sonst gibt es Überraschungen.
Data-Flow-Diagramme pro Use-Case (welche Daten verlassen Ihr System, wohin, mit welchem Vertrag), Logging aller Inferenzen für Audit-Trails, Input-Validation gegen Prompt-Injection, klare Verantwortungs-Zuordnung wer was reviewt. Bei DSGVO-sensitiven Daten häufig: Self-Hosting oder Cloud-Anbieter mit DPA und EU-Region. AI-Compliance ist kein nachträglicher Patch, sondern Architektur-Eigenschaft.
Ein paar gezielte Fragen statt starres Formular — ich verstehe in 2–3 Minuten, worum es geht, und melde mich persönlich.