Ende 2023 stand unser Team vor einer Aufgabe, die es so vorher nicht gab: Eine AI-Plattform für 120.000 Siemens-Mitarbeiter entwickeln –
Infrastruktur, Backend, AI. Nicht als Experiment. Nicht als Prototyp. In Produktion.
Heute laufen über 50 AI-Modelle auf dieser Plattform. Hunderttausende Nachrichten pro Tag. Tausende Agents, die von Mitarbeitern ohne Programmierkenntnisse erstellt wurden.
Es ist eine Erfolgsstory. Aber der Weg dahin war alles andere als geradlinig.
Hier ist, was wir gelernt haben.
1. Provider-Agnostik ist keine Option, sondern Pflicht
Als wir SiemensGPT konzipierten, war die Versuchung groß, auf einen einzigen AI-Provider zu setzen. OpenAI war dominant, die API gut dokumentiert, das Ökosystem wuchs schnell.
Wir haben uns dagegen entschieden. Und das war eine der besten architektonischen Entscheidungen des Projekts.
Innerhalb von 18 Monaten hat sich die Modelllandschaft dreimal fundamental verändert. Claude wurde besser als GPT-4 für bestimmte Anwendungsfälle. Open-Source-Modelle wie LLaMA erreichten Enterprise-Niveau. Google brachte Gemini mit Multimodalität.
Hätten wir uns an einen Provider gebunden, hätten wir die Plattform dreimal umbauen müssen. Stattdessen konnten wir neue Modelle innerhalb von Tagen integrieren.
Takeaway: Schaffe Abstraktionsschichten. Nicht weil es elegant ist, sondern weil sich AI-Modelle schneller verändern als jede andere Technologie, mit der wir je gearbeitet haben.
2. LLMs konnten 2023 keine Agents. Wir haben trotzdem welche entwickelt.
Als wir starteten, gab es keine nativen agentic Workflows in LLMs. Kein Tool Calling wie heute. Kein Function Calling, das zuverlässig funktionierte. Die Modelle konnten Text generieren, aber keine Systeme steuern.
Unser Team hat ein Custom Agent Framework entwickelt. Von Grund auf. Prompt Engineering, Retry-Logik, Tool-Orchestrierung, Fehlerbehandlung. Alles selbst.
Sechs Monate später brachte OpenAI Function Calling. Ein Jahr später hatte jeder Provider native Agents. Unser Framework war technisch überholt, bevor es alt wurde.
War das verschwendete Arbeit? Nein. Denn in diesen sechs Monaten hatten 120.000 Mitarbeiter bereits Zugang zu Agents. Unsere Kunden warteten nicht auf die Industrie.
Und das Know-how aus dem eigenen Framework hat uns geholfen, die nativen APIs besser zu nutzen. Schneller als Teams, die erst mit Function Calling angefangen haben.
Takeaway: Warte nicht auf die perfekte Technologie. Arbeite mit dem, was da ist.
Die Erfahrung ist wertvoller als die Abkürzung.
3. 1.500 AWS Accounts sind kein Infrastruktur-Problem. Sie sind ein Organisationsproblem.
Siemens betreibt über 1.500 AWS Accounts. Cross-Account-Zugriffe, unterschiedliche Security-Policies, Teams mit verschiedenen Compliance-Anforderungen. Technisch lösbar. Organisatorisch eine Herausforderung.
Die meisten Probleme, die wir lösen mussten, waren keine Code-Probleme. Es waren Governance-Probleme: Wer darf auf welche Daten zugreifen? Wie stellt man sicher,
dass ein AI Agent in Account A Daten aus Account B lesen darf, ohne Security-Policies zu verletzen? Wie deployt man Updates über Hunderte Accounts, ohne bestehende Workflows zu brechen?
Unsere Lösung: Infrastructure as Code mit CDK, Cross-Account-Rollen mit minimalen Berechtigungen, und ein Deployment-Pipeline, die jeden Account als eigenständige Einheit behandelt.
Kein Account vertraut einem anderen blind.
Takeaway: Bei Enterprise-Skalierung sind 80 % der Herausforderungen organisatorisch, nicht technisch. Plane dafür.
4. No-Code Agent Builder funktioniert.
Wir waren skeptisch. Können Mitarbeiter ohne technisches Know-how wirklich nützliche AI Agents erstellen? Werden die Agents qualitativ ausreichen? Wird der Support-Aufwand die Produktivitätsgewinne auffressen?
Die Antwort nach 10.000+ erstellten Agents: Ja, es funktioniert. Und zwar besser als erwartet.
Die besten Agents kommen nicht von uns. Sie kommen von Fachabteilungen, die ihre Prozesse besser kennen als jedes Consulting-Team. HR erstellt Onboarding-Agents.
Finance erstellt Reporting-Agents. Engineering erstellt Code-Review-Agents. Jeder mit Domain-Wissen und einem klaren Problem.
Der Trick: Die Plattform muss die Komplexität abstrahieren, ohne die Mächtigkeit zu verlieren. Guardrails statt Einschränkungen. Templates statt leere Seiten.
Monitoring statt Vertrauen.
Takeaway: Die wertvollsten AI-Anwendungen werden nicht von AI-Experten erstellt, sondern von Domain-Experten mit den richtigen Werkzeugen.
5. Observability bei 50 Modellen ist ein eigenes Problem
Ab einer bestimmten Skalierung reicht Standard-Monitoring nicht mehr. 50 Modelle von fünf Providern, jedes mit eigenen Latenzprofilen, Rate Limits und Fehlermustern. Hunderttausende Nachrichten pro Tag. Tausende Agents, die von Fachabteilungen erstellt wurden.
Jeder Provider verhält sich anders bei Last. Claude wird langsamer, GPT gibt 429er zurück, Gemini hat andere Timeout-Muster. Wenn ein Provider degradiert, muss die Plattform das erkennen und Anfragen umrouten. Nicht nach Minuten. Nach Sekunden.
Wir haben Observability von Anfang an als Architekturkomponente behandelt. Jede Modellanfrage wird geloggt: Latenz, Token-Verbrauch, Fehlerrate, Kosten. Pro Modell, pro Agent, pro Nutzer. Das gibt uns ein Echtzeit-Bild der gesamten Plattform und die Grundlage für automatisches Failover zwischen Providern.
Takeaway: Bei einer Multi-Model-Plattform ist Observability kein Ops-Thema. Es ist ein Architektur-Thema. Wer 50 Modelle betreibt, braucht Monitoring, das die Unterschiede zwischen Providern versteht.
Was wir daraus gelernt haben
Drei Prinzipien, die heute unser Standard sind:
-
Observability von Tag 1. Monitoring ist heute Teil jeder Architektur von Anfang an. Nachträgliche Integration kostet immer mehr.
-
Standards vor Custom. Eigene Frameworks nur, wenn es keine Alternative gibt.
Und sobald native APIs verfügbar sind, migrieren. -
Forward-Deployed Engineering. Die besten Ergebnisse entstehen, wenn unsere Engineers direkt mit den Fachabteilungen arbeiten. Gemeinsam, am selben Problem.
Die eine Sache, die bleibt
50 AI-Modelle in Produktion haben mich eines gelehrt: Die Technologie verändert sich alle paar Monate. Was bleibt, ist die Fähigkeit, große, sichere, skalierbare Systeme zu entwickeln. Systems Engineering. Das ist unser Kern. AI ist das Werkzeug. Aber das Handwerk dahinter ist dasselbe wie vor 20 Jahren: Architektur, Entscheidungen, Verantwortung.
Wir denken in Möglichkeiten und machen sie real. Und das wird sich nicht ändern, egal welches Modell als nächstes kommt.
