PaperlayerView exact revision on arXiv

Source-linked AI summary

Trustworthy Data- and ML-Ops for Intelligent Transportation Systems and Logistics

Antonio Emanuele Cinà, Giovanni Scodeller, Cecilia Caterina Pasquale, Silvia Siri, Davide Anguita, Fabio Roli, Simona Sacone, Luca Oneto

arXiv:2610.01282v1cs.AIcs.SE

TL;DR

ITS&L needs operational approaches for managing heterogeneous data and production ML while addressing trustworthiness, yet existing work does not fully integrate these concerns. This review examines DataOps, MLOps, and trustworthy-AI tools and practices in ITS&L. It finds DataOps adoption relatively mature, while systematic MLOps adoption and unified integration remain limited.

  • Problem

    The review identifies a lack of a unified framework integrating DataOps, MLOps, and trustworthy-AI principles for ITS&L.

    Source: §VII · p. 28

  • Method

    The paper reviews DataOps and MLOps practices, tools, and case studies in ITS&L alongside trustworthy-AI metrics, methods, and assessment tools.

    Source: §I · p. 2, C. Explainability · p. 23

  • Results

    The review finds DataOps solutions relatively mature in adoption, while systematic MLOps adoption is more limited and integration of DataOps, MLOps, and trustworthy AI remains incomplete.

    Source: §VIII · p. 30

  • Takeaways & Limitations

    The review presents tighter integration of DataOps, MLOps, and trustworthy-AI principles as a promising direction for future intelligent transportation and logistics services.

    Source: §VIII · p. 30

    The review identifies the absence of a single framework comprehensively integrating DataOps, MLOps, and trustworthy-AI principles.

    Source: §VII · p. 28

Abstract

from arXiv · show

The rapid evolution of Intelligent Transportation Systems and Logistics (ITS\&L) has become a cornerstone of the modern social economy, relying heavily on the integration of Data, Artificial Intelligence (AI), and, more specifically, Machine Learning (ML). This paper provides a comprehensive review of Trustworthy Data and Machine Learning Operations (DataOps and MLOps) in the ITS\&L domain, underscoring their importance in improving efficiency, reliability, and decision-making precision within transportation and logistics services. We begin by identifying gaps in current literature, offering clear context for our contribution. Subsequently, we explore the complexities of DataOps and MLOps, discussing their necessity, key components, available tools, practical insights, and case studies relevant to ITS\&L. Additionally, we address the critical issue of Trustworthiness in AI applications, examining methods and tools designed to strengthen confidence in AI systems - especially in real-world ITS\&L scenarios. The paper concludes with a discussion of persisting challenges and future prospects in this rapidly advancing field, aiming to serve as a vital resource for researchers, industry practitioners, and policy makers. Overall, this work not only establishes a foundational understanding of DataOps and MLOps in ITS\&L but also charts a path for further research and innovation in developing more efficient, sustainable, and trustworthy intelligent transportation and logistics systems.

I. INTRODUCTION

ITS&L increasingly relies on data and AI, but its high-volume, fast-moving, heterogeneous data and the need to monitor AI trustworthiness create operational challenges. The review examines how DataOps, MLOps, and trustworthy AI can address these needs and surveys tools, adoption, and open challenges.

I. INTRODUCTION

  • ITS&L data spans large volumes, real-time streams, and heterogeneous formats, creating collection, storage, and curation challenges.The 3V challenges arise from numerous monitored entities, the need for timely decisions, and varied data types, devices, formats, and frequencies.Source: §I · p. 1
  • AI systems require continuous monitoring of technical and human-related metrics to preserve appropriate behavior and build trust, with Generative AI and regulation adding urgency.Examples include accuracy and non-regressiveness alongside robustness, fairness, and privacy; the passage also points to the AI Act.Source: §I · p. 1
  • DataOps manages data workflows, while MLOps supports production ML models through scalable deployment, continuous learning, and monitoring of technical and human-related metrics.MLOps also supports automated retraining, reproducible versioned workflows, and regulatory compliance.Source: §I · p. 2
  • DataOps governs ingestion, processing, and storage of heterogeneous data streams, and MLOps governs model training through deployment and monitoring to support trustworthy ITS&L services.Figure 1 depicts heterogeneous sources flowing through DataOps and MLOps, with trustworthy-AI principles as a governance layer.Source: §I · p. 2, Figure 1 · p. 2
  • The review surveys prior-review gaps, DataOps and MLOps tools and adoption, trustworthy-AI metrics and adoption, their synergies, and unresolved challenges.It also covers practical insights and ITS&L case studies for DataOps and MLOps.Source: §I · p. 2
  • The review is intended as a structured entry point for researchers and a resource on operational implications, tools, case studies, gaps, and future directions for practitioners and senior researchers.The paper also covers ITS&L application areas and challenges, DataOps, MLOps and LLMOps, trustworthy AI, and future perspectives.Source: §I · p. 2

