Paper deep dive

On AI Safety and Security Technical Debt in Engineering AI-Enabled Systems

Muhammad Tukur, Hayatullahi B. Adeyemo, Tao Chen, Nour Ali, Anis Zarrad, Rick Kazman, Marco Agus, Rami Bahsoon

Year: 2026Venue: arXiv preprintArea: cs.SEType: PreprintEmbeddings: 253

Intelligence

Status: not_run | Model: - | Prompt: - | Confidence: 0%

Entities (0)

No extracted entities yet.

Relation Signals (0)

No relation signals yet.

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:Artificial intelligence (AI) systems are increasingly deployed in high-stakes domains such as healthcare, autonomous driving, finance, and education. While these systems offer powerful data-driven and adaptive capabilities, their complexity, rapid evolution, and dependence on dynamic data pipelines introduce new forms of engineering liability collectively referred to as AI Technical Debts (AITDs). AITDs arise from root causes spanning data governance, model implementation, algorithm design, architectural decisions, operational processes, documentation practices, and testing adequacy. Unlike conventional technical debt, many AITDs are latent and propagate across tightly coupled AI pipelines, leading to maintenance challenges, reliability degradation, and heightened safety or security risks. Guided by the principles of AI Trust, Risk, and Security Management (AI TRiSM), this study reinterprets technical debt through the interconnected dimensions of trustworthiness, focusing on AI safety and security technical debts. We conduct a systematic review of 60 primary studies and identify 31 distinct types of AITD, which are organized into a root-cause-oriented taxonomy comprising seven classes. The analysis examines how these debts map to 18 trust-related concerns, including 6 safety hazards and 12 security vulnerabilities. To support mitigation, the review synthesizes 34 actionable guidelines (8 safety and 26 security) targeting the prevention, detection, and reduction of AITDs across the AI lifecycle. Building on these findings, we introduce AITD-MAP, an integrated framework that connects the AITD taxonomy, quality and risk impacts, and mitigation strategies into a unified structure for risk-aware AI engineering. The framework aims to assist AI software engineers in making AI safety and security technical debts visible, understanding their root causes, and mitigating their presence.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

251,716 characters extracted from source content.

Expand or collapse full text

