Every requirement, in full

The complete text of the AI Requirements Framework, version 3.6, last updated 2026-09-08. Every requirement is published with its rationale, the method by which it is verified, and the criteria that decide whether the verification succeeded. This is the same text as the deposited record; cite the framework at the concept DOI 10.5281/zenodo.19024420, not at this URL. The framework overview summarizes the thirteen areas, and Ask SCL answers questions grounded in this text.

• AI-1
• AI-2
• AI-3
• AI-4
• AI-5
• AI-6
• AI-7
• AI-8
• AI-9
• AI-10
• AI-11
• AI-12
• AI-13

AI-1 Operational and Data Foundations

The AI system will establish operational scope and data integrity sufficient to support reliable model behavior and a defensible certification claim throughout the model lifecycle.

AI-1.0 Operational Design Domain

The AI system shall declare an Operational Design Domain (ODD) that defines the operational conditions, inputs, users, subjects, regulatory context, and constraints under which the system is designed and validated to operate. The ODD declaration shall begin with an Operational Claim summary statement and shall address the eight attribute categories defined in Table 2.1.0-A at the declaration rigor established for the system’s classification in Table 1-4; Operational Support systems shall address, at minimum, the reduced category set specified there.

Rationale. AI systems trained against representative data perform reliably within the conditions represented in that data and become unreliable outside those conditions. Without an explicit declaration of operational scope, the certification claim is unbounded; the certificate appears to attest to system behavior under all conditions when verification evidence supports only a subset. ODD declaration establishes the operational envelope as a contractual element of the certification, scoping the certification claim to declared conditions and providing the basis from which downstream requirements are derived: dataset partitioning (AI-1.1), bias evaluation across subject populations (AI-2), operational input distribution testing (AI-3.3), output validity boundaries (AI-4.4), training distribution characterization (AI-6.1), and operational role verification (AI-9.6). ODD is the operational complement to system classification: classification establishes what the system is; ODD establishes where, for whom, and how it is intended to operate. Operational Claim: The ODD declaration shall begin with a single-sentence Operational Claim summarizing the scope of the certification: “This AI system is designed and validated to [function] for [subject population] under [operational conditions], operated by [user role] within [regulatory regime].” The Operational Claim is the elevator-summary of the ODD; the attribute categories below specify it in detail. The ODD declaration shall address the attribute categories defined in Table 2.1.0-A, at the coverage and rigor established for the system’s classification in Table 1-4. Exclusions shall be declared using the five exclusion sub-categories defined in Table 2.1.0-B. Threshold categories (Section 1.5) and operational input distributions (AI-3.3) shall be derived from and consistent with the declared ODD. Table 2.1.0-A: Required ODD Attribute Categories Downstream Requirements Category Description Examples Operational Environment Physical, spatial, atmospheric, and temporal conditions of operation Geographic scope, weather and atmospheric conditions, illumination and time-of-day ranges, terrain or surface types, ambient temperature ranges, care setting (medical), facility class AI-3.3, AI-6.1 System Inputs Sensor and data source characteristics, supported health states, input quality envelopes, and defined system behavior at degradation thresholds Sensor types and configurations, sensor health states under which operation is supported, data source provenance, input quality bounds, defined behavior (degraded mode, disengage, fallback, non-diagnostic message) when degradation thresholds are reached AI-3.3, AI-6.1, AI-9.4 User Population Operator qualifications, training, currency, authorized roles, and role within operational workflow Required operator certifications, systemspecific training, currency requirements, role-based authorization levels, supported team configurations, user role in the decision workflow (autonomous, decision support, advisory) AI-9.1, AI-9.3 Subject Population Populations or entities the AI’s decisions act upon, with validated subject characteristics and excluded subject conditions Validated patient demographics (medical), vehicle/pedestrian/cyclist populations the perception system handles (automotive), aircraft and obstacle classes (aviation), entity classes for surveillance or targeting systems AI-2, AI-3.3, AI-4.4 Downstream Requirements Category Description Examples Operational Phases Intended use cases, operational phase transitions, and phase-level constraints Supported workflow stages or AI-9.4, AI-9.6 mission segments, mode transition conditions, supported task categories, maximum phase or session duration, operational tempo (frequency, duty cycle, throughput per operator) Performance Envelope Per-decision performance limits and timing requirements Detection ranges, sensitivity and specificity, accuracy thresholds, decision latency, throughput bounds, confidence calibration error, computational resource availability AI-3.3, AI-4.2, AI-4.4, AI-8.3 Regulatory and Operational Authorization Applicable regulatory regime, required certifications, waivers, authorization conditions, and ODD evolvability under change control Governing regulatory framework (FAA Part 107, FDA SaMD class, ISO 26262 ASIL, EU AI Act risk class), required waivers or special authorizations, jurisdictional limitations, applicable industry standards, ODD evolvability declaration (locked at certification, or evolvable under defined change control mechanism such as FDA PCCP) All of Section 2 (foundational scoping) Exclusions Explicit out-ofSee Table 2.1.0-B for required scope conditions exclusion sub-categories under which the system shall not engage AI-4.4, AI-6.3, AI-9.1 Provenance: the ODD concept is adapted from SAE J3016 clause 3.16, which defined the Operational Design Domain for on-road driving automation; later automated-vehicle safety work including ISO 21448 and the ODD attribute taxonomy of ISO 34503 took the concept up, with analogous operational-envelope concepts in aviation guidance. AI-1.0 generalizes it into a domain-agnostic AI ODD declaration, adding the Operational Claim summary, the attribute categories of Table 2.1.0-A, the exclusion sub-categories of Table 2.1.0-B, and the framework-defined Subject Population and User Population distinction (Section 1.3.2). See the SAE J3016 standards profile for the full lineage. Note on Operational Phases vs. Performance Envelope: Operational Phases captures phase-level or mission-level constraints (duration, sequence, transitions, tempo). Performance Envelope captures per-decision performance (latency, throughput, accuracy at the inference level). Time-bounded attributes that describe the workflow or mission belong in Operational Phases; time-bounded attributes that describe individual inferences belong in Performance Envelope. Note on Subject Population: Not all systems have a distinct subject population from their user population. Where the AI acts on the user themselves (e.g., a personal recommendation system with no third-party subject), the Subject Population entry may state “Subject = User; see User Population.” Where subjects are abstract objects rather than people (e.g., obstacle detection in drones), Subject Population still applies and should declare the validated object classes. Table 2.1.0-B: Required Exclusion Sub-Categories Sub-Category Description Example Excluded Environments Environmental conditions outside the operational envelope Night operations, heavy precipitation, visibility below threshold, temperature extremes, terrain types not supported, deployment outside cleared jurisdiction Excluded Use Cases Mission types or operational scenarios outside intended use Aerobatic maneuvers, formation operations, payload drop, multi-system coordination, mission durations beyond validated bounds, screening use of a diagnostic-only system Excluded Operator Conditions Operator states, qualifications, or staffing configurations not supported Operators without current certification, operators below minimum currency, staffing below required minimum, nonradiologist users of a radiology decision support system Excluded Subject Conditions Subject populations or Pediatric patients in an adult-validated conditions outside medical system, pedestrians in validated scope wheelchairs or carrying large objects in a perception system not validated for those cases, subject conditions explicitly excluded from training data Excluded System States System or sensor degradation conditions that trigger automatic disengage or fallback

Verification. Sensor degradation beyond defined thresholds, communication loss conditions, computational resource exhaustion, image quality below threshold, GPS-denied conditions The AI system shall verify ODD declaration by inspection. The inspection shall confirm that the ODD declaration includes a single-sentence Operational Claim summary, that the declaration addresses all eight attribute categories required for the system’s classification per Section 1.2.3 Table 1-4, that quantitative bounds are documented where the attribute is measurable, that exclusions are explicitly enumerated using the five sub-categories defined in Table 2.1.0-B, that the ODD declaration is approved at the authority level specified for the system’s classification, and that downstream artifacts (operational input distributions per AI-3.3, training distribution characterization per AI-6.1, output validity boundaries per AI-4.4, bias evaluation populations per AI-2) are derived from and consistent with the declared ODD.

Success criteria. The verification shall be considered successful when the inspection shows that the Operational Claim is present and consistent with the detailed ODD, ODD declaration addresses all required attribute categories, quantitative bounds are documented where measurable, exclusions are explicitly enumerated using the required sub-categories, declaration is approved at the required authority level, and downstream artifacts are traceable to the declared ODD. ODD Maintenance: The ODD declaration shall be reviewed at the periodic intervals defined for operational role verification (AI-9.6). Identified divergence between declared ODD and actual operational use shall trigger formal ODD revision under the same authority structure as initial declaration. For systems declared as evolvable under a change control mechanism (e.g., FDA PCCP), ODD evolution shall follow the approved change control plan; ODD changes outside the approved plan shall require recertification.

AI-1.1 Dataset Separation

The AI system shall maintain separation between training, validation, and test datasets.

Rationale. Data leakage, which occurs when information from test or validation sets contaminates training data, produces artificially inflated performance metrics. A model that has “seen” test data during training will perform well on that data but may fail on novel operational inputs. Strict separation with technical enforcement ensures performance estimates reflect true generalization capability.

Verification. The AI system shall verify dataset separation by inspection. The inspection shall confirm dataset partitions are documented with unique identifiers, partition boundaries are enforced with technical controls (e.g., separate storage locations, access controls, automated pipeline checks), no data leakage exists between partitions, and partition integrity is verified prior to model training and evaluation.

Success criteria. The verification shall be considered successful when the inspection shows that dataset partitions are documented with unique identifiers, partition boundaries are enforced with technical controls, no data leakage exists between partitions, and partition integrity is verified prior to training and evaluation.

AI-1.2 Partition Use Restriction

The AI system shall ensure each dataset partition is used only for its intended purpose.

Rationale. Even with proper separation, using partitions incorrectly (e.g., using validation data for final testing, or repeatedly evaluating against test data during development) compromises the integrity of performance estimates. Restricting partition use to intended purposes and logging all access ensures data integrity is maintained throughout the development lifecycle.

Verification. The AI system shall verify partition use restriction by inspection and analysis. The inspection shall confirm intended use for each partition is documented (training for model fitting, validation for hyperparameter tuning and model selection, test for final performance evaluation). The analysis shall confirm access controls restrict partition use to authorized processes, audit logs capture dataset access and usage, and violation of intended use triggers alert and investigation.

Success criteria. The verification shall be considered successful when the inspection and analysis show that intended use for each partition is documented, access controls restrict partition use to authorized processes, audit logs capture access and usage, and violations trigger alerts and investigation.

AI-1.3 Data Provenance

The AI system shall document data provenance for all datasets used in model development.

Rationale. AI model behavior is a direct function of training data. Without documented provenance, the source, quality, and potential biases in training data cannot be assessed. Provenance documentation enables root cause analysis when model failures occur, supports retraining decisions, and provides traceability required for safety-critical systems.

Verification. The AI system shall verify data provenance by inspection. The inspection shall confirm data sources are identified and documented for each dataset, data collection methods are documented (including sensors, sampling rates, time periods, and environmental conditions), data transformations and preprocessing steps are recorded (including normalization, augmentation, filtering, and feature extraction), and provenance documentation is traceable to source records.

Success criteria. The verification shall be considered successful when the inspection shows that data sources are identified and documented, collection methods are documented, transformations and preprocessing are recorded, and provenance is traceable to source records.

AI-1.4 Ground Truth Labeling Quality

The AI system shall validate ground truth labeling quality for all supervised learning datasets.

Rationale. Supervised learning models learn to predict labels. If labels are incorrect, the model learns incorrect behavior. Label errors are particularly dangerous because they directly encode wrong answers into the model. For safety-critical applications, label quality must be validated through independent verification, as label errors could cause the model to make dangerous predictions with high confidence.

Verification. The AI system shall verify ground truth labeling quality by inspection and analysis. The inspection shall confirm labeling methodology and labeler qualifications are documented. The analysis shall confirm inter-rater reliability metrics meet defined thresholds for multi-labeler datasets (e.g., Cohen’s Kappa ≥ 0.8 for safety-critical applications), label accuracy is validated through spot-checking or independent verification for safety-critical applications, ambiguous or disputed labels are identified and resolved with documented rationale, and label error rate is estimated and its impact on model performance is assessed.

Success criteria. The verification shall be considered successful when the inspection and analysis show that labeling methodology and qualifications are documented, inter-rater reliability meets defined thresholds, label accuracy is validated for safety-critical applications, ambiguous labels are resolved with rationale, and label error rate impact is assessed.

AI-1.5 Pre-Ingestion Classification Screening

The AI system shall screen all data sources for information classification markings prior to ingestion into model training, fine-tuning, or retrieval-augmented generation (RAG) pipelines.

Rationale. AI training pipelines ingest data from diverse sources including government databases, technical repositories, contractor deliverables, sensor archives, and publicly available datasets. Any of these sources may contain data subject to information handling controls (CUI, ITAR, EAR, or other classification designations). Once controlled data is ingested into model training, the classification marking is permanently separated from the content. Pre-ingestion screening is the only reliable point at which to prevent classification loss, as no post-training mechanism exists to identify or remove controlled content from model parameters. This requirement establishes screening as a mandatory gate in the data pipeline, analogous to the partition integrity verification required by AI-1.1 prior to every training run.

Verification. The AI system shall verify pre-ingestion classification screening by inspection and analysis. The inspection shall confirm that a documented screening process exists for all data sources entering AI training, fine-tuning, or RAG pipelines; that screening criteria include CUI markings (per 32 CFR Part 2002 marking requirements), ITAR controlled technical data identifiers, EAR Export Control Classification Numbers (ECCNs), and any organization-specific classification markings; and that screening results are documented for each data source with disposition (approved, excluded, or approved with handling controls). The analysis shall confirm that automated screening tools are validated against known-positive controlled content at a project-defined detection rate threshold (see Section 5.1); that manual review procedures are defined for data sources where automated screening is insufficient; and that screening coverage is complete, and no data enters the training pipeline without a documented screening disposition.

Success criteria. The verification shall be considered successful when the inspection and analysis show that a documented screening process exists, screening criteria cover all applicable classification regimes, screening results are documented with disposition for each data source, automated tools are validated against known-positive content, manual review procedures exist for edge cases, and no data enters the pipeline without screening disposition.

AI-1.6 Information Classification Inheritance

The AI system shall document the information classification level of all training data and shall apply the principle that AI model artifacts and outputs inherit the highest classification level of the training data unless the training pipeline demonstrates, with verifiable evidence, that controlled content was excluded.

Rationale. In traditional information systems, data classification follows the data: a CUI document copied to a new system requires the new system to handle the copy as CUI. AI systems break this principle because the data transformation from documents to model weights destroys the classification metadata while retaining the controlled content. Without an explicit inheritance rule, the default assumption becomes that AI outputs are uncontrolled, which is incorrect when the training data included controlled content. This requirement establishes classification inheritance as the default, placing the burden of proof on the pipeline to demonstrate that controlled content was excluded rather than on the consumer to determine whether generated outputs contain controlled information. This is consistent with the derivative classification principle in information security: products derived from classified sources inherit the classification of the source material.

Verification. The AI system shall verify information classification inheritance by inspection and analysis. The inspection shall confirm that the classification level of all training datasets is documented in the data provenance record required by AI-1.3; that model artifacts (trained weights, serialized models, deployment packages) are marked with the inherited classification level; and that the classification inheritance determination is documented with justification, either inheriting the highest training data classification or certifying exclusion of controlled content with evidence. The analysis shall confirm that the classification inheritance chain is complete from data sources through model artifacts to deployment endpoint; that any claim of controlled content exclusion is supported by the screening evidence required by AI-1.5; and that downstream systems receiving model outputs are authorized to handle information at the inherited classification level.

Success criteria. The verification shall be considered successful when the inspection and analysis show that training data classification is documented in provenance records, model artifacts carry inherited classification markings, inheritance determination is documented with justification, the inheritance chain is complete, exclusion claims are supported by screening evidence, and downstream systems are authorized for the inherited classification level.

AI-1.7 Output Classification Awareness

The AI system shall implement mechanisms to ensure that consumers of AIgenerated outputs are aware of the information classification handling requirements applicable to those outputs.

Rationale. When an AI model trained on or exposed to controlled content generates outputs, those outputs may contain reconstructed controlled information. If the model operates at an inherited classification level per AI-1.6, all outputs must be handled at that level. However, the primary risk is that end users receive AI-generated content without any indication of applicable handling requirements. The user treats the output as uncontrolled general knowledge, copies it to uncontrolled systems, shares it with unauthorized recipients, or disseminates it to foreign persons, each constituting a potential violation of applicable regulations. This requirement ensures that classification awareness propagates to the point of consumption, not just the point of model storage. For ITAR technical data, failure to maintain this awareness constitutes a potential deemed export violation (22 CFR 120.17). For CUI, it violates dissemination controls established by the CUI Registry.

Verification. The AI system shall verify output classification awareness by test and analysis. The test shall confirm that AI-generated outputs include or are accompanied by applicable classification handling indicators appropriate to the output channel (e.g., CUI markings on documents, banner markings on display interfaces, metadata tags on programmatic outputs); that output classification indicators are consistent with the inherited classification level determined under AI-1.6; that classification indicators cannot be trivially stripped or bypassed by end users during normal operational use; and that when AI outputs are consumed by downstream systems or pipelines, classification metadata is propagated programmatically. The analysis shall confirm that output classification awareness mechanisms are appropriate for all operational output channels (display, document generation, API response, data export); that operator training materials address the classification handling requirements for AI-generated outputs; and that the output classification mechanism addresses the case where a model is queried by users at different authorization levels, ensuring outputs are appropriate to the requesting user’s authorization.

