Live-Datensatz · Stand 10. Juni 2026

Der deutsche KI-Arbeitsmarkt, entschlüsselt.

Ein durchgängiges Datenprodukt, das tausende roher Stellenanzeigen in eine strukturierte Landkarte verwandelt: welche KI-Arbeit Unternehmen tatsächlich einkaufen, mit welchen Werkzeugen, für welche Anwendungsfälle, in welchen Teamstrukturen und mit welcher Nachfrage dahinter.

Eine Fallstudie aus Produkt-, Daten- und KI-Sicht von Jan (heyjan)
4.268
KI-/Tech-Stellenanzeigen
2.052
verschiedene Unternehmen
425
Städte in Deutschland
74
erfasste KI-Tools und Skills
3
Quellen, per ML dedupliziert
ai-verticals.dev · Live-Dashboard
ai-verticals.dev Dashboard: Anzeigentempo, Wachstum des Datensatzes und Live-Kennzahlen
Das laufende Produkt. 4.033 aktive Anzeigen über 1.982 Unternehmen und 416 Städte hinweg: Anzeigentempo, Wachstum des Datensatzes und ein Live-Feed neuer Stellen, dargestellt in einem Nuxt- und Three.js-Dashboard im Blueprint-Stil.
Die These

Eine Stellenanzeige ist ein Geständnis. In der Summe wird sie zur Strategie-Landkarte.

Jede KI-Stellenanzeige verrät leise die Wahrheit über die KI-Roadmap eines Unternehmens: auf welche Modelle es setzt, welche Probleme es lösen will, welche Werkzeuge seine Entwickler bereits produktiv einsetzen und wie es seine Leute organisiert, um zu liefern. Eine Anzeige ist eine Anekdote. Viertausend, dedupliziert und strukturiert, sind Marktwissen.

Personalsuche ist der ehrlichste Frühindikator, den ein Unternehmen aussendet. Pressemitteilungen zeigen Absichten; eine budgetierte, offene Stelle für einen „AI & LLM Integration Engineer (RAG, LangChain, Azure OpenAI)“ ist eine Festlegung. Niemand bezahlt Recruiter für Stellen, die gar nicht besetzt werden sollen. Dieses Projekt macht das Lesen dieses Signals systematisch.

Wir fragen Unternehmen nicht, was sie über KI denken. Wir lesen, wofür sie einstellen, und das über den gesamten deutschen Markt hinweg.

Das Rohmaterial ist unsauber: dieselbe Stelle erscheint bei LinkedIn, Xing und Glassdoor unter drei verschiedenen Titeln, Beschreibungen bestehen aus 3.700 Zeichen zweisprachiger Textbausteine, Werkzeuge stecken irgendwo im Fließtext. Die eigentliche Arbeit und der eigentliche Wert liegen in der Pipeline, die aus diesem Wirrwarr saubere, abfragbare und vergleichbare Fakten macht. Dieser Bericht zeigt diese Pipeline aus drei Blickwinkeln: Daten (wie wir sie erfassen und ihnen vertrauen), KI/ML (wie wir sie deduplizieren und strukturieren) und Produkt (wie wir sie beantwortbar machen).

3.920
Anzeigen tragen eine inhaltlich substanzielle Beschreibung (über 200 Zeichen), das qualitative Gold. Durchschnittliche Länge: 3.696 Zeichen.
5.547
Job-zu-Tool-Signale, vom LLM extrahiert. Sie zeigen, welche Technologien wo gefragt sind.
45 %
der Anzeigen nennen ein Gehalt (1.915 von 4.268), genug, um Vergütung nach Rolle und Stadt einzuordnen.
Der Nutzen

Ein Datensatz, vier wichtige Fragen beantwortet.

Dieselben strukturierten Daten sprechen sehr unterschiedliche Leser an. Jeder bekommt eine belegbare Antwort auf eine Frage, die sonst auf Vermutungen beruht.

FÜR KI-VERANTWORTLICHE

„Wie besetze und rüste ich mein KI-Team aus?“

