Die Rolle taucht in Ausschreibungen erst seit wenigen Jahren auf und wird oft mit anderen verwechselt. Kurz gesagt: Ein AI Platform Engineer baut nicht die Modelle, sondern das, worauf die Modelle laufen. In einer Beratung tut er das nicht einmal, sondern immer wieder - bei verschiedenen Kunden, unter verschiedenen Bedingungen, mit demselben Kern an Fragen.
Was ein AI Platform Engineer baut
Wenn in einem Unternehmen drei Teams mit KI arbeiten, hat jedes davon dieselben Bedürfnisse: Zugang zu Modellen, Rechenkapazität, einen Weg, etwas in Betrieb zu nehmen, und die Gewissheit, dass es hinterher noch läuft. Wenn jedes Team das für sich löst, entstehen drei unterschiedliche Lösungen, drei Rechnungen und drei Sicherheitslücken. Die Plattform ist der Versuch, das einmal zu bauen und allen zur Verfügung zu stellen.
Konkret geht es um sechs Bereiche.
Zugriff auf Modelle. Ein einheitlicher Weg, über den Teams Modelle ansprechen - eingekaufte ebenso wie selbst betriebene. Dahinter steckt weniger Zauberei als Verwaltung: Schlüssel, Kontingente, Fehlerbehandlung, ein Wechsel des Anbieters ohne Umbau in jeder Anwendung.
Rechenressourcen. Wer bekommt wie viele Grafikkarten, wie lange, und was passiert mit Aufträgen, die warten müssen. In Häusern mit knapper Hardware ist das der Teil, an dem sich der Nutzen einer Plattform zuerst zeigt.
Deployment-Wege. Wie kommt ein Modell oder ein Dienst von der Entwicklungsumgebung in den Betrieb, reproduzierbar und ohne dass jemand von Hand etwas auf einen Server kopiert.
Überwachung. Läuft es, wie schnell antwortet es, wie oft schlägt es fehl. Bei KI-Diensten kommen Größen dazu, die klassische Anwendungen nicht kennen: Antwortlängen, Abbruchquoten, auffällige Eingabemuster.
Kosten. Modellaufrufe kosten pro Anfrage, Rechenzeit kostet pro Stunde. Ohne Zuordnung zu Teams und Projekten weiß am Monatsende niemand, wofür die Rechnung entstanden ist. Kostentransparenz ist ein Plattformthema, kein Buchhaltungsthema.
Rechte und Protokollierung. Wer darf welches Modell mit welchen Daten benutzen, und lässt sich das im Nachhinein belegen. Dieser Punkt ist in regulierten Branchen der Grund, warum eine Plattform überhaupt gebaut wird.
Der Unterschied zu MLOps und zum klassischen Plattform-Engineering
Die drei Rollen überschneiden sich und werden in kleinen Häusern von derselben Person ausgefüllt. Trotzdem lohnt es, den Unterschied zu kennen, weil er in Ausschreibungen den Ausschlag gibt.
| Womit befasst | Typische Frage | |
|---|---|---|
| Plattform-Engineering | allgemeine Infrastruktur für Entwicklungsteams | Wie kommt Software zuverlässig in Betrieb? |
| MLOps | Lebenszyklus einzelner Modelle | Wie wird dieses Modell trainiert, versioniert, abgelöst? |
| AI Platform Engineering | gemeinsame Grundlage für viele KI-Anwendungen | Wie können zehn Teams sicher und bezahlbar Modelle nutzen? |
Vereinfacht: Der MLOps Engineer denkt vom Modell aus, der Plattform-Engineer vom Nutzer der Plattform aus. Ein Modell in Betrieb zu nehmen ist eine MLOps-Aufgabe. Dafür zu sorgen, dass jedes Team im Haus das ohne Rückfrage selbst kann, ist eine Plattform-Aufgabe. Die vollständige Beschreibung des Berufsbilds findest du auf der Seite zum KI-Plattform-Engineer, verwandte Rollen im Berufsfeld KI-Engineering und Betrieb.
Warum Beratungen dieses Profil suchen
Der Grund ist unspektakulär: Beratungen bauen dieselbe Grundlage bei vielen Kunden. Jedes Haus, das anfängt, KI ernsthaft einzusetzen, stößt auf dieselben sechs Fragen von oben - und die wenigsten haben intern Leute, die das schon einmal gemacht haben. Genau daraus entsteht das Geschäft.
Für dich hat das zwei Folgen. Die angenehme: Du siehst in zwei Jahren mehr unterschiedliche Umgebungen als in fünf Jahren im selben Unternehmen. Die unangenehme: Du baust selten etwas zu Ende. Projekte enden mit der Übergabe, und ob das, was du gebaut hast, ein Jahr später noch benutzt wird, erfährst du oft nicht.
Welche Art von Haus sucht solche Profile?
Große Wirtschaftsprüfungs- und Strategiehäuser mit eigenen Technologiebereichen. Dort ist die Nähe zu Regulierung, Revision und Nachweispflichten groß - Rechte und Protokollierung wiegen entsprechend schwer.
IT-Beratungen und Systemhäuser. Hier ist die Arbeit am handfestesten: Es wird gebaut, betrieben und häufig auch übergeben. Für den Einstieg oft die zugänglichste Variante, weil die technische Ausbildung im Haus geregelt ist.
Cloud-Partner. Häuser, die eng an einem der großen Anbieter arbeiten. Du lernst eine Umgebung sehr tief statt drei oberflächlich. Das ist ein Vorteil, solange du weißt, dass du dich damit ein Stück festlegst.
Spezialisierte KI-Boutiquen. Kleine Teams, oft aus dem Forschungs- oder Gründungsumfeld. Mehr Verantwortung früher, weniger Struktur, schwankende Auslastung.
Welche Häuser gerade tatsächlich ausschreiben und unter welchem Titel, ändert sich zu schnell für einen Ratgebertext. Ein Blick in die Übersicht der ausgeschriebenen KI-Praktika ist dafür der bessere Weg als jede Liste. Wie Beratungsprojekte im Alltag ablaufen, beschreibt der Beitrag zum Data-Science-Praktikum in der Beratung - Taktung und Kundenkontakt sind dieselben, unabhängig von der Rolle.
Wie der Berufseinstieg dort abläuft
Der übliche Weg führt über ein Praktikum oder eine Werkstudentenstelle in ein Einstiegsprogramm. Beratungen stellen in Jahrgängen ein, mit fester Einarbeitung und einer Zuordnung zu einem Bereich. In den ersten Monaten arbeitest du zu, oft an klar abgegrenzten Teilen: eine Automatisierung, ein Überwachungsdashboard, die Dokumentation einer Umgebung. Verantwortung für einen Plattformbaustein bekommst du typischerweise nach sechs bis zwölf Monaten.
Was in dieser Zeit über deine Entwicklung entscheidet, ist selten die technische Tiefe. Es ist die Fähigkeit, in einer fremden Umgebung schnell zu verstehen, wie dort gearbeitet wird, und den eigenen Stand so zu berichten, dass niemand nachfragen muss. Das klingt weich und ist in einem Projektgeschäft die härteste Währung.
Im Auswahlgespräch wird entsprechend selten nach Modellarchitekturen gefragt. Häufiger sind Fragen, die eine Denkweise prüfen: Wie würdest du herausfinden, warum ein Dienst seit gestern langsamer antwortet? Was tust du, wenn ein Kunde eine Änderung direkt im Betrieb verlangt? Wie erklärst du jemandem ohne technischen Hintergrund, warum eine Umgebung zwei Wochen Vorlauf braucht? Auf solche Fragen gibt es keine auswendig gelernte Antwort, wohl aber erkennbar durchdachte und erkennbar unvorbereitete.
Rechne außerdem mit Reisetätigkeit, wechselnden Ansprechpartnern und Phasen, in denen du zwischen zwei Projekten hängst. Wer feste Abläufe braucht, ist in einem Produktteam besser aufgehoben - der Vergleich der drei Einstiegswege ins Unternehmen hilft bei dieser Entscheidung mehr als die Rollenbeschreibung.
Welche Kenntnisse zählen
Für den Einstieg wird kein fertiges Plattformwissen erwartet. Erwartet wird eine solide Grundlage in fünf Bereichen.
- Cloud. Mindestens eine der großen Umgebungen praktisch benutzt haben: Rechenleistung, Speicher, Netzwerkgrundlagen, Rechteverwaltung. Ein Anbieter reicht - das Denken überträgt sich.
- Container. Ein Abbild bauen, es lokal starten, verstehen, was in einer Orchestrierung passiert. Kein tiefes Kubernetes-Wissen, aber die Begriffe müssen sitzen.
- Infrastruktur als Code. Umgebungen aus Dateien erzeugen statt aus Klicks. Wer das einmal an einem eigenen Projekt gemacht hat, argumentiert im Gespräch anders als jemand, der es nur gelesen hat.
- CI/CD. Eine Pipeline, die testet und ausliefert. Auch hier reicht ein eigenes kleines Beispiel.
- Grundlagen des Modellbetriebs. Wie ein Modell hinter einer Schnittstelle bereitgestellt wird, warum Versionierung nötig ist, was bei Last passiert. Du musst kein Modell trainieren können, aber wissen, was du da betreibst.
Dazu kommt Programmierung, meist Python, und Umgang mit der Kommandozeile. Ein sichtbares Beispiel wiegt hier schwer: eine kleine Anwendung mit Modellanbindung, in Containern, per Pipeline ausgeliefert, mit einer README, die den Aufbau erklärt. Wie so ein Projekt aufgebaut sein sollte, steht im Leitfaden für Portfolioprojekte.
Wer aus der Datenrichtung kommt, hat einen kürzeren Weg als gedacht - viele Bausteine sind dieselben, wie der Beitrag zum Data Engineering als KI-Einstieg zeigt. Weitere Beiträge zu Berufseinstieg und Rollen findest du in der Kategorie Einstieg.
Die Antwort in drei Sätzen
Ein AI Platform Engineer in einer Beratung baut für Kunden die gemeinsame Grundlage, auf der deren KI-Anwendungen laufen: Modellzugang, Rechenressourcen, Auslieferung, Überwachung, Kosten, Rechte. Gesucht wird das Profil von großen Prüfungs- und Strategiehäusern, IT-Beratungen, Cloud-Partnern und kleinen KI-Spezialisten - überall dort, wo dieselbe Aufgabe bei vielen Kunden wiederkehrt. Für den Einstieg zählen Cloud, Container, Infrastruktur als Code, CI/CD und ein Grundverständnis vom Modellbetrieb, belegt an einem Projekt, das man dir zeigen lassen kann.
Bereit für den nächsten Schritt?
Setz dein Wissen direkt ein und finde einen freien KI-Praktikum in deiner Nähe – kostenlos und ohne Anmeldung.
KI-Praktika finden