Success criteria. The verification shall be considered successful when the test and analysis show that outputs include classification handling indicators, indicators are consistent with the inherited classification level, indicators are not trivially bypassed, downstream propagation is implemented, all output channels are covered, operator training addresses output handling, and user authorization levels are respected in output generation.

AI-1.8 Classification Compliance Audit Trail

The AI system shall maintain an audit trail documenting classification screening decisions, inheritance determinations, output classification events, and any identified or suspected classification incidents throughout the AI system lifecycle.

Rationale. Regulatory compliance for CUI, ITAR, and EAR requires demonstrable evidence of proper handling. Traditional information systems maintain access logs and handling records. AI systems require analogous records covering the AIspecific aspects of information classification: what data was screened and what was the disposition, what classification level was inherited and on what basis, what outputs were generated at what classification level, and whether any incidents of suspected classification loss or improper dissemination occurred. Without this audit trail, an organization cannot demonstrate compliance during regulatory review, cannot scope the impact of a discovered classification incident, and cannot support the continuous improvement of classification controls. This requirement is the classification-specific complement to the human-AI interaction logging required by AI-9.5 and the OOD event logging required by AI-6.4.

Verification. The AI system shall verify classification compliance audit trail by inspection. The inspection shall confirm that pre-ingestion screening decisions are logged with timestamps, data source identifiers, screening method, and disposition; that classification inheritance determinations are logged with justification and authorizing authority; that output classification events are logged at a level sufficient to support incident investigation (including query context, output classification level applied, and output channel); that suspected classification incidents are logged with timestamps, discovery method, affected data scope estimate, and remediation actions; and that audit trail records are retained for a period consistent with applicable regulatory requirements (minimum retention periods per 32 CFR Part 2002 for CUI, ITAR record retention requirements per 22 CFR 122.5, and EAR record retention requirements per 15 CFR 762).

Success criteria. The verification shall be considered successful when the inspection shows that screening decisions are logged, inheritance determinations are logged with justification, output classification events are logged, suspected incidents are logged with remediation actions, and retention periods meet applicable regulatory requirements.

AI-1.9 AI Hazard Analysis Integration

The AI system shall be included in the system-level hazard analysis conducted under the project’s applicable system safety process, and that hazard analysis shall address the AI-specific failure mode categories identified in Section 5.2.2: datarelated, model-related, operational, adversarial, privacy, and human factors. Identified AI hazards shall trace to the framework requirements and project-defined thresholds that mitigate them, and hazard analysis outputs shall inform system classification (Section 1.2.2) and threshold selection (Section 1.5).

Rationale. The foundational principle of this framework is that requirements are defined by the failures they prevent. The hazard analysis is where a project enumerates those failures for its specific system, yet prior versions treated AI hazard analysis as informative guidance only. This requirement establishes the normative hook: it does not create a parallel hazard analysis process, but requires that the hazard analysis the project’s system safety process already mandates (FMEA, FMECA, FTA, STPA, or PRA per applicable domain practice) explicitly address AI-specific failure modes and connect its outputs to classification, threshold selection, and requirement tailoring. Section 5.2 provides implementation guidance for this integration.

Verification. The AI system shall verify AI hazard analysis integration by inspection and analysis. The inspection shall confirm that a system-level hazard analysis conducted under the project’s applicable system safety process exists and includes the AI system; that the analysis addresses each AI-specific failure mode category identified in Section 5.2.2 or documents the category as not credible for the system with rationale; and that the analysis is maintained current with the system configuration under change control. The analysis shall confirm that each identified AI hazard traces to the requirement or requirements and the threshold or thresholds that mitigate it, or to a documented risk acceptance, and that hazard analysis outputs are reflected in the system classification and in threshold justifications.

Success criteria. The verification shall be considered successful when the inspection and analysis show that the hazard analysis includes the AI system, addresses all AI-specific failure mode categories or documents non-credibility with rationale, remains current under change control, and traces identified hazards to mitigating requirements, thresholds, or documented risk acceptances. Applicable Domain Standards • General: ISO/IEC 23894:2023 (AI risk management); ISO 31000:2018 (Risk management principles) • Aviation: SAE ARP4761 (Guidelines for conducting the safety assessment process on civil airborne systems) • Automotive: ISO 26262-3:2018 Clause 6 (Hazard analysis and risk assessment); ISO 21448:2022 (Safety of the intended functionality) • Medical: ISO 14971:2019 (Application of risk management to medical devices) • Aerospace/Defense: NASA-STD-8739.8 (Software safety analysis); MIL-STD882E (System safety) • Cross-Domain: NIST AI RMF MAP function; STPA Handbook (Leveson and Thomas, 2018)

AI-1.10 Retrieval Corpus Controls

Where the AI system employs retrieval-augmented generation or otherwise incorporates retrieved content into model inputs or outputs at runtime, the retrieval corpus shall be subject to documented controls including: source provenance meeting the criteria of AI-1.3; content screening prior to corpus admission per AI-1.5; integrity protection and change control for corpus additions, modifications, and removals; and protection against corpus poisoning and indirect prompt injection per AI-7.1 and AI-7.2. Where retrieval augmentation is not used, this sub-requirement may be documented as Not Applicable with rationale.

Rationale. Retrieval augmentation moves behavior-determining content out of trained parameters and into a corpus that can change at runtime. A corpus change is functionally a model behavior change, but it bypasses the training pipeline controls of AI-1.1 through AI-1.4 unless the corpus is explicitly controlled. An uncontrolled corpus is also the entry point for indirect prompt injection, in which adversarial instructions embedded in retrieved content manipulate system outputs. This requirement extends the data foundation controls to the retrieval pathway so that corpus content receives the same provenance, screening, and integrity discipline as training data.

Verification. The AI system shall verify retrieval corpus controls by inspection and test. The inspection shall confirm that corpus sources are documented with provenance per AI-1.3; that each corpus source has a recorded screening disposition per AI-1.5; that corpus additions, modifications, and removals are executed under documented change control with an audit trail retained per AI-1.8; and that corpus access controls restrict modification to authorized processes and personnel. The test shall confirm that corpus modifications outside the change control process are detected and rejected or alerted, and that content containing known indirect prompt injection patterns is detected during screening or its influence on system outputs is bounded per the protections verified under AI-7.2.

Success criteria. The verification shall be considered successful when the inspection and test show that corpus provenance, screening dispositions, change control, and access controls are documented and operating, unauthorized corpus modifications are detected, and indirect prompt injection protections function as designed. Where retrieval augmentation is not used, AI-1.10 may be documented as Not Applicable with rationale. Applicable Domain Standards • General: NIST AI 600-1 (Generative AI Profile); NIST SP 800-53 Rev. 5 CM-3 (Configuration change control) and SI-7 (Software, firmware, and information integrity) • AI-Specific: OWASP Top 10 for LLM Applications LLM01 (Prompt injection); MITRE ATLAS AML.T0051 (LLM prompt injection); MITRE ATLAS AML.T0020 (Poison training data) • EU: EU AI Act Article 10 (Data and data governance); EU AI Act Article 15(5) (Resilience against adversarial inputs) • Cross-Domain: NIST AI RMF MAP-2.3 and MANAGE-3

AI-2 Addressing AI Bias

The AI system will implement bias detection, prevention, and mitigation mechanisms to provide equitable and unbiased decision-making across all applicable operational scenarios and applicable Subject Populations and User

AI-2.1 Bias-Bounded Baseline Performance

The AI system shall be baselined with performance disparities across user classes and operational contexts bounded within approved bias thresholds.

Rationale. Establishing baseline performance prior to deployment provides a reference point for continuous monitoring and enables detection of bias drift during operations. Without documented baselines, degradation in performance cannot be objectively measured or addressed.

Verification. The AI system shall verify bias-bounded baseline performance by analysis and test. The analysis shall confirm bias performance criteria, including approved disparity thresholds, are defined for all applicable user attributes and operational contexts relevant to the AI function. The test shall provide results congruent with defined bias performance criteria using validation datasets representative of operational conditions.

Success criteria. The verification shall be considered successful when the analysis and test show that bias-bounded baseline criteria are defined, test results meet defined criteria prior to operational deployment, and a validation report captures baseline values, threshold criteria, and threshold justification. Applicable Domain Standards • General: ISO/IEC TR 24027:2021 §6 (Bias assessment approaches); ISO/IEC 22989:2022 3.5.4 (Bias definition) • Aviation: FAA AI Safety Roadmap (equitable performance across operational demographics) p.8 (“Focus on Safety Assurance and Safety Enhancements” principle) • Automotive: UNECE WP.29 R157 (ALKS) performance consistency requirements §5.2 (Dynamic Driving Task) • Medical: FDA Draft Guidance on AI-Enabled Device Software Functions (2025) Section VIII (Data Management), Section X.A (Performance Validation), and Appendix C (Performance Validation Considerations); FDA Digital Health Policy Navigator • EU: EU AI Act Article 10(2)(f) (bias examination and correction); EU AI Act Article 10(3) (training data representativeness); EU AI Act Article 15(3) (performance across demographic groups) • Consumer/Employment (where applicable): EEOC AI Technical Assistance (2023) • Cross-Domain: NIST AI RMF MANAGE-2.3; NIST SP 1270:2022 (Taxonomy of AI Bias)

AI-2.2 Bias-Managed Training Data

The AI system shall use training datasets that account for underrepresented groups, historical biases, and labeling errors.

Rationale. Training data quality directly determines AI system behavior. Datasets with underrepresented groups, historical biases, or labeling errors will produce models that perpetuate those biases.

Verification. The AI system shall verify bias-managed training data by inspection. The inspection shall confirm training datasets document representation across applicable user classes and operational contexts, known historical biases are identified and addressed, and labeling methodology includes quality controls.

Success criteria. The verification shall be considered successful when the inspection shows that training data representation is documented, historical biases are identified and addressed, and labeling quality controls are documented.

AI-2.3 Training Dataset Validation

The AI system shall validate training datasets that could impact Safety-Critical or Mission-Critical decisions.

Rationale. Validation of training datasets prior to model development confirms that the training data bias management requirements (AI-2.2) have been met and provides documented evidence for verification closure.

Verification. The AI system shall verify training dataset validation by inspection and analysis. The inspection shall confirm training datasets do not contain data that contributes to biases such as underrepresented groups, historical biases, or labeling errors. The analysis shall quantify representation across applicable user classes and operational contexts and confirm absence of known bias patterns. Where absence cannot be confirmed, the analysis shall include a risk assessment due to included bias and provide a mitigation strategy for reducing the risk.

Success criteria. The verification shall be considered successful when the inspection confirms training datasets do not contain bias-contributing data, and the analysis confirms either absence of known bias patterns or documented risk assessment with mitigation strategy.

AI-2.4 Continuous Bias Monitoring

The AI system shall implement continuous bias monitoring appropriate to the operational context.

Rationale. AI system bias can emerge or amplify during operations due to data drift, changing operational contexts, or feedback loops. Continuous monitoring enables early detection of bias before it impacts safety or operational success. Monitoring frequency and methods should scale with system classification and decision criticality.

Verification. The AI system shall verify continuous bias monitoring by test. The test shall confirm continuous bias monitoring is operational and metrics are maintained within approved thresholds.

Success criteria. The verification shall be considered successful when the test shows that continuous bias monitoring is operational, and metrics are maintained within approved thresholds.

AI-2.5 Bias Impact Assessment

The AI system shall conduct bias impact assessments for all AI decisions affecting human safety, resource allocation, mission planning, and operational procedures.

Rationale. Not all AI decisions carry equal risk of harm from bias. Impact assessments ensure that bias mitigation efforts are prioritized for decisions with the greatest potential consequences for safety and operational success.

Verification. The AI system shall verify bias impact assessments by analysis and test. The analysis shall document bias impact assessments for each decision category and ensure assessment methodology is traceable to defined criteria. The test shall confirm assessment results inform mitigation strategies prior to deployment.

Success criteria. The verification shall be considered successful when the analysis and test show that bias impact assessments are documented for each decision category, assessment methodology is traceable to defined criteria, and results inform mitigation strategies prior to deployment.

AI-2.6 Bias Indicator Definition

The AI system shall define bias indicators and thresholds for each AI function.

Rationale. Bias detection requires defined metrics (indicators) and acceptance boundaries (thresholds). Without explicit definition, bias detection is subjective and unverifiable.

Verification. The AI system shall verify bias indicator definition by inspection. The inspection shall confirm bias indicators are defined for each AI function, threshold values are defined and justified for each indicator, and threshold derivation rationale is documented.

Success criteria. The verification shall be considered successful when the inspection shows bias indicators are defined, thresholds are defined and justified, and derivation rationale is documented.

AI-2.7 Bias Threshold Alerting

The AI system shall generate alerts when bias indicators exceed predefined thresholds.

Rationale. Detection without notification provides no opportunity for response. Alerts enable operators and systems to respond to detected bias conditions.

Verification. The AI system shall verify bias threshold alerting by test. The test shall confirm alerts are generated when bias indicators exceed thresholds and alerts are delivered to designated recipients within specified latency limits.

Success criteria. The verification shall be considered successful when the test shows alerts are generated when thresholds are exceeded and alerts are delivered within latency limits.

AI-2.8 Bias Threshold Response

The AI system shall provide bias-corrected decision pathways and alternative recommendations when bias indicators exceed predefined thresholds.

Rationale. Detection and alerting without corrective action provides no protection. This requirement ensures the system has predefined corrective actions when bias is detected.

Verification. The AI system shall verify bias threshold response by test. The test shall confirm bias-corrected pathways are invoked when thresholds are exceeded and alternative recommendations are presented.

Success criteria. The verification shall be considered successful when the test shows bias-corrected pathways are invoked and alternative recommendations are presented when thresholds are exceeded.

AI-2.9 Bias Event Logging

The AI system shall log bias detection events, corrective actions taken, and decision rationale to support accountability and post-mission analysis.

Rationale. Logs provide accountability and enable post-mission analysis to improve future AI systems. Without comprehensive logging, bias events cannot be reconstructed for root cause analysis or used to improve subsequent model versions.

Verification. The AI system shall verify bias event logging by inspection. The inspection shall confirm logs record bias detection events with timestamps, logs capture metrics, decision context, mitigation actions, and operator inputs, logs are immutable and retrievable for post-mission analysis, and log schema documentation is complete.

Success criteria. The verification shall be considered successful when the inspection shows that logs record bias detection events with timestamps, logs capture all required information, logs are immutable and retrievable, and log schema documentation is complete.

AI-2.10 Safety-Critical Bias Prohibition

The AI system shall implement controls to prevent detected bias from adversely impacting safety-critical operations or human safety.

Rationale. Bias affecting safety-critical functions poses unacceptable risk. This requirement establishes the fundamental constraint that detected bias must be prevented from affecting safety-critical decisions, with escalation and override as the enforcement mechanism.

Verification. The AI system shall verify safety-critical bias prohibition by analysis and test. The analysis shall identify all AI decision points that affect safety-critical operations. The test shall confirm that detected bias at safety-critical decision points triggers protective action preventing biased outputs from affecting safety-critical operations.

Success criteria. The verification shall be considered successful when the analysis identifies safety-critical decision points and the test confirms bias detection triggers protective action at those points.

AI-2.11 Safety-Critical Bias Escalation

The AI system shall escalate any bias detection that would adversely impact safety-critical operations or human safety for immediate human review and potential system override with documented rationale, or, where the approved autonomy level (AI-9.1) or disconnected operations (AI-4.6) preclude timely human review, shall execute the defined fallback response with the escalation logged for human review at the next available opportunity.

Rationale. Bias affecting safety-critical functions requires immediate human intervention. Autonomous continuation in the presence of detected safety-critical bias could result in harm. This requirement ensures human authority is maintained over safety-critical AI decisions per AI-9.1 (Human Decision Authority).

Verification. The AI system shall verify safety-critical bias escalation by test. The test shall simulate safety-critical bias scenarios and confirm mandatory human review states are triggered, or the defined fallback response executes where approved autonomy or disconnected operations preclude timely human review, autonomous execution is blocked until review or fallback completes, system override capability is functional, and escalation logs capture review decisions and rationale.

Success criteria. The verification shall be considered successful when the test shows that safety-critical bias scenarios trigger mandatory human review, or the defined fallback response where human review is precluded, autonomous execution is blocked until review or fallback completes, system override capability is functional and documented, and escalation logs capture review decisions and rationale.

AI-2.12 Bias Edge Case Definition

The AI system shall define edge-case datasets and stress scenarios for bias validation.

Rationale. Edge cases and stress conditions represent operational boundaries where bias is most likely to emerge but least likely to be represented in training data. Explicit definition of edge cases ensures systematic coverage during validation rather than ad-hoc testing.

Verification. The AI system shall verify bias edge case definition by inspection. The inspection shall confirm edge-case datasets are defined and documented, stress scenarios are defined and documented, and edge cases address operational boundaries and conditions underrepresented in training data.

Success criteria. The verification shall be considered successful when the inspection shows that edge-case datasets and stress scenarios are defined and documented.

AI-2.13 Bias Edge Case Validation

The AI system shall validate bias performance under defined edge cases and stress scenarios.

Rationale. Bias may not manifest under nominal conditions but emerge at operational boundaries or under stress. Validation across edge cases ensures the system maintains performance within approved bias thresholds even in conditions that may not be well-represented in training data.

Verification. The AI system shall verify bias edge case validation by test. The test shall confirm bias metrics remain within acceptable bounds under defined edge cases and stress scenarios, or threshold exceedances trigger defined mitigation.

Success criteria. The verification shall be considered successful when the test shows bias metrics remain within acceptable bounds under edge cases and stress scenarios, or exceedances trigger defined mitigation.