II. LITERATURE REVIEW

The review uses a targeted search of recent surveys to identify gaps in integrated coverage of DataOps, MLOps, trustworthy AI, and ITS&L. It also organizes ITS&L applications by shared operational challenges and domain-specific requirements.

II. LITERATURE REVIEW

  • The survey search covered the last 10 years in Scopus and Google Scholar, using operational-AI and ITS&L terms alongside review and survey terms.The screening also considered cited reviews and broader adjacent-area terminology, reporting prominent terms directly related to the paper's scope.Source: §II · p. 3
  • Existing surveys often treat trustworthy AI, DataOps, and MLOps separately, while the review jointly examines five trustworthiness dimensions and tools for assessing them across the lifecycle.The five dimensions are robustness, interpretability, fairness, sustainability, and privacy.Source: §II · p. 3

III. INTELLIGENT TRANSPORTATION SYSTEMS AND LOGISTICS

  • The review organizes ITS&L applications into a taxonomy that groups areas by shared DataOps, MLOps, and trustworthy-AI challenges and connects them to domain-specific operational requirements.Requirements include real-time processing, scalability, safety, privacy, fairness, sustainability, and explainability.Source: §III · p. 3
  • Vehicle control systems require real-time testing and monitoring, protection of sensitive driver data, and scalability across changing traffic and connected-vehicle conditions.The systems include driver-assistance and autonomous-vehicle technologies, among others.Source: §III · p. 3
  • Traffic management requires timely network-level data processing while addressing privacy, security, fairness in recommendations and pricing, and environmental sustainability.Its applications extend beyond roads to navigation and air, water, and rail transport systems.Source: §III · p. 5
  • Freight and supply-chain systems span multimodal cargo, warehousing, and last-mile delivery, where delays or compromised data can propagate into logistics errors and financial losses.Continuous integrity monitoring, scalability, and bias mitigation are identified as needs across these systems.Source: §III · p. 5
  • Emergency management must collect and process data quickly while protecting data integrity and preserving fairness in crisis response and humanitarian relief.These systems coordinate timely delivery of emergency resources and rescue services.Source: §III · pp. 5–6

IV. DataOps

ITS&L data management must address growing volume, velocity, and variety, while DataOps organizes data across its lifecycle for downstream analytics and machine learning. These demands are especially acute in real-time traffic and emergency management.

IV. DataOps

  • DataOps integrates practices and technologies across the data lifecycle to make ITS&L data efficiently processed and available for downstream analytics and machine-learning workflows.The paper situates DataOps as a layer that transforms heterogeneous data sources into reliable, monitored, and reusable data assets.Source: §IV · p. 6

A. Motivations

  • Volume, variety, and velocity drive DataOps adoption across ITS&L, with variety and velocity especially important for real-time traffic and emergency management.Those applications must collect from different sources continuously and process data in real time to maintain service quality and usefulness.Source: A. Motivations · p. 6
  • Inefficient handling of growing data volumes can delay processing and feed outdated or inaccurate information into decisions, while overwhelming storage and risking data loss or corruption.The paper gives traffic-light timing and route recommendations as examples of decisions affected by outdated data.Source: A. Motivations · p. 6
  • ITS&L operations rely on timely processing for route optimization, delivery-time reduction, traffic updates, and logistics efficiency; lagging processing can compromise service or cause system crashes.Delayed traffic updates can yield suboptimal routes, while slow delivery processing can disrupt schedules and lead to missed delivery windows.Source: A. Motivations · p. 6
  • ITS&L data now spans graphs, sequences, logs, audio, and natural language as well as tabular formats, requiring strategies for versioning, processing, and linking diverse data.The paper notes that poorly integrated formats can fragment data into silos and impair analysis and decision-making.Source: A. Motivations · p. 7

