Catalog / Data & Analytics / DATA-009

AutoML for business analysts

No-code and low-code tools that train, compare and explain predictive models on business tables, so analysts can build churn, demand or scoring models without a data-science team.

Many companies have the data for useful predictions (who will churn, what will sell, which invoice will be paid late) but no data scientists. AutoML automates feature handling, model selection, tuning and validation, and wraps the result in a spreadsheet-like or SQL interface. An analyst can get a validated, explainable model in hours. The skill that remains essential is framing the question and checking for leakage, bias and drift. LLM assistants now help with exactly that.

Problem & value

  • Today: predictive questions are answered with gut feeling, static Excel rules or a backlog request to a small data team. Custom models take months and are rarely maintained.
  • AI value: automated search over gradient boosting, linear models, neural nets and ensembles with cross-validation; explanations for business users; one-click deployment as a scoring job. LLM copilots add natural-language problem framing, data checks and report writing.
  • Evidence: open benchmarks show that well-configured AutoML ensembles match or beat most hand-tuned models on typical tables [1][2]. Business uplift depends entirely on the decision it supports; no general ROI figure should be assumed.

Variants

  • Classification / regression on CRM and ERP tables: churn, lead scoring, late payment, price.
  • Time-series forecasting: demand, revenue, headcount, energy (see PRED-001, DATA-024).
  • In-database AutoML: train and score with SQL inside the warehouse; data never leaves.
  • Citizen-analyst tools in spreadsheets / BI: Excel add-ins, Power BI, Tableau-integrated models.
  • Public sector / research: case-load or demand prediction with strict explainability needs.
  • Private use: hobby and small-shop forecasting with free notebooks; no regulatory overhead.

How it works

  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)
  • Core engine: classical ML on tables (gradient-boosted trees, ensembles) remains the strongest default; deep learning rarely wins on small business tables.
  • Tabular foundation models (TabPFN and similar) predict in one forward pass without per-dataset training and are strong on small datasets (up to roughly tens of thousands of rows) [3].
  • LLM layer: translates the business question into a task setup, proposes features, explains the leaderboard and writes documentation. LLMs are not the predictor.
  • Human-in-the-loop: the analyst defines target, time split and cost of errors, and signs off deployment. Decisions affecting people need a named human owner.

Data preparation

AutoML is only as good as its tables: most of the effort goes into data, not modelling. The data typically sits in ERP and CRM exports, Excel sheets maintained by individuals, accounting systems and web-shop databases. Typical gaps are inconsistent customer IDs across systems, free-text fields instead of categories, missing or late-recorded target labels (for example churn is never flagged), duplicates, history that is too short, and columns that leak the answer into the training data. Access rights to the source systems are often unclear.

Concrete steps: inventory the sources and define the one question the model answers (GUIDE-003, PREP-001, PREP-002); pull data out of ERP and SaaS tools via exports or connectors (PREP-005); turn spreadsheets into tidy tables (PREP-011); fix definitions of KPIs and the target column (PREP-012); harvest labels from existing records (PREP-020); pseudonymise personal data before modelling (PREP-022). Tools: Power Query, dbt, pandas or a small DuckDB/PostgreSQL warehouse; see also DATA-003 and DATA-008. Rough share of effort: 60-70 percent of a first project; later models reuse the same tables and become much cheaper.

Implementation paths

Which path for whom

  • SMB: Path A. Mature AutoML and BI-integrated products with EU hosting exist at SMB prices and the process (train, compare, explain) is standard.
  • Enterprise: Path C. A shared internal ML platform with open-source AutoML (e.g. AutoGluon, H2O) avoids per-seat costs and keeps sensitive customer and HR data in-house.
  • Developer: Path C. Open-source AutoML libraries run on HW1 and give full control over features, validation and deployment.
  • Platforms: DataRobot, H2O.ai Driverless AI, Dataiku (France, EU), Alteryx, RapidMiner/Altair AI Studio (Altair, now part of Siemens), KNIME (Switzerland/Germany, EU-adjacent, open core) and Obviously AI.
  • Inside data platforms: Snowflake Cortex ML functions, Databricks AutoML, Google BigQuery ML, Microsoft Fabric / Azure Machine Learning automated ML, Amazon SageMaker Canvas and Autopilot.
  • Choose A when: data already lives in one of these platforms, the team has analysts but no ML engineers, and the number of models is small. Check EU region, DPA, model export and lock-in.

Path B — Build on cloud APIs

  • Managed AutoML APIs: Vertex AI AutoML tabular and forecasting, Azure ML AutoML (EU regions), SageMaker Autopilot (Frankfurt), plus Mistral or Claude/Gemini/GPT APIs for the LLM assistant (natural-language setup, report drafting) on EU-region endpoints.
  • Orchestration: dbt + warehouse scheduling, Airflow, n8n; scores written back to the CRM/ERP.
  • Choose B when: you need custom integration or embedded predictions in your own product.

Path C — Self-host (open source)

  • Libraries: AutoGluon (Amazon; TabularPredictor, TimeSeriesPredictor with Chronos models) [1], FLAML (Microsoft), H2O-3 AutoML, auto-sklearn, PyCaret, LightGBM / XGBoost / CatBoost, TabPFN [3].
  • Forecasting: StatsForecast, Darts, Chronos, TimesFM and other open time-series foundation models.
  • Explainability: SHAP, scikit-learn inspection tools; tracking with MLflow.
  • Interface for analysts: KNIME, Orange or JupyterLab with an open-weight coding LLM helper.
  • Hardware: HW1 (CPU server) suffices for most tables; HW2 only for TabPFN-style models on larger data or large time-series model fleets.

