The problem LaredoMLOps addresses is one of the most persistent in data science: expertise is scarce, and machine learning remains technically demanding. Building, training, deploying and maintaining models requires fluency in programming, statistics, cloud computing and data visualization — a multidisciplinary skill set that few domain experts possess. As a result, many organizations must rely on a limited pool of data scientists, which constrains how widely data-driven approaches can be adopted. Automation frameworks such as Automated Machine Learning (AutoML) and Machine Learning Operations (MLOps) have emerged to reduce this burden by handling algorithm selection, hyperparameter tuning, deployment, monitoring and retraining, but the platforms that implement them come with trade-offs that exclude precisely the users who need help most.

The existing landscape splits into three camps, each with significant constraints. Cloud-provider ecosystems — Amazon SageMaker Canvas, Google Vertex AI and Microsoft Azure Machine Learning — offer comprehensive end-to-end solutions with AutoML and no-code interfaces, but they promote vendor lock-in and rely on pay-as-you-go pricing. Trial credits exist, yet the absence of stable free tiers and the unpredictability of operational costs pose serious barriers for budget-constrained organizations. Specialized commercial platforms such as DataRobot, H2O.ai and BigML provide advanced capabilities, including automated model generation and large language model integration, but they are predominantly proprietary, require paid licenses for full functionality — especially for production deployment and monitoring — and some still demand coding expertise. Workflow-oriented tools such as KNIME and Altair RapidMiner began as open-source projects with strong visual programming interfaces, but their evolution toward freemium models has restricted critical lifecycle stages like deployment, monitoring and version control behind paid subscriptions. Other open-source alternatives fall short in different ways: Besser focuses on code generation rather than training and deploying models, while Weka lacks version control and deployment capabilities entirely.

LaredoMLOps deliberately covers all stages of the machine learning lifecycle except two: exploratory data analysis and production monitoring. The exclusions are principled rather than accidental. Exploratory data analysis is inherently iterative and dependent on domain knowledge, requiring human interpretation, hypothesis formulation and interactive visualization; fully automating this phase in a no-code setting risks oversimplification and misleading conclusions. Production monitoring, meanwhile, is strongly context-dependent, tied to organizational infrastructures, deployment platforms and operational constraints such as data drift, concept drift and alerting policies. Implementing generic no-code solutions across heterogeneous environments remains a formidable challenge. By excluding both, the platform preserves usability and simplicity while still adhering to good MLOps practices, assuming that users supply datasets that have already undergone initial validation and exploration, and providing generic monitoring metrics designed to be handled by external specialized components.

Architecturally, the platform consists of three main components: a backend, an AI-based assistant and a frontend. The backend is a REST API built in Python containing all the application logic and handling training, logging and deployment tasks. Machine learning and deep learning models are created using the well-known Python packages scikit-learn, PyTorch and AutoGluon. For version control and experiment tracking, the backend connects to an MLflow server, which stores logs in a relational database and artifacts in an object store. Deployment is handled by KServe: the backend creates a KServe InferenceService object in Kubernetes that runs an inference service through a REST or GRPC API, so client applications can consume the model. Currently the platform uses KServe’s Kubernetes-native serving mode, which deploys a single pod replica by default to minimize resource consumption in on-premises environments. Because the serving layer is fully decoupled and managed via Helm charts, users can configure Kubernetes Horizontal Pod Autoscaling or event-driven autoscaling mechanisms such as KEDA at the cluster level to handle high-concurrency production workloads without modifying the platform’s core code.

The AI-based assistant is built as a Retrieval-Augmented Generation (RAG) system using Python and LangChain to manage communication with the user, translate messages to match the user’s language and maintain conversation history. The system is model-agnostic, supporting both commercial APIs — specifically Gemini 3.1 Flash Lite — and local, reproducible open-weight models such as Gemma 4. Its knowledge base draws on documentation extracted from the official scikit-learn, PyTorch and AutoGluon websites, plus custom documentation on the use of the tool itself. The chatbot interface is implemented as a React component integrated into the application’s frontend, allowing users to ask questions about the application, receive recommendations for parameter tuning, or obtain explanations about how the underlying algorithms work. Every component of the application is packaged as a Docker image and shipped with a Helm chart for deployment on a Kubernetes cluster, with configuration parameters to connect to external MLflow servers and object stores or to deploy local versions of them inside the same cluster for development purposes.