B. DataOps Lifecycle

The paper proposes an iterative, eight-step DataOps lifecycle because agreement on the lifecycle’s start and end points exceeds consensus on its intermediate stages. Its stages cover data acquisition through monitoring and feedback.

B. DataOps Lifecycle

  • The proposed generalized DataOps lifecycle has eight steps: ingestion, processing, storage, analysis and visualization, release, deployment, monitoring, and feedback.The model follows an iterative workflow intended to support continual refinement and adaptation to evolving application requirements.Source: B. DataOps Lifecycle · p. 7
  • Ingestion plans, acquires, and loads data with metadata from varied sources into centralized storage, based on application needs and expected data volume.The paper aligns this stage with DevOps planning.Source: B. DataOps Lifecycle · p. 7
  • Processing cleans, filters, and refines acquired data to meet metadata-defined formats and structures, tracking and possibly correcting inaccuracies or inconsistencies.The paper aligns this stage with DevOps coding.Source: B. DataOps Lifecycle · p. 7
  • Storage manages the volume, velocity, and variety of pipeline data; the paper describes data lakehouses as a centralized option for structured, semi-structured, and unstructured data.The lifecycle discussion aligns storage with the DevOps build stage.Source: B. DataOps Lifecycle · p. 7
  • Analysis and visualization inspect stored data to test pipeline operation and provide data to higher-level services, including MLOps.The paper aligns these stages with DevOps testing and describes the DataOps substrate as supporting services from real-time tracking to AI applications.Source: B. DataOps Lifecycle · p. 7
  • Release checks data consistency and pipeline function before deployment; monitoring tracks pipeline health and performance, and feedback uses monitoring and user or downstream input to improve other stages.Monitoring may track throughput, processing time, and error rates and use alerts to notify teams about issues or anomalies.Source: B. DataOps Lifecycle · pp. 7–8

C. Open-Source Solutions

The DataOps tool landscape spans open-source components that are often combined and proprietary services that offer integrated pipeline capabilities. Their trade-offs include flexibility and customization alongside support, cost, and deployment constraints.

C. Open-Source Solutions

  • Open-source tools support different DataOps pipeline components, and practitioners typically combine multiple tools rather than relying on one tool for the complete pipeline.The section emphasizes customization and integration with third-party libraries as advantages of open-source tools.Source: C. Open-Source Solutions · p. 8
  • Apache Kafka supports DataOps ingestion and monitoring with high-throughput, low-latency handling of large data volumes and security features.The passage describes encryption in transit, authentication, and authorization.Source: C. Open-Source Solutions · p. 8
  • HDFS supports DataOps storage across cluster nodes, with replication for reliability, node additions for scalability, and support for unstructured data.The passage lists tables, text, audio, video, and images among the data types it handles.Source: C. Open-Source Solutions · p. 8
  • Apache Spark is presented as a scalable in-memory processing framework, while Flink is presented as a stream-processing option for continuous data management.The passage says stream processing can reduce storage requirements compared with batch processing, and that the choice depends on task requirements such as precision, velocity, and efficiency.Source: C. Open-Source Solutions · p. 8
  • DataOps operations tools cover release, deployment, monitoring, alerting, visualization, and feedback, including dbt, Docker and Kubernetes, Prometheus, Airflow, Jenkins, Power BI, Tableau, and version control systems.The passage describes Git and SVN as supporting an iterative feedback loop and continuous improvement in data-related operations.Source: C. Open-Source Solutions · p. 8

D. Proprietary Solutions

  • Proprietary solutions offer integrated, user-friendly coverage of DataOps steps, support, and enterprise-oriented features, with licensing costs, potential vendor lock-in, and limited customization as drawbacks.Google Cloud Dataflow and Amazon EMR are cloud-managed and cannot be served on-premise, while Azure Data Factory allows on-premise deployment.Source: D. Proprietary Solutions · pp. 8–9

E. Solutions Comparison

