11. Secure AI Architecture, MLOps and Model Monitoring

Introduction and Context

Artificial intelligence systems are no longer isolated research artefacts. They are embedded in fraud detection, threat intelligence, identity verification, security operations, autonomous decision support, and business processes. Their security therefore depends not only on the model algorithm, but also on the complete chain through which data, code, dependencies, models, infrastructure, and decisions move from development to production.

This chain is commonly described as the AI supply chain. It includes data collection and labelling, feature engineering, experimentation, software libraries, training infrastructure, model packaging, registries, deployment platforms, application interfaces, monitoring systems, and human oversight. A weakness in any link can compromise the confidentiality, integrity, availability, or reliability of the entire AI service. For example, a tampered training dataset may produce a backdoored classifier; an unpatched dependency may expose a model-serving endpoint; inadequate monitoring may allow gradual model drift to remain undetected.

MLOps applies DevOps principles to machine-learning systems, but it must address additional concerns. Conventional software is generally built from explicitly specified logic, whereas machine-learning behaviour is partly determined by data and learned parameters. Consequently, secure MLOps must provide reproducibility, provenance, controlled experimentation, model validation, deployment governance, and continuous assurance. Model monitoring extends operational observability beyond uptime and latency to include prediction quality, data distribution, fairness, security signals, and changes in the environment.

For cybersecurity professionals, the central question is not simply whether a model is accurate. It is whether the model can be trusted throughout its lifecycle, whether its behaviour can be explained sufficiently for the intended use, and whether the organisation can detect, contain, investigate, and recover from compromise.

Learning Objectives

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

• explain the architecture and lifecycle of a secure AI supply chain;
• distinguish data, code, dependency, model, infrastructure, and operational risks;
• design access-control, provenance, registry, and deployment controls for MLOps;
• apply secure release, rollback, observability, and incident-response practices;
• select meaningful metrics for drift, performance, reliability, and security monitoring;
• evaluate governance, ethical, regulatory, and organisational implications; and
• develop a continuous-assurance plan for an AI-enabled service.

The AI Supply Chain as a Security Boundary

A useful way to understand secure AI architecture is to treat every transformation of an artefact as a security boundary. A raw dataset becomes a curated dataset; curated data becomes features; source code and configuration produce a trained model; a model becomes a container or service; and the service generates decisions that affect people or business operations. At each boundary, the organisation should know what changed, who authorised the change, which tools were used, and whether the resulting artefact was tested.

The principal assets include:

• data and labels;
• source code, notebooks, prompts, and configuration;
• feature definitions and feature stores;
• third-party libraries, base images, and model components;
• training environments and compute resources;
• model weights, metadata, and evaluation results;
• deployment manifests, service accounts, and secrets; and
• logs, monitoring data, alerts, and audit records.

Threats include poisoning, unauthorised modification, theft of intellectual property, malicious dependencies, credential compromise, model extraction, adversarial inputs, denial of service, privacy leakage, and insider misuse. Some threats affect the development process, while others target a deployed endpoint. A secure architecture must therefore combine preventive, detective, and corrective controls.

The principle of least privilege is particularly important. A data scientist may need to read approved training data and write experiment results, but should not automatically be able to promote a model to production. A deployment service may retrieve an approved model and write health metrics, but should not have unrestricted access to source repositories or raw personal data. Separation of duties reduces the chance that one compromised identity can alter data, approve a model, and deploy it without independent review.

Provenance, Reproducibility and Integrity

Provenance is the record of an artefact’s origin, transformations, dependencies, approvals, and relationships. In an AI system, provenance should answer questions such as: Which data version trained this model? Which labelling policy was used? Which code commit and dependency versions were present? What evaluation results supported release? Who approved the promotion? Which production endpoint is serving the model?

A practical provenance record may contain cryptographic hashes, timestamps, responsible identities, dataset identifiers, source-code commit identifiers, environment specifications, training parameters, evaluation reports, and links to downstream deployments. Hashes help detect unauthorised modification, while signed metadata helps establish who approved an artefact. Provenance does not prove that an artefact is safe; it makes investigation, reproduction, and accountability possible.

Reproducibility has several levels. Exact reproducibility attempts to recreate identical outputs using the same data, code, parameters, hardware, and random seeds. Functional reproducibility seeks equivalent performance even when infrastructure differs. Scientific reproducibility concerns whether an independent team can validate the reported method and results. In operational environments, the second and third forms are often more realistic, but the organisation should explicitly state which level is required.

