Commoditech Schreiben Sie uns
← Zurück zu den Artikeln

Prädiktive Analytik und Datenpipelines: Data-Science Body Leasing

Das Modell im Notebook hat AUC 0.87. In Produktion wartet der Kreditantrag 14 Tage, weil das Feature „Transaktionsanzahl 30 Tage“ ein manueller GUI-Export nach CSV ist. Oder die Inference-p99 springt über 500 ms, weil jemand ein Laptop-Artefakt als pickle serialisiert und in einen Container ohne Feature Store gestopft hat.

Das ist kein Algorithmusproblem. Das ist ein Pipeline-Problem. Prädiktive Analytik im Enterprise stirbt an einem Hybrid: Jupyter und Dataiku auf der einen Seite, Spark CLI, Airflow und kubectl auf der anderen. Das Team klickt, fügt ein, exportiert. Das Modell altert in dem Tempo, in dem der Backlog „to deploy“ wächst.

Was den meisten Briefs „wir brauchen einen Data Scientist“ fehlt: wann eine Person mieten (data science staff augmentation, body leasing) und wann die Pipeline einen Squad aus DE + DS + MLOps braucht. Stundensätze stehen in einem eigenen Artikel: IT-Body-Leasing-Sätze Polen 2026. Hier rechnen wir, warum AUC allein nie in Produktion kommt.

Ein Satz, der nie auf die Sales-Folie kommt

Ein Data Scientist ohne Datenpipeline ist ein Forscher mit 8-Stunden-Cap in Jira. Eine Pipeline ohne Data Scientist ist ETL, das nichts vorhersagt. Staff Augmentation einer Rolle funktioniert, wenn die andere schon in Ihrem Team sitzt. Sonst haben Sie ein Timesheet gekauft, keine Prognose.

1. Anatomie: ein Notebook ist kein Produkt

Ein typischer Tag im Team für prädiktive Analytik in einer Bank, Telco oder im Retail sieht nicht aus wie ein scikit-learn-Tutorial. Er sieht aus wie das Umschalten von Modalitäten:

  • GUI: Qualitätschecks in einem BI-Tool, manueller Warehouse-Export, Retrain-Klick in Dataiku / SageMaker Studio, Drift auf einem Dashboard beobachten.
  • CLI / API: Spark-submit, dbt run, airflow dags trigger, kubectl rollout, MLflow log, ein BigQuery-Batch.

Jeder Wechsel ist der Ort, an dem Reproduzierbarkeit stirbt. Ein Feature, das im Notebook berechnet wird, ist nicht das Feature, das im Service berechnet wird. Das ist training-serving skew: das Modell lernt eine Definition, die Produktion nicht wiederholt. Sculley et al. nannten das 2015 pipeline jungles und glue code — ML-Technical-Debt, der schneller wächst als das Modell selbst.

Drei Anzeichen, dass Sie einen Jungle haben, keine Plattform:

  1. CSV als Schnittstelle. Die Source of Truth ist der Export von gestern. Niemand kann sagen, aus welcher Tabelle und mit welchem Filter.
  2. Das Feature wird zweimal berechnet. Pandas auf dem Laptop, SQL in Airflow. Eine Lücke von 0.3 pp in der Fill-Rate taucht ein Quartal später auf, wenn der Drift schon in der Kreditentscheidung sitzt.
  3. Deployment als Ticket an DevOps. Der Data Scientist hört bei „model.pkl“ auf. Jemand anderes packt das Image, eine dritte Person setzt den Probe. Idea-to-Inference: Wochen, nicht Tage.

Deshalb ist ein Brief „Data Scientist mieten“ ohne Pipeline-Kontext der teuerste Weg zu einem weiteren Notebook. Die Skills, die prädiktive Analytik wirklich ausliefern, sitzen auf drei Landings: Data Science und BI, Data Engineering, MLOps.

2. Was die Papers sagen, nicht die MLOps-Decks