The reviewed DataOps tools trade integration effort and customization against usability and support. ITS&L case studies show recurring data-management needs across application areas, with their relative importance varying by domain.

E. Solutions Comparison

  • Open-source DataOps tools are cost-effective, reliable, interoperable, customizable, and popular, but often require advanced skills and multiple components for an end-to-end pipeline.Practitioners may need to integrate tools designed for specific purposes; the required integration, deployment, and maintenance skills restrict adoption in some contexts.Source: E. Solutions Comparison · p. 9
  • Proprietary DataOps solutions offer integrated, user-friendly pipelines and enterprise support, but are less customizable and can entail lock-in and difficult cost-benefit trade-offs.The passage also identifies safety, security, and service continuity as considerations when assessing costs and benefits.Source: E. Solutions Comparison · p. 9

F. Case Studies

  • The reviewed case studies span six ITS&L areas and commonly use open-source Apache technologies in real-world DataOps deployments.The review presents cases from the last ten years, highlighting complex data-management challenges and complementary examples.Source: F. Case Studies · p. 9
  • The review identifies an opportunity to document DataOps applications more fully across the supply chain because some studies do not explicitly address big-data challenges or tools.The cited passage notes that additional studies exist but often omit those details.Source: F. Case Studies · p. 11
  • Across ITS&L domains, DataOps pipelines address recurring data-management challenges, but priorities vary by application area and Apache technologies recur frequently.Vehicle control and traffic management emphasize high-volume, high-velocity data; freight and supply chains emphasize integration, while emergency management emphasizes low latency.Source: F. Case Studies · pp. 11–12

V. MLOps

In ITS&L, MLOps provides a dedicated, automated workflow for developing, deploying, monitoring, and updating ML models. The review motivates it through continuous data and technology change, ML design complexity, monitoring demands, and deployment needs.

V. MLOps

  • MLOps extends DevOps with an automated ML lifecycle because ML systems require continuous updates and bring distinct design, deployment, and monitoring challenges.Its activities include training, testing, release, deployment, monitoring, and feedback, building on reliable DataOps pipelines for operational ITS&L services.Source: §V · p. 12

A. Motivations

  • Changing ITS&L data and evolving ML methods require continuous model updates, while manual tuning, retraining, versioning, testing, deployment, and monitoring can slow upgrades.MLOps supports an automated pipeline that incorporates new knowledge from collected data and newly developed models.Source: A. Motivations · pp. 12–13
  • ML design changes can affect an interconnected pipeline, while hyperparameter tuning and a fragmented, changing library ecosystem add ongoing management complexity.The review also notes the need to monitor interactions with traditional software, library maintenance, and licensing changes.Source: A. Motivations · p. 13
  • Model monitoring must track both input data and model results, including outliers or drift and multiple technical and ethical metrics.The cited discussion names accuracy, robustness, energy, explainability, fairness, and privacy among relevant metrics; monitoring does not eliminate security issues.Source: A. Motivations · p. 13
  • ML deployment must support reproducibility and scalable resource allocation across computationally demanding training jobs and high-volume test requests.MLOps supports traceability and automated deployment in both training and test phases.Source: A. Motivations · p. 13

B. MLOps Lifecycle

The MLOps lifecycle is an iterative workflow that links data preparation and model development to production operations and feedback. Its stages connect DataOps data, model selection against multiple requirements, and ongoing monitoring and refinement.

Lifecycle overview

  • The eight-stage MLOps lifecycle runs from data collection and data engineering through training, testing, release, deployment, monitoring, and feedback.The workflow is described as iterative, supporting continuous refinement and adaptation to evolving application requirements.Source: B. MLOps Lifecycle · p. 13

Data collection and engineering

  • Data collection retrieves application-relevant data from DataOps pipelines, while data engineering cleans data and prepares features for ML algorithms.Feature engineering transforms raw data into useful inputs; manually designed features are common for tabular or mildly unstructured data, while unstructured-data representations can be learned from data.Source: B. MLOps Lifecycle · pp. 13–14

Model training

  • Model training defines candidate algorithms, architectures, and hyperparameters, then fits a selected configuration by optimizing its parameters on training samples.Choices depend on experience, data type, business and user requirements, and computational resources; fitting iteratively updates parameters to minimize a predefined loss.Source: B. MLOps Lifecycle · p. 14