AI-3 ML Test Coverage

The AI system will demonstrate adequate test coverage for machine learning models using methods appropriate to data-driven systems where traditional code coverage metrics do not apply.

AI-3.1 Test Coverage Metric Definition

The AI system shall define test coverage metrics appropriate to each ML model type.

Rationale. Different ML model types require different coverage approaches. For image classifiers, coverage might focus on variations in lighting, angle, and occlusion. For time-series predictors, coverage might address temporal patterns, seasonality, and anomalies. Metrics must be justified based on model architecture and mission criticality to ensure testing is meaningful rather than merely comprehensive in volume.

Verification. The AI system shall verify test coverage metric definition by inspection. The inspection shall confirm test coverage metrics are defined for each ML model, metrics are justified based on model type and mission criticality, coverage metrics address input space, edge cases, and operational scenarios, and rationale for metric selection is documented.

Success criteria. The verification shall be considered successful when the inspection shows that test coverage metrics are defined for each ML model, metrics are justified based on model type and criticality, coverage addresses input space, edge cases, and operational scenarios, and rationale is documented.

AI-3.2 Test Coverage Threshold Achievement

The AI system shall achieve defined test coverage thresholds prior to operational deployment.

Rationale. Defining metrics without achieving them provides no assurance. Coverage thresholds should be established based on system classification: SafetyCritical AI requires higher coverage thresholds than Operational Support AI. Coverage gaps must be identified and dispositioned with documented rationale, either by additional testing or by risk acceptance with mitigation.

Verification. The AI system shall verify test coverage threshold achievement by analysis and test. The analysis shall confirm coverage thresholds are defined and documented with justification based on system classification and mission risk tolerance. The test shall execute test cases to achieve required coverage levels, identify and document any coverage gaps, and disposition gaps through additional testing or documented risk acceptance.

Success criteria. The verification shall be considered successful when the analysis and test show that coverage thresholds are defined and documented, test execution achieves required coverage levels, coverage gaps are identified and dispositioned, and coverage reports are retained as verification evidence.

AI-3.3 Operational Input Distribution Testing

The AI system shall test ML models across representative operational input distributions.

Rationale. ML models perform well on data similar to their training data but may fail on data that differs from training distributions. Testing must cover the full range of inputs expected during actual operations, including nominal conditions, offnominal conditions, and mission phase transitions. Gaps between test and operational distributions represent untested regions where model behavior is uncertain. Operational input distributions shall be derived from the declared ODD (AI-1.0).

Verification. The AI system shall verify operational input distribution testing by test. The test shall confirm operational input distributions are characterized and documented based on mission analysis and operational scenarios, test datasets represent the full range of expected operational inputs, model performance is validated across the operational input space, and gaps between test and operational distributions are identified and mitigated through additional test data collection, synthetic data generation, or documented risk acceptance.

Success criteria. The verification shall be considered successful when the test shows that operational input distributions are characterized, test datasets represent the full operational range, model performance is validated across the input space, and distribution gaps are identified and mitigated.

AI-3.4 Boundary And Edge Case Testing

The AI system shall perform boundary and edge case testing for all ML models.

Rationale. ML models often fail at input boundaries: values at the edges of the training distribution or combinations of inputs not well-represented in training data. Edge cases are particularly important for safety-critical functions because they represent conditions where model behavior is least certain. Systematic boundary testing ensures the model behaves acceptably at operational limits.

Verification. The AI system shall verify boundary and edge case testing by test. The test shall confirm input boundaries are defined for each ML model based on operational constraints and physical limits, edge cases are identified and documented through systematic analysis (e.g., equivalence partitioning, boundary value analysis adapted for ML), model behavior at boundaries is tested and acceptable, and edge case test results are recorded with pass/fail criteria.

Success criteria. The verification shall be considered successful when the test shows that input boundaries are defined for each ML model, edge cases are identified and documented, model behavior at boundaries is tested and acceptable, and test results are recorded with pass/fail criteria.

AI-4 Continuous Validation

The AI system will implement continuous validation processes to ensure model performance remains within acceptable bounds throughout operational deployment. AI model performance can degrade during operations due to data drift, concept drift, or environmental changes. Continuous validation detects performance degradation before it impacts safety or operational success, enabling timely corrective action such as model retraining, threshold adjustment, or fallback to manual operations. Applicable Domain Standards • General: ISO/IEC 5338:2023 §6.4.14; ISO/IEC 22989:2022 5.11.9 • Aviation: FAA AI Safety Roadmap (operational monitoring) • Automotive: ISO 21448:2022 §13 (Field monitoring); UNECE WP.29 R157 (ALKS) §5.2 (Dynamic Driving Task) • Medical: FDA PCCP Guidance (2023); FDA AI/ML-Based SaMD Action Plan §5 (Real-World Performance) • EU: EU AI Act Article 17 (Quality management system); EU AI Act Article 72 (Post-market monitoring) • Cross-Domain: NIST AI RMF MEASURE-3; NIST AI RMF MEASURE-4

AI-4.1 Data Drift Monitoring

The AI system shall monitor for data drift that could cause inaccurate decisions or predictions.

Rationale. Data drift occurs when the statistical characteristics of production data diverge from the training data distribution. Sensor degradation, environmental changes, or novel operational scenarios can cause inputs to shift from what the model was trained on, leading to degraded prediction accuracy. Without drift detection, performance degradation may go unnoticed until a critical failure occurs.

Verification. The AI system shall verify data drift monitoring by test. The test shall confirm data drift detection mechanisms are implemented and operational, drift is measured against baseline training data distributions using defined statistical methods (e.g., KL divergence, population stability index), drift metrics are logged with timestamps, and alerts are generated when drift exceeds defined thresholds.

Success criteria. The verification shall be considered successful when the test shows that data drift detection mechanisms are operational, drift is measured against baseline distributions, drift metrics are logged with timestamps, and alerts are generated when drift exceeds defined thresholds.

AI-4.2 Performance Threshold Maintenance

The AI system shall maintain model performance above defined thresholds throughout operation.

Rationale. AI model performance can degrade over time even without data drift through concept drift, model staleness, or accumulated edge cases. Continuous performance monitoring against defined thresholds provides early warning of degradation before it impacts operational success or safety. Threshold values should be derived from mission risk tolerance per Section 5.1 (Threshold Selection Guidance).

Verification. The AI system shall verify performance threshold maintenance by analysis and test. The analysis shall confirm performance thresholds are defined and justified based on mission risk tolerance, and that performance metrics are appropriate to the AI function (e.g., accuracy, precision, recall, F1 score, domain-specific metrics). The test shall confirm performance metrics are continuously computed during operation, performance degradation below threshold triggers defined mitigation response, and performance logs are maintained for trend analysis.

Success criteria. The verification shall be considered successful when the analysis and test show that performance thresholds are defined and justified, performance metrics are continuously computed, degradation below threshold triggers mitigation response, and performance logs support trend analysis.

AI-4.3 Model Maintenance Criteria

The AI system shall define criteria for model maintenance, retraining, or version updates when performance deviates beyond acceptable bounds.

Rationale. When continuous monitoring detects performance degradation, the system must have predefined response procedures. Without documented criteria for when and how to update models, operators may allow degraded performance to continue or may apply ad-hoc fixes that introduce new risks. This requirement ensures maintenance decisions are systematic and traceable. Model maintenance changes also invoke the model integrity controls established under AI-7.4 and the deployment format validation established in AI-4.7; these three control points apply in concert whenever a deployed model is updated.

Verification. The AI system shall verify model maintenance criteria by inspection. The inspection shall confirm retraining and update trigger criteria are documented, version control procedures exist for model updates, regression testing requirements are defined for updated models, and change history is maintained with rationale for each update.

Success criteria. The verification shall be considered successful when the inspection shows that retraining/update trigger criteria are documented, version control procedures exist, regression testing requirements are defined, and change history with rationale is maintained.

AI-4.4 Output Validity Boundaries

The AI system shall define and enforce boundaries for output data validity.

Rationale. AI systems can produce outputs that are technically valid (within data type constraints) but operationally invalid (physically impossible, outside safe operating ranges, or inconsistent with known constraints). Output boundary enforcement provides a safety envelope that catches erroneous outputs regardless of the internal cause, whether from drift, adversarial inputs, or model failure. Operational limits that bound acceptable outputs shall be derived from the Performance Envelope and Exclusions declared under AI-1.0.

Verification. The AI system shall verify output validity boundaries by test. The test shall confirm output boundaries are defined for each AI function based on physical constraints, operational limits, and safety margins. The test shall inject inputs designed to produce boundary-case outputs and confirm outputs exceeding boundaries are flagged or rejected, boundary violations are logged with context, and out-of-bounds outputs do not propagate to downstream systems without human review or invocation of defined fallback behavior.

Success criteria. The verification shall be considered successful when the test shows that output boundaries are defined for each AI function, outputs exceeding boundaries are flagged or rejected, boundary violations are logged, and out-ofbounds outputs do not propagate without human review or fallback behavior.

AI-4.5 Periodic Model Validation

The AI system shall perform model validation at defined intervals and maintain baseline validation scores.

Rationale. Continuous monitoring of individual metrics may not capture gradual, systemic degradation. Periodic comprehensive validation against baseline scores provides a systemic check that the model continues to perform as originally validated. Validation frequency should scale with system classification and operational tempo.

Verification. The AI system shall verify periodic model validation by test. The test shall confirm validation frequency is defined and justified based on system classification and mission profile, validation executes automatically at specified intervals, validation scores are compared against baseline thresholds, and validation failures trigger defined response procedures.

Success criteria. The verification shall be considered successful when the test shows that validation frequency is defined and justified, validation executes automatically at specified intervals, validation scores are compared against baselines, and validation failures trigger defined response procedures.

AI-4.6 Operational Validation Without Ground Truth

The AI system shall define and justify proxy validation mechanisms for operational environments where ground truth data is unavailable or inaccessible.

Rationale. AI-4 requirements assume continuous validation against known correct outputs. This assumption holds during development and in connected operational environments where labeled data or authoritative reference sources remain accessible. However, many safety-critical operational contexts lack ground truth entirely: disconnected systems, autonomous platforms, deep space missions, submarine operations, or any environment where the “correct answer” cannot be independently determined in real time. In these environments, validation must rely on proxy mechanisms that provide evidence of continued reliable performance without direct comparison to ground truth. These proxies include output boundary enforcement (per AI-4.4), statistical drift detection against baseline distributions (per AI-4.1), independent cross-validation using dissimilar methods (per AI-5.5), and temporal consistency checks against the system’s own recent output history. The selection and sufficiency of proxy mechanisms are context dependent. A system operating autonomously for hours faces different validation challenges than one operating autonomously for months. Projects shall document which proxy mechanisms apply, justify why those proxies are sufficient for the specific operational context and duration, and define the conditions under which proxy validation is no longer adequate and operations should be suspended or degraded.

Verification. The AI system shall verify operational validation without ground truth by inspection and analysis. The inspection shall confirm the operational environment is characterized with respect to ground truth availability, proxy validation mechanisms are identified and documented for each AI function operating without ground truth, and the justification for proxy sufficiency is documented with traceability to operational context, mission duration, and system classification. The analysis shall confirm selected proxy mechanisms collectively address performance degradation detection, output validity assurance, and behavioral consistency monitoring; that the analysis identifies conditions under which proxy validation is insufficient and documents the required system response (degraded mode, human escalation, or operational suspension); and that proxy validation coverage is assessed against the operational timeline to confirm adequacy for the expected duration of ground truth unavailability.

Success criteria. The verification shall be considered successful when the inspection and analysis show that the operational environment is characterized for ground truth availability, proxy mechanisms are documented and justified, proxy coverage addresses degradation detection, output validity, and behavioral consistency, insufficiency conditions are defined with required system response, and proxy adequacy is confirmed for the expected operational duration.

AI-4.7 Deployment Format Validation

The AI system shall revalidate deployment-format models against the original trained model before operational use, where deployment-format models are produced through transformations such as quantization, pruning, knowledge distillation, or framework conversion.

Rationale. Model transformations applied for deployment can introduce numerical, accuracy, or behavioral drift relative to the originally validated model. Without explicit revalidation, an artifact that passed all training-time verification may exhibit degraded or unsafe behavior at runtime, a gap not closed by retraining triggers (AI-4.3) or load-time integrity checks (AI-7.4). Side-by-side comparison on representative data establishes that the deployed artifact retains its validated properties. Common transformations requiring revalidation include: • Quantization: reducing model precision (e.g., FP32 to INT8) to enable execution on resource-constrained hardware. • Pruning: removing model weights, neurons, or layers to reduce computational cost. • Knowledge distillation: training a smaller model to approximate the behavior of a larger original. • Format conversion: converting between frameworks (e.g., PyTorch to ONNX to TensorRT) for runtime compatibility.

Verification. The AI system shall verify deployment format validation by test. The test shall demonstrate that the deployment-format model meets all performance thresholds established for the original trained model under representative test conditions. Performance degradation attributable to the transformation shall be documented and accepted within margins established per Section 5.1 (Threshold Selection Guidance), or the transformation shall be revised. Verification evidence shall include side-by-side performance comparisons on representative test datasets covering the declared Operational Design Domain. Deployment Format Validation operates as a control point complementary to Model Maintenance Criteria (AI-4.3) and Model Integrity (AI-7.4); a deployed transformation shall satisfy all three before operational use.

Success criteria. The verification shall be considered successful when the test shows that the deployment-format model meets or exceeds all performance thresholds established for the original trained model under representative test conditions, performance deltas are documented and accepted per Section 5.1, and the verification evidence is retained per AI-1.8 (Classification Compliance Audit Trail). Applicable Domain Standards • Aerospace: NPR 7150.2D §4 (Software Lifecycle Processes including Verification and Validation); NASA-STD-8739.8B (Software Assurance) • Aviation: DO-178C §6.4 (Software Testing) and §11.5 (Verification of Verification Process Results) • Automotive: ISO 26262-6:2018 §11 (Testing of the embedded software); ISO 21448:2022 §12 (Evaluation of the achievement of the SOTIF) • Medical: IEC 62304:2006+A1:2015 §5.7 (Software system testing) and §5.8 (Software release) • Industrial: ISO 13849-1 (Functional safety of control systems)

AI-5 Hallucination Prevention

The AI system will implement mechanisms to detect, prevent, and mitigate AI outputs that are fabricated, unsupported by input data, or inconsistent with operational reality. Rationale: AI systems, particularly neural networks and generative models, can produce outputs that appear valid but are completely fabricated or contradicted by physical reality. NIST AI 600-1 defines hallucination as “the production of confidently stated but erroneous or false content.” Unlike traditional software bugs that produce obviously wrong outputs (e.g., null values, exceptions), hallucinations appear plausible and may not trigger conventional error handling.

AI-5.1 Hallucination Criteria Definition

The AI system shall define what constitutes a hallucination within the operational context.

Rationale. Hallucination is context-dependent. An output that would be a hallucination in one domain may be valid in another. For example, a predicted temperature of -270°C would be valid near absolute zero but a hallucination for cabin temperature. Defining mission-specific hallucination criteria enables automated detection and ensures operators understand when an output should be considered unreliable. Ground truth baselines provide authoritative reference points against which outputs can be validated.

Verification. The AI system shall verify hallucination criteria definition by inspection. The inspection shall confirm hallucination criteria are defined for each AI function, criteria include outputs outside expected bounds, contradictory outputs, and outputs unsupported by inputs, definition is traceable to mission-specific operational constraints, examples of hallucination versus valid edge-case outputs are documented, and ground truth baselines are established for each AI function including authoritative data sources, physical constraints and conservation laws, cross-validation with independent sensors or systems, and operator-verified reference datasets.

Success criteria. The verification shall be considered successful when the inspection shows that hallucination criteria are defined for each AI function, criteria address bounds violations, contradictions, and unsupported outputs, definitions are traceable to operational constraints, examples distinguish hallucinations from valid edge cases, and ground truth baselines are established.

AI-5.2 Hallucination Detection

The AI system shall implement detection mechanisms for hallucinated outputs.

Rationale. Once hallucination criteria are defined, automated detection mechanisms can identify suspect outputs before they propagate to downstream systems or influence decisions. Detection should occur at inference time, not just during post-mission analysis, to prevent real-time operational impact. Detection mechanisms may include consistency checks, physical constraint validation, cross-sensor comparison, or confidence thresholding.

Verification. The AI system shall verify hallucination detection by test. The test shall confirm detection algorithms are implemented for each AI function, detection mechanisms identify outputs meeting hallucination criteria, detection is performed prior to output delivery to downstream systems, and detection performance is validated against known hallucination test cases including injected hallucinations that violate physical constraints, contradict sensor inputs, or fall outside valid operating ranges.

Success criteria. The verification shall be considered successful when the test shows that detection algorithms are implemented for each AI function, detection identifies outputs meeting hallucination criteria, detection occurs prior to downstream delivery, and detection performance is validated against known test cases.

AI-5.3 Hallucination Response

The AI system shall prevent hallucinated outputs from being acted upon without human review or defined fallback behavior appropriate to the AI function’s criticality.

Rationale. Detection without response provides no protection. When a potential hallucination is detected, the system must prevent autonomous action based on that output, either escalating to human review or invoking defined fallback behavior, consistent with the response pattern established for out-of-distribution inputs (AI-6.3). This ensures either human judgment or a validated safe response is applied before potentially erroneous AI outputs influence safety-critical decisions. The response should be proportionate to the criticality of the AI function and the confidence of hallucination detection.

