Was ist AI Engineering?

Blogreihe »AI Engineering in der Praxis«

In den letzten zwei Jahren sind Large Language Models von Forschungs-Kuriositäten zur Grundlage einer völlig neuen Art des Systembaus geworden. Ob ChatGPT von OpenAI, Claude von Anthropic oder Gemini von Google: Die leistungsfähigsten Modelle sind heute per API verfügbar, und Unternehmen jeder Größe bauen darauf auf. Doch während die Modelle selbst immer besser werden, stellen wir in unserer Beratungspraxis fest, dass die meisten Teams noch keine Antwort auf die entscheidende Frage gefunden haben: Wer baut eigentlich die Systeme um diese Modelle herum, die in Produktion tatsächlich funktionieren?

AI Engineering: Mehr als MLOps, mehr als Prompt Engineering

AI Engineering ist kein neues Label für bekannte Disziplinen. MLOps ist um spezifische Probleme herum gewachsen: Modelle auf kuratierten Datensätzen trainieren, Versionen verwalten, Drift überwachen, Feature Pipelines bauen. Diese Probleme setzen voraus, dass das Modell einem selbst gehört. Man fine-tuned es. Man kontrolliert die Gewichte. AI Engineering startet von einem fundamental anderen Punkt: Die leistungsfähigsten Modelle greift man über APIs an. Man trainiert sie nicht. Man fine-tuned sie nicht. Stattdessen komponiert man mit ihnen, gibt ihnen Werkzeuge und baut Systeme um sie herum.

Der Unterschied ist nicht subtil. Wenn Sie ein Modell trainieren, verbringen Sie Wochen damit, Daten zu kuratieren und Loss-Kurven auszuwerten. Das Ergebnis ist deterministisch: gleicher Input, gleicher Output. Wenn Sie auf einem Frontier-Modell via API aufbauen, arbeiten Sie mit einer nicht-deterministischen Reasoning-Engine. Derselbe Prompt kann unterschiedliche Ergebnisse liefern. Das Modell kann eine Aufgabe verweigern, die es gestern noch erledigt hat, weil der Anbieter seine Safety-Filter aktualisiert hat. Ihr Job ist nicht, bessere Gewichte zu trainieren. Ihr Job ist, das Gerüst zu bauen, das eine unberechenbare Reasoning-Engine dazu bringt, in Produktion zuverlässig zu funktionieren.

Genauso wenig ist AI Engineering dasselbe wie Prompt Engineering. Prompt Engineering, das sorgfältige Formulieren von Anweisungen, um bessere Ergebnisse aus einem Modell zu bekommen, ist eine einzige Fähigkeit innerhalb der breiteren Disziplin. Es wäre, als würde man Softwareentwicklung auf »Code formatieren« reduzieren. Die eigentliche Arbeit passiert in den Schichten um das Modell herum:

- Retrieval-Augmented Generation (RAG): Modelle mit proprietärem Wissen verbinden, ohne sie neu trainieren zu müssen.
- Tool Calling und Agent-Architekturen: Modelle befähigen, Datenbanken abzufragen, APIs aufzurufen und E-Mails zu versenden.
- Evaluierungs-Frameworks: Die Qualität von Modell-Outputs systematisch messen, nicht nur deren Existenz prüfen.
- Safety Guardrails: Verhindern, dass Modelle schädliche oder unerwünschte Antworten ausliefern.
- Kostenoptimierung und Latenz-Management: API-Kosten senken, Fallback-Modelle vorhalten, Prompt-Versionierung betreiben.

Die fünf Kernaktivitäten eines AI Engineers

Aus unserer Projektarbeit bei WB-Tech haben sich fünf Kernaktivitäten herauskristallisiert, die das Berufsbild des AI Engineers definieren. Keine davon existierte in dieser Form vor fünf Jahren.

1. Systemdesign um probabilistische Komponenten herum. Klassische Softwareentwicklung geht von vorhersagbarem Verhalten aus. Eine Funktion liefert bei gleichen Eingaben das gleiche Ergebnis. Ein API-Endpunkt antwortet oder wirft einen Fehler. AI Engineers entwerfen Systeme, in denen die zentrale Reasoning-Komponente inhärent probabilistisch ist. Sie bauen Evaluierungs-Frameworks, die die Qualität von Outputs beurteilen können. Sie entwickeln Fallback-Pfade für den Fall, dass das Modell halluziniert. Sie gestalten User Experiences, die anmutig mit Unsicherheit umgehen.