Sie brauchen keine weitere Definition von „MLOps maturity“. Sie brauchen die Grenzen, an denen ein Modell das Labor nie verlässt.

  • ML-Debt sitzt im Glue, nicht im Loss. Sculley et al., Hidden Technical Debt in Machine Learning Systems (NIPS 2015): in ML-Systemen ist der Lerncode meist ein kleiner Bruchteil. Der Rest ist Konfiguration, Collection, Verification, Serving, Monitoring. „Ein Feature ändern“ zündet eine Kaskade, weil die Abhängigkeiten versteckt sind. Ein Pipeline-Jungle wächst, wenn Sie Pfade hinzufügen statt alte zu löschen.
  • Computerarbeit ist hybrid. Shi, Wang, Fang, Liang et al., CUA-Universe (arXiv:2609.05374, September 2026): echte Arbeit mischt visuelle State-Inspektion mit präzisem CLI über gemeinsamen Application-State. GUI-only-Agenten erzeugen ineffiziente Trajektorien; CLI-only-Agenten erblinden am Layout. Training auf Hybrid GUI+CLI hat ein 9B-Modell bewegt: CUA-Verse +39.3 pts, −37% Schritte, −60% Tokens; OSWorld SR +16.8 pts, −57% Schritte, −44% Tokens. Das ist kein Paper über Credit Scoring. Das ist eine Messung, was das Jonglieren zwischen Fenster und Terminal kostet. Ein Data-Science-Team, das in Studio klickt und Commands in Confluence einfügt, zahlt dieselbe Steuer.
  • Delivery ist eine Team-Metrik, keine Notebook-Metrik. DORA 2024: Elite vs. Low ist eine Größenordnung bei Deploy-Frequenz und Change Lead Time. Diese Zahlen beschreiben Teams mit gemeinsamer Definition of Done. Fünf getrennte Timesheets (DS von Vendor A, DE von B, „jemand für Kubernetes“ von C) setzen keinen Lead Time zusammen. Sie setzen drei Ersatz-SLAs und einen Status „in progress“ zusammen. Diesen Failure Mode haben wir in team leasing vs staff augmentation 2026 auseinandergenommen.

Der architektonische Schluss

Die Pipeline zu standardisieren heißt nicht „SageMaker kaufen“. Es heißt, GUI↔CLI-Wechsel dort zu töten, wo API und IaC sie ersetzen können. Feature Store, ein DAG, ein Serving-Image, ein Schema-Test auf dem PR. Der Rest ist Vendor-Kosmetik. Wenn Ihr Data Scientist ein Feature nicht aus einem Commit reproduzieren kann, haben Sie keine prädiktive Analytik. Sie haben ein Demo.

3. Produktionsfall: Scoring, das einen Sprint hinterherhinkte

Aus der Engineering-Praxis: von 3 Wochen auf 3 Tage

Ein Finanzinstitut, ein Buch mit Millionen Kunden. Application Scoring und Fraud Detection. Quellen: Oracle / PostgreSQL, ein Data Lake (S3 + Hive), Logs in Elasticsearch. Das Team für prädiktive Analytik arbeitete so:

  • Extraktion: handgeschriebenes SQL, CSV-Export,
  • Features: Pandas auf dem Laptop, Excel-Joins „für alle Fälle“,
  • Training: Dataiku-GUI, manueller Artefakt-Export,
  • Release: ein Ticket an DevOps, Docker „wie es kommt“, API Gateway, Kubernetes ohne Schema-Test.

Problem: Idea-to-Inference 3–4 Wochen. Modelle waren am Go-live-Tag schon alt. p99 der kritischen Predictions > 500 ms. Betriebskosten wuchsen mit jedem neuen pickle.

Änderung: Spark-Pipelines, orchestriert von Airflow in einen Feature Store (Hopsworks). Jede Stufe (data, train, validate, serve) in einem Image. GitOps auf den Cluster. Monitoring von Feature-Drift und Data Quality (Prometheus / Grafana). DS hört auf, CSV zu exportieren. DE hört auf zu raten, welche Feature-Version in den Batch geht.

Gemessen danach: Time-to-Production 3 Tage statt 3 Wochen. Pipeline- und Deploy-Fehler −85%. Inference-p99 < 80 ms. MLOps-Infrastrukturkosten −40% — nicht durch eine billigere Cloud, durch kein manuelles Firefighting und keine abgebrochenen Retrains.