Sehen Sie die Referenzarchitektur, für die der Markt einstellt (RAG, LangChain und Azure OpenAI auf Kubernetes), und vergleichen Sie Stack und Senioritätsverteilung Ihres Teams mit 4.000 aktuellen Stellen. Planen Sie Einstellungen auf Basis von Belegen statt von Hersteller-Folien.

FÜR PRODUKTMANAGER:INNEN

„Wohin entwickelt sich die KI-Nachfrage, und welcher Stack zählt?“

Verfolgen Sie die Verschiebung zu agentischer KI (334 Stellen), die Welle der No-Code-KI-Entwicklung (59) und welche Werkzeuge gemeinsam auftreten, damit Roadmap und Integrationen dem Trend vorausgehen statt hinterher.

FÜR GESCHÄFTSFÜHRUNG UND GRÜNDER:INNEN

„Worin investieren die anderen tatsächlich?“

Personalsuche ist das ehrlichste Signal für die Strategie der Wettbewerber. Sehen Sie, in welche Funktionen (Engineering gegenüber einem boomenden Beratungsmarkt) und in welche Städte das KI-Budget fließt, ein Frühindikator, den keine Pressemitteilung liefert.

FÜR ENTWICKLER:INNEN UND BEWERBER:INNEN

„Was sollte ich lernen, und was zahlt sich aus?“

Ordnen Sie Fähigkeiten nach echter Nachfrage, sehen Sie, welche Kombinationen mit Gehaltsangaben einhergehen, und finden Sie Regionen und Remote-Stellen, die passen. Karriereplanung auf Basis des gesamten Marktes.

Aus Datensicht

Eine verlässliche Tabelle, zusammengesetzt aus drei unzuverlässigen Quellen.

Der Datensatz ist eine einzige verlässliche Quelle in Postgres: jede Anzeige trägt ihre Herkunft, Audit-Zeitstempel, ein absolutes Veröffentlichungsdatum und ein Soft-Delete-Kennzeichen, damit eine an der Quelle entfernte Stelle ihre Historie behält, statt zu verschwinden.

Woher die Daten kommen

LinkedIn
2.125
Xing
1.411
Glassdoor
274
Quellenübergreifend zusammengeführt
458

Zahlen je Quelle nach der Deduplizierung. Der grüne Balken zeigt Anzeigen, die der ML-Matcher über zwei oder drei Plattformen hinweg zu einem einzigen Datensatz verschmolzen hat (z. B. linkedin+xing).

Was wir je Anzeige speichern

Ein normalisiertes Schema, für die Analyse gebaut, nicht nur für die Anzeige:

TitelUnternehmenStadt · Ort vollständige BeschreibungGehaltKarrierestufe Vertragsart · BrancheKategorie posted_date (absolut)first_seen / last_seen active (Soft-Delete)Quellenherkunft

Audit-Spalten beantworten „neue Stellen heute“ und „Stellen, die im letzten Scrape verschwunden sind“ ohne zusätzliche Buchführung. Das ist die Grundlage jeder späteren Trendauswertung.

4.033
derzeit aktive Anzeigen. 235 wurden als entfernt markiert (Soft-Delete), also behalten statt gelöscht.
~3 Wo.
gleitendes Fenster in diesem Stand; Anzeigen datiert vom 21. April bis 10. Juni 2026. Täglich per Cron aktualisiert.
1.426
Anzeigen erstmals in den letzten 7 Tagen gesehen. Der Datensatz ist ein laufender Feed, kein einmaliger Scrape.
Warum das ein Datenprodukt ist und keine Tabelle
Drei Scraper (LinkedIn, Xing, Glassdoor) speisen eine täglich per Cron laufende Pipeline. Jeder Schritt ist idempotent: ein erneuter Scrape derselben Stelle aktualisiert last_seen_at, statt sie zu duplizieren; eine entfernte Xing-Anzeige (HTTP 410) wird auf active=false gesetzt und behält Beschreibung und Anreicherung. Das Ergebnis ist ein Datensatz, dem man über die Zeit vertrauen kann. Genau das ist die Voraussetzung, um überhaupt etwas zu messen.
Aus KI-Sicht · Nachfragesignal

Wofür deutsche Unternehmen KI-Leute tatsächlich einstellen.