2. Modelle mit der realen Welt verbinden. Ein Sprachmodell, das isoliert vor sich hin denkt, ist interessant. Ein Sprachmodell, das eine SAP-Datenbank abfragen, interne APIs einer Fertigungsanlage aufrufen, technische Dokumentation lesen und Service-Mitarbeitern Handlungsempfehlungen geben kann, ist transformativ. AI Engineers entscheiden, welche Tools ein Modell bekommt und wie mehrere Aufrufe, möglicherweise über verschiedene Modelle hinweg, zu kohärenten Workflows orchestriert werden.

3. Retrieval und Grounding. RAG ist zum Standardmuster geworden, um Modellen Zugriff auf proprietäres Wissen zu geben. Unsere Erfahrung zeigt: Die meisten Teams unterschätzen dramatisch, wie schwer es ist, das gut zu machen. Die richtige Chunking-Strategie für Dokumente wählen, ein Embedding-Modell auswählen, Retrieval-Parameter tunen, multimodale Inhalte handhaben, Indizes aktuell halten. Jede dieser Entscheidungen multipliziert sich. Eine schlampige RAG-Implementierung liefert schlechtere Ergebnisse als gar kein RAG, weil sie dem Modell irrelevanten Kontext zuführt, der es verwirrt.

4. Evaluierung. Das ist der schwierigste Teil von AI Engineering und der, den die meisten Teams überspringen. In klassischer Software schreibt man Unit Tests: Input X produziert Output Y. Bei LLMs muss man beurteilen, ob eine Antwort »gut genug« ist: faktisch korrekt, angemessen detailliert, gut strukturiert, sicher. Das erfordert eine Kombination aus automatisierten Metriken, bei denen andere LLMs als Richter fungieren, menschlicher Evaluierung zur Kalibrierung und sorgfältigem Tracking von Edge Cases. Wir haben Teams gesehen, die KI-Features ohne Evaluierungs-Pipeline auslieferten und dann überrascht waren, als die Qualität nach einem Modell-Update einbrach. Evaluierungs-Infrastruktur zu bauen ist nicht optional. Es ist die Grundvoraussetzung.

5. Operatives Management. Wenn Sie von Third-Party-Modellen abhängen, erben Sie deren Rate Limits, deren Preisänderungen, deren Deprecation-Pläne, deren Verfügbarkeitsprobleme. Ein AI Engineer denkt über Caching-Strategien nach, um API-Kosten zu senken, über Fallback-Modelle, wenn der primäre Anbieter ausfällt, und über Latenz-Budgets, die Netzwerk-Roundtrips plus Inferenzzeit berücksichtigen. Nichts davon ist glamourös. Alles davon entscheidet darüber, ob ein KI-System in Produktion funktioniert oder nur in einer Demo.

Das Modell ist eine Commodity

Die vielleicht wichtigste Erkenntnis aus unserer Arbeit: Bei AI Engineering geht es nicht um das Modell. Das Modell ist eine Commodity. Jeder hat Zugriff auf dasselbe GPT-4, denselben Claude, dasselbe Gemini. Die Differenzierung, also das, worüber sich entscheidet, ob ein KI-Produkt tatsächlich Wert liefert, steckt in allem um das Modell herum.

Der Vergleich mit der Frühzeit des Webs drängt sich auf. Anfangs konkurrierten Unternehmen darum, wer überhaupt eine Website hatte. Dann, sehr schnell, war eine Website zu haben die Grundvoraussetzung, und die Gewinner waren diejenigen, die die beste Erfahrung drumherum bauten: bessere Suche, bessere Personalisierung, bessere Checkout-Flows. Wir sind heute im selben Übergang mit KI. Vor zwölf Monaten war es noch bemerkenswert, einfach ein KI-Feature auszuliefern. Heute wird das erwartet. Was Gewinner vom Rest unterscheidet, ist die Qualität des Engineerings um diese Features herum: Zuverlässigkeit, Genauigkeit, Latenz, Kosteneffizienz, Sicherheit.

Das bedeutet: AI Engineering wird in den nächsten fünf Jahren zu einer der wertvollsten Rollen in der Softwareentwicklung. Unternehmen stellen zunehmend fest, dass es ein schlechter Fit ist, ML-Forscher für den Bau von produktiven KI-Systemen einzustellen. Forscher wollen die Grenzen dessen verschieben, was Modelle können. AI Engineers wollen die bestehenden Modellfähigkeiten zuverlässig in großem Maßstab zum Laufen bringen. Das sind unterschiedliche Denkweisen, unterschiedliche Skillsets, unterschiedliche Karrierepfade.