Model validation

  • Model validation selects among candidate models using multiple technical, ethical, and business metrics on validation data, balancing metrics that may conflict.Poor evaluation can prompt training changes, while performance beyond application requirements may justify reducing model complexity to lower computational demands.Source: B. MLOps Lifecycle · p. 14

Release, deployment, monitoring, and feedback

  • Release checks model consistency and dependencies; deployment scales the model, and monitoring tracks operational performance and gathers feedback for refinement.Monitoring can use a subset, the same set, or a superset of validation metrics, and can reveal abrupt behavioral deviations associated with data or evaluation changes.Source: B. MLOps Lifecycle · p. 14

C. Open-Source Solutions

The reviewed MLOps offerings range from focused open-source tools to domain-specific platforms and proprietary services. A single tool often covers only part of the lifecycle, so complete workflows may combine tools.

C. Open-Source Solutions

  • Open-source MLOps tools support customizable workflows, but a single tool often implements only part of the lifecycle, requiring developers to combine tools.These tools can integrate third-party libraries and benefit from open-source community support and documentation.Source: C. Open-Source Solutions · pp. 14–15
  • Metaflow supports feature engineering, model building, training, validation, and deployment, while ZenML organizes workflow steps as reusable components and integrates tracking and monitoring tools.The review describes Metaflow as suited to data-intensive applications and ZenML as emphasizing reproducibility and consistency across environments.Source: C. Open-Source Solutions · p. 15
  • BentoML focuses on model release and deployment rather than the entire lifecycle, whereas Kubeflow targets ML workflows and deployment within Kubernetes environments.BentoML supports multiple frameworks and deployment options; Kubeflow emphasizes orchestration, scalability, resource management, and reproducibility in Kubernetes.Source: C. Open-Source Solutions · p. 15
  • Apollo is a domain-specific operational stack for autonomous driving, supporting model development, simulation-based validation, deployment, and runtime execution.The review contrasts it with general-purpose MLOps tools and identifies vehicle control as its focus.Source: C. Open-Source Solutions · p. 15

D. Proprietary Solutions

  • Vertex AI provides model lifecycle tools and production monitoring, while Watson Studio supports cloud or on-premise deployment and native data-quality and drift metrics.Vertex AI includes AutoML and custom training; Watson Studio combines open-source frameworks with IBM tools and risk-management scores.Source: D. Proprietary Solutions · pp. 15–16
  • Azure ML and SageMaker support large-scale pipelines and popular languages and libraries, while MATLAB and Simulink offer end-to-end workflows with AutoML and drift detection.The review notes on-premise use for Azure ML and real-time Kafka-stream monitoring and model creation for MATLAB and Simulink.Source: D. Proprietary Solutions · p. 16

E. Solutions Comparison

The review contrasts trade-offs among proprietary and open-source MLOps tools and finds that MLOps adoption in ITS&L is less mature than DataOps, with limited evidence on full lifecycle practices. Case studies vary by domain, from more complete logistics deployments to less explored traveler-information and emergency applications.

E. Solutions Comparison

  • The tool comparison covers lifecycle coverage, AutoML, deployment, end-to-end support, scalability, and limitations; proprietary and open-source options each involve trade-offs.Proprietary tools may offer scalable, user-friendly pipelines but can cost more and constrain on-premise or hybrid deployment; open-source tools offer customization but can require ongoing maintenance.Source: E. Solutions Comparison · p. 16, Table III · p. 17