Ein LLM liest jede Beschreibung und extrahiert die konkret genannten Werkzeuge, Frameworks und Fähigkeiten. Dann zählen wir sie über den gesamten Markt. Das ist die wertvollste Sicht im Datensatz: der reale KI-Tech-Stack, sortiert nach Nachfrage.

Top 20 Werkzeuge und Fähigkeiten, nach Zahl der nachfragenden Anzeigen

Python
826
Generative AI
434
PyTorch
317
OpenAI
311
API-Integration
256
LangChain
228
Machine Learning
213
Kubernetes
174
Microsoft Azure
168
RAG
155
AI Agents
153
Docker
150
Agentic AI
123
Cloud-Plattformen
114
Agile
108
AWS
104
Hugging Face
98
MLOps
86
scikit-learn
79
MLflow
70

Lila Balken = das GenAI- und Agenten-Cluster. Python bleibt die universelle Grundlage, doch die Geschichte darunter hat sich verändert.

Die Verschiebung zu Agenten ist real und im Mainstream angekommen

334 Anzeigen

nennen mindestens eines von LangChain, RAG, AI Agents oder Agentic AI, also etwa jede zwölfte Stelle und im Engineering deutlich mehr. „Generative AI“ (434) und „OpenAI“ (311) liegen inzwischen vor Klassikern wie TensorFlow (47) und scikit-learn (79). Die Einstellungen in Deutschland haben sich vom Trainieren eigener Modelle hin zum Bauen von Produkten auf Foundation-Modellen verschoben.

Der leise Aufstieg der No-Code-KI-Entwicklung

59 Anzeigen

fragen Automatisierungswerkzeuge nach: n8n (48), Zapier (47), Make (43), dazu Microsoft Copilot (42), Power Platform (34) und Low-Code (34). Eine ganze Art von KI-Umsetzungsarbeit findet inzwischen außerhalb der klassischen Softwareentwicklung statt. Wer nur auf den bekannten ML-Stack schaut, übersieht sie.

Der lange Schwanz zeigt, wohin es geht

Jenseits der Top 20 zeigt die nächste Reihe die Breite echter Einsätze: Cloud, MLOps, Vision, BI und die namentlich genannten Foundation-Modelle:

Azure 81DevOps 66SQL 66ChatGPT 61TensorFlow 47Databricks 45Copilot 42Apache Spark 41OpenCV 39Google Cloud 39NLP 39Figma 37HubSpot 35Power Platform 34Midjourney 31Claude 27Power BI 25CUDA 20UiPath 19dbt 13BPMN 12

Jedes davon ist eine Co-occurrence-Kante im Knowledge Graph: Sie können fragen „welche Stellen verbinden RAG mit Azure?“ oder „wo taucht Databricks ohne MLflow auf?“ und bekommen die Antwort in einer einzigen Abfrage.

Die Marktstruktur

Wo die Nachfrage liegt: nach Funktion, Region und Senioritätsstufe.

KI-Arbeit nach Funktion

Engineering / Dev
1.633
Beratung
559
Data Science / ML
437
Vertrieb / Marketing
335
Forschung
289
Management
285
Training / Annotation
216
Produkt / Design
194
Data Engineering
105
Operations
83
Robotik / Hardware
53

Engineering dominiert, doch die Überraschung ist die Beratung (559): ein riesiger Markt nach dem Motto „hilf uns, KI zu verstehen“. Management und Produkt zusammen (479) zeigen, dass KI als Disziplin zum Führen besetzt wird, nicht nur zum Programmieren.

Die Geografie der deutschen KI

Berlin
599
Hamburg
316
München
308
Köln
198
Frankfurt a.M.
151
Stuttgart
148
Düsseldorf
126
Hannover
83
Nürnberg
82
Leipzig
81

Berlin ist mit fast dem Doppelten von Hamburg und München der klare Knotenpunkt. 951 Anzeigen (rund 22 %) erwähnen Remote-Arbeit, ein spürbarer Anteil, der die Geografie für Bewerber öffnet.

Senioritätsverteilung (sofern angegeben)

StufeAnzeigen
Berufserfahren390
Management349
Berufseinstieg251
Ausbildung / Praktikum85
Direktor:in / VP25
Geschäftsleitung20