Data lineage is equally significant. A training dataset should be associated with its sources, collection permissions, transformations, filtering decisions, labels, retention rules, and known quality limitations. Dataset versioning must include not only file versions but also schemas, feature definitions, labelling guidelines, and exclusions. Without this information, a performance regression may be impossible to explain and a privacy request may be impossible to fulfil.

Identity, Access Control and Secrets

Secure MLOps requires identity-centred control rather than informal trust among project members. Authentication should support strong user and workload identities, preferably with centralised identity management and multifactor authentication for human administrators. Authorisation should be based on roles and, where necessary, attributes such as project, environment, data classification, or deployment stage.

Typical roles include data steward, ML engineer, security reviewer, model owner, platform administrator, release approver, and incident responder. These roles need not be permanent or broad. Time-limited, just-in-time elevation is safer than standing administrative privileges. Production access should be logged, reviewed, and restricted to approved operational needs.

Secrets such as API keys, database credentials, signing keys, and cloud tokens should not be stored in notebooks, source repositories, container images, or model files. A secrets-management service should issue credentials with limited scope and rotation. Workload identity can allow a training job or deployment service to obtain only the credentials required for its task. Revocation procedures are essential because an exposed secret is a security incident, not merely a configuration error.

Access decisions should also cover model inputs and outputs. Prediction logs may contain personal or commercially sensitive information. The ability to query a high-value model can itself be sensitive because repeated queries may facilitate model extraction or reveal membership information. Rate limits, query auditing, output filtering, and separate access policies for training, validation, and production data are therefore necessary.

Dependency and Build Security

An AI application depends on more than its primary model library. It may use numerical packages, data connectors, operating-system packages, container base images, GPU drivers, orchestration components, model-serving frameworks, and external APIs. A vulnerability or malicious change in any component can affect the final service.

Dependency management should maintain a software bill of materials (SBOM) and, where appropriate, a machine-learning bill of materials identifying datasets, models, code, libraries, images, and tools. Dependencies should be obtained from trusted repositories, pinned or constrained to reviewed versions, scanned for known vulnerabilities, and tested before release. Automated scanning is valuable but incomplete: a package without a known vulnerability can still be malicious, abandoned, incorrectly configured, or incompatible with the security requirements of the system.

Builds should be reproducible and preferably generated in controlled, ephemeral environments. Continuous integration pipelines should run unit tests, data-validation tests, static analysis, dependency checks, secret detection, licence checks, and security tests. Build artefacts should be signed and promoted through environments rather than rebuilt differently for production. This reduces the risk that the tested object is not the object eventually deployed.

The same discipline applies to pretrained models and external datasets. Their provenance, licence, intended use, known limitations, security history, and integrity should be assessed. A model downloaded from an unverified location may contain unsafe serialisation behaviour, hidden functionality, or a backdoor. Deserialisation should use safe formats and isolated processes wherever possible.

Model Registries and Controlled Promotion

A model registry is the authoritative inventory of models and their lifecycle states. It should hold model artefacts or secure references to them, along with metadata such as version, owner, training data, code revision, evaluation metrics, intended use, limitations, approvals, and deployment history. Useful lifecycle states include development, candidate, validated, approved, production, deprecated, and quarantined.

The registry should enforce promotion policies rather than functioning as a passive file store. A model may be promoted only when required tests have passed, provenance is complete, security review is recorded, and an authorised person or group has approved the release. Policies may require minimum performance, maximum error rates, fairness checks, robustness tests, latency limits, or privacy review depending on the application.

Model versioning should distinguish the model artefact from its serving configuration. A change in threshold, preprocessing, feature definition, prompt template, or post-processing rule can materially change system behaviour even if model weights remain constant. The deployable unit should therefore be represented as a versioned release package containing all relevant components.

Secure Deployment Architecture

Deployment architecture should reflect the sensitivity and criticality of the use case. Common patterns include batch inference, an internal service, an API gateway in front of a model server, or an edge deployment. Each pattern creates different exposure, latency, and data-residency concerns.

