11. AI Systems Engineering, Data-Centric AI, and MLOps

Introduction and Context

A machine-learning model is not a production AI system. A model is an artifact that maps inputs to outputs under assumptions about data, operating conditions, latency, users, and decision costs. A production AI system includes the data-generating process, collection mechanisms, storage, feature computation, training infrastructure, deployment environment, monitoring, governance, security controls, and procedures for responding to failure. The central concern of AI systems engineering is therefore the reliable transformation of data into governed, useful, and maintainable decisions.

Traditional software engineering emphasizes source code, deterministic tests, release management, and operational reliability. Machine-learning systems add a second changing component: the learned behavior of the model. Changes in the data distribution, labeling policy, user population, upstream systems, or business objective can alter performance even when the application code is unchanged. MLOps addresses this problem by extending DevOps principles—automation, reproducibility, version control, continuous integration, delivery, and monitoring—to the complete machine-learning lifecycle.

Data-centric AI complements this perspective. Rather than treating model architecture as the primary route to improvement, data-centric practice treats data quality, coverage, labeling consistency, provenance, and representativeness as engineering objects. In many industrial settings, a modest model trained on dependable data is more valuable than a sophisticated model trained on unstable or biased data.

At doctoral level, the topic must be understood as socio-technical systems engineering. Technical architecture interacts with organizational incentives, human oversight, regulation, economics, and social consequences. A highly accurate model may still be unsuitable if its predictions cannot be explained, its latency is unacceptable, its operating cost is excessive, or its errors are distributed unfairly.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Distinguish a machine-learning model from a production AI system and explain the role of MLOps.

2. Design a data-centric pipeline involving quality controls, lineage, labeling, feature stores, and model registries.

3. Select appropriate distributed-computing, deployment, cloud-edge, and serving patterns.

4. Define monitoring and observability strategies for data quality, model behavior, infrastructure, and business outcomes.

5. Analyze drift, feedback loops, security threats, lifecycle risks, and cost-performance trade-offs.

6. Develop a continuous-learning strategy that includes validation, approval, rollback, and human governance.

7. Critically evaluate an AI architecture in a professional or research setting.

From a Model to an AI Production System

A useful abstraction is a closed lifecycle:

problem formulation → data acquisition → data preparation and labeling → feature engineering → training → evaluation → registration → deployment → monitoring → intervention or retraining.

The lifecycle is not strictly linear. Production observations may expose labeling problems; monitoring may reveal that the original target is no longer meaningful; and a change in policy may require redesigning the data schema. Effective systems therefore preserve feedback paths and explicit decision gates.

The first engineering decision is the definition of the prediction task. A target variable should be operationally meaningful, measurable, and temporally valid. For example, predicting loan default using information available at application time is legitimate; using a later collections outcome as an input is leakage. A system specification should identify the unit of prediction, prediction horizon, allowable features, acceptable error types, service-level objectives, fairness requirements, and conditions under which the model must defer to a human.

A production pipeline commonly contains four planes. The data plane ingests and transforms records. The training plane creates datasets, features, and model artifacts. The serving plane generates predictions in batch, online, or at the edge. The control plane manages metadata, permissions, versioning, policies, orchestration, and audit records. Separating these concerns improves maintainability, although boundaries may be implemented differently across organizations.

Data-Centric Engineering

Data quality is multidimensional. Accuracy concerns whether values represent reality; completeness concerns missing values; consistency concerns agreement across systems; validity concerns conformance to permitted formats and ranges; timeliness concerns freshness; uniqueness concerns duplicate records; and integrity concerns relationships among entities. Quality is not an abstract score alone. A missing value in a noncritical descriptive field may be harmless, whereas a missing timestamp can invalidate temporal evaluation.

Data contracts make expectations explicit between producers and consumers. A contract may define schemas, semantic meaning, units, nullability, acceptable ranges, update frequency, ownership, and backward-compatibility rules. Automated checks should run at ingestion and transformation boundaries. A failed quality gate should not automatically be bypassed merely because a scheduled training job is waiting; it should generate an incident or route the data to quarantine.

Lineage records where data originated, how it changed, which features were derived, which model consumed it, and where predictions were used. Provenance is essential for reproducibility, debugging, intellectual-property control, and regulatory response. Dataset versioning should preserve both the data snapshot and the code, configuration, label definitions, and environment used to produce it.

