AutoML für Business-Analysten

Viele Unternehmen haben die Daten für nützliche Vorhersagen (wer abwandert, was sich verkauft, welche Rechnung zu spät bezahlt wird), aber keine Data Scientists. AutoML automatisiert Merkmalsaufbereitung, Modellauswahl, Feintuning und Validierung und verpackt das Ergebnis in eine Tabellenkalkulations- oder SQL-Oberfläche. Ein Analyst erhält in Stunden ein validiertes, erklärbares Modell. Unverzichtbar bleibt die Fähigkeit, die Frage richtig zu formulieren und auf Datenlecks (Leakage), Verzerrungen und Drift zu prüfen. Genau dabei helfen inzwischen LLM-Assistenten.

Problem & Nutzen

• Heute: Vorhersagefragen werden mit Bauchgefühl, statischen Excel-Regeln oder einer Anfrage im Rückstau eines kleinen Datenteams beantwortet. Eigene Modelle dauern Monate und werden selten gepflegt.
• KI-Nutzen: automatisierte Suche über Gradient Boosting, lineare Modelle, neuronale Netze und Ensembles mit Kreuzvalidierung; Erklärungen für Fachanwender; Bereitstellung per Klick als Scoring-Job. LLM-Copiloten ergänzen eine Problemformulierung in natürlicher Sprache, Datenprüfungen und das Verfassen von Berichten.
• Belege: offene Benchmarks zeigen, dass gut konfigurierte AutoML-Ensembles bei typischen Tabellen die meisten von Hand abgestimmten Modelle erreichen oder übertreffen [1][2]. Der geschäftliche Mehrwert hängt vollständig von der Entscheidung ab, die das Modell unterstützt; eine allgemeine ROI-Zahl sollte nicht angenommen werden.

Varianten

• Klassifikation / Regression auf CRM- und ERP-Tabellen: Kundenabwanderung, Lead-Scoring, Zahlungsverzug, Preis.
• Zeitreihenprognose: Nachfrage, Umsatz, Personalstand, Energie (siehe PRED-001, DATA-024).
• AutoML in der Datenbank: Training und Scoring mit SQL im Warehouse; die Daten verlassen es nie.
• Werkzeuge für Citizen Analysts in Tabellenkalkulation / BI: Excel-Add-ins, Power BI, in Tableau integrierte Modelle.
• Öffentlicher Sektor / Forschung: Vorhersage von Fallzahlen oder Nachfrage mit strengen Anforderungen an die Erklärbarkeit.
• Private Nutzung: Hobby- und Kleinbetriebsprognosen mit kostenlosen Notebooks; kein regulatorischer Aufwand.

So funktioniert es

1. business question
2. target definition & data selection (analyst, human)
3. data profiling & leakage checks (rules + LLM review)
4. feature engineering & encoding (automatic)
5. model search + cross-validation / time-based backtest
6. leaderboard, calibration, fairness and explanation (SHAP-style)
7. model card / plain-language report (LLM)
8. human approval
9. deployment (batch score, API, SQL function)
10. monitoring: drift, accuracy against actual outcomes (see DATA-008)

• Kernmotor: klassisches ML auf Tabellen (Gradient-Boosted Trees, Ensembles) bleibt die stärkste Standardwahl; Deep Learning gewinnt auf kleinen Geschäftstabellen selten.
• Tabellarische Foundation-Modelle (TabPFN und ähnliche) sagen in einem einzigen Vorwärtsdurchlauf voraus, ohne Training je Datensatz, und sind bei kleinen Datensätzen stark (bis grob einige zehntausend Zeilen) [3].
• LLM-Schicht: übersetzt die Geschäftsfrage in eine Aufgabenstellung, schlägt Merkmale vor, erklärt die Rangliste und schreibt die Dokumentation. LLMs sind nicht der Prädiktor.
• Mensch-in-der-Schleife (Human-in-the-Loop): Der Analyst legt Ziel, zeitliche Aufteilung und Kosten von Fehlern fest und gibt die Bereitstellung frei. Entscheidungen, die Menschen betreffen, brauchen einen benannten verantwortlichen Menschen.

Datenaufbereitung

AutoML ist nur so gut wie seine Tabellen: Der größte Teil des Aufwands fließt in die Daten, nicht in die Modellierung. Die Daten liegen typischerweise in ERP- und CRM-Exporten, von Einzelpersonen gepflegten Excel-Tabellen, Buchhaltungssystemen und Webshop-Datenbanken. Typische Lücken sind uneinheitliche Kunden-IDs über Systeme hinweg, Freitextfelder statt Kategorien, fehlende oder verspätet erfasste Zielwerte (zum Beispiel wird Abwanderung nie markiert), Dubletten, zu kurze Historie und Spalten, die die Antwort in die Trainingsdaten durchsickern lassen. Die Zugriffsrechte auf die Quellsysteme sind oft ungeklärt.