F. Case Studies

  • Transportation-management case studies range from conceptual architectures to a tram-positioning pipeline tested on two routes.The conceptual architectures emphasize delivery, verification, and safety assessment; the tram pipeline continuously integrates onboard-camera images.Source: F. Case Studies · p. 18
  • MLOps adoption in ITS&L remains less mature than DataOps, with few studies addressing the full ML lifecycle beyond training and evaluation.Across current case studies, evidence is limited on retraining, versioning, deployment, monitoring, and post-deployment updates.Source: F. Case Studies · pp. 18–19
  • Vehicle-control applications emphasize safety-aware continuous verification and monitoring under changing road, traffic, and environmental conditions.Reviewed work also addresses automation of data management, training, and monitoring, and monitoring for out-of-distribution data.Source: F. Case Studies · pp. 17–18
  • Traffic-management applications highlight periodic retraining and elastic inference, while some reviewed systems still lack scalable automatic deployment.Foresight periodically retrains traffic models; Foresight Plus uses on-demand inference services for workloads with idle periods and peaks.Source: F. Case Studies · pp. 17, 19
  • Freight and supply-chain logistics provide some of the most complete MLOps examples, automating training, deployment, and monitoring across distributed networks.Examples use tools including Airflow, Kubeflow, and cloud services.Source: F. Case Studies · pp. 18–19
  • Traveler-information and emergency-management applications remain less explored, often relying on conceptual frameworks or application-level ML rather than mature lifecycle automation.The emergency examples include flood detection and mapping, while the traveler-information study remains largely conceptual.Source: F. Case Studies · pp. 18–19

G. The Recent LLMOps Development

The review frames LLMOps as an extension of MLOps for foundation-model applications, with lifecycle practices adapted to their data, modeling, validation, and deployment needs. It also describes specialized tools and evaluation that combine automated metrics with human judgment.

LLMOps scope

  • LLMOps specializes MLOps for foundation-model applications, while FMOps generalizes operational concerns beyond text to multimodal and generative models.The survey uses LLMOps as its main reference because that term is more consolidated in the literature.Source: G. The Recent LLMOps Development · p. 19

Data Collection

  • LLMOps data collection prioritizes diverse, representative, high-quality task data over the large labeled datasets often used to train classical ML models from scratch.For ITS&L, the review points to reliable domain evidence such as current traffic conditions, operational constraints, regulations, and service information.Source: G. The Recent LLMOps Development · p. 19

Feature engineering

  • LLMOps feature engineering includes prompt design and retrieval of external knowledge to supply task-specific context at inference time.RAG retrieves relevant documents or data sources for a user query and incorporates them into the prompt.Source: G. The Recent LLMOps Development · p. 19

Model Training

  • Downstream LLMOps training generally adapts a selected pretrained model rather than training an LLM from scratch.Model engineering can include instruction tuning or parameter-efficient fine-tuning, model selection for subtasks, and safety alignment mechanisms or guardrails.Source: G. The Recent LLMOps Development · pp. 19–20

Model Validation

  • Generative LLM validation needs task-specific metrics alongside human assessment, and monitoring also tracks biases, ethical issues, and unintended consequences.Human evaluators assess qualities such as coherence, relevance, contextual appropriateness, and grammatical correctness.Source: G. The Recent LLMOps Development · p. 20

Release, Deploy, Monitoring, and Feedback

  • LLMOps deployment must address substantial resource and memory demands during training, fine-tuning, and inference, using specialized infrastructure and optimization.The reviewed tool ecosystem includes model and dataset resources, inference serving, application development, and continuous validation and safety evaluation.Source: G. The Recent LLMOps Development · p. 20

H. Emerging AgentOps for Agentic AI Systems

AgentOps extends model-focused operations to the runtime behavior of agentic workflows. Its broader operational scope reflects the risks of tool use and multi-step actions, while the field remains methodologically immature and this review offers only an introduction.

AgentOps scope

  • Agentic systems can pursue goals through intermediate steps, using tools, retrieved information, memory, users, or other agents; AgentOps governs their runtime workflows.Unlike LLMOps, AgentOps is system-oriented and does not replace MLOps or LLMOps.Source: H. Emerging AgentOps for Agentic AI… · pp. 20–21

Operational scope and risks

  • AgentOps monitors the full execution trajectory, including prompts, retrieved information, tool calls, memory updates, external interactions, and final actions.Risks include incorrect tool calls, unstable planning, memory failures, prompt injection, cascading errors, and emergent multi-agent behavior.Source: H. Emerging AgentOps for Agentic AI… · p. 21

Operational mechanisms

  • AgentOps mechanisms aim to make workflows traceable, check policy consistency, identify failure origins, and support corrective intervention during execution.The monitored object is the complete agentic system, not only its underlying model.Source: H. Emerging AgentOps for Agentic AI… · p. 21