Label quality deserves special attention. Labels may be noisy, delayed, subjective, or influenced by prior decisions. Inter-rater agreement can identify ambiguity, but agreement is not proof that the labeling policy is ethically or operationally appropriate. Active learning can prioritize uncertain or high-impact examples for expert review. Weak supervision can combine heuristic labeling functions, but its assumptions must be tested against a trusted sample.

Representativeness should be evaluated across relevant populations, time periods, environments, devices, and operating conditions. A random split can be misleading when records from the same customer, patient, machine, or event occur in both training and test sets. Group-based, temporal, or environment-based splits may better estimate deployment performance. Evaluation should also examine rare but consequential cases rather than relying only on aggregate accuracy.

Features, Stores, and Reproducibility

A feature is an input variable prepared for model consumption. A feature pipeline should define its source, transformation, time semantics, missing-value behavior, ownership, and quality thresholds. Feature stores address two recurring problems: inconsistent computation between training and serving, and uncontrolled reuse of undocumented features.

An offline feature store supports historical training and batch analysis. An online feature store provides low-latency values for real-time inference. The critical design requirement is feature parity: the online computation must represent the same logic as the training computation. Point-in-time correctness is equally important. When constructing a historical training example, a feature must contain only information available at the prediction time. Otherwise, temporal leakage produces an unrealistically strong model.

Feature stores should not become ungoverned data warehouses. Each feature needs an owner, description, lineage, freshness expectation, sensitivity classification, and deprecation policy. Derived features involving personal or confidential information require access control and retention rules. Feature reuse is valuable, but reuse without semantic review can transfer hidden bias or leakage from one task to another.

Model registries provide controlled storage for model artifacts and metadata. A registry entry may include training-data identifiers, code commit, dependency environment, evaluation results, fairness analysis, approval status, intended use, limitations, and rollback information. A model should be promoted through stages such as development, validation, approved, and retired rather than copied manually between environments.

Distributed Computing and Pipeline Orchestration

AI systems often process data volumes or training workloads beyond a single machine. Distributed data processing divides computation across workers, but distribution introduces synchronization costs, network bottlenecks, skew, fault recovery, and nondeterminism. Data-parallel training assigns different mini-batches to workers and aggregates gradients; model-parallel training divides a large model across devices. The appropriate strategy depends on model size, communication volume, accelerator memory, and failure tolerance.

Distributed computing does not remove the need for algorithmic judgment. A poorly partitioned dataset can create skew; a non-associative reduction can produce numerical differences; and excessive checkpointing can make a job operationally expensive. Reproducibility requires recording random seeds where meaningful, library and hardware versions, data snapshots, hyperparameters, and distributed configuration.

Workflow orchestration expresses dependencies, schedules jobs, retries transient failures, records metadata, and supports backfills. Idempotent tasks are particularly important: rerunning a task should not create duplicate records or corrupt downstream state. Pipelines should distinguish transient infrastructure failures from data-quality failures. Automatic retries are suitable for the former but may repeatedly amplify the latter.

A mature pipeline separates experimentation from production execution while allowing successful experiments to be promoted through tested components. Continuous integration can test transformation logic, schema compatibility, feature calculations, model interfaces, security policies, and representative prediction behavior. Continuous delivery then packages and deploys an approved artifact under controlled conditions.

Deployment Patterns and Serving Architecture

Models may be deployed through batch scoring, online synchronous APIs, asynchronous queues, streaming systems, or embedded edge devices. Batch inference is appropriate when decisions can be delayed and large volumes can be processed economically. Online inference is required when a decision depends on current context and must meet a latency objective. Edge inference reduces network dependence and may protect sensitive data, but it creates constraints on memory, energy, update mechanisms, and device observability.

A serving system should specify latency percentiles, throughput, availability, model timeout behavior, input validation, and fallback behavior. A prediction endpoint should not silently return arbitrary output when a feature is missing or a model is unavailable. It may instead use a safe default, a previous approved model, or human review, depending on the application risk.

Canary deployment exposes a new model to a small, controlled portion of traffic. Shadow deployment sends production inputs to a candidate model without using its predictions for decisions, allowing comparison without immediate user impact. A/B testing can estimate business outcomes, but randomization may be ethically or operationally inappropriate in high-risk settings. Champion–challenger arrangements compare an incumbent model with alternatives under defined governance.