Dieses Ergebnis kam nicht von „einem besseren XGBoost“. Es kam davon, die GUI für die Inspektion zu lassen und CLI/API für den Pfad, der sich um 03:00 wiederholen muss. Dieselbe Lektion, die CUA-Universe an Agenten misst: Hybrid funktioniert, wenn beide Modalitäten State teilen — nicht wenn ein Mensch der Bus zwischen Fenstern ist.

4. Entscheidungstabelle: welche Pipeline, welches Line-up

Ansatz Komplexität Latenz p95/p99 Infra-Kosten Team-Overhead Wann einsetzen
Notebook + ad-hoc ETL Niedrig am Start, wächst exponentiell Sekunden–Minuten, oft manuell Niedrig am Start Hoch (Glue, Debugging) PoC, ein Analyst, kein SLA
MLOps OSS (Airflow, MLflow, Kubeflow, Feast/Hopsworks) Hoch (Plattform) ms–s, wiederholbar Mittel Mittel–hoch (DE + MLOps) Enterprise mit Bedarf an Kontrolle und On-Prem / Hybrid
Managed Service (SageMaker, Vertex, Azure ML) Mittel (Cloud-Integration) ms–s Mittel–hoch (Service-Meter) Operativ niedriger Wenn Sie schon in einem Cloud-IAM leben und kein Legacy-GUI mitschleppen
Hybrid + T&M-Line-up Sehr hoch Begrenzt durch den schwächsten Connector Hoch Hoch, bis GUI und API zusammengenäht sind Bank, Pharma, Daten die nicht rausgehen. Meist ein Squad, keine einzelne Rolle.

Python CRUD und Python für Datenpipelines sind zwei Jobs. Backend-Bänder 145–200 / 200–280 PLN/h (Contractor / Kunde). Data Pipelines sitzen im oberen Teil dieses Bandes. Production AI/LLM: 180–250 / 240–350 PLN/h. Marge 10–25%. Eine Karte, keine Preisliste — Details im Artikel zu den Sätzen 2026.

5. Anti-Patterns, die Sie in keinem Kubeflow-Tutorial finden

  1. Ein Brief „Python Developer“ für Scoring. Sie bekommen Django. Sie bekommen keinen Feature Store. Der Markt ist gespalten: klassisches Backend hat Angebot, Pipeline- und LLM-Engineers nicht. Eine falsch gelabelte Anzeige füllt sich in 48 h mit CVs und null Drift-Kompetenz.
  2. Keine Datentests. CI lintet das Modell, nicht das Input-Schema. Eine stille Null-Änderung in der Quelle geht live. Die Prediction ist „grün“. Die Business-Entscheidung ist es nicht.
  3. Ein Feature ohne Owner. DS berechnet es im Notebook, DE in dbt, BI in Power Query. Drei Churn-Definitionen. Ein Dashboard, drei Kriege im Stand-up.
  4. Ein Fake-Analytics-Team. DS von Vendor A, DE von B, MLOps „wenn Zeit ist“ vom internen DevOps. Drei Onboardings, kein gemeinsamer DAG. Das ist kein staff augmentation. Das ist die Integrationssteuer, beschrieben unter IT team leasing.

6. Playbook: wen mieten, und in welcher Reihenfolge

Fangen Sie nicht beim Modell an. Fangen Sie damit an, welche Modalität das SLA blockiert.

  1. Eine Lücke in einer bestehenden Pipeline. Sie haben Airflow, einen Feature Store und jemanden, der PRs reviewed. Es fehlt ein Senior am Modell oder an Spark. Das ist klassisches data science staff augmentation oder ein Data Engineer: eine Person, Ihr Stand-up, Ihr DoD. Erste Profile in Tagen, nicht in einem Quartal — wir sourcen on demand, wir verkaufen keine namentliche Bank für morgen früh.
  2. Das Notebook ist das Produkt. Kein DAG, kein Schema-Test, kein Serving. Eine Person näht das nicht zusammen. Line-up 3–5: DE (Quellen, dbt/Spark), DS (Modell, Validation), MLOps (Image, Drift-Monitoring). Näher an team leasing als an „wir legen noch einen Analysten drauf“.
  3. Daten verlassen die VPC nicht. Contractor in Ihrem IAM, Ihrer Cloud, NDA und Auftragsverarbeitung. Colab mit einem Production-Dump ist ein Leak, keine Beschleunigung. Offline-Feature-Berechnung im Batch, Online-Serving aus demselben Feature-Code.
  4. Ramp-up. Eine Person ins bestehende Team: erste CVs in 24–48 h, Start nach Ihren Interviews und dem Vertrag. Ein Squad von null: Wochen, kein Sprint, weil Sie Access, Daten und DoD zusammennähen. „Drei Senior Python ab Montag“ ist ein CV-Pack oder eine Bank, die wir nicht haben — und nicht vortäuschen werden.