The tool offers two modes for creating machine learning pipelines. The basic mode is built on the AutoML framework AutoGluon and lets users choose the kind of problem — regression, classification or clustering — along with the expected quality of the final model, a time limit for the training process and the validation metric, such as accuracy or F1, used to evaluate candidate models. The advanced mode, built on scikit-learn, lets users design pipelines in three steps: choosing which dataset columns to drop, selecting preprocessing steps from three categories — standardisation, null imputation and feature selection — and choosing the algorithm. After training, models are evaluated, versioned and stored in the model registry to enable systematic control, comparison and lifecycle management. Users can search previously trained pipelines, view their details including a diagram of the pipeline, and deploy them on the inference server.

The usability evaluation involved 14 master’s students with different backgrounds: eight specialized in computation, three in computer engineering and three in software engineering. They were selected for their familiarity with advanced digital systems and prior experience with usability evaluation techniques, providing the perspective of people with a computing background but not specialized in data science, alongside users familiar with machine learning projects. After a brief introduction, participants completed nine predefined tasks in a controlled laboratory environment, ranging from creating classification and regression models to configuring preprocessing pipelines and comparing model performance, with a maximum session duration of 45 minutes. Subjective usability was measured with the System Usability Scale and cognitive workload with the NASA Task Load Index. The SUS score of 87.69 exceeds the 80-point threshold for excellent usability according to established guidelines. Most questionnaire responses concentrated between 4 and 5 on the five-point Likert scale, with several questions showing more than 70 percent of respondents selecting the highest score and no responses in the lowest categories. NASA-TLX responses revealed moderate to low perceived cognitive effort, with limited temporal pressure, acceptable mental demand and low frustration. Task completion times showed a high degree of consistency, with standard deviations below one minute for all tasks except the first two — which involved participants’ first interaction with the tool — and Tasks 5 and 9, which required comparing trained models to identify the best-performing configurations. Average completion time for most tasks was approximately 1.5 minutes.

Qualitative feedback highlighted the structured workflow, the availability of both basic and advanced modes, and especially the support provided by the integrated chatbot for task completion and understanding of results. Some comments pointed to areas for improvement, including clearer guidance in advanced configurations, occasional ambiguity in parameter selection and opportunities to improve interface intuitiveness when building custom pipelines. To demonstrate the platform end-to-end, the developers applied it to a credit fraud detection problem using a Kaggle dataset of 10,000 simulated credit card transactions reflecting realistic class imbalance between legitimate and fraudulent cases. In advanced mode, the workflow involved uploading a CSV file, confirming data types and the target variable, dropping the transaction_id attribute, handling missing values with a SimpleImputer, transforming the merchant_category attribute with an OrdinalEncoder, normalizing numerical features through StandardScaler, training a Random Forest model with default parameters, and deploying it as a KServe inference service accessible through an OpenAPI Swagger interface within seconds.

The software is actively used within the developers’ research group and by partners in their consortium, and it has been incorporated into several project deliverables in the logistics sector and internal experiments. As an open-source solution, it addresses the cost limitations of proprietary platforms such as DataRobot or Google Vertex AI, which remain inaccessible to organizations with limited budgets and to educational institutions. It does exclude exploratory data analysis and production monitoring to preserve simplicity, and it currently supports a narrower range of algorithms than commercial alternatives. Future work includes broadening the number and complexity of supported algorithms, adding explainable AI capabilities and real-time monitoring features to the inference services, improving dataset management, grouping models into experiments to simplify comparison during model selection, and extending the usability evaluation to broader user groups including domain experts. The evaluation was carried out on machines with an Intel Core i5 processor and 16 GB of RAM, sufficient for development and testing purposes, though a dedicated GPU is recommended for computationally demanding models such as neural networks.

Subject of Research: Machine learning software engineering

Article Title: LaredoMLOps: a friendly tool for modelling and deploying AI models

Article References: Dintén, R., & Zorrilla, M. (2026). LaredoMLOps: a friendly tool for modelling and deploying AI models. SoftwareX, 36, Article 103153. https://doi.org/10.1016/j.softx.2026.103153

Image Credits: AI Generated

DOI: 10.1016/j.softx.2026.103153

Keywords: machine learning, MLOps, open source, AutoML, usability, artificial intelligence, software engineering, data science, LaredoMLOps, friendly, tool, modelling