Cloud platforms offer elastic compute, managed storage, orchestration, and specialized accelerators. Edge and hybrid architectures are useful where connectivity, latency, sovereignty, or privacy constraints matter. The choice should be based on workload characteristics and risk, not on the assumption that cloud or edge is universally superior. Data transfer, accelerator utilization, storage retention, inference frequency, and observability overhead all contribute to total cost of ownership.

Observability, Monitoring, and Drift

Monitoring asks whether a system continues to behave acceptably; observability asks whether its internal state can be inferred from emitted evidence. Logs, metrics, traces, feature statistics, model outputs, decision outcomes, and deployment metadata form the evidence base. Monitoring should cover at least four layers:

• Infrastructure: resource utilization, errors, latency, availability, queue depth, and accelerator health.
• Data: schema changes, missingness, ranges, freshness, cardinality, and distribution shifts.
• Model: confidence, calibration, error rates when labels arrive, subgroup performance, and prediction distributions.
• Business and social outcomes: costs, conversion, safety incidents, complaints, overrides, fairness indicators, and downstream effects.

Drift is not one phenomenon. Covariate drift occurs when the input distribution changes. Label or concept drift occurs when the relationship between inputs and the target changes. Prior-probability drift concerns changes in outcome prevalence. A statistical difference does not automatically imply performance degradation; conversely, stable input distributions do not guarantee that the target relationship remains valid.

Drift detectors may compare distributions using measures such as population stability measures, divergence metrics, quantile changes, or hypothesis tests. For continuous monitoring, practical thresholds should account for sample size, business materiality, seasonality, and multiple comparisons. Alerts should be connected to actions: investigate data sources, validate labels, recalibrate, retrain, restrict use, or roll back. An alert without ownership and a response procedure is merely an informational display.

Delayed labels make monitoring difficult. Organizations can use proxy indicators, expert review, outcome sampling, and sequential evaluation while waiting for ground truth. However, proxies should not be presented as definitive performance evidence. A model may also alter the population from which labels are later observed, creating selective labels and feedback loops.

Continuous Learning and Lifecycle Control

Continuous learning does not mean retraining after every new record. It means that data, evaluation, and release decisions are organized so that updating the model is safe and justified. A continuous-learning policy should define retraining triggers, minimum data volume, data-quality gates, evaluation windows, fairness checks, approval authorities, deployment strategy, and rollback conditions.

Automated retraining can be useful in stable, low-risk environments. In high-impact domains, human review may be required before promotion. A robust pipeline compares the candidate with the incumbent on a fixed benchmark, recent data, stress cases, and relevant subgroups. It should test for regression, leakage, calibration failure, unacceptable resource use, and changes in interpretability.

Lifecycle management includes deprecating obsolete features, rotating credentials, updating dependencies, renewing certificates, patching serving images, archiving artifacts, and documenting retirement decisions. Technical debt accumulates when experiments become undocumented services, when pipelines depend on unsupported libraries, or when no one owns a model after its creator leaves. Model cards, data documentation, runbooks, and incident records reduce this debt.

Security, Governance, and Responsible Operation

AI systems inherit conventional cybersecurity risks and add machine-learning-specific threats. Data poisoning modifies training examples to influence behavior; evasion manipulates inputs at inference time; model extraction seeks to reproduce a model through queries; membership inference attempts to determine whether a record was in training data; and prompt or tool manipulation can affect systems that combine language models with external actions.

Controls include least-privilege identity management, encryption in transit and at rest, network segmentation, secret management, signed artifacts, dependency scanning, input validation, rate limiting, anomaly detection, secure enclaves where appropriate, and separation of duties. Training data and model artifacts should be treated as sensitive assets, not merely files.

Governance requires a documented purpose, accountable owner, risk classification, data-protection basis, retention policy, access controls, audit trail, and incident process. Privacy-preserving techniques such as minimization, aggregation, pseudonymization, differential privacy, and federated learning can reduce exposure, although each introduces utility or implementation trade-offs. Fairness assessment should examine both statistical metrics and institutional context. Equal performance across groups may not be sufficient if the target itself reflects unequal access or historical discrimination.

Human oversight must be meaningful. A human who receives an unexplained recommendation under severe time pressure may function only as a rubber stamp. Effective oversight provides authority to contest, override, or suspend the system; appropriate training; access to evidence; and accountability that is not shifted entirely onto the operator.

Cost, Reliability, and Organizational Design

