Data- und AI-Berufe in der Schweiz 2026: Rollen, Skills und Einstieg

Eine Stelle verlangt Python, SQL, Cloud und «AI-Erfahrung». Dahinter kann ein Data Engineer für eine Bank, ein MLOps Engineer in einem Basler Life-Sciences-Unternehmen oder ein AI Engineer für einen RAG-Assistenten stehen. Bei Data- und AI-Berufen in der Schweiz ist deshalb weniger der Titel entscheidend als die Frage, an welcher Stelle der Daten- und AI-Wertschöpfung eine Rolle Verantwortung übernimmt.

Dieser Überblick richtet sich an Backend Developers, BI Analysts, Software Engineers sowie Berufseinsteigerinnen und Berufseinsteiger. Er ordnet die Rollen nach Arbeitsalltag, Stack und Verantwortungsbereich. Zwischen einem Dashboard, einer stabilen Streaming-Pipeline und einem produktiven LLM-Assistenten gibt es gemeinsame Grundlagen, aber unterschiedliche Risiken und Erfolgskriterien.

Schweizer Inserate verwenden oft dieselben Schlagwörter für unterschiedliche Aufgaben: Python, SQL, Databricks, Cloud und Machine Learning. Die Arbeit kann jedoch bei Quellsystemen beginnen, bei der Modellierung für Finance enden oder den Betrieb eines Modells in einer regulierten Umgebung umfassen. Eine Bank sucht mit «Data & AI Engineer» womöglich vor allem verlässliche Datenpipelines; ein Hochschul-Spin-off eher eine Person, die Sprachmodelle sinnvoll in ein Produkt integriert.

Drei Fragen helfen bei der Einordnung: Baut die Person Datenfundamente? Macht sie Daten für Analysen und Entscheidungen nutzbar? Oder entwickelt und betreibt sie Modelle beziehungsweise AI-Anwendungen? Data Engineer und Data Architect arbeiten stärker an den Fundamenten, Analytics Engineer und Data Scientist näher an Erkenntnissen. Machine Learning Engineer, MLOps/Platform Engineer und AI Engineer verbinden Modelle oder LLMs mit dem produktiven Einsatz.

Jobtitel werden klarer, wenn man sie auf der Wertschöpfungskette einordnet.

Data Engineers bauen die Leitungen und Speicher, durch die Daten verlässlich fliessen. Sie kümmern sich um Ingestion, Transformation, Orchestrierung, Datenqualität und häufig auch um Berechtigungen. Analytics Engineers formen Rohdaten zu nachvollziehbaren Datenprodukten für BI und Fachbereiche. Data Scientists untersuchen konkrete fachliche Fragen, testen statistische oder ML-basierte Ansätze und übersetzen Resultate in Entscheidungen.

Beim Machine Learning Engineer steht ein Modell oder eine Modellfamilie im Zentrum: Training, Serving, Performance und Integration in Software. MLOps- und Platform Engineers schaffen dagegen gemeinsame Betriebsprozesse, etwa reproduzierbare Deployments, Observability und Rechtekonzepte. AI Engineers mit LLM- oder RAG-Fokus bauen die Anwendung rund um ein Modell und arbeiten an Retrieval, Quellen, Evaluation, Guardrails und Nutzererlebnis.

Der Data Architect ist meist keine weitere Spezialistenrolle im Backlog, sondern arbeitet übergreifend. Er oder sie klärt Domänengrenzen, Integrationsmuster, Datenklassifikation, Sicherheitsprinzipien und die langfristige Plattformrichtung. In grossen Versicherungen, Behörden oder Life-Sciences-Organisationen gehört dazu viel Abstimmung. Gute Architektur sorgt dafür, dass Teams sensible Daten und Schnittstellen nicht jeweils neu erfinden.

SQL und Python sind in vielen Data- und AI-Rollen ein gemeinsamer Nenner. Hinzu kommen Git, Datenmodellierung, Tests, Cloud-Grundverständnis und die Fähigkeit, Begriffe mit Fachbereichen präzise zu klären. Tools wechseln, Konzepte bleiben: idempotente Pipelines, saubere Zugriffsmodelle, nachvollziehbare Datenqualität und reproduzierbare Deployments. Wer begründen kann, weshalb ein Ladejob sicher wiederholbar sein muss, zeigt mehr Praxisverständnis als mit einer langen Zertifikatsliste.