Verification. The AI system shall verify hallucination response by test. The test shall inject hallucinated outputs and confirm detected hallucinations are flagged and quarantined, autonomous execution is blocked for flagged outputs, human review workflow is triggered or defined fallback behavior is invoked for flagged outputs as required by system classification, and override requires documented rationale.

Success criteria. The verification shall be considered successful when the test shows that detected hallucinations are flagged and quarantined, autonomous execution is blocked, human review workflow is triggered or defined fallback behavior is invoked as required by system classification, and override requires documented rationale.

AI-5.4 Hallucination Logging

The AI system shall log all detected hallucinations for post-mission analysis.

Rationale. Comprehensive logging of hallucination events enables post-mission analysis to identify patterns, root causes, and potential model improvements. Logs support trend analysis to determine if hallucination frequency is increasing (indicating model degradation) and provide evidence for retraining decisions. Logging also supports accountability and incident investigation.

Verification. The AI system shall verify hallucination logging by inspection. The inspection shall confirm hallucination events are logged with timestamps, inputs, and outputs, logs capture detection method and confidence, logs capture human review decision and rationale, and logs are retrievable for trend analysis and model improvement.

Success criteria. The verification shall be considered successful when the inspection shows that hallucination events are logged with timestamps, inputs, and outputs, logs capture detection method, confidence, and human review decisions, and logs are retrievable for trend analysis.

AI-5.5 Independent Output Validation

The AI system shall validate AI outputs affecting safety-critical or mission-critical functions against an independent source prior to execution.

Rationale. For safety-critical functions, relying solely on the AI system’s internal consistency checks is insufficient; an AI can produce confidently wrong outputs that pass its own validation. Independent validation using dissimilar methods, sensors, or processing provides a defense-in-depth layer that can catch errors the primary AI cannot detect. The independent source must not share common failure modes with the primary AI to ensure that a single fault (e.g., corrupted sensor data, adversarial input, systematic model error) cannot defeat both the primary output and its validation.

Verification. The AI system shall verify independent output validation by analysis and test. The analysis shall identify independent validation sources for each safety-critical AI output and confirm validation sources use dissimilar methods, sensors, or processing from the primary AI. The analysis shall demonstrate that independent validation does not share common failure modes with the primary AI, including common training data sources, common sensor inputs, common processing hardware, or common software dependencies. The test shall inject discrepancies between AI output and independent validation sources and confirm discrepancies trigger human review or defined fallback behavior, the system does not execute safety-critical actions when validation fails, and validation latency meets operational timing requirements.

Success criteria. The verification shall be considered successful when the analysis and test show that independent validation sources are identified for each safetycritical AI output, validation sources use dissimilar methods from the primary AI, discrepancies trigger human review or fallback behavior, and independent validation does not share common failure modes with the primary AI.

AI-6 Out-of-Distribution Detection

The AI system will detect and appropriately handle inputs that fall outside the distribution of training data. ML models are only reliable within the distribution of data they were trained on.

AI-6.1 Training Distribution Characterization

The AI system shall characterize the training data distribution for each ML model.

Rationale. OOD detection requires knowing what “in-distribution” looks like. Characterizing the training data distribution provides the baseline against which operational inputs are compared. Documentation should include statistical measures (mean, variance, range, density estimates) that enable automated OOD detection at runtime. Without explicit distribution characterization, OOD detection cannot be implemented systematically. The distribution shall be characterized within the scope declared under AI-1.0; characterization need not extend beyond the declared Operational Environment and Subject Population.

Verification. The AI system shall verify training distribution characterization by inspection. The inspection shall confirm training data distribution is documented for each model, distribution boundaries and characteristics are defined including statistical measures (e.g., mean, variance, covariance, range, density estimates), documentation includes statistical measures of distribution properties sufficient to support runtime OOD detection, and distribution characterization is traceable to training datasets.

Success criteria. The verification shall be considered successful when the inspection shows that training data distribution is documented for each model, distribution boundaries and characteristics are defined, statistical measures are documented, and characterization is traceable to training datasets.

AI-6.2 Runtime Ood Detection

The AI system shall implement mechanisms to detect out-of-distribution inputs at runtime.

Rationale. OOD detection must occur during operation, not just during development testing. Runtime detection mechanisms compare incoming inputs against the characterized training distribution and flag inputs that fall outside defined boundaries. Detection methods may include statistical distance measures (Mahalanobis distance), density estimation, ensemble disagreement, or dedicated OOD detection models. Detection must meet operational timing requirements to enable timely response.

Verification. The AI system shall verify runtime OOD detection by test. The test shall confirm OOD detection mechanisms are implemented for each ML model, detection correctly identifies inputs outside training distribution using defined statistical methods, detection performance is validated against known OOD test cases including both synthetic OOD inputs and realistic operational scenarios, and detection latency meets operational timing requirements for the AI function.

Success criteria. The verification shall be considered successful when the test shows that OOD detection mechanisms are implemented for each model, detection correctly identifies OOD inputs, detection is validated against known test cases, and latency meets operational timing requirements.

AI-6.3 Ood Response

The AI system shall prevent autonomous action on out-of-distribution inputs without human review or defined fallback behavior.

Rationale. Detecting OOD inputs without a defined response provides no protection. When an input is flagged as OOD, the system must either escalate to human review or invoke predefined fallback behavior appropriate to the AI function’s criticality. Autonomous execution based on potentially unreliable OOD predictions could lead to hazardous outcomes. The response should be proportionate to system classification: Safety-Critical AI may require mandatory human review, while Operational Support AI may use automated fallback.

Verification. The AI system shall verify OOD response by test. The test shall inject OOD inputs and confirm OOD inputs trigger defined response procedures, autonomous execution is blocked or fallback behavior is invoked, human review workflow is available for OOD conditions when required by system classification, and system behavior for OOD inputs is documented and tested across all defined OOD scenarios.

Success criteria. The verification shall be considered successful when the test shows that OOD inputs trigger defined response procedures, autonomous execution is blocked or fallback is invoked, human review workflow is available when required, and OOD behavior is documented and tested.

AI-6.4 Ood Event Logging

The AI system shall log all out-of-distribution detection events.

Rationale. OOD events provide valuable information about operational conditions that differ from training assumptions. Logging enables post-mission analysis to identify patterns, assess whether the operational environment has shifted from training assumptions, and inform decisions about model retraining or operational envelope expansion. OOD logs also support trend analysis to detect gradual distribution shift that might indicate data drift.

Verification. The AI system shall verify OOD event logging by inspection. The inspection shall confirm OOD events are logged with timestamps and input data (or input characterization sufficient for analysis), logs capture detection confidence and method, logs capture system response and operator actions, and logs are retrievable for trend analysis and model improvement.

Success criteria. The verification shall be considered successful when the inspection shows that OOD events are logged with timestamps and input data, logs capture detection confidence, method, and system response, and logs are retrievable for analysis.

AI-7 Adversarial Robustness

The AI system will implement mechanisms to detect, prevent, and mitigate adversarial attacks that could compromise AI integrity, manipulate outputs, or degrade system performance. AI systems are vulnerable to attack vectors that do not exist for traditional software. Adversarial attacks can manipulate training data (poisoning), craft inputs that cause misclassification (adversarial examples), extract model parameters (model theft), or reconstruct sensitive training data (model inversion). Adversarial compromise could affect safety or operational success. This requirement addresses the “vulnerable to adversarial attacks” gap identified in Section 1.2.4. AI-specific adversarial robustness does not replace foundational cybersecurity engineering; it extends it. The controls in AI-7.1 through AI-7.6 address attack vectors unique to AI systems; however, these controls assume an underlying cybersecurity posture consistent with established security frameworks. Systems subject to SCL certification should implement security controls consistent with NIST SP 800-53 Rev. 5 (Security and Privacy Controls for Information Systems and Organizations), with particular attention to the System and Information Integrity (SI) and System and Communications Protection (SC) control families as they apply to AI components. Additionally, the development process for AI system software, including ML pipeline code, training infrastructure, and deployment tooling, should follow secure software development practices consistent with NIST SP 800-218 (Secure Software Development Framework, SSDF). AI-7 sub-requirements complement rather than duplicate these foundational controls: data poisoning protection (AI-7.1) extends SI controls to training data; model integrity (AI-7.4) extends SI controls to model artifacts; and supply chain security (AI-7.6) extends SSDF practices to AI-specific dependencies including pre-trained models and ML frameworks. Applicable Domain Standards • General: NIST AI 100-2e2023 (Adversarial ML Taxonomy); ISO/IEC 5338:2023 §6.4.3 • Aviation: DO-326A (Airworthiness Security Process); DO-356A (Airworthiness Security Methods); FAA AI Safety Roadmap • Automotive: ISO/SAE 21434:2021 (Road vehicles cybersecurity); UNECE WP.29 R155 (Cyber security management) • Medical: FDA Premarket Cybersecurity Guidance (2023); FDA Postmarket Cybersecurity Guidance (2016) • EU: EU AI Act Article 15 (Cybersecurity); EU Cyber Resilience Act (EU Cyber Resilience Act article reference held) • Cross-Domain: NIST AI RMF MANAGE-2.2; NIST SP 800-218 (Secure Software Development Framework); NIST SP 800-53 Rev. 5 SI family

AI-7.1 Data Poisoning Protection

The AI system shall implement protections against training data poisoning attacks.

Rationale. Data poisoning injects malicious samples into training datasets to influence model behavior in attacker-controlled ways. Poisoned models may appear to function normally on most inputs but produce incorrect outputs on specific attacker-chosen inputs. Poisoning could create backdoors that trigger dangerous behavior under specific conditions. Protection requires authenticating data sources, validating data integrity, and detecting statistically anomalous samples.

Verification. The AI system shall verify data poisoning protection by analysis and test. The analysis shall confirm training data sources are authenticated and validated through documented provenance, and data integrity checks detect unauthorized modifications. The test shall confirm anomaly detection identifies statistically suspicious training samples, and poisoning attack scenarios are tested with known attack patterns (e.g., backdoor triggers, label flipping, gradient-based poisoning).

Success criteria. The verification shall be considered successful when the analysis and test show that training data sources are authenticated, data integrity checks detect modifications, anomaly detection identifies suspicious samples, and poisoning attack scenarios are tested. Applicable Domain Standards • General: NIST SP 800-53 Rev. 5 SI-7 (Software, firmware, and information integrity); ISO/IEC 27001:2022 A.8.28 (Secure coding) • AI-Specific: NIST AI 100-2e2023 §2.3 (Poisoning Attacks and Mitigations); MITRE ATLAS AML.T0020 (Poison training data) • Data Integrity: ISO/IEC 5259-3:2024 (Data quality management, verification); ISO 8000-61:2016 (Data quality management process reference model) • Aviation: RTCA DO-326A §3.5 (Security risk assessment); SAE ARP 4754A §4 (Development assurance) • Automotive: ISO/SAE 21434:2021 §15 (Threat analysis and risk assessment methods) • Cross-Domain: NIST AI RMF MANAGE-2.1 (Risk response to identified AI risks); EU AI Act Article 15(4) (Resilience against attempts to manipulate training data)

AI-7.2 Adversarial Input Protection

The AI system shall implement protections against adversarial input manipulation at runtime.

Rationale. Adversarial inputs are carefully crafted to cause model misclassification while appearing valid to human observers. Small perturbations imperceptible to humans can cause dramatic changes in model outputs. Known attack patterns include FGSM (Fast Gradient Sign Method), PGD (Projected Gradient Descent), and C&W (Carlini & Wagner) attacks. Runtime protection requires input validation, perturbation detection, and verification that outputs are stable under small input changes.

Verification. The AI system shall verify adversarial input protection by test. The test shall confirm input validation detects malformed or anomalous inputs, adversarial perturbation detection mechanisms are implemented, model outputs are stable under small input perturbations within operational bounds, and known adversarial attack patterns (e.g., FGSM, PGD, C&W) are tested and model response is documented; for systems incorporating generative models or retrieval augmentation, the test shall additionally confirm that prompt injection attack patterns, both direct and indirect through retrieved or ingested content, are tested and the system response is documented.

Success criteria. The verification shall be considered successful when the test shows that input validation detects anomalous inputs, perturbation detection is implemented, outputs are stable under small perturbations, and known attack patterns, including prompt injection for generative and retrieval-augmented systems, are tested. Applicable Domain Standards • General: NIST SP 800-53 Rev. 5 SI-10 (Information input validation); NIST AI 100-2e2023 §2 (Evasion attacks) • AI-Specific: OWASP ML Top 10 (2023) ML01 (Input manipulation attack); OWASP Top 10 for LLM Applications LLM01 (Prompt injection); MITRE ATLAS AML.T0043 (Craft adversarial data); MITRE ATLAS AML.T0051 (LLM prompt injection) • Robustness: ISO/IEC TR 24029-1:2021 (AI robustness assessment overview); IEEE 7009-2024 (Fail-safe design of autonomous systems) • Aviation: RTCA DO-326A §3.7 (Security architecture); SAE ARP 6983 (AI/ML in airborne systems, draft) • Automotive: ISO/SAE 21434:2021 §9.5 (Cybersecurity concept) • Cross-Domain: NIST AI RMF MEASURE-2.7 (AI system security); EU AI Act Article 15(5) (Resilience against adversarial inputs)

AI-7.3 Model Inversion And Extraction Protection

The AI system shall implement protections against model inversion and extraction attacks.

Rationale. Model inversion attacks reconstruct sensitive training data by analyzing model outputs, potentially exposing sensitive information. Model extraction attacks systematically query the model to replicate its behavior, enabling attackers to study vulnerabilities offline. Protection requires access controls, query rate limiting, and output perturbation techniques that prevent systematic probing while maintaining operational utility. Where differential privacy or analogous techniques are applied for data subject privacy purposes, see also AI-10.4 (Privacy-Enhancing Techniques); the same mechanism may satisfy both requirements under distinct threat models.

Verification. The AI system shall verify model inversion and extraction protection by inspection and analysis. The inspection shall confirm model access is restricted to authorized queries only, and training data sensitivity classification is documented. The analysis shall confirm query rate limiting prevents systematic model probing, and output perturbation or differential privacy techniques are applied where applicable based on training data sensitivity.

Success criteria. The verification shall be considered successful when the inspection and analysis show that model access is restricted, training data sensitivity is classified, query rate limiting is implemented, and appropriate privacy techniques are applied. Applicable Domain Standards • General: NIST SP 800-53 Rev. 5 SC-8 (Transmission confidentiality) and SC28 (Protection of information at rest) • AI-Specific: NIST AI 100-2e2023 §2.4 (Privacy Attacks: membership inference, model inversion, extraction); MITRE ATLAS AML.T0024 (Exfiltration via ML inference API) • Privacy-Preserving ML: NIST SP 800-226 (Guidelines for evaluating differential privacy guarantees) • Data Protection: ISO/IEC 27701:2019 (Privacy information management); GDPR Article 32 (Security of processing) • Cross-Domain: NIST AI RMF MAP-4.1 (Approaches for mapping AI technology and legal risks); EU AI Act Article 15(4) (Resilience against confidentiality attacks)

AI-7.4 Model Integrity

The AI system shall maintain model integrity throughout the operational lifecycle.

Rationale. Model integrity ensures that the deployed model is the validated model and has not been modified, corrupted, or replaced. Unauthorized modifications could introduce backdoors, degrade performance, or alter behavior in ways that circumvent all prior verification. Cryptographic signing provides tamper-evident verification, and integrity checks at load time and runtime detect unauthorized changes. Model integrity controls apply in concert with the maintenance criteria established under AI-4.3 and the deployment format validation established in AI4.7; legitimate model updates shall pass through all three control points before operational deployment.

Verification. The AI system shall verify model integrity by inspection. The inspection shall confirm model artifacts are cryptographically signed, integrity verification occurs at model load and at defined intervals during operation, unauthorized model modifications trigger alerts and fallback procedures, and model version history is maintained with tamper-evident logging.

Success criteria. The verification shall be considered successful when the inspection shows that model artifacts are signed, integrity verification occurs at load and defined intervals, unauthorized modifications trigger alerts, and version history is maintained with tamper-evident logging. Applicable Domain Standards • General: NIST SP 800-53 Rev. 5 SI-7 (Integrity) and CM-5 (Access restrictions for change) • Secure Development: NIST SP 800-218 (SSDF, Secure Software Development Framework); SLSA Framework v1.0 (Supply-chain Levels for Software Artifacts) • Model Signing: Sigstore / Linux Foundation Model Transparency project (cryptographic signing of model weights) • Aviation: RTCA DO-326A §3.9 (Security assurance); RTCA DO-178C §11.5 (Configuration management) • Automotive: ISO/SAE 21434:2021 §11 (Cybersecurity validation) • Cross-Domain: NIST AI RMF MANAGE-2.1 (Risk response); EU AI Act Article 15(1) (Accuracy, robustness, and cybersecurity throughout lifecycle)

AI-7.5 Adversarial Event Logging

The AI system shall log all adversarial detection events and security incidents for post-mission analysis.

Rationale. Comprehensive logging of adversarial events supports post-mission forensic analysis, enables detection of attack patterns, and informs security improvements for future missions. Logs must be immutable to prevent attacker manipulation and must be retained for sufficient duration to support post-mission analysis.

Verification. The AI system shall verify adversarial event logging by inspection. The inspection shall confirm security events are logged with timestamps, event type, and severity, logs capture detection confidence and system response, logs are immutable and retrievable for forensic analysis, and log retention meets mission duration plus post-mission analysis requirements.