AI architecture is an economic system. Costs include data storage, data movement, training, experimentation, inference, observability, security, human labeling, incident response, and opportunity cost. Larger models may improve performance but increase latency, energy use, infrastructure dependence, and operational complexity. Cost should therefore be evaluated per accepted decision, not only per prediction.

Reliability engineering uses service-level indicators and objectives. For example, an organization may measure prediction availability, p95 latency, data freshness, valid-input rate, and error-free decision rate. Error budgets can help balance rapid improvement with stability. High-risk systems may require redundancy, disaster recovery, graceful degradation, and tested rollback procedures.

Organizationally, responsibility may be distributed among data engineering, platform engineering, data science, product, security, legal, compliance, and operations. Distributed responsibility requires explicit ownership. A model owner should not be solely accountable for upstream data quality or downstream harm that they cannot control; governance should establish shared responsibilities and escalation paths.

Illustrative Case: Predictive Maintenance for a Distributed Energy Operator

Background

Consider an illustrative energy operator managing wind turbines across coastal and inland sites. The operator wants to predict gearbox failure early enough to schedule maintenance and avoid unplanned outages. Sensors produce temperature, vibration, rotational-speed, and power-output data at different frequencies. Connectivity is intermittent at some remote sites.

Situation and Problem

An initial model performs well in a laboratory evaluation but generates excessive alerts after deployment. Engineers discover that training data came mainly from newer coastal turbines, while the deployment fleet includes older inland equipment. Some sensor values are also backfilled after maintenance, creating temporal leakage in the original evaluation. The online system occasionally uses stale features because the feature service and training pipeline calculate rolling statistics differently.

Analysis

The problem is not simply model accuracy. It involves population shift, data provenance, feature-time semantics, deployment parity, and operational costs. False alarms consume engineering capacity, while missed failures cause expensive outages. Because failures are rare and labels arrive only after inspections, conventional accuracy is uninformative. The team therefore defines precision at the maintenance-capacity limit, recall for high-severity failures, warning lead time, and performance by turbine generation and location.

Approach and Solution

The operator establishes data contracts for sensor identity, units, timestamps, calibration status, and freshness. Records affected by backfill are excluded from point-in-time training examples. A governed feature pipeline produces both historical and online rolling features from shared transformation definitions. The team uses grouped and temporal validation, with entire turbines held out from some test sets.

A model registry records data versions, code, sensor coverage, and subgroup results. The candidate model is first shadowed in production. Its predictions are compared with the incumbent, while engineers review a sample of high-confidence alerts. Edge devices retain a compact fallback model for periods without connectivity and transmit summarized evidence when the connection returns. The serving system reports feature freshness and sensor availability rather than treating missing data as ordinary zeros.

Retraining is triggered by confirmed performance decline, substantial fleet composition change, or a validated sensor recalibration—not by every statistical fluctuation. A human approval board reviews cost, safety, and subgroup performance before promotion. A rollback package contains the previous model, feature configuration, and compatible runtime.

Outcome

In this illustrative case, the major improvement comes from correcting temporal leakage, aligning feature computation, and changing evaluation—not from selecting a more complex algorithm. The organization gains more trustworthy alerts, clearer operational ownership, and a repeatable release process. The case demonstrates that MLOps is a system of controls and feedback, not merely a collection of deployment tools.

Learning Points

1. Data and feature semantics can dominate algorithm choice.

2. Rare-event systems require metrics tied to operational capacity and harm.

3. Edge deployment must include synchronization, fallback, and update governance.

4. Monitoring must connect detection to an explicit response.

5. Reproducibility requires data, code, environment, configuration, and lineage.

Common Failure Modes and Critical Limitations

A frequent mistake is to optimize offline metrics without defining deployment conditions. Another is to split data randomly when records are temporally or organizationally related. Teams may also monitor infrastructure while ignoring labels, subgroup outcomes, or business harm. Automatic retraining can institutionalize corrupted labels or drift toward biased historical decisions. Feature stores may create an illusion of governance if ownership and lineage are absent.

Observability itself has risks. Excessive logging can expose personal information and increase cost. Drift detectors can produce alert fatigue when thresholds ignore seasonality. Canary tests may miss rare harms if traffic is too small, while A/B tests can distribute risk to real users. A model registry does not guarantee reproducibility if external datasets, undocumented manual edits, or mutable dependencies are omitted.