394 KI-Stellen auf Führungsebene (Management, Direktor:in/VP und Geschäftsleitung). KI wird zunehmend als Disziplin zum Führen besetzt, nicht nur zum Bauen. (1.281 Anzeigen machen keine Angabe zur Stufe.)

Top KI-Teilsegmente: die Arbeit hinter der Arbeit

TeilsegmentStellen
Applied AI & Full Stack364
Generative AI & LLMs203
AI Strategy & Transformation136
MLOps & Platform93
Predictive Analytics & Statistics55
AI Product Management53
AI Sales46

Eine vollständig vom LLM entdeckte Taxonomie: 71 Teilsegmente über 14 Kategorien, keine handgepflegte Stichwortliste.

Wer am meisten einstellt

Eine Mischung aus Beratungen (der Boom der KI-Beratung), Konzernen (SAP, BMW, Siemens, IBM), Daten-Labeling-Plattformen und Recruitern, die Nachfrage bündeln:

Deloitte 79SAP 46adesso SE 41CHECK24 55Capgemini 22IBM 18BMW Group 17Siemens 16KPMG 15DataAnnotation 68Mindrift 30Mercor 19

Recruiting-Aggregatoren (etwa Jobriver, Instaffo) führen die reinen Zahlen an; die Sicht auf namentliche Arbeitgeber oben ist für Entscheidungen aussagekräftiger.

Aus Produktsicht

Von der Datenbank zu etwas, das ein Mensch befragen kann.

Saubere Daten sind nötig, aber für sich genommen träge. Die Produktebene macht daraus drei Zugänge, jeweils auf einen anderen Nutzer zugeschnitten.

ERKUNDEN

Interaktives Dashboard

Ein Frontend mit Nuxt 4, Tailwind 4 und Three.js: eine Deutschlandkarte der Nachfrage nach Stadt, Aufschlüsselungen nach Kategorie, Stufe und Unternehmen, Gehaltsfelder, Wachstum über die Zeit und Feeds neuer Stellen. Die Sicht für die ersten 30 Sekunden, für jede Zielgruppe.

STRUKTUR SEHEN

Knowledge Graph

Ein dreistufiger Graph (Kategorie → Teilsegment → Werkzeug) mit gewichteten Co-occurrence-Kanten. Er macht die Beziehungen sichtbar: welche Werkzeuge sich um „Generative AI & LLMs“ gruppieren, welche Teilsegmente sich einen Stack teilen. Nachfrage als Netzwerk, nicht als Liste.

ALLES FRAGEN

Dialogfähiger SQL-Agent

Ein dauerhaft laufender Agent mit einem einzigen, abgeschotteten sql-Werkzeug auf Postgres, ohne Shell, ohne Dateien. Fragen Sie in normaler Sprache „wie viele PyTorch-Stellen in Berlin in den letzten 7 Tagen?“; er schreibt und führt nur lesendes SQL aus und antwortet. Self-Service-Analyse für Menschen ohne Analyse-Hintergrund.

ai-verticals.dev · vollständiges Dashboard
Vollständiges ai-verticals Dashboard: Kennzahlen, Wachstum, Kategorien, Top-Städte, Top-Unternehmen und Seniorität
Ein Bildschirm, alle Blickwinkel. Kennzahlen, Anzeigentempo, Teilsegmente, Top-Städte, Top-Unternehmen und Senioritätsverteilung. Die Sicht für die ersten 30 Sekunden, für jede Zielgruppe.
Die Produkt-Erkenntnis
Derselbe strukturierte Datensatz bedient die Geschäftsführung, die ein Diagramm möchte, die Produktmanagerin, die Stacks vergleichen will, und die Analystin, die rohes SQL braucht, ohne dass irgendjemand die Daten erneut aufbereitet. Diese Trennung eines verlässlichen Datenkerns von mehreren schlanken Zugängen ist die Architekturentscheidung, die das Ganze wiederverwendbar macht.
Unter der Haube

Die Pipeline: von rohem HTML zu strukturiertem Wissen.