A secure serving path generally includes authenticated clients, authorisation checks, input validation, rate limiting, network segmentation, encrypted communication, controlled model retrieval, and structured logging. The model server should run with a minimal operating-system image and a non-privileged identity. Administrative interfaces should not be exposed to public networks. Resource quotas and circuit breakers help limit denial-of-service effects caused by expensive or unusually large inputs.

Input validation must address both ordinary quality problems and adversarial behaviour. Schemas, ranges, encoding, file types, and dimensionality should be checked before inference. For language and multimodal systems, validation may include content limits, prompt-injection controls, tool-authorisation boundaries, and filtering of sensitive output. Validation does not replace model robustness testing, but it reduces avoidable attack surface.

Deployment strategies should support controlled exposure. Blue-green deployment maintains separate old and new environments and switches traffic after validation. Canary deployment sends a small proportion of traffic to the new version while comparing health, performance, and security indicators. Shadow deployment evaluates a new model on copied production inputs without allowing it to influence decisions. These approaches reduce the blast radius of an unsafe release.

Observability and Model Monitoring

Traditional application monitoring measures availability, response time, resource consumption, and error rates. AI services require these measures plus model-specific observability. Monitoring should be designed around questions, not merely around dashboards: Is the service available? Are inputs changing? Is prediction quality declining? Is the model being attacked? Are outputs unfair or unstable? Can an incident be reconstructed?

Three layers are useful. System observability covers infrastructure health, network errors, CPU or accelerator use, memory, queue length, latency, and throughput. Data observability covers schema violations, missingness, ranges, cardinality, freshness, outliers, and distribution changes. Model observability covers confidence, class proportions, calibration, error rates, business outcomes, subgroup performance, and drift.

Monitoring must respect privacy and security. Full raw inputs may be unnecessary and dangerous to retain. Organisations can use redaction, tokenisation, aggregation, sampling, or privacy-preserving telemetry. Logs should have access controls, retention limits, integrity protection, and a documented purpose. Excessive logging can itself become a data-protection failure.

Drift Detection

Drift is a change that may reduce the validity of a model or alter the risks surrounding it. Data drift concerns changes in input distributions. Concept drift concerns changes in the relationship between inputs and outcomes. Prediction drift concerns changes in output distributions. Operational drift may arise when workflows, user behaviour, sensors, policies, or adversaries change.

A drift signal is not automatically a failure. Seasonal variation may be legitimate, and a statistically significant change may be operationally irrelevant in a large dataset. Conversely, a small change in a high-risk subgroup may be important even when aggregate metrics appear stable. Drift detection should therefore combine statistical tests, domain thresholds, performance measures, and human review.

When labels are delayed, proxy indicators can be used temporarily, but they should not be treated as definitive evidence. Monitoring plans should specify baselines, windows, thresholds, alert severity, ownership, and response actions. A useful response may be investigation, recalibration, increased sampling, temporary restrictions, retraining, rollback, or retirement.

Model and Security Metrics

Metrics should be selected according to the decision and threat model. Classification systems may require precision, recall, false-positive rate, false-negative rate, calibration, and subgroup comparisons. Ranking systems may require ranking quality and coverage. Anomaly detectors require investigation of alert volume, analyst confirmation, and changing base rates. Security operations should also track adversarial indicators, unusual query patterns, rejected inputs, authentication failures, extraction-like behaviour, and changes in model confidence.

A single composite score can conceal important failures. For example, a high overall accuracy may coexist with poor performance for a minority subgroup or a dangerous increase in false negatives. Dashboards should present distributions, confidence intervals where appropriate, and comparisons with approved baselines. Monitoring is most useful when it leads to a defined decision rather than alert fatigue.

Incident Response, Rollback and Recovery

AI incident response adapts established cybersecurity response practices to model-specific failures. Incidents may involve data poisoning, model theft, exposed secrets, unauthorised deployment, harmful outputs, privacy leakage, adversarial manipulation, dependency compromise, or unexplained performance degradation.

Preparation includes asset inventories, contact lists, escalation criteria, playbooks, forensic logging, tested rollback procedures, and decisions about when human review is mandatory. Detection should correlate application, identity, infrastructure, data, and model telemetry. Containment may involve disabling an endpoint, reducing privileges, blocking a data source, applying a safe fallback, freezing promotion, or routing decisions to human analysts.