No architecture eliminates uncertainty. Labels may remain ambiguous, causal effects may be confused with correlations, and fairness metrics may conflict. Technical safeguards should therefore be combined with domain expertise, independent review, user feedback, and the authority to suspend the system.

Current Developments and Emerging Directions

Recent practice is moving toward platform engineering for machine learning, where reusable templates provide identity, data access, testing, deployment, and observability while allowing domain teams to own task-specific logic. Feature and model metadata are increasingly treated as searchable knowledge graphs. Automated evaluation is expanding to include robustness, privacy, security, calibration, and subgroup behavior.

Edge AI is developing through quantization, pruning, distillation, specialized accelerators, and federated arrangements. These methods can reduce bandwidth and improve privacy but complicate update verification and fleet management. Generative and foundation-model systems introduce additional concerns: retrieval-data freshness, tool permissions, hallucination evaluation, prompt injection, model licensing, and output provenance. Their lifecycle should still be governed by the same principles of versioning, testing, monitoring, human accountability, and controlled change.

Research opportunities include causal monitoring, adaptive drift detection, uncertainty-aware deployment, energy-aware scheduling, privacy-utility optimization, and formal verification of selected pipeline properties. A significant open question is how to evaluate socio-technical outcomes when model decisions change the environment that generates future data.

Best-Practice Principles

A dependable AI system should:

• define the decision, stakeholders, risks, and service objectives before selecting a model;
• treat datasets, labels, features, code, models, and environments as versioned artifacts;
• enforce data contracts and point-in-time correctness;
• test temporal, subgroup, environmental, and adversarial conditions;
• separate candidate evaluation from production promotion;
• monitor infrastructure, data, model behavior, and real-world outcomes;
• connect alerts to named owners, runbooks, and rollback or suspension actions;
• minimize sensitive data and apply least-privilege access;
• measure total cost and energy as well as predictive performance;
• document assumptions, limitations, intended use, and retirement criteria.

Chapter Summary

AI systems engineering extends machine-learning practice from model construction to the design and operation of reliable socio-technical systems. Data-centric AI emphasizes quality, labeling, representation, provenance, contracts, and point-in-time correctness. Feature stores and model registries support reuse and reproducibility when accompanied by ownership and metadata. Distributed computing and orchestration provide scale but require attention to partitioning, idempotence, failure recovery, and reproducibility.

Deployment may be batch, online, streaming, or edge-based, with canary, shadow, and rollback strategies supporting controlled change. Observability combines infrastructure, data, model, business, and social monitoring. Drift must be interpreted in relation to labels, seasonality, performance, and operational consequences. Continuous learning requires explicit triggers, validation, governance, and lifecycle control rather than indiscriminate retraining. Security, privacy, fairness, human oversight, cost, and accountability are architectural concerns. The central professional lesson is that production AI succeeds when technical performance is integrated with evidence, governance, operational readiness, and responsible management of change.

Key Terms

Data-centric AI: An approach that prioritizes the quality, coverage, labeling, and governance of data used by AI systems.

MLOps: Practices and infrastructure for developing, deploying, monitoring, and governing machine-learning systems across their lifecycle.

Data contract: A documented agreement specifying a dataset’s schema, semantics, quality expectations, ownership, and compatibility rules.

Data lineage: A record of data origins, transformations, dependencies, and downstream uses.

Point-in-time correctness: The requirement that a training feature contain only information available at the prediction time.

Feature store: A governed system for producing, storing, discovering, and serving machine-learning features.

Model registry: A controlled repository of model artifacts, versions, metadata, evaluations, and approval states.

Concept drift: Change in the relationship between input variables and the target outcome.

Covariate drift: Change in the distribution of input variables over time or across environments.

Observability: The ability to infer system state from logs, metrics, traces, and other emitted evidence.

Shadow deployment: Running a candidate model on production inputs without using its outputs for decisions.

Canary deployment: Gradually exposing a new model or service version to a limited portion of traffic.

Continuous learning: A governed process for updating models as new data and evidence become available.

Data poisoning: Deliberate manipulation of training data to influence model behavior.

Model extraction: An attempt to reproduce a model through systematic queries to its service.

Service-level objective: A defined target for a service characteristic such as availability, latency, or freshness.

Technical debt: Future maintenance and risk created by expedient, undocumented, or poorly governed technical decisions.

Feedback loop: A process in which system decisions influence the future data or outcomes used to evaluate or retrain the system.

Edge AI: AI inference or learning performed on or near the device where data is generated.