Path D — Custom training

Worth it for high-value, high-volume decisions (credit-like scoring, pricing) with years of labelled history, or when AutoML underperforms on special structure (graphs, long sequences). Requires a data scientist, feature store and a monitoring set-up; most SMBs should exhaust A to C first.

State of the art (2026)

  • Ensembling beats tuning: stacked ensembles of boosted trees and neural nets (AutoGluon-style) dominate open tabular leaderboards; TabArena is the maintained living benchmark for this [2].
  • Tabular foundation models (TabPFN-v2 and successors) are now competitive on small and medium tables, and are being integrated into AutoML ensembles [3].
  • Time-series foundation models (Chronos, TimesFM, Moirai) give zero-shot baselines that often match tuned classical models; always compare to a seasonal-naive baseline [4].
  • Agentic AutoML: LLM agents set up experiments, write feature code and iterate, but they may silently introduce leakage or tune on the test set. Treat generated pipelines as untrusted code to review.
  • Limits and failure modes: target leakage, random splits on time-dependent data, concept drift, biased historical labels, tiny classes, overfitting to the leaderboard, and over-trust in "automatic" results. Explanations (SHAP) show model behaviour, not causality (see DATA-027).

Shared resources & combinations

  • Same stack (tabular-ml + time-series): PRED-001 demand, PRED-002 sales, PRED-003 churn, PRED-016 cash-flow, DATA-024 FP&A forecasting. One AutoML platform and feature store can serve all.
  • Upstream: DATA-003 cleaning and master data, DATA-006 spreadsheet analysis, DATA-001 conversational BI for exploring data before modelling.
  • Downstream / ops: DATA-008 data quality and drift monitoring; DATA-002 reporting of results.
  • Causal follow-up: DATA-027 experiments to verify that acting on predictions really helps.

Effort, cost & KPIs

  • Path A: days to weeks to the first model; licences range from per-seat to enterprise platform fees; many warehouse-native options bill by compute only.
  • Path B: 1–3 months with integration; cost is mostly engineering plus compute.
  • Path C: 1–3 months; open source is free, costs are people and hosting; low compute needs.
  • Path D: 3–9 months with a data scientist.
  • KPIs: metric on a held-out time-based test set (AUC, MAPE, RMSE, lift), uplift versus the existing rule or naive baseline, time from question to deployed model, share of models still monitored, realised business effect (retention, stock-outs, DSO).

People & change

Start with management (budget, which decisions the model may influence) and the department lead who owns the question; add data owners of ERP/CRM early, since they release data and know its quirks. IT handles access and deployment, the DPO is needed whenever scores relate to individuals (customers, employees) for the legal basis, AVV and a possible DPIA (GUIDE-005).

Works council: depends. Models on customer or product data usually need none, but scoring of employees (absence, performance, attrition) or tools that log analysts' behaviour fall under §87(1) no. 6 BetrVG, and §90(1) no. 3 requires timely information when work processes are planned with AI; the council may engage an expert under §80(3). Public sector: staff council (GUIDE-004).

Measures to support AI literacy (Art. 4 AI Act) should cover reading metrics, leakage and bias, not only tool clicks (GUIDE-006). Pick one analyst plus one sceptical business user as pilot group (GUIDE-008). Typical concerns: "the black box replaces my judgement" (answer with feature importance and a human decision on every action) and "the numbers will be used to rank us" (agree purpose limitation in writing). Keep humans in control: scores are recommendations, thresholds and overrides are set by the department.

Risks, regulation & compliance

  • EU AI Act: depends on use. Churn, demand or maintenance prediction is typically minimal risk. Models that score natural persons for creditworthiness, insurance pricing in life/health, recruitment, worker evaluation or access to public benefits are high-risk (Annex III) with duties for data governance, documentation, human oversight and logging. Emotion inference at work and social scoring are prohibited (Art. 5). AI literacy (Art. 4) applies to the citizen analysts [5].
  • GDPR: customer or employee data in training sets needs a legal basis, purpose limitation and minimisation. Art. 22 limits solely automated decisions with legal or similarly significant effect; provide meaningful information about the logic. A DPIA is likely for profiling at scale [6].
  • Sector rules: credit scoring (EBA guidelines, Consumer Credit Directive), insurance (EIOPA), German works council co-determination for employee-related models.
  • Typical risks: proxy discrimination via features such as postcode, leakage, silent drift, shadow models built by citizen analysts outside governance.
  • Mitigations: model register, mandatory time-split validation, fairness checks on sensitive groups, named model owner, approval gate before production, drift monitoring, rollback plan.

Getting started

  1. Pick one decision with a measurable outcome and at least a year of history (e.g. late payers).
  2. Write down target, prediction time and what is known at that time, to avoid leakage.
  3. Run a baseline (rule or seasonal naive), then an open AutoML run (AutoGluon/FLAML) or a platform trial on the same split.
  4. Review explanations and errors with the business owner; check fairness if people are scored.
  5. Deploy as a batch score with monitoring and a monthly review of accuracy against outcomes.

Sources

  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