Kein Unternehmen setzt exakt diesen Stack ein. Databricks kann Snowflake ersetzen, Prefect kann Airflow ersetzen, und eine Cloud-eigene AI-Plattform kann einen Teil der MLOps-Aufgaben abdecken. Im Interview ist daher weniger der Toolname entscheidend als das zugrunde liegende Problem: Wie erkennen Sie Schemaänderungen? Wie testen Sie eine Kennzahl? Wie messen Sie, ob eine RAG-Antwort korrekt und sicher genug ist?

css
App-Event -> Kafka/API -> Raw Storage
        -> getestete Transformation (SQL/dbt) -> Metrikenschicht
        -> kuratierte Dokumente -> Embeddings/Vector Store -> RAG-Antwort mit Quellen
​
Landkarte, keine Bauanleitung: Jede Stufe braucht Ownership, Tests und Zugriffsregeln.

Ein Data Engineer beginnt den Morgen vielleicht mit einem fehlgeschlagenen nächtlichen Ladejob. Die zentrale Frage ist dann nicht nur, wie sich der Fehler beheben lässt, sondern ob ein Quellsystem sein Schema geändert hat und welche nachgelagerten Modelle betroffen sind. Ein Analytics Engineer klärt mit Finance, was ein «aktives Kundenkonto» genau bedeutet, bevor diese Definition als getestete Metrik veröffentlicht wird. Ein Data Scientist prüft, ob ein Prognosemodell eine operative Entscheidung verbessert oder bloss auf historischen Daten gut aussieht.

Beim ML Engineer kann ein Release wegen erhöhter Latenz zurückgerollt werden. Ein MLOps Engineer baut vielleicht ein Self-Service-Template, damit weitere Teams Modelle mit einheitlichem Monitoring ausliefern können. Der AI Engineer testet parallel einen RAG-Assistenten auf internen Dokumenten: Zitiert er die passende Quelle, verweigert er unzulässige Anfragen und wie verhält er sich bei fehlendem Kontext? Programmieren ist zentral, ebenso gehören Abstimmungen mit Product Ownern, Security, Data Owners und Fachbereichen zum Alltag.

Technik allein genügt nicht: Für einen verantwortbaren Betrieb muss klar sein, welche Daten verwendet werden, wer darauf zugreifen darf und wer die Verantwortung trägt. Diese Fragen betreffen Datenmodelle, Berechtigungen, Monitoring und die Übergabe an den Betrieb gleichermassen.

Der Data Architect entscheidet selten isoliert über ein Kästchen im Diagramm. Bei einer neuen Plattformfrage moderiert er oder sie etwa den Konflikt zwischen schneller Produktentwicklung, Datenresidenz, Kosten und Sicherheitsvorgaben. Die Datenklassifikation beeinflusst später Logging, Testdaten, Schnittstellen und die Auswahl eines LLM-Anbieters. Frühe Architekturentscheide prägen den Alltag der Delivery-Teams oft stärker als das nächste Framework.

Basel ist mit Pharma und Life Sciences ein wichtiger Markt für Datenplattformen, Governance, Forschung und dokumentierbare Prozesse. Zürich bietet eine breite Mischung aus Banken, Versicherungen, Technologie- und Dienstleistungsunternehmen. Retail und Industrie benötigen Datenkompetenz etwa für Supply Chain, Kundendaten und Automatisierung. Bern verbindet Bundesnähe, öffentliche Hand, Versicherungen und etablierte IT-Organisationen; Genf und Lausanne ergänzen dies mit internationalen Organisationen, Finanz- und Dienstleistungsumfeldern sowie Forschung und Spin-offs rund um die EPFL.

Für belastbare Lohnbandbreiten nach Rolle, Seniorität und Standort fehlen in diesem Auftrag überprüfbare aktuelle Quellen. Pauschale Jahreslöhne für Zürich, Basel, Genf, Lausanne oder Bern wären deshalb nicht seriös. Vergleichen Sie konkrete Angebote stets nach Basislohn in CHF, Bonus, Pensum, Führungsanteil, On-Call, Sprache und branchenspezifischer Verantwortung.