On AI Safety and Security Technical Debt in Engineering AI-Enabled Systems Muhammad Tukur mmt310@student.bham.ac.uk 0000-0003-1103-9659 Computer Science, University of Birmingham, Edgbaston, UK; CSE, HBKUQatar , Hayatullahi B. Adeyemo Computing and Informatics, Bournemouth UniversityBournemouthUK hadeyemo@bournemouth.ac.uk , Tao Chen Computer Science, University of Birmingham, EdgbastonBirminghamUK t.chen@bham.ac.uk , Nour Ali Brunel University London, UxbridgeLondonUK Nour.Ali@brunel.ac.uk , Anis Zarrad Computer Science, University of Birmingham, EdgbastonBirminghamUK a.zarrad@bham.ac.uk , Rick Kazman University of HawaiiHonoluluUSA kazman@hawaii.edu , Marco Agus College of Science and Engineering, HBKUQatar magus@hbku.edu.qa and Rami Bahsoon Computer Science, University of Birmingham, EdgbastonBirminghamUK r.bahsoon@bham.ac.uk Abstract. Artificial intelligence (AI) systems are increasingly deployed in high-stakes domains such as healthcare, autonomous driving, finance, and education. While these systems offer powerful data-driven and adaptive capabilities, their complexity, rapid evolution, and dependence on dynamic data pipelines introduce new forms of engineering liability collectively referred to as AI Technical Debts (AITDs). AITDs arise from root causes spanning data governance, model implementation, algorithm design, architectural decisions, operational processes, documentation practices, and testing adequacy. Unlike conventional technical debt, many AITDs are latent and propagate across tightly coupled AI pipelines, leading to maintenance challenges, reliability degradation, and heightened safety or security risks. Guided by the principles of AI TRiSM (AI Trust, Risk, and Security Management), this study reinterprets technical debt through the interconnected dimensions of trustworthiness, focusing on AI safety and security technical debts. We conduct a systematic review of 60 primary studies and identify 31 distinct types of AITD, which are organized into a root-cause–oriented taxonomy comprising seven classes. The analysis examines how these debts map to 18 trust-related concerns, including 6 safety hazards and 12 security vulnerabilities. To support mitigation, the review synthesizes 34 actionable guidelines (8 safety and 26 security) targeting the prevention, detection, and reduction of AITDs across the AI lifecycle. Building on these findings, we introduce AITD-MAP, an integrated framework that connects AITD taxonomy, quality and risk impacts, and mitigation strategies into a unified structure for risk-aware AI engineering. The framework aims at assisting AI Software Engineers in making AI Safety and Security technical debts visible, along their root causes and mitigating their presence. Artificial Intelligence, Mitigation Strategies, Safety, Security, Technical Debt †copyright: acmlicensed†journalyear: 2026†doi: X.X†ccs: Security and privacy Systems security†ccs: Computing methodologies Artificial intelligence†ccs: Software and its engineering Software creation and management 1. Introduction Artificial Intelligence (AI)-based systems have become deeply embedded in critical domains such as healthcare (Dave and Patel, 2023), autonomous vehicles (Bendiab et al., 2023), education (Srinivasa et al., 2022), and finance (Giudici and Raffinetti, 2023). An AI-based system is defined as a software-enabled environment that integrates AI techniques—such as machine learning (ML), deep learning (DL), or natural language processing (NLP)—to perform complex tasks with a degree of autonomy or intelligence beyond what is achievable through conventional rule-based automation (Recupito et al., 2024a). These systems leverage such techniques to automate decision-making, adapt to dynamic environments, and solve problems that require reasoning and learning, thereby exceeding the capabilities of traditional rule-based systems (Recupito et al., 2024a). Despite their growing capabilities and adoption, AI-enabled systems introduce substantial engineering and operational challenges. These include issues of transparency, maintainability, robustness, and long-term reliability, especially in dynamic, data-intensive, and safety-critical environments (Salhab et al., 2024). A significant contributor to these challenges is the accumulation of AI Technical Debt (AITD)—the hidden costs and risks associated with suboptimal architectural, design, or operational decisions made throughout the AI system lifecycle (Cunningham, 1992). In this study, AI Technical Debt (AITD) is defined as “a metaphor to indicate the typical quality concerns of suboptimal solutions integrated into the building process of AI-enabled systems” (Bogner et al., 2021). This definition extends the classical notion of technical debt to the AI context, reflecting quality concerns unique to data-driven and learning-based development processes. As Sculley et al. (Sculley et al., 2015) observed, “ML systems have a special capacity for incurring technical debt, because they have all the maintenance problems of traditional code plus an additional set of ML-specific issues.” These issues include data instability, model brittleness, algorithmic bias, and the opacity of learned behaviors. Similar to conventional technical debt, AI Technical Debts (AITDs) may remain latent and only become visible when they manifest as performance degradation, ethical violations, or system failures. However, in AI-enabled systems, this latency is often intensified by uncertainty in the system behaviour, continuous learning, feedback loops, and complex data pipelines and drifts feeding into the learning, making tracing and identifying the root causes of the debts difficult - particularly in high-stakes domains (Gyevnár2025531; Salhab et al., 2024). In response to the growing need for trustworthy AI, the concept of AI TRiSM (AI Trust, Risk, and Security Management) has emerged as a guiding governance framework. Highlighted by Gartner as a top strategic technology trend for 2023 (Groombridge and others, 2022) and formally developed by Habbal et al. (Habbal et al., 2024), IBM (IBM, 2025), NIST (NIST, 2024), and Avivah (Avivah, 2024), AI TRiSM frames trust as a multidimensional construct encompassing safety, security, fairness, reliability, and transparency. Within this framework, safety and security are treated as complementary and interdependent pillars, not siloed concerns. AI safety refers to the assurance that AI systems operate reliably without causing unintended harm (Gyevnár2025531; Arnez et al., 2021a), while AI security focuses on protecting these systems against adversarial threats, unauthorized access, and malicious manipulation (Schneider et al., 2024; Gnitko, 2024). Although their technical origins differ—accidental failures versus intentional attacks—their consequences frequently overlap. A security breach may trigger unsafe system behavior, while weaknesses in safety mechanisms can expose systems to exploitation. In adaptive and continuously learning AI environments, AI Safety and Security vulnerabilities make the system more ”porous” (e.g., numerous gaps/holes weakening the protective safety/security boundary of the system) due to factors such as data drift, continuous model updates, feedback loops, and growing system autonomy, which allow failures and attacks to propagate across traditionally separate concerns. This can be observed through coupled safety–security incidents, shared failure modes, and the accumulation of interrelated technical debts. Despite this convergence, existing literature largely treats safety and security debts in isolation, limiting our ability to reason about their co-evolution and cumulative impact on system risk and trustworthiness over time. The AI TRiSM perspective therefore motivates integrated approaches that jointly identify, model, and mitigate these intertwined forms of debt. While our study does not extend AI TRiSM in a technical implementation sense, it adopts AI TRiSM as a conceptual lens to reinterpret technical debt in AI-enabled systems. Our core innovation is to view AITDs not solely through architectural layers or lifecycle phases, but also through the risk-oriented dimensions of trust, risk, safety, and security, as advocated by AI TRiSM. This trust-oriented framing enables a structured re-evaluation of technical debt and helps consolidate fragmented discussions around AI safety and security. For example, debts such as ethical debt, undeclared consumers, feedback loops, and algorithmic bias are reinterpreted as systemic risks that degrade AI trustworthiness if left unmanaged. To the best of our knowledge, this is the first systematic review to explicitly examine AITDs through the lens of AI TRiSM. By doing so, we offer a risk-informed, actionable roadmap that aligns technical debt management with the broader goals of trustworthy and sustainable AI governance. 1.1. Motivation AI-based systems are increasingly deployed in dynamic, high-stakes environments where long-term reliability and perceived trustworthiness are critical (Aleksandra et al., 2025). These systems often incur AI Technical Debt (AITD)—hidden costs arising from suboptimal decisions during design, development, or deployment (Sculley et al., 2015). Unlike traditional technical debt, AITDs are frequently driven by AI-specific factors such as data drift, opaque models, feedback loops, and algorithmic bias, making them harder to detect and manage. In the context of responsible AI, safety and security represent core system quality attributes that can be explicitly designed, implemented, and verified, while trust and risk reflect higher-level assessments of system behavior, assurance, and stakeholder confidence (Li et al., 2023a; NIST, 2024). Recent governance frameworks, including AI TRiSM (AI Trust, Risk, and Security Management), emphasize the need to manage these dimensions in a coordinated manner (Groombridge and others, 2022; IBM, 2025; Avivah, 2024; Habbal et al., 2024). However, existing AITD research rarely examines how accumulated technical debt degrades safety and security properties and, in turn, shapes system-level risk exposure and trust outcomes over time. This study is motivated by the need to bridge this gap. We adopt AI TRiSM as a conceptual lens—not to extend the framework but to reframe AITD through its dimensions. Our goal is to support a more holistic, risk-informed understanding of technical debt in AI systems, enabling more trustworthy and sustainable AI development. 1.2. Research Questions and Contributions To address the gaps identified in the current literature and advance a root-cause–oriented understanding of AI Technical Debt (AITD), this study conducts a systematic review investigating the forms, impacts, and mitigation strategies associated with AITDs across the AI development lifecycle. The review is guided by the following research questions: • RQ1: What are the different types of technical debt found in AI-enabled systems? And which types are reported most frequently in the literature? This question seeks to identify, characterize, and classify AITDs across the full AI lifecycle, including debts related to data, models, algorithms, architecture, operational processes, documentation, and testing. • RQ2: How are the identified AITDs related to safety and security debt? This question examines the extent to which AITDs contribute to vulnerabilities and operational hazards, reinforcing the AI TRiSM view of trustworthiness. • RQ3: What mitigation strategies and management activities are suggested for addressing the identified AITDs? This question synthesizes actionable guidelines to support responsible, risk-aware AI development. Building on these research questions, the study offers the following key contributions: • A comprehensive, root-cause–oriented taxonomy of 31 AITDs, organized into seven major classes: Data & Library–Related Debts, Model & Code–Related Debts, Algorithm–Related Debts, Design & Architecture Debts, Operational & Lifecycle Debts, Documentation & Communication Debts, and Testing & Quality Assurance Debts. • A novel mapping between AITDs and trust-related risks, identifying 6 safety and 12 security concerns directly linked to specific forms of debt, thereby demonstrating how AITDs shape vulnerability paths and operational hazards in AI-enabled systems. • A synthesis of 34 actionable mitigation guidelines (8 safety and 26 security), providing concrete strategies for preventing, detecting, and reducing AITDs. These include practices such as Human-AI Control Mode Switching, Ethical Black Boxes, Continuous Behavioral and Drift Monitoring, Adversarial and Defensive Training, Out-of-Distribution Detection, and Formal Verification for high-risk applications. • The introduction of AITD-MAP, a unified analytical framework that integrates AITD taxonomy, impact analysis, and mitigation strategies (See Figure 1), designed to support risk-informed decision-making in AI system engineering and align with principles of trustworthy AI. By consolidating fragmented insights and providing a structured, risk-aware roadmap for managing AI Technical Debt, this study advances responsible, resilient, and sustainable AI engineering. The findings reinforce the importance of integrating quality, safety and security considerations throughout the AI lifecycle, offering actionable guidance for practitioners and researchers working toward trustworthy and dependable AI systems. 1.3. Paper Organization The rest of the paper is structured as follows: Section 2 presents the related works. Section 3 describes the research methodology. Section 4 presents the taxonomy of AITDs. It further explores their impact on software quality attributes. Section 5 examines their connection to safety and security. Section 6 proposes mitigation guidelines. Section 7 discusses principal findings and outlines strengths and limitations. Section 8 concludes with a summary and future directions. Figure 1. Circular representation of AITD-MAP (Mapping AI Technical Debt: Types, Impacts, & Guidelines), illustrating how each research question (RQ1–RQ3) contributes to the construction of the integrative framework. The diagram highlights the flow from taxonomy development and frequency analysis to the assessment of security and safety concerns and corresponding mitigation strategies. 2. Related work Technical debt (TD) has been extensively studied in the context of traditional software (Avgeriou et al., 2016) and systems (Kleinwaks et al., 2023b, a) engineering. Foundational reviews have explored its identification (Alves et al., 2016), management (Avgeriou et al., 2016; Li et al., 2015), prioritization (Alfayez et al., 2020), financial implications (Ampatzoglou et al., 2015), and intelligent management techniques across diverse domains (Albuquerque et al., 2022). However, these studies generally overlook the unique characteristics and quality concerns associated with AI-based systems. In response to the growing importance of Artificial Intelligence (AI), recent research has begun to explore technical debt in AI-enabled systems. These efforts, however, remain fragmented. Some works focus on specific debt types such as ethical debt (Petrozzino, 2021), bias and fairness (Roselli et al., 2019), self-admitted technical debt (SATD) (OBrien et al., 2022), algorithmic debt (Simon et al., 2023), architectural debt (Sas and Avgeriou, 2023), and requirements engineering debt (Belani et al., 2019). Others investigate technical debt within particular application domains, such as AI-based competition platforms (Sklavenitis and Kalles, 2024), recommender systems (Moreschini et al., 2024), large language models (LLMs) (Menshawy et al., 2024), and complex systems (Belani et al., 2019). In terms of comprehensive analyses, Bogner et al. (Bogner et al., 2021) presented a systematic mapping study on TD and anti-patterns in AI systems, offering a partial taxonomy with limited impact analysis and scattered mitigation approaches. Recupito et al. (Recupito et al., 2024a) conducted a survey-based study that captures practitioner insights into architecture-level AITDs, but lacks a structured taxonomy and generalized mitigation framework. Washizaki et al. (Washizaki et al., 2019) attempted to classify SE design patterns for ML systems but focused more on conceptual classification than technical debt characterization. Sculley et al. (Sculley et al., 2015) provided the foundational industry perspective on ML-specific technical debt, such as glue code and entanglement, but did not offer empirical classification or mitigation strategies. Bhatia et al. (Bhatia et al., 2023) conducted a large-scale empirical study on SATD in ML projects, contributing a refined SATD taxonomy and insights into long-term debt evolution, although security and safety aspects were not addressed. Menshawy et al. (Menshawy et al., 2024) offered practical insights into TD associated with LLM deployment, highlighting engineering trade-offs and mitigation practices from real-world systems. A comparative summary of these works is presented in Table 1. As shown, existing literature generally lacks a holistic view of AITDs across types, impacts, and mitigation strategies. In addition, few studies incorporate a systematic approach to evaluate the security and safety implications of AITDs or provide actionable guidelines for debt reduction. In contrast, this study provides the first comprehensive review that systematically identifies and categorizes 31 distinct types of AITDs from 60 primary studies. It goes further to analyze their effects on system quality, with an emphasis on safety and security concerns, and synthesizes 16 actionable guidelines for mitigating these issues. Our findings address critical gaps in the previous literature by integrating taxonomic classification, impact assessment, and practical mitigation strategies within a single unified framework. Table 1. Summary of Related Works on Technical Debt in AI-Based Systems Study Type # of Studies Pub. Period Objective Methodological Framework Taxonomy Provided Impact Analysis Security/ Safety Consideration Mitigation Strategies Bogner et al. (2021) (Bogner et al., 2021) Systematic Mapping Study (SMS) 21 Up to 2020 Map the landscape of TD and antipatterns in AI systems Wohlin (Wohlin, 2014) and Petersen (Petersen et al., 2008) guidelines Partial – categorized TDs & antipatterns loosely General discussion of impact Mentioned generally 46 scattered mitigation approaches Recupito et al. (2024) (Recupito et al., 2024a) Survey Study 53 practitioner responses Up to 2024 Investigate code- and architecture-level AITDs Survey + qualitative content analysis Focused on 9 AITD types Moderate, practitioner-perceived impact Mentioned generally Mostly ad hoc, manual strategies Sklavenitis et al. (2024) (Sklavenitis and Kalles, 2024) Scoping Review 100 2012–2023 Measure AITDs in competitions; introduce Accessibility Debt Scoping review + domain-specific questionnaire Yes – 18 AITDs incl. Accessibility Debt Structured analysis with practical examples Not a primary emphasis Not a primary emphasis Washizaki et al. (2019) (Washizaki et al., 2019) Preliminary SLR 38 Up to 2019 Identify SE design patterns in ML systems Literature review + ML lifecycle classification Yes – 33 SE patterns Partially – conceptual Not explicitly analyzed Not explicitly analyzed Sculley et al. (2015) (Sculley et al., 2015) Conceptual Essay N/A Pre-2015 Highlight ML-specific TD from industry view Conceptual analysis (Google experience) Yes – anti-patterns Qualitative discussion Limited (e.g., feedback loops) Conceptual suggestions (e.g., monitoring) Bhatia et al. (2023) (Bhatia et al., 2023) Empirical Study 318 ML + 318 Non-ML Up to 2023 Analyze SATD in ML software Mixed methods – SHAP, survival, manual coding Yes – Extends SATD taxonomy Evolution + predictors of SATD Not directly addressed Implicit suggestions Menshawy et al. (2024) (Menshawy et al., 2024) Perspective Study N/A Up to 2024 Discuss TD in LLM deployment Experience-based synthesis + examples Yes – LLM-specific TD types Covers performance, memory, latency Explicit (bias, hallucinations, feedback) Prompt tuning, quantization, caching Ours (2025) Scoping Review 60 Up to 2025 Identify, categorize, and analyze AITDs, their impacts, and mitigation strategies PRISMA-ScR (Tricco et al., 2018) Comprehensive taxonomy of AITDs Detailed impact on AI-system trustworthiness Explicit analysis of security and safety implications 34 synthesized mitigation guidelines 3. Methodology To address the research questions outlined in the introduction, we adopted the guidelines set by the PRISMA Extension for Scoping Reviews (PRISMA-ScR) (Tricco et al., 2018). As illustrated in Figure 2.A, this framework provides a structured and systematic approach for conducting comprehensive scoping reviews, ensuring rigor and thoroughness. The literature search was conducted through the following stages: 3.1. Search Strategy The search strategy encompassed the selection of bibliographic databases, formulation of search terms and strings, establishment of inclusion and exclusion criteria, and the process for selecting relevant studies for inclusion. 3.2. Data Source Selection To ensure comprehensive coverage of relevant literature, we conducted searches in the following electronic databases: ACM Digital Library, IEEE Xplore, Scopus, and Springer. These databases were selected for their extensive coverage of research in software engineering and computer science in general. 3.3. Venue Selection Criteria In addition to database and content filtering, venue selection was guided by stringent quality and relevance criteria. Priority was given to studies published in high-impact, peer-reviewed journals, top-tier conferences, workshops, and symposium with a clear focus on AI system engineering and/or software development practices. The final selection spans 34 distinct venues, with CAIN, Empirical Software Engineering, SEAA, ICSE, and TechDebt, among the most represented (c.f. Table 2). Emphasis was placed on venues indexed by ACM, IEEE, Springer, and Scopus, given their established reputation and consistent record of publishing research on software engineering. Table 2. Distribution of Selected Studies by Venue S/N Venue Count 1 International Conference on AI Engineering: Software Engineering for AI (CAIN) 6 2 Empirical Software Engineering 5 3 Euromicro Conference on Software Engineering and Advanced Applications (SEAA) 4 4 International Conference on Software Engineering (ICSE) 4 5 ACM/IEEE International Conference on Technical Debt (TechDebt) 4 6 ACM Transactions on Software Engineering and Methodology 3 7 IEEE International Conference on Software Maintenance and Evolution (ICSME) 3 8 IEEE Transactions on Software Engineering 2 9 Software Quality: Future Perspectives on Software Engineering Quality (SWQD) 2 10 AI and Ethics 2 11 International Conference on Mining Software Repositories (MSR) 2 12 Journal of Systems and Software 1 13 ACM Conference on Equity and Access in Algorithms, Mechanisms, and Optimization 1 14 ACM Conference on Fairness, Accountability, and Transparency 1 15 ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering 1 16 ACM SIGMOD Record 1 17 ACM/IEEE Workshop on AI Engineering-Software Engineering for AI (WAIN) 1 18 Advances in Neural Information Processing Systems 1 19 IEEE International Conference on Big Data (Big Data) 1 20 Information and Software Technology 1 21 International Conference on Automated Software Engineering (ASE) 1 22 International Conference on Green Computing and Internet of Things (ICGCIoT) 1 23 International Conference on Industrial Informatics (INDIN) 1 24 International Conference on Product-Focused Software Process Improvement 1 25 International Conference on Software Architecture Companion (ICSA-C) 1 26 International Requirements Engineering Conference Workshops 1 27 International Workshop on Empirical Software Engineering in Practice (IWESEP) 1 28 Workshop on Machine Learning and Systems 1 29 World Wide Web Conference 1 30 International Conference on Emerging Technologies and Computing (ICETC) 1 31 Brazilian Symposium on Software Components, Architectures, and Reuse 1 32 International Conference on Program Comprehension (ICPC) 1 33 IEEE Access 1 34 IEEE Annual Computing and Communication Workshop and Conference (CCWC) 1 Total 60 3.4. Search terms AI-enabled systems share certain forms of technical debt with traditional software systems; however, they also introduce unique types of technical debt that arise from their data-driven architectures, learning components, adaptive behaviors and feedback loops, and emergence. Consequently, it is essential to focus on literature that explicitly addresses technical debt in AI-based systems. Based on this distinction, the following terms were identified as most relevant for constructing the search queries. • AI Terms: Artificial Intelligence, AI, Machine Learning, ML, Deep Learning, DL, Natural Language Processing, NLP, Generative Artificial Intelligence, GenAI, Large Language Model, LLM, Agentic AI. • Technical Debt Terms: Technical Debt, TD, AITD, Anti-patterns, Self-Admitted Technical Debt, SATD, Smell. 3.5. Search Strings Search queries were formulated using appropriate literal and semantic synonyms to capture a wide range of relevant results. Table 3 presents the search strings applied to each data source: Table 3. Restricted Electronic Search Results for AI and Technical Debt Data Source Search String Filters Applied Results ACM Digital Library [[Abstract: artificial intelligence] OR [Abstract: ai] OR [Abstract: machine learning] OR [Abstract: ml] OR [Abstract: deep learning] OR [Abstract: dl] OR [Abstract: natural language processing] OR [Abstract: nlp] OR [Abstract: generative artificial intelligence] OR [Abstract: genai] OR [Abstract: large language model] OR [Abstract: llm] OR [Abstract: agentic ai]] AND [[Abstract: technical debt] OR [Abstract: td] OR [Abstract: artificial intelligence technical debt] OR [Abstract: aitd] OR [Abstract: anti-patterns] OR [Abstract: self-admitted technical debt] OR [Abstract: satd] OR [Abstract: smell]] Research articles only, and date 330 IEEE Xplore ((”Abstract”:”Artificial Intelligence” OR ”Abstract”:”AI” OR ”Abstract”:”Machine Learning” OR ”Abstract”:”ML” OR ”Abstract”:”Deep Learning” OR ”Abstract”:”DL” OR ”Abstract”:”Natural Language Processing” OR ”Abstract”:”NLP” OR ”Abstract”:”Generative Artificial Intelligence” OR ”Abstract”:”GenAI” OR ”Abstract”:”Large Language Model” OR ”Abstract”:”LLM” OR ”Abstract”:”Agentic AI”) AND (”Abstract”:”Technical Debt” OR ”Abstract”:”TD” OR ”Abstract”:”Artificial Intelligence Technical Debt” OR ”Abstract”:”AITD” OR ”Abstract”:”Anti-patterns” OR ”Abstract”:”Self-Admitted Technical Debt” OR ”Abstract”:”SATD” OR ”Abstract”:”Smell”) ) Journals and conferences only, and date 558 Scopus ( ”Artificial Intelligence” OR ”AI” OR ”Machine Learning” OR ”ML” OR ”Deep Learning” OR ”DL” OR ”Natural Language Processing” OR ”NLP” OR ”Generative Artificial Intelligence” OR ”GenAI” OR ”Large Language Model” OR ”LLM” OR ”Agentic AI” ) AND ( ”Technical Debt” OR ”TD” OR ”Artificial Intelligence Technical Debt” OR ”AITD” OR ”Anti-patterns” OR ”Self-Admitted Technical Debt” OR ”SATD” OR ”Smell” ) Document Type: Article and Conference paper; Subject area: Computer Science and Engineering; Language: English only; and date 203 Springer ”Artificial Intelligence” OR ”Machine Learning” OR ”Deep Learning” AND ”Technical Debt” OR ”Anti-patterns” Research articles and conference papers only; Discipline: Computer Science; Subject area: Software Engineering, Software Testing; Language: English only; and date 260 Total 1,351 3.6. Search Criteria Studies were included based on their direct relevance to AI-technical debt. The inclusion and exclusion criteria were as follows: 3.6.1. Inclusion criteria: • IC1. The study must explicitly discuss or analyze technical debt within AI-enabled systems and provide direct insights relevant to one or more of the research questions formulated in this review. • IC2. The publication must be a peer-reviewed journal article, conference paper, workshop, or symposium contribution. • IC3. The publication must have been released between 2015 and November 2025. This period begins with the introduction of the concept of technical debt in AI and machine learning systems by Sculley et al. (Sculley et al., 2015) in 2015. • IC4. The paper must exceed three pages in length to ensure adequate depth of discussion and analysis. 3.6.2. Exclusion criteria: • EC1. Non-original research articles were excluded. This includes review papers, Ph.D. dissertations, secondary studies (e.g., SLRs and SMSs), posters, editorials, and magazine articles. • EC2. Articles not written in English were excluded. • EC3. Studies without accessible full-text versions were excluded. • EC4. Studies that do not explicitly address technical debt in AI-based systems were excluded. • EC5. Duplicate publications were excluded. These include instances where the same study appeared in multiple databases or was published in more than one venue (e.g., journal, conference, or workshop). 3.7. Study Selection The study selection process was conducted in three phases: (1) automatic search restriction and duplicate removal, followed by (2) initial screening of titles and abstracts for relevance, and (2) a full-text review to confirm eligibility based on the predefined inclusion and exclusion criteria. Figure 2. Methodology charts: (A) PRISMA chart of the included studies; (B) publication type of the selected papers. (C) The distribution of studies over the years. 3.7.1. Automatic search restriction and duplicate removal In this phase, we included papers published between January 2015 and October 2025, as Sculley et al. (Sculley et al., 2015) were the first to introduce the concept of technical debt in AI and machine learning systems in the year 2015. In addition to the time restriction, we applied additional filters based on the options available in each digital library. For example, the Scopus Digital Library allows filtering by document type, subject area, language, and publication date. Table 3 outlines the filters applied and the number of studies retrieved from each digital database. In total, 1,351 studies were initially retrieved, and after removing 115 duplicates, 1,236 unique papers with distinct titles and abstracts were considered for further analysis. Further information and replication package is provided in the Search Results folder of the Supplementary Material for additional details. 3.7.2. Screening based on title and abstract In this phase, studies were screened based on their titles, abstracts, and the availability of full texts. This resulted in the exclusion of 997 studies due to irrelevance or inaccessible full-texts, leaving 239 unique full-text studies for further evaluation. 3.7.3. Screening based on full-text The remaining studies were subjected to a full-text review, where the inclusion and exclusion criteria outlined in Sec. 3.6 were rigorously applied. Studies that only discussed technical debt without specifically addressing AI-based systems, or those that did not link technical debt to AI-enabled systems, were excluded. Following a comprehensive review, 60 studies were identified as highly relevant and selected as primary sources. The multidisciplinary nature of this review is evident in the diverse range of publication venues, as outlined in the references (c.f. 2. Figure 2.B illustrates the types of publications included, while Figure 2.C shows the distribution of the selected studies over the past decade. 3.8. Grounded Theory Coding Procedure To systematically identify and categorize the 31 AI Technical Debts (AITDs), we adopted a grounded theory methodology structured around the three classical phases of Corbin and Strauss (Corbin and Strauss, 1990): open coding, axial coding, and selective coding. During the open coding phase, two co-authors independently analyzed the full-text content of the 60 primary studies, extracting and labeling recurring technical challenges indicative of debt-like behavior. This stage produced 101 initial codes, with each refined AITD supported by at least three underlying conceptual indicators. In the axial coding phase, these codes were iteratively compared, clustered, and refined to identify conceptual relationships and remove redundancies. Through this constant comparison process, the analysis converged into 31 distinct AITDs, each representing a higher-level abstraction of related debt patterns. In the selective coding phase, these 31 AITDs were organized into seven main root-cause-oriented categories. This classification underwent a structured assessment involving the co-authors. Agreement was achieved through multiple consensus-building sessions, with disagreements resolved via structured deliberation until full consensus was reached. The analysis achieved theoretical saturation after three iterations, at which point no new debt concepts emerged. This rigorous multi-stage approach ensured the reliability, transparency, and saturation of the resulting taxonomy, as summarized in Tables 4 and further detailed in Section 4. Additional details are provided in the Supplementary Material. 4. Overview of the identified AITDs and their taxonomy (RQ1) This section offers a comprehensive definition and discussion of the thirty-one (31) AI Technical Debts (AITDs) identified in the primary studies, each illustrated with relevant use cases. The AITDs are systematically categorized, and a detailed analysis is conducted, with each debt ordered by frequency of occurrence using grounded theory as the analytical approach (Corbin and Strauss, 1990) (see Tables 4 and the Supplementary Material). Additionally, an in-depth examination of the overall impact of AITDs on the quality of AI-based systems is provided. 4.1. Root-Cause-Oriented AITD Taxonomy To develop a unified and conceptually coherent understanding of the diverse forms of AI Technical Debt (AITD), the thirty-two identified debts were systematically classified according to their root causes—that is, the underlying technical, organizational, or ethical conditions that give rise to debt accumulation within AI-enabled systems. This root-cause-oriented perspective emphasizes the intrinsic source of each debt rather than its surface manifestation, providing a more holistic view of how AITDs emerge, propagate, and persist throughout the lifecycle of intelligent systems. The resulting taxonomy consolidates related technical debts into seven principal categories, each representing a distinct causal domain that influences the introduction and long-term impact of debt: (1) Data & Library–Related Debts (2) Model & Code–Related Debts (Implementation Debts) (3) Algorithm–Related Debts (4) Design & Architecture Debts (Structural Debts) (5) Operational & Lifecycle Debts (6) Documentation & Communication Debts (7) Testing & Quality Assurance Debts Each category groups together debt types that share a common origin, engineering failure mode, or decision-making trade-off, enabling more precise reasoning about how and why these debts arise. This structure also facilitates targeted mitigation by linking each debt to its underlying technical or managerial driver. The classification process followed an iterative grounded-theory procedure, in which the co-authors independently reviewed and validated the conceptual boundaries of each identified debt type. Disagreements were resolved through structured, consensus-based discussions, resulting in a stable and mutually agreed-upon taxonomy. The hierarchical relationships among the seven categories, their constituent subcategories, and the individual technical debt types are illustrated in Figure 3. This taxonomy provides an integrated and extensible representation of the AITD landscape, synthesizing perspectives from software engineering, machine learning systems, responsible AI, and operational practices. The resulting categorizations are presented in the subsections that follow, each accompanied by detailed descriptions, example scenarios, and a justification for its assignment to the respective category. Figure 3. AITD taxonomy showing seven main categories—each divided into subcategories with corresponding debt types. 4.1.1. Data & Library-Related Debts These debts arise from shortcomings in data governance, feature-pipeline stability, and dependency management—factors that form the foundation of every AI-based system. Because AI models rely heavily on the quality, consistency, and traceability of their training and inference inputs, even minor irregularities in data or library configurations can propagate significant degradation in system reliability, reproducibility, and long-term maintainability. These debts collectively reflect failures to manage the data ecosystem and software dependencies that support the learning pipeline. i. Data Debt This emerges when datasets used for training, validation, or inference suffer from quality issues such as missing values, biased distributions, poor metadata, untracked schema evolution, or inconsistent preprocessing procedures. In AI systems, where model performance is intrinsically tied to input quality, such deficiencies can severely distort learned representations and weaken generalization. Data Debt often accumulates gradually as datasets evolve without proper versioning, monitoring, or documentation. Impact: It introduces instability, model drift, fairness violations, reduced robustness, and increased retraining overhead. Production models may fail unpredictably, degrade silently, or exhibit harmful behavior—such as biased decision-making—when new data deviates from historical patterns. Use Case: In a real-time fraud-detection system, a financial institution updates its transaction schema by renaming fields and adding new categorical indicators. Because these changes are untracked, the deployed model interprets inputs incorrectly, resulting in a surge of false positives and customer complaints. Justification (Why): Data Debt is classified under Data & Library-Related Debts because its root cause is inherently tied to data governance failures, unstable data pipelines, and unmanaged dataset evolution—issues central to the foundational data layer of AI systems. Source(s): (Sculley et al., 2015; Alahdab and Çalıklı, 2019; Zhang et al., 2022a; Tang et al., 2021; Arpteg et al., 2018; Polyzotis et al., 2018; Foidl et al., 2022; Lenarduzzi et al., 2021; Foidl et al., 2019; Breck et al., 2017; Hutchinson et al., 2021; Moreschini et al., 2024; Nahar et al., 2022; Shivashankar and Martini, 2022; Roselli et al., 2019; Côté et al., 2024; Belani et al., 2019; Sas and Avgeriou, 2023; Wang et al., 2023b; Khanvilkar et al., 2025; Recupito et al., 2024b; Cunha et al., 2020; de Souza Santos et al., 2025; Akgül et al., 2025; Ximenes et al., 2025; Shome et al., 2022; Moldovan et al., 2024). i. Pipeline Jungle: This refers to preprocessing or feature-engineering pipelines that have grown organically—often through rapid experimentation—resulting in deeply nested, ad-hoc, and poorly documented chains of transformations. As components evolve, the pipeline becomes opaque, fragile, and difficult to reproduce or debug. AI systems are particularly vulnerable since the learning process depends critically on deterministic and transparent data transformations. Impact: It undermines reproducibility, slows development, and increases the risk of hidden data leaks or inconsistent training-inference paths. Even small upstream changes can cause cascading failures or silent performance degradation. Use Case: A computer-vision team incrementally adds new image augmentations for training. Over time, the pipeline incorporates dozens of conditional operations spread across multiple scripts. During deployment, a mismatch between training and inference transformations leads to lower detection accuracy in real-world images. Justification (Why): Pipeline Jungle is grouped under this category because its core deficiencies relate to data pipeline management, transparency, and structural oversight—problems rooted in data engineering rather than model architecture or code structure. Source(s): (Recupito et al., 2024a; Sculley et al., 2015; Alahdab and Çalıklı, 2019; Washizaki et al., 2019; Foidl et al., 2022; Moreschini et al., 2024; Shivashankar and Martini, 2022; Belani et al., 2019; Wang et al., 2023b). i. Scattered Use of ML Libraries (SML): This debt arises when an AI system relies on multiple machine learning libraries, framework versions, or overlapping APIs without clear standardization. Examples include mixing TensorFlow 1.x and 2.x, combining incompatible PyTorch modules, or using different versions of NumPy for different components. Such inconsistency introduces brittleness, dependency conflicts, and unpredictable behavior. Impact: SML leads to nondeterministic outputs, runtime incompatibilities, serialization failures, deployment instability, and increased maintenance cost—especially when model components must interoperate in production. Use Case: A research team trains a model in PyTorch but uses TensorFlow scripts for feature extraction. Minor version differences between development and production environments cause silent discrepancies in tensor shapes, breaking the deployment pipeline. Justification (Why): SML is rooted entirely in dependency mismanagement and inconsistency within the library ecosystem—precisely the type of foundational support issue that characterizes Data & Library-Related Debts. Source(s): (Recupito et al., 2024a; Costal et al., 2024). iv. Dispensible Dependency: It refers to unused, obsolete, or redundant software packages and libraries that remain in the environment even though they are no longer required by the AI system. These dependencies increase the risk of security vulnerabilities, version conflicts, and inflated environments that are difficult to reproduce or audit. Impact: This debt increases attack surfaces, slows build times, complicates dependency resolution, and introduces uncertainty into model reproducibility. It may also hinder deployment on resource-constrained platforms. Use Case: A legacy feature-extraction toolkit remains installed in a production environment despite being replaced months earlier. A vulnerability scanner later identifies a critical security flaw in the unused library, forcing emergency remediation. Justification (Why): Dispensable Dependency is placed under Data & Library-Related Debts because its origin lies in library ecosystem mismanagement and poor dependency hygiene—both fundamental aspects of the AI data-processing environment. Source(s): (Chaudhary et al., 2018; Costal et al., 2024; Breck et al., 2017). All the debts in this category share a common root cause: poor control, monitoring, and governance of the data pipelines and software dependencies that constitute the backbone of AI systems. These debts hinder reproducibility, undermine trust in model behavior, and increase operational friction across the entire AI lifecycle. 4.1.2. Model/Code Related Debts These originate from deficiencies in implementation practices, modularization, interface management, and the structural integrity of the code that supports AI components. AI systems are particularly susceptible to these debts because model behavior is deeply intertwined with the structure of the underlying code artifacts—such as dataflow logic, model wrappers, feature utilities, and runtime inference pathways. Unlike traditional software components, AI models introduce additional complexity stemming from non-deterministic behaviors, hidden state, and tight coupling between learned parameters and computational code. The debts in this category collectively degrade maintainability, reliability, and integration stability across the model development and deployment lifecycle. i. Correction Cascades (C): Occur when modifications made to fix a model issue inadvertently introduce new defects elsewhere in the system. In AI pipelines, where components depend heavily on learned representations or preprocessing logic, even minor adjustments—such as threshold tuning, feature normalization changes, or loss-function updates—may ripple through downstream modules. Impact: This debt increases maintenance effort, leads to unpredictable regressions, and complicates quality assurance. Over time, the system becomes brittle, with every fix posing a risk of degrading other functionalities. Use Case: A development team adjusts the classification threshold of a churn-prediction model to reduce false negatives. The change unexpectedly affects marketing automation logic that relies on threshold-based customer segmentation, resulting in misaligned promotional campaigns. Justification (Why): Correction Cascades are categorized as Model & Code–Related Debts because their root cause lies in tight coupling, insufficient isolation, and ad-hoc code modifications that propagate unintended side effects across model components. Source(s): (Recupito et al., 2024a; Sculley et al., 2015; Belani et al., 2019; Shukla and Cartlidge, 2022). i. Undeclared Consumers: This arises when model outputs are consumed by downstream services or processes unknown to the development team. These hidden dependencies often emerge in fast-paced AI development environments where APIs evolve quickly and internal teams reuse AI components without formal registration or interface governance. Impact: They create operational risk, unauthorized data exposure, brittle integration pathways, and unpredictable behavior when model contracts or inference formats change. Use Case: A sentiment-analysis model originally designed for customer-support triage is silently reused by a marketing analytics team. When the model is updated with a new tokenization scheme, the downstream system silently begins classifying sentiment incorrectly, altering business reports. Justification (Why): The debt originates from undocumented and unmanaged model interfaces, making it fundamentally a model/code-level integration debt rather than a design or architectural issue. Source(s): (Recupito et al., 2024a; Sculley et al., 2015; Chaudhary et al., 2018; Washizaki et al., 2019; Belani et al., 2019; Wang et al., 2023b). i. Hidden Feedback Loops: This occurs when model outputs unintentionally influence their future inputs, creating self-reinforcing behavior. Common examples include ranking systems, recommender pipelines, and content-moderation models, where predictions directly affect the distribution of new training data. Impact: These loops amplify bias, degrade robustness, and may lead to degenerative behavior (e.g., popularity bias or echo-chamber effects). Additionally, they complicate retraining, making it difficult to disentangle learned behavior from past model outputs. Use Case: A recommender system suggests articles to users based on previous engagement. Over time, the system continues presenting similar content, narrowing topic diversity and reducing exploratory signals in training data. Justification (Why): Because feedback loops manifest through runtime coupling between model outputs and model inputs, they are inherently rooted in model-code interactions rather than algorithm design or pipeline configuration. Source(s) (Sculley et al., 2015; Arpteg et al., 2018; Menshawy et al., 2024; Moreschini et al., 2024; Shivashankar and Martini, 2022; Roselli et al., 2019; Khritankov, 2021; Wang et al., 2023b; Shukla and Cartlidge, 2022). iv. Deep God File (DG): This denotes excessively large or monolithic files—often originating from early experimentation—that contain intertwined logic for data preprocessing, model training, evaluation, and deployment (Recupito et al., 2024a; Gesi et al., 2022). Such files hinder modularization, reuse, debugging, and testing. Impact: They reduce maintainability, complicate onboarding, hinder automated testing, and increase the likelihood of introducing defects during refactoring. Use Case: A Jupyter notebook used for initial research is promoted directly into production. It contains data cleaning, feature engineering, model training, and inference logic in a single script, making any modification risky. Another example is an AI application where data preprocessing, model training, and testing logic are all implemented within the same file, leading to a cluttered codebase. Justification (Why): DG arises from poor code organization, a foundational model-implementation issue, and is therefore grouped under Model & Code–Related Debts. 111It is important to note that Deep God File extends the traditional God Class concept to AI contexts, where large monolithic scripts or notebooks combine data preprocessing, model design, training, and evaluation in a single file. Unlike the classic design-level anti-pattern, this debt arises from experimental ML workflows and the lack of modularization typical in AI development. Furthermore, the key difference is the motivation. A classic God Class often results from a lack of architectural discipline. In ML, the ”Deep God File” often arises naturally from the exploratory nature of the work, where experimentation takes priority over software engineering best practices. The focus is on getting a working model, not on creating reusable and modular components. Source(s): (Recupito et al., 2024a; Cunha et al., 2020). v. Prototype Debt/Dead Experimental Code Paths: Prototype Debt accumulates when experimental prototypes or proof-of-concept scripts transition into production without refinement, optimization, or appropriate architectural restructuring. While common in AI research settings, such code is fragile and poorly suited for operational use. Impact: It leads to runtime inconsistencies, missing error handling, reduced scalability, and challenges in debugging or extending the model. Use Case: A prototype hyperparameter-tuning script is used as the production training pipeline. When data volume increases, the script fails due to hard-coded assumptions and lack of batching logic. Justification (Why): Its origin lies in moving research artifacts directly into production, making it fundamentally a model/code-related implementation debt. Source(s): (Sculley et al., 2015; Tang et al., 2021; Washizaki et al., 2019; Li et al., 2023b, c; OBrien et al., 2022; Pérez et al., 2021; Moreschini et al., 2024; Belani et al., 2019; Wang et al., 2023b; Li et al., 2022). vi. Entanglement: It arises when multiple AI components or feature pathways become tightly interwoven, such that modifying one element requires changing others. This reduces modularity and makes isolated improvements or debugging nearly impossible. Impact: It creates high modification cost, restricts model evolution, and slows experimentation cycles. Errors propagate more easily, and testing becomes more complex. Use Case: A set of models share a common feature vector generated through a single, monolithic script. Updating any part of the vector requires revisiting all dependent models. Justification (Why): Entanglement reflects poor separation of concerns within model code, justifying its placement within this category. Source(s): (Sculley et al., 2015; Menshawy et al., 2024; Belani et al., 2019; Wang et al., 2023b). vii. Multiple Language Smells (MLS): MLS occurs when a system incorporates multiple programming languages or framework ecosystems without clear boundaries or tooling support. Though sometimes necessary for performance (e.g., C++ extensions), unmanaged heterogeneity creates build-time and runtime fragility. Impact: It increases integration complexity, complicates containerization, introduces serialization challenges, and hinders collaborative development. It also adds complexity and requires diverse expertise for maintenance. Use Case: A deep-learning team mixes PyTorch (Python), CUDA kernels (C++/CUDA), and custom Java-based serving infrastructure. Differences in serialization formats cause inference failures. Justification (Why): MLS is rooted in cross-language integration problems that directly affect model code and runtime interactions. Source(s): (Recupito et al., 2024a; Sculley et al., 2015; Alahdab and Çalıklı, 2019; Tang et al., 2021; Washizaki et al., 2019; Moreschini et al., 2024; Wang et al., 2023b). viii. Duplicate Model Code: This debt occurs when identical or near-identical model functions, utilities, or architectural components are replicated across codebases or modules. It often results from parallel experimentation or copy-paste development practices. Impact: Leads to inconsistent behavior, duplicate bugs, and increased maintenance effort. Updating a single model component requires tracking and modifying multiple copies. Use Case: Two research teams independently copy the same LSTM layer implementation and introduce different small changes, resulting in inconsistent behavior across models. Redundant model code across various analytics models within an organization, requiring changes to be made in multiple locations. Justification (Why): The core issue—replication of model logic across code—is a model/code-level maintainability debt. Source(s): (Tang et al., 2021; Albuquerque et al., 2022; Van Oort et al., 2021; Li et al., 2023b, c; OBrien et al., 2022; Pérez et al., 2021; Jebnoun et al., 2022; Khanvilkar et al., 2025; Li et al., 2022). ix. Unwanted Debugging Code (UDC): UDC refers to temporary print statements, debug logs, or ad-hoc instrumentation left in production code. In AI systems, where inputs often include sensitive data, such artifacts may inadvertently expose information or distort performance measurements. Impact: It degrades performance, increases log noise, risks leaking confidential information, and complicates monitoring pipelines. Use Case: Residual debug logs unintentionally record user-provided medical symptoms in server logs, violating privacy obligations. Temporary code snippets used to debug a recommendation engine that, if left in production, could expose sensitive data paths. Justification (Why): This debt arises from failure to clean up experimental instrumentation, clearly falling within model and code practices. Source(s): (Recupito et al., 2024a; Li et al., 2023b, c; OBrien et al., 2022; Pérez et al., 2021). x. Glue Code (GC): GC refers to fragile, hand-crafted code used to connect components that were not designed to interoperate. In AI systems, this often appears in bridging incompatible frameworks, data structures, or inference formats. This debt arises when large amounts of code are written specifically to integrate libraries or components that were not initially designed to work together. Glue code often lacks proper organization, which complicates future maintenance. Impact: It increases brittleness, reduces portability, complicates debugging, and introduces hidden dependencies that hinder scaling and refactoring. Use Case: Developers write custom JSON converters to translate between two ML microservices instead of using a shared schema or API contract. Justification (Why): GC is inherently a code-level integration shortcut, belonging naturally to the Model & Code–Related Debts category. Source(s): (Recupito et al., 2024a; Sculley et al., 2015; Alahdab and Çalıklı, 2019; Costal et al., 2024; Tang et al., 2021; Washizaki et al., 2019; Van Oort et al., 2021; Arpteg et al., 2018; Li et al., 2023b, c; Lenarduzzi et al., 2021; OBrien et al., 2022; Pérez et al., 2021; Moreschini et al., 2024; Shivashankar and Martini, 2022; Belani et al., 2019; Bavota and Russo, 2016; Wang et al., 2023b). All debts in this category arise from implementation-level deficiencies—including poor modularization, ad-hoc experimentation, fragile integrations, runtime coupling, and unmanaged code evolution. While these debts are not exclusive to AI-based systems and may also occur in traditional software, they are particularly prevalent and impactful in AI-enabled systems due to their tight coupling between data, models, and code. As a result, these debts weaken maintainability, increase operational risk, and hinder the scalability of AI-based systems 4.1.3. Algorithm-Related Debts These arise from deficiencies in the conceptual design, ethical alignment, optimization objectives, or evaluation strategies of AI models. Unlike Model & Code–Related Debts, which stem from implementation and structural issues, Algorithm-Related Debts originate in the fundamental reasoning logic encoded in algorithmic choices, objective functions, and evaluation protocols. These debts influence how AI systems learn, generalize, and behave under real-world conditions, often with long-term consequences for fairness, explainability, robustness, and trustworthiness. Because algorithmic decisions shape the system’s predictive behavior and risk profile, debts in this category propagate into downstream models, user interactions, and sociotechnical ecosystems. The following debts fall under this category. i. Algorithm Inclination Debt (Human Bias Debt): Occurs when bias is inadvertently embedded within the model design, objective functions, or feature selection strategies. Unlike Data Debt, which concerns bias in the training corpus, this debt reflects bias introduced by model developers—through choices such as skewed class weights, inappropriate regularization terms, or the omission of fairness-aware modeling techniques. These decisions influence who benefits or is disadvantaged by the model’s outputs. It also refers to a bias introduced by over-reliance on familiar algorithms, even when they are suboptimal for the problem. Impact: It leads to discriminatory outcomes, lower fairness, undermined user trust, and legal or ethical liabilities. Such bias often snowballs in production systems, particularly in high-stakes applications such as credit scoring, hiring, policing, and healthcare. Use Case: A loan-approval classifier is optimized solely for overall accuracy on an imbalanced dataset. Because the cost of false negatives is not penalized for minority applicants, the model disproportionately rejects their applications—a consequence stemming from the unfair optimization objective, not the raw data itself. A recommendation system using outdated algorithms that fail to adapt to user behavior, causing dissatisfaction. Justification (Why): This debt is categorized under Algorithm-Related Debts because the root cause is the algorithmic formulation—not code quality or data defects. It emerges from modeling choices, loss-function configuration, class balancing strategies, and inductive biases directly encoded into the learning process. Source(s): (Chaudhary et al., 2018; Liu et al., 2020; Chen et al., 2023; Arpteg et al., 2018; Liu et al., 2021; Simon et al., 2023; Wang et al., 2023b; Nikanjam and Khomh, 2021; Li et al., 2022; de Souza Santos et al., 2025). i. Ethical Debt: Ethical Debt accumulates when the development process neglects moral, societal, or human-centric considerations—such as user consent, privacy preservation, transparency, or fairness. Ethical Debt differs from Algorithm Inclination Debt in that it encompasses broader governance-level harms beyond algorithmic optimization, including neglect of ethical guidelines, insufficient documentation of value trade-offs, and absence of bias-impact assessments. Impact: It increases the risk of harmful or discriminatory system behavior, erodes public trust, exposes organizations to regulatory penalties, and can lead to reputational damage. Ethical Debt often becomes visible only after deployment when real-world impacts emerge. Use Case: A facial-recognition model is deployed in a public environment without transparency documentation or ethical risk analysis. Later, it is found to perform poorly on underrepresented demographic groups, leading to public backlash and regulatory scrutiny. A healthcare AI system that exhibits racial bias due to lack of diverse data, resulting in unequal treatment recommendations. Justification (Why): Ethical Debt belongs to this category because its origin is algorithmic governance and moral oversight. It reflects decisions made at the conceptual design and alignment stage, rather than issues of code structure or operational infrastructure. Source(s): (Menshawy et al., 2024; Chang and Custis, 2022; Roselli et al., 2019; Petrozzino, 2021). i. Overly Simplified Metrics: refers to the use of oversimplified, misaligned, or insufficient evaluation metrics that fail to capture the real-world performance, safety, or societal impacts of AI models. Focusing solely on metrics such as accuracy, precision, or F1-score may obscure system vulnerabilities—such as sensitivity to out-of-distribution data, robustness under adversarial conditions, or fairness disparities. It can also refer to the use of metrics that are generic or misaligned with specific problem requirements. Impact: This debt leads to misleading validation results, a false sense of model reliability, and unanticipated failures when deployed in dynamic environments. Models optimized for incomplete or Overly Simplified Metrics may perform well in controlled experiments but fail dramatically in real-world contexts. Use Case: A medical-diagnosis model is evaluated exclusively using overall accuracy. Rare but critical conditions (minority classes) are under-detected because the metric does not capture the cost of false negatives. Deployment then results in missed diagnoses and potential patient harm. Justification (Why): The root cause lies in evaluation-design inadequacy, an algorithmic-level failure to define meaningful and context-aware success metrics. Therefore, Overly Simplified Metrics Debt is rightfully placed under Algorithm-Related Debts rather than testing or data categories. Source(s): (Chaudhary et al., 2018; Khanvilkar et al., 2025; Ximenes et al., 2025). Algorithm-Related Debts arise from conceptual design choices that govern how AI systems learn, reason, and behave. These debts are epistemic rather than structural—stemming from flawed optimization objectives, inadequate evaluation strategies, or ethical misalignment rather than software engineering deficiencies. If left unaddressed, they compromise fairness, safety, trustworthiness, and long-term societal impact, making them critical to responsible AI development and governance. 4.1.4. Design/Architecture Debts These debts arise from deficiencies in the structural organization, interface boundaries, and configuration management of AI-based systems. These debts reflect weaknesses in how system components are designed, how architectural layers interact, and how configurations are specified, tracked, and maintained. Unlike Model & Code–Related Debts, which emerge from implementation artifacts, these debts originate earlier in the system’s conceptual and structural design. They compromise long-term extensibility, maintainability, and reproducibility—attributes especially critical in AI systems, where models depend on complex pipelines, configurable hyperparameters, and evolving architectural patterns. The debts in this category collectively undermine internal cohesion, architectural integrity, and configuration reliability. i. Jumbled Model Architecture (JMA): JMA arises when AI models—particularly deep learning architectures—lack coherent structural organization. Examples include inconsistent layering schemes, irregular activation patterns, or ad-hoc combinations of architectural modules. Such models often originate from rapid experimentation or incremental patching during prototyping. Impact: It reduces interpretability, increases training instability, complicates debugging, and diminishes the model’s ability to generalize. Since architecture heavily influences representational learning, fragmented structures can introduce vanishing gradients, bottlenecks, or redundant paths. Use Case: A computer vision team alternates between different convolutional block types across layers due to experimentation. The resulting architecture exhibits sporadic gradient explosions during training, making optimization highly unstable; An AI system developed with a mix of different neural network architectures without clear separation between components, leading to difficulties in maintenance. Justification (Why): JMA belongs to this category because it reflects a design-phase structural deficiency rather than implementation or code-level issues. The root cause is architectural inconsistency originating from poor design discipline. Source(s): (Recupito et al., 2024a; Albuquerque et al., 2022; Li et al., 2023c; Foidl et al., 2019; Pérez et al., 2021; Sas and Avgeriou, 2023; Li et al., 2022; Pérez et al., 2019; Cunha et al., 2020). i. Boundary Erosion: This occurs when architectural boundaries—such as module interfaces, layer abstractions, or service contracts—are violated. In AI systems, this may manifest when data preprocessing modules directly interact with model internals, or when models bypass APIs to access raw system components. Over time, the boundaries between components in an AI system may erode due to complex interdependencies, weakening the modularity of the system and increasing maintenance difficulty. Impact: It increases coupling, reduces modularity, and exposes internal components to misuse. Eroded boundaries introduce security risks, complicate dependency management, and restrict the ability to update or replace components independently. Use Case: In a multi-model AI platform, as models become interdependent, changes in one affect others, eroding the clear separation between components; A feature-engineering script directly injects intermediate tensors into a model’s internal layers for debugging. Later changes to the model break the pipeline, as external components were never meant to interact with these layers; Justification (Why): Boundary Erosion’s root cause is architectural-layer violation, making it conceptually distinct from code smells or operational issues and thus appropriately classified here. Source(s): (Sculley et al., 2015; Chaudhary et al., 2018; Tang et al., 2021). i. AI Architectural Debt Refers to architectural or structural decisions that trade long-term quality for short-term speed, simplicity, or expedience. In AI systems, this often appears as simplistic model wrappers, hard-coded hyperparameters, or missing abstraction layers that prevent future scaling or generalization. Impact: It limits reusability, slows feature development, and introduces fragility into evolving codebases. Poor design also impedes systematic monitoring, experimentation, and integration—key aspects of continuous AI deployment. Use Case: A research team wraps a model inside a single script without separating preprocessing, inference, and monitoring logic. As production requirements evolve, each modification forces large-scale refactoring. Justification (Why): Design Debt is inherently a structural design failure, justifying its assignment to this category rather than implementation or operational domains. Source(s): (Liu et al., 2020; Albuquerque et al., 2022; Li et al., 2023b, c; Pérez et al., 2021; Jebnoun et al., 2022; Bavota and Russo, 2016; Yan et al., 2018; Liu et al., 2021; Nikanjam and Khomh, 2021; Li et al., 2022; de Souza Santos et al., 2025; Sutoyo and Capiluppi, 2024). iv. Configuration Debt: This debt arises when hyperparameters, environment variables, or system settings are poorly documented, inconsistently defined, or not version-controlled. In AI systems—where configuration governs behavior as much as code—such inconsistencies cause unpredictability and hinder reproducibility. Over time, configuration settings in an AI system become overly complex or difficult to manage, increasing the risk of errors and misconfiguration. Impact: It produces experimental inconsistencies, failed model replications, training divergence, or mismatched behavior between training and inference. Configuration Debt frequently leads to irreproducible results, a central challenge in machine learning research. Use Case: A deep learning model fails to reproduce validation accuracy because random seeds, batch sizes, and learning schedules were not logged during earlier experiments; An AI system with numerous hyperparameter settings, making it difficult for operators to manage configurations accurately across deployment environments. Justification (Why): This debt reflects configurational mismanagement, a structural rather than implementation issue, and is therefore appropriately grouped under this category. Source(s): (Sculley et al., 2015; Alahdab and Çalıklı, 2019; Zhang et al., 2022a; Tang et al., 2021; Chen et al., 2023; Foidl et al., 2019; Breck et al., 2017; Jebnoun et al., 2022; Belani et al., 2019; Khanvilkar et al., 2025; Nikanjam and Khomh, 2021; Ximenes et al., 2025). v. Compatibility Debt: This emerges when AI components rely on outdated, incompatible, or conflicting frameworks, model formats, or serialization schemes. This often occurs when transitioning between versions of TensorFlow, PyTorch, ONNX, or other tooling ecosystems. Impact: It hinders system evolution, complicates deployment across environments, increases integration overhead, and may prevent models from being exported or reused across platforms; Incompatibilities among system components lead to inefficient workarounds, raising system complexity and maintenance challenges. Use Case: A model trained in an older TensorFlow version cannot be exported to ONNX without extensive patching, delaying migration to a faster inference engine. Justification (Why): Its origin lies in architectural and design decisions regarding toolchain selection, framework versions, and dependency constraints—not in code-level implementations. Source(s): (Liu et al., 2020; Chen et al., 2023; Lenarduzzi et al., 2021; Liu et al., 2021). vi. Abstraction Debt: Occurs when interfaces are overly generic, insufficiently defined, or inconsistently structured. Poor abstraction design leads to convoluted inheritance hierarchies, unclear responsibilities, and tightly coupled components. Impact: It makes model components harder to extend, test, and reuse. Abstraction Debt often introduces hidden coupling and forces developers to modify low-level details even for high-level changes. Use Case: A base “Model” class defines ambiguous abstract methods, causing inconsistent implementations across subclasses. Adding a new training mode requires modifying nearly all subclassed models. Justification (Why): This debt’s root cause is inadequate abstraction in design, making it a prototypical structural debt falling under Design, Architecture & Configuration. Source(s): (Sculley et al., 2015; Costal et al., 2024; Tang et al., 2021; Washizaki et al., 2019). Design, Architecture & Configuration Debts reflect structural and conceptual weaknesses introduced during the design and configuration stages of AI system development. These debts degrade modularity, hinder reproducibility, and amplify technical friction across the lifecycle. They differ from implementation-level debts because their origins lie in poor architectural foresight, inconsistent configuration practices, and inadequate abstraction mechanisms rather than the code itself. 4.1.5. Operational & Lifecycle Debts These emerge from weaknesses in the processes, infrastructure, and versioning practices that support the continuous development, deployment, and maintenance of AI systems. Unlike debts rooted in design or implementation, these reflect failures in operational discipline and lifecycle governance, including inadequate CI/CD automation, untracked evolution of model artifacts, and ambiguous requirements that lead to rework. Because AI systems require tight synchronization across model, data, and environment versions, even routine operational lapses can manifest as long-term technical liabilities, particularly in production environments. i. Requirement Debt: This accumulates when functional or quality attribute specifications are ambiguous, incomplete, or inconsistently communicated (Ernst et al., 2021). AI systems are particularly vulnerable because their performance depends on well-defined metrics, target thresholds, and operational constraints. Poor requirement alignment often leads to misinterpretation of expected outcomes or inappropriate model objectives. Impact: This debt results in rework, misaligned performance goals, wasted experimentation cycles, and delayed delivery. It also increases the risk of deploying models that fail to meet stakeholder expectations or regulatory requirements. Use Case: A healthcare model is trained to maximize accuracy, but stakeholders later clarify that minimizing false negatives is critical for patient safety. The model must be retrained, causing significant delays; An AI-based e-commerce system where user experience requirements were insufficiently defined, leading to an incomplete recommendation feature. Justification (Why): Because the root cause is inadequate requirements engineering within the lifecycle, Requirements Debt is classified as an Operational & Lifecycle Debt rather than an algorithmic or design-level issue. Source(s): (Liu et al., 2020; Albuquerque et al., 2022; Li et al., 2023b, c; OBrien et al., 2022; Pérez et al., 2021; Moreschini et al., 2024; Nahar et al., 2022; Belani et al., 2019; Bavota and Russo, 2016; Liu et al., 2021; Li et al., 2022; de Souza Santos et al., 2025; Sutoyo and Capiluppi, 2024). i. Defect Debt: This arises when known bugs or system flaws are deferred for future resolution, often due to time pressure or resource limitations. These defects may include incorrect preprocessing logic, mislabeled data, unstable model behaviors, or unhandled exceptions. Impact: It reduces system reliability, increases the frequency of runtime failures, and demands greater developer time to diagnose and correct issues later in the lifecycle. Use Case: A feature extractor intermittently outputs NaN values during training. The issue is noted but deprioritized. Over time, the intermittency increases, leading to complete training failure during a critical deployment phase. Justification (Why): The root cause is post-development defect tolerance, an operational choice that directly affects lifecycle maintenance. Source(s): (Liu et al., 2020; Albuquerque et al., 2022; Li et al., 2023c; OBrien et al., 2022; Pérez et al., 2021; Bavota and Russo, 2016; Yan et al., 2018; Liu et al., 2021; Li et al., 2022). i. Versioning Debt: This occurs when model artifacts, datasets, code modules, or environment configurations are not appropriately version-controlled. AI systems heavily depend on deterministic versioning to ensure reproducibility, auditability, and rollback capability. Poor version control practices lead to challenges in tracking changes, maintaining compatibility, and reproducing past results. Impact: It obstructs experiment tracking, prevents reproducibility of results, hinders debugging, and complicates compliance audits. Models may behave unpredictably because different environment or dataset versions inadvertently enter the pipeline. Use Case: A new model underperforms during A/B testing. Investigation reveals that the training dataset version differs from the dataset used in validation, but no version metadata was tracked. Justification (Why): Because the root cause lies in lifecycle artifact management, this debt belongs to the Operational & Lifecycle category. Source(s): (Washizaki et al., 2019; Albuquerque et al., 2022; Pérez et al., 2021; Côté et al., 2024; Shukla and Cartlidge, 2022). iv. Process/Infrastructure Debt: This debt arises from outdated, inconsistent, or manual operational workflows, including CI/CD pipelines, orchestration processes, hardware provisioning, or monitoring infrastructure. AI lifecycles often rely on complex tooling (e.g., model registries, deployment orchestrators, monitoring dashboards), making process deficiencies especially harmful. Impact: It slows deployment cycles, increases operational risk, reduces system scalability, and introduces failure points due to manual interventions. Use Case: A model deployment pipeline requires manual execution of several scripts. When an urgent patch is needed, a step is executed incorrectly, causing service downtime; An AI-based recommendation system with an outdated build pipeline lacking automation. Justification (Why): Since the underlying issue is lack of automation and process maturity, it is appropriately placed under Operational & Lifecycle Debts. Source(s): (Lenarduzzi et al., 2021; Pérez et al., 2021; Nahar et al., 2022). v. Build Debt: This accumulates when build scripts, Dockerfiles, environment specifications, or compilation pipelines become fragmented, non-standardized, or poorly maintained. This often results from ad-hoc experimentation during early development stages. Impact: It causes inconsistent builds, extends debugging time, creates deployment fragility, and increases onboarding complexity. Build Debt is a common source of environment drift between development, testing, and production; Results in unreliable deployment processes and system instability. Use Case: A production inference container fails because a dependency version differs from development. The mismatch originates from an outdated Dockerfile with ambiguous version specifications. Justification (Why): The root cause is build environment instability, making this a lifecycle and operational concern rather than a code-level one. Source(s): (Li et al., 2023c; Pérez et al., 2021; Li et al., 2022). These debts all stem from operational misalignment, inadequate automation, and poor lifecycle management practices. If unaddressed, they significantly undermine the reliability, reproducibility, and agility of AI development and deployment. 4.1.6. Documentation and Communication Debt These debts originate from insufficient documentation, weak communication channels, and inadequate knowledge transfer practices across teams. AI systems rely on complex interactions between data engineers, ML researchers, software developers, and domain experts. When documentation is incomplete or communication is fragmented, system behavior becomes opaque, maintenance becomes slower, and organizational risk increases. These debts reflect socio-technical deficiencies rather than purely technical ones. i. Documentation Debt: This arises when key artifacts—such as model behavior, preprocessing steps, data assumptions, evaluation methodologies, or architectural decisions—are insufficiently documented, outdated, or missing entirely (Ernst et al., 2021). Impact: It slows onboarding, increases maintenance effort, complicates audits, and leads to miscommunication during handovers. For AI systems, lack of documentation also undermines explainability, transparency, and regulatory compliance; Poor documentation creates obstacles for developers to maintain and extend AI systems effectively, resulting in reduced system reliability. Use Case: A deployment engineer attempts to reproduce a training run but cannot locate information on normalization strategies used in the original experiment, resulting in inconsistent model behavior; Sparse documentation in a complex AI model for disease diagnosis, which complicates onboarding new developers and troubleshooting. Justification (Why): This debt’s root cause is deficiency in documentation and knowledge management, making it a socio-technical rather than algorithmic or architectural debt. Source(s): (Liu et al., 2020; Albuquerque et al., 2022; Li et al., 2023b, c; Hutchinson et al., 2021; OBrien et al., 2022; Pérez et al., 2021; Nahar et al., 2022; Chang and Custis, 2022; Côté et al., 2024; Bavota and Russo, 2016; Liu et al., 2021; Wang et al., 2023b; Li et al., 2022; Sutoyo and Capiluppi, 2024). i. Cultural/People/Social Debt: This debt arises when teams have misaligned communication practices, insufficient collaboration, or conflicting expectations. In AI settings, teams often operate in silos—data engineers manage schemas, ML researchers iterate on models, and software engineers maintain deployments—causing integration friction. It also refers to the differences in culture, values, or priorities between teams, such as research and engineering, leading to misalignments (Ernst et al., 2021). Impact: It leads to coordination failures, inconsistent workflows, misconfigured models, duplicated effort, and erroneous assumptions about system behavior. It also increases risk in safety-critical or regulated contexts. Use Case: An ML team updates a model’s input schema but does not communicate the change to the data engineering team. As a result, the data pipeline continues to produce the old schema, causing runtime failures and misaligned features. Justification (Why): The root cause is organizational misalignment, not technical implementation defects. Thus, it aligns naturally with Documentation & Communication Debts. Source(s): (Arpteg et al., 2018; Lenarduzzi et al., 2021; Pérez et al., 2021; Menshawy et al., 2024; Moreschini et al., 2024; Nahar et al., 2022; Mailach and Siegmund, 2023; Annunziata et al., 2025; de Souza Santos et al., 2025; Akman et al., 2025). Documentation & Communication Debts highlight the human and organizational dimension of technical debt. These debts impair transparency, collaboration, and maintainability, especially in interdisciplinary AI teams where knowledge silos are common. 4.1.7. Testing and Quality Assurance Debt These debts emerge from insufficient verification, limited test coverage, and overlooked quality-assurance practices. AI systems require testing not only of code correctness but also of data pipelines, model behavior under distribution shifts, fairness metrics, and robustness to adversarial conditions. Inadequate testing accelerates technical debt accumulation, reduces trustworthiness, and increases the likelihood of harmful failures in production. i. Test Debt: Test Debt accumulates when testing suites are incomplete, outdated, or insufficient to assess AI system behavior. This includes lack of unit tests for preprocessing logic, missing integration tests, absence of fairness or robustness evaluations, and insufficient testing of edge-case inputs (Ernst et al., 2021). Impact: It leads to undetected regressions, silent model degradation, vulnerability to distribution shifts, and reduced confidence in deployments. Test Debt often manifests only when unexpected failures occur in real-world usage. Use Case: A sentiment-analysis model fails to handle emerging slang and social-media phrases because its test suite only covers standard dictionary terms. A predictive analytics model deployed without comprehensive testing, resulting in undetected errors in real-time use. Justification (Why): The debt originates from insufficient QA practices, making it distinct from data, architecture, and operational deficiencies. Source(s): (Liu et al., 2020; Tang et al., 2021; Albuquerque et al., 2022; Arpteg et al., 2018; Li et al., 2023b, c; Lenarduzzi et al., 2021; Breck et al., 2017; OBrien et al., 2022; Pérez et al., 2021; Shivashankar and Martini, 2022; Bavota and Russo, 2016; Liu et al., 2021; Wang et al., 2023b; Li et al., 2022; de Souza Santos et al., 2025; Sutoyo and Capiluppi, 2024). RQ1.1: The analysis revealed that AI Technical Debts (AITDs) are best explained through a root-cause–oriented perspective comprising seven overarching categories: (1) Data & Library-Related Debts, (2) Model & Code-Related Debts, (3) Algorithm-Related Debts, (4) Design, Architecture & Configuration Debts, (5) Operational & Lifecycle Debts, (6) Documentation & Communication Debts, and (7) Testing & Quality Assuarance Debts. By grounding the taxonomy in the underlying engineering sources—such as data instability, structural design flaws, algorithmic misalignment, inadequate lifecycle processes, and socio-technical communication gaps—the classification provides a holistic and integrative view of the diverse mechanisms through which technical debt accumulates in AI-based systems. RQ1.2: Through grounded theory analysis, we identified and refined a total of 31 distinct AITDs reported across the 60 primary studies. These debts span all seven root-cause categories and collectively reflect the multifaceted nature of technical debt in AI-enabled systems. Their prevalence varies considerably across the literature, with Data Debt (45.00%), Glue Code (30.00%), and Test Debt (28.33%) emerging as the most frequently reported issues. Table 4 summarizes the occurrence frequencies and provides a detailed overview of how often each debt type appears across empirical studies. Table 4. Overview of AI Technical Debts (AITDs) as part of the systematic review # AITD Freq(n=60) % Category 1 Data Debt/Unstable Data Dependencies 27 45.00 Data/Library Related Debts 2 Glue Code (GC) 18 30.00 Model/Code Related Debts 3 Test Debt 17 28.33 Testing & Quality Assurance Debts 4 Documentation Debt 15 25.33 Documentation & Communication Debts 5 Requirement Debt 14 23.33 Operational & Lifecycle Debts 6 AI Architectural Debt 13 21.67 Design & Architecture Debts 7 Configuration Debt 12 20.00 Design & Architecture Debts 8 Dead Experimental Code Paths/Prototype Debt 11 18.33 Model/Code Related Debts 9 Algorithm Debt/Inclination/Human Bias 10 16.67 Algorithm Related Debts 10 Duplicate Model Code 10 16.67 Model/Code Related Debts 11 Cultural/People/Social Debt 10 16.67 Documentation & Communication Debts 12 Pipeline Jungle 9 15.00 Data/Library Related Debts 13 Jumbled Model Architecture (JMA) 9 15.00 Design & Architecture Debts 14 Hidden Feedback Loops 9 15.00 Model/Code Related Debts 15 Defect Debt 9 15.00 Operational & Lifecycle Debts 16 Multiple Language Smells (MLS) 7 11.67 Model/Code Related Debts 17 Undeclared consumers 6 10.00 Model/Code Related Debts 18 Ethical Debt 6 10.00 Algorithm Related Debts 19 Unwanted Debugging Code (UDC) 5 8.33 Model/Code Related Debts 20 Versioning Debt 5 8.33 Operational & Lifecycle Debts 21 Correction Cascades (C) 4 6.67 Model/Code Related Debts 22 Entanglement 4 6.67 Model/Code Related Debts 23 Compatibility Debt 4 6.67 Design & Architecture Debts 24 Abstraction Debt 4 6.67 Design & Architecture Debts 25 Dispensable Dependency 3 5.00 Data/Library Related Debts 26 Boundary Erosion 3 5.00 Design & Architecture Debts 27 Overly Simplified Metrics 3 5.00 Algorithm Related Debts 28 Process/Infrastructure Debt 3 5.00 Operational & Lifecycle Debts 29 Build Debt 3 5.00 Operational & Lifecycle Debts 30 Scattered Use of ML Libraries (SML) 2 3.33 Data/Library Related Debts 31 Deep God File (DG) 2 3.33 Model/Code Related Debts 4.2. Analysis of the Identified AITDs and Their Implications Through the Lens of AI TRiSM Table 4 summarizes the 31 AI Technical Debts (AITDs) identified across the 60 primary studies and ranks them by frequency and percentage occurrence. The distribution reveals several dominant forms of debt that consistently appear across diverse AI system development contexts. Data Debt is the most frequently reported AITD, appearing in 45.00% of the studies. This debt category reflects persistent data governance and data-quality challenges, including unstable data dependencies, schema inconsistencies, missing metadata, and untracked transformations. Given that AI systems rely on continuously evolving and heterogeneous data sources, these deficiencies lead to model drift, silent performance degradation, and reproducibility failures. Data Debt remains the most systemic and foundational problem recorded in the literature. Glue Code is the second-most prevalent, reported in 30.00% of the studies. It captures the ad-hoc integration logic used to connect disparate data pipelines, libraries, model components, and deployment tools. Although Glue Code enables rapid experimentation—particularly in early development phases—it produces fragile, highly coupled systems that are difficult to extend or debug. This debt reflects the rapid, tool-centric, and exploratory nature of typical AI workflows. Test Debt ranks third, appearing in 28.33% of the included studies. AI-based systems require extensive testing not only at the code level but also across data transformations, model behavior, fairness, robustness, and performance under distribution shift. The literature indicates that teams frequently deprioritize testing due to the difficulty of specifying expected ML behavior or the iterative nature of model development. This leads to insufficient test coverage, poor monitoring, and higher risk of failure in deployment settings. Documentation Debt follows closely at 25.33%. As AI projects involve interdisciplinary teams (AI researchers, ML engineers, domain experts), inadequate documentation compromises maintainability, reproducibility, and onboarding. Missing or outdated dataset descriptions, model cards, configuration files, feature-engineering rationales, and pipeline diagrams hinder long-term system understanding and evolution. Requirement Debt appears in 23.33% of the studies, illustrating how evolving stakeholder needs and ambiguous system goals affect AI development. Requirement Debt often arises when model behavior is not fully specified or when performance and fairness requirements evolve during experimentation. This leads to incomplete implementations and rework. AI Architectural Debt and Configuration Debt were reported in 21.67% and 20.00% of the papers respectively. Design Debt arises from rushed architectural decisions and insufficient modularity—often exacerbated by early experimentation culture. Configuration Debt reflects the complexity of hyperparameters, environment variables, orchestration specifications, and deployment parameters, which, when poorly managed, cause reproducibility gaps and environment-dependent failures. Prototype Debtappear in 18.33% of the studies. Prototype Debt stems from experimental code that is prematurely reused in production. It illustrate the tension between research-driven iteration and production engineering. Following these, a second tier of moderately frequent debts (reported in 15–17% of studies) includes: Algorithm Inclination/Human Bias (16.67%), Duplicate Model Code (16.67%), Cultural/People/Social Debt (16.67%), Pipeline Jungle (15.00%), Jumbled Model Architecture (JMA) (15.00%), Hidden Feedback Loops (15.00%), Defect Debt (15.00%), Multiple Language Smells (MLS) (11.67%), Undeclared Consumers (10.00%), Ethical Debt (10.00%). These debts highlight structural, behavioral, and socio-technical issues such as unplanned architecture evolution (JMA), unintended system dynamics (Hidden Feedback Loops), implementation redundancy (Duplicate Model Code), ethically problematic decision pathways (Ethical Debt), and misalignment across teams (Cultural/People/Social Debt). The remaining AITDs, each appearing in fewer than 10% of the studies, include Unwanted Debugging Code (8.33%), Versioning Debt (8.33%), Correction Cascades (6.67%), Entanglement (6.67%), Compatibility Debt (6.67%), Abstraction Debt (6.67%), Dispensable Dependency (5.00%), Boundary Erosion (5.00%), Overly Simplified Metrics (5.00%), Process/Infrastructure Debt (5.00%), Build Debt (5.00%), Scattered Use of ML Libraries (3.33%), and Deep God File (3.33%). Although individually less frequent, these debts are still significant. Many reflect emerging or specialized risks unique to AI complexity, such as: unstable component borders (Boundary Erosion), cascading dependency breakages (Correction Cascades), flawed or manipulated evaluation criteria (Overly Simplified Metrics), architectural monoliths (Deep God File), tool fragmentation (Scattered ML Libraries). Their lower frequency does not imply low severity; several represent high-impact failure modes that are under-investigated in current research. The prevalence distribution reinforces the inherently multifaceted nature of AITDs. High-impact debts (Data Debt, Glue Code, Test Debt) correlate strongly with foundational AI engineering workflows—data management, model integration, and verification—while medium-frequency and low-frequency debts highlight structural, algorithmic, operational, and socio-technical weaknesses. In summary, the landscape of AITDs reveals a complex interplay between AI-specific engineering challenges and long-standing software quality concerns. The prevalence analysis indicates that AI-intensive systems demand specialized management strategies addressing data governance, integration practices, rigorous testing, reproducibility, and responsible algorithmic design to ensure sustainable and trustworthy AI development. Implications of Prevalent AITDs Through the Lens of AI TRiSM Taken together, the ten most prevalent AITDs identified in this review—Data Debt/Unstable Data Dependencies (Data/Library-Related Debts); Glue Code, Prototype Debt, and Duplicate Model Code (Model/Code-Related Debts); Test Debt (Testing & Quality Assurance Debts); Documentation Debt (Documentation & Communication Debts); Requirement Debt (Operational & Lifecycle Debts); AI Architectural Debt and Configuration Debt (Design & Architecture Debts); and Algorithmic Inclination/Human Bias (Algorithm-Related Debts)—exhibit clear, mechanism-level intersections with AI safety and AI security concerns. Data and library–related weaknesses (e.g., unstable data dependencies) increase the likelihood of unsafe behavior under data drift and reduce confidence in input validity. Model and code–related debts (e.g., glue code, duplicate model code, and prototype paths) introduce fragile integration layers and hidden dependencies that broaden attack surfaces and make failures harder to isolate. Testing and documentation deficits reduce fault and vulnerability discoverability and weaken auditability and incident response capabilities, while operational and architectural debts—such as requirements ambiguity, configuration drift, and architectural shortcuts—can embed unsafe assumptions, misconfigurations, and weak boundary controls into production systems. Finally, algorithm-related bias debt directly contributes to harmful outcomes and safety violations through systematic misbehavior across specific populations or operational contexts. This analysis demonstrates how the most frequently reported AITDs consistently map to concrete safety- and security-relevant risk pathways, thereby supporting an AI-TRiSM–aligned perspective on AITD management. This mapping, however, should be regarded as an initial analytical step; Sections 5 and 6 provide a deeper examination of how these AITDs propagate and compound risks related to security and safety, as well as their management -the foundational pillars of AI TRiSM—thereby directly addressing RQ2–RQ3. 5. AITDs - Safety and Security Concerns (RQ2) 5.1. Safety Concerns The increasing integration of AI in high-stakes domains has amplified the need to address critical safety concerns that extend beyond technical debt and performance limitations. As detailed in prior AI safety literature, particularly in (Salhab et al., 2024; Rajendran et al., 2021; Gyevnár2025531; Bucaioni et al., 2025), key safety risks emerge due to the opaque, non-deterministic, and dynamic nature of AI systems. These concerns are especially pronounced in systems leveraging deep learning and reinforcement learning models, which are often sensitive to environmental noise, distributional shifts, and adversarial manipulation. Table 5 presents a comprehensive mapping between these safety concerns and their related AITDs, providing an explanatory context for each relationship. 5.1.1. Explainability and Interpretability AI models - particularly deep learning architectures - often operate as black boxes, making it difficult for developers and stakeholders to understand, validate, or justify system decisions. In addition to this opacity, many AI models exhibit inherently stochastic behavior due to probabilistic inference, non-deterministic training processes, and adaptive updates. Such stochasticity reduces predictability, which has traditionally been a cornerstone of safety and security engineering. Together, limited interpretability and non-deterministic behavior pose significant safety risks in domains such as healthcare, finance, and autonomous systems, where accountability, traceability, and reliable error analysis are essential (Gyevnár2025531; Xu et al., 2019; Sheh, 2021; Albahri et al., 2023; Adadi and Berrada, 2018; Krajna et al., 2022; Chamola et al., 2023). Related AITDs: • Jumbled Model Architecture: Poorly structured and undocumented model architectures obscure the internal logic of AI systems, making it difficult to interpret model behavior or trace decision flows. • Overly Simplified Metrics: When models are evaluated using high-level, generic metrics (e.g., accuracy), without alignment to context-specific safety goals (e.g., false negatives in medical diagnosis), the model’s performance becomes misleading and less interpretable. • Documentation Debt: Lack of sufficient documentation about models, features, and training processes severely impairs the ability of users and auditors to interpret system logic, creating blind spots in safety validation efforts. 5.1.2. Robustness and Reliability Robustness is the ability of AI systems to remain stable and accurate under perturbations, noisy data, or adversarial conditions (Gyevnár2025531; Wang et al., 2023a; Girard-Satabin et al., 2022; Zhao et al., 2021; Akram et al., 2022; Tarchoun et al., 2022; Arnez et al., 2021b; Mziou Sallami et al., 2019; Choi et al., 2022; Carlini and Wagner, 2017). Reliability ensures consistent performance over time and across various deployment environments. A lack of robustness and reliability can cause erratic behavior and system failures, undermining trust and safety in AI operations (Fisher et al., 2021; Schwartz et al., 2020; Maabreh et al., 2022b; Kshetry and Varshney, 2019; Zhao et al., 2020; Werner et al., 2023). Related AITDs: • Data Debt: Poor quality, inconsistent, or evolving training data leads to brittle models that fail when exposed to real-world or shifted inputs. • Defect Debt: Known but unresolved bugs in the system compromise reliability, especially as they accumulate and interact unpredictably with evolving components. • Test Debt: Inadequate testing, particularly in edge-case scenarios, increases the likelihood of system crashes or incorrect outputs under stress conditions. 5.1.3. Transparency and Trustworthiness Transparency refers to the ability to inspect, understand, and verify AI processes (Cooper et al., 2022; Krajna et al., 2022; Sokol and Flach, 2019; Zhao et al., 2020; Sheh, 2021; Buczak et al., 2022; Chamola et al., 2023; Samadi et al., 2023). Trustworthiness builds upon transparency by assuring users that the system behaves ethically, consistently, and as intended (Bravo-Rocca et al., 2022; Srinivasan and Chander, 2019; He et al., 2021; Chamola et al., 2023; Steimers and Bömer, 2021; Hagendorff, 2021). In safety-critical settings, lack of transparency can result in hidden vulnerabilities, while eroded trust may prevent responsible AI adoption. Related AITDs: • Documentation Debt: Insufficient documentation prevents clear understanding of system behavior, hindering transparency and the ability to audit the model pipeline. • Versioning Debt: Poor version tracking of datasets, models, or parameters makes it difficult to reproduce results, undermining system transparency and regulatory traceability. • Ethical Debt: Failing to explicitly consider ethics or fairness in system design leads to opacity in value alignment, undermining user trust. 5.1.4. Bias and Fairness Bias in AI systems arises from imbalanced datasets, unrepresentative sampling, or discriminatory design choices. These biases compromise fairness and can result in systemic harm to individuals or groups, particularly in sensitive domains such as hiring, lending, and criminal justice (Kim and Cho, 2020; Srinivasan and Chander, 2019; Jaipuria et al., 2022; Kim and Cho, 2020). Related AITDs: • Algorithmic Inclination / Human Bias: Over-reliance on familiar or convenient algorithms, rather than evaluating fairness implications, can encode human or institutional bias into the system. • Ethical Debt: Failure to integrate ethical design principles allows biased data or assumptions to propagate unchecked, resulting in unfair or unsafe model decisions. • Overly Simplified Metrics: Metrics that fail to account for fairness dimensions (e.g., equal opportunity, demographic parity) obscure potential bias and mask harmful outcomes. 5.1.5. Adversarial and Poisoning Attacks Adversarial attacks involve input manipulations crafted to mislead AI systems, while data poisoning injects malicious data into training pipelines to degrade model integrity. These threats compromise system safety by causing incorrect outputs that may go undetected in critical environments (He et al., 2021; Carlini and Wagner, 2017; Maabreh et al., 2022a, b; Ali et al., 2020). Related AITDs: • Algorithmic Inclination / Human Bias: Use of predictable or widely known algorithms increases susceptibility to adversarial manipulation, especially if security hardening is not prioritized. • Correction Cascades: Inter-model dependencies make it possible for adversarial changes in one component to cascade through the system, amplifying unsafe behaviors. • Entanglement: Tight coupling between components means that adversarially targeted faults in one model can trigger ripple effects, leading to systemic vulnerabilities. 5.1.6. Out-of-Distribution (OOD) Generalization AI systems are often trained in controlled settings and may fail when deployed in real-world environments that differ from their training data distributions. OOD generalization failures can result in unsafe decisions, especially when the system is unaware of its own limitations (Rajendran et al., 2021; Kamoi and Kobayashi, 2020; Arnez et al., 2021a; Rossolini et al., 2022; Girard-Satabin et al., 2022; Bravo-Rocca et al., 2022; Carlini and Wagner, 2017; Haider et al., 2023). Related AITDs: • Pipeline Jungle: Overly complex and interdependent data pipelines hinder the ability to adapt to new data distributions, leading to failures in OOD settings. • Dead Experimental Code Paths / Prototype Debt: Experimental or prototype components may lack robustness and are often not validated against diverse real-world data, making them vulnerable to distribution shifts. • Overly Simplified Metrics: Over-reliance on aggregate metrics during training can hide poor generalization performance on unseen inputs, leading to unsafe or unexpected system behavior post-deployment. Table 5. Mapping Safety Concerns to Related AI Technical Debts (AITDs) S/N Safety Concern Related AITDs Explanation 1 Explainability and Interpretability Jumbled Model Architecture, Overly Simplified Metrics, Documentation Debt Opaque model structures, vague or misaligned evaluation metrics, and poor documentation reduce the ability to understand or justify AI decisions—critical in high-stakes scenarios like healthcare and law. 2 Robustness and Reliability Data Debt, Defect Debt, Test Debt Poor data quality, unresolved bugs, and insufficient testing undermine model stability and cause erratic or unreliable performance in unpredictable real-world environments. 3 Transparency and Trustworthiness Documentation Debt, Versioning Debt, Ethical Debt Incomplete documentation, weak version tracking, and disregard for ethical considerations hinder traceability and reduce stakeholder confidence in the system’s outputs. 4 Bias and Fairness Algorithmic Inclination / Human Bias, Ethical Debt, Overly Simplified Metrics Systems trained on biased data or developed without ethical oversight can produce unfair or discriminatory results, particularly when using simplistic or poorly aligned performance metrics. 5 Adversarial and Poisoning Attacks Algorithmic Inclination / Human Bias, Correction Cascades, Entanglement Overused algorithms, coupled components, and cascading model dependencies increase the attack surface and enable faults or adversarial perturbations to propagate across the system. 6 Out-of-Distribution (OOD) Generalization Pipeline Jungle, Dead Experimental Code Paths, Overly Simplified Metrics Complex or disorganized pipelines, unvetted prototype code, and overly generic evaluation metrics result in models that perform poorly or dangerously when encountering unfamiliar input distributions. To provide a visual representation of the relationships between identified safety concerns and the corresponding AI technical debts, we present Figure 4. This mapping helps to clarify how various safety attributes are undermined by specific AITDs and reinforces the interconnectedness between safety assurance and technical debt management in AI systems. Figure 4. Visual Mapping of Safety Concerns to AI Technical Debts: Red circles represent safety concerns, while blue circles represent AITDs. Each safety concern is linked to its associated technical debts using color-coded edges, illustrating the multidimensional impact of technical debt on AI system safety. RQ2.1 – Safety Concerns in AI Systems AI Technical Debts (AITDs) undermine the safety of AI systems in high-stakes environments. Key safety risks include: • Low Explainability: Complex and poorly structured models reduce interpretability. • Poor Robustness: Fragile models fail under noisy or adversarial inputs. • Opaque Behavior: Documentation and versioning issues erode transparency and trust. • Bias Risks: Algorithmic shortcuts and Overly Simplified Metrics conceal unfair outcomes. • OOD Failures: Models trained on limited data generalize poorly to real-world inputs. Note: These risks demand proactive design, validation, and monitoring to ensure safe AI deployment. 5.2. Security Concerns AI systems, similar to conventional software systems, are exposed to dynamic threats and evolving adversarial attacks. However, these challenges are often amplified in AI-based systems due to their reliance on data-driven learning, probabilistic decision-making, and adaptive behaviors, which introduce additional uncertainty and complexity. Over time, these characteristics contribute to increased maintenance burdens, expanded attack surfaces, and greater difficulty in anticipating and mitigating security risks. As a result, these systems are vulnerable to a range of security threats that can introduce technical debt which can in turn introduce other security risks if not mitigated early. This section examines the security concerns associated with identified AI technical debts (AITDs). For each concern, a clear definition is provided, followed by a discussion of the relevant AITDs and their implications. Table 6 presents a comprehensive mapping between these security concerns and their related AITDs, providing an explanatory context for each relationship. It is important to note that many of these security concerns are not exclusive to AI-intensive systems; rather, consistent with our earlier observation that ML systems inherit the maintenance challenges of traditional software while introducing additional AI-specific issues (Sculley et al., 2015), these concerns also arise in conventional systems but are often intensified in AI-enabled contexts due to data dependence, adaptive behavior, and model-driven decision-making. 5.2.1. Authentication and Authorization This concern arises when AI systems lack robust authentication and authorization mechanisms, which are essential for controlling who can access the system or its data (Recupito et al., 2024a). Without these controls, unauthorized users could gain access to sensitive model outputs or even manipulate system behavior. Inadequate authorization systems can also allow unauthorized users to alter critical system parameters, increasing the risk of security breaches (Sculley et al., 2015). This is particularly dangerous in safety-critical applications where malicious modifications or unauthorized access could lead to severe consequences, such as in healthcare (Thota et al., 2018) or autonomous systems (Katzenbeisser et al., 2019). Related AITDs: • Undeclared Consumers: This AITD is directly related, as it arises from the failure to implement proper access controls and authentication mechanisms, leading to unauthorized usage of the model’s outputs. • Configuration Debt: Misconfigurations can weaken or bypass authentication and authorization mechanisms, increasing security risks. 5.2.2. Data Integrity and Validation When AI systems do not adequately validate their input data or ensure the integrity of the data they rely on, they become vulnerable to security risks. Data integrity debt occurs when a system begins to process inaccurate, incomplete, or manipulated data, leading to unsafe or unreliable results (Foidl and Felderer, 2019; Recupito et al., 2024a). For example, in AI systems handling financial transactions, if input data isn’t properly validated, attackers might exploit the system by feeding it fraudulent or corrupt data. This could lead to incorrect predictions or actions, such as approving unauthorized transactions or making unsafe decisions based on flawed information. Related AITDs: • Unstable Data Dependencies/Data Debt: This directly relates to data integrity issues, as unreliable data sources can introduce incorrect or outdated information into the model, leading to unsafe or insecure outcomes. • Hidden Feedback Loops: Feedback loops can interfere with the integrity of the system’s decision-making process, making it more prone to errors due to invalid data inputs. 5.2.3. Security Patch and Update This concern arises when security patches and updates for the underlying software, libraries, or dependencies in AI systems are not applied regularly. Over time, unpatched vulnerabilities expose the system to attacks that exploit known security flaws. Systems relying on outdated or vulnerable libraries are especially prone to exploitation (Wang et al., 2021). In safety-critical applications like healthcare or autonomous vehicles, failure to apply security patches can lead to catastrophic outcomes, as attackers might leverage these vulnerabilities to compromise the system’s functionality, cause data breaches, or trigger unsafe behaviors. Related AITDs: • Dispensable Dependency: Dependencies that are no longer necessary but not removed create vulnerabilities due to missed security patches and updates. • Inconsistent Use of ML Libraries: Scattered library use makes it difficult to apply security patches consistently across the system, leaving some parts vulnerable to attack. 5.2.4. Data Privacy and Confidentiality AI systems often handle sensitive data, and failing to implement adequate privacy and confidentiality safeguards creates debt. This includes insufficient encryption, anonymization, or access control for data stored or processed by the system. As a result, unauthorized access to personal or sensitive data can occur, leading to privacy breaches, legal liabilities, and loss of trust (Al Alamin and Uddin, 2021). For example, in AI-driven healthcare systems, improper protection of patient records could expose confidential medical information, putting both patients and the organization at risk of legal penalties and reputational damage (Nankya et al., 2024). Related AITDs: • Undeclared Consumers: Failure to control access to model outputs can lead to privacy breaches where sensitive data is exposed to unauthorized parties. • Glue Code: Poorly written integration code may fail to protect data, exposing it to potential leaks or unauthorized access. 5.2.5. Adversarial Attack Resilience This concern is significant, especially when AI systems are not designed or hardened against adversarial attacks, where input is intentionally manipulated to trick the system into making incorrect or harmful decisions. Attackers may subtly alter input data (such as images or text) in ways that are imperceptible to humans, but cause AI to make erroneous predictions (Dai et al., 2021). For instance, an adversarial attack on an autonomous vehicle’s AI could involve subtly altering road signs to cause the vehicle to misinterpret a stop sign as a speed limit sign, leading to unsafe driving behaviors (Girdhar et al., 2023). Related AITDs: • Algorithmic Inclination/Human Bias: AI systems that rely too heavily on specific algorithms may be vulnerable to adversarial attacks that exploit known weaknesses in those algorithms. • Correction Cascades (C): Complex dependencies between models may create opportunities for adversarial manipulation, where altering input to one model can cascade through the system, resulting in unexpected and unsafe outcomes. 5.2.6. Fail-Safe Mechanisms Fail-safe mechanisms are critical for ensuring that AI systems can safely handle unexpected errors, failures, or external threats. In safety-critical environments such as industrial robotics or autonomous driving, the lack of fail-safe mechanisms could result in hazardous conditions when an error occurs, as the system may continue to operate in an unsafe manner instead of shutting down or reverting to a safe state (Farrell et al., 2021). Related AITDs: • Dead Experimental Code Paths/Prototype Debt: Experimental or prototype systems often lack robust fail-safe mechanisms, leading to unpredictable behavior when they encounter unexpected situations in production environments. • Boundary Erosion: As clear separations between components weaken, fail-safe mechanisms may fail to isolate issues, allowing errors in one component to propagate through the system. 5.2.7. Model Interpretability and Transparency There is concern when AI models are too opaque to allow users to understand how decisions are made, particularly in complex, black-box models like deep neural networks (Nallakaruppan et al., 2024; Hoang and Phan, 2024). Without model interpretability, it becomes difficult to detect biases, vulnerabilities, or potential failures, especially in safety-critical applications (Hoang and Phan, 2024). For example, in AI-driven medical diagnosis, a lack of transparency in how AI arrives at its recommendations could prevent healthcare professionals from identifying flaws in the model, potentially leading to incorrect treatments or adverse outcomes (Mohammed, 2024; Kumar et al., 2024). Related AITDs: • Jumbled Model Architecture: Disorganized model architectures can make it difficult to interpret or understand the behavior of the system, increasing the risk of undetected vulnerabilities or unsafe decisions. • Overly Simplified Metrics: AI systems optimized for abstract performance metrics may lack transparency, making it harder to trace decisions and assess model safety in critical situations. 5.2.8. Real-Time Security Monitoring AI systems often operate in dynamic environments where real-time threats and security risks must be continuously monitored (Chirra, 2020). An uncertain consequence can arise as a result of insufficient real-time security monitoring and incident response infrastructure in place. Without robust monitoring, security breaches or failures can go unnoticed for long periods, allowing attackers to exploit vulnerabilities or manipulate system behavior undetected (Chirra, 2020). For instance, in AI-controlled energy grids, the absence of real-time security monitoring could allow a cyberattack to disrupt operations without being detected until it is too late. Related AITDs: • Hidden Feedback Loops: Without proper real-time monitoring, feedback loops may go unnoticed, leading to system degradation or vulnerabilities that can be exploited over time. • Dead Experimental Code Paths: Leftover experimental code that is not actively monitored in production can introduce vulnerabilities that are difficult to detect without proper real-time oversight. 5.2.9. Access Control and Data Protection A lack of sufficient controls over who can access sensitive data or model outputs in AI systems is a significant concern in AI systems (Tibebu, 2024). If access controls are weak or nonexistent, unauthorized users could gain access to data that should be protected, such as proprietary model outputs or sensitive customer data. This increases the risk of data breaches and compliance violations, particularly in highly regulated industries such as finance (Hernández et al., 2019) or healthcare (de Kok et al., 2023). Furthermore, in safety-critical systems, unauthorized access to model outputs could lead to unsafe actions if the model predictions are used inappropriately (Ruland and Sassmannshausen, 2018). Related AITDs: • Undeclared Consumers: As this AITD involves lack of control over who accesses model outputs, it directly contributes to data protection issues, making it difficult to secure sensitive information. • Deep God File: A large, monolithic file containing multiple components makes it harder to enforce access controls effectively, increasing the risk of data leaks. 5.2.10. Complexity-Induced Vulnerabilities AI systems with complex architectures or pipelines often hide vulnerabilities that are difficult to detect and address (Sculley et al., 2015). This occurs when the system’s complexity makes it challenging to perform thorough security assessments or safety analyses. For example, in systems where multiple models or components are interdependent, it may be difficult to track how data flows through the system or identify weak points where security measures are inadequate. This complexity can lead to vulnerabilities that attackers can exploit or cause system failures in safety-critical applications. Related AITDs: • Pipeline Jungle: The complexity of AI pipelines increases the likelihood of hidden vulnerabilities, making it harder to secure the system and identify potential weaknesses. • Entanglement: Tightly coupled components make it difficult to manage security risks, as vulnerabilities in one part of the system can affect other interconnected components. 5.2.11. Dependency-Related Vulnerabilities AI systems often rely on external libraries, tools, and frameworks to function. Whenever outdated or unused dependencies are not properly managed, it leads to creating vulnerabilities that can be exploited by attackers (Chaudhary et al., 2018). Unused dependencies that remain in the system without regular updates can serve as backdoor for malicious activity (Costal et al., 2024). In safety-critical applications such as autonomous driving or healthcare, dependency-related vulnerabilities can lead to unpredictable system behavior or integration issues, potentially causing unsafe outcomes or system failures. Related AITDs: • Dispensable Dependency: Unnecessary dependencies in the system introduce security vulnerabilities, as they are often not updated or patched regularly. • Compatibility Debt: Dependency on outdated or insecure libraries can result in vulnerabilities that compromise system security and safety. 5.2.12. Ethical and Bias-Induced Safety and Security AI systems that are developed without adequate consideration for ethical principles, such as fairness, accountability, and transparency, accumulate ethical debt (Petrozzino, 2021) can lead to biased decisions that result in unsafe or unethical outcomes (Roselli et al., 2019). In safety-critical environments, such as healthcare, biased AI models could deny certain demographic groups access to critical treatments, resulting in harm (Sujan, 2023). Similarly, from a security perspective, attackers could exploit biased algorithms to influence the system’s behavior in ways that compromise both safety and security (Chaudhary et al., 2018). Related AITDs: • Ethics Debt: This is directly related, as biases in AI models can lead to unethical decisions, which may also introduce security risks if attackers exploit those biases. • Algorithmic Inclination/Human Bias: Over-reliance on specific algorithms may introduce systemic bias, leading to unsafe decisions in critical applications and increasing susceptibility to exploitation. These security concerns are deeply interwoven with technical debt manifestations across AI-enabled systems. Figure 5 visually consolidates these relationships, highlighting their interconnections, providing a graphical representation of how each AITD contributes to broader risk categories. RQ2.2 – Security Concerns in AI Systems The identified AITDs, such as Undeclared Consumers, Data Debt, Algorithmic Bias, and Ethical Debt, significantly impact the security of AI-based systems. These debts can lead to vulnerabilities, including unauthorized access, data breaches, and biased outcomes. Critical risks identified include: • Authentication and Authorization: Weak controls can lead to unauthorized access to sensitive AI model outputs. • Data Integrity: Poor validation processes make systems vulnerable to manipulated or inaccurate data. • Adversarial Attacks: Systems without resilience mechanisms are prone to exploitation by adversarial inputs, jeopardizing both security and safety. • Ethical and Bias-Induced: Failing to address fairness and accountability in AI systems can lead to harmful or unethical outcomes. Impact on High-Stakes Domains: The safety-critical nature of sectors like healthcare, finance, and autonomous systems magnifies these concerns, requiring robust mitigation strategies. Table 6. Mapping Security Concerns to Related AI Technical Debts (AITDs) S/N Security Concern Related AITDs Explanation 1 Authentication and Authorization Undeclared Consumers, Configuration Debt, Glue Code Lack of access control and misconfigurations allow unauthorized access to model outputs and parameters. 2 Data Integrity and Validation Data Debt (Unstable Dependencies), Hidden Feedback Loops, Correction Cascades Inadequate validation of input data or changes in source data can compromise prediction accuracy and trustworthiness. 3 Security Patch and Update Dispensable Dependency, Scattered Use of ML Libraries, Compatibility Debt, Multiple Language Smells Outdated, scattered, or heterogeneous codebases increase difficulty in applying consistent security updates. 4 Data Privacy and Confidentiality Undeclared Consumers, Glue Code, Deep God File Poor control of model outputs and monolithic code structures may expose sensitive data. 5 Adversarial Attack Resilience Algorithmic Inclination / Human Bias, Correction Cascades, Entanglement Lack of algorithm diversity and complex model interdependencies increase susceptibility to adversarial manipulation. 6 Fail-Safe Mechanisms Prototype Debt, Boundary Erosion, Jumbled Model Architecture Weak architectural modularity and experimental code can prevent safe fallback during system failure. 7 Model Interpretability and Transparency Jumbled Model Architecture, Overly Simplified Metrics Opaque model design and inappropriate evaluation metrics hinder understanding and safety validation. 8 Real-Time Security Monitoring Hidden Feedback Loops, Prototype Debt Insufficient oversight allows critical issues (e.g., feedback drift) to go unnoticed in production.. 9 Access Control and Data Protection Undeclared Consumers, Glue Code, Deep God File Lack of modularity and loosely managed outputs can expose the system to unauthorized use or data leakage. 10 Complexity-Induced Vulnerabilities Pipeline Jungle, Entanglement, Configuration Debt, Multiple Language Smells Interdependent modules and use of multiple languages increase brittleness and vulnerability to subtle configuration flaws. 11 Dependency-Related Vulnerabilities Dispensable Dependency, Compatibility Debt Poor management of software/library dependencies increases exposure to known exploits. 12 Ethical and Bias-Induced Safety Ethical Debt, Algorithmic Inclination / Bias, Overly Simplified Metrics Neglecting fairness, transparency, and appropriate evaluation criteria can lead to unsafe, discriminatory outcomes. Figure 5. Bipartite mapping between security concerns and AI Technical Debts (AITDs), showing how identified AITDs contribute to or exacerbate specific security risks in AI-enabled systems. Green circles represent security concerns, while blue circles represent AITDs. 6. Safety and Security guidelines for mitigating the identified AITDs (RQ3) 6.1. Safety Guidelines To mitigate the impact of AI Technical Debts (AITDs) on system safety, this study identifies a set of strategic guidelines derived from established AI safety research and best practices. These guidelines address core safety concerns, including robustness, explainability, fairness, transparency, and operational assurance. Each guideline is explicitly linked to specific AITDs that introduce safety risks, as identified in Section 4. Our contribution lies in systematically consolidating, synthesizing, and mapping these established guidelines to the concrete forms of AITD uncovered in this review. Table 7. Mapping of Safety Guidelines to Related AI Technical Debts (AITDs) S/N Safety Guideline Related AITDs Explanation 1 Explainable AI (XAI) Jumbled Model Architecture, Overly Simplified Metrics, Documentation Debt Improves model transparency and enables users to understand and justify AI decisions, enhancing trust and accountability. 2 Fairness Assessment and Bias Mitigation Algorithmic Inclination / Human Bias, Ethical Debt, Overly Simplified Metrics Detects and corrects biases in data and model behavior to ensure equitable and non-discriminatory AI outcomes. 3 Adversarial Training Algorithmic Inclination / Human Bias, Correction Cascades, Entanglement Increases model robustness against malicious inputs and reduces vulnerability propagation through tightly coupled components. 4 OOD Detection Pipeline Jungle, Prototype Debt, Overly Simplified Metrics Prevents unsafe decisions on unfamiliar data by identifying distribution shifts and handling anomalies effectively. 5 Formal Verification Defect Debt, Test Debt, Jumbled Model Architecture Ensures correctness of AI systems via mathematical proofs, addressing unverified bugs and untestable complex models. 6 Domain Adaptation and Transfer Learning Data Debt, Pipeline Jungle, Dead Experimental Code Paths Enhances model generalization across diverse contexts by adapting to new domains and discarding obsolete or fragile components. 7 Black Box Auditing and Logging Documentation Debt, Versioning Debt Facilitates traceability and compliance through systematic logging and monitoring of AI decision-making processes. 8 Secure and Federated Learning Configuration Debt, Dispensable Dependency, Compatibility Debt Preserves data privacy and system integrity by securely distributing training without centralizing sensitive information. 6.1.1. Explainable AI (XAI) Explainable AI encompasses methods and techniques that make AI system decisions understandable to humans. This includes model-agnostic tools like Local Interpretable Model-agnostic Explanations (LIME) and SHapley Additive exPlanations (SHAP), inherently interpretable models like decision trees, and visualizations like saliency maps. By enhancing transparency, XAI helps end-users, developers, and regulators to audit and trust AI outputs (Dağlarli20; Xu et al., 2019; Sheh, 2021; Albahri et al., 2023; Adadi and Berrada, 2018; Krajna et al., 2022; Chamola et al., 2023). Related AITDs: Jumbled Model Architecture obscures the internal structure and decision pathways of models, complicating explanation. Overly Simplified Metrics do not convey interpretable performance indicators. Documentation Debt limits external understanding of design choices and model logic. 6.1.2. Fairness Assessment and Bias Mitigation This guideline ensures that AI systems treat individuals and groups equitably. Techniques include fairness-aware training algorithms (Shi et al., 2023), pre-processing data balancing (Parmar et al., 2023), and post-hoc fairness evaluations using metrics like demographic parity or equal opportunity (Hardt et al., 2016). The goal is to detect and reduce both data and algorithmic biases (Ferrara, 2023; Hardt et al., 2016). Related AITDs: Algorithmic Inclination / Human Bias encodes unchecked human biases into model logic. Ethical Debt stems from ignoring fairness and social implications during development. Overly Simplified Metrics may fail to capture nuanced biases in model outputs. 6.1.3. Adversarial Training Adversarial training improves robustness by exposing models to adversarial examples during training. This enables the system to learn resilience against malicious perturbations. It is crucial for security-critical applications where robustness is a primary safety concern (Ziegler et al., 2022; Zhao et al., 2022). Related AITDs: Algorithmic Inclination / Human Bias may prioritize performance over resilience. Correction Cascades allow adversarial perturbations in one module to affect downstream outputs. Entanglement creates interdependencies that amplify security vulnerabilities. 6.1.4. Out-of-Distribution (OOD) Detection OOD detection allows AI systems to recognize when they are presented with inputs that significantly deviate from their training data. Strategies include confidence scoring, uncertainty modeling, and Bayesian inference. By deferring or flagging these cases, the system avoids unsafe decisions (Kamoi and Kobayashi, 2020; Haider et al., 2023). Related AITDs: Pipeline Jungle complicates systematic integration of OOD detectors. Prototype Debt results in fragile components not validated for distributional robustness. Overly Simplified Metrics often miss edge-case or anomaly behavior. 6.1.5. Formal Verification Formal verification applies mathematical proofs and logical reasoning to ensure that AI systems meet predefined specifications. This is particularly useful for verifying safety properties, such as invariants and boundary conditions in control systems (Meng et al., 2022; Corsi et al., 2021). Related AITDs: Defect Debt includes unaddressed errors that may invalidate verification results. Test Debt results in insufficient test coverage for verifying formal properties. Jumbled Model Architecture complicates reasoning due to its opacity and lack of modularity. 6.1.6. Domain Adaptation and Transfer Learning These approaches allow models trained on one domain to adapt effectively to another. They involve fine-tuning or augmenting training data to generalize across varying distributions (Zhuang et al., 2021; Kamath et al., 2019). These are essential for deploying models in dynamic or diverse environments. Related AITDs: Data Debt limits generalization due to insufficient diversity. Pipeline Jungle obstructs the integration of domain adaptation pipelines. Dead Experimental Code Paths leave legacy components that are poorly adapted to new domains. 6.1.7. Black Box Auditing and Logging This involves systematically recording the inputs, outputs, and internal states of AI systems to enable retrospective analysis (Adadi and Berrada, 2018). Logging enables debugging, monitoring, and compliance with regulatory standards. It is essential for safety transparency (Chennam et al., 2023). Related AITDs: Documentation Debt restricts the reproducibility of logs and audit trails. Versioning Debt impairs traceability across system updates. 6.1.8. Secure and Federated Learning These are privacy-preserving learning paradigms where models are trained collaboratively without sharing raw data (Zhang et al., 2022b). Federated learning improves security and trust in multi-agent environments. Encryption and differential privacy techniques are often employed (Shejwalkar et al., 2022). Related AITDs: Configuration Debt creates exposure due to insecure settings. Dispensable Dependency brings in third-party components that may not be vetted for privacy. Compatibility Debt hinders integration of federated architectures into existing systems. These guidelines provide a multidimensional defense-in-depth strategy that enhances the safety of AI-based systems while also facilitating sustainable debt management. As summarized in Table 7, each safety guideline is explicitly linked to one or more AI Technical Debts (AITDs), highlighting the targeted impact of these practices. Additionally, Figure 6 provides a visual mapping that illustrates how each guideline contributes to the mitigation of specific AITDs, supporting a comprehensive safety assurance strategy. RQ3.1: Safety Guidelines for Mitigating AITDs To enhance the safety of AI-based systems, the following guidelines are recommended for addressing AI Technical Debts (AITDs): • Explainable AI (XAI): Enhances system transparency, mitigating debts related to interpretability and trust. • Robustness Testing: Detects failure points under adversarial or noisy conditions. • Continuous Monitoring: Ensures early detection of drift, decay, or bias during deployment. • Ethical and Fairness Audits: Mitigates bias, ethical, and societal debts through regular assessments. • Modular and Versioned Pipelines: Reduces architecture and documentation debt by enabling traceability and maintainability. • OOD Detection Mechanisms: Handles novel inputs and prevents unsafe behavior from unrecognized data. Adopting these guidelines supports resilient, fair, and transparent AI systems in safety-critical domains. Figure 6. Mapping of Safety Guidelines to Related AI Technical Debts (AITDs). This figure visualizes the relationships between key AI safety guidelines and the specific technical debts they help mitigate. Each guideline (green nodes) is connected to one or more AITDs (blue nodes) that pose risks to safety attributes such as explainability, robustness, fairness, and security. 6.2. Security Guidelines This section presents a comprehensive set of security guidelines designed to effectively mitigate the AI Technical Debts (AITDs) identified in this review. Our contribution lies in systematically consolidating, synthesizing, and mapping established guidelines to the specific forms of AITD uncovered in this study. The selected guidelines reflect the most relevant and impactful practices for addressing the root causes of AITDs, spanning critical areas such as secure data handling, adversarial resilience, configuration discipline, system monitoring, dependency governance, and organizational preparedness. In the following subsections, each guideline is presented with: (i) a concise definition, (i) a practical example illustrating its application in real-world AI deployments, and (i) an explanation of the specific AITDs it helps mitigate. To enhance traceability and support evidence-based mitigation planning, Table 8 provides a structured mapping between the security guidelines and the AITDs they address, while Figure 7 visually illustrates their interconnections. Together, these artifacts enable practitioners and researchers to understand how targeted security practices can reduce the accumulation of technical debt across the AI lifecycle and strengthen the robustness, trustworthiness, and sustainability of AI-enabled systems. Figure 7. Mapping of Security Guidelines to Related AI Technical Debts (AITDs). This figure visualizes the relationships between key AI security guidelines and the specific technical debts they help mitigate. Each guideline (green node) is connected to one or more AITDs (blue nodes) that introduce vulnerabilities or risks to system security and reliability. The connections illustrate how implementing these guidelines can address multiple forms of AI Technical Debt—such as data, model, and configuration-related debts—thereby enhancing the overall resilience and trustworthiness of AI-enabled systems. 6.2.1. Configuration Management Robust configuration management ensures that all AI components—models, pipelines, hyperparameters, dependencies, and deployment environments—are consistently versioned, controlled, and auditable throughout the lifecycle (ISO/IEC 27002, 2022; Simonetta and Paoletti, 2024; Soundararajan, ). In AI-enabled systems, where small changes in data sources, hyperparameters, or library versions can significantly alter model behavior, disciplined configuration practices are essential to maintain reproducibility, traceability, and secure rollback in case of failures or regressions. Centralizing configuration artifacts (e.g., as code, in registries, or configuration databases) also supports governance, compliance, and cross-team collaboration in complex MLOps settings. • Example: An MLOps pipeline stores configuration snapshots (hyperparameters, model versions, data schemas) in a managed registry before every retraining cycle, ensuring reproducibility. • Related AITDs: Configuration Debt (uncontrolled parameter drift), Versioning Debt (untracked changes across updates), Pipeline Jungle (inconsistent configurations across stages), Compatibility Debt (misaligned module configurations). 6.2.2. Encryption and Secure Data Storage Encryption and secure data storage are foundational security practices for AI systems, ensuring that all sensitive data—during collection, preprocessing, model training, evaluation, and deployment—is protected from unauthorized access, tampering, or interception. This guideline encompasses two complementary aspects: encryption of data at rest and in transit and the secure storage of training, validation, and retraining datasets, especially those containing personally identifiable or confidential information. Compliance-focused AI systems must implement industry-grade cryptographic standards (e.g., AES-256 for stored data, TLS 1.2+ for data in transit), robust key-management procedures, and controlled access to secure storage environments. These safeguards align with regulatory requirements such as GDPR and ISO 27002 by ensuring confidentiality, integrity, and long-term protection of sensitive data throughout the AI lifecycle (Shahriar et al., 2023; Hamon et al., 2024; Schneider et al., 2024; Sujatha et al., 2023; Hjerppe et al., 2019). • Example: In a healthcare diagnostic AI system, patient records uploaded for model inference are transmitted over encrypted channels (TLS), while historical datasets used for retraining are stored in encrypted repositories (AES-256) with strict access controls. This prevents unauthorized access, accidental exposure, or inference-time data leakage. • Related AITDs: This guideline mitigates several data- and configuration-related debts, including: Data Debt / Unstable Data Dependencies — securing data flows reduces exposure to compromised or inconsistent data sources. Configuration Debt — enforcing proper cryptographic settings, key rotation, and secure storage parameters prevents misconfigurations that weaken system security. Documentation Debt — requiring well-documented encryption policies and data-handling procedures enhances traceability and audit readiness. Versioning Debt — secure key management and versioning of encrypted assets prevent stale or misaligned cryptographic states. 6.2.3. Continuous Behavioral & Performance Monitoring This involves the systematic, real-time observation of AI system behavior to ensure that models operate within expected ethical, functional, and performance boundaries. This unified guideline integrates two complementary monitoring practices: (i) continuous behavioral monitoring, which evaluates adherence to ethical, fairness, and security policies; and (i) performance monitoring, which tracks accuracy, drift, degradation, and operational reliability over time. Together, these monitoring practices enable early detection of anomalies, misconfigurations, emerging biases, model drift, or hidden system interactions that may compromise system integrity or safety (Lu et al., 2024; Hamon et al., 2024; Bogner et al., 2021; ISO/IEC 27002, 2022; Feng et al., 2022; Guo et al., 2025). Continuous monitoring is especially critical for AI systems deployed in dynamic or high-stakes environments where data distributions evolve and decision quality must remain consistently reliable. • Example: In a real-time fraud detection system, continuous monitoring evaluates whether model predictions remain fair and unbiased across customer groups, while performance monitoring checks for drops in detection accuracy that may indicate emerging fraud patterns or model drift. Alerts are triggered when behavioral or performance deviations exceed thresholds, prompting retraining, recalibration, or human review. • Related AITDs: This guideline mitigates multiple AITDs, including: Ethical Debt — by continuously checking for fairness, bias, or ethical violations in model outputs; Configuration Debt — by detecting misconfigurations or runtime deviations that affect behavior or safety; Unstable Data Dependencies (Data Debt) — by identifying drift or changes in upstream data that degrade model performance; Hidden Feedback Loops — by surfacing recurrent or cyclic interactions that cause unexpected model behaviors; and Performance or Design Debt — by detecting accuracy drops, latency spikes, or reliability issues early in the AI lifecycle. 6.2.4. Data Validation This guideline requires that all input data feeding AI pipelines undergo strict validation checks for correctness, format consistency, completeness, and authenticity (Sheeba et al., 2025; Hamon et al., 2024; Ranjitsingh and Rao, 2025). Strong validation reduces the risk of corrupted, noisy, or malicious data introducing instability. • Example: Before retraining a recommendation system, automated validators check for missing fields, incorrect data types, and out-of-distribution samples, preventing corrupted data from degrading model accuracy. • Related AITDs: Data Debt (unvetted data introduces drift and errors), Pipeline Jungle (complex pipelines lacking validation checkpoints), Correction Cascades (invalid data propagating errors downstream). 6.2.5. Secure Coding Practices This guideline emphasizes applying standard secure-software engineering principles—such as static analysis, dependency scanning, code reviews, and avoiding hard-coded secrets—to AI pipelines and model-serving infrastructure (ISO/IEC 27002, 2022; Simonetta and Paoletti, 2024; Loncar et al., 2024). • Example: During deployment, static code analysis flags insecure API endpoints and outdated dependencies used in the inference server, prompting corrective refactoring. • Related AITDs: Glue Code Debt (quick fixes introducing vulnerabilities), Duplicate Model Code (security flaws replicated across modules), Unwanted Debugging Code (leftover logs leaking sensitive info), Defect Debt (known issues not addressed). 6.2.6. Incident Response for AI Systems Incident response involves establishing structured procedures to detect, investigate, contain, and recover from security incidents affecting AI workflows (Jawhar et al., 2024; Matsuda et al., 2019; Hamon et al., 2024; Jones et al., 2025). This includes AI-specific events such as adversarial data poisoning, unauthorized model access, or misconfiguration-induced failures. • Example: In a fraud-detection AI system, if an attacker injects adversarial inputs that manipulate prediction thresholds, an incident response workflow automatically detects anomalies, isolates compromised components, and triggers human review. • Related AITDs: Hidden Feedback Loops (undetected abnormal system behavior), Unstable Data Dependencies (data poisoning events), Configuration Debt (incidents caused by misconfigurations). 6.2.7. Threat Intelligence It involves the continuous collection, analysis, and application of information about emerging vulnerabilities, attack vectors, system misuses, and adversarial behaviors relevant to AI-enabled systems. In the context of AI security, threat intelligence extends beyond traditional cybersecurity practices by incorporating AI-specific risks such as data poisoning, model evasion, adversarial perturbations, prompt injection, and manipulation of training or inference pipelines. By proactively monitoring threat landscapes—including AI model repositories, dependency ecosystems, upstream data sources, and adversarial research communities—organizations can anticipate misconfigurations, model weaknesses, and infrastructural exposures that could manifest as AI Technical Debt (AITD). Integrating actionable threat intelligence into AI development pipelines enhances preparedness, supports risk-informed decision-making, and ensures that AI components evolve in alignment with emerging security requirements (ISO/IEC 27002, 2022; Camilo et al., 2024; Sarker, 2024). • Example: A financial-services AI platform incorporates threat intelligence feeds that track newly discovered vulnerabilities in ML libraries (e.g., TensorFlow, PyTorch), recent data poisoning campaigns detected in public datasets, and adversarial evasion techniques emerging from academic research. When a critical vulnerability is reported in a dependency, the system automatically flags relevant components, triggering audits, dependency upgrades, and revalidation of affected models. • Related AITDs: Threat Intelligence mitigates a range of debt types, including: Dispensable Dependency — by detecting obsolete or vulnerable dependencies that should be removed or replaced; Scattered Use of ML Libraries (SML) — by identifying fragmented or inconsistent library usage that increases exposure to security flaws; Configuration Debt — by uncovering unsafe or outdated configuration settings tied to evolving threat patterns; Data Debt / Unstable Data Dependencies — by detecting compromised or manipulated upstream data sources; Boundary Erosion and Compatibility Debt — by highlighting insecure integrations or outdated interfaces that may become attack vectors; Documentation and Versioning Debt — by reinforcing the need for traceability of updates, patches, and threat responses across AI lifecycle artifacts. 6.2.8. Red Teaming and AI Alignment (RLHF) Red teaming systematically tests AI systems using adversarial, stress-testing, or probing techniques to expose vulnerabilities. RLHF (Reinforcement Learning from Human Feedback) aligns model behavior with safe and acceptable outcomes, reducing misuse and unintended behaviors (Spelda and Stritecky, 2025; Ouyang et al., 2022; Bai et al., 2022; Walter et al., 2024; Feffer et al., 2024). • Example: Before deployment, a large language model undergoes red-teaming sessions where experts test harmful prompts, manipulations, and jailbreak attempts. RLHF is then used to retrain the model and correct unsafe behaviors. • Related AITDs: Ethical Debt (lack of alignment with societal norms), Algorithmic Inclination / Bias (unchecked bias requiring feedback alignment), Overly Simplified Metrics (models optimized with insufficient safety metrics). 6.2.9. Data Leak Prevention (DLP) Data Leak Prevention involves monitoring, filtering, and controlling the flow of sensitive data inside AI pipelines to prevent accidental exposure or exfiltration (ISO/IEC 27002, 2022; Simonetta and Paoletti, 2024; Jaeyalakshmi et al., 2023; Alneyadi et al., 2016). • Example: A model-training cluster blocks outbound file transfers containing sensitive patterns (e.g., credit card numbers), preventing unintended dataset exposure. • Related AITDs: Data Debt (poorly governed sensitive data), Documentation Debt (missing data-handling guidelines), Dispensable Dependency (unnecessary third-party components leaking data), Undeclared Consumers (unmonitored data usage). 6.2.10. Data Masking & Information Deletion Data masking anonymizes sensitive data used in training or inference. Information deletion ensures obsolete or risky data is securely removed, minimizing retention-related risk (ISO/IEC 27002, 2022; Simonetta and Paoletti, 2024; Gaddam, 2024; Bilakanti, ). • Example: An AI system masks personally identifiable information (PII) before performing analytics and automatically deletes expired training logs after a retention window. • Related AITDs: Data Debt (unmasked or outdated data remains in the pipeline), Unstable Data Dependencies (stale data causing unexpected behavior), Process/Infrastructure Debt (missing secure-deletion procedures), Documentation Debt (unclear retention policies). 6.2.11. Controlled AI Output Consumers This guideline ensures that outputs produced by AI models—predictions, scores, embeddings, or generated content—are only accessed by explicitly authorized systems, services, or users (Bogner et al., 2021; Recupito et al., 2024a; Martínez-Fernández et al., 2022). Enforcing strict consumption policies prevents downstream components from silently depending on AI outputs, which can introduce hidden couplings, regulatory violations, and unmonitored propagation of errors or sensitive information. Controlled output consumption also supports auditability by requiring explicit logging, authentication, and authorization checks whenever AI outputs are requested or consumed. This reduces the risk of unintended reuse, shadow pipelines, or unauthorized integrations that frequently lead to systemic vulnerabilities in AI-driven architectures. • Example: In an AI-driven cybersecurity monitoring platform, only vetted detection modules and SOC (Security Operations Center) tools can access threat-classification outputs through authenticated API calls. Unauthorized services attempting to query the AI’s outputs are automatically blocked and logged, preventing silent dependencies or accidental leakage of sensitive threat intelligence. • Related AITDs: Undeclared Consumers — prevents hidden or unauthorized modules from silently consuming AI outputs; Glue Code Debt — reduces ad-hoc integrations that bypass approved consumption pathways; Documentation Debt — requires clear documentation of permitted consumers and access rules. 6.2.12. Model Watermarking (Model Integrity Controls) Model watermarking embeds identifiers or verification signatures into AI models to detect unauthorized replication, tampering, or misuse (Pooyandeh et al., 2022; Banerjee et al., 2025; Mekhfioui et al., 2025; Narula et al., 2025). This strengthens model integrity and provides forensic traceability. • Example: A commercial NLP model embeds a proprietary watermark into its weight matrices. If leaked or cloned, developers can verify fingerprints to identify unauthorized deployments. • Related AITDs: Undeclared Consumers (untracked or unauthorized model usage), Versioning Debt (lack of traceability enabling misuse), Documentation Debt (missing model-ownership records), Glue Code Debt (uncontrolled integrations facilitating illicit replication). 6.2.13. AI System Software Bill of Materials (AI-SBOM) An AI System Software Bill of Materials (AI-SBOM) is a machine-readable inventory that lists all datasets, model versions, libraries, configurations, and dependencies used across the AI lifecycle (Rajbahadur et al., 2025; Xia, 2025; Sood and Zeadally, 2025). It provides end-to-end traceability of how models were trained, what data they relied on, and which components they depend on, thereby strengthening transparency, auditability, and supply-chain security. AI-SBOMs also support rapid vulnerability assessment when flaws or dataset integrity issues arise (Xia et al., 2023). • Example: In a healthcare AI system, an AI-SBOM records training datasets, preprocessing steps, model checkpoints, and library versions, enabling auditors to verify compliance with GDPR and medical-device regulations. • Related AITDs: Data Debt / Unstable Data Dependencies — through clear provenance tracking. Dispensable Dependency — by identifying outdated or unnecessary components. Versioning Debt — by documenting model and dependency histories. Documentation Debt — by formalizing system lineage and configuration details. 6.2.14. Modular & Reusable AI Components This guideline emphasizes designing AI systems using modular, self-contained components with clearly defined interfaces and separation of concerns (Schneider et al., 2024; Martínez-Fernández2022; Riggio et al., 2021; Celepija et al., 2025). Modular architectures minimize unnecessary coupling between data pipelines, model logic, and service layers, making AI systems easier to test, secure, maintain, and evolve. Reusable components also promote architectural consistency across projects, reduce duplication, and lower the risk of integrating ad-hoc patches or experimental code that later becomes technical debt. • Example: In an AI-based fraud detection platform, independently developed modules for feature extraction, model inference, and case scoring can be reused across credit card fraud, loan fraud, and identity-theft scenarios. This avoids rewriting redundant logic and enables secure updates without impacting unrelated components. • Related AITDs: Glue Code Debt — modular interfaces reduce the need for brittle integration scripts. Deep God File — decomposition prevents monolithic files accumulating multiple responsibilities. Design Debt — modularity enforces cleaner architectural boundaries. Duplicate Model Code — reusable components reduce redundant implementations across the system. 6.2.15. Standardized & Interoperable Data Formats This guideline promotes the use of consistent, well-defined, and interoperable data formats across all stages of the AI pipeline (Bogner et al., 2021; Gujar, 2025; Zhi et al., 2024; Naeem et al., 2021). Standardization minimizes the need for ad-hoc data conversions and reduces the likelihood of mismatches between feature schemas, model inputs, and downstream services. By enforcing shared data conventions—such as unified schemas, typed data structures, consistent encodings, and versioned dataset specifications—organizations can prevent integration failures, enhance security by reducing transformation-related vulnerabilities, and improve long-term maintainability of AI workflows. • Example: In a smart city AI platform aggregating data from traffic sensors, public transit feeds, and environmental monitors, enforcing interoperable formats (e.g., standardized timestamps, unified geospatial encodings, consistent JSON schemas) ensures that downstream prediction models can reliably process data without error-prone conversion scripts. • Related AITDs: Glue Code Debt — reduces the need for excessive data wrangling or conversion scripts used to bridge incompatible formats; Unstable Data Dependencies (Data Debt) — ensures predictable, consistent data flows across heterogeneous systems; Compatibility Debt — avoids failures originating from mismatched data structures between models, services, or pipeline components. 6.2.16. API-Governed AI Access Control This guideline promotes accessing AI models and components exclusively through well-governed, authenticated, and rate-limited APIs rather than distributing models for local execution (Siriwardena, 2019; Paidy and Chaganti, 2024; Lu et al., 2024; Hamon et al., 2024). Centralizing access through APIs strengthens security by enforcing fine-grained permissions, monitoring usage patterns, applying request validation, and preventing unauthorized or uncontrolled consumption of AI outputs. It also reduces the attack surface by avoiding model proliferation across uncontrolled environments, enabling organizations to maintain better visibility, governance, and lifecycle control over deployed AI capabilities. In addition, API-mediated access supports compliance and auditability, since all interactions with the AI system can be logged, attributed, and reviewed, ensuring that AI predictions and model updates remain traceable and accountable. • Example: An AI-based weather prediction model is deployed behind a secure API gateway. External partners in agriculture, aviation, and logistics can query predictions through authenticated API calls, without receiving direct access to model weights or internal logic. This prevents model theft, unauthorized reuse, and uncontrolled distribution, while enabling centralized monitoring and permission enforcement. • Related AITDs: Undeclared Consumers — by ensuring AI outputs are accessed only by authorized systems and recorded in access logs. Dispensable Dependency — by reducing the need to embed or replicate models locally, avoiding unnecessary third-party integrations that create security and maintenance burdens. Glue Code Debt — by minimizing ad-hoc local integrations and promoting standardized, well-defined API interfaces. Versioning Debt — by enabling centralized version control of models and ensuring clients always access the correct model version through the API. 6.2.17. Adequate AI Resource & Continuity Management This focuses on ensuring that AI systems are provisioned with adequate computational resources—such as CPU/GPU capacity, memory, storage, and network bandwidth—while also maintaining organizational readiness for operational continuity in the event of outages, failures, or unexpected load surges. This guideline combines two complementary security and reliability practices: (i) resource sufficiency, which supports stable and timely AI model execution, and (i) ICT readiness for business continuity, which ensures fallback mechanisms, redundancy, and systematic recovery procedures are in place to maintain secure and safe AI operation even under adverse conditions (Bogner et al., 2021; Shneiderman, 2020; Shahriar et al., 2023; ISO/IEC 27002, 2022). • Example: In an autonomous driving system, ensuring sufficient GPU acceleration and memory bandwidth allows AI models to process multimodal sensor inputs (e.g., LiDAR, radar, cameras) with millisecond latency. Simultaneously, redundancy in compute nodes and a business continuity plan (e.g., automatic failover to a secondary control module) ensures that vehicle perception and decision-making continue uninterrupted during hardware faults or peak load conditions. • Related AITDs: This guideline mitigates several AITDs, including: Configuration Debt — by ensuring proper resource provisioning and avoiding misconfigured system parameters that lead to performance bottlenecks; and Process/Infrastructure Debt — by strengthening operational readiness, redundancy, and failover strategies. 6.2.18. AI Component Divergence Monitoring This guideline focuses on the continuous detection and analysis of behavioral discrepancies between redundant AI components or between an AI system’s expected outputs and its actual runtime behavior (Aagaard et al., 2024; Renard et al., 2024; Lu et al., 2024). Such divergence may signal a variety of underlying issues—including data quality problems, configuration drift, adversarial interference, model degradation, or faulty integration logic. By systematically monitoring for mismatches, organizations can identify anomalies at an early stage, initiate corrective action, and prevent security- or safety-critical consequences. Divergence monitoring is especially important in safety-critical and real-time AI systems, where silent failures or unnoticed drift can propagate downstream and trigger cascading errors. • Example: In an AI-driven industrial control system, if two redundant models controlling a robotic arm produce different movement instructions, this discrepancy would trigger an alert for human review. The system may automatically revert to a safe fallback mode or require operator approval before executing actions, thereby preventing accidental equipment damage or unsafe operations. • Related AITDs: Helps mitigate Unstable Data Dependencies by catching inconsistencies in upstream data or model behavior early, and Correction Cascades by preventing erroneous or misaligned outputs from propagating through interconnected components in the AI pipeline. 6.2.19. Multi-Model Consensus Decision Framework This guideline advocates deploying multiple AI models in parallel—each trained with different architectures, datasets, feature sets, or optimization strategies—to independently generate decisions that are then compared to derive a consensus (Lu et al., 2024; Schneider et al., 2024; Shahin et al., 2025; Gupta et al., 2025). By diversifying the decision-making process across multiple models, the system becomes inherently more fault-tolerant, reducing susceptibility to single-model failures, dataset biases, adversarial perturbations, or unexpected distribution shifts. Consensus-based decision mechanisms strengthen the robustness of AI-driven systems by identifying anomalous outputs early, isolating underperforming models, and enabling ensemble-level validation (Dang et al., 2022). Moreover, multi-model consensus supports adaptive system design, allowing continuous improvement by monitoring divergence patterns across models and informing when retraining, recalibration, or model retirement is necessary. • Example: In healthcare diagnostics, separate AI models—such as a CNN, a transformer-based classifier, and a segmentation-based model—can independently analyze radiographic images. If one model generates an output that deviates from the majority consensus, the system automatically flags the case for manual review, ensuring higher reliability and preventing diagnostic errors. • Related AITDs: Mitigates Correction Cascades by preventing downstream components from acting on a faulty single-model output. Addresses Hidden Feedback Loops by distributing decision-making across diverse model pathways, reducing the risk that self-reinforcing errors or biased predictions propagate through the pipeline without detection. 6.2.20. AI Redundancy & Failover Mechanisms This guideline emphasizes the deployment of multiple identical—or functionally equivalent—AI components operating in parallel to provide resilience, robustness, and continuity under failure conditions (Tutuncuoglu, 2024; Musunuru et al., 2025; Gupta, 2025). By maintaining redundant AI modules, the system can seamlessly transition to a backup component whenever the primary model encounters unexpected behavior, hardware degradation, adversarial interference, or operational faults. Failover mechanisms are essential in high-availability and safety-critical environments, where a single point of AI failure can produce cascading errors or compromise system safety. Redundancy reduces operational risk by ensuring that model predictions remain stable even when one instance becomes compromised, overloaded, or misconfigured. It also enables cross-validation between identical components, improving anomaly detection and strengthening reliability during runtime. Beyond resilience, redundancy supports secure and responsible AI deployment by enabling rolling updates, safe model rollbacks, and phased testing of new model versions. This ensures that experimental or updated AI components do not destabilize system behavior, as stable redundant units remain available to maintain uninterrupted operation. Collectively, redundancy and failover strategies enhance system robustness, protect against adversarial failure modes, and uphold service continuity. • Example: In a smart grid energy distribution system, multiple redundant AI controllers continuously monitor load patterns and grid conditions. If the primary controller is compromised—due to a cyberattack, hardware fault, or sensor malfunction—the secondary controller instantly assumes control, preventing blackouts, safety hazards, or cascading failures across the grid. • Related AITDs: Mitigates Algorithmic Inclination / Human Bias by reducing dependence on a single algorithmic decision-maker. Addresses Unstable Data Dependencies by ensuring that failures in one data pathway do not compromise the entire system, as redundant components can operate on parallel or validated data streams. 6.2.21. Use of Hardened Models and Defensive Training This guideline advocates for using models trained with defensive mechanisms such as adversarial training, robust optimization, or certified defenses to increase resilience against malicious perturbations (Hamon et al., 2024; Olutimehin et al., 2025; Samuel, 2025). • Example: An image classifier used in a biometric access system is trained with adversarially perturbed samples, increasing robustness against evasion attacks that slightly manipulate facial images. • Related AITDs: Algorithmic Inclination / Human Bias (models optimized only for accuracy, not robustness), Entanglement (high interdependencies amplifying vulnerabilities), Correction Cascades (unrobust models propagating errors), Design Debt (architectures not built for robust defense). 6.2.22. Input Sanitization (Defense Against Evasion Attacks) This involves applying filters, normalization techniques, and anomaly detection to remove adversarial perturbations or malicious payloads (Hamon et al., 2024; Barlas et al., 2022; Kiranbabu et al., 2025). This is critical for mitigating evasion attacks targeting model vulnerabilities. • Example: A vision-based authentication model normalizes pixel distributions and rejects suspiciously manipulated images before inference, reducing exposure to adversarial examples designed to bypass access controls. • Related AITDs (not sure - double check): Algorithmic Inclination / Human Bias (models not trained to handle edge cases), Entanglement (tight coupling amplifying adversarial effects), Correction Cascades (malicious inputs causing downstream failures), Defect Debt (unhandled edge cases left unresolved). 6.2.23. Ethical Black Box This is a comprehensive logging mechanism that captures AI system inputs, outputs, intermediate signals, model states, and the reasoning (where available) behind decisions (Lu et al., 2024; Schneider et al., 2024; Franzoni, 2023; Pedreschi et al., 2019). Inspired by aviation black boxes, this mechanism provides a continuous, tamper-evident record of the AI system’s behavior. Such detailed traceability is essential for post-incident analysis, forensic auditing, compliance verification, and diagnosing failures—particularly in high-stakes domains involving safety, fairness, or accountability (Bélisle-Pipon20231507). By enabling stakeholders to reconstruct decision pathways, the Ethical Black Box strengthens transparency and supports ethical AI governance. It also facilitates proactive oversight by making deviations from expected behavior detectable long before they propagate into harmful system outcomes. • Example: In an AI-driven financial system, an ethical black box records every loan-approval decision, including input features (e.g., credit score, income), model-inferred risk factors, confidence scores, and decision rationale. During audits or dispute resolution, this record allows regulators or internal teams to evaluate whether decisions were fair, explainable, and aligned with organizational and legal requirements. • Related AITDs: Mitigates Ethical Debt by providing the transparency and traceability needed to assess fairness, detect discrimination, and verify decision legitimacy. Addresses Entanglement by offering clear logs that disentangle complex interactions between system components. Mitigates Undeclared Consumers by recording which systems or entities accessed or consumed AI outputs, ensuring accountability and preventing unauthorized use. 6.2.24. Human–AI Control Mode Switching This guideline introduces a configurable mechanism that allows users or system operators to dynamically determine whether AI-generated outputs should be executed autonomously or treated as advisory suggestions requiring human confirmation before action (Lu et al., 2023b, 2022; Ge et al., 2024; Lu et al., 2023a). By enabling seamless switching between automated and human-in-the-loop modes, this guideline enhances operational transparency, prevents over-reliance on automated decisions, and ensures that critical tasks remain under appropriate levels of human oversight. Such control mechanisms are especially vital in high-stakes or safety-critical environments—such as transportation, healthcare, finance, and industrial automation—where fully autonomous operation may expose the system to unacceptable levels of risk or error propagation. Human–AI control mode switching also provides an additional safeguard against unexpected system behaviors, model drift, or misinterpretations by ensuring that human judgment can override or validate AI outputs before execution. • Example: In an autonomous vehicle, the mode-switching mechanism allows the driver to specify whether the AI should automatically initiate lane changes or merely suggest them, enabling manual review in dense traffic or hazardous conditions. This ensures that the human operator retains situational awareness and can intervene when contextual nuances exceed the model’s competence. • Related AITDs: Mitigates Entanglement by providing a clear separation between AI-generated recommendations and their execution, reducing the risk of tightly coupled autonomous decisions leading to cascading failures. Also addresses Undeclared Consumers by ensuring that AI outputs are not silently consumed or acted upon without explicit human approval, thereby improving transparency and accountability in how AI-driven decisions are used. 6.2.25. Unified Programming Language Policy Adopting a single, standardized programming language across the AI development lifecycle reduces fragmentation in implementation practices and streamlines system-wide security, testing, and audit processes (Yang et al., 2024; Bogner et al., 2021; Martínez-Fernández2022). When AI pipelines depend on multiple languages—such as Python for modeling, R for analytics, and Java or C++ for deployment—teams face increased complexity in dependency management, debugging, and vulnerability scanning. A unified programming language policy improves maintainability, enhances developer productivity, supports more consistent security hardening, and reduces integration overhead by minimizing cross-language interoperability challenges. • Example: In an AI-based e-commerce recommendation system, standardizing all components—feature engineering, model training, batch scoring, and API serving—on Python enables consistent dependency management (e.g., pip/conda), uniform static analysis, and streamlined deployment pipelines, lowering the risk of language-specific vulnerabilities or mismatched runtime environments. • Related AITDs: Multiple Language Smells (MLS) — reduces fragmentation and eliminates hard-to-maintain cross-language boundaries; Glue Code Debt — minimizes the need for connectors or wrappers between mismatched languages; Compatibility Debt — avoids inconsistencies in runtime environments and library ecosystems caused by heterogeneous language stacks. 6.2.26. AI-Adaptive Secure Design Practices This guideline emphasizes the integration of AI-specific ethical, security, and operational requirements into established system design methodologies, such as Unified Modeling Language (UML), SysML, workflow diagrams, or architectural blueprints (Shahriar et al., 2023; Ebad, 2022; Spelda and Stritecky, 2025; Patel and Shah, 2021). Traditional design methods often fall short in representing the unique risks of AI components—such as model drift, data dependency volatility, adversarial susceptibility, or fairness constraints. By adapting these methods to explicitly model AI behaviors, data flows, decision boundaries, and governance constraints, organizations can surface potential vulnerabilities early in the design phase. This ensures that AI-driven components are not treated as black-box add-ons but as first-class citizens whose ethical, safety, and security requirements shape the architecture from its inception. Embedding AI-aware design practices also supports cross-team alignment by enabling data engineers, ML researchers, and software architects to reason about system interactions holistically. Early modeling of AI-specific design concerns reduces downstream refactoring, minimizes architectural inconsistencies, and strengthens long-term system maintainability. • Example: When architecting an AI-powered traffic management system, UML component diagrams may explicitly represent fairness constraints, model-update workflows, input-validation checkpoints, and monitoring hooks. Including these aspects early ensures the final system adheres to ethical expectations, safety constraints, and regulatory requirements. • Related AITDs: Design Debt — mitigated by embedding robust architectural principles and ethical/security considerations from the outset; Boundary Erosion — reduced by clearly representing AI component boundaries and interfaces; Configuration Debt — minimized by documenting AI-specific configuration parameters within formal design artifacts; Entanglement — avoided by designing modular, well-isolated AI components with explicitly defined interactions. Table 8. Mapping of Security Guidelines to Related AI Technical Debts (AITDs) S/N Security Guideline Related AITDs Explanation 1 Configuration Management Configuration Debt, Versioning Debt, Pipeline Jungle, Compatibility Debt Ensures consistent, auditable, and controlled configurations across models, pipelines, dependencies, and environments. 2 Encryption and Secure Data Storage Data Debt, Configuration Debt, Documentation Debt, Versioning Debt Protects sensitive data via encryption at rest/in transit, secure storage, and proper cryptographic configuration. 3 Continuous Behavioral & Performance Monitoring Ethical Debt, Configuration Debt, Data Debt, Hidden Feedback Loops, Design Debt Detects drift, misconfigurations, unfair outcomes, and anomalous behaviors. 4 Incident Response for AI Systems Hidden Feedback Loops, Unstable Data Dependencies, Configuration Debt, SATD Enables structured detection, containment, and recovery from AI-specific incidents (e.g., poisoning). 5 Data Validation Data Debt, Pipeline Jungle, Correction Cascades Ensures input data is correct, consistent, authentic, and complete before entering AI pipelines. 6 Input Sanitization (Defense Against Evasion Attacks) Algorithmic Inclination, Entanglement, Correction Cascades, Defect Debt Removes adversarial inputs and malicious payloads to prevent evasion attacks. 7 Model Watermarking (Model Integrity Controls) Undeclared Consumers, Versioning Debt, Documentation Debt, Glue Code Detects tampering, unauthorized use, and illicit replication of models. 8 Use of Hardened Models & Defensive Training Algorithmic Inclination, Entanglement, Correction Cascades, Design Debt Improves robustness via adversarial training and defense-oriented modeling. 9 Red Teaming and AI Alignment (RLHF) Ethical Debt, Algorithmic Inclination, Overly Simplified Metrics, SATD Identifies vulnerabilities and aligns model behavior with safe and ethical outcomes. 10 Adequate AI Resource & Continuity Management Configuration Debt, Process/Infrastructure Debt Ensures AI systems have reliable resources and continuity plans for safe operation. 11 Secure Coding Practices Glue Code, Duplicate Model Code, Unwanted Debugging Code, Defect Debt Enforces secure development, dependency scanning, and removal of insecure code artifacts. 12 Data Leak Prevention (DLP) Data Debt, Documentation Debt, Dispensable Dependency, Undeclared Consumers Prevents accidental or malicious exfiltration of sensitive data. 13 Data Masking & Information Deletion Data Debt, Unstable Data Dependencies, Process/Infrastructure Debt, Documentation Debt Anonymizes and securely deletes sensitive/obsolete data to reduce risk. 14 Threat Intelligence Dispensable Dependency, SML, Configuration Debt, Data Debt, Boundary Erosion, Compatibility Debt, Documentation/Versioning Debt Provides early awareness of AI-specific threats and emerging vulnerabilities. 15 Human–AI Control Mode Switching Entanglement, Undeclared Consumers Enables human oversight, preventing unintended or unsafe autonomous decisions. 16 Multi-Model Consensus Decision Framework Correction Cascades, Hidden Feedback Loops Uses diverse models to detect inconsistencies and avoid cascading failures. 17 AI Redundancy & Failover Mechanisms Algorithmic Inclination, Unstable Data Dependencies Eliminates single-model or single-data-source failure points. 18 Ethical Black Box Entanglement, Undeclared Consumers, Ethical Debt Enhances traceability and accountability for AI decisions. 19 AI Component Divergence Monitoring Correction Cascades, Unstable Data Dependencies Detects divergence across redundant components. 20 Controlled AI Output Consumers Undeclared Consumers, Glue Code, Documentation Debt Prevents unauthorized or untracked consumption of AI outputs. 21 API-Governed AI Access Control Undeclared Consumers, Dispensable Dependency, Glue Code, Versioning Debt Enforces controlled access to AI components and outputs. 22 AI System Software Bill of Materials (AI-SBOM) Data Debt, Dispensable Dependency, Versioning Debt, Documentation Debt Tracks datasets, libraries, and model lineage for transparency and safety. 23 Modular & Reusable AI Components Glue Code, Deep God File, Design Debt, Duplicate Model Code Promotes modular designs that reduce coupling and simplify updates. 24 Standardized & Interoperable Data Formats Glue Code, Unstable Data Dependencies, Compatibility Debt Ensures interoperability and reduces risky conversions. 25 Unified Programming Language Policy Multiple Language Smells (MLS), Glue Code, Compatibility Debt Reduces complexity and lowers cross-language security risks. 26 AI-Adaptive Secure Design Practices Design Debt, Boundary Erosion, Configuration Debt, Entanglement Embeds ethical and security considerations directly into AI system design. RQ3.2: Security Guidelines for Mitigating AITDs Through a systematic consolidation of industry best practices, standards, and research insights, the study proposes a comprehensive set of 26 security-oriented guidelines designed to mitigate the risks associated with AI Technical Debt (AITD). These guidelines address vulnerabilities across the entire AI development and operational lifecycle, with emphasis on data pipelines, model training and deployment, system integration, and governance structures. The key thematic categories include: • Transparency and Accountability Mechanisms: Ethical Black Boxes, auditable decision logs, and traceability tools to support post-hoc analysis and regulatory compliance. • Human–AI Oversight and Control: Human–AI mode switching, human-on-the-loop and human-in-the-loop procedures for high-stakes decisions, and manual override pathways. • Continuous Monitoring and Drift Management: Behavioral monitoring, data drift and concept drift detection, performance tracking, and anomaly detection pipelines. • Resilience and Continuity Engineering: Multi-model consensus, redundancy and failover mechanisms, fallback policies, and robustness techniques against adversarial or unexpected system behavior. • Secure Data Handling and Governance: Encryption, access control, data masking, secure storage, automated deletion routines, and standardized data formats to reduce data-related AITDs. • Model Security and Integrity: Watermarking, hardened models, adversarial and defensive training, and integrity validation checks across the model lifecycle. • Threat Intelligence and Incident Response: AI-specific threat modeling, red-teaming, alignment testing, and rapid incident response workflows tailored for AI-enabled systems. • Configuration, Dependency, and Resource Management: Version control for AI components, environment reproducibility, AI SBOM management, modularization, and resource continuity planning to reduce operational AITD accumulation. Overall Emphasis: The presented set of 26 guidelines aims to enhance system resilience, reduce vulnerability exposure, and ensure that AI-enabled systems remain secure, transparent, and trustworthy throughout their lifecycle. These guidelines form the foundation for mitigating the diverse forms of AITD identified in this study. 7. Principal findings This systematic review consolidates evidence from 60 primary studies and identifies 31 distinct forms of technical debt as they manifest in AI-enabled systems. Using grounded theory and a root-cause–oriented synthesis approach, these debts were organized into a unified taxonomy consisting of seven major classes: (1) Data & Library–Related Debts, (2) Model & Code–Related Debts, (3) Algorithm–Related Debts, (4) Design & Architecture Debts, (5) Operational & Lifecycle Debts, (6) Documentation & Communication Debts, and (7) Testing & Quality Assurance Debts. This classification shifts the perspective from traditional categorizations toward a cause-driven view, enabling deeper analysis of how AITDs originate, propagate, and affect downstream system behavior, quality, and risk. Root-Cause–Oriented Debt Landscape: The taxonomy reveals that AITDs arise from heterogeneous origins across the AI development pipeline. Data & Library–Related Debts, such as Data Debt and Pipeline Jungle, remain dominant and often triggered by incomplete, biased, outdated, or inconsistently processed datasets. These debts impede reproducibility and increase the likelihood of bias amplification and model drift. Model & Code–Related Debts capture issues such as Model Entanglement, Model Complexity, and Glue Code, which introduce maintainability bottlenecks and obscure system behavior. Algorithm–Related Debts, including Algorithmic Inclination or misaligned objective functions, reflect deeper issues with optimization choices or inadequately specified learning criteria. Design & Architecture Debts highlight structural shortcomings such as poor modularity, tightly coupled components, and undocumented dependencies, which impair scalability and evolution capability. Operational & Lifecycle Debts underscore challenges in deployment, monitoring, retraining, and model governance—areas increasingly recognized as critical in MLOps environments. Finally, Documentation & Communication Debts and Testing & QA Debts reveal persistent gaps in transparency, traceability, and verification, further weakening system accountability and reliability. Collectively, this taxonomy illustrates that AITDs originate from systemic and interconnected root causes spanning data, model internals, architectural decisions, operational workflows, and organizational practices. Impact on System Quality Attributes: Across the reviewed studies, AITDs were found to substantially degrade qualities such as maintainability, performance, scalability, robustness, and efficiency. Debts related to data governance and model behavior often introduce latent risks—manifesting only during redeployment, domain shifts, or integration with new pipelines. Model Entanglement, for instance, impedes debugging and retraining, while missing or poor documentation complicates audits and compliance checks. The analysis also highlights strong interactions between AITDs and explainability, interpretability, and fairness—quality dimensions that carry unique significance in AI engineering. These impacts extend beyond typical software failures, affecting trustworthiness and societal acceptance of AI systems. Notably, the findings show that many AITDs have a cascading effect: errors in data processing propagate into models, which then propagate into downstream decisions, magnifying technical and ethical risks. Safety and Security Integration: A core contribution of this study is the explicit mapping of the 31 AITDs to 6 safety and 12 security risks identified in the literature. Certain debts, such as Data Debt, Undeclared Consumers, and Correction Cascades, were repeatedly linked to vulnerabilities including adversarial susceptibility, data leakage, unreliable model reuse, and unstable behavior under distribution shifts. Ethical and documentation-related debts were associated with failures in accountability, auditability, and safe human oversight. Operational debts further compromise resilience by impairing monitoring, retraining, and incident response workflows. This mapping confirms that AITDs function not merely as engineering inefficiencies but as systemic vulnerabilities with direct implications for safety, compliance, and risk governance—highlighting the need to integrate AITD assessment with security engineering and safety certification processes. Mitigation Strategies: The study synthesizes a total of 34 mitigation guidelines - 8 safety guidelines and 26 security - designed to address the root causes and propagation pathways of AITDs. These include mechanisms such as: Human–AI Control Mode Switching, Ethical Black Boxes for decision logging, Continuous Behavioral and Drift Monitoring, Model Watermarking and Hardening, Redundancy and Failover Architectures, Out-of-Distribution Detection, and Formal Verification and Model Assurance for high-risk deployments. Each guideline is mapped to one or more debt classes (Tables 7–8), creating a traceable link between AITD type, underlying cause, associated risks, and appropriate mitigation techniques. By grounding mitigation in root causes, the framework supports proactive debt prevention during design, development, deployment, and continuous operation. AITD-MAP Framework: Building on the taxonomy and mappings, the study introduces the AITD-MAP (Mapping AI Technical Debt: Types, Impact, and Guidelines) framework. AITD-MAP integrates three dimensions: (i) the root-cause-oriented AITD taxonomy, (i) the identified impacts on software quality, safety, and security, and (i) the 34 mitigation guidelines. This unified model enables practitioners to diagnose debts based on symptoms, trace their propagation across pipelines, evaluate associated risks, and select targeted mitigation strategies. It also offers a conceptual foundation for future automated tools for AITD detection, monitoring, and refactoring in MLOps ecosystems. Prevalence and Prioritization: The prevalence analysis shows that Data Debt/Unstable Data Dependencies is the most frequently reported AITD, appearing in 27 of 60 studies (45%). This is followed by Glue Code (30%), Test Debt (28.33%), and Documentation Debt (25.33%). Other commonly reported debts include Requirement Debt (23.33%), Design Debt (21.67%), and Configuration Debt (20%). These results indicate that data-related and model/code-related debts dominate current AI development challenges, particularly those associated with unstable data pipelines, ad-hoc integrations, prototype code, and insufficient testing practices. The relatively high frequency of documentation, requirement, and design debts further reflects the ongoing struggle to maintain traceability, architectural clarity, and consistent communication in rapidly evolving AI workflows. Overall, the distribution of AITDs underscores that the most pervasive issues stem from the early stages of the AI pipeline (data and preprocessing), the implementation layer (model/code quality), and system-level coordination (requirements, documentation, and configuration). This prioritization highlights the need for context-aware debt management practices tailored to system maturity, domain criticality, and operational risk profiles. Synthesis and Implications: Overall, this review provides the first root-cause–oriented, security-aware, and mitigation-driven characterization of AI Technical Debt. By connecting technical debt origin, systemic impact, and prescriptive mitigation, the study bridges a significant gap in the AI engineering literature. The findings emphasize that AITD management must be continuous, interdisciplinary, and transparent-spanning data governance, model design, architecture, testing, deployment, and organizational practices. Integrating AITD assessment into DevOps and MLOps workflows is essential for early detection and automated mitigation. This work lays a robust foundation for future empirical validations, tool development, and policy frameworks aimed at promoting sustainable, trustworthy, and resilient AI systems. 7.1. Strengths and limitations This study demonstrates several notable strengths. It systematically identifies and categorizes 31 distinct types of AI Technical Debts (AITDs), offering a comprehensive taxonomy that captures their structural, operational, and ethical implications in AI-based systems. By emphasizing the intersection between AITDs and critical concerns—particularly security and safety—the study provides a nuanced understanding of how these debts affect system attributes such as maintainability, robustness, and resilience. The introduction of AITD-MAP (Mapping AI Technical Debt: Types, Impact, and Guidelines) further strengthens the contribution by organizing insights across taxonomy, quality attributes, and mitigation strategies into a coherent, actionable framework. Another key strength lies in the proposed mitigation strategies. The study presents 34 security and safety guidelines that are explicitly mapped to the identified AITDs, offering practical pathways to address risks in AI system development and deployment. This integration of mitigation guidance into a structured framework represents a novel step toward responsible and sustainable AI engineering. Additionally, the application of grounded theory ensures a rigorous and data-driven process for categorization, enhancing the validity and reliability of findings. The review draws on 60 primary studies from diverse domains, reinforcing the generalizability of the findings across various AI use cases and development contexts. However, the study is not without limitations. The reliance on selected academic databases (ACM Digital Library, IEEE Xplore, Scopus, and Springer) may have led to the exclusion of relevant studies from other specialized or emerging sources. The manual nature of the selection, coding, and classification process—though mitigated by cross-checking and author consensus—still poses a risk of human bias or oversight. Furthermore, the study’s focus on recent literature (2015–2025) offers a timely synthesis but may omit insights from earlier foundational works on technical debt or AI safety. While the inclusion of mitigation guidelines is a major strength, their practical applicability remains to be validated through industrial case studies or empirical trials. Additionally, some emerging debts—such as Correction Cascades and Boundary Erosion—appear less frequently in the literature, making their classification provisional and highlighting the need for further empirical investigation. Despite these limitations, this research significantly advances the field by providing a taxonomy-driven, security-aware, and mitigation-oriented perspective on AI Technical Debt. It sets a solid foundation for future empirical studies and practical tool development aimed at improving the quality, accountability, and resilience of AI-based systems. 8. Conclusion and future work As AI-based systems increasingly operate in safety-critical and trust-sensitive environments, the accumulation of AI Technical Debt (AITD) poses a serious challenge to their long-term sustainability, maintainability, and trustworthiness. This study conducted a systematic review of 60 primary studies and identified 31 distinct types of AITDs, offering a detailed taxonomy and analysis of their origin, impact, and mitigation strategies. A key contribution of this work is the adoption of AI TRiSM (AI Trust, Risk, and Security Management) as a conceptual lens to reinterpret AITDs through the dimensions of trust, risk, safety, and security. This perspective consolidates fragmented concerns across technical and governance domains and emphasizes the interdependence between safety and security debt—both of which are often treated in isolation in existing literature. To operationalize this perspective, we proposed the AITD-MAP framework, which unifies taxonomic classification, impact assessment, and mitigation planning for AITDs. We further introduced 34 actionable guidelines to assist practitioners and researchers in identifying and addressing AITDs—especially those that compromise safety, security, and overall system trustworthiness. In summary, this study offers a structured, multi-dimensional understanding of AITDs and introduces a practical roadmap for addressing them. The proposed taxonomy, impact mappings, and mitigation framework contribute to the growing body of knowledge on responsible and sustainable AI engineering—supporting researchers, developers, and policymakers in building safe, secure, reliable, and maintainable AI systems. While this study consolidates and maps a comprehensive set of safety and security guidelines to the identified AITDs, future work should focus on empirically validating these guidelines in industrial settings and evaluating their effectiveness within MLOps pipelines. A natural extension of this work involves operationalizing the AITD-MAP framework into automated tools for debt detection, monitoring, and risk-aware refactoring. Such developments can draw on principles of responsible, safe, and secure AI engineering, as discussed in Section 6, with the aim of improving guideline applicability and supporting continuous assurance. Moreover, although the reviewed debts primarily reflect challenges in foundational AI systems, the insights extend to emerging paradigms such as Agentic-AI (Shavit et al., 2023; Chawla et al., 2024) and large language models (LLMs) (Chang et al., 2024). These systems introduce increased autonomy, complexity, and dependency on dynamic data sources, which may intensify the accumulation and propagation of AITDs. Investigating how the proposed taxonomy, guidelines, and AITD-MAP framework apply to these new architectures represents a promising direction for future research. 8.1. Future Challenges and Research Directions Building upon the findings and risk-informed roadmap proposed in this study, several open challenges and research directions emerge that warrant further exploration to advance the management of AI Technical Debt (AITD) in intelligent systems. • Standardized Metrics and Measurement Frameworks. Although this study provides a taxonomy and qualitative mapping of AITDs, the absence of standardized metrics for assessing the severity, propagation, and resolution of such debts remains a critical gap. Future research should focus on defining quantifiable indicators and benchmark datasets to enable empirical measurement of AITD impact on software quality, maintainability, and trustworthiness. • Tooling and Automation for Debt Detection. While mature automated tools already exist for detecting several forms of technical debt—particularly code- and design-related debts - many AI-specific and cross-cutting AITDs (e.g., data-related debt, pipeline-level debt, and socio-technical debt) still rely heavily on manual qualitative analysis. Developing AI-aware and integrated detection and monitoring approaches-leveraging static analysis, ML-driven pattern recognition, and natural language processing of development artifacts-will therefore be crucial for operationalizing comprehensive AITD management within MLOps and continuous integration pipelines. • Dynamic Risk Modeling and Simulation. As AITDs evolve over time through feedback loops and system updates, static analyses may fail to capture their long-term implications. Future studies should adopt dynamic simulation techniques (e.g., digital twins, system dynamics) to model how debts accumulate, interact, and impact reliability, security, and ethics throughout the system lifecycle. • Integration with AI Governance and TRiSM Frameworks. The mapping with AI TRiSM and related governance models revealed strong conceptual overlap between AITDs and concerns such as fairness, transparency, and accountability. Future work should formalize these relationships by embedding debt-aware risk assessment modules within governance, assurance, and certification frameworks. • Towards a Debt-Aware Software Engineering Paradigm. The long-term vision is to establish a debt-aware AI engineering paradigm where design decisions, testing strategies, and deployment pipelines are continuously informed by AITD risk indicators. Future work should develop integrated frameworks that connect technical debt management with responsible and sustainable AI system development. By addressing these open challenges, future research can move toward a quantitative, automated, and context-aware understanding of AI Technical Debt. This will strengthen both theoretical foundations and practical interventions, ensuring the responsible and sustainable evolution of intelligent systems. References N. Aagaard, E. K. Aasvang, and C. S. Meyhoff (2024) Discrepancies between promised and actual ai capabilities in the continuous vital sign monitoring of in-hospital patients: a review of the current evidence. Sensors (Basel, Switzerland) 24 (19), p. 6497. Cited by: §6.2.18. A. Adadi and M. Berrada (2018) Peeking inside the black-box: a survey on explainable artificial intelligence (xai). IEEE Access 6 (), p. 52138–52160. External Links: Document Cited by: §5.1.1, §6.1.1, §6.1.7. N. Y. Akgül, T. T. Temizel, Ö. Ö. Top, and P. D. Akman (2025) Aligning data debt with ai-integrated software project lifecycle processes: a standard-based mapping approach. In 2025 IEEE/ACM International Conference on Technical Debt (TechDebt), p. 1–11. Cited by: item 1. P. D. Akman, Ö. Ö. Top, and T. T. Temizel (2025) People and management debt in ml-integrated software projects: structuring industry insights. IEEE Access. Cited by: item 2. M. N. Akram, A. Ambekar, I. Sorokos, K. Aslansefat, and D. Schneider (2022) StaDRe and stadro: reliability and robustness estimation of ml-based forecasting using statistical distance measures. In International Conference on Computer Safety, Reliability, and Security, p. 289–301. Cited by: §5.1.2. M. A. Al Alamin and G. Uddin (2021) Quality assurance challenges for machine learning software applications during software development life cycle phases. In 2021 IEEE International Conference on Autonomous Systems (ICAS), p. 1–5. Cited by: §5.2.4. M. Alahdab and G. Çalıklı (2019) Empirical analysis of hidden technical debt patterns in machine learning software. In Product-Focused Software Process Improvement: 20th International Conference, PROFES 2019, Barcelona, Spain, November 27–29, 2019, Proceedings 20, p. 195–202. Cited by: item 1, item 2, item 10, item 7, item 4. A.S. Albahri, A. M. Duhaim, M. A. Fadhel, A. Alnoor, N. S. Baqer, L. Alzubaidi, O.S. Albahri, A.H. Alamoodi, J. Bai, A. Salhi, J. Santamaría, C. Ouyang, A. Gupta, Y. Gu, and M. Deveci (2023) A systematic review of trustworthy and explainable artificial intelligence in healthcare: assessment of quality, bias risk, and data fusion. Information Fusion 96, p. 156 – 191. Note: Cited by: 359 External Links: Document, Link Cited by: §5.1.1, §6.1.1. D. Albuquerque, E. Guimaraes, G. Tonin, M. Perkusich, H. Almeida, and A. Perkusich (2022) Comprehending the use of intelligent techniques to support technical debt management. In Proceedings of the International Conference on Technical Debt, p. 21–30. Cited by: §2, item 8, item 1, item 3, item 1, item 2, item 3, item 1, item 1. N. Aleksandra, J. Bojana, R. Maryan, and T. Dimitar (2025) Evaluating trustworthiness in ai: risks, metrics, and applications across industries. Electronics 14 (13), p. 2717. Cited by: §1.1. R. Alfayez, W. Alwehaibi, R. Winn, E. Venson, and B. Boehm (2020) A systematic literature review of technical debt prioritization. In Proceedings of the 3rd international conference on technical debt, p. 1–10. Cited by: §2. M. Ali, Y. Hu, D. K. Luong, G. Oguntala, J. Li, and K. Abdo (2020) Adversarial attacks on ai based intrusion detection system for heterogeneous wireless communications networks. In 2020 AIAA/IEEE 39th Digital Avionics Systems Conference (DASC), Vol. , p. 1–6. External Links: Document Cited by: §5.1.5. S. Alneyadi, E. Sithirasenan, and V. Muthukkumarasamy (2016) A survey on data leakage prevention systems. Journal of Network and Computer Applications 62, p. 137–152. Cited by: §6.2.9. N. S. Alves, T. S. Mendes, M. G. De Mendonça, R. O. Spínola, F. Shull, and C. Seaman (2016) Identification and management of technical debt: a systematic mapping study. Information and Software Technology 70, p. 100–121. Cited by: §2. A. Ampatzoglou, A. Ampatzoglou, A. Chatzigeorgiou, and P. Avgeriou (2015) The financial aspect of managing technical debt: a systematic literature review. Information and Software Technology 64, p. 52–73. Cited by: §2. G. Annunziata, S. Lambiase, D. A. Tamburri, W. Van Den Heuvel, F. Palomba, G. Catolino, F. Ferrucci, and A. De Lucia (2025) Uncovering community smells in machine learning-enabled systems: causes, effects, and mitigation strategies. ACM Transactions on Software Engineering and Methodology 34 (6), p. 1–48. Cited by: item 2. F. Arnez, H. Espinoza, A. Radermacher, and F. Terrier (2021a) Improving robustness of deep neural networks for aerial navigation by incorporating input uncertainty. In Computer Safety, Reliability, and Security. SAFECOMP 2021 Workshops, I. Habli, M. Sujan, S. Gerasimou, E. Schoitsch, and F. Bitsch (Eds.), Cham, p. 219–225. External Links: ISBN 978-3-030-83906-2 Cited by: §1, §5.1.6. F. Arnez, H. Espinoza, A. Radermacher, and F. Terrier (2021b) Improving robustness of deep neural networks for aerial navigation by incorporating input uncertainty. In International Conference on Computer Safety, Reliability, and Security, p. 219–225. Cited by: §5.1.2. A. Arpteg, B. Brinne, L. Crnkovic-Friis, and J. Bosch (2018) Software engineering challenges of deep learning. In 2018 44th euromicro conference on software engineering and advanced applications (SEAA), p. 50–59. Cited by: item 1, item 10, item 3, item 1, item 2, item 1. P. Avgeriou, P. Kruchten, I. Ozkaya, and C. Seaman (2016) Managing technical debt in software engineering (dagstuhl seminar 16162). Dagstuhl reports 6 (4), p. 110–138. Cited by: §2. L. Avivah (2024) Tackling trust, risk and security in ai models. https://w.gartner.com/en/articles/ai-trust-and-ai-risk. Cited by: §1.1, §1. Y. Bai, A. Jones, K. Ndousse, A. Askell, A. Chen, N. DasSarma, D. Drain, S. Fort, D. Ganguli, T. Henighan, et al. (2022) Training a helpful and harmless assistant with reinforcement learning from human feedback. arXiv preprint arXiv:2204.05862. Cited by: §6.2.8. S. Banerjee, M. Thomas, V. Chavan, U. Mangla, and S. Tummalapenta (2025) Securing the future of ai: a holistic approach to trust and robustness. In Assurance and Security for AI-enabled Systems 2025, Vol. 13476, p. 121–142. Cited by: §6.2.12. E. Barlas, X. Du, and J. C. Davis (2022) Exploiting input sanitization for regex denial of service. In Proceedings of the 44th International Conference on Software Engineering, p. 883–895. Cited by: §6.2.22. G. Bavota and B. Russo (2016) A large-scale empirical study on self-admitted technical debt. In Proceedings of the 13th international conference on mining software repositories, p. 315–326. Cited by: item 10, item 3, item 1, item 2, item 1, item 1. H. Belani, M. Vukovic, and Ž. Car (2019) Requirements engineering challenges in building ai-based complex systems. In 2019 IEEE 27th International Requirements Engineering Conference Workshops (REW), p. 252–255. Cited by: §2, item 1, item 2, item 1, item 10, item 2, item 5, item 6, item 4, item 1. G. Bendiab, A. Hameurlaine, G. Germanos, N. Kolokotronis, and S. Shiaeles (2023) Autonomous vehicles security: challenges and solutions using blockchain and artificial intelligence. IEEE Transactions on Intelligent Transportation Systems 24 (4), p. 3614–3637. Cited by: §1. A. Bhatia, F. Khomh, B. Adams, and A. E. Hassan (2023) An empirical study of self-admitted technical debt in machine learning software. arXiv preprint arXiv:2311.12019. Cited by: Table 1, §2. [29] G. Bilakanti Secure data masking for healthcare data protection. . Cited by: §6.2.10. J. Bogner, R. Verdecchia, and I. Gerostathopoulos (2021) Characterizing technical debt and antipatterns in ai-based systems: a systematic mapping study. In 2021 IEEE/ACM International Conference on Technical Debt (TechDebt), p. 64–73. Cited by: §1, Table 1, §2, §6.2.11, §6.2.15, §6.2.17, §6.2.25, §6.2.3. G. Bravo-Rocca, P. Liu, J. Guitart, A. Dholakia, D. Ellison, and M. Hodak (2022) Human-in-the-loop online multi-agent approach to increase trustworthiness in ml models through trust scores and data augmentation. In 2022 IEEE 46th Annual Computers, Software, and Applications Conference (COMPSAC), p. 32–37. Cited by: §5.1.3, §5.1.6. E. Breck, S. Cai, E. Nielsen, M. Salib, and D. Sculley (2017) The ml test score: a rubric for ml production readiness and technical debt reduction. In 2017 IEEE international conference on big data (big data), p. 1123–1132. Cited by: item 1, item 4, item 4, item 1. A. Bucaioni, R. Kazman, and P. Pelliccione (2025) A checklist of quality concerns for architecting ml-intensive systems. Journal of Systems and Software, p. 112612. Cited by: §5.1. A. L. Buczak, B. D. Baugher, A. J. Berlier, K. E. Scharfstein, and C. S. Martin (2022) Explainable forecasts of disruptive events using recurrent neural networks. In 2022 IEEE international conference on assured autonomy (ICAA), p. 64–73. Cited by: §5.1.3. R. Camilo, S. Yuki, and B. Eleanor (2024) AI-driven threat intelligence: enhancing cybersecurity in modern software systems. Journal of Adaptive Learning Technologies 1 (8), p. 53–68. Cited by: §6.2.7. N. Carlini and D. Wagner (2017) Towards evaluating the robustness of neural networks. In 2017 ieee symposium on security and privacy (sp), p. 39–57. Cited by: §5.1.2, §5.1.5, §5.1.6. A. Celepija, B. Lepri, and R. Kazhamiakin (2025) Towards a structured ai development lifecycle for reusable ai products in the public sector. Cited by: §6.2.14. V. Chamola, V. Hassija, A. R. Sulthana, D. Ghosh, D. Dhingra, and B. Sikdar (2023) A review of trustworthy and explainable artificial intelligence (xai). IEEe Access 11, p. 78994–79015. Cited by: §5.1.1, §5.1.3, §6.1.1. J. Chang and C. Custis (2022) Understanding implementation challenges in machine learning documentation. In Proceedings of the 2nd ACM Conference on Equity and Access in Algorithms, Mechanisms, and Optimization, p. 1–8. Cited by: item 2, item 1. Y. Chang, X. Wang, J. Wang, Y. Wu, L. Yang, K. Zhu, H. Chen, X. Yi, C. Wang, Y. Wang, et al. (2024) A survey on evaluation of large language models. ACM Transactions on Intelligent Systems and Technology 15 (3), p. 1–45. Cited by: §8. D. K. Chaudhary, S. Srivastava, and V. Kumar (2018) A review on hidden debts in machine learning systems. In 2018 Second International Conference on Green Computing and Internet of Things (ICGCIoT), p. 619–624. Cited by: item 4, item 2, item 1, item 3, item 2, §5.2.11, §5.2.12. C. Chawla, S. Chatterjee, S. S. Gadadinni, P. Verma, and S. Banerjee (2024) Agentic ai: the building blocks of sophisticated ai business applications. Journal of AI, Robotics & Workplace Automation 3 (3), p. 1–15. Cited by: §8. J. Chen, Y. Liang, Q. Shen, J. Jiang, and S. Li (2023) Toward understanding deep learning framework bugs. ACM Transactions on Software Engineering and Methodology 32 (6), p. 1–31. Cited by: item 1, item 4, item 5. K. K. Chennam, S. Mudrakola, V. U. Maheswari, R. Aluvalu, and K. G. Rao (2023) Black box models for explainable artificial intelligence. In Explainable AI: Foundations, Methodologies and Applications, M. Mehta, V. Palade, and I. Chatterjee (Eds.), p. 1–24. External Links: ISBN 978-3-031-12807-3, Document, Link Cited by: §6.1.7. D. R. Chirra (2020) AI-based real-time security monitoring for cloud-native applications in hybrid cloud environments. Revista de Inteligencia Artificial en Medicina 11 (1), p. 382–402. Cited by: §5.2.8. S. Choi, J. Shin, P. Liu, and Y. Choi (2022) ARGAN: adversarially robust generative adversarial networks for deep neural networks against adversarial examples. IEEE Access 10, p. 33602–33615. Cited by: §5.1.2. J. Cooper, O. Arandjelović, and D. J. Harrison (2022) Believe the hipe: hierarchical perturbation for fast, robust, and model-agnostic saliency mapping. Pattern Recognition 129, p. 108743. Cited by: §5.1.3. J. M. Corbin and A. Strauss (1990) Grounded theory research: procedures, canons, and evaluative criteria. Qualitative sociology 13 (1), p. 3–21. External Links: Document Cited by: §3.8, §4. D. Corsi, E. Marchesini, and A. Farinelli (2021) Formal verification of neural networks for safety-critical tasks in deep reinforcement learning. In Proceedings of the Thirty-Seventh Conference on Uncertainty in Artificial Intelligence, C. de Campos and M. H. Maathuis (Eds.), Proceedings of Machine Learning Research, Vol. 161, p. 333–343. External Links: Link Cited by: §6.1.5. D. Costal, C. Gómez, S. del Rey, and S. Martínez-Fernández (2024) Using metrics for code smells of ml pipelines. In 2024 IEEE 21st International Conference on Software Architecture Companion (ICSA-C), Vol. , p. 289–294. External Links: Document Cited by: item 3, item 4, item 10, item 6, §5.2.11. P. Côté, A. Nikanjam, R. Bouchoucha, I. Basta, M. Abidi, and F. Khomh (2024) Quality issues in machine learning software systems. Empirical Software Engineering 29 (6), p. 1–47. Cited by: item 1, item 3, item 1. W. S. Cunha, G. A. Armijo, and V. V. de Camargo (2020) Investigating non-usually employed features in the identification of architectural smells: a machine learning-based approach. In Proceedings of the 14th Brazilian Symposium on Software Components, Architectures, and Reuse, p. 21–30. Cited by: item 1, item 4, item 1. W. Cunningham (1992) The wycash portfolio management system. ACM Sigplan Oops Messenger 4 (2), p. 29–30. Cited by: §1. G. Dai, S. Sthapit, G. Epiphaniou, and C. Maple (2021) Artificial intelligence technologies in building resilient machine learning. In Competitive Advantage in the Digital Economy (CADE 2021), Vol. 2021, p. 50–55. Cited by: §5.2.5. N. Dang, K. Shao, L. Chen, and M. Yang (2022) Multi-model decision-making seizure types classification based on transfer learning. Conference paper p. 192 – 201. Note: Cited by: 6 External Links: Document, Link Cited by: §6.2.19. M. Dave and N. Patel (2023) Artificial intelligence in healthcare and education. British dental journal 234 (10), p. 761–764. Cited by: §1. J. W. de Kok, M. Á. A. de la Hoz, Y. de Jong, V. Brokke, P. W. Elbers, P. Thoral, A. Castillejo, T. Trenor, J. M. Castellano, A. E. Bronchalo, et al. (2023) A guide to sharing open healthcare data under the general data protection regulation. Scientific data 10 (1), p. 404. Cited by: §5.2.9. R. de Souza Santos, F. Fronchetti, S. Freire, and R. Spinola (2025) Software fairness debt: building a research agenda for addressing bias in ai systems. ACM Transactions on Software Engineering and Methodology 34 (5), p. 1–21. Cited by: item 1, item 1, item 3, item 1, item 2, item 1. S. A. Ebad (2022) Exploring how to apply secure software design principles. IEEE Access 10, p. 128983–128993. Cited by: §6.2.26. N. Ernst, R. Kazman, and J. Delange (2021) Technical debt in practice: how to find it and fix it. MIT Press. Cited by: item 1, item 1, item 2, item 1. M. Farrell, M. Luckcuck, L. Pullum, M. Fisher, A. Hessami, D. Gal, Z. Murahwi, and K. Wallace (2021) Evolution of the ieee p7009 standard: towards fail-safe design of autonomous systems. In 2021 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW), p. 401–406. Cited by: §5.2.6. M. Feffer, A. Sinha, W. H. Deng, Z. C. Lipton, and H. Heidari (2024) Red-teaming for generative ai: silver bullet or security theater?. In Proceedings of the AAAI/ACM Conference on AI, Ethics, and Society, Vol. 7, p. 421–437. Cited by: §6.2.8. J. Feng, R. V. Phillips, I. Malenica, A. Bishara, A. E. Hubbard, L. A. Celi, and R. Pirracchio (2022) Clinical artificial intelligence quality improvement: towards continual monitoring and updating of ai algorithms in healthcare. npj Digital Medicine 5 (1). Note: Cited by: 175; All Open Access, Gold Open Access, Green Open Access External Links: Document, Link Cited by: §6.2.3. E. Ferrara (2023) Fairness and bias in artificial intelligence: a brief survey of sources, impacts, and mitigation strategies. Sci 6 (1), p. 3. Cited by: §6.1.2. M. Fisher, V. Mascardi, K. Y. Rozier, B. Schlingloff, M. Winikoff, and N. Yorke-Smith (2021) Towards a framework for certification of reliable autonomous systems. Autonomous Agents and Multi-Agent Systems 35, p. 1–65. Cited by: §5.1.2. H. Foidl, M. Felderer, and S. Biffl (2019) Technical debt in data-intensive software systems. In 2019 45th Euromicro conference on software engineering and advanced applications (SEAA), p. 338–341. Cited by: item 1, item 1, item 4. H. Foidl, M. Felderer, and R. Ramler (2022) Data smells: categories, causes and consequences, and detection of suspicious data in ai-based systems. In Proceedings of the 1st International Conference on AI Engineering: Software Engineering for AI, p. 229–239. Cited by: item 1, item 2. H. Foidl and M. Felderer (2019) Risk-based data validation in machine learning-based software systems. In proceedings of the 3rd ACM SIGSOFT international workshop on machine learning techniques for software quality evaluation, p. 13–18. Cited by: §5.2.2. V. Franzoni (2023) From black box to glass box: advancing transparency in artificial intelligence systems for ethical and trustworthy ai. In International Conference on Computational Science and Its Applications, p. 118–130. Cited by: §6.2.23. N. Gaddam (2024) AI-powered data masking for privacy-preserving cloud data sharing. International Journal of Advanced Research in Cloud Computing 5 (2), p. 12–22. Cited by: §6.2.10. M. Ge, J. Xu, Z. Liu, and J. Huang (2024) A mode-switched control architecture for human-in-the-loop teleoperation of multislave robots via data-training-based observer. IEEE Transactions on Systems, Man, and Cybernetics: Systems 54 (4), p. 2471–2483. Cited by: §6.2.24. J. Gesi, S. Liu, J. Li, I. Ahmed, N. Nagappan, D. Lo, E. S. de Almeida, P. S. Kochhar, and L. Bao (2022) Code smells in machine learning systems. Cited by: item 4. J. Girard-Satabin, M. Alberti, F. Bobot, Z. Chihani, and A. Lemesle (2022) CAISAR: a platform for characterizing artificial intelligence safety and robustness. In AISafety, Cited by: §5.1.2, §5.1.6. M. Girdhar, J. Hong, and J. Moore (2023) Cybersecurity of autonomous vehicles: a systematic literature review of adversarial attacks and defense models. IEEE Open Journal of Vehicular Technology 4, p. 417–437. Cited by: §5.2.5. P. Giudici and E. Raffinetti (2023) SAFE artificial intelligence in finance. Finance Research Letters 56, p. 104088. Cited by: §1. K. Gnitko (2024) Systematic overview of ai security standards. Available at SSRN 4922592. Cited by: §1. D. Groombridge et al. (2022) Gartner top 10 strategic technology trends for 2023. https://w. gartner. com/en/articles/gartner-top-10-strategic-technology-trends-for-2023. Cited by: §1.1, §1. P. Gujar (2025) Data standardization and interoperability. In Data usability in the enterprise: how usability leads to optimal digital experiences, p. 89–110. Cited by: §6.2.15. J. Guo, S. Ma, C. Wen, and S. Jin (2025) Performance monitoring-enabled reliable ai-based csi feedback. IEEE Transactions on Wireless Communications 24 (1), p. 197 – 212. Note: Cited by: 1 External Links: Document, Link Cited by: §6.2.3. P. Gupta, R. Singh, H. Kaur, N. Subramanian, N. Jain, et al. (2025) Optimizing cryptocurrency trading strategies through artificial intelligence and blockchain integration: a multi-model framework for predictive analytics.. Advances in Consumer Research 2 (3). Cited by: §6.2.19. S. Gupta (2025) GPU reliability in ai clusters: a study of failure modes and effects. Journal Of Engineering And Computer Sciences 4 (6), p. 298–306. Cited by: §6.2.20. A. Habbal, M. K. Ali, and M. A. Abuzaraida (2024) Artificial intelligence trust, risk and security management (ai trism): frameworks, applications, challenges and future research directions. Expert Systems with Applications 240, p. 122442. Cited by: §1.1, §1. T. Hagendorff (2021) Linking human and machine behavior: a new approach to evaluate training data quality for beneficial machine learning. Minds and Machines 31 (4), p. 563–593. Cited by: §5.1.3. T. Haider, K. Roscher, F. S. da Roza, and S. Günnemann (2023) Out-of-distribution detection for reinforcement learning agents with probabilistic dynamics models. Conference paper Vol. 2023-May, p. 851 – 859. Note: Cited by: 15 External Links: Link Cited by: §5.1.6, §6.1.4. R. Hamon, H. Junklewitz, J. S. Garrido, and I. Sanchez (2024) Three challenges to secure ai systems in the context of ai regulations. Ieee Access 12, p. 61022–61035. Cited by: §6.2.16, §6.2.2, §6.2.21, §6.2.22, §6.2.3, §6.2.4, §6.2.6. M. Hardt, E. Price, and N. Srebro (2016) Equality of opportunity in supervised learning. In Proceedings of the 30th International Conference on Neural Information Processing Systems, NIPS’16, Red Hook, NY, USA, p. 3323–3331. External Links: ISBN 9781510838819 Cited by: §6.1.2. H. He, J. Gray, A. Cangelosi, Q. Meng, T. M. McGinnity, and J. Mehnen (2021) The challenges and opportunities of human-centered ai for trustworthy robots and autonomous systems. IEEE Transactions on Cognitive and Developmental Systems 14 (4), p. 1398–1412. Cited by: §5.1.3, §5.1.5. E. Hernández, M. Öztürk, I. Sittón, and S. Rodríguez (2019) Data protection on fintech platforms. In Highlights of Practical Applications of Survivable Agents and Multi-Agent Systems. The PAAMS Collection: International Workshops of PAAMS 2019, Ávila, Spain, June 26–28, 2019, Proceedings 17, p. 223–233. Cited by: §5.2.9. K. Hjerppe, J. Ruohonen, and V. Leppänen (2019) The general data protection regulation: requirements, architectures, and constraints. Conference paper Vol. 2019-September, p. 265 – 275. Note: Cited by: 39; All Open Access, Green Open Access External Links: Document, Link Cited by: §6.2.2. A. Hoang and H. Phan (2024) Explainable ai in finance: an overview. . Cited by: §5.2.7. B. Hutchinson, A. Smart, A. Hanna, E. Denton, C. Greer, O. Kjartansson, P. Barnes, and M. Mitchell (2021) Towards accountability for machine learning datasets: practices from software engineering and infrastructure. In Proceedings of the 2021 ACM Conference on Fairness, Accountability, and Transparency, p. 560–575. Cited by: item 1, item 1. IBM (2025) What is ai trism?. Note: Accessed: 16 January 2026 External Links: Link Cited by: §1.1, §1. ISO/IEC 27002 (2022) Note: https://sprinto.com/blog/iso-27002-controls/Accessed: Dec 02, 2025 Cited by: §6.2.1, §6.2.10, §6.2.17, §6.2.3, §6.2.5, §6.2.7, §6.2.9. M. Jaeyalakshmi, P. R. Gangadhar, M. Srivatsan, and M. Bhavani (2023) A self-learning ai-based information leak protection system. In International Conference on Advances in Artificial Intelligence and Machine Learning in Big Data Processinging, p. 68–78. Cited by: §6.2.9. N. Jaipuria, K. Stevo, X. Zhang, M. L. Gaopande, I. Calle, J. Jain, and V. N. Murali (2022) DeepPIC: deep perceptual image clustering for identifying bias in vision datasets. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, p. 4793–4802. Cited by: §5.1.4. S. Jawhar, J. Miller, and Z. Bitar (2024) AI-based cybersecurity policies and procedures. In 2024 IEEE 3rd International Conference on AI in Cybersecurity (ICAIC), p. 1–5. Cited by: §6.2.6. H. Jebnoun, M. S. Rahman, F. Khomh, and B. A. Muse (2022) Clones in deep learning code: what, where, and why?. Empirical Software Engineering 27 (4), p. 84. Cited by: item 8, item 3, item 4. G. Jones, D. Kasimatis, N. Pitropakis, R. Macfarlane, and W. J. Buchanan (2025) Analysing the role of llms in cybersecurity incident management. International Journal of Information Security 24 (6), p. 1–14. Cited by: §6.2.6. U. Kamath, J. Liu, and J. Whitaker (2019) Transfer learning: domain adaptation. In Deep Learning for NLP and Speech Recognition, p. 495–535. External Links: ISBN 978-3-030-14596-5, Document, Link Cited by: §6.1.6. R. Kamoi and K. Kobayashi (2020) Out-of-distribution detection with likelihoods assigned by deep generative models using multimodal prior distributions. In SafeAI@AAAI, External Links: Link Cited by: §5.1.6, §6.1.4. S. Katzenbeisser, I. Polian, F. Regazzoni, and M. Stöttinger (2019) Security in autonomous systems. In 2019 IEEE European Test Symposium (ETS), p. 1–8. Cited by: §5.2.1. O. Khanvilkar, M. W. Mkaouer, E. A. AlOmar, A. ElSaid, A. Chaaben, and M. Touati (2025) Automated identification of machine learning technical debt code comments. In 2025 International Conference on Emerging Technologies and Computing (IC_ETC), p. 1–6. Cited by: item 1, item 8, item 3, item 4. A. Khritankov (2021) Hidden feedback loops in machine learning systems: a simulation model and preliminary results. In Software Quality: Future Perspectives on Software Engineering Quality: 13th International Conference, SWQD 2021, Vienna, Austria, January 19–21, 2021, Proceedings 13, p. 54–65. Cited by: item 3. J. Kim and S. Cho (2020) Fair representation for safe artificial intelligence via adversarial learning of unbiased information bottleneck.. In SafeAI@ AAAI, p. 105–112. Cited by: §5.1.4. M. Kiranbabu, A. J. Viji, A. K. Chandanan, V. Birchha, T. K. Pandey, and S. K. Sar (2025) The challenge of adversarial attacks on ai-driven cybersecurity systems.. Journal of Cybersecurity & Information Management 15 (1). Cited by: §6.2.22. H. Kleinwaks, A. Batchelor, and T. H. Bradley (2023a) An ontology for technical debt in systems engineering. IEEE Open Journal of Systems Engineering. Cited by: §2. H. Kleinwaks, A. Batchelor, and T. H. Bradley (2023b) Technical debt in systems engineering—a systematic literature review. Systems Engineering 26 (5), p. 675–687. Cited by: §2. A. Krajna, M. Kovac, M. Brcic, and A. Šarčević (2022) Explainable artificial intelligence: an updated perspective. In 2022 45th Jubilee International Convention on Information, Communication and Electronic Technology (MIPRO), p. 859–864. Cited by: §5.1.1, §5.1.3, §6.1.1. N. Kshetry and L. R. Varshney (2019) Safety in the face of unknown unknowns: algorithm fusion in data-driven engineering systems. In ICASSP 2019-2019 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP), p. 8162–8166. Cited by: §5.1.2. P. V. Kumar, T. Ganguly, R. Gupta, K. S. Pokkuluri, A. K. V. Mishra, and V. Selvi (2024) ML and ai based healthcare model to more interpretable and transparent in medical diagnosis. African Journal of Biological Sciences. Cited by: §5.2.7. V. Lenarduzzi, F. Lomio, S. Moreschini, D. Taibi, and D. A. Tamburri (2021) Software quality for ai: where we are now?. In Software Quality: Future Perspectives on Software Engineering Quality: 13th International Conference, SWQD 2021, Vienna, Austria, January 19–21, 2021, Proceedings 13, p. 43–53. Cited by: item 1, item 10, item 5, item 4, item 2, item 1. B. Li, P. Qi, B. Liu, S. Di, J. Liu, J. Pei, J. Yi, and B. Zhou (2023a) Trustworthy ai: from principles to practices. ACM Computing Surveys 55 (9), p. 1–46. Cited by: §1.1. Y. Li, M. Soliman, P. Avgeriou, and M. Van Ittersum (2023b) DebtViz: a tool for identifying, measuring, visualizing, and monitoring self-admitted technical debt. In 2023 IEEE International Conference on Software Maintenance and Evolution (ICSME), p. 558–562. Cited by: item 10, item 5, item 8, item 9, item 3, item 1, item 1, item 1. Y. Li, M. Soliman, and P. Avgeriou (2022) Identifying self-admitted technical debt in issue tracking systems using machine learning. Empirical Software Engineering 27 (6), p. 131. Cited by: item 5, item 8, item 1, item 1, item 3, item 1, item 2, item 5, item 1, item 1. Y. Li, M. Soliman, and P. Avgeriou (2023c) Automatic identification of self-admitted technical debt from four different sources. Empirical Software Engineering 28 (3), p. 65. Cited by: item 10, item 5, item 8, item 9, item 1, item 3, item 1, item 2, item 5, item 1, item 1. Z. Li, P. Avgeriou, and P. Liang (2015) A systematic mapping study on technical debt and its management. Journal of Systems and Software 101, p. 193–220. Cited by: §2. J. Liu, Q. Huang, X. Xia, E. Shihab, D. Lo, and S. Li (2020) Is using deep learning frameworks free? characterizing technical debt in deep learning frameworks. In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering: Software Engineering in Society, p. 1–10. Cited by: item 1, item 3, item 5, item 1, item 2, item 1, item 1. J. Liu, Q. Huang, X. Xia, E. Shihab, D. Lo, and S. Li (2021) An exploratory study on the introduction and removal of different types of technical debt in deep learning frameworks. Empirical Software Engineering 26, p. 1–36. Cited by: item 1, item 3, item 5, item 1, item 2, item 1, item 1. K. Loncar, J. Redzepagic, and V. Dakic (2024) SECURE coding guidelines and standards.. Annals of DAAAM & Proceedings 35. Cited by: §6.2.5. Q. Lu, Y. Luo, L. Zhu, M. Tang, X. Xu, and J. Whittle (2023a) Developing responsible chatbots for financial services: a pattern-oriented responsible artificial intelligence engineering approach. IEEE Intelligent Systems 38 (6), p. 42–51. Cited by: §6.2.24. Q. Lu, L. Zhu, X. Xu, J. Whittle, D. Douglas, and C. Sanderson (2022) Software engineering for responsible ai: an empirical study and operationalised patterns. In Proceedings of the 44th International Conference on Software Engineering: Software Engineering in Practice, p. 241–242. Cited by: §6.2.24. Q. Lu, L. Zhu, X. Xu, J. Whittle, D. Zowghi, and A. Jacquet (2024) Responsible ai pattern catalogue: a collection of best practices for ai governance and engineering. ACM Computing Surveys 56 (7), p. 1–35. Cited by: §6.2.16, §6.2.18, §6.2.19, §6.2.23, §6.2.3. Q. Lu, L. Zhu, X. Xu, and J. Whittle (2023b) Responsible-ai-by-design: a pattern collection for designing responsible artificial intelligence systems. Ieee Software 40 (3), p. 63–71. Cited by: §6.2.24. M. Maabreh, O. Darwish, O. Karajeh, and Y. Tashtoush (2022a) On developing deep learning models with particle swarm optimization in the presence of poisoning attacks. In 2022 International Arab Conference on Information Technology (ACIT), p. 1–5. Cited by: §5.1.5. M. Maabreh, A. Maabreh, B. Qolomany, and A. Al-Fuqaha (2022b) The robustness of popular multiclass machine learning models against poisoning attacks: lessons and insights. International Journal of Distributed Sensor Networks 18 (7), p. 15501329221105159. Cited by: §5.1.2, §5.1.5. A. Mailach and N. Siegmund (2023) Socio-technical anti-patterns in building ml-enabled software: insights from leaders on the forefront. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), p. 690–702. Cited by: item 2. S. Martínez-Fernández, J. Bogner, X. Franch, M. Oriol, J. Siebert, A. Trendowicz, A. M. Vollmer, and S. Wagner (2022) Software engineering for ai-based systems: a survey. ACM Transactions on Software Engineering and Methodology (TOSEM) 31 (2), p. 1–59. Cited by: §6.2.11. W. Matsuda, M. Fujimoto, T. Aoyama, and T. Mitsunaga (2019) Cyber security risk assessment on industry 4.0 using ics testbed with ai and cloud. In 2019 IEEE conference on application, information and network security (AINS), p. 54–59. Cited by: §6.2.6. M. Mekhfioui, N. El Bazi, O. Laayati, A. Satif, M. Bouchouirbat, C. Kissi, T. Boujiha, and A. Chebak (2025) Optimized digital watermarking for robust information security in embedded systems. Information 16 (4), p. 322. Cited by: §6.2.12. M. H. Meng, G. Bai, S. G. Teo, Z. Hou, Y. Xiao, Y. Lin, and J. S. Dong (2022) Adversarial robustness of deep neural networks: a survey from a formal verification perspective. ArXiv abs/2206.12227. External Links: Link Cited by: §6.1.5. A. Menshawy, Z. Nawaz, and M. Fahmy (2024) Navigating challenges and technical debt in large language models deployment. In Proceedings of the 4th Workshop on Machine Learning and Systems, p. 192–199. Cited by: Table 1, §2, §2, item 3, item 6, item 2, item 2. F. Mohammed (2024) Developing transparent ai models to enhance interpretability and trust in medical diagnostics: implementing explainable ai techniques to provide transparent explanations for medical diagnoses, enhancing trust and acceptance among healthcare professionals. Journal of Machine Learning for Healthcare Decision Support 4 (2), p. 36–43. Cited by: §5.2.7. V. Moldovan, L. Berciu, and R. Patcas (2024) The python software quality dataset. In 2024 50th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), p. 395–398. Cited by: item 1. S. Moreschini, V. Lenarduzzi, and L. Coba (2024) Towards a technical debt for ai-based recommender system. In Proceedings of the 7th ACM/IEEE International Conference on Technical Debt, p. 36–39. Cited by: §2, item 1, item 2, item 10, item 3, item 5, item 7, item 1, item 2. M. V. Musunuru, C. Devi, and S. Sethuraman (2025) Optimizing hot standby redundancy using ai for network traffic balancing and failover management. Journal of Knowledge Learning and Science Technology ISSN: 2959-6386 (online) 4 (3), p. 14–26. Cited by: §6.2.20. M. Mziou Sallami, M. Ibn Khedher, A. Trabelsi, S. Kerboua-Benlarbi, and D. Bettebghor (2019) Safety and robustness of deep neural networks object recognition under generic attacks. In International conference on neural information processing, p. 274–286. Cited by: §5.1.2. M. Naeem, T. Jamal, J. Diaz-Martinez, S. A. Butt, N. Montesano, M. I. Tariq, E. De-la-Hoz-Franco, and E. De-La-Hoz-Valdiris (2021) Trends and future perspective challenges in big data. In Advances in intelligent data analysis and applications: Proceeding of the sixth euro-China conference on intelligent data analysis and applications, 15–18 October 2019, Arad, Romania, p. 309–325. Cited by: §6.2.15. N. Nahar, S. Zhou, G. Lewis, and C. Kästner (2022) Collaboration challenges in building ml-enabled systems: communication, documentation, engineering, and process. In Proceedings of the 44th international conference on software engineering, p. 413–425. Cited by: item 1, item 1, item 4, item 1, item 2. M. Nallakaruppan, B. Balusamy, M. L. Shri, V. Malathi, and S. Bhattacharyya (2024) An explainable ai framework for credit evaluation and analysis. Applied Soft Computing 153, p. 111307. Cited by: §5.2.7. M. Nankya, A. Mugisa, Y. Usman, A. Upadhyay, and R. Chataut (2024) Security and privacy in e-health systems: a review of ai and machine learning techniques. IEEE Access. Cited by: §5.2.4. S. Narula, M. Ghasemigol, J. Carnerero-Cano, A. Minnich, E. Lupu, and D. Takabi (2025) Exploring ai security: a systematic mapping study. IEEE Access. Cited by: §6.2.12. A. Nikanjam and F. Khomh (2021) Design smells in deep learning programs: an empirical study. In 2021 IEEE International conference on software maintenance and evolution (ICSME), p. 332–342. Cited by: item 1, item 3, item 4. NIST (2024) AI risks and trustworthiness. https://airc.nist.gov/airmf-resources/airmf/3-sec-characteristics/. Cited by: §1.1, §1. D. OBrien, S. Biswas, S. Imtiaz, R. Abdalkareem, E. Shihab, and H. Rajan (2022) 23 shades of self-admitted technical debt: an empirical study on machine learning software. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, p. 734–746. Cited by: §2, item 10, item 5, item 8, item 9, item 1, item 2, item 1, item 1. A. T. Olutimehin, A. J. Ajayi, O. C. Metibemu, A. Y. Balogun, T. O. Oladoyinbo, and O. O. Olaniyi (2025) Adversarial threats to ai-driven systems: exploring the attack surface of machine learning models and countermeasures. Available at SSRN 5137026. Cited by: §6.2.21. L. Ouyang, J. Wu, X. Jiang, D. Almeida, C. Wainwright, P. Mishkin, C. Zhang, S. Agarwal, K. Slama, A. Ray, et al. (2022) Training language models to follow instructions with human feedback. Advances in neural information processing systems 35, p. 27730–27744. Cited by: §6.2.8. P. Paidy and K. Chaganti (2024) Securing ai-driven apis: authentication and abuse prevention. International Journal of Emerging Research in Engineering and Technology 5 (1), p. 27–37. Cited by: §6.2.16. G. Parmar, R. Gupta, T. Bhatt, G. Sahani, B. Y. Panchal, and H. Patel (2023) A review on data balancing techniques and machine learning methods. In 2023 5th International Conference on Smart Systems and Inventive Technology (ICSSIT), p. 1004–1008. Cited by: §6.1.2. J. Patel and H. Shah (2021) Creating safe and secure ai-from computer design to cloud technology. INTERNATIONAL RESEARCH JOURNAL OF ENGINEERING & APPLIED SCIENCES 9 (4), p. 10–55083. Cited by: §6.2.26. D. Pedreschi, F. Giannotti, R. Guidotti, A. Monreale, S. Ruggieri, and F. Turini (2019) Meaningful explanations of black box ai decision systems. In Proceedings of the AAAI conference on artificial intelligence, Vol. 33, p. 9780–9784. Cited by: §6.2.23. B. Pérez, C. Castellanos, D. Correal, N. Rios, S. Freire, R. Spínola, C. Seaman, and C. Izurieta (2021) Technical debt payment and prevention through the lenses of software architects. Information and Software Technology 140, p. 106692. Cited by: item 10, item 5, item 8, item 9, item 1, item 3, item 1, item 2, item 3, item 4, item 5, item 1, item 2, item 1. B. Pérez, D. Correal, and H. Astudillo (2019) A proposed model-driven approach to manage architectural technical debt life cycle. In 2019 IEEE/ACM International Conference on Technical Debt (TechDebt), p. 73–77. Cited by: item 1. K. Petersen, R. Feldt, S. Mujtaba, and M. Mattsson (2008) Systematic mapping studies in software engineering. In 12th international conference on evaluation and assessment in software engineering (EASE), Cited by: Table 1. C. Petrozzino (2021) Who pays for ethical debt in ai?. AI and Ethics 1 (3), p. 205–208. Cited by: §2, item 2, §5.2.12. N. Polyzotis, S. Roy, S. E. Whang, and M. Zinkevich (2018) Data lifecycle challenges in production machine learning: a survey. ACM SIGMOD Record 47 (2), p. 17–28. Cited by: item 1. M. Pooyandeh, K. Han, and I. Sohn (2022) Cybersecurity in the ai-based metaverse: a survey. Applied Sciences 12 (24), p. 12993. Cited by: §6.2.12. G. K. Rajbahadur, K. Gallaba, E. Rashno, A. Suriyawongkul, K. Bennet, K. Stewart, and A. E. Hassan (2025) Building an open aibom standard in the wild. arXiv preprint arXiv:2510.07070. Cited by: §6.2.13. P. T. Rajendran, H. Espinoza, A. Delaborde, and C. Mraidha (2021) Human-in-the-loop learning methods toward safe dl-based autonomous systems: a review. In Computer Safety, Reliability, and Security. SAFECOMP 2021 Workshops: DECSoS, MAPSOD, DepDevOps, USDAI, and WAISE, York, UK, September 7, 2021, Proceedings, Berlin, Heidelberg, p. 251–264. External Links: ISBN 978-3-030-83905-5, Link, Document Cited by: §5.1.6, §5.1. L. M. Ranjitsingh and T. S. Rao (2025) Establish legal and regulatory standards for the testing and validation of ai systems to ensure their reliability and safety in operational environments. International Journal of System Assurance Engineering and Management 16 (10), p. 3338–3353. Cited by: §6.2.4. G. Recupito, F. Pecorelli, G. Catolino, V. Lenarduzzi, D. Taibi, D. Di Nucci, and F. Palomba (2024a) Technical debt in ai-enabled systems: on the prevalence, severity, impact, and management strategies for code and architecture. Journal of Systems and Software 216, p. 112151. Cited by: §1, Table 1, §2, item 2, item 3, item 1, item 10, item 2, item 4, item 4, item 7, item 9, item 1, §5.2.1, §5.2.2, §6.2.11. G. Recupito, R. Rapacciuolo, D. Di Nucci, and F. Palomba (2024b) Unmasking data secrets: an empirical investigation into data smells and their impact on data quality. In Proceedings of the IEEE/ACM 3rd International Conference on AI Engineering-Software Engineering for AI, p. 53–63. Cited by: item 1. X. Renard, T. Laugel, and M. Detyniecki (2024) Understanding prediction discrepancies in classification. Machine Learning 113 (10), p. 7997–8026. Cited by: §6.2.18. R. Riggio, E. Coronado, N. Linder, A. Jovanka, G. Mastinu, L. Goratti, M. Rosa, H. Schotten, and M. Pistore (2021) Ai@ edge: a secure and reusable artificial intelligence platform for edge computing. In 2021 Joint European Conference on Networks and Communications & 6G Summit (EuCNC/6G Summit), p. 610–615. Cited by: §6.2.14. D. Roselli, J. Matthews, and N. Talagala (2019) Managing bias in ai. In Companion proceedings of the 2019 world wide web conference, p. 539–544. Cited by: §2, item 1, item 3, item 2, §5.2.12. G. Rossolini, A. Biondi, and G. Buttazzo (2022) Increasing the confidence of deep neural networks by coverage analysis. Vol. 49, ACM New York, NY. Cited by: §5.1.6. C. Ruland and J. Sassmannshausen (2018) Access control in safety critical environments. In 2018 12th International Conference on Reliability, Maintainability, and Safety (ICRMS), p. 223–229. Cited by: §5.2.9. W. Salhab, D. Ameyed, F. Jaafar, and H. Mcheick (2024) A systematic literature review on ai safety: identifying trends, challenges and future directions. IEEE Access. Cited by: §1, §5.1. A. Samadi, A. Shirian, K. Koufos, K. Debattista, and M. Dianati (2023) SAFE: saliency-aware counterfactual explanations for dnn-based automated driving systems. In 2023 IEEE 26th International Conference on Intelligent Transportation Systems (ITSC), p. 5655–5662. Cited by: §5.1.3. O. J. Samuel (2025) Adversarial ai the new frontier in cybersecurity threats and defenses. Journal of Science, Technology and Engineering Research 3 (1), p. 1–13. Cited by: §6.2.21. I. H. Sarker (2024) Introduction to ai-driven cybersecurity and threat intelligence. In AI-driven cybersecurity and threat intelligence: Cyber automation, intelligent decision-making and explainability, p. 3–19. Cited by: §6.2.7. D. Sas and P. Avgeriou (2023) An architectural technical debt index based on machine learning and architectural smells. IEEE Transactions on Software Engineering 49 (8), p. 4169–4195. Cited by: §2, item 1, item 1. S. Schneider, A. Saha, E. Mezzi, K. Tuma, and R. Scandariato (2024) Designing secure ai-based systems: a multi-vocal literature review. In 2024 IEEE Secure Development Conference (SecDev), p. 13–19. Cited by: §1, §6.2.14, §6.2.19, §6.2.2, §6.2.23. D. Schwartz, Y. Alparslan, and E. Kim (2020) Regularization and sparsity for adversarial robustness and stable attribution. In Advances in Visual Computing: 15th International Symposium, ISVC 2020, San Diego, CA, USA, October 5–7, 2020, Proceedings, Part I 15, p. 3–14. Cited by: §5.1.2. D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, V. Chaudhary, M. Young, J. Crespo, and D. Dennison (2015) Hidden technical debt in machine learning systems. Advances in neural information processing systems 28. Cited by: §1.1, §1, Table 1, §2, 3rd item, §3.7.1, item 1, item 2, item 1, item 10, item 2, item 3, item 5, item 6, item 7, item 2, item 4, item 6, §5.2.1, §5.2.10, §5.2. O. R. Shahin, H. H. Alshammari, R. N. Alabdali, A. M. Salaheldin, and N. Saleh (2025) Automated multi-model framework for malaria detection using deep learning and feature fusion. Scientific Reports 15 (1), p. 25672. Cited by: §6.2.19. S. Shahriar, S. Allana, S. M. Hazratifard, and R. Dara (2023) A survey of privacy risks and mitigation strategies in the artificial intelligence life cycle. IEEE Access 11, p. 61829–61854. Cited by: §6.2.17, §6.2.2, §6.2.26. Y. Shavit, S. Agarwal, M. Brundage, S. Adler, C. O’Keefe, R. Campbell, T. Lee, P. Mishkin, T. Eloundou, A. Hickey, et al. (2023) Practices for governing agentic ai systems. Research Paper, OpenAI, December. Cited by: §8. R. Sheeba, J. P. Mahto, S. S. Ansari, Z. R. Surani, P. Chinnasamy, and M. Alagarsamy (2025) Decentralized data validation for ethical ai training. In 2025 International Conference on Computational Robotics, Testing and Engineering Evaluation (ICCRTEE), p. 1–6. Cited by: §6.2.4. R. Sheh (2021) Explainable artificial intelligence requirements for safe, intelligent robots. In 2021 IEEE international conference on intelligence and safety for robotics (ISR), p. 382–387. Cited by: §5.1.1, §5.1.3, §6.1.1. V. Shejwalkar, A. Houmansadr, P. Kairouz, and D. Ramage (2022) Back to the drawing board: a critical evaluation of poisoning attacks on production federated learning. Conference paper Vol. 2022-May, p. 1354 – 1371. Note: Cited by: 192; All Open Access, Green Open Access External Links: Document, Link Cited by: §6.1.8. Y. Shi, H. Yu, and C. Leung (2023) Towards fairness-aware federated learning. IEEE Transactions on Neural Networks and Learning Systems. Cited by: §6.1.2. K. Shivashankar and A. Martini (2022) Maintainability challenges in ml: a systematic literature review. In 2022 48th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), p. 60–67. Cited by: item 1, item 2, item 10, item 3, item 1. B. Shneiderman (2020) Bridging the gap between ethics and practice: guidelines for reliable, safe, and trustworthy human-centered ai systems. ACM Transactions on Interactive Intelligent Systems (TiiS) 10 (4), p. 1–31. Cited by: §6.2.17. A. Shome, L. Cruz, and A. Van Deursen (2022) Data smells in public datasets. In Proceedings of the 1st International Conference on AI Engineering: Software Engineering for AI, p. 205–216. Cited by: item 1. R. M. Shukla and J. Cartlidge (2022) Challenges faced by industries and their potential solutions in deploying machine learning applications. In 2022 IEEE 12th Annual Computing and Communication Workshop and Conference (CCWC), p. 0119–0124. Cited by: item 1, item 3, item 3. E. I. Simon, M. Vidoni, and F. H. Fard (2023) Algorithm debt: challenges and future paths. In 2023 IEEE/ACM 2nd International Conference on AI Engineering–Software Engineering for AI (CAIN), p. 90–91. Cited by: §2, item 1. A. Simonetta and M. C. Paoletti (2024) ISO/iec standards and design of an artificial intelligence system. Cited by: §6.2.1, §6.2.10, §6.2.5, §6.2.9. P. Siriwardena (2019) Advanced api security: oauth 2.0 and beyond. Apress. Cited by: §6.2.16. D. Sklavenitis and D. Kalles (2024) Measuring technical debt in ai-based competition platforms. In Proceedings of the 13th Hellenic Conference on Artificial Intelligence, p. 1–10. Cited by: Table 1, §2. K. Sokol and P. Flach (2019) Counterfactual explanations of machine learning predictions: opportunities and challenges for ai safety. In 2019 AAAI Workshop on Artificial Intelligence Safety, SafeAI 2019, Cited by: §5.1.3. A. K. Sood and S. Zeadally (2025) Malicious ai models undermine software supply-chain security. Communications of the ACM 68 (6), p. 62–71. Cited by: §6.2.13. [192] B. Soundararajan Secure configuration management for microservices architecture. Cited by: §6.2.1. P. Spelda and V. Stritecky (2025) Security practices in ai development. AI & SOCIETY, p. 1–11. Cited by: §6.2.26, §6.2.8. K. G. Srinivasa, M. Kurni, and K. Saritha (2022) Harnessing the power of ai to education. In Learning, Teaching, and Assessment Methods for Contemporary Learners: Pedagogy for the Digital Generation, p. 311–342. External Links: ISBN 978-981-19-6734-4, Document, Link Cited by: §1. R. Srinivasan and A. Chander (2019) Understanding bias in datasets using topological data analysis.. In AISafety@ IJCAI, Cited by: §5.1.3, §5.1.4. A. Steimers and T. Bömer (2021) Sources of risk and design principles of trustworthy artificial intelligence. In International Conference on Human-Computer Interaction, p. 239–251. Cited by: §5.1.3. M. A. Sujan (2023) Looking at the safety of ai from a systems perspective: two healthcare examples. In Safety in the Digital Age: Sociotechnical Perspectives on Algorithms and Machine Learning, p. 79–90. Cited by: §5.2.12. B. Sujatha, K. A. Faraz, N. Pranathi, Ch. B. R. Saranya, and B.S.V. Chaitanya (2023) Securing data with blockchain and ai. Conference paper Vol. 2492. Note: Cited by: 1 External Links: Document, Link Cited by: §6.2.2. E. Sutoyo and A. Capiluppi (2024) SATDAUG-a balanced and augmented dataset for detecting self-admitted technical debt. In Proceedings of the 21st International Conference on Mining Software Repositories, p. 289–293. Cited by: item 3, item 1, item 1, item 1. Y. Tang, R. Khatchadourian, M. Bagherzadeh, R. Singh, A. Stewart, and A. Raja (2021) An empirical study of refactorings and technical debt in machine learning systems. In 2021 IEEE/ACM 43rd international conference on software engineering (ICSE), p. 238–250. Cited by: item 1, item 10, item 5, item 7, item 8, item 2, item 4, item 6, item 1. B. Tarchoun, A. B. Khalifa, and M. A. Mahjoub (2022) Investigating the robustness of multi-view detection to current adversarial patch threats. In 2022 6th International Conference on Advanced Technologies for Signal and Image Processing (ATSIP), p. 1–6. Cited by: §5.1.2. C. Thota, R. Sundarasekar, G. Manogaran, R. Varatharajan, and M. Priyan (2018) Centralized fog computing security platform for iot and cloud in healthcare system. In Fog computing: Breakthroughs in research and practice, p. 365–378. Cited by: §5.2.1. H. Tibebu (2024) Framework for data protection, security, and privacy in ai applications. The Broadcast Centre Here East, London. Cited by: §5.2.9. A. C. Tricco, E. Lillie, W. Zarin, K. K. O’Brien, H. Colquhoun, D. Levac, D. Moher, M. D. Peters, T. Horsley, L. Weeks, et al. (2018) PRISMA extension for scoping reviews (prisma-scr): checklist and explanation. Annals of internal medicine 169 (7), p. 467–473. External Links: Document Cited by: Table 1, §3. B. T. Tutuncuoglu (2024) Zero-downtime ai: predictive and autonomous server restoration without human input. Available at SSRN 5249062. Cited by: §6.2.20. B. Van Oort, L. Cruz, M. Aniche, and A. Van Deursen (2021) The prevalence of code smells in machine learning projects. In 2021 IEEE/ACM 1st Workshop on AI Engineering-Software Engineering for AI (WAIN), p. 1–8. Cited by: item 10, item 8. M. J. Walter, A. Barrett, and K. Tam (2024) A red teaming framework for securing ai in maritime autonomous systems. Applied Artificial Intelligence 38 (1), p. 2395750. Cited by: §6.2.8. H. Wang, C. Li, J. Jiang, X. Zhang, Y. Zhao, and W. Gong (2023a) Distribution-restrained softmax loss for the model robustness. arXiv preprint arXiv:2303.12363. Cited by: §5.1.2. X. Wang, H. Schuster, R. Borrison, and B. Kløpper (2023b) Technical debt management in industrial ml-state of practice and management model proposal. In 2023 IEEE 21st International Conference on Industrial Informatics (INDIN), p. 1–9. Cited by: item 1, item 2, item 10, item 2, item 3, item 5, item 6, item 7, item 1, item 1, item 1. X. Wang, S. Wang, P. Feng, K. Sun, S. Jajodia, S. Benchaaboun, and F. Geck (2021) Patchrnn: a deep learning-based system for security patch identification. In MILCOM 2021-2021 IEEE Military Communications Conference (MILCOM), p. 595–600. Cited by: §5.2.3. H. Washizaki, H. Uchida, F. Khomh, and Y. Gueheneuc (2019) Studying software engineering patterns for designing machine learning systems. In 2019 10th International Workshop on Empirical Software Engineering in Practice (IWESEP), p. 49–495. Cited by: Table 1, §2, item 2, item 10, item 2, item 5, item 7, item 6, item 3. B. D. Werner, B. J. Schumeg, T. M. Mills, and E. V. Velilla (2023) An assurance case for the dod ethical principles of artificial intelligence. In 2023 Annual Reliability and Maintainability Symposium (RAMS), p. 1–7. Cited by: §5.1.2. C. Wohlin (2014) Guidelines for snowballing in systematic literature studies and a replication in software engineering. In Proceedings of the 18th international conference on evaluation and assessment in software engineering, p. 1–10. Cited by: Table 1. B. Xia, T. Bi, Z. Xing, Q. Lu, and L. Zhu (2023) An empirical study on software bill of materials: where we stand and the road ahead. Conference paper p. 2630 – 2642. Note: Cited by: 37; All Open Access, Green Open Access External Links: Document, Link Cited by: §6.2.13. B. Xia (2025) Operationalising safe and responsible ai: a system level perspective. Ph.D. Thesis, UNSW Sydney. Cited by: §6.2.13. R. Ximenes, A. P. S. Alves, T. Escovedo, R. Spinola, and M. Kalinowski (2025) Investigating issues that lead to code technical debt in machine learning systems. In 2025 IEEE/ACM 4th International Conference on AI Engineering–Software Engineering for AI (CAIN), p. 173–183. Cited by: item 1, item 3, item 4. F. Xu, H. Uszkoreit, Y. Du, W. Fan, D. Zhao, and J. Zhu (2019) Explainable ai: a brief survey on history, research areas, approaches and challenges. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) 11839 LNAI, p. 563 – 574. Note: Cited by: 486 External Links: Document, Link Cited by: §5.1.1, §6.1.1. M. Yan, X. Xia, E. Shihab, D. Lo, J. Yin, and X. Yang (2018) Automating change-level self-admitted technical debt determination. IEEE Transactions on Software Engineering 45 (12), p. 1211–1229. Cited by: item 3, item 2. H. Yang, Y. Nong, S. Wang, and H. Cai (2024) Multi-language software development: issues, challenges, and solutions. IEEE Transactions on Software Engineering 50 (3), p. 512–533. Cited by: §6.2.25. H. Zhang, L. Cruz, and A. Van Deursen (2022a) Code smells for machine learning applications. In Proceedings of the 1st international conference on AI engineering: software engineering for AI, p. 217–228. Cited by: item 1, item 4. K. Zhang, X. Song, C. Zhang, and S. Yu (2022b) Challenges and future directions of secure federated learning: a survey. Frontiers of Computer Science 16 (5). Note: Cited by: 94; All Open Access, Bronze Open Access, Green Open Access External Links: Document, Link Cited by: §6.1.8. W. Zhao, S. Alwidian, and Q. H. Mahmoud (2022) Adversarial training methods for deep learning: a systematic review. Algorithms 15 (8). External Links: Link, ISSN 1999-4893, Document Cited by: §6.1.3. X. Zhao, A. Banks, J. Sharp, V. Robu, D. Flynn, M. Fisher, and X. Huang (2020) A safety framework for critical systems utilising deep neural networks. In Computer Safety, Reliability, and Security: 39th International Conference, SAFECOMP 2020, Lisbon, Portugal, September 16–18, 2020, Proceedings 39, p. 244–259. Cited by: §5.1.2, §5.1.3. X. Zhao, W. Huang, S. Schewe, Y. Dong, and X. Huang (2021) Detecting operational adversarial examples for reliable deep learning. In 2021 51st Annual IEEE/IFIP International Conference on Dependable Systems and Networks-Supplemental Volume (DSN-S), p. 5–6. Cited by: §5.1.2. L. Zhi, S. Liu, H. Dai, M. Liu, and J. Wang (2024) Algorithm for data format conversion and compatibility guarantee in technical platforms for cross platform application integration. In 2024 IEEE 4th International Conference on Data Science and Computer Application (ICDSCA), p. 893–897. Cited by: §6.2.15. F. Zhuang, Z. Qi, K. Duan, D. Xi, Y. Zhu, H. Zhu, H. Xiong, and Q. He (2021) A comprehensive survey on transfer learning. Proceedings of the IEEE 109 (1), p. 43–76. External Links: Document Cited by: §6.1.6. D. M. Ziegler, S. Nix, L. Chan, T. Bauman, P. Schmidt-Nielsen, T. Lin, A. Scherlis, N. Nabeshima, B. Weinstein-Raun, D. de Haas, B. Shlegeris, and N. Thomas (2022) Adversarial training for high-stakes reliability. In Proceedings of the 36th International Conference on Neural Information Processing Systems, NIPS ’22, Red Hook, NY, USA. External Links: ISBN 9781713871088 Cited by: §6.1.3.

Instant research discovery