Success criteria. The verification shall be considered successful when the inspection shows that security events are logged with timestamps, type, and severity, logs capture detection confidence and response, logs are immutable and retrievable, and retention meets requirements. Applicable Domain Standards • General: NIST SP 800-53 Rev. 5 AU-2 (Event logging), AU-3 (Content of audit records), AU-12 (Audit record generation) • Security Monitoring: ISO/IEC 27001:2022 A.8.15 (Logging) and A.8.16 (Monitoring activities) • Incident Response: NIST SP 800-61 Rev. 2 (Computer security incident handling guide) • Aviation: RTCA DO-326A §3.10 (Security monitoring) • Automotive: ISO/SAE 21434:2021 §8.3 (Cybersecurity monitoring) • Cross-Domain: NIST AI RMF MEASURE-4.3 (Ongoing monitoring); EU AI Act Article 12 (Record-keeping of events relevant to risk identification)

AI-7.6 Ai Supply Chain Security

The AI system shall assess and document supply chain risks for all AI/ML frameworks, libraries, and pre-trained model components.

Rationale. AI systems depend on complex software supply chains including ML frameworks (e.g., TensorFlow, PyTorch), libraries (e.g., NumPy, ONNX), and potentially pre-trained models or transfer learning components. These dependencies may contain vulnerabilities, backdoors, or undocumented behaviors introduced through foreign contribution, compromised maintainers, or malicious updates. Pre-trained models may encode biases, backdoors, or behaviors from unknown training data. Supply chain assessment ensures that AI system integrity extends beyond the project’s own development to encompass all external dependencies.

Verification. The AI system shall verify AI supply chain security by inspection. The inspection shall confirm AI/ML frameworks and libraries are identified and documented with version numbers and sources, supply chain risk assessment addresses foreign contribution, maintenance status, and known vulnerabilities, pretrained models (if used) have documented provenance and integrity verification, and mitigation strategies are documented for identified supply chain risks.

Success criteria. The verification shall be considered successful when the inspection shows that AI/ML frameworks and libraries are documented, supply chain risk assessment addresses contribution sources and maintenance, pretrained model provenance is documented, and mitigation strategies are documented for identified risks. Applicable Domain Standards • General: NIST SP 800-53 Rev. 5 SR-3 (Supply chain controls) and SR-5 (Acquisition strategies) • Supply Chain: NIST SP 800-161 Rev. 1 (C-SCRM for systems and organizations); NIST SP 800-218 (SSDF) • Model Bill-of-Materials: NTIA Minimum Elements for SBOM (2021); CISA SBOM guidance; extensions for ML (ML-BOM) • Aviation: RTCA DO-326A §3.8 (Supplier risk); RTCA DO-355 (Information security guidance for airworthiness) • Automotive: ISO/SAE 21434:2021 §7 (Distributed cybersecurity activities: supplier relationships) • Cross-Domain: NIST AI RMF GOVERN-6.1 (Third-party risk management); EU AI Act Article 25 (Obligations along the AI value chain)

AI-8 Explainability

The AI system will provide explanations of AI decisions and recommendations sufficient for operators to verify AI reasoning and establish appropriate trust.

AI-8.1 Explainability Requirements Definition

The AI system shall define explainability requirements appropriate to each AI function’s criticality and user needs.

Rationale. Explainability requirements should scale with decision criticality; Safety-Critical AI functions require more rigorous explanation capabilities than Operational Support functions. Requirements must also consider the target audience; operators need operationally relevant explanations, while engineers may need deeper technical detail. Defining requirements upfront ensures explainability is designed in, not retrofitted.

Verification. The AI system shall verify explainability requirements definition by inspection. The inspection shall confirm explainability requirements are defined for each AI function, requirements are scaled to function criticality and decision impact, target audience and their explanation needs are documented (e.g., operators, engineers, analysts), and explainability approach is justified for each AI function (e.g., feature importance, attention visualization, rule extraction, inherently interpretable models).

Success criteria. The verification shall be considered successful when the inspection shows that explainability requirements are defined for each AI function, requirements scale with criticality, target audiences are documented, and explainability approaches are justified.

AI-8.2 Decision Explanation Generation

The AI system shall provide decision explanations in a format understandable to operators.

Rationale. Explanations must be actionable and comprehensible to the intended audience within operational time constraints. Technical explanations (e.g., feature weights, activation patterns) may be appropriate for post-mission analysis but are inadequate for real-time operational decisions. Explanation format should be validated through human factors assessment to ensure operators actually understand and can act on the information provided.

Verification. The AI system shall verify decision explanation generation by demonstration. The demonstration shall confirm explanations are generated for AI decisions and recommendations, explanation format is appropriate to operational context and timing constraints, explanations identify key factors influencing the decision, and operator comprehension is validated through usability assessment with representative operators performing representative tasks under realistic conditions.

Success criteria. The verification shall be considered successful when the demonstration shows that explanations are generated for AI decisions, format is appropriate to context, key influencing factors are identified, and operator comprehension is validated through usability assessment.

AI-8.3 Confidence Indication

The AI system shall indicate confidence levels for AI outputs.

Rationale. AI outputs vary in reliability: some predictions are made with high confidence, others are uncertain. Operators need to know when to trust AI outputs and when to apply additional scrutiny or seek alternative information. Confidence must be calibrated; a stated 90% confidence should be correct approximately 90% of the time, to enable appropriate operator trust calibration. ISO 22989 Section 3.5.8 defines predictability as enabling reliable assumptions about outputs; calibrated confidence supports this property.

Verification. The AI system shall verify confidence indication by test. The test shall confirm confidence metrics are computed for AI outputs, confidence is presented to operators with outputs in a format that supports decision-making, confidence calibration is validated against actual accuracy (e.g., Expected Calibration Error ≤ 0.05), and low-confidence outputs are clearly distinguished from high-confidence outputs through visual or auditory differentiation.

Success criteria. The verification shall be considered successful when the test shows that confidence metrics are computed, confidence is presented with outputs, calibration is validated against actual accuracy, and low-confidence outputs are clearly distinguished. Applicable Domain Standards • General: ISO/IEC 22989:2022 3.5.8 (Predictability); ISO/IEC TS 6254:2024 §6 (Confidence communication) • Aviation: FAA AI Safety Roadmap (Interpretability and uncertainty quantification) • Automotive: SAE J3016:2021 §5.3 (Automation reliability feedback to user) • Medical: FDA AI/ML Transparency Principles (2021) Principle 3 (Labeling for transparency); FDA CDS Guidance (January 2026) §IV(4) (Criterion 4: basis and evidence supporting recommendations) • EU: EU AI Act Article 13(3)(b)(iv) (Information on level of accuracy and reliability) • Cross-Domain: NIST AI RMF MEASURE-2.5

AI-8.4 Reasoning Inspection Capability

The AI system shall enable operators to query or inspect AI reasoning for safetycritical decisions.

Rationale. For safety-critical decisions, operators may need to understand AI reasoning in greater depth than routine explanations provide. On-demand inspection capability allows operators to drill down into AI reasoning when uncertainty exists or when AI recommendations conflict with operator expectations. This capability supports the human decision authority required by AI-9.1 (Human Decision Authority) and aligns with ISO 22989 Section 3.5.6 controllability requirements.

Verification. The AI system shall verify reasoning inspection capability by test. The test shall confirm query or inspection capability is available for safety-critical AI functions, operators can access additional detail on demand beyond routine explanations, inspection does not unacceptably delay operational timelines, and inspection capability is documented in operator procedures.

Success criteria. The verification shall be considered successful when the test shows that inspection capability is available for safety-critical functions, operators can access additional detail on demand, inspection meets timing requirements, and capability is documented in procedures.

AI-8.5 Public Disclosure Support

The AI system shall provide the artifacts and information necessary to support public disclosure obligations applicable to the deployment context, in a form suitable for stakeholder consumption outside the development organization.

Rationale. AI systems may be subject to public disclosure requirements including external model cards or system factsheets, consumer-facing information under EU AI Act Article 13, federal AI use case inventory reporting under Executive Order 14110 and OMB M-24-10, and public registration for high-risk systems under EU AI Act Article 71. The specific disclosure obligations depend on deployment context and generally bind the deploying organization rather than the developer; however, the AI system design must support those obligations by producing standardized disclosure artifacts consumable by regulators, users, data subjects, and the public. This requirement complements the internal explainability requirements (AI-8.1 through AI-8.4) by establishing the external-facing disclosure surface. Disclosure artifacts should be derived from existing framework evidence (ODD declaration per AI-1.0, bias evaluation per AI-2, performance characterization per AI-4, explainability outputs per AI-8.1-8.4) rather than generated independently, to ensure external disclosures remain consistent with internal verification evidence. This sub-requirement is optional by classification and may be documented as Not Applicable with rationale where no public disclosure obligation applies.

Verification. The AI system shall verify public disclosure support by inspection. The inspection shall confirm that applicable public disclosure obligations are identified in the ODD declaration under Regulatory and Operational Authorization (AI-1.0); that disclosure artifact formats are defined (e.g., external model card, AI factsheet, EU AI Act Article 13 user information, federal AI inventory entry); that each required artifact is populated from existing framework evidence rather than generated in parallel; and that artifacts are reviewed prior to release for consistency with ODD declaration, documented limitations, and verification evidence. The inspection shall further confirm that artifact update procedures are defined so that disclosure artifacts remain consistent with the current system state following updates, drift remediation (AI-4.3), reclassification (AI-9.6), or ODD revision; and that artifacts are retained for the retention period required by the applicable regulatory regime.

Success criteria. The verification shall be considered successful when the inspection shows that applicable disclosure obligations are identified, disclosure artifacts are defined and populated from framework evidence, artifacts are reviewed for consistency before release, update procedures are defined, and retention requirements are satisfied. Where no public disclosure obligation applies, AI-8.5 may be documented as Not Applicable with rationale. Applicable Domain Standards • General: ISO/IEC 23894:2023 Annex A.12 (Transparency and explainability to stakeholders); ISO/IEC 5259-4 §7 (Data quality process for ML); ISO/IEC 42001:2023 §8.3 (Communication) • Aviation: FAA AI Safety Roadmap (stakeholder transparency) • Automotive: NHTSA AV 4.0 element 2 (Operational Design Domain description); NHTSA AV Transparency and Engagement Principles • Medical: FDA Predetermined Change Control Plan Guidance (2024) §V (Policy for Predetermined Change Control Plans, including labeling requirements at lines 844-887 of the guidance); FDA Transparency for Machine LearningEnabled Device Guidance (2021) • EU: EU AI Act Article 13 (Transparency and provision of information to deployers); EU AI Act Article 50 (Transparency obligations for generalpurpose AI); EU AI Act Article 71 (Public EU database registration for high-risk AI) • US Federal: Executive Order 14110 Section 10.1(b) (Federal AI inventory); OMB M-24-10 (Federal AI use case inventory requirements); NIST AI 100-1 (AI Risk Management Framework) • Cross-Domain: NIST AI RMF GOVERN-1.4 (Risk documentation); NIST AI RMF MANAGE-4.1 (Post-deployment monitoring disclosure)

AI-9 Human-AI Teaming

The AI system will support effective human-AI collaboration, enabling operators to maintain situational awareness, appropriate trust calibration, and final decision authority over safety-critical actions. AI systems in safety-critical operations operate as part of a human-machine team, not as fully autonomous agents. ISO 22989 Section 5.13 defines automation levels ranging from full human control to full autonomy; for safety-critical systems, human oversight remains essential. Operators must understand what the AI is doing, trust it appropriately (neither too much nor too little), and retain authority to override AI actions when necessary. This requirement addresses the “operators cannot verify reasoning” gap and ensures AI augments rather than replaces human judgment in safety-critical decisions. Applicable Domain Standards • General: ISO/IEC 22989:2022 3.5.6 (Controllability); §5.13 (Automation levels) • Aviation: 14 CFR 25.1302 (Installed systems and equipment for use by the flightcrew); FAA AC 25.1322 (Flight Crew Alerting); FAA AI Safety Roadmap (human oversight) • Automotive: SAE J3016:2021 §5 (Automation levels); NHTSA Automated Vehicles Comprehensive Plan (2021) • Medical: FDA CDS Guidance (January 2026) §IV(4) (Criterion 4: independent review); HHS/ONC Health IT Certification • EU: EU AI Act Article 14 (Human oversight); EU AI Act Article 26 (Deployer obligations) • Cross-Domain: NIST AI RMF GOVERN-1.5; NIST AI RMF MANAGE-2.1

AI-9.1 Human Decision Authority

The AI system shall maintain human decision authority over safety-critical actions.

Rationale. For safety-critical actions, those that could result in harm, equipment damage, or mission loss, humans must retain final decision authority. AI may recommend, advise, or prepare actions, but execution should require human authorization except where explicitly designed and approved for autonomous operation (e.g., time-critical emergency responses). ISO 22989 Section 3.5.6 defines controllability as the property allowing human intervention; this requirement ensures controllability is maintained for safety-critical functions.

Verification. The AI system shall verify human decision authority by test. The test shall confirm safety-critical actions require human authorization before execution, AI cannot execute safety-critical actions autonomously unless explicitly designed, approved, and documented for autonomous operation, human override capability is always available and functional, and authority boundaries are documented and enforced through technical controls.

Success criteria. The verification shall be considered successful when the test shows that safety-critical actions require human authorization, autonomous execution is limited to explicitly approved cases, human override is always available, and authority boundaries are documented and enforced. Applicable Domain Standards • General: ISO/IEC 22989:2022 3.5.6 (Controllability) • Aviation: 14 CFR 25.1302 (Flight crew installed systems); FAA AC 25.1322 §4 (Alert prioritization and integration) • Automotive: SAE J3016:2021 §5.2 (Dynamic Driving Task fallback); NHTSA AV 4.0 Voluntary Safety Self-Assessment element 3 (Human Machine Interface) • Medical: FDA Clinical Decision Support Software Guidance (January 2026) §IV(4) (Criterion 4: basis for practitioner independent review) • EU: EU AI Act Article 14(4) (Human oversight measures for high-risk AI); EU AI Act Article 14(5) (oversight of certain biometric categorization) • Cross-Domain: NIST AI RMF GOVERN-1.5; NIST AI RMF MANAGE-2.1

AI-9.2 Operational Situational Awareness

The AI system shall support operator situational awareness of AI state and behavior.

Rationale. Operators cannot effectively supervise AI systems they do not understand. Situational awareness requires visibility into what the AI is doing, what it is recommending, and why. Changes in AI state (e.g., mode transitions, confidence drops, detected anomalies) must be communicated to operators to prevent surprise and enable proactive response.

Verification. The AI system shall verify operator situational awareness support by test. The test shall confirm AI operational state is visible to operators through appropriate displays, AI actions and recommendations are communicated clearly within operational timing constraints, changes in AI state or confidence are annunciated (e.g., state change notification ≤500ms, confidence drop >15% triggers alert), and operators can determine what the AI is doing and why through available displays and explanations.

Success criteria. The verification shall be considered successful when the test shows that AI state is visible to operators, actions and recommendations are clearly communicated, state changes are annunciated within timing requirements, and operators can determine AI status and reasoning.

AI-9.3 Trust Calibration

The AI system shall support appropriate trust calibration between operators and AI.

Rationale. Miscalibrated trust either over-trust or under-trust degrades human-AI team performance. Over-trust leads to automation complacency where operators fail to catch AI errors; under-trust leads to operators ignoring valid AI recommendations. Trust calibration requires that operators understand AI reliability and limitations, that training addresses appropriate trust levels, and that system design promotes calibrated trust through transparency and appropriate confidence communication.

Verification. The AI system shall verify trust calibration support by analysis and demonstration. The analysis shall confirm AI reliability and limitations are documented and communicated to operators, and training materials address appropriate AI trust levels including scenarios where AI should and should not be trusted. The demonstration shall confirm system design discourages both over-trust (e.g., through uncertainty indication, limitation warnings) and under-trust (e.g., through reliability demonstration, confidence calibration), and trust calibration is assessed through human factors evaluation with representative operators under realistic operational conditions.

Success criteria. The verification shall be considered successful when the analysis and demonstration show that AI reliability and limitations are communicated, training addresses trust calibration, system design discourages miscalibrated trust, and human factors evaluation confirms appropriate trust calibration.

AI-9.4 Graceful Degradation

The AI system shall degrade gracefully when AI capabilities are reduced or unavailable.

Rationale. AI systems may experience capability reduction due to sensor failures, computational resource constraints, detected anomalies, or explicit mode transitions. When AI capabilities are degraded, operators must be notified and manual or backup procedures must be available to continue operations. Abrupt AI failure without graceful degradation could leave operators without situational awareness or control capability. Degraded mode definitions shall be consistent with the System Inputs degradation behaviors declared under AI-1.0.

Verification. The AI system shall verify graceful degradation by test. The test shall confirm degraded AI modes are defined and documented for each AI function, operators are notified of AI capability reduction through appropriate annunciation, manual or backup procedures are available and documented for operation without full AI capability, and transition to degraded modes is tested and acceptable (e.g., ≤2 operator actions, ≤5 seconds to transition to manual mode).

Success criteria. The verification shall be considered successful when the test shows that degraded modes are defined, operators are notified of capability reduction, manual/backup procedures are available, and mode transitions are tested and acceptable.

AI-9.5 Human-Ai Interaction Logging

The AI system shall log human-AI interactions for post-mission analysis.

Rationale. Comprehensive logging of human-AI interactions supports post-mission analysis to identify human factors issues, assess trust calibration, evaluate override patterns, and improve future AI systems. Logs should capture what the AI recommended, what the human decided, and the rationale for any overrides. This data is essential for continuous improvement of human-AI teaming effectiveness.

Verification. The AI system shall verify human-AI interaction logging by inspection. The inspection shall confirm human-AI interactions are logged with timestamps, logs capture AI recommendations and human decisions, logs capture overrides with rationale, and logs support post-mission human factors analysis including trust calibration assessment and override pattern analysis.