Rollback is not always the best response. Returning to an older model may restore a known weakness or reintroduce outdated behaviour. The decision should consider the cause, the integrity of the previous version, current environmental conditions, and the consequences of service interruption. A safe fallback can be a rules-based system, a conservative threshold, manual review, or temporary denial of high-risk actions.

Recovery includes rebuilding from trusted artefacts, rotating credentials, validating the environment, reviewing affected decisions, notifying relevant stakeholders, and documenting lessons learned. Post-incident analysis should examine contributing organisational conditions, not merely identify an individual error. Corrective actions should be tracked to completion and tested for effectiveness.

Continuous Assurance and Governance

Continuous assurance means that confidence in an AI system is maintained throughout operation rather than granted once at initial approval. It combines automated controls, periodic review, independent assessment, risk-based testing, and evidence collection. Evidence may include provenance records, access logs, evaluation reports, vulnerability findings, monitoring results, incident records, and approval decisions.

A governance framework should define the model owner, business owner, data steward, security responsibility, acceptable use, prohibited use, performance requirements, review frequency, retention, and retirement conditions. High-impact systems require stronger controls, more frequent review, and clearer human accountability. Automation should not obscure responsibility: an organisation remains accountable for decisions made through systems it deploys.

Ethical and regulatory considerations include privacy, fairness, transparency, explainability, contestability, accessibility, intellectual-property rights, data minimisation, and records of processing. Security controls can conflict with other goals. Extensive monitoring may improve detection but increase privacy risk; aggressive input filtering may reduce attacks but exclude legitimate users; frequent retraining may improve adaptation but amplify poisoned feedback. These trade-offs should be documented and reviewed rather than handled informally.

An Applied Case: Securing an AI-Based Fraud Detection Service

Background

A financial institution uses a machine-learning service to score payment transactions for possible fraud. The service receives transaction attributes from several internal systems and returns a risk score to an orchestration platform. High-risk transactions are held for investigation, while low-risk transactions proceed automatically.

Situation and Problem

The model initially performs well, but analysts observe a sudden increase in alerts from one region. At the same time, the service experiences higher latency and several deployment records are incomplete. An investigation finds that a feature-engineering library was upgraded directly in production, a new data source was added without documented validation, and model queries from an unfamiliar service account increased sharply.

Analysis

The incident combines operational, supply-chain, and security weaknesses. The undocumented library change means that the production feature transformation cannot be compared confidently with the training process. The new data source may have changed the input distribution or introduced corrupted values. The unfamiliar account may indicate credential misuse or an unapproved integration. Increased alerts could reflect genuine fraud, data drift, a feature defect, or adversarial manipulation.

Approach and Solution

The institution first activates its AI incident playbook. The suspicious account is disabled and credentials are rotated. The service is placed behind stricter rate limits, and high-risk decisions are routed to human review. A known-good model and feature pipeline are restored only after their hashes and registry records are verified.

The team then reconstructs provenance from source-control records, container manifests, registry metadata, and logs. Data-quality tests compare the new source with approved schemas and historical distributions. Security analysts examine query patterns for extraction attempts. Model owners evaluate precision, recall, false-positive rates, latency, and regional subgroup performance before and after the change.

Longer-term controls include mandatory registry promotion, signed build artefacts, an SBOM, separate service identities, canary deployment, shadow evaluation for feature changes, drift alerts, and an approval rule requiring both model-owner and security review for production changes. The organisation also adds a documented fallback: transactions above a defined risk threshold require manual review when monitoring confidence is low.

Outcome

The institution restores a verified release, reduces the immediate operational impact, and obtains an auditable account of the incident. The investigation does not assume that the alert increase had one cause; it separates data-quality, performance, and security hypotheses and tests each with evidence.

Learning Points

The case demonstrates that model monitoring cannot compensate for missing provenance, and a secure registry is ineffective if teams can bypass it. It also shows why rollback, identity control, feature validation, and human escalation must be designed before an incident occurs. Most importantly, an AI incident is often a system incident involving data, software, infrastructure, and organisational process simultaneously.

Common Failure Patterns and Design Judgements

Several mistakes recur in AI operations. Teams may treat notebooks as production specifications, rely on unversioned datasets, approve models on aggregate accuracy alone, store credentials in configuration files, or monitor infrastructure without monitoring predictions. Another common error is alerting on every statistical change without defining response ownership; this creates fatigue and encourages operators to ignore meaningful signals.