Model rollback: Restoration of a previously approved model and compatible configuration after a deployment problem.

Review Questions

Short Answer Questions

1. Why is a production AI system broader than a machine-learning model?

2. What is point-in-time correctness, and why does it matter?

3. Distinguish covariate drift from concept drift.

4. What purposes do feature stores and model registries serve?

5. Why should monitoring include business and social outcomes?

Long Answer Questions

1. Explain how data contracts, lineage, labeling procedures, and dataset versioning contribute to reproducible AI systems.

2. Compare batch, online, streaming, and edge deployment, including their principal engineering trade-offs.

3. Design a monitoring framework covering infrastructure, data, model, and business layers.

4. Discuss how continuous learning can be governed safely in a high-impact domain.

5. Analyze the relationship among security, privacy, fairness, human oversight, and accountability in MLOps.

Analytical / Application Questions

1. A fraud model’s input distributions remain stable, but confirmed fraud rates and precision decline sharply. What kinds of drift or operational change might explain this, and what evidence should be collected?

2. An organization wants to deploy a predictive-maintenance model to intermittently connected devices. Propose an architecture that addresses feature freshness, fallback inference, model updates, monitoring, and rollback.

3. A candidate model improves overall accuracy but performs substantially worse for a small, high-risk subgroup and requires twice the inference cost. How should the release decision be analyzed and governed?

22. Multiple Choice Questions with Answers

Question 1

Which condition most directly prevents temporal leakage when constructing a training example?

A. Using the largest available dataset

B. Including only feature values available at the prediction time

C. Randomly shuffling all records before splitting

D. Increasing model complexity

Correct Answer: B. Including only feature values available at the prediction time

Question 2

What is the primary purpose of a model registry?

A. To replace all data-quality tests

B. To provide unversioned storage for predictions

C. To manage model artifacts, metadata, evaluation, and approval states

D. To calculate network latency

Correct Answer: C. To manage model artifacts, metadata, evaluation, and approval states

Question 3

A model’s input distribution changes, but the relationship between inputs and the target remains stable. This is best described as:

A. Covariate drift

B. Concept drift

C. Data poisoning

D. Model extraction

Correct Answer: A. Covariate drift

Question 4

Which deployment method evaluates a candidate model on production inputs without using its predictions for actual decisions?

A. Canary deployment

B. Shadow deployment

C. Rollback deployment

D. Batch deployment

Correct Answer: B. Shadow deployment

Question 5

Why is point-in-time correctness especially important in predictive maintenance?

A. It guarantees zero infrastructure cost

B. It prevents maintenance records created after an event from leaking into earlier predictions

C. It eliminates the need for labels

D. It ensures every turbine has identical sensors

Correct Answer: B. It prevents maintenance records created after an event from leaking into earlier predictions

Question 6

Which response is most appropriate when a data-quality alert shows that an upstream sensor schema has changed?

A. Automatically retrain immediately

B. Ignore the alert if infrastructure is healthy

C. Quarantine or validate the data and investigate the contract violation

D. Increase the model’s learning rate

Correct Answer: C. Quarantine or validate the data and investigate the contract violation

Question 7

Which statement best characterizes continuous learning?

A. Retraining after every new record without review

B. A governed process with triggers, validation, approval, and controlled deployment

C. Replacing monitoring with human intuition

D. Using only online learning algorithms

Correct Answer: B. A governed process with triggers, validation, approval, and controlled deployment

Question 8

Which security threat attempts to reproduce a model by querying its prediction service?

A. Data poisoning

B. Model extraction

C. Covariate drift

D. Sensor backfill

Correct Answer: B. Model extraction

Question 9

Why might an edge deployment be selected over centralized cloud inference?

A. Edge systems always have greater computational capacity

B. Edge deployment can reduce latency and dependence on connectivity

C. Edge deployment removes the need for model updates

D. Edge systems automatically guarantee fairness

Correct Answer: B. Edge deployment can reduce latency and dependence on connectivity

Question 10

A candidate model has higher aggregate accuracy but substantially worse performance for a high-risk subgroup. What is the most defensible release decision?

A. Deploy it because aggregate accuracy is the only relevant metric

B. Deploy it only if the model is larger

C. Conduct subgroup, harm, governance, and operational analysis before deciding

D. Delete all subgroup metrics to avoid bias

Correct Answer: C. Conduct subgroup, harm, governance, and operational analysis before deciding