Sechs idempotente Stufen, täglich ausgeführt. In zwei davon steckt die eigentliche KI/ML-Arbeit: Deduplizierung und Klassifizierung.

01 · SCRAPE
Erfassen
LinkedIn, Xing und Glassdoor zu rohem JSON, je Stadt, täglich.
02 · MERGE
Dedup (ML)
Fuzzy- und Gradient-Boosting-Matcher führt Mehrfachanzeigen quellenübergreifend zusammen.
03 · CLEAN
Filtern
Entfernt nach Relevanz, was nicht KI/Tech ist.
04 · RESOLVE
Abgleich mit DB
Gleicher Matcher gegen bestehende DB-Zeilen vor dem Einfügen.
05 · CLASSIFY
LLM-Extraktion
DeepSeek labelt Teilsegmente und Werkzeuge je Stelle.
06 · ENRICH
Kontext
Deutsche Unternehmensbeschreibungen für die wichtigsten Firmen.

Mit einem LLM strukturieren, ohne es halluzinieren zu lassen

Der Klassifizierer arbeitet in zwei Phasen und ist an ein festes Menü gebunden. Zuerst zieht ein Discovery-Lauf rund 120 Beschreibungen je Kategorie und lässt das Modell 4 bis 6 spezialisierende Teilsegmente und die häufigsten Werkzeuge vorschlagen. So entsteht die Taxonomie aus den Daten selbst (71 Teilsegmente, 74 Werkzeuge). Dann reicht ein Labeling-Lauf Stapel von rund 20 Stellen samt Auswahlmenü ein und fragt ausschließlich nach IDs aus diesem Menü. JSON-Modus, niedrige Temperatur und ein harter Prüfschritt, der jede erfundene ID und jedes Teilsegment außerhalb der Kategorie der Stelle verwirft. Das LLM liefert das Urteil, der Code liefert die Leitplanken.

Technische Disziplin, die im Maßstab zählt
Klassifizierung in Stapeln (nicht ein Agent je Stelle) hält Kosten und Latenz vorhersehbar. Jeder Stapel schreibt in einer einzigen Transaktion, sodass ein Abbruch mittendrin den Datensatz nie halb gelabelt zurücklässt. Das ist der Unterschied zwischen einer KI-Demo und einem KI-System.
Das zentrale KI/ML-Problem

Deduplizierung: das unscheinbare Problem, an dem hängt, ob die Zahlen überhaupt stimmen.

Wenn dieselbe Stelle dreimal auftaucht, ist jede Zahl oben falsch. Die Deduplizierung ist die stille tragende Wand des ganzen Produkts, und sie entpuppte sich als echtes ML-Problem, nicht als ein DISTINCT.

Die Falle: dieselbe Stelle erscheint auf der einen Seite als „Senior Software Developer“ und auf der anderen als „Senior AI Software Engineer (m/w/d)“, offensichtlich dieselbe Rolle. Zugleich sind „AI Engineer“ und „DevOps Engineer“ im selben Unternehmen verschiedene Rollen, die einem naiven Textvergleich fast gleich aussehen. Beides gleichzeitig richtig zu treffen ist die eigentliche Aufgabe.

Was wir probiert haben, und warum die naheliegenden Antworten scheiterten

AnsatzPräzision in den schweren FällenFazit
Einzelner Fuzzy-Matching-Score (token_sort / token_set / WRatio)begrenzt auf ~43 %Kann rollenverschiedene Paare nicht trennen.
Mehrsprachige Embedding-Kosinus-Ähnlichkeit von der Stange~21 %, schlechterSynonym-blind: bewertet Developer, Architect und Consultant desselben Produkts mit ≈ 0,97.
Gelerntes Gradient-Boosting-Modell über mehrere Felder≥ 80 %Der einzige Ansatz ohne LLM, der die Schwelle erreicht.

Getestet gegen 520 vom LLM gelabelte Kandidatenpaare (23 echte Dubletten), als Referenz gespeichert, damit jede künftige Änderung gegen dieselbe Grundlage bewertet wird.

Das Modell