Over-automation is also risky. Automatic retraining can incorporate poisoned or low-quality feedback, while automatic rollback can restore a vulnerable version. Automation should be bounded by policy, tested in advance, and capable of being paused. Conversely, excessive manual approval can slow urgent remediation and encourage informal bypasses. The appropriate balance depends on system criticality and risk.

Model monitoring has inherent limitations. Ground-truth labels may be delayed, biased, or unavailable. Drift metrics can produce false alarms, and attacks may imitate normal distributions. Explainability tools provide useful evidence but are not guaranteed to reveal causal reasoning. No single control establishes trust. Defence in depth, explicit uncertainty, human judgement, and continuous review remain necessary.

Emerging Directions

Secure AI operations are increasingly incorporating policy-as-code, automated evidence collection, signed provenance, confidential computing, privacy-preserving telemetry, and specialised security testing for foundation models. Organisations are also connecting model inventories with enterprise asset-management and vulnerability-management systems. For generative AI, monitoring expands to prompt injection, unsafe tool use, sensitive-data disclosure, retrieval-source integrity, hallucination indicators, and abuse patterns.

The emerging direction is not simply more automation. It is the integration of security, reliability, data governance, model risk management, and software engineering into a single lifecycle. This integration enables organisations to make deployment decisions based on evidence and to adapt controls to the consequences of failure.

Best-Practice Design Pattern

A mature secure MLOps capability generally follows these practices:

1. maintain an inventory of models, data sources, dependencies, owners, and deployments;

2. version and sign code, data descriptions, models, configurations, and release packages;

3. enforce least privilege, separation of duties, strong workload identity, and secret rotation;

4. use controlled builds, SBOMs, vulnerability management, and safe model deserialisation;

5. require registry-based promotion supported by reproducible evaluation evidence;

6. deploy with canary, blue-green, or shadow techniques appropriate to risk;

7. monitor infrastructure, data, predictions, security signals, privacy, and subgroup outcomes;

8. define thresholds, owners, playbooks, fallbacks, rollback criteria, and escalation paths;

9. preserve tamper-evident evidence while minimising sensitive telemetry; and

10. review the system continuously, including after incidents, major data changes, and material environmental changes.

Chapter Summary

Secure AI architecture treats the entire AI supply chain as a set of connected security boundaries. Data, code, dependencies, models, infrastructure, identities, and operational evidence must be controlled throughout the lifecycle. Provenance and reproducibility make artefacts traceable; least privilege and separation of duties limit misuse; dependency and build security protect the software foundation; and model registries provide controlled promotion.

Secure deployment requires validated inputs, protected interfaces, minimal privileges, controlled exposure, and reliable fallback or rollback procedures. Model monitoring extends ordinary observability with data-quality, drift, performance, fairness, and security indicators. Effective incident response combines technical containment with evidence preservation, human oversight, recovery, and organisational learning. Continuous assurance ensures that governance is not a one-time approval but an ongoing evaluation of whether the AI system remains trustworthy, lawful, secure, and fit for purpose.

Key Terms

AI supply chain: The connected lifecycle of data, code, dependencies, models, infrastructure, and operational services used to build and run AI.

MLOps: Practices and technologies for developing, deploying, operating, and governing machine-learning systems.

Provenance: Evidence describing an artefact’s origin, transformations, dependencies, ownership, and approvals.

Data lineage: The traceable history of data sources, transformations, labels, and uses.

Reproducibility: The ability to recreate or independently validate a method, result, or operational release.

Least privilege: Granting an identity only the access necessary for its authorised task.

Separation of duties: Dividing sensitive responsibilities among different people or systems.

Software bill of materials: An inventory of software components and dependencies in a build.

Model registry: A controlled repository recording model versions, metadata, approvals, and deployment states.

Model promotion: The authorised movement of a model between lifecycle stages.

Canary deployment: A release strategy that exposes a new version to a small proportion of traffic first.

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

Observability: The ability to understand system state from telemetry such as logs, metrics, and traces.

Data drift: A change in the distribution of model inputs over time.

Concept drift: A change in the relationship between inputs and the target outcome.

Model extraction: An attempt to infer or reproduce a model through repeated queries.

Rollback: Returning a service to a previously approved version or safe state.

Continuous assurance: Ongoing collection and evaluation of evidence that a system remains trustworthy and compliant.