Success criteria. The verification shall be considered successful when the inspection shows that interactions are logged with timestamps, logs capture recommendations, decisions, and override rationale, and logs support post-mission human factors analysis.

AI-9.6 Operational Role Verification

The AI system shall implement periodic verification that the system’s operational role remains consistent with its classification.

Rationale. AI system classification (Section 1.2.2) determines which requirements apply and at what stringency. Classification is assigned based on the intended operational role of the AI system: whether its outputs are advisory, operational, or safety critical. However, operational usage can drift over time without any change to the system itself. A system classified as Operational Support may produce outputs that operators gradually elevate from advisory to authoritative, relying on AI recommendations as though they were directives. This usage drift is particularly insidious because no technical change triggers a review. The model performs identically; only the human reliance on it has changed. When this occurs, the system is effectively operating at a higher classification tier without the corresponding requirements, verifications, or safeguards. Periodic verification of operational role ensures that classification remains aligned with actual usage and that any drift toward higher reliance triggers formal reclassification and the application of additional requirements. This is the human factors complement to the technical drift monitoring required by AI-4.

Verification. The AI system shall verify operational role verification by inspection and analysis. The inspection shall confirm a periodic review schedule is defined and justified based on system classification and operational tempo, the review process includes assessment of how operators actually use AI outputs (not just how the system is designed to be used), review criteria explicitly address whether operators treat AI outputs as advisory, operational, or authoritative, review criteria include adherence of actual operational use to the declared ODD (AI-1.0), and review findings are documented and retained as verification evidence. The analysis shall confirm the review process includes mechanisms to detect usage drift, such as operator workflow analysis, override rate trends, or decision dependency assessment; that identified usage drift triggers formal reclassification evaluation per Section 1.2.2; and that when reclassification is warranted, the additional requirements corresponding to the new classification are applied and verified before continued operation at the elevated role.

Success criteria. The verification shall be considered successful when the inspection and analysis show that a periodic review schedule is defined and justified, the review assesses actual operator usage against classification assumptions, usage drift detection mechanisms are defined, identified drift triggers reclassification evaluation, and reclassification results in application of corresponding requirements.

AI-9.7 Operator Qualification

The AI system shall require documented operator qualifications appropriate to system classification and operational role, including system-specific training, demonstrated proficiency in normal and abnormal operations, and currency requirements that remain valid during continued operation.

Rationale. AI system safety and performance depend on operator understanding of system capabilities, limitations, and failure modes. Unqualified operators may over-trust AI outputs, fail to recognize degraded performance, or misinterpret advisory outputs as directives. Qualification rigor should scale with classification: Safety-Critical AI requires formal operator certification, Mission-Critical AI requires role-based qualification, and Operational Support AI requires documented familiarization. Currency requirements prevent qualification decay during extended operation and ensure operators remain proficient following system updates that materially change AI behavior.

Verification. The AI system shall verify operator qualification by inspection and test. The inspection shall confirm that operator qualification requirements are documented for each operational role; that qualification criteria address AI-specific topics including system capabilities, documented limitations (Section 1.5 thresholds, AI-1.0 ODD bounds), known failure modes (AI-6 OOD, AI-7 adversarial), and appropriate trust calibration (AI-9.3); that currency requirements are defined with intervals justified by system classification and operational tempo; and that qualification records are retained as verification evidence. The test shall confirm that operators assigned to the AI system hold current qualification for their role, that operators without current qualification are prevented from assuming roles that require it through administrative or technical controls, and that qualification re-validation is triggered when material system updates affect operator-relevant behavior.

Success criteria. The verification shall be considered successful when the inspection and test show that operator qualification requirements are documented by role and classification, AI-specific qualification content is addressed, currency requirements are defined and enforced, and qualification records are retained as verification evidence. Applicable Domain Standards • General: ISO/IEC 22989:2022 3.5.5 (Human-AI collaboration); ISO/IEC 25059:2023 §5 (Quality characteristics for AI systems) • Aviation: 14 CFR 121 Subpart N (Training Program); 14 CFR 121 Subpart Y (Advanced Qualification Program); FAA AI Safety Roadmap (operator training) • Automotive: SAE J3016:2021 §8 (User considerations); NHTSA AV 4.0 element 12 (Consumer Education and Training) • Medical: FDA 21 CFR 820.25 (Personnel - Training); FDA Clinical Decision Support Software Guidance (January 2026); note: 'Practitioner learning' is not addressed as a distinct section in the current 2026 version; concept is implicit in §IV(4) Criterion 4 discussion of HCP independent review • EU: EU AI Act Article 4 (AI literacy); EU AI Act Article 14(4)(a) (Oversight competence); EU AI Act Article 26(2) (Deployer training obligations) • Cross-Domain: NIST AI RMF GOVERN-2.2 (Accountability for staff); NIST SP 800-53 Rev. 5 AT-3 (Role-Based Training); NIST SP 800-53 Rev. 5 PS-3 (Personnel Screening)

AI-9.8 Workload Management

The AI system shall define operational workload parameters and implement design measures that maintain operator cognitive capacity within documented limits under nominal, degraded, and high-tempo conditions.

Rationale. AI deployment can increase or decrease operator cognitive workload depending on interface design, alert logic, and the degree to which AI outputs require operator verification. Excess workload degrades decision quality, delays responses to abnormal conditions, and increases error probability. Insufficient workload induces complacency and reduces attentional resources available for monitoring AI outputs, which is a documented precursor to automation-induced failures. Workload must be validated as part of the operational design rather than discovered in deployment; this requirement complements trust calibration (AI-9.3) by ensuring the operator retains the cognitive margin required to exercise judgment and complements operator qualification (AI-9.7) by establishing the environment in which qualified operators function.

Verification. The AI system shall verify workload management by analysis and test. The analysis shall confirm that operational workload parameters are defined for representative nominal, degraded, and high-tempo scenarios; that cognitive workload limits are documented with reference to an accepted workload assessment method (e.g., NASA-TLX, Bedford, SWAT) or domain guidance (e.g., FAA AC 25.1302, AAMI HE75); that automation-bias and complacency risks are explicitly addressed in the workload design; and that workload monitoring mechanisms (manual override rates, alert acknowledgement latency, task completion times) are specified. The test shall confirm that under representative operational scenarios, measured workload remains within documented limits; that mitigations are invoked when workload indicators exceed defined thresholds (e.g., alert suppression, task offloading, fallback behaviors); and that operators retain the cognitive capacity necessary to exercise decision authority required by AI-9.1.

Success criteria. The verification shall be considered successful when the analysis and test show that workload parameters are defined for nominal, degraded, and high-tempo scenarios, measured workload remains within documented limits, automation-bias and complacency risks are addressed, and workload mitigations are effective. Applicable Domain Standards • General: ISO 9241-11 (Usability: Definitions and concepts); ISO 11064 (Ergonomic design of control centres); ISO/IEC 25059:2023 §5 (AI system quality characteristics) • Aviation: 14 CFR 25.1302 (Flightcrew workload); FAA AC 25.1302-1 (Installed Systems and Equipment for Use by the Flightcrew); FAA AI Safety Roadmap (cognitive workload) • Automotive: NHTSA Visual-Manual Driver Distraction Guidelines (2013); SAE J3016:2021 §5.3 (Driver readiness); SAE J2944 (Driving performance terms) • Medical: FDA Human Factors and Usability Engineering Guidance (2016) §6.3.1 (Task Analysis); AAMI HE75:2009/(R)2018 (Human factors design) • EU: EU AI Act Article 14(4)(d) (Measures to counter automation bias); Council Directive 89/391/EEC Article 6 (General obligations for safe working conditions) • Cross-Domain: NIST AI RMF MEASURE-2.8 (Human factors); MIL-STD-1472H (DoD Human Engineering Design Criteria); NUREG-0711 Rev. 3 (Human Factors Engineering Program Review)

AI-9.9 Training Program Requirements

The AI system shall be supported by a training program that provides initial qualification, recurrent training, and scenario-based exercises covering AI system capabilities, documented limitations, failure modes, and appropriate trust calibration.

Rationale. Training programs for AI systems must address considerations that differ from traditional system training: non-deterministic behavior, performance variability across operational conditions, AI-specific failure modes such as OOD inputs and adversarial attacks, and the calibration between operator reliance and demonstrated AI performance. Initial qualification alone is insufficient because AI system behavior may evolve with updates, data drift, or operational context. Recurrent training maintains proficiency during extended operation, and scenariobased exercises expose operators to rare failure modes before they occur operationally. Training program requirements complement operator qualification (AI-9.7) by defining the content and cadence that produce qualified operators, and complement workload management (AI-9.8) by ensuring operators possess the knowledge required to recognize and respond to high-workload conditions.

Verification. The AI system shall verify training program requirements by inspection. The inspection shall confirm that an initial qualification curriculum is documented and covers AI system capabilities, documented limitations (Section 1.5 thresholds, AI-1.0 ODD bounds), known failure modes (AI-6 OOD, AI-7 adversarial, AI-4 drift), explainability outputs (AI-8), and trust calibration guidance (AI-9.3); that recurrent training is scheduled at documented intervals justified by classification and operational tempo; that scenario-based exercises cover both nominal operations and rare off-nominal conditions including AI-specific failure modes; and that training effectiveness is measured through assessment of operator performance rather than attendance alone. The inspection shall further confirm that material system updates trigger targeted training for the affected operator population before the updated system is released to operational use; that training content is updated to reflect current system behavior, thresholds, and ODD; and that training records are retained as verification evidence supporting AI-9.7 qualification currency.

Success criteria. The verification shall be considered successful when the inspection shows that initial qualification, recurrent training, and scenario-based exercises are documented and delivered; that AI-specific content is addressed; that training is updated in response to material system changes; and that training records support AI-9.7 qualification currency. Applicable Domain Standards • General: ISO/IEC 22989:2022 5.5 (Operation and monitoring); ISO/IEC 27002:2022 §6.3 (Information security awareness, education and training) • Aviation: 14 CFR 121 Subpart Y (Advanced Qualification Program); FAA AC 12035D (Line Operational Simulations); FAA AI Safety Roadmap §4 (Operator proficiency) • Automotive: NHTSA AV 4.0 element 12 (Consumer education); SAE J3016:2021 §8.3 (User training for higher levels of driving automation) • Medical: FDA 21 CFR 820.25 (Personnel training); FDA Clinical Decision Support Software Guidance (January 2026); note: dedicated 'Practitioner learning and proficiency' section does not exist in the current 2026 version; concept is implicit in §IV(4) • EU: EU AI Act Article 4 (AI literacy); EU AI Act Article 26(2) (Deployer obligations, competence of natural persons assigned oversight) • Cross-Domain: NIST AI RMF GOVERN-2.2 (Accountability for staff); NIST SP 800-53 Rev. 5 AT-2 (Literacy Training), AT-3 (Role-Based Training), AT-4 (Training Records)

AI-10 Privacy and Data Protection

The AI system will implement personal data protection mechanisms that enable lawful processing, respect data subject rights, and minimize privacy risk throughout the AI lifecycle. AI systems frequently process personal data: patient records in medical AI, biometric data in identity systems, behavioral data in recommendation systems, sensor-derived personal information in autonomous platforms. The handling of this data is governed by privacy regulations distinct from information classification regimes: GDPR in the EU, HIPAA in US healthcare, CCPA/CPRA in California, PIPEDA in Canada, and analogous frameworks globally. AI systems also introduce privacy risks not present in traditional software: training data may be reconstructable from model parameters (model inversion), trained models may leak membership information about training subjects, and the opacity of AI decisions complicates the exercise of data subject rights. This requirement addresses personal data handling throughout the AI lifecycle, complementing the information classification handling established in AI-1.5 through AI-1.8. Applicability: AI-10 applies to AI systems that process personal data as defined under any applicable privacy framework. Where the system does not process personal data, AI-10 sub-requirements may be documented as Not Applicable with rationale. Determination of personal data processing shall be documented in the ODD declaration (AI-1.0) under Subject Population and Regulatory and Operational Authorization. Applicable Domain Standards • General: ISO/IEC 27701:2019 (Privacy Information Management); ISO/IEC 29100:2011 (Privacy framework) • Medical: HIPAA Privacy Rule (45 CFR 164 Subpart E); HIPAA Security Rule (45 CFR 164 Subpart C) • EU: GDPR (Regulation 2016/679); EU AI Act Article 10(5) (special categories of personal data) • US State: CCPA/CPRA (Cal. Civ. Code §§ 1798.100 et seq.) • Cross-Domain: NIST Privacy Framework v1.0; NIST SP 800-53 Rev. 5 PT family; NIST SP 800-122 (PII)

AI-10.1 Personal Data Identification And Minimization

The AI system shall identify personal data within all training, validation, test, and operational datasets, and shall apply data minimization principles to limit personal data collection, retention, and processing to what is necessary for the declared purpose.

Rationale. Personal data identification is a prerequisite for any privacy control. Without knowing what personal data is present, no other privacy requirement can be satisfied. Direct identifiers (name, email, government ID, biometric data, medical record number) are typically straightforward to detect; indirect identifiers (combinations of attributes that enable re-identification) require more sophisticated assessment. Data minimization, processing only what is necessary for the declared purpose, is foundational to GDPR Article 5(1)(c), CCPA reasonable necessity provisions, and HIPAA minimum necessary standard. AI systems often violate minimization implicitly by retaining all collected data for potential future training; explicit minimization requires documented justification for each data category retained.

Verification. The AI system shall verify personal data identification and minimization by inspection and analysis. The inspection shall confirm that personal data identification methods are documented and applied to all datasets in scope; that direct and indirect identifiers are documented per dataset; that data minimization analysis documents the necessity of each personal data category retained; and that minimization decisions are reviewed at the cadence of the dataset refresh cycle. The analysis shall confirm that automated identification tools are validated against known personal data samples; that re-identification risk assessment addresses indirect identifier combinations; and that retention periods for personal data are bounded and justified relative to the declared processing purpose.

Success criteria. The verification shall be considered successful when the inspection and analysis show that personal data identification methods are documented and applied, identifiers are documented per dataset, minimization analysis is complete with documented necessity, automated tools are validated, reidentification risk is assessed for indirect identifiers, and retention periods are bounded and justified.

AI-10.2 Lawful Basis And Consent Management

The AI system shall document the lawful basis for personal data processing under each applicable privacy framework, and shall implement consent management mechanisms where consent is the lawful basis.

Rationale. Personal data processing requires a lawful basis under all major privacy frameworks. GDPR Article 6 enumerates six lawful bases (consent, contract, legal obligation, vital interests, public task, legitimate interests); HIPAA distinguishes covered entity processing, business associate processing, and authorizationbased processing; CCPA provides a notice-and-opt-out framework with specific bases for sensitive personal information. The lawful basis selected determines the obligations that follow: consent-based processing requires consent records, withdrawal mechanisms, and re-consent triggers; legitimate-interests-based processing requires a documented balancing test. AI systems trained on data collected under one lawful basis may be unable to be retrained on the same data if the basis changes; documenting basis throughout the lifecycle is necessary for ongoing lawful operation.

Verification. The AI system shall verify lawful basis and consent management by inspection. The inspection shall confirm that the lawful basis for personal data processing is documented under each applicable privacy framework; that the basis is documented per dataset and per processing purpose; that consent records are maintained where consent is the basis, including consent text, capture mechanism, timestamp, and withdrawal status; that consent withdrawal mechanisms are implemented and accessible to data subjects; and that processing ceases or is justified under a different basis when consent is withdrawn.

Success criteria. The verification shall be considered successful when the inspection shows that lawful basis is documented per dataset and processing purpose under each applicable framework, consent records are complete and accessible, withdrawal mechanisms are functional, and basis changes trigger documented review.

AI-10.3 Data Subject Rights Implementation

The AI system shall implement procedures to support data subject rights as required by applicable privacy frameworks, including rights of access, rectification, erasure, restriction, portability, and objection.

Rationale. Data subject rights are a defining feature of modern privacy frameworks. GDPR Articles 15 through 22 establish access, rectification, erasure, restriction, portability, objection, and rights regarding automated decision-making. HIPAA establishes patient access rights and amendment rights under 45 CFR 164.524 and 164.526. CCPA establishes access, deletion, and opt-out rights. AI systems present unique implementation challenges: the right to erasure may require model retraining if personal data influenced learned parameters; the right to access may require explanation of automated decisions; the right to rectification of training data does not retroactively correct already-trained model behavior. These challenges require explicit procedural design rather than ad-hoc handling. Where data subject rights require explanation of automated decisions, AI-8 (Explainability) outputs serve as supporting evidence.

Verification. The AI system shall verify data subject rights implementation by inspection and test. The inspection shall confirm that procedures are documented for each data subject right applicable under the relevant privacy frameworks; that response timelines meet regulatory requirements (e.g., 30 days under GDPR Article 12(3), 30 days under HIPAA 164.524, 45 days under CCPA); that procedures address AIspecific implementation challenges including erasure from trained models and access to automated decision explanations; and that data subject request intake mechanisms are accessible and documented. The test shall confirm that representative data subject rights requests can be processed end-to-end within required timelines; that erasure requests result in documented removal from datasets and assessment of model retraining necessity; and that access requests produce intelligible responses including, where applicable, explanation of automated decision logic per AI-8.

Success criteria. The verification shall be considered successful when the inspection and test show that procedures exist for each applicable right, timelines meet regulatory requirements, AI-specific challenges are addressed procedurally, intake mechanisms are accessible, end-to-end processing meets timelines, erasure assessments include model retraining necessity, and access responses include automated decision explanation where applicable.