»Das Modell ist eine Commodity. Die Differenzierung, also das, worüber sich entscheidet, ob ein KI-Produkt tatsächlich Wert liefert, steckt in allem um das Modell herum.«

Wie verankert man AI Engineering in der Organisation?

In vielen Unternehmen beobachten wir derzeit dasselbe Muster: KI-Features werden gleichzeitig von drei verschiedenen Teams mit drei verschiedenen Ansätzen gebaut, ohne gemeinsame Infrastruktur, ohne gemeinsame Evaluierungsstandards, und niemand ist für die langfristige Zuverlässigkeit verantwortlich. Das ist keine Strategie, sondern schlicht Chaos.

Die Teams, die wir erfolgreich begleitet haben, schaffen eine dedizierte AI-Engineering-Funktion, die zwischen Forschungs- und Anwendungsteams sitzt. Diese Gruppe besitzt die grundlegende Infrastruktur: Evaluierungs-Frameworks, RAG-Pipelines, Agent-Architekturen und Guardrail-Systeme. Sie stellt diese den Produktteams als interne Plattform zur Verfügung. Die Produktteams komponieren diese Fähigkeiten dann zu Features, so wie sie heute Datenbankzugriffe oder Authentifizierungsdienste komponieren.

Muss ich dafür AI Engineer werden?

Die Frage hören wir häufig von einzelnen Entwicklern. Unsere Antwort: Sie müssen sich nicht zwischen einem »normalen« Softwareentwickler und einem AI Engineer entscheiden. Die Grenze verschwimmt. In den nächsten Jahren werden die meisten Backend- und Full-Stack-Entwickler AI-Engineering-Fähigkeiten in ihre Arbeit integrieren, so wie die meisten Entwickler heute Datenbanken und APIs verstehen. Flüssigkeit im Umgang mit LLMs, RAG und Agent-Architekturen wird so fundamental werden wie das Verständnis von SQL oder HTTP.

Wer sich spezialisieren möchte, sollte sich auf Folgendes konzentrieren:

- Systematisch evaluieren: Lernen Sie, Modell-Outputs systematisch zu bewerten, nicht nur durch Anschauen einiger Beispiele. Bauen Sie Evaluierungs-Pipelines mit klaren Metriken.
- RAG von Grund auf verstehen: Bauen Sie eine Retrieval-Pipeline und entdecken Sie aus erster Hand, warum naive Implementierungen in Produktion scheitern.
- Agent-Architekturen experimentell erkunden: Geben Sie einem Modell Tools, lassen Sie es planen, und entwickeln Sie Strategien für den Fall, dass der Plan schiefgeht.
- Operative Exzellenz aufbauen: Investieren Sie Zeit in Caching, Fallbacks, Kosten-Tracking. Das unterscheidet AI Engineers von Entwicklern, die einfach eine LLM-API aufrufen können.

Ausblick: Die Muster sind noch nicht festgelegt

Das Feld bewegt sich schnell. Die Tools, von LangChain über LlamaIndex bis CrewAI, entwickeln sich wöchentlich weiter. Was heute als Best Practice gilt, kann in sechs Monaten überholt sein. Das kann destabilisierend wirken. Wir sehen es als Chance: Die Muster sind noch nicht festgelegt, und die Teams, die heute bauen, sind diejenigen, die definieren werden, wie diese Disziplin im nächsten Jahrzehnt funktioniert.

Kurz gesagt: AI Engineering ist keine Modeerscheinung und kein Hype. Es ist die Professionalisierung dessen, was bisher jeder irgendwie nebenbei gemacht hat. Mit den richtigen Strukturen, Werkzeugen und Evaluierungsstandards wird aus dem Experiment eine Ingenieursdisziplin.

In unserem nächsten Blogbeitrag gehen wir näher darauf ein, wie sich der ROI von AI-Engineering-Investitionen messen lässt.

Haben Sie Fragen zum Aufbau von AI Engineering in Ihrem Unternehmen? Lassen Sie uns gemeinsam herausfinden, wie Sie Ihre KI-Systeme zuverlässig und skalierbar machen können. Sprechen Sie uns an.