Fallback: A predefined alternative process used when the primary AI service is unsafe or unavailable.

Review Questions

Short Answer Questions

1. What purposes do provenance records serve in a secure AI supply chain?

2. Why should model-serving services use separate workload identities?

3. Distinguish data drift from concept drift.

4. What information should a model registry retain besides model weights?

5. Why is rollback not always the safest incident-response action?

Long Answer Questions

1. Explain how least privilege and separation of duties should be applied across an MLOps lifecycle.

2. Discuss the role of dependency management, SBOMs, controlled builds, and artefact signing in AI security.

3. Design a monitoring strategy covering infrastructure, data, model performance, and security indicators.

4. Explain how canary, blue-green, and shadow deployments reduce the risk of unsafe model releases.

5. Describe a complete incident-response process for a compromised AI model, from preparation through recovery.

Analytical / Application Questions

1. A fraud model’s false-positive rate rises sharply after a new data source is introduced, but overall accuracy remains stable. Analyse possible causes and propose an evidence-based investigation.

2. A team proposes automatic retraining whenever drift exceeds a threshold. Evaluate the proposal and design safeguards against poisoned feedback and inappropriate retraining.

3. Design a secure MLOps architecture for a high-impact decision service, identifying identities, registry controls, monitoring signals, fallback arrangements, and governance responsibilities.

22. Multiple Choice Questions with Answers

Question 1

Which control most directly supports tracing a production model back to its training data and code?

A. Rate limiting

B. Provenance metadata

C. Load balancing

D. Output filtering

Correct Answer: B. Provenance metadata

Question 2

A model registry should primarily function as:

A. An unstructured storage location for large files

B. A public marketplace for pretrained models

C. An authoritative and controlled record of model versions and approvals

D. A replacement for application monitoring

Correct Answer: C. An authoritative and controlled record of model versions and approvals

Question 3

Which deployment method evaluates a new model on production inputs without allowing it to influence decisions?

A. Shadow deployment

B. Blue-green cutover

C. Full replacement

D. Emergency rollback

Correct Answer: A. Shadow deployment

Question 4

Why is aggregate accuracy insufficient for monitoring a high-impact model?

A. Accuracy cannot be calculated for any classifier

B. It may conceal subgroup failures or harmful false negatives

C. It measures infrastructure latency instead

D. It automatically causes data drift

Correct Answer: B. It may conceal subgroup failures or harmful false negatives

Question 5

An unfamiliar service account begins making unusually frequent queries to a valuable model. Which response is most appropriate initially?

A. Increase the model’s learning rate

B. Disable or restrict the identity, rotate credentials, and investigate query patterns

C. Delete all historical monitoring data

D. Promote the latest experimental model

Correct Answer: B. Disable or restrict the identity, rotate credentials, and investigate query patterns

Question 6

Which statement best distinguishes data drift from concept drift?

A. Data drift concerns input distributions, while concept drift concerns relationships between inputs and outcomes

B. Data drift concerns infrastructure, while concept drift concerns encryption

C. Data drift occurs only during training, while concept drift occurs only during deployment

D. They are two names for exactly the same event

Correct Answer: A. Data drift concerns input distributions, while concept drift concerns relationships between inputs and outcomes

Question 7

What is the main security benefit of separating model approval from model deployment?

A. It eliminates the need for testing

B. It creates separation of duties and reduces unauthorised promotion

C. It guarantees perfect model accuracy

D. It removes all operational latency

Correct Answer: B. It creates separation of duties and reduces unauthorised promotion

Question 8

Why should automatic retraining based solely on a drift threshold be treated cautiously?

A. Drift can never be measured statistically

B. Retraining may incorporate poisoned, biased, or low-quality feedback

C. Retraining always reduces performance

D. Models cannot be versioned after retraining

Correct Answer: B. Retraining may incorporate poisoned, biased, or low-quality feedback

Question 9

Which artefact best describes the components included in a software build?

A. A software bill of materials

B. A confusion matrix

C. A drift baseline

D. A service-level alert

Correct Answer: A. A software bill of materials

Question 10

During an AI incident, why might returning to an older model be unsafe?

A. Older models cannot be monitored

B. The older version may contain a known weakness or be invalid for current conditions

C. Rollback always destroys provenance

D. Older models require no infrastructure

Correct Answer: B. The older version may contain a known weakness or be invalid for current conditions