AI-10.4 Privacy-Enhancing Techniques

The AI system shall apply privacy-enhancing techniques appropriate to the personal data sensitivity, processing purpose, and re-identification risk of the system.

Rationale. Privacy-enhancing techniques (PETs) reduce privacy risk through technical design rather than procedural controls alone. Anonymization removes the link between data and data subjects; pseudonymization replaces identifiers with reversible tokens; differential privacy adds calibrated noise to prevent membership inference; federated learning trains models without centralizing raw data; secure aggregation enables computation without exposing inputs; encryption protects data at rest, in transit, and increasingly in computation. The selection of PETs depends on the threat model, the utility requirements, and the regulatory regime. PETs are not interchangeable: anonymization that meets HIPAA Safe Harbor may not meet GDPR anonymization standards; differential privacy parameters that satisfy academic definitions may not satisfy regulatory expectations. Where differential privacy is applied as defense against model inversion attacks, see also AI-7.3 (Model Inversion and Extraction Protection); AI-10.4 addresses PETs as design choices for data subject privacy, while AI-7.3 addresses inversion as an adversarial threat. The same technical mechanism may satisfy both requirements.

Verification. The AI system shall verify privacy-enhancing techniques by analysis and test. The analysis shall confirm that the privacy-enhancing techniques applied are appropriate to the personal data sensitivity, processing purpose, and reidentification risk; that the selection rationale is documented including consideration of alternatives; that anonymization or pseudonymization claims are validated against the applicable regulatory standard (e.g., GDPR Article 4(5), HIPAA Safe Harbor at 45 CFR 164.514(b)(2), or Expert Determination at 164.514(b)(1)); that differential privacy parameters where applied are documented with privacy budget and composition analysis; and that encryption methods meet applicable cryptographic standards. The test shall confirm that applied techniques function as designed under representative operational conditions; that anonymization is robust against reidentification using documented adversary capability assumptions; and that privacy guarantees do not degrade unacceptably under operational use patterns.

Success criteria. The verification shall be considered successful when the analysis and test show that PETs are appropriate to risk and purpose, selection is documented with alternatives considered, anonymization meets the applicable regulatory standard, differential privacy parameters are documented with composition analysis, encryption meets cryptographic standards, techniques function under operational conditions, and privacy guarantees are robust against documented adversary assumptions.

AI-10.5 Cross-Border Data Transfer Controls

The AI system shall identify and control cross-border transfers of personal data using mechanisms appropriate to the source and destination jurisdictions.

Rationale. Personal data transferred across jurisdictional boundaries is subject to additional regulatory requirements. GDPR Chapter V restricts transfers outside the European Economic Area to jurisdictions with adequacy decisions, transfers under Standard Contractual Clauses, transfers under Binding Corporate Rules, or transfers under enumerated derogations. Other jurisdictions impose analogous restrictions (e.g., China PIPL, India DPDP, Brazil LGPD). AI systems often involve transfers that are not obvious: cloud-hosted training infrastructure, third-party annotation services, regional inference endpoints, model weights derived from trans-jurisdictional training data. Each transfer point must be identified and brought under an appropriate transfer mechanism, or the system must be architected to avoid the transfer.

Verification. The AI system shall verify cross-border data transfer controls by inspection and analysis. The inspection shall confirm that personal data flows are mapped across all AI lifecycle stages including data collection, training infrastructure, third-party services, model storage, and inference endpoints; that cross-border transfers are identified with source and destination jurisdictions; that transfer mechanisms are documented for each transfer (adequacy decision, SCCs, BCRs, derogations, or other applicable mechanism); and that jurisdictional limitations of system deployment are documented in the ODD under Regulatory and Operational Authorization. The analysis shall confirm that selected transfer mechanisms are valid under current regulatory guidance; that transfer impact assessments have been performed where required (e.g., post-Schrems II requirements for transfers to certain jurisdictions); and that contingency plans exist for transfer mechanism invalidation.

Success criteria. The verification shall be considered successful when the inspection and analysis show that personal data flows are mapped, cross-border transfers are identified with jurisdictions, transfer mechanisms are documented and valid, transfer impact assessments are complete where required, and contingency plans exist for mechanism invalidation.

AI-10.6 Privacy Impact Assessment

The AI system shall conduct a Privacy Impact Assessment (PIA) or Data Protection Impact Assessment (DPIA) where required by applicable regulation, addressing privacy risks across the AI lifecycle and documenting risk mitigation measures.

Rationale. Privacy impact assessment is mandated for high-risk processing under GDPR Article 35 and recommended as a best practice across most modern privacy frameworks. AI systems frequently meet GDPR DPIA triggering criteria: systematic evaluation of personal aspects (Article 35(3)(a)), large-scale processing of special categories (Article 35(3)(b)), and systematic monitoring (Article 35(3)(c)). Beyond regulatory compliance, PIAs surface privacy risks that would otherwise be invisible: re-identification risk in anonymized datasets, membership inference susceptibility, function creep beyond original purpose, and downstream privacy harms from automated decisions. The PIA is the integrating artifact that ties together AI-10’s other sub-requirements.

Verification. The AI system shall verify privacy impact assessment by inspection. The inspection shall confirm that a PIA or DPIA has been conducted addressing the AI system; that the assessment covers personal data flows, lawful basis, data subject rights implementation, privacy-enhancing techniques applied, crossborder transfers, and re-identification and inference attack risks; that the assessment is traceable to the declared ODD Subject Population (AI-1.0); that mitigation measures are documented for each identified risk; that the assessment has been reviewed and approved by an authority with privacy responsibility (e.g., Data Protection Officer where required, Privacy Officer, or designated equivalent); and that the assessment is reviewed at periodic intervals or upon material change to the system.

Success criteria. The verification shall be considered successful when the inspection shows that the PIA is complete and covers all required topics, is traceable to the declared ODD, includes documented mitigation measures, is approved by a privacy authority, and is subject to periodic review and changetriggered review.

AI-10.7 Privacy Compliance Audit Trail

The AI system shall maintain an audit trail of privacy-relevant events including data subject rights requests and dispositions, consent grants and withdrawals, crossborder transfer authorizations, identified privacy incidents, and PIA reviews and updates.

Rationale. Regulatory compliance under GDPR, HIPAA, CCPA, and analogous frameworks requires demonstrable evidence of proper privacy handling. GDPR Article 30 specifies records of processing activities; HIPAA 164.316 requires policies and procedures documentation with retention; CCPA requires verification records for data subject requests. Beyond compliance, the privacy audit trail supports incident scoping, regulatory inquiries, and demonstration of accountability. This requirement is the privacy-domain complement to the classification compliance audit trail established in AI-1.8; the two audit trails serve distinct regulatory regimes and are maintained separately even where the underlying logging infrastructure is shared.

Verification. The AI system shall verify privacy compliance audit trail by inspection. The inspection shall confirm that data subject rights requests are logged with timestamps, requestor identification (or appropriate pseudonymous identifier), request type, response timeline, and disposition; that consent grants and withdrawals are logged with timestamps and consent text version; that crossborder transfer authorizations are logged with destination jurisdiction and transfer mechanism; that identified privacy incidents are logged with timestamps, discovery method, scope estimate, notification actions, and remediation; that PIA reviews and updates are logged with timestamps and approver; and that audit trail records are retained for periods consistent with applicable regulatory requirements.

Success criteria. The verification shall be considered successful when the inspection shows that data subject rights, consent events, transfer authorizations, privacy incidents, and PIA reviews are logged with required content, and that retention periods meet applicable regulatory requirements under each privacy framework that applies to the system.

AI-11 Multi-Model Systems

The AI system will, when implemented as a multi-model system, manage intermodel coordination, combined confidence representation, cascading failure mitigation, and operator-facing display of multi-model decisions in a manner that preserves overall system reliability and operator interpretability. Multi-model systems combine outputs from two or more AI models. Examples include a perception model feeding a planning model, multiple specialized classifiers contributing to a fused decision, ensemble architectures with voting or weighted aggregation, and retrieval-augmented generation pipelines. These systems exhibit failure modes that single-model systems do not, including coordination drift, conflicting outputs, error propagation, combined-confidence misrepresentation, and correlated failures. The following sub-requirements apply to AI systems that incorporate two or more interacting AI models. Applicable Domain Standards • General: ISO/IEC 22989:2022; ISO/IEC 5338:2023 • Aerospace: NPR 7150.2D §4 (Software Lifecycle Processes); NASA-STD8739.8B (Software Assurance); neither directly addresses multi-model AI architecture; framework-defined • Aviation: SAE ARP4754B §4 (Development assurance for systems and items); SAE ARP6983/EUROCAE ED-324 (forward reference, Q1 2026) • Automotive: ISO 26262-6:2018 §7 (Software architectural design); ISO 21448:2022 §5 (Specification and design) • Medical: IEC 62304:2006+A1:2015 §5.3 (Software architectural design); FDA AI-Enabled Device Software Functions guidance Section IX (Model

AI-11.1 Multi-Model Architecture Documentation

The AI system shall document the multi-model architecture including the role of each model, the data flow between models, the interface specifications for modelto-model data exchange, the combined system-level performance requirements, and the failure mode analysis addressing cascading and correlated failure scenarios.

Rationale. Multi-model architectures introduce coordination concerns that singlemodel systems do not face. Without explicit architecture documentation, intermodel dependencies are implicit and the system cannot be assessed against the failure modes that multi-model coordination introduces.

Verification. The AI system shall verify multi-model architecture documentation by inspection. The inspection shall confirm the architecture documentation identifies the role of each model, specifies the data flow between models, defines the interface specifications for model-to-model data exchange, states the combined system- level performance requirements, and includes a failure mode analysis addressing cascading and correlated failure scenarios.

Success criteria. The verification shall be considered successful when the inspection shows that the architecture documentation identifies the role of each model, specifies inter-model data flow, defines model-to-model interface specifications, states combined system-level performance requirements, and includes a failure mode analysis addressing cascading and correlated failures, and the documentation is complete, accurate, and available for assessor review.

AI-11.2 Cascading Failure Mitigation

The AI system shall implement and document mitigations for cascading failure scenarios in chained model architectures, including error propagation between sequential models, confidence degradation across model chains, out-ofdistribution propagation where upstream OOD outputs appear in-distribution to downstream models, and latency accumulation in time-critical decision paths.

Rationale. When AI models are chained, errors can amplify or be masked, combined confidence is generally lower than individual model confidence, and OOD detection at the system entry point may not catch outputs that drift OOD between models. Latency accumulation in sequential processing affects timecritical decisions.

Verification. The AI system shall verify cascading failure mitigation by analysis and test. The analysis shall confirm mitigations are documented for error propagation between sequential models, confidence degradation across model chains, out-ofdistribution propagation where upstream out-of-distribution outputs appear indistribution to downstream models, and latency accumulation in time-critical decision paths. The test shall demonstrate that the documented mitigations operate as designed under representative cascading-failure conditions.

Success criteria. The verification shall be considered successful when the analysis and test show that mitigations are documented for error propagation between sequential models, confidence degradation across model chains, out-ofdistribution propagation, and latency accumulation, and that the mitigations are demonstrated to operate as designed under representative test conditions.

AI-11.3 Ensemble Coordination

The AI system shall implement and document coordination mechanisms for ensemble and voting architectures, including controls against correlated failures (where models trained on similar data fail on the same inputs), documented voting threshold rationale (majority, unanimous, or weighted voting schemes), and disagreement handling when models disagree beyond defined thresholds.

Rationale. Ensemble systems are intended to provide robustness through model diversity, but correlated failures can defeat this intent. Voting threshold selection materially affects ensemble behavior and requires justification.

Verification. The AI system shall verify ensemble coordination by analysis and test. The analysis shall confirm the coordination mechanisms include controls against correlated failures, documented rationale for the selected voting threshold (majority, unanimous, or weighted), and defined handling for cases where models disagree beyond established thresholds. The test shall demonstrate that the coordination mechanisms operate per the documented design under representative scenarios, including disagreement cases.

Success criteria. The verification shall be considered successful when the analysis and test show that the coordination mechanisms include controls against correlated failures, documented voting threshold rationale, and defined disagreement handling, and that the mechanisms operate per the documented design under representative test scenarios including disagreement cases.

AI-11.4 Combined Confidence Representation

The AI system shall compute and display combined confidence values that accurately represent the aggregate uncertainty across all participating models. Multi-model confidence displays shall include combined system-level confidence clearly labeled, individual model contributions visible on demand, visual indication when models disagree beyond defined thresholds, and clear mapping between confidence levels and recommended operator action per Section 5.1 (Threshold Selection Guidance).

Rationale. Operators interacting with multi-model systems need to understand both the aggregate confidence and the contribution of each model to diagnose unusual outputs and exercise appropriate authority. Cascaded model architectures generally compute combined confidence as the product of individual confidences (assuming independence) or via Bayesian propagation; ensemble architectures may use weighted average, minimum (most conservative), or ensemble-specific calibration. The presentation method must support operator interpretation.

Verification. The AI system shall verify combined confidence representation by test. The test shall confirm combined confidence is computed by the documented method and accurately represents the aggregate uncertainty across all participating models, the combined system-level confidence is clearly labeled, individual model contributions are visible on demand, model disagreement beyond defined thresholds is visually indicated, and confidence levels map to recommended operator action per Section 5.1 (Threshold Selection Guidance).

Success criteria. The verification shall be considered successful when the test shows that combined confidence is computed by the documented method, the combined confidence and individual model contributions are displayed as required, model disagreement is visually indicated, confidence levels map to recommended operator action, and the operator interface is validated through scenario-based testing including disagreement cases.

AI-11.5 Multi-Model Audit Trail

The AI system shall maintain an audit trail of multi-model decisions including which models contributed to each output, the contribution weights or confidence values, the aggregation method applied, and the resulting decision rationale.

Rationale. Post-mission analysis, incident investigation, and certification surveillance require the ability to reconstruct multi-model decisions including the contribution of each constituent model.

Verification. The AI system shall verify the multi-model audit trail by inspection. The inspection shall confirm the audit trail records which models contributed to each output, the contribution weights or confidence values, the aggregation method applied, and the resulting decision rationale, and that records are retained per AI-1.8 (Classification Compliance Audit Trail).

Success criteria. The verification shall be considered successful when the inspection shows that the audit trail records the contributing models, their contribution weights or confidence values, the aggregation method applied, and the resulting decision rationale, and that the audit trail is complete, accurate, and retained per AI-1.8 (Classification Compliance Audit Trail).

AI-12 Neural Networks

The AI system will, when implemented using neural network architectures, address the specific failure modes of neural architectures including confidence miscalibration, the absence of inspectable decision logic, training integrity concerns, adversarial vulnerability, generative hallucination, and transformationinduced behavioral drift.

AI-12.1 Neural Network Architecture Documentation

The AI system shall document neural network architecture details in addition to standard software documentation, including layer types, dimensions, and connectivity; activation functions and normalization schemes; total parameter count and memory footprint; computational requirements (FLOPs) for inference; optimizer configuration, learning rate schedule, and regularization; batch size and training duration; data augmentation techniques; hardware and framework versions used; accuracy metrics across data subsets and operational scenarios; calibration curves for confidence outputs; latency and throughput on target hardware; known failure modes and limitations; and the deployment artifact chain with traceability and cryptographic hashes at each transformation step.

Rationale. Neural network behavior depends on architectural choices, training configuration, and deployment transformations in ways not present in traditional software. Comprehensive architecture documentation is required for assessor evaluation and post-mission analysis.

Verification. The AI system shall verify neural network architecture documentation by inspection. The inspection shall confirm the documentation records the network architecture (layer types, dimensions, connectivity, activation and normalization schemes, parameter count, memory footprint, and inference computational requirements), the training configuration (optimizer, learning rate schedule, regularization, batch size, training duration, data augmentation, and hardware and framework versions), the performance characterization (accuracy across data subsets and operational scenarios, calibration curves, latency and throughput on target hardware, and known failure modes and limitations), and the deployment artifact chain with traceability and cryptographic hashes at each transformation step.

Success criteria. The verification shall be considered successful when the inspection shows that the architecture, training configuration, performance characterization, and deployment artifact chain are documented as required, and the documentation is complete, accurate, and current with the deployed system.

AI-12.2 Confidence Calibration

The AI system shall demonstrate that model confidence outputs are calibrated against actual prediction accuracy. Calibration techniques such as temperature scaling, Platt scaling, or isotonic regression shall be applied where calibration error exceeds thresholds established per Section 5.1 (Threshold Selection Guidance), and calibration shall be validated on representative held-out data.

Rationale. Neural network confidence scores (typically softmax outputs) are often poorly calibrated. A model reporting 90% confidence may be correct only 70% of the time. Operators relying on AI confidence to make decisions are misled by uncalibrated confidence outputs. Scope extension: under the AI-12 area scope note, this requirement applies beyond neural networks. AI-12.2 additionally applies to AI systems implemented with other statistical machine learning models, including gradient-boosted trees, random forests, and support vector machines, because these model families exhibit the same confidence miscalibration failure mode. A system built on gradient boosting or a random forest is subject to confidence calibration even where no neural network component is present.

Verification. The AI system shall verify confidence calibration by analysis and test. The analysis shall confirm calibration error is measured against actual prediction accuracy, calibration thresholds are established per Section 5.1 (Threshold Selection Guidance), and any calibration techniques applied (such as temperature scaling, Platt scaling, or isotonic regression) are justified. The test shall demonstrate that model confidence outputs are calibrated against actual accuracy on representative held-out data and that calibration error remains within the established thresholds.

Success criteria. The verification shall be considered successful when the analysis and test show that confidence calibration is validated against actual accuracy on representative held-out data, calibration error is documented, and any calibration techniques applied are justified.

AI-12.3 Neural Network Explainability Methods

The AI system shall implement explainability methods appropriate to the neural network architecture and decision criticality, with method selection documented and justified. For Safety-Critical AI functions, the AI system shall document the rationale for selecting neural network architectures over inherently interpretable alternatives (decision trees, rule-based systems, linear models) when interpretable alternatives could achieve required performance.

Rationale. Neural networks present inherent explainability challenges because decision logic is distributed across learned weights rather than explicit rules. Posthoc methods such as SHAP, LIME, attention visualization, and layer-wise relevance propagation provide explanations of individual predictions but do not constitute proof of correct decision logic. For high-criticality functions, the choice to use a neural network rather than an interpretable alternative is itself a design decision requiring justification.

Verification. The AI system shall verify neural network explainability methods by inspection and test. The inspection shall confirm explainability methods appropriate to the architecture and decision criticality are documented with selection rationale, and that any Safety-Critical use of a neural network over an inherently interpretable alternative is justified per AI-8 (Explainability). The test shall demonstrate that the implemented explainability methods generate explanations for individual predictions as documented.

Success criteria. The verification shall be considered successful when the inspection and test show that explainability methods are implemented and validated, method selection rationale is documented, and any Safety-Critical use of neural networks over interpretable alternatives is justified per AI-8 (Explainability).

AI-12.4 Training Integrity

The AI system shall implement and document training integrity controls including: documented overfitting indicators and the threshold beyond which retraining is required; documented relationship between model architecture complexity and training data volume; documented random seeds and training configurations to enable reproducibility; and validation set contamination controls beyond [R.AI-1.1] (Dataset Separation) and [R.AI-1.2] (Partition Use Restriction), specifically addressing hyperparameter tuning on validation data and architecture decisions informed by validation performance.

Rationale. Neural network and other statistical machine learning training introduces risks not present in traditional software development. Models with sufficient capacity can memorize training data rather than learning generalizable patterns. Hyperparameter tuning effectively incorporates validation information into the model. Stochastic training processes introduce reproducibility concerns. These risks require specific controls beyond the algorithm-agnostic dataset partitioning requirements. Scope extension: under the AI-12 area scope note, this requirement applies beyond neural networks. AI-12.4 additionally applies to AI systems implemented with other statistical machine learning models, including gradient-boosted trees, random forests, and support vector machines, because these model families exhibit the same overfitting and memorization failure modes. A system built on gradient boosting or a random forest is subject to training integrity controls even where no neural network component is present.

Verification. The AI system shall verify training integrity by inspection and analysis. The inspection shall confirm training integrity controls are documented, including overfitting indicators and the retraining threshold, the relationship between architecture complexity and training data volume, random seeds and training configurations enabling reproducibility, and validation set contamination controls beyond AI-1.1 (Dataset Separation) and AI-1.2 (Partition Use Restriction). The analysis shall confirm the documented controls were applied during development and are verifiable from training records.

Success criteria. The verification shall be considered successful when the inspection and analysis show that training integrity controls are documented, applied during development, and verifiable from training records.

AI-12.5 Neural Network Out-Of-Distribution Detection Extensions

The AI system shall implement out-of-distribution detection methods appropriate to neural network architectures, recognizing that softmax confidence alone is insufficient for OOD detection. OOD detection for neural networks shall use methods that account for the tendency of neural networks to produce highconfidence predictions on inputs far from the training distribution, such as ensemble disagreement, energy-based methods, feature-space distance metrics, or deep generative model likelihood.

Rationale. Neural networks often produce high softmax confidence scores on inputs outside the training distribution. Standard OOD detection per [R.AI-6.2] requires neural-network-specific extensions to be effective.

Verification. The AI system shall verify neural network out-of-distribution detection extensions by test. The test shall demonstrate that the out-of-distribution detection methods are effective on representative out-of-distribution test data, account for the tendency of neural networks to produce high-confidence predictions on inputs far from the training distribution, and that the chosen method (such as ensemble disagreement, energy-based methods, feature-space distance metrics, or deep generative model likelihood) is justified relative to the neural network architecture and extends the standard detection required by AI-6.2.

Success criteria. The verification shall be considered successful when the test shows that out-of-distribution detection methods are validated on representative out-of-distribution test data and the chosen method is justified relative to the neural network architecture.

AI-12.6 Adversarial Vulnerability Mitigation

The AI system shall implement adversarial robustness measures specific to neural network attack classes, including testing against gradient-based attacks (FGSM, PGD, C&W) and gradient-free attacks. Adversarial defenses shall be evaluated for gradient masking, where defenses appear to reduce gradient-based attack success but do not actually improve robustness.

Rationale. Neural networks are uniquely susceptible to adversarial examples: inputs with imperceptible perturbations that cause dramatic misclassification. This vulnerability is fundamental to gradient-based learning and cannot be fully eliminated. Some adversarial defenses create a false sense of security by masking gradients rather than improving robustness, requiring evaluation with gradient-free attacks. Neural-network-specific adversarial measures supplement [R.AI-7.2] (Adversarial Input Manipulation Protection).

Verification. The AI system shall verify adversarial vulnerability mitigation by test. The test shall demonstrate that adversarial robustness is evaluated against both gradient-based attack classes (such as FGSM, PGD, and C&W) and gradient-free attack classes, that apparent robustness is not attributable to gradient masking, and that residual vulnerability is documented, supplementing the protection required by AI-7.2 (Adversarial Input Manipulation Protection).

Success criteria. The verification shall be considered successful when the test shows that adversarial robustness is validated against both gradient-based and gradient-free attack classes, gradient masking is excluded as the source of any apparent robustness, and residual vulnerability is documented.

AI-12.7 Generative Model Hallucination Constraints

For neural networks that generate outputs (text, trajectories, plans, code, images), the AI system shall implement domain-specific hallucination constraints including physical plausibility checks (conservation laws, kinematic limits, domain-specific bounds), cross-validation with independent sensors or models where available, confidence-bounded outputs (refusing to generate beyond confidence thresholds), and output format constraints that limit the space of generable outputs to verifiable forms.

Rationale. Generative neural models can produce plausible-seeming outputs that are factually incorrect or physically infeasible. Hallucination detection per [R.AI-5] requires generative-model-specific constraints to be effective in safety-critical contexts.

Verification. The AI system shall verify generative model hallucination constraints by analysis and test. The analysis shall confirm the documented constraints include physical plausibility checks (conservation laws, kinematic limits, domain-specific bounds), crossvalidation with independent sensors or models where available, confidencebounded outputs, and output format constraints that limit generable outputs to verifiable forms, supplementing the hallucination detection required by AI-5. The test shall demonstrate that the implemented constraints bound the system’s output space within verifiable limits per the operational context.

Success criteria. The verification shall be considered successful when the analysis and test show that generative output constraints are documented, implemented, and demonstrated to bound the system’s output space within verifiable limits per the operational context.

AI-12.8 Deployment Transformation Validation (Neural Network Considerations)

CONSIDERATIONS) Neural network deployment transformations shall be validated per [R.AI-4.7] (Deployment Format Validation), with neural-network-specific attention to: quantization sensitivity (per-layer impact analysis, post-quantization calibration on representative data); pruning effects (validation that pruned models do not exhibit different failure modes than original models); knowledge distillation (validation that distilled student models preserve teacher model behavior on out-of-distribution inputs and edge cases); and framework conversion (numerical equivalence validation between source and target frameworks with documented acceptable tolerances).