Commoditech macht T&M und Festanstellungssuche seit 2012 aus Warschau. 80+ Spezialisten im Netzwerk, kein Idle-Bench. Ein T&M- oder Success-Fee-Brief lässt sich aus der IDE über MCP für AI-Agenten einreichen, nicht nur über ein Kontaktformular. Ein Mensch quotiert den Stack; Spannen stehen im Artikel zu den Sätzen, nicht im JSON des Agenten.

FAQ

Worin unterscheidet sich Data Science staff augmentation von der Festanstellung eines Data Scientist?

Eine Festanstellung ist ein FTE in Ihrem HR. Die mittlere Lebensdauer einer IT-Anzeige auf JobHunt im September 2026 beträgt 50 Tage — bevor Sie überhaupt interviewen. Data Science staff augmentation ist T&M: die Person in Ihrem Team, Ihrem Git, Ihrem SLA, mit Ersatzklausel für die Rolle. Sie kaufen nicht „ein Modell im Abo“. Sie kaufen eine Stunde Skill. TCO vs. Payroll (Recruiting, Bank, Abfindung, Hardware) steht in den Sätzen 2026.

Wann eine Person mieten, wann einen Data-Science-Squad?

Eine Person, wenn die Pipeline schon existiert und eine Lücke fehlt: Senior DS, Spark, MLOps. Ein Squad aus 3–5, wenn das Notebook das einzige Artefakt ist. Ein Data Scientist allein liefert AUC. Er liefert nicht p99, keinen Schema-Test und keinen Retrain um 03:00. Wenn niemand auf Ihrer Seite den PR des Contractors reviewen kann, kaufen Sie kein staff augmentation. Kaufen Sie einen Lead plus eine Rolle, oder einen Squad.

Was kostet Data Science staff augmentation in Polen 2026?

Python für Datenpipelines ist kein CRUD: in der Praxis zahlt der Kunde das obere Ende des Senior-Bands 200–280 PLN/h. Wenn das Modell mit LLM / RAG live geht, näher an 240–350 PLN/h. Vendor-Marge 10–25% — wenn jemand 8% bei Ersatz in 5 Tagen verspricht, sitzt das auf einer anderen Zeile. Eine Marktkarte, kein Angebot. Ein Mensch preist den Brief.

Kann ein Data-Science-Contractor auf Daten unter NDA und DSGVO arbeiten?

Ja: Ihre Umgebung, Ihr IAM, Ihre Cloud oder On-Prem, ein Vertrag mit NDA, Auftragsverarbeitung und IP auf Kundenseite. Ein Notebook auf einem privaten Laptop mit Production-Dump ist ein Leak. Offline-Features im Batch, Online-Serving aus demselben Code. Access-Audit ist Ihres. Der Contractor nimmt den Datensatz nicht mit, „um schneller zu rechnen“.

Quellen

  • Sculley, D. et al. (2015). Hidden Technical Debt in Machine Learning Systems. NIPS 2015. papers.nips.cc
  • Shi, H., Wang, W., Fang, W., Liang, Y. et al. (2026). CUA-Universe: A Scalable and Dynamic Environment for Hybrid GUI+CLI Agents. arXiv:2609.05374. arxiv.org/abs/2609.05374
  • DORA / Google Cloud (2024). Accelerate State of DevOps Report.
  • JobHunt.pl (1. September 2026). 21,211 aktive IT-Rollen, mittlere Anzeigenlebensdauer 50 Tage — Kontext Time-to-Hire vs. T&M.