Konkrete Schritte: Quellen inventarisieren und die eine Frage festlegen, die das Modell beantwortet (GUIDE-003, PREP-001, PREP-002); Daten per Export oder Konnektor aus ERP- und SaaS-Werkzeugen ziehen (PREP-005); Tabellenkalkulationen in saubere Tabellen überführen (PREP-011); Definitionen der Kennzahlen und der Zielspalte festlegen (PREP-012); Zielwerte aus vorhandenen Datensätzen gewinnen (PREP-020); personenbezogene Daten vor der Modellierung pseudonymisieren (PREP-022). Werkzeuge: Power Query, dbt, pandas oder ein kleines DuckDB-/PostgreSQL-Warehouse; siehe auch DATA-003 und DATA-008. Grober Aufwandsanteil: 60–70 Prozent eines ersten Projekts; spätere Modelle nutzen dieselben Tabellen und werden deutlich günstiger.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A. Ausgereifte AutoML- und BI-integrierte Produkte mit EU-Hosting gibt es zu KMU-tauglichen Preisen, und der Ablauf (trainieren, vergleichen, erklären) ist Standard.
• Großunternehmen: Weg C. Eine gemeinsame interne ML-Plattform mit Open-Source-AutoML (z. B. AutoGluon, H2O) vermeidet Lizenzkosten je Nutzer und hält sensible Kunden- und Personaldaten im Haus.
• Entwickler: Weg C. Open-Source-AutoML-Bibliotheken laufen auf HW1 und geben volle Kontrolle über Merkmale, Validierung und Bereitstellung.

Weg A — Kaufen (Standardsoftware) (für die meisten KMU empfohlen)

• Plattformen: DataRobot, H2O.ai Driverless AI, Dataiku (Frankreich, EU), Alteryx, RapidMiner/Altair AI Studio (Altair, inzwischen Teil von Siemens), KNIME (Schweiz/Deutschland, EU-nah, Open Core) und Obviously AI.
• In Datenplattformen: Snowflake Cortex ML Functions, Databricks AutoML, Google BigQuery ML, Microsoft Fabric / Azure Machine Learning Automated ML, Amazon SageMaker Canvas und Autopilot.
• Weg A wählen, wenn: die Daten bereits in einer dieser Plattformen liegen, das Team Analysten, aber keine ML-Ingenieure hat und die Zahl der Modelle klein ist. EU-Region, AVV, Modellexport und Lock-in prüfen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Verwaltete AutoML-APIs: Vertex AI AutoML Tabular und Forecasting, Azure ML AutoML (EU-Regionen), SageMaker Autopilot (Frankfurt), dazu Mistral- oder Claude-/Gemini-/GPT-APIs für den LLM-Assistenten (Einrichtung in natürlicher Sprache, Berichtsentwürfe) auf Endpunkten in EU-Regionen.
• Orchestrierung: dbt + Warehouse-Zeitplanung, Airflow, n8n; Scores werden ins CRM/ERP zurückgeschrieben.
• Weg B wählen, wenn: Sie eine individuelle Integration oder eingebettete Vorhersagen im eigenen Produkt benötigen.

Weg C — Selbst betreiben (Open Source)

• Bibliotheken: AutoGluon (Amazon; TabularPredictor, TimeSeriesPredictor mit Chronos-Modellen) [1], FLAML (Microsoft), H2O-3 AutoML, auto-sklearn, PyCaret, LightGBM / XGBoost / CatBoost, TabPFN [3].
• Prognose: StatsForecast, Darts, Chronos, TimesFM und weitere offene Zeitreihen-Foundation-Modelle.
• Erklärbarkeit: SHAP, Inspektionswerkzeuge von scikit-learn; Nachverfolgung mit MLflow.
• Oberfläche für Analysten: KNIME, Orange oder JupyterLab mit einem Coding-LLM mit offenen Gewichten als Helfer.
• Hardware: HW1 (CPU-Server) genügt für die meisten Tabellen; HW2 nur für Modelle im Stil von TabPFN bei größeren Daten oder große Flotten von Zeitreihenmodellen.

Weg D — Eigenes Training

Lohnt sich bei wertvollen Entscheidungen in hoher Stückzahl (kreditähnliches Scoring, Preisgestaltung) mit jahrelanger gelabelter Historie oder wenn AutoML bei besonderen Strukturen (Graphen, lange Sequenzen) schwächelt. Erfordert einen Data Scientist, einen Feature Store und ein Monitoring-Setup; die meisten KMU sollten zuerst A bis C ausschöpfen.