Ein kalibrierter GradientBoostingClassifier über einen 11-dimensionalen Feature-Vektor je Paar: Fuzzy-Matching-Scores der Titel (roh und ohne Geschlechtskürzel), TF-IDF-Titel-Kosinus (Wort- und Zeichen-n-Gramme), Verhältnis der Tokenlängen und ein TF-IDF-Kosinus über die ersten 100 Wörter der Beschreibung. Gradient Boosting, weil das Signal stark von Wechselwirkungen lebt: „hohe Tokenüberschneidung ist gut, außer die Beschreibungen laufen auseinander“.

  • Das Kürzen der Beschreibungen auf rund 100 Wörter erhöht die Präzision; der volle Text bricht sie ein, weil Textbausteine Rauschen sind.
  • Die Wahrscheinlichkeiten sind kalibriert (Platt/Sigmoid), damit eine kreuzvalidierte Schwelle tatsächlich auf das ausgelieferte Modell übertragbar ist.
  • Die Schwelle ist auf ein Präzisionsziel (≥ 80 %) gesetzt: lieber eine Zusammenführung verpassen, als zwei verschiedene Stellen falsch verschmelzen.

Die Architektur: Fuzzy-Backbone ODER ML-Catch

Eine günstige Fuzzy-Regel fängt die einfachen exakten und quellenübergreifenden Dubletten (~840 im Maßstab). Das ML-Modell ist ein Recall-Verstärker, nur auf dem schweren Rest trainiert, nämlich beinahe gleichen Paaren innerhalb desselben Unternehmens, und holt rund 25 weitere, die die Fuzzy-Regel übersieht.

Ein Schutz über unterscheidende Tokens kümmert sich um den Grenzbereich: bei knapp ähnlichen Titeln verlangt er zusätzlich eine Überschneidung der bedeutungstragenden Tokens und verhindert so falsche Zusammenführungen rollenverschiedener Stellen (Junior↔Senior, AI↔DevOps), ohne Recall zu verlieren.

Echter Lauf: ein 7-Tage-Nachimport von LinkedIn mit 2.083 zusammengeführten Datensätzen faltete 45 in bestehende DB-Zeilen, also 45 verhinderte Dublettenzeilen, darunter echte quellenübergreifende Zusammenführungen (linkedin+xing, glassdoor+linkedin).

Die Lektion, die einen Blogartikel wert ist
Der Reflex 2026 lautet „wirf ein Embedding-Modell drauf“. Hier waren Embeddings die schlechteste Wahl, denn die Aufgabe ist nicht semantische Ähnlichkeit, sondern Identität, und beides läuft genau dort auseinander, wo es zählt. Der entscheidende Schritt war zu wissen, wann man das modische Werkzeug nicht nimmt, und stattdessen einen kalibrierten, an Benchmarks gemessenen Klassifizierer zu bauen. 458 quellenübergreifende Zusammenführungen in den Live-Daten sind der Ertrag.
Über diese Fallstudie

Ein Nebenprojekt, durchgängig gebaut.

Ich bin Jan, KI-Entwickler. Ich habe ai-verticals allein gebaut, um zu sehen, wie weit eine kleine, disziplinierte Pipeline kommt: von drei unsauberen Scraper-Quellen zu einem sauberen, abfragbaren Datensatz und einem Produkt, das man in dreißig Sekunden erfasst. Das Interessante steckte am Ende in den unscheinbaren Teilen, und genau die dokumentiert dieser Bericht.

  • Data Engineering: ein idempotenter, auditierter Postgres-Kern, gespeist von täglichen Cron-Jobs über drei Quellen.
  • Angewandtes ML: ein an Benchmarks gemessener, kalibrierter Dedup-Klassifizierer und die Entscheidung, Embeddings abzulehnen, weil die Belege dafür sprachen.
  • LLMs im Einsatz: an ein Menü gebundene, validierte, transaktionale Stapel-Klassifizierung sowie ein abgeschotteter dialogfähiger SQL-Agent.
  • Produkt: ein verlässlicher Datenkern hinter drei schlanken Zugängen für drei verschiedene Leser.

Dieser Bericht ist die Grundlage für einen längeren Fallstudien-Artikel auf meiner Website.

Stack: Python · TypeScript · Postgres · Nuxt · scikit-learn · LLMs Kontakt: [email protected]