Paper deep dive
Rethinking Data Quality for AI-Driven Systems: Evidence from Practitioner Interviews
Hariharan Gopinath, Jan Bosch, Helena Holmström Olsson
Intelligence
Status: not_run | Model: - | Prompt: - | Confidence: 0%
Entities (0)
Relation Signals (0)
No relation signals yet.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Data quality research has usually treated data as an input that is stored, processed, and validated. In AI-driven software-intensive systems, data also shapes model behavior, evaluation, and lawful use. Empirical evidence remains limited on how practitioners define, assess, and manage quality under these conditions. We interviewed 16 practitioners from nine organizations and analyzed the transcripts using reflexive thematic analysis and developed six themes from participants' accounts. In AI systems, traceability shifted from modular debugging to attributing model behavior, while using models as quality assessors introduced circularity. Agent context and memory became data objects, and synthetic and pseudo-labeled data made authenticity a quality concern. In foundation-model development, lawfulness became a gate for training data, while representativeness was judged through coverage of situations in which the system must behave safely. Prior ML research examines many of these problems separately. Our study provides a practitioner-grounded account of how they are encountered together as an engineering and organizational concern. We also interpret five recurring conditions as helping explain how the themes relate to reduced trust in data and AI outcomes. We synthesize these findings through lifecycle assurance: a conceptual framing focused on producing evidence that data can support a specific AI claim when its influence may be embedded in model behavior, model-based judgments, or agent actions.
Tags
Links
- Source: https://arxiv.org/abs/2609.31191v1
- Canonical: https://arxiv.org/abs/2609.31191v1
Trouble viewing inline? Open PDF directly â
Full Text
49,517 characters extracted from source content.
Expand or collapse full text
1 This is a preprint version. The final version will appear in the proceedings of PROFES 2026. arXiv:2609.31191v1 [cs.SE] 25 Sep 2026 Rethinking Data Quality for AI-Driven Systems: Evidence from Practitioner Interviews Hariharan Gopinath 1 , Jan Bosch 1,2 , and Helena Holmström Olsson 3 1 Chalmers University of Technology, Department of Computer Science and Engineering, Gothenburg, Sweden hargop@chalmers.se, jan.bosch@chalmers.se 2 Eindhoven University of Technology, Department of Mathematics and Computer Science, Eindhoven, Netherlands 3 Malmö University, Department of Computer Science and Media Technology, Malmö, Sweden helena.holmstrom.olsson@mau.se Abstract. Data quality research has usually treated data as an input that is stored, processed, and validated. In AI-driven software-intensive systems, data also shapes model behavior, evaluation, and lawful use. Empirical evidence re- mains limited on how practitioners define, assess, and manage quality under these conditions. We interviewed 16 practitioners from nine organizations and analyzed the transcripts using reflexive thematic analysis and developed six themes from participantsâ accounts. In AI systems, traceability shifted from modular debugging to attributing model behavior, while using models as quality assessors introduced circularity. Agent context and memory became data objects, and synthetic and pseudo-labeled data made authenticity a quality concern. In foundation-model development, lawfulness became a gate for training data, while representative- ness was judged through coverage of situations in which the system must behave safely. Prior ML research examines many of these problems separately. Our study provides a practitioner-grounded account of how they are encountered together as an engineering and organizational concern. We also interpret five recurring con- ditions as helping explain how the themes relate to reduced trust in data and AI outcomes. We synthesize these findings through lifecycle assurance: a conceptual framing focused on producing evidence that data can support a specific AI claim when its influence may be embedded in model behavior, model-based judgments, or agent actions. Keywords: Data quality· Data management· AI-driven systems· Data trust· Practitioner interviews 1 Introduction Data quality has long been understood as more than the absence of errors. Foundational work defines it as fitness for use: the same dataset may be adequate for one con- sumer, task, or decision and inadequate for another [25]. Traditional data management operationalizes this through dimensions such as accuracy, completeness, consistency, timeliness, accessibility, and provenance [3]. These dimensions remain important, but AI-driven software-intensive systems change how data quality affects system behavior. Rethinking Data Quality for AI-Driven Systems3 Data is no longer only stored, queried, transformed, and validated, but it is also used to train models, evaluate behavior, populate runtime context, and constrain whether a system can be lawfully released or operated. Production ML research already documents hidden data dependencies, feedback loops, and blurred system boundaries [21], as well as data work that continues from collection through monitoring [1, 18]. Weak data practices can also propagate into unreliable models and harmful outcomes [20]. These studies usually examine prove- nance, synthetic data, documentation, or governance separately. We know less about how practitioners face these concerns together while training, evaluating, deploying, and operating AI-driven systems. We therefore interviewed 16 practitioners from nine organizations working in automotive, telecom, data annotation, industrial automation, decentralized AI, and foundation-model development. The interviews addressed three research questions (RQs): RQ1. How do practitioners define and assess data quality in AI-driven systems, and how does this differ from traditional data management? RQ2. What data quality challenges do practitioners encounter across the AI develop- ment lifecycle? RQ3. How do organizational structure, technical factors, and emerging AI artifacts shape practitionersâ trust in data for AI-driven systems? In this paper, data trust means justified confidence that data are suitable for a specific AI use and that their origin, transformations, ownership, permitted use, and influence on system behavior can be examined and accounted for. It is one part of AI system trustworthiness, alongside model design, human oversight, interfaces, and organizational controls. Our analysis produced six practitioner-grounded themes showing how AI reshapes data-quality practice (Sect. 4). We interpret five foundational explanatory mechanisms that help explain how these changes weaken trust in data and AI outcomes (Sect. 5.2). We synthesize these findings as lifecycle assurance: producing artifact-specific evidence that data is fit for claims made during training, validation, certification, deployment, and agent action (Sect. 5.3). 2 Background and Related Work 2.1 Background Data quality has traditionally been understood as a purpose-dependent concept. Wang and Strong define data quality as âfitness for useâ meaning that the same data may be suitable for one consumer, task, or decision but unsuitable for another [25]. This view is broader than accuracy alone. It includes whether data is complete, timely, interpretable, accessible, and relevant to the context in which it is used. Later work on data-quality assessment similarly distinguishes measurable properties of data from user- and context- dependent judgments of quality [17]. For this study, this literature provides the baseline, as data quality is not a universal property of a dataset but a judgment about whether data can support a particular use. 4H. Gopinath et al. Traditional data-quality research also draws on provenance and governance. Prove- nance records where data originated and how it was transformed, supporting interpreta- tion and reproducibility [23]. Data governance defines decision rights and accountability for quality, access, metadata, and lifecycle management [13]. For AI-driven systems, these perspectives direct attention beyond record contents to an organizationâs ability to explain where data came from, how it changed, and who is responsible for its use. Provenance and ownership provide concepts for examining how practitioners justify trust in data. Our study investigates how this concern extends from data records to model behavior. Machine learning complicates this account because data enters system behavior instead of remaining stored, queried, or reported. Research on technical debt shows that ML systems create hidden data dependencies, feedback loops, unstable boundaries, and downstream consumers that may be difficult to anticipate [21]. Production ML research also places data work throughout collection, cleaning, labeling, feature prepa- ration, training, testing, deployment, and monitoring [18]. Data quality is consequently a lifecycle concern: decisions made upstream can later affect model behavior, evaluation results, and operational reliability. 2.2 Related Work Empirical studies of AI development show that data problems propagate. Sambasivan et al. describe "data cascades" in high-stakes AI, where undervalued data work produces downstream model failures [20]. Their study examines poor data practices and their consequences. We ask how practitioners define, assess, and trust data quality across end- to-end, foundation-model, and agentic systems. Data-centric AI argues that improving AI systems requires systematic attention to data, not only model architecture [26]. Datasheets for Datasets, likewise, makes composition, collection, and intended use explicit [8]. We extend this evidence-based view beyond source datasets to pseudo- labels, synthetic data, model judgments, agent context, and legal provenance. Qian et al.âs interviews with ten dataset practitioners in one organization found that quality was a priority but lacked a shared definition and was often assessed through ad hoc inspection [19]. Further, LLM-as-a-judge research shows that model-based evaluators carry their own biases [27], recursive training degrades models trained on their own output [22], and provenance audits find licensing hard to establish at training-data scale [15]. Prior work documents these problems individually, but less is known about how practitioners encounter and connect them as a data-quality and trust problem across the AI lifecycle. We address this gap through an integrated practitioner account and synthesize the findings as lifecycle assurance: producing evidence that data artifacts are fit for the specific AI claims they support. 3 Research Method We conducted an exploratory interview study with 16 practitioners from nine organi- zations involved in AI development, deployment, or data provision. We used purposive Rethinking Data Quality for AI-Driven Systems5 Table 1. Participants by domain area (16 participants across nine organizations) Domain areaParticipants IDs Automotive and safety-critical AII01 - I07, I12, I13 Telecom and network systemsI08 - I10 Cross-industry AI, data services, and foundation modelsI11, I15, I16 Industrial automationI14 Roles across the sample: technical experts and senior technical leaders, deep learning and ML engineers, data and pipeline engineers, data and AI architects, researchers and research managers, a product owner, a quality lead, a data manager, a data expert, and an AI consultant. sampling to recruit information-rich participants with direct experience of AI develop- ment, deployment, or data provision, and complemented this with snowball sampling through participant and professional network referrals [16]. The sample was designed to capture different organizational relationships with AI, including organizations that train and deploy their own models, organizations that provide data or annotation services, and organizations applying foundation models in enterprise settings. Participants are anonymized as I01-I16 and their nine organizations are grouped into four domain areas in Table 1. The sample was intentionally weighted toward safety-critical perception-and-control AI development, where autonomous driving makes data quality especially demanding. To broaden the empirical basis, we added participants working on foundation models, decentralized and federated AI, large-scale data services, industrial automation, and consultancy. 3.1 Data Collection The interviews were conducted between April 2026 and June 2026 in English, either through Microsoft Teams or on site at participating organizations. With participantsâ consent, all interviews were audio-recorded. Before each interview, participants were in- formed that their names, organizations, and personal information would be anonymized in research outputs. Audio recordings and full transcripts other than supplementary ma- terial would not be shared or used for purposes beyond this study. Each interview lasted between 45 and 60 minutes and was semi-structured. The interview guide was designed around the three research questions discussed in Section 1. Semi-structured interviews were appropriate because they provided a common structure across participants while allowing follow-up questions and concrete examples from participantsâ own work [11]. Interview recordings were transcribed using a locally installed version of Whis- perX [2] on the first authorâs computer. The recordings were not uploaded to or processed by external AI services. WhisperX generated the initial transcripts, aligned words with the audio, performed speaker diarization, and exported speaker-labeled transcripts with timestamps. The first author then reviewed each transcript against the original audio and manually corrected transcription errors, especially domain-specific terms and phrases where mistakes changed the meaning. During transcription and analysis, AI was used 6H. Gopinath et al. only for transcription and speaker separation. Coding, theme construction, cross-theme interpretation, and analytical writing were performed by the authors. 3.2 Data Analysis We analyzed the transcripts using reflexive thematic analysis (RTA), following Braun and Clarkeâs six-phase approach [5]. RTA suited this exploratory study because it allowed us to examine how practitioners define, assess, and manage data quality in AI-driven systems without imposing predefined data-quality categories. First, in familiarization, the first author read the transcripts repeatedly and wrote analytical notes on recurring concerns, contradictions, and concrete examples. Second, generating initial codes, rele- vant transcript segments were coded inductively in Taguette, capturing how practitioners described and assessed data quality across the AI lifecycle. For instance, extracts such as "no reasoning trace" and "pixel to torque" were coded as behavior-level attribution collapse. Third, searching for themes, related codes were consolidated and grouped into candidate themes by comparing patterns across participants, organizations, and lifecycle stages. The code above, with related ones, formed the candidate theme "Behavior-Level Traceability". Fourth, reviewing themes, the candidate themes were checked against the coded extracts and the full dataset, and codes were merged, separated, or repositioned when they described different aspects of the same issue. Fifth, defining and naming themes: each theme was named to capture its analytical meaning rather than only its topic, and the sixth phase, producing the report, presents them in Section 4. After constructing the six themes, we compared patterns across them in a second interpretive step. This analysis identified five foundational explanatory mechanisms that helped us interpret why several themes recurred and how they related to practitionersâ accounts of diminished trust. For instance, the attribution problems in Theme 1, such as "pixel to torque" and the absence of a reasoning trace, and the coverage gaps that became driving behavior in Theme 6 share an underlying condition that data does not remain an inspectable input but is absorbed into model behavior. We consolidated this condition as F3. This cross-theme analysis resulted in the five foundational explanatory mechanisms (F1-F5) presented in Section 5.2. These are not additional themes but second-order explanations that connect the six themes and support the model in Figure 1. The analysis followed the chain: quoteâ initial codeâ consolidated codeâ themeâ explanatory mechanism We created a supplementary evidence table to keep the path from the empirical material to our interpretations visible. It links quote and participant IDs to initial codes, consolidated codes, themes, and explanatory mechanisms. The six themes draw on 45 quote-level extracts, including one used for two themes. The five mechanisms draw on 15 additional extracts and seven also used for themes. These counts document analytical grounding, not frequency. The full anonymized table is available on Zenodo 4 . Following reflexive thematic analysis, we treated coding as interpretive and did not calculate inter- coder agreement. 4 https://doi.org/10.5281/zenodo.22901446 Rethinking Data Quality for AI-Driven Systems7 4 Findings The thematic analysis produced six themes (T) through inductive coding. Rather than mapping directly onto individual research questions, the themes collectively inform all three, and we draw them together to answer each research question in Section 5. T1: Behavior-Level Traceability The shift: Participants traced model behavior back through the data and pipeline that produced it. In traditional systems, traceability connects requirements, code, transformations, tests, and defects [6], and lineage tracks records through pipelines [23]. In end-to-end AI systems, practitioners also trace behaviors and autonomous actions back through model versions, training data distributions, source data, and labels. One participant (I12) contrasted modular pipelines, where perception, planning, and control had clear interfaces, with end-to-end models that are far harder to debug. A model may learn correlations rather than causal relations, associating a red light with forward movement or acquiring a driving bias from an imbalanced training mix, consistent with causal misidentification in imitation learning [9] and findings that hidden dataset biases can be absorbed into end-to-end driving behavior [28]. Because such models offer no reasoning trace and are, in the participantâs words, "just a bunch of tensors" (I12), diagnosis depends on experimentation and A/B testing. Others described the same collapse. One called it a "pixel to torque" problem (I01): when a vehicle acts incorrectly, it is hard to know whether pixels, training data, or model internals caused it. As end-to-end boundaries expand, "the notion of data gets diluted" (I06), and even ground truth becomes behavioral, since teams must judge whether recorded human driving was good behavior to learn (I13). This makes lineage central: practitioners need to trace from "decision to model to data" (I10), because "any data without lineage is not trustable" (I07). Failures are not untraceable, but attribution becomes costly and indirect. Part of the difficulty is organizational, as teams own individual sources, models, or checks, while no role owns the chain connecting them, so a defect can cross several correct-looking stages before it surfaces (I03, I04). While ML research treats causal confusion and dataset bias as technical phenomena, our findings show practitioners experiencing them as an organizational traceability problem, where the unit of traceability expands from data records to model behavior. T2: Models as Data-Quality Judges The shift: Participants used models to assess training data when rules and human review did not scale, introducing circularity. Assessment still relies on rule-based checks, sampling, and human review [17, 25]. In annotation-heavy automotive pipelines, manual inspection persists because some defects escape automated checks. For example, if a road-lane marking is placed incorrectly in lidar point-cloud data, the error "cannot be checked by the sanity check script," yet there is "no way to check every one of them" (I05). Because manual review does not scale, the same engineer turned the model into the assessor. After training an initial model, 8H. Gopinath et al. the team runs inference over all data and treats an unusually high loss as a signal that "actually the annotation of this specific sequence is wrong," reworking those sequences before the next cycle (I05). This surfaces mislabeled data at a scale no human review could reach, but it is circular. The judging model was trained on annotations of the same kind and inherits their blind spots, and a defect it was never taught to recognize passes silently back into training. Another participant named the pattern "model as an assessor, model as a judge" (I01). The circularity deepens when the assessorâs own data is model-generated, creating what one participant called "an infinite loop of models training on their own data" that severs external ground truth (I15). Practitioners therefore insisted that "we cannot automate everything" and that human "check and balance" remains essential (I11). The question "Is my data good?" becomes "Is my checkerâs data good?" The ML literature documents related risks such as self-preference and biases in model-based evaluation [27]. Our contribution is the organizational view: assurance adopted out of necessity can create a recursive accountability gap that is absent when validation remains external to the model. T3: Agent Context and Memory as a New Data Object The shift: Participants treated retrieved context and retained memory as part of the agentâs operational data layer. Access control, retention, and governance are familiar enterprise problems [13]. With agentic systems, data is also retrieved into context, retained in memory, reused, and acted upon, so context and memory become quality objects in their own right. A senior AI lead (I08) framed the precondition: organizational data must be exposed "over an API in structured data" so "agents can consume it." Governance then becomes a real-time problem, since manual access approval "didnât work before, but it certainly doesnât work going forward" (I08), raising the question of who is accountable when agents act on behalf of people. A data and AI architect (I10) made the failure mode concrete. As an agent writes new context on top of old, it produces "a new silo" that "was not factored in before in the whole production life cycle". That memory can be corrupted, as when a coding agentâs memory became "infiltrated" and the agent responded strangely until the memory was cleared and the codebase reloaded (I10). The defect lives in accumulated operational context, not in any source dataset, and silently changes decisions. Another participant distrusted agentic outputs simply because "I donât know where it comes from" (I16). We report this theme as emergent rather than saturated as only three participants discussed agent memory in depth, as agentic systems were still emerging in the par- ticipating organizations. One participant noted some data problems are unchanged in principle by AI (I08), and the researchers are beginning to govern agent memory tech- nically [14, 24]. Practitioners report the organizational gap, that no role owns this layer, leaving provenance, freshness, and contamination unmanaged. Rethinking Data Quality for AI-Driven Systems9 T4: Authenticity of Generated Data The shift: Whether data was observed or generated now affects whether it is fit for a particular use. Traditional frameworks asked whether derived data was accurate, representative, and fit for purpose [25]. In AI-driven systems, models generate, annotate, and recycle data at scale, so data may be synthetic, pseudo-labeled, model-generated, or human- verified, and authenticity becomes a practical dimension: was the data observed from the world or produced by a model, and is that authentic enough for its lifecycle role? A decentralized-AI participant illustrated this limitation with a classification example (I11). When synthetic data is generated from only a few real samples, âeverything that is synthetic is aroundâ those samples. If the real points occupy only one region of the space, the synthetic points also cluster there and fail to âcover the boundariesâ between classes. The dataset therefore appears larger, but the decision boundary remains weakly observed. Related concerns appeared in foundation-model pseudo-annotation, where âthe majorityâ of labels only needs to be good enough (I05), and in doubts about whether neural-rendered data captures real conditions (I06). For foundation-model training, AI- generated text was described as ânot authentic data,â or at best âsilver data,â creating âan infinite loop of models training on their own dataâ (I15), consistent with "model collapse" [22]. The contrasting cases qualify the concern. One participant trusted synthetic depth more than measured outdoor depth because real estimates were unreliable, while syn- thetic scenes were âgenerated perfectlyâ (I09). Another used artificial scenarios to cover rare cases that would be difficult to observe in practice (I04). These accounts show that accuracy alone is not the binding constraint; coverage, authenticity, and governance are. Practitioners therefore treat authenticity and provenance as operational, stage-specific quality dimensions, with different acceptance thresholds for training and validation data (I01). T5: Lawful Governance and Data Rights as a Training-Data Gate The shift: In foundation-model work, lawfulness became an acceptance criterion for data entering the training pipeline. Legal compliance, licensing, privacy, and provenance have long shaped how data can be stored, shared, and processed [13, 23]. In foundation-model development, however, lawfulness becomes part of data quality itself. A dataset may be technically useful but still unacceptable for training if its copyright, license, opt-out, or personal-data status is unclear. One participant linked quality directly to data acceptance: quality required âlawful contentâ with permissive licenses or explicit contracts because âwe only include in our LLM data that has checked all these boxesâ (I15). The challenge is operationalizing this at scale; the same participant described âthe impossibility of knowing what is legal data and whatâs illegal dataâ as a blocker that can paralyze the system (I15). A second participant made unlearning concrete (I11). Under GDPR a person can demand deletion, but deleting the record does not remove its influence on a trained model. They illustrated this with a linear regression: removing one personâs point still leaves a line that interpolates and predicts that personâs information, so a court could 10H. Gopinath et al. ask why the system still predicts deleted data, which is why they argued for "provable unlearning processes" (I11). In safety-critical settings, "quality and legal is the same" (I02). These concerns map onto the EU AI Act [7], contested copyright in training data [10], and machine unlearning [4]. Most evident in foundation-model and agent contexts, lawfulness was treated as a pipeline acceptance criterion, while automotive participants prioritized calibration and representativeness over GDPR. T6: Representativeness as Behavioral Coverage The shift: Participants treated representativeness as coverage of situations in which the system must behave safely. Traditionally, representativeness asks whether data reflects the population of in- terest [25]. In safety-critical AI it becomes behavioral coverage: the model must act correctly in situations that are rare, underrepresented, or structurally absent, a concern central to the safety-of-the-intended-functionality standard [12]. A fleet-analytics prod- uct owner made this concrete through crash data (I04). The most important crashes are high-severity events, and in exactly those events the data-collection hardware in- side the vehicle is destroyed on impact, so the data is never recorded. The team can examine 10,000 crashes and believe it understands crashes, then realize it is "lacking the 10% most important crashes, which is 95% of the fatal accidents" (I04). The dataset looks trustworthy and high-quality while systematically missing the cases that matter most. This is not ordinary under-sampling, since the missing data is structurally non- collectable by the system itself. The risk compounds when gaps become behaviors. An imbalanced regional composition in the training data surfaced as a directional bias in model behavior rather than staying a dataset property (I12). Another participant framed the epistemic limit as "we collect data about the real world, but we donât collect the real world," warning that "edge cases are drowned in the signal of the average" (I14). Rep- resentativeness in AI is therefore less about population descriptiveness in the abstract and more about whether the model has been exposed to the conditions under which it must behave safely, extending safety engineeringâs coverage concern into everyday data-quality practice. Across all six themes, practitioners repeatedly described conditions that can weaken confidence in data whenever they could no longer explain how data influenced model behavior, who owned it, or whether it remained appropriate for its intended use. Section 5 develops our interpretation of this connection between data quality and trust. 5 Discussion 5.1 What AI Changes About Data Quality This section addresses the three research questions by interpreting the six themes and relating them to prior work. Rather than restating the findings, we draw out their cross- theme implications. Table 2 summarizes how the themes map to each research question. For RQ1, practitioners evaluated data quality as fitness for a specific AI claim rather than against a universal checklist. While classic frameworks define quality as fitness for Rethinking Data Quality for AI-Driven Systems11 Table 2. Mapping research questions to themes (T) and foundational mechanisms (F) RQ Analytical mapping RQ1 Definition and assessment: from generic quality dimensions to fitness for a specific AI claim (T1, T4, T5, T6) RQ2 Lifecycle stages: collection and preprocessing (T1, T6); annotation and training (T2, T4); validation (T6); deployment and operation (T2, T3, T5) RQ3 Trust layers: ownership (F5); traceability (T1); governance of AI data artifacts (T2âT5) use relative to a consumer and task [17, 25], our findings show that AI shifts this judgment to the lifecycle claim the data supports and the evidence available to justify it. Traditional dimensions such as accuracy and completeness [3] therefore remain necessary, but their interpretation changes once data is embedded in model behavior, assessed by models, or constrained by legal rights. Rather than replacing established dimensions, AI extends them into lifecycle assurance. For RQ2, practitioners described data-quality problems that propagate through the AI lifecycle and change form along the way. Defects introduced during collection or pre- processing later reappear as behavioral errors, weak validation confidence, or reduced trust after being mediated by models, synthetic data, or automated quality checks. This interpretation is consistent with data cascades in high-stakes AI [20] and hidden techni- cal debt in production ML [21], while extending both. Whereas prior work emphasizes neglected data practices or technical dependencies, our participants described propa- gation even in mature development environments because defects become increasingly difficult to attribute once absorbed into model behavior and AI-generated artifacts. For RQ3, practitioners described trust as depending on ownership, traceability, and governance across the AI lifecycle. Confidence weakened when practitioners could not identify who was responsible for data quality, how data had been transformed, how it shaped model behavior, or whether its use was permitted. Evidence came from collapsed traceability in end-to-end AI, uncertain authenticity in synthetic or pseudo-labeled data, legal provenance and unlearning concerns, agent context and memory, and missing rare but critical cases. This extends data governance [13] and provenance [23] by showing that AI trust requires governing datasets and AI-specific data artifacts. Taken together, these findings suggest that AI-driven systems shift data quality from a property of datasets to a problem of lifecycle assurance: producing and maintaining evidence that data artifacts are authentic, representative, lawful, traceable, and fit for the AI claims they support. 5.2 Why the Themes Recur: Five Foundational Explanatory Mechanisms Looking across the six themes, we observed recurring patterns that we interpreted as reflecting a smaller set of underlying conditions. A second-order interpretation across themes resulted in the five foundational explanatory mechanisms (F1-F5) shown in Fig. 1. F1. Data reused beyond its original purpose (the data axis): Data collected for one operational purpose is later used for AI it was never specified for, so its quality was 12H. Gopinath et al. F1. Data reused beyond original purpose F2. AI scale exceeds human inspection F3. Models absorb data into behavior F4. AI systems create new data artifacts F5. Organizational ownership fragmented T6. Representativeness as Behavioral Coverage T4. Authenticity of Generated Data T2. Models as Data- Quality Judges T1. Behavior- Level Traceability T3. Agent Context and Memory as a New Data Object T5. Lawful Governance and Data Rights as a Training-Data Gate Reduced trust in AI data and outputs Fig. 1. Five foundational explanatory mechanisms connect the six AI data quality themes to reduced trust in AI data and outputs. Arrows denote interpretive analytical links identified in the interview data, not causal claims. never defined against the new use. Participants described data that "was not created for how we use it" (I16) and that carries different quality requirements across consumers (I10). This is the mismatch that dataset documentation aims to prevent [8], and it drives representativeness gaps (T6) and the turn to synthetic substitutes (T4). F2. AI scale exceeds human inspection (the volume axis): The volume and modal- ity of training data make exhaustive checking infeasible, so practitioners sample rather than inspect (I05), echoing the ad hoc inspection reported among dataset practition- ers [19]. The gap pushes toward automated alternatives, driving models as assessors (T2) and pseudo-labeled or synthetic data (T4). F3. Models absorb data into behavior (the model architecture axis): Data does not remain an external input. It becomes learned behavior, and end-to-end architectures dissolve the boundaries that once supported debugging, the erosion anticipated by work on hidden technical debt [21, 28]. As Theme 1 showed, defects surface as learned behav- ior rather than inspectable dataset errors (I01, I12). This collapses modular traceability into behavior-level attribution (T1) and turns representativeness gaps into behavioral coverage risks(T6). F4. AI systems create new data artifacts (the new-artifacts axis): AI-driven sys- tems introduce data objects produced, judged, or reused by the system itself. These in- clude agent context and memory (I10), model-based data assessment (I01), AI-generated training data (I15), and training data whose lawful use or removal must be demonstrated (I15, I11). Prior work studies these issues separately, such as judge bias, model collapse, and memory governance [14, 22, 27]. In our findings, they converge as one assurance problem, explaining why agent context becomes a quality object (T3), models become data-quality assessors (T2), and lawful trainability becomes a quality gate (T5). F5. Organizational ownership of data quality is fragmented (the organizational axis): Responsibility for data quality was distributed across sources, transformations, models, and checks, but rarely owned end-to-end. Teams could explain their local stage, Rethinking Data Quality for AI-Driven Systems13 while the evidence chain connecting stages often remained no oneâs responsibility (I03, I04). Data governance defines decision rights and accountabilities for data [13], but our findings suggest that in AI systems these accountabilities can stop at handoffs. This matters because data defects propagate into model behavior, automated checks, and agent actions. Fragmented ownership therefore helps explain traceability loss (T1), circular model-based checking (T2), and unmanaged agent context (T3). Together, the five mechanisms explain why the themes converge on reduced trust (Fig. 1). Each breaks a different link in the evidence chain: reuse and model absorption obscure lineage (F1, F3), scale limits verification (F2), new AI-generated artifacts es- cape existing governance (F4), and fragmented ownership leaves the chain without an accountable owner (F5). Because trust in AI data depends on accountable links between sources, transformations, behavior, permitted use, and ownership, each mechanism can weaken it. 5.3 Implications: Lifecycle Assurance as Evidence Infrastructure Across the findings, practitionersâ trust weakened whenever they could not connect data to its resulting behavior, ownership, and permitted use. This suggests that data quality can no longer be understood as a property of stored datasets alone. As data becomes embedded in model behavior, assessed by models, and reused through agent context, we synthesize these findings as lifecycle assurance: a conceptual framing in which each data artifact carries the evidence needed to justify the AI claim it supports. Figure 2 summarizes this synthesis by organizing the artifacts described by participants into five lifecycle layers and the evidence associated with each. Because AI-generated artifacts such as synthetic data and model judgments re-enter earlier stages, assurance must also account for data produced by the system itself. The runtime layer extends the emerging agentic contexts described by participants. Our findings suggest three implications. First, data management should move from generic quality dimensions to claim-specific assurance. Fitness for use ties quality to a consumer and a task [25], and our findings narrow it to the claim. A data artifact is not high quality in general but fit for a particular use, such as training, validation, lawful pre-training, or agent action. The question becomes what claim the data supports and what evidence justifies that use. Second, our findings suggest authenticity and provenance should be treated as first- class metadata. Whether data is observed, synthetic, pseudo-labeled, model-judged, or human-verified determines where it can be trusted and legitimately used. Dataset documentation already treats source datasets this way [8]. We extend the obligation to every artifact in Figure 2. Provenance audits show such evidence cannot be assumed at scale [15], and regulation increasingly requires it [7]. Recording origin, verification level, lawful use, freshness, and coverage exposes uncertainty rather than hiding it. Third, accountability should follow the data-model-decision chain, the traceabil- ity path Figure 2 draws from decision back to collection context. Data governance assigns decision rights for quality and access [13], but those rights stop at stage boundaries, which practitioners experienced as fragmented ownership (F5). Organizations may ben- efit from owning not only individual datasets but also the evidence chain linking them to 14H. Gopinath et al. Data Artifacts Requiring Assurance Evidence Assurance objective: Can practitioners trace data to behavior, ownership, and permitted use? Source and collection artifacts Prepared and derived artifacts Model and assessment artifacts Runtime and agent artifacts System behavior and decisions 1 2 3 4 5 Sensor data, lidar points, images, logs. Known gaps: structurally non- collectable cases. Annotations and ground truth; pseudo-labels; synthetic data; train/validation slices. Training data version; model version; model judgments (model-as-judge); evaluation results. Retrieval results; context window; agent memory; tool outputs; action logs. Driving behavior, agent action, operational decision. Defects surface as behavior. Assurance evidence Evidence is attached to each artifact according to its role and claim. Provenance/lineage origin and transformations Owner Accountability Authenticity Observed, synthetic, pseudo-labeled Coverage Missing and included situations Legal rights / purpose Permitted use Freshness Validity of the data Checks / verification Human or automated review Lifecycle claim Training, validation, release, agent action System - generated data (synthetic, model judged) re - enters earlier stages Behavior-level traceability: Decisionâ Model â Data â Collection context Fig. 2. Data artifacts and assurance evidence in AI-driven systems: a conceptual model synthesized from the interview findings. Each artifact should be linked to evidence matched to the lifecycle claim it supports, and system-generated artifacts re-enter earlier stages. model behavior and system decisions. Together, these implications frame AI data man- agement as evidence infrastructure: the capability to produce, maintain, and connect evidence about data artifacts across the lifecycle. Its value is not removing uncertainty but managing it, so that data is trusted only within the claims it can support. 6 Threats to Validity This qualitative study seeks analytical rather than statistical generalization. The sam- ple is weighted toward automotive, which may limit transferability to other domains, although this focus provided access to mature data practices in safety-critical settings. Recruitment through professional networks and participant referrals may also have fa- vored practitioners with similar backgrounds. The first author conducted the coding. Consistent with reflexive thematic analysis, we treated coding as interpretive and sup- ported reflexivity through analytical notes, repeated comparison with the full dataset, and discussion among the authors rather than calculating inter-coder agreement. Whis- perX transcripts could contain errors, but each transcript was manually checked against the original audio. Finally, lifecycle assurance is an interpretive framing derived from this study and requires further evaluation across organizations and domains. Rethinking Data Quality for AI-Driven Systems15 7 Conclusion This study examined how 16 practitioners across nine organizations define, assess, and manage data quality in AI-driven software-intensive systems. We identified six themes showing that data quality extends beyond dataset correctness to include behavior- level traceability, model-mediated assessment, agent context, authenticity, lawfulness, and behavioral coverage. We further synthesized these themes into five foundational explanatory mechanisms that help account for weakened trust. Our central contribution is a practitioner-grounded framing of data quality as lifecycle assurance, where data quality depends on producing and maintaining evidence that data artifacts are fit for the AI claims they support. Rather than eliminating uncertainty, lifecycle assurance makes uncertainty explicit, reviewable, and accountable across the data-model-decision chain. Our findings suggest that, in AI-driven systems, managing data quality increasingly requires managing the evidence that justifies how data is used, transformed, and trusted throughout the lifecycle. Future work should evaluate the lifecycle-assurance framing in industrial case studies, investigate how artifact-level assurance evidence can be operationalized in development pipelines, and examine whether it improves data trust and AI outcomes across different application domains. Declaration of AI-assisted technologies in the writing process: The first author used QuillBot for grammatical correction. All suggestions were reviewed and revised by the first author, who takes full responsibility for the final content. Acknowledgments. We would like to thank the Software Center companies for partly funding this research. Disclosure of Interests. The authors have no competing interests to declare that are relevant to the content of this article. References 1. Amershi, S., Begel, A., Bird, C., DeLine, R., Gall, H., Kamar, E., Nagappan, N., Nushi, B., Zimmermann, T.: Software engineering for machine learning: A case study. In: 2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP). p. 291â300 (2019). https://doi.org/10.1109/ICSE-SEIP.2019.00042 2. Bain, M., Huh, J., Han, T., Zisserman, A.: Whisperx: Time-accurate speech transcription of long-form audio. In: Interspeech (2023), https://api.semanticscholar.org/CorpusID:257255343 3. Batini, C., Cappiello, C., Francalanci, C., Maurino, A.: Methodologies for data quality assessment and improvement. ACM Comput. Surv. 41(3) (Jul 2009). https://doi.org/10.1145/1541880.1541883 4. Bourtoule, L., Chandrasekaran, V., Choquette-Choo, C.A., Jia, H., Travers, A., Zhang, B., Lie, D., Papernot, N.: Machine Unlearning. In: 2021 IEEE Symposium on Security and Privacy (SP). p. 141â159 (2021). https://doi.org/10.1109/SP40001.2021.00019 5. Braun, V., Clarke, V.: Using thematic analysis in psychology. Qualitative Research in Psy- chology 3(2), 77â101 (2006). https://doi.org/10.1191/1478088706qp063oa 16H. Gopinath et al. 6. Cleland-Huang, J., Gotel, O.C.Z., Huffman Hayes, J., MĂ€der, P., Zisman, A.: Software trace- ability: trends and future directions. In: Future of Software Engineering Proceedings. p. 55â69. FOSE 2014, Association for Computing Machinery, New York, NY, USA (2014). https://doi.org/10.1145/2593882.2593891 7. European Parliament and Council of the European Union: Regulation (EU) 2024/1689 (Ar- tificial Intelligence Act). Official Journal of the European Union (2024), article 10 8. Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J.W., Wallach, H., I, H.D., Crawford, K.: Datasheets for datasets. Commun. ACM 64(12), 86â92 (Nov 2021), https://doi.org/10.1145/3458723 9. de Haan, P., Jayaraman, D., Levine, S.: Causal confusion in imitation learning. Curran Associates Inc., Red Hook, NY, USA (2019) 10. Henderson, P., Li, X., Jurafsky, D., Hashimoto, T., Lemley, M., Liang, P.: Foundation models and fair use. SSRN Electronic Journal (01 2023). https://doi.org/10.2139/ssrn.4404340 11. Hove, S., Anda, B.: Experiences from conducting semi-structured interviews in empirical software engineering research. In: 11th IEEE International Software Metrics Symposium (METRICSâ05). p. 10 p.â23 (2005). https://doi.org/10.1109/METRICS.2005.24 12. International Organization for Standardization: ISO 21448:2022 Road vehicles - Safety of the intended functionality (SOTIF). Standard (2022), https://w.iso.org/standard/77490.html, ISO 21448:2022 13. Khatri, V., Brown, C.V.: Designing data governance. Commun. ACM 53(1), 148â152 (Jan 2010), https://doi.org/10.1145/1629175.1629210 14. Lin, Z., Hao, X., Fu, R., Cui, S., Chen, K., Li, C., Li, Z., Xiong, F.: A survey on long-term memory security in LLM agents: Attacks, defenses, and governance across the memory lifecycle (2026), https://api.semanticscholar.org/CorpusID:287618401 15. Longpre, S., Mahari, R., Chen, A., Obeng-Marnu, N., Sileo, D., Brannon, W., Muennighoff, N., Khazam, N., Kabbara, J., Perisetla, K., Wu, X., Shippole, E., Bollacker, K., Wu, T., Villa, L., Pentland, S., Hooker, S.: A large-scale audit of dataset licensing and attribution in AI. Nature Machine Intelligence 6(8), 975â987 (8 2024), https://doi.org/10.1038/s42256-024- 00878-8 16. Palinkas, L., Horwitz, S., Green, C., Wisdom, J., Duan, N., Hoagwood, K.: Purposeful sam- pling for qualitative data collection and analysis in mixed method implementation research. Administration and policy in mental health 42 (11 2013). https://doi.org/10.1007/s10488- 013-0528-y 17. Pipino, L.L., Lee, Y.W., Wang, R.Y.: Data quality assessment. Commun. ACM 45(4), 211â218 (Apr 2002), https://doi.org/10.1145/505248.506010 18. Polyzotis, N., Roy, S., Whang, S.E., Zinkevich, M.: Data management challenges in production machine learning. In: Proceedings of the 2017 ACM International Conference on Management of Data. p. 1723â1726. SIGMOD â17, Association for Computing Machinery, New York, NY, USA (2017). https://doi.org/10.1145/3035918.3054782 19. Qian, C., Reif, E., Kahng, M.: Understanding the dataset practitioners behind large language models. In: Extended Abstracts of the CHI Conference on Human Factors in Computing Systems. CHI EA â24, Association for Computing Machinery, New York, NY, USA (2024). https://doi.org/10.1145/3613905.3651007 20. Sambasivan, N., Kapania, S., Highfill, H., Akrong, D., Paritosh, P., Aroyo, L.M.: âev- eryone wants to do the model work, not the data workâ: Data cascades in high-stakes ai. In: Proceedings of the 2021 CHI Conference on Human Factors in Computing Sys- tems. CHI â21, Association for Computing Machinery, New York, NY, USA (2021). https://doi.org/10.1145/3411764.3445518 21. Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.F., Dennison, D.: Hidden technical debt in machine learning systems. In: Rethinking Data Quality for AI-Driven Systems17 Proceedings of the 29th International Conference on Neural Information Processing Systems - Volume 2. p. 2503â2511. MIT Press (2015) 22. Shumailov, I., Shumaylov, Z., Zhao, Y., Papernot, N., Anderson, R., Gal, Y.: AI mod- els collapse when trained on recursively generated data. Nature 631, 755â759 (07 2024). https://doi.org/10.1038/s41586-024-07566-y 23. Simmhan, Y.L., Plale, B., Gannon, D.: A survey of data provenance in e-science. SIGMOD Rec. 34(3), 31â36 (Sep 2005). https://doi.org/10.1145/1084805.1084812 24. Sumers, T.R., Yao, S., Narasimhan, K., Griffiths, T.L.: Cognitive archi- tectures for language agents. Trans. Mach. Learn. Res. 2024 (2023), https://api.semanticscholar.org/CorpusID:261556862 25. Wang, R.Y., Strong, D.M.: Beyond accuracy: what data quality means to data consumers. J. Manage. Inf. Syst. 12(4), 5â33 (Mar 1996). https://doi.org/10.1080/07421222.1996.11518099 26. Zha, D., Bhat, Z.P., Lai, K.H., Yang, F., Jiang, Z., Zhong, S., Hu, X.: Data-centric artificial in- telligence: A survey. ACM Comput. Surv. 57(5) (Jan 2025), https://doi.org/10.1145/3711118 27. Zheng, L., Chiang, W.L., Sheng, Y., Zhuang, S., Wu, Z., Zhuang, Y., Lin, Z., Li, Z., Li, D., Xing, E.P., Zhang, H., Gonzalez, J.E., Stoica, I.: Judging LLM-as-a-judge with MT-bench and Chatbot Arena. In: Proceedings of the 37th International Conference on Neural Information Processing Systems. NIPS â23, Curran Associates Inc. (2023) 28. Zimmerlin, J., Beisswenger, J., Jaeger, B., Geiger, A., Chitta, K.: Hidden biases of end-to-end driving datasets. ArXiv (2024), https://api.semanticscholar.org/CorpusID:274656126