Rationale. Neural networks are particularly sensitive to deployment-format transformations. Reducing precision can cause catastrophic accuracy degradation in some layers, pruning can introduce different failure modes, distillation may not preserve out-of-distribution behavior, and framework conversion can introduce numerical differences due to operator implementation variations. AI-4.7 establishes the general normative requirement; this sub-requirement specifies the neural-network-specific concerns.

Verification. CONSIDERATIONS) The AI system shall verify deployment transformation validation by test, per [V.AI4.7] (Deployment Format Validation). The test shall demonstrate the validation evidence required by [V.AI-4.7], with neural-network-specific attention to quantization sensitivity (per-layer impact analysis and post-quantization calibration on representative data), pruning effects (confirmation that pruned models do not exhibit different failure modes than the original), knowledge distillation (confirmation that distilled student models preserve teacher behavior on out-of-distribution inputs and edge cases), and framework conversion (numerical equivalence between source and target frameworks within documented tolerances).

Success criteria. The verification shall be considered successful when the test shows that deployment transformations satisfy [V.AI-4.7] with neural-networkspecific validation evidence demonstrating that the quantization, pruning, distillation, and framework-conversion concerns are addressed.

AI-13 Continuous Learning and Adaptation

The AI system will, when implementing continuous learning or adaptation during operations, control the conditions under which learning occurs, validate what is being learned, preserve the ability to detect and recover from learning that produces degraded behavior, and maintain transparency over the system’s learning history. Continuously-learning systems update their model parameters during operation based on observed data. ISO/IEC 22989:2022 5.11.9.2 defines continuous learning as incremental training that occurs during operation. While continuous learning enables AI systems to adapt to operational environments and address drift (improving mission effectiveness when properly controlled), it introduces failure modes that statically-trained systems do not exhibit, including catastrophic forgetting, learning data drift, online learning instability, and the inability to verify the operational model against a fixed validation baseline. The following subrequirements apply to AI systems implementing continuous learning during operations. Applicable Domain Standards • General: ISO/IEC 22989:2022 5.11.9.2; ISO/IEC 5338:2023 • Aerospace: NPR 7150.2D §4 (Software Lifecycle Processes); NASA-STD8739.8B (Software Assurance); current NASA guidance heavily restricts postdeployment learning; framework-defined for continuous learning • Aviation: FAA AI Safety Roadmap, p.10 (“Differentiate Between Learned AI and Learning AI” principle); directly addresses learning-AI safety assurance methodology • Automotive: ISO 21448:2022 §13 (Operation phase activities) for fieldmonitoring of evolving systems; UNECE WP.29 R157 §5.2 for post-market ALKS changes • Medical: FDA AI-Enabled Device Software Functions guidance Section III (TPLC Approach: General Principles); FDA Predetermined Change Control Plan (PCCP) Guidance; central FDA framework for post-market AI/ML changes • Industrial: ISO 13849-1 (Functional safety of control systems); does not address continuous learning; framework-defined

AI-13.1 Continuous Learning Permission Criteria

The AI system shall declare the conditions under which continuous learning is permitted, including the system classification tier, the operational scenarios in which learning may occur, the data sources from which learning may proceed, and the controls required at each tier. Safety-Critical AI continuous learning requires rollback capability, approval for model updates prior to activation, shadow mode validation before operational use, and automated performance bounds monitoring. Mission-Critical AI continuous learning requires performance monitoring per AI-4, automated rollback at defined thresholds, logging of all model updates, and periodic review of learning trajectory. Operational Support AI continuous learning requires baseline performance tracking and anomaly alerting for significant behavior changes.

Rationale. Continuous learning has different risk profiles depending on system classification and operational context. Permission criteria scale the required controls to the consequences of degraded learning outcomes.

Verification. The AI system shall verify continuous learning permission criteria by inspection. The inspection shall confirm the permission criteria declare the system classification tier, the operational scenarios in which learning may occur, the permitted data sources, and the controls required at each tier, and that the controls are classification-appropriate (Safety-Critical AI requiring rollback capability, pre-activation approval, shadow mode validation, and automated performance bounds monitoring; Mission-Critical AI requiring performance monitoring per AI-4, automated rollback at defined thresholds, update logging, and periodic learning-trajectory review; and Operational Support AI requiring baseline performance tracking and anomaly alerting).

Success criteria. The verification shall be considered successful when the inspection shows that continuous learning permission criteria are documented, classification-appropriate, and enforced by system controls.

AI-13.2 Runtime Learning Controls

The AI system shall implement runtime controls that prevent learning when defined preconditions are not met, including controls for safety-critical operational windows, controls when learning data sources are suspect, and controls when system confidence is below validated thresholds.

Rationale. Continuous learning permitted under all conditions risks incorporating poisoned data, learning during anomalous operational states, or amplifying lowconfidence behavior. Runtime controls operationalize the permission criteria declared under AI-13.1.

Verification. The AI system shall verify runtime learning controls by test. The test shall demonstrate that runtime controls prevent learning when defined preconditions are not met, including during safety-critical operational windows, when learning data sources are suspect, and when system confidence is below validated thresholds, operationalizing the permission criteria declared under AI-13.1.

Success criteria. The verification shall be considered successful when the test shows that runtime learning controls prevent learning under each documented precondition violation through test scenarios.

AI-13.3 Learning Data Validation

The AI system shall validate learning data quality before incorporating it into model updates, including data freshness (recency relative to operational distribution), source legitimacy (trusted data origin), and absence of poisoning indicators (anomaly detection on learning data prior to use).

Rationale. Learning data quality directly determines what the model learns. Without validation, continuous learning is vulnerable to data poisoning, distribution shift in learning data, and incorporation of stale data that misrepresents current operational conditions.

Verification. The AI system shall verify learning data validation by test and analysis. The analysis shall confirm the validation criteria address data freshness (recency relative to the operational distribution), source legitimacy (trusted data origin), and poisoning indicators (anomaly detection on learning data prior to use). The test shall demonstrate that learning data failing the freshness, legitimacy, or poisoning checks is rejected before incorporation into model updates.

Success criteria. The verification shall be considered successful when the test and analysis show that learning data validation is implemented and demonstrated to reject learning data that fails freshness, legitimacy, or poisoning checks.

AI-13.4 Catastrophic Forgetting Mitigation

The AI system shall implement and verify mitigations against catastrophic forgetting (loss of previously-validated capabilities through new learning), using methods such as elastic weight consolidation, progressive neural networks, replay buffers, or other techniques appropriate to the model architecture and learning paradigm.

Rationale. Per ISO/IEC 22989:2022, continuous learning systems are susceptible to catastrophic forgetting where new learning overwrites previously acquired knowledge. Without mitigation, continuous learning can degrade validated capabilities even as it improves performance on new tasks.

Verification. The AI system shall verify catastrophic forgetting mitigation by test. The test shall demonstrate that the implemented mitigations (such as elastic weight consolidation, progressive neural networks, or replay buffers appropriate to the model architecture and learning paradigm) retain previously-validated capabilities after continuous learning episodes.

Success criteria. The verification shall be considered successful when the test shows that catastrophic forgetting mitigations retain previously-validated capabilities after continuous learning episodes.

AI-13.5 Learning Validation

The AI system shall validate continuous learning updates against benchmark performance criteria before the updated model becomes the operational model. Updates that fail validation shall be rejected and the prior validated model retained.

Rationale. Without pre-activation validation, learning updates that produce degraded behavior become operational before the degradation is detected. Preactivation validation is the gate that prevents this.

Verification. The AI system shall verify learning validation by test. The test shall demonstrate that continuous learning updates are validated against benchmark performance criteria before becoming the operational model, that updates failing validation are rejected with the prior validated model retained, and that accepted updates meet or exceed prior performance on the benchmark suite.

Success criteria. The verification shall be considered successful when the test shows that learning validation rejects updates that fail benchmark criteria, and accepted updates meet or exceed prior performance on the benchmark suite.

AI-13.6 Rollback Procedures

The AI system shall implement rollback procedures that restore a prior validated model state when continuous learning updates produce degraded performance after activation. Rollback shall be invokable both automatically (on thresholdtriggered detection) and manually (by qualified operator authority).

Rationale. Pre-activation validation reduces but does not eliminate the risk of degraded learning outcomes reaching operations. Rollback procedures provide the recovery path when post-activation degradation is detected.

Verification. The AI system shall verify rollback procedures by test. The test shall demonstrate that rollback restores a prior validated model state when continuous learning updates produce degraded performance after activation, invokable both automatically (on threshold-triggered detection) and manually (by qualified operator authority).

Success criteria. The verification shall be considered successful when the test shows that rollback restores the prior validated model state both automatically under threshold scenarios and on manual operator command.

AI-13.7 Odd Evolvability Declaration

The AI system shall declare its ODD evolvability per AI-1.0, specifying whether the operational design domain is permitted to evolve through continuous learning, the bounds within which evolution may occur, and the conditions that trigger ODD reassessment.

Rationale. Continuous learning that changes the model’s effective operational envelope changes the system’s ODD. Without explicit ODD evolvability declaration, the relationship between continuous learning and the validated operational envelope is implicit and unverifiable.

Verification. The AI system shall verify the ODD evolvability declaration by inspection. The inspection shall confirm the declaration specifies, per AI-1.0, whether the operational design domain is permitted to evolve through continuous learning, the bounds within which evolution may occur, and the conditions that trigger ODD reassessment, and that the declaration is consistent with the AI-1.0 ODD declaration.

Success criteria. The verification shall be considered successful when the inspection shows that ODD evolvability is declared and consistent with the AI-1.0 ODD declaration, and the bounds and trigger conditions are documented.

AI-13.8 Continuous Learning Audit Trail

The AI system shall maintain an audit trail of all continuous learning events, including data sources used for each learning event, parameter updates applied, validation outcomes, and any rollback actions taken.

Rationale. Post-incident analysis, certification surveillance, and operational accountability require complete reconstruction of the system’s learning history.

Verification. The AI system shall verify the continuous learning audit trail by inspection. The inspection shall confirm the audit trail records the data sources used for each learning event, the parameter updates applied, the validation outcomes, and any rollback actions taken, and that records are retained per AI-1.8 (Classification Compliance Audit Trail).

Success criteria. The verification shall be considered successful when the inspection shows that the continuous learning audit trail is complete, accurate, and retained per AI-1.8 (Classification Compliance Audit Trail).