Scope and maturity

  • AgentOps remains less methodologically mature, standardized, and systematically adopted than DataOps and MLOps, and the survey does not treat it comprehensively.The review introduces it as a recent development relevant to future ITS&L deployments.Source: H. Emerging AgentOps for Agentic AI… · p. 21

VI. TAI

The review presents trustworthy AI as a cross-cutting concern for DataOps and MLOps, requiring technical and ethical metrics suited to application needs. It also surveys sustainability pressures and measures for AI training and operation in ITS&L.

VI. TAI

  • Optimizing a single AI metric can conflict with hidden or implicit metrics, while technical and ethical concerns make trustworthy AI important across decision-making domains.The review highlights risks including shortcut learning, spurious correlations, bias, hallucinations, and reduced robustness.Source: §VI · p. 21
  • Trustworthy-AI metrics and mitigation strategies span data quality, model behavior, and deployed services, cutting across DataOps and MLOps lifecycles.The review focuses on sustainability, robustness, explainability, fairness, and privacy, while noting other metrics may also matter.Source: §VI · pp. 21–22

A. Sustainability

  • ML training and inference carry economic and environmental costs, and training demands substantial data and computation.Strategies include data selection, transfer learning, smaller or lower-precision models, suitable optimizers, and custom hardware; high-end hardware can remain cost-prohibitive or technically difficult.Source: A. Sustainability · p. 22
  • High prediction volumes and hardware limits can make even small per-inference savings consequential for sustainability, prediction time, and costs in ITS&L.Hardware accelerators may be impractical in some cases.Source: A. Sustainability · p. 22
  • Sustainability monitoring can combine cost, carbon-emission, and power metrics with lower-level model factors in MLOps pipelines.The reviewed tools include CodeCarbon and CarbonTracker for emissions, Eco2AI for power and emissions, and Scaphandre and PowerJoular for power consumption.Source: A. Sustainability · p. 22

B. Robustness

Robustness, explainability, and fairness are central trustworthiness concerns for ML systems in ITS&L, with assessment methods and tools available but important evaluation challenges remaining.

B. Robustness

  • Robustness assessment spans attack success, performance under attack or distribution shift, and energy consumption, but empirical tests can mislead and formal verification faces scalability limits.Tools include FoolBox, SecML, CleverHans, and Art; many tools and datasets target image vision, leaving other input domains without standardized benchmarks.Source: B. Robustness · pp. 22–23

C. Explainability

  • XAI distinguishes transparent models from post-hoc explanations, which can describe overall model behavior or individual predictions.Explanations can be assessed for accuracy, fidelity, correctness, consistency, stability, certainty, and feature importance; tools include Captum, AI Explainability 360, and InterpretML.Source: C. Explainability · pp. 23–24

D. Fairness

  • ITS&L fairness concerns include unequal treatment of similar individuals and unequal outcomes across groups, with individual and group fairness representing distinct notions.Demographic Parity, Equality of Opportunity, and Equal Odds assess group fairness; individual measures include Fairness Through Awareness and Counterfactual Fairness.Source: D. Fairness · p. 24
  • Fairness interventions operate before training through data preprocessing, during training through fairness constraints, or after training by adjusting model outputs.Fairlearn and AIF360 support fairness assessment and mitigation, while Fairness Indicators enables evaluation across data slices.Source: D. Fairness · pp. 24–25

E. Privacy

Privacy-preserving ML methods trade privacy, utility, and computational cost in different ways. ITS&L case studies address these and other trustworthiness principles, but holistic integration remains uncommon.

E. Privacy

  • Privacy risks involve both personal data and proprietary model information, while protecting sensitive location or travel data can conflict with service value.Privacy attacks include reconstruction, model inversion, membership inference, and model discovery.Source: E. Privacy · p. 25
  • Anonymization and perturbation can reduce utility, while cryptographic and distributed methods preserve privacy and utility at computational or communication cost.Federated methods still risk disclosure through shared local updates and are often combined with perturbation or cryptographic methods.Source: E. Privacy · p. 25
  • Privacy-preserving ML is assessed through privacy-leakage, data-utility, and computation metrics; available tools cover anonymization, differential privacy, encryption, federated learning, and secure computation.Examples include ARX, TensorFlow Privacy, Microsoft SEAL, Flower, and PySyft.Source: E. Privacy · p. 25