Stand der Technik (2026)

• Ensembling schlägt Feintuning: gestapelte Ensembles aus Boosted Trees und neuronalen Netzen (im Stil von AutoGluon) dominieren offene Tabellen-Ranglisten; TabArena ist der gepflegte, laufend aktualisierte Benchmark dafür [2].
• Tabellarische Foundation-Modelle (TabPFN-v2 und Nachfolger) sind bei kleinen und mittleren Tabellen inzwischen konkurrenzfähig und werden in AutoML-Ensembles integriert [3].
• Zeitreihen-Foundation-Modelle (Chronos, TimesFM, Moirai) liefern Zero-Shot-Basislinien, die oft abgestimmte klassische Modelle erreichen; immer mit einer saisonal-naiven Basislinie vergleichen [4].
• Agentisches AutoML: LLM-Agenten richten Experimente ein, schreiben Feature-Code und iterieren, können aber unbemerkt Leakage einführen oder auf dem Testdatensatz abstimmen. Erzeugte Pipelines als nicht vertrauenswürdigen, zu prüfenden Code behandeln.
• Grenzen und Fehlerbilder: Target Leakage, zufällige Aufteilung bei zeitabhängigen Daten, Concept Drift, verzerrte historische Labels, winzige Klassen, Überanpassung an die Rangliste und zu großes Vertrauen in „automatische“ Ergebnisse. Erklärungen (SHAP) zeigen das Modellverhalten, nicht Kausalität (siehe DATA-027).

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (tabular-ml + time-series): PRED-001 Nachfrage, PRED-002 Vertrieb, PRED-003 Abwanderung, PRED-016 Cashflow, DATA-024 FP&A-Prognose. Eine AutoML-Plattform und ein Feature Store können alle bedienen.
• Vorgelagert: DATA-003 Bereinigung und Stammdaten, DATA-006 Tabellenanalyse, DATA-001 dialogorientierte BI zum Erkunden der Daten vor der Modellierung.
• Nachgelagert / Betrieb: DATA-008 Datenqualität und Drift-Überwachung; DATA-002 Berichte zu den Ergebnissen.
• Kausale Fortsetzung: DATA-027 Experimente, um zu prüfen, dass Handeln auf Basis der Vorhersagen tatsächlich hilft.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen bis zum ersten Modell; Lizenzen reichen von Preisen je Nutzer bis zu Gebühren für Unternehmensplattformen; viele Warehouse-native Optionen rechnen nur nach Rechenleistung ab.
• Weg B: 1–3 Monate mit Integration; die Kosten bestehen überwiegend aus Entwicklung plus Rechenleistung.
• Weg C: 1–3 Monate; Open Source ist kostenlos, Kosten entstehen durch Personal und Hosting; geringer Rechenbedarf.
• Weg D: 3–9 Monate mit einem Data Scientist.
• Kennzahlen: Metrik auf einem zurückgehaltenen, zeitlich getrennten Testdatensatz (AUC, MAPE, RMSE, Lift), Verbesserung gegenüber der bestehenden Regel oder naiven Basislinie, Zeit von der Frage bis zum bereitgestellten Modell, Anteil der Modelle, die noch überwacht werden, realisierte geschäftliche Wirkung (Kundenbindung, Fehlbestände, DSO).

Menschen & Veränderung

Beginnen Sie mit der Geschäftsleitung (Budget, welche Entscheidungen das Modell beeinflussen darf) und der Abteilungsleitung, die die Frage verantwortet; beziehen Sie die Datenverantwortlichen von ERP/CRM früh ein, denn sie geben Daten frei und kennen deren Eigenheiten. Die IT kümmert sich um Zugriff und Bereitstellung, die/der Datenschutzbeauftragte wird immer dann gebraucht, wenn Scores sich auf Personen (Kunden, Beschäftigte) beziehen, wegen Rechtsgrundlage, AVV und einer möglichen DSFA (GUIDE-005).

Betriebsrat: abhängig vom Einzelfall. Modelle auf Kunden- oder Produktdaten brauchen in der Regel keinen, aber das Scoring von Beschäftigten (Fehlzeiten, Leistung, Fluktuation) oder Werkzeuge, die das Verhalten der Analysten protokollieren, fallen unter § 87 Abs. 1 Nr. 6 BetrVG, und § 90 Abs. 1 Nr. 3 verlangt rechtzeitige Unterrichtung, wenn Arbeitsverfahren mit KI geplant werden; der Betriebsrat kann nach § 80 Abs. 3 einen Sachverständigen hinzuziehen. Öffentlicher Dienst: Personalrat (GUIDE-004).