Ein höheres Gehalt ist nicht automatisch die passendere Rolle. In regulierten Branchen können Plattformverantwortung, Domänenwissen und nachweisbare Produktionsreife stärker zählen als ein einzelnes Framework. Für einen Data Engineer macht es einen Unterschied, ob nur Transformationen entstehen oder ob die Rolle auch kritische Schnittstellen, On-Call und Governance verantwortet. Wer Angebote vergleicht, sollte Auftrag, Lernkurve, Teamreife und variable Vergütung gemeinsam betrachten.

Das Schweizer Datenschutzgesetz prägt praktische Entscheidungen rund um Zweckbindung, Verhältnismässigkeit, Transparenz und Datensicherheit. Besonders schützenswerte Personendaten verlangen erhöhte Sorgfalt. Für Teams heisst das: Logs nicht gedankenlos mit Personenbezug füllen, Testdaten kontrolliert behandeln, Aufbewahrungsfristen definieren und Berechtigungen nach Datenklassifikation umsetzen. Das ist keine Rechtsberatung, aber konkrete Engineering-Arbeit.

Der EU AI Act gilt nicht allein deshalb, weil ein Unternehmen in der Schweiz sitzt. Schweizer Anbieter und Unternehmen mit Bezug zum EU-Markt können jedoch in seinen Anwendungsbereich fallen, etwa wenn sie AI-Systeme in der EU bereitstellen oder deren Output dort verwendet wird. Risikoanalyse, Dokumentation, menschliche Aufsicht und weitere Pflichten werden damit zu Produkt- und Betriebsfragen. Security, Datenschutz und Legal früh einzubeziehen, verhindert spätere Umbauten.

Bei Sovereign Cloud und Datenresidenz lautet die praktische Frage: Darf ein Team Kundenunterlagen an einen externen LLM-Dienst übermitteln, in welcher Region findet die Verarbeitung statt, wer hat administrative Zugriffe und welche Verträge sowie Kontrollen gelten? Das beeinflusst Architektur, Verschlüsselung, Schlüsselverwaltung, Retrieval-Design, Monitoring und Incident-Prozesse. Konkrete Einzelfälle gehören mit internen oder externen Fachstellen geklärt.

Der Wechsel vom Backend Developer zum Data Engineer ist oft näher, als es klingt. Vertiefen Sie SQL und Datenmodellierung, überführen Sie eine API- oder Event-Quelle in eine getestete Pipeline und lernen Sie Orchestrierung sowie Cloud-IAM. Machen Sie Datenqualität sichtbar, etwa mit Schema-Tests und einem klaren Verhalten bei fehlerhaften Events. So wird aus «ich kann Python» ein nachvollziehbarer Produktionsnachweis.

Für BI Analysts führt ein realistischer Weg zum Analytics Engineer über Git, dbt, semantische Modelle, Tests und Review-Prozesse. Behandeln Sie ein Dashboard als versioniertes Datenprodukt: Woher kommt jede Metrik, wer ist Data Owner und welche Definition gilt? Weitere Übergänge sind möglich: Data Engineers können sich über Deployment und Monitoring in Richtung ML oder MLOps entwickeln, Data Scientists über Software Engineering in Richtung ML Engineering. Erfahrene Engineers wachsen mit Domänenmodellierung und Stakeholderführung in die Architektur.

Wo Unternehmen Datenfundamente, Governance, AI-Integration und zuverlässigen Betrieb verbinden müssen, bleiben breit aufgestellte Engineering-Profile besonders relevant. Standardisierte Reporting-, Prompting- oder Analyseaufgaben können stärker automatisiert werden, wenn Domänenwissen, Qualitätsverantwortung und Engineering-Anteil fehlen. Der sinnvollste nächste Schritt ist daher nicht der modischste Titel, sondern ein sichtbarer Nachweis: Sie können Daten und AI in einen sicheren, nachvollziehbaren Betrieb überführen.