Hiring a dedicated data science team for every industrial machine is a proven way to burn budgets and blow past delivery deadlines. In heavy industry, potential use cases for machine learning exist at every stage of the process—from stabilizing technological regimes to minimizing raw material waste. However, scaling bespoke development across dozens of geographically distributed sites with bespoke specialists is physically impossible. Andrey Pisarev, Head of Machine Learning in the AI Technology Department at RUSAL, shared a pragmatic way out of this staffing bottleneck: replace one-off custom projects with an assembly line of standardized modules.
Assembly lines replace bespoke development
When a company runs dozens of industrial facilities worldwide with only a handful of in-house ML specialists, classic custom software development inevitably collapses. The only way to cover operations without ballooning payroll is to shift ML service creation to a standardized platform. RUSAL structured this process around the SinaraML framework and an on-premise infrastructure featuring NVIDIA A100 GPUs and a distributed Apache Ozone storage system holding roughly 0.5 PB (according to 2025 data from RUSAL's I.V. Kazarin).
The product lifecycle begins not with writing code, but with establishing strict boundaries of responsibility across four core roles: the process engineer, the business analyst, the data scientist, and the tech lead. Requirements are locked in a unified Definition of Ready (DoR) document. This immediately filters out unrealistic shop-floor requests and enables an objective assessment of on-site sensor reliability from day one.
"If we had built an ML product from scratch for every single site, we wouldn't have survived."
Once the DoR is approved, project roles diverge cleanly. Software engineers build integrations with the Kafka message broker, local databases, and UI layers; ML engineers allocate platform compute; and data scientists handle data pipelines, feature engineering, and the core standardized service. Meanwhile, the project manager frames business requirements and technical specifications without pulling the engineering team away from architecture design.
Local autonomy meets centralized control
Every algorithm is packaged as a standard Model Service artifact complete with versioning, data lineage tracking, and BentoML encapsulation exposed via REST API. To prevent forecast accuracy from degrading over time, the module connects directly to a Model Monitoring system for data drift detection. Without this engineering foundation, any production model turns into a liability the moment its author leaves the company.
The architecture relies on edge autonomy: individual factories run their own storage, local Model Service instances, and operator interfaces. Connectivity to the central platform in Moscow—home to long-term storage and central telemetry monitoring—is maintained via an enterprise service bus (ESB). If network connectivity to headquarters drops, the local service continues running the machinery autonomously, buffering telemetry to sync with Moscow once the connection restores.
Once proven, a production scenario scales to identical machinery without rewriting the codebase. For instance, an algorithm designed for a 150-meter nepheline sintering kiln at the Pikalevo Alumina Refinery (PGSU) required only minor calibration of thresholds and features before being prepped for rollout across the site's remaining five identical kilns.
The PGSU deployment illustrates the actual economics of industrial ML: moving from proof-of-concept (PoC) to closed pilot testing of a CatBoost model (MAE = 225, R² = 0.48, RMSE = 330) took three months, with expected savings running into tens of millions of rubles annually. For executive leadership, the takeaway is clear: scaling enterprise AI does not require endless data science hiring—it demands disciplined platform standards and modular architecture.