Maßnahmen zur Förderung der KI-Kompetenz (Art. 4 KI-Verordnung) sollten das Lesen von Kennzahlen, Leakage und Verzerrungen abdecken, nicht nur Klicks im Werkzeug (GUIDE-006). Wählen Sie einen Analysten und einen skeptischen Fachanwender als Pilotgruppe (GUIDE-008). Typische Bedenken: „Die Black Box ersetzt mein Urteil“ (Antwort: Merkmalswichtigkeit und eine menschliche Entscheidung bei jeder Maßnahme) und „Die Zahlen werden genutzt, um uns zu ranken“ (Zweckbindung schriftlich vereinbaren). Behalten Sie den Menschen die Kontrolle: Scores sind Empfehlungen, Schwellenwerte und Übersteuerungen legt die Fachabteilung fest.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): abhängig vom Einsatz. Vorhersagen zu Abwanderung, Nachfrage oder Wartung haben typischerweise minimales Risiko. Modelle, die natürliche Personen bei Kreditwürdigkeit, Versicherungstarifen in Leben/Gesundheit, Personalauswahl, Beschäftigtenbewertung oder Zugang zu öffentlichen Leistungen bewerten, sind Hochrisiko (Anhang III) mit Pflichten zu Daten-Governance, Dokumentation, menschlicher Aufsicht und Protokollierung. Emotionserkennung am Arbeitsplatz und Social Scoring sind verboten (Art. 5). Die KI-Kompetenz (Art. 4) gilt auch für die Citizen Analysts [5].
• DSGVO: Kunden- oder Beschäftigtendaten in Trainingsdaten brauchen eine Rechtsgrundlage, Zweckbindung und Datenminimierung. Art. 22 begrenzt ausschließlich automatisierte Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung; aussagekräftige Informationen über die involvierte Logik sind bereitzustellen. Für Profiling in großem Umfang ist wahrscheinlich eine DSFA nötig [6].
• Branchenregeln: Kredit-Scoring (EBA-Leitlinien, Verbraucherkreditrichtlinie), Versicherung (EIOPA), deutsche Mitbestimmung des Betriebsrats bei beschäftigtenbezogenen Modellen.
• Typische Risiken: Proxy-Diskriminierung über Merkmale wie die Postleitzahl, Leakage, unbemerkte Drift, Schattenmodelle, die Citizen Analysts außerhalb der Governance bauen.
• Gegenmaßnahmen: Modellregister, verpflichtende Validierung mit zeitlicher Aufteilung, Fairness-Prüfungen bei sensiblen Gruppen, benannte Modellverantwortliche, Freigabeschritt vor dem Produktivbetrieb, Drift-Überwachung, Rückfallplan.

Erste Schritte

1. Wählen Sie eine Entscheidung mit messbarem Ergebnis und mindestens einem Jahr Historie (z. B. säumige Zahler).
2. Halten Sie Ziel, Vorhersagezeitpunkt und den zu diesem Zeitpunkt bekannten Wissensstand schriftlich fest, um Leakage zu vermeiden.
3. Führen Sie eine Basislinie aus (Regel oder saisonal-naiv), dann einen offenen AutoML-Lauf (AutoGluon/FLAML) oder einen Plattform-Test mit derselben Aufteilung.
4. Prüfen Sie Erklärungen und Fehler gemeinsam mit der Fachverantwortlichen bzw. dem Fachverantwortlichen; prüfen Sie Fairness, wenn Personen bewertet werden.
5. Stellen Sie das Modell als Batch-Score mit Überwachung und einer monatlichen Prüfung der Genauigkeit gegenüber den Ergebnissen bereit.

Quellen

1. AutoGluon documentation — https://auto.gluon.ai/stable/index.html
2. TabArena: a living benchmark for machine learning on tabular data — https://tabarena.ai/
3. TabPFN (Prior Labs), Hollmann et al., "Accurate predictions on small data with a tabular foundation model", Nature 2025 — https://www.nature.com/articles/s41586-024-08328-6
4. Chronos time-series foundation models — https://github.com/amazon-science/chronos-forecasting
5. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. Regulation (EU) 2016/679 (GDPR), Art. 22 — https://eur-lex.europa.eu/eli/reg/2016/679/oj
7. Google Cloud — BigQuery ML — https://cloud.google.com/bigquery/docs/bqml-introduction
8. Snowflake — ML functions (Cortex) — https://docs.snowflake.com/en/guides-overview-ml-functions
9. Microsoft — Automated ML in Azure Machine Learning — https://learn.microsoft.com/azure/machine-learning/concept-automated-ml