F. Case Studies

  • Case studies cover privacy, fairness, and sustainability across logistics and transport, including fairer delivery pay, lightweight models, and fairness-aware emergency allocation and routing.FairFoody reports up to a tenfold improvement in equitable pay over baseline strategies with limited impact on customer satisfaction; one emergency-allocation study does not consider robustness or privacy.Source: F. Case Studies · pp. 27–28
  • Across ITS&L case studies, trustworthiness work is fragmented, with most studies addressing only a few principles and limited joint integration into operational pipelines.The reviewed domains differ in emphasis: vehicle control spans several principles, while emergency management studies focus on fairness in resource allocation and response.Source: F. Case Studies · pp. 26, 28

VII. OPEN PROBLEMS AND FUTURE PERSPECTIVES

The review identifies gaps in integrating DataOps, MLOps, and trustworthy AI in ITS&L, alongside uneven adoption and coverage. It points to unified lifecycle support and broader research across principles and application areas as open needs.

Synthesis

  • Table IV summarizes case studies across DataOps, MLOps, and TAI, providing a visual overview of their integration and unresolved challenges.The review frames this synthesis as a basis for identifying future research directions.Source: §VII · p. 28, Table IV · p. 29

Lack of a Unified Framework for DataOps, MLOps, and TAI Integration

  • No existing approach comprehensively unites DataOps, MLOps, and trustworthy AI; integrative approaches exist but remain exceptions, and a conceptual model lacks implementation guidelines.Some DataOps frameworks focus on automation while overlooking data quality, security, poisoning defenses, and fairness.Source: §VII · p. 28

Limited Adoption to MLOps and Emerging Needs for LLMOps in ITS&L

  • MLOps is less widely adopted than DataOps in ITS&L, and publicly documented LLMOps implementations remain limited despite growing LLM adoption and lifecycle-governance complexity.The review identifies systematic MLOps and LLMOps integration as an avenue for future research.Source: §VII · p. 28

Unequal and Non-Holistic Attention to TAI Principles

  • TAI attention is imbalanced: privacy and sustainability receive substantial attention, while fairness and explainability receive less scrutiny and principles are often studied individually.The review calls for lifecycle methods and tools that address trustworthiness dimensions holistically.Source: §VII · pp. 28–29

Unbalanced Coverage of Case Studies Across Areas

  • Case-study coverage is uneven, concentrating on traffic management and vehicle control while emergency management, warehousing, and delivery remain underexplored.Confidentiality constraints can impede data sharing and make large-scale empirical validation and detailed methodological publication difficult in emergency management.Source: §VII · p. 29

VIII. CONCLUSIONS

The review finds DataOps adoption relatively mature, while systematic MLOps adoption is more limited and unified DataOps, MLOps, and TAI deployments remain uncommon. It calls for lifecycle trustworthiness and tighter integration as AI systems in ITS&L grow more complex.

VIII. CONCLUSIONS

  • DataOps manages large-scale, heterogeneous data pipelines, while MLOps supports systematic development, deployment, monitoring, and maintenance of production ML models.The review presents these complementary capabilities as fundamental to addressing operational challenges in ITS&L.Source: §VIII · p. 30
  • DataOps adoption is relatively mature, but systematic MLOps adoption is more limited and unified DataOps, MLOps, and TAI deployments remain uncommon.The review calls for TAI-oriented solutions to remain robust, explainable, fair, sustainable, and privacy-preserving throughout their lifecycle.Source: §VIII · p. 30
  • LLMOps and future AgentOps address the operational demands of increasingly complex AI systems, which add models, tools, data sources, and software components to manage across their lifecycle.The review anticipates a shift from isolated models toward governing integrated data- and AI-driven ecosystems.Source: §VIII · p. 30
  • Future progress depends on methodologies, tools, and standards that keep systems reliable, transparent, sustainable, and aligned with trustworthiness requirements throughout their lifecycle.The review identifies tighter integration of DataOps, MLOps, and TAI principles as a promising direction for future ITS&L services.Source: §VIII · p. 30
Loading 2610.01282v1…