13. Juni 2026

Architekt, aber hands-on: Was ein AI Solutions Architect wirklich macht

Viele fragen, was ein “AI Solutions Architect” eigentlich den ganzen Tag macht. Verständliche Frage — der Titel taucht inzwischen überall auf und bedeutet für sich allein fast nichts.

Also die konkrete Version: die Arbeit selbst, nicht das Organigramm dahinter.

Es beginnt mit einem Workflow, nicht mit einem Modell

Die Arbeit beginnt nie mit “welches Modell?”. Sie beginnt mit einem realen Prozess, der langsam, teuer oder fehleranfällig ist: ein Dokument, das zu lange gesucht wird, eine Anfrage, die zwischen drei Systemen hin und her springt, eine Entscheidung, die auf jemanden wartet, der gerade keine Zeit hat.

Das Modell ist eine der letzten Entscheidungen, nicht die erste.

Dann kommt die wichtigste Entscheidung: bauen, kaufen oder integrieren

Vor der ersten Codezeile steht die eigentliche Frage: Sollten wir das überhaupt bauen?

Die meisten AI-Fähigkeiten sind inzwischen Commodity. Das Modell, die Plattform, die Infrastruktur: vieles kauft man. Ein guter Architekt sagt öfter “das kaufen wir” als “das bauen wir selbst”. Genau darin liegt Glaubwürdigkeit. Ein eigenes Modell oder eine eigene Foundation zu bauen ist fast immer der teure Fehler.

Warum also überhaupt bauen?

Weil der entscheidende Teil meistens der ist, den kein Vendor verkauft: die Integration in Legacy-Systeme, Datengrenzen und regulierte Workflows. Das Muster, das funktioniert: buy the engine, build the integration. Modell und Plattform kaufen, aber nur die dünne, differenzierende Schicht bauen, die beides passend macht.

In regulierten Umfeldern endet “buy” oft genau dort: Das fertige Produkt erfüllt eine Data-Residency- oder Compliance-Anforderung nicht. Dann baut man den Teil, der diese Grenze einhalten kann — und nichts mehr.

Grenzen ziehen — vor allem Datengrenzen

In einem regulierten Umfeld ist das die halbe Arbeit. Welche Daten darf das System sehen? Wo dürfen sie liegen? Wer darf das Ergebnis lesen? Was wird geloggt? Was verlässt nie das Haus?

Das sind keine Features, die man später anschraubt. Das sind Designbedingungen. Sie prägen die Architektur oft stärker als jeder Modell-Benchmark.

Proof bauen, MVP liefern — im Code

Hier trennt sich die Rolle von den Rollen darüber. Der Architekt übergibt nicht ein Diagramm an ein Team und verschwindet. Man baut den Proof of Concept selbst, liefert die erste reale Version, bleibt im Code.

Groß genug im Denken, um das ganze System zu sehen. Nah genug an der Umsetzung, um es real werden zu lassen.

Mit der Realität integrieren, die wirklich da ist

Die Demo funktioniert mit sauberen Daten. Produktion hat SSO, zwanzig Jahre alte Dokumentenablagen, halb dokumentierte APIs und ein Operations-Team mit starken und berechtigten Meinungen.

Der größte Teil der Engineering-Arbeit liegt hier: das System in der Organisation zum Laufen bringen, die es wirklich gibt — nicht in der Organisation auf der Folie.

Über den Piloten hinauskommen

Ein System, das niemand nutzt, ist ein gescheitertes System, egal wie elegant es gebaut ist.

Die letzte Strecke ist Adoption: Enablement, Messung, Support und die wenig glamouröse Übergabe an diejenigen, die es nachher betreiben. Produktion ist nicht die Demo, die einmal funktioniert hat. Produktion ist das System, das noch läuft, wenn man den Raum verlassen hat.

Warum der Titel alle verwirrt

Das ist die Arbeit. Schwierig zu besetzen ist sie, weil der Titel in einem Cluster von Rollen liegt, die von außen fast gleich klingen.

Eine Bekannte aus der Chemie hat es einmal gut beschrieben: In ihrem Feld weiß jeder sofort, ob jemand organische, anorganische oder medizinische Chemie macht. In der IT klingen Enterprise Architect, Solutions Architect, AI Architect und Staff Engineer für Außenstehende wie ein Job.

Sind sie nicht. Aber der Unterschied ist situativ, keine Rangordnung.

Ein Enterprise Architect arbeitet eine Ebene höher: Landschaft, Standards, Zielbild, Governance — genau das, was man braucht, wenn es viel zu verbinden und zu steuern gibt.

Ein Solutions Architect arbeitet eine Ebene näher am konkreten System: ein Use Case wird bis zu einem laufenden System getragen, hands-on, mit Code-Nähe. Eine Organisation, die das System noch nicht gebaut hat, braucht meistens zuerst diese zweite Rolle — schreibt aber oft die Stellenbeschreibung für die erste, oder mischt beides und findet niemanden.

Beides sind echte Rollen, die zu unterschiedlichen Zeitpunkten unterschiedliche Probleme lösen. Der Fehler ist nicht, die eine oder andere zu wählen. Der Fehler ist, nicht zu wissen, in welchem Moment man gerade ist.

Der unterschätzte Teil: Wer baut es wirklich?

Eine Vision und ein Deck sind kein System. Die ehrliche Frage ist nicht “wie groß muss das Team sein”, sondern ob jemand tatsächlich mandatiert und ausgestattet ist, das System zu bauen.

Es beginnt beim Architekten: Ein hands-on Architect bleibt nah genug an der Umsetzung, damit sich das Design an der Realität weiterentwickelt. Darauf aufbauend ist die Grundlage bewusst klein: ein enger Kern starker Engineers, zunehmend verstärkt durch AI Agents, die Arbeit übernehmen, für die früher zusätzliche Hände nötig waren. Das Team, das ein Produktionssystem ausliefert, wird kleiner, nicht größer.

Aber die Grenze, an der Architekturen wirklich scheitern, ist selten Headcount. Es ist Mandat. Eine Architektur, die niemand bauen darf und für die niemand ausgestattet ist, bleibt ein Diagramm — egal wie viele Menschen nominell verfügbar sind.

Wenn Sie einstellen

Starten Sie nicht mit der Stellenanzeige. Starten Sie mit zwei Fragen:

1. Was genau können wir heute nicht? Nicht “wir wollen AI”, sondern die konkrete Lücke.
2. Welche Rolle schließt diese Lücke — und gibt es die Grundlage dafür schon?

Wenn die ehrliche Antwort lautet: “Ideen ja, aber nichts in Produktion”, brauchen Sie sehr wahrscheinlich einen hands-on Solutions Architect mit einem kleinen Engineering-Kern — keine Strategieschicht auf einem leeren Stack.

Wenn diese Unterscheidung stimmt, wird der Titel zweitrangig: Aus einem Workflow wird eine Architektur, aus der Architektur ein System, das Menschen wirklich nutzen.