{ "dataset": { "meta": { "title": "AI Model & System Assurance Control Matrix", "subtitle": "modelverifier.ai — Apeiris Model Assurance Verifier", "domain": "model", "site": "https://modelverifier.ai", "corpus_url": "https://modelverifier.ai/integration/model-controls-full.json", "version": "1.5.0", "schema_version": "1.1.0", "generated_at": "2026-06-27T16:37:10.384Z", "license": "CC BY 4.0", "license_url": "https://creativecommons.org/licenses/by/4.0/", "baseline_control_count": 15, "baseline_controls": [ "LI-01", "LI-04", "LI-06", "TG-01", "TG-05", "EV-01", "EV-06", "EV-07", "EV-09", "OA-01", "OA-07", "BH-03", "BH-05", "CR-01", "CR-02" ], "frameworks": [ "nist_rmf", "nist_ai_600_1", "iso_42001", "eu_ai_act", "sr262", "aisvs", "llm10", "aicm", "mitre", "owasp_aitg" ], "controls_count": 57, "build": { "aisvs_compatibility_note": "Portions of this dataset reference OWASP AI Security Verification Standard v1.0 (CC BY-SA 4.0). Requirement text is paraphrased under fair use and independent authorship — not reproduced verbatim. Mapping identifiers (e.g., C1.1) are used as locators only. See INTEGRATION-GUIDE.md §License.", "content_hash": "sha256:caf10a1a03fc3fca7c288b7a7c81ac850aaab6d800b3cdd4cc9d4598b6eddac8", "cors": "enabled", "framework_count": 10, "generated_by": "build-integration.mjs", "has_warnings": false, "layer_count": 6, "namespace": "apeiris://model", "planes": [ "control", "data", "both", "lifecycle" ], "profile_count": 11, "profiles": [ "general-predictive-ml", "generative-ai", "multimodal", "hosted-api", "continuously-learning", "high-impact-decision", "us-regulated-banking", "eu-high-risk", "gpai-provider", "gpai-systemic-risk", "frontier-capability" ], "release_manifest_url": "https://modelverifier.ai/integration/release-manifest.json", "source_schema": "https://schema.apeiris.ai/model-assurance/v1/model-controls.schema.json", "warning_count": 0 }, "alias_domain": "modelverifier.ai", "attestation_artifact": "ModelAssuranceAttestation", "attestation_control": "CR-08", "canonical_prefix": "apeiris://model/controls/", "description": "Apeiris Model Control Matrix: 57 machine-readable controls across 6 layers.", "domain_number": 2, "domain_slug": "model", "integration_endpoint": "https://apeiris.ai/integration/domains/model-controls-full.json", "layers": 6, "lenses": [ "engineering", "evaluation", "grc", "mlops", "red_team" ], "published": "2026-07-03", "source": "https://apeiris.ai/domains/model/", "source_freshness": { "status": "current", "checked_on": "2026-06-29", "review_cadence": "quarterly" }, "schema_extended_on": "2026-06-29", "extended_schema_fields": [ "validation_objective", "evidence_required", "machine_tests", "human_review", "blocking_effect", "normative_status", "anti_patterns", "update_status" ], "layer_names": [ { "prefix": "LI", "name": "AI Asset, Lineage & Applicability" }, { "prefix": "TG", "name": "Training & Data Governance" }, { "prefix": "EV", "name": "Evaluation, Validation & Release" }, { "prefix": "OA", "name": "Governance, Accountability & Oversight" }, { "prefix": "BH", "name": "Deployment & Runtime Assurance" }, { "prefix": "CR", "name": "Continuous Risk, Incident & Evidence" } ] }, "controls": [ { "id": "LI-01", "layer": "LI", "plane": "control", "name": "Unique Model Identity and Content-Addressed Version Hash", "plain": "Every model version receives a unique identifier and a cryptographic fingerprint so the exact deployed artifact can always be verified and audited.", "threat": { "tags": [ "undisclosed-model-change", "supply-chain-compromise", "unauthorized-deployment" ], "desc": "Without a stable unique identity and cryptographic hash, models can be silently replaced with different artifacts without detection. An adversary with pipeline access (AML.T0044 — Full AI Model Access) can substitute a backdoored or degraded model while preserving the model label. Absent content-addressed identity, behavioral changes cannot be attributed to a specific artifact, making root-cause analysis and regulatory documentation impossible. The consequence is undetectable model substitution and complete loss of audit integrity." }, "standard": [ { "id": "nist_rmf", "section": "GOVERN-1.2", "title": "Trustworthy-AI characteristics integrated into policies" }, { "id": "iso_42001", "section": "A.6.2.5", "title": "AI system deployment" }, { "id": "sr262", "section": "Sec. VI", "title": "Governance and controls — model inventory" }, { "id": "aisvs", "section": "C3.1", "title": "Model lifecycle — model authorization & integrity" } ], "sources": [ { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/LI-01 Unique Model Identity and Content-Addressed Version Hash control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary-paid", "status": "current", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/LI-01 Unique Model Identity and Content-Addressed Version Hash control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "title": "SR 26-2: Revised Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "canonical_url": "https://www.federalreserve.gov/supervisionreg/srletters/sr2602.htm", "license": "us-government-public-domain", "supersedes": "SR 11-7, SR 21-8", "status": "current", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/LI-01 Unique Model Identity and Content-Addressed Version Hash control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_aisvs_v1", "title": "OWASP AI Security Verification Standard v1.0", "authority": "Open Worldwide Application Security Project (OWASP)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2026-06-24", "retrieved_on": "2026-06-26", "canonical_url": "https://github.com/OWASP/AISVS", "license": "CC BY-SA 4.0", "status": "current", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "url": "https://github.com/OWASP/AISVS", "source_id": "owasp_aisvs_v1", "relationship": "implementation_pattern", "rationale": "Establishes OWASP AI Security Verification Standard v1.0 requirements informing the apeiris://model/controls/LI-01 Unique Model Identity and Content-Addressed Version Hash control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Assign a globally unique model ID per model+version+provider combination at packaging time; compute a SHA-256 content hash covering weights, tokenizer, and inference configuration; store both in an append-only model registry; enforce hash verification as a blocking gate at every pipeline promotion stage.", "steps": [ "Define a model ID schema encoding model family, provider, and semantic version (e.g., {org}/{family}/{provider}/{semver}). Register uniqueness as a hard constraint in the model registry — duplicate version entries must be rejected, not overwritten.", "Compute SHA-256 over the full artifact bundle (weights file(s), tokenizer config, inference config, Dockerfile or serving spec) at packaging time. Store the canonical hash in a cryptographically-signed manifest alongside the model ID.", "Gate CI/CD pipeline promotions (build → staging → production) to recompute and verify the artifact hash against the registry entry. Any mismatch must block promotion and raise an alert to the MLOps team.", "Surface model ID and artifact hash in inference API response headers and structured audit log entries so that every inference can be attributed to a specific, verified artifact." ], "anti_patterns": [ "Using a mutable human-readable label such as 'model-prod' as the unique identifier — labels can be reassigned to different artifacts silently and provide no integrity guarantee.", "Hashing only the weights file and omitting configuration files — behavioral changes introduced via configuration modification bypass the hash check while the weights hash remains valid.", "Treating hash verification as a logging step rather than a blocking gate — a warning-only check allows substituted artifacts to reach production while creating a false sense of integrity control." ] }, "validation": { "design_check": [ "Confirm the model registry schema enforces uniqueness on the (model-family, version, provider) triple and rejects or errors on duplicate version entries rather than overwriting them [ref:sr262_2026].", "Verify the artifact hash computation procedure specification covers weights, tokenizer, and inference configuration as a bundle, and that SHA-256 or stronger is mandated [ref:nist_ai_rmf_1_0].", "Inspect CI/CD pipeline configuration to confirm hash verification is a blocking gate before promotion to each environment — not a logging-only step [ref:iso_42001_2023]." ], "runtime_test": [ "Attempt to deploy an artifact with a modified configuration file while retaining the original model-ID tag; confirm the pipeline rejects the artifact and raises an auditable alert [ref:nist_ai_rmf_1_0].", "Query the inference API after deployment and confirm the model ID and artifact hash appear in response headers or structured audit log entries for sampled requests [ref:owasp_aisvs_v1].", "Retrieve the deployed artifact hash from the registry and independently recompute SHA-256 over the production artifact bundle; confirm the values match [ref:iso_42001_2023]." ], "evidence": [ "model:registry-entry — append-only model registry record containing unique model ID, artifact hash, provider, version, and deployment timestamps [unverified]", "model:deployment-manifest — cryptographically signed deployment manifest containing model ID, hash, and pipeline gate verification result for each promotion stage [unverified]", "model:inference-audit-log-sample — sample of inference audit log entries demonstrating model ID and hash attribution per request [unverified]" ] }, "lenses": { "engineering": { "summary": "Model identity is an infrastructure concern: the registry schema, hash computation procedure, and pipeline gate are owned by ML engineering. A mutable or label-only identity is an architectural defect that invalidates downstream assurance.", "actions": [ "Implement SHA-256 artifact bundle hashing in the model packaging step", "Configure CI/CD pipeline to block promotion on hash mismatch or missing registry entry", "Surface model ID and hash in inference API response headers and audit logs" ], "tools": [ "MLflow Model Registry", "DVC (Data Version Control)", "Weights & Biases Artifacts", "Hugging Face Hub model cards with SHA pinning" ], "failure_signals": [ "Deployment pipeline has no hash verification step — only label-based selection", "Model registry allows overwrite of existing version entries", "Audit logs record model name but not artifact hash" ] }, "evaluation": { "summary": "Evaluation results are meaningless without a verified artifact identity. Every benchmark run must record the artifact hash alongside results so that performance claims can be tied to a specific, immutable model version.", "actions": [ "Record artifact hash in every evaluation run metadata before executing benchmarks", "Verify the artifact hash of the evaluation target against the registry before starting any evaluation run", "Reject or flag evaluation reports that do not include a verified artifact hash reference" ], "failure_signals": [ "Evaluation reports reference a model version label without an artifact hash", "Evaluation environment cannot confirm it is running the same artifact registered for deployment" ] }, "red_team": { "summary": "Red teams must verify that model identity controls are adversarially robust — that pipeline access cannot be used to substitute a modified artifact while preserving the registered model ID.", "actions": [ "Attempt to register a modified artifact under an existing model ID in the registry and verify rejection", "Attempt to bypass the pipeline hash verification gate via configuration manipulation or environment variable override", "Test whether the inference API correctly surfaces the artifact hash or whether a spoofed header can be injected upstream" ], "failure_signals": [ "Pipeline hash check is present but non-blocking — logs a warning rather than rejecting the artifact", "Registry API accepts PUT/PATCH on an existing version entry without elevated authorization" ] }, "grc": { "summary": "Regulators and auditors require the ability to identify the exact model artifact deployed during any period. Model identity is the foundation of all audit trails, incident investigations, and regulatory disclosures including SR 26-2 model inventory requirements.", "actions": [ "Confirm the model registry is append-only with audit-logged access and retention of at least 7 years for SR 26-2 supervised institutions", "Verify that model ID and artifact hash appear in all model risk documentation, regulatory disclosures, and incident reports", "Confirm no model in production scope lacks a registry entry with a verified content hash" ], "metrics": [ "Percentage of deployed models with a verified artifact hash in the append-only registry", "Number of production models without a registry entry (target: zero)" ], "failure_signals": [ "Model risk documentation references model name only — no version or hash", "Any team member can modify registry entries without access control or audit log" ] }, "mlops": { "summary": "Model ID and artifact hash enable MLOps teams to attribute behavioral incidents to specific versions, execute precise rollbacks to verified prior artifacts, and coordinate with SecOps for behavioral change attribution in SIEM/SOAR workflows.", "actions": [ "Integrate model ID and artifact hash into CI/CD pipeline metadata and deployment records", "Configure monitoring to correlate behavioral anomalies with artifact version via model ID in log fields", "Maintain a rollback map from model ID to artifact storage location for each production-eligible version" ], "failure_signals": [ "Incident response team cannot determine which model artifact was deployed at the time of the incident", "Rollback procedure selects by label rather than verified artifact hash, risking selection of an incorrect version" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations maintain human-readable version labels without content-addressed hashes. Achieving 'defined' requires integrating hash computation into CI/CD, enforcing hash verification as a blocking gate, and populating an append-only registry." }, "coverage_note": "This control covers model artifact identity. System-level identity (the composite of model artifact, system prompt, RAG corpus, and tool integrations) is covered by LI-09. Access control to the model registry is a cross-domain concern enforced by securitycontrols.ai — LI-01 specifies the identity scheme and integrity check, not the access policy.", "capability_risk": { "capability_level": "low", "access_mode": "api", "autonomy": "supervised", "external_reach": false, "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "tiers": [ "general-predictive-ml", "generative-ai", "hosted-api", "high-impact-decision", "us-regulated-banking", "eu-high-risk", "frontier-capability" ], "implementers": [ "ML Engineering", "MLOps", "Platform Engineering" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-1.2 (GOVERN function) provides that the characteristics of trustworthy AI are integrated into organizational policies, processes, and practices. LI-01’s unique model identity and content-addressed hashing supply the artifact-level traceability on which accountability and transparency — among the trustworthy-AI characteristics this subcategory integrates into policy — depend.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.5", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.5 (AI system deployment) requires deployment to follow defined requirements, which presupposes knowing exactly which artifact is being deployed. LI-01’s content-addressed identity and promotion-gate hash verification make that determination verifiable at every deployment.", "source_locator": { "section": "Annex A", "clause": "A.6.2.5" }, "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "sr262", "requirement_id": "Sec. VI", "fit": "direct", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. VI (Governance and Controls) describes maintenance of a model inventory as a core governance control. LI-01's unique identifier and content-addressed hash give each inventory entry a verifiable technical anchor, supporting an accurate and current inventory; the guidance itself does not prescribe cryptographic identity mechanisms. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "source_locator": { "section": "Sec. VI (Governance and Controls)" }, "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "uncovered_portion": "Sec. VI covers the broader governance apparatus — policies, roles, and documentation — beyond the artifact-identity mechanism LI-01 provides.", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aisvs", "requirement_id": "C3.1", "fit": "direct", "direction": "bidirectional", "rationale": "OWASP AISVS C3.1 (Model Authorization & Integrity) requires a model registry inventorying all deployed model artifacts and their origin (req 3.1.1) with cryptographic verification of artifacts (3.1.2). LI-01's unique ID and content-addressed hash directly satisfy the registry-integrity requirements.", "source_locator": { "chapter": "C3.1", "chapter_name": "Model Authorization & Integrity" }, "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0044", "fit": "partial", "direction": "control-supports-requirement", "rationale": "MITRE ATLAS AML.T0044 (Full AI Model Access) describes an adversary gaining access to a model artifact, which can enable artifact substitution or unauthorized copying. Content-addressed identity makes substitution detectable by exposing hash mismatches. LI-01 is a detective control against this technique; full mitigation additionally requires access controls owned by securitycontrols.ai.", "uncovered_portion": "AML.T0044 encompasses unauthorized model access beyond substitution including model extraction and reuse; access control enforcement is a cross-domain security concern outside LI-01 scope.", "source_version": "v2026.06", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "owasp_aitg", "requirement_id": "AITG-INF-01", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "AITG-INF-01 (Testing for Supply Chain Tampering) verifies that model artifacts have not been substituted or altered between build and deployment. LI-01's unique identifier and content-addressed hash are the reference data a supply-chain tampering test checks artifacts against.", "source_locator": { "test_id": "AITG-INF-01", "test_name": "Testing for Supply Chain Tampering" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "supplychainmanage", "fit": "supporting", "rationale": "Content-addressed model IDs and SHA-256 artifact hashes are the integrity mechanism the AI supply-chain-management control relies on to verify the exact deployed model artifact.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0023", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every deployed model version must have a globally unique model ID and a SHA-256 content…\" enacts ATLAS mitigation AML.M0023 AI Bill of Materials; complements the control’s existing technique mapping AML.T0044 (defends_against) — OpenCRE crosswalks the AI Exchange concept (supplychainmanage) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0014", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every deployed model version must have a globally unique model ID and a SHA-256 content…\" enacts ATLAS mitigation AML.M0014 Verify AI Artifacts; complements the control’s existing technique mapping AML.T0044 (defends_against) — OpenCRE crosswalks the AI Exchange concept (supplychainmanage) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.05", "fit": "supporting", "rationale": "Control \"Every deployed model version must have a globally unique model ID and a SHA-256 content…\" defends against NIST AI 100-2 attack class NISTAML.05 \"Supply Chain Attacks\"; OpenCRE crosswalks this control’s OWASP AI Exchange concept (supplychainmanage) to this NIST class. (Anchor captures the attack taxonomy, so we cite the threat class as defends_against, not the NIST mitigation named by OpenCRE.)", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against", "mapping_confidence": "medium", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "cross_domain": { "references": [ { "uri": "apeiris://security/controls/CM-02", "relationship": "related", "note": "Security domain configuration management enforces access controls on the model registry and artifact storage that LI-01 depends on for tamper-evidence." } ], "evidence_artifacts": [ { "artifact_type": "model:registry-entry", "producer_verifier": "apeiris://model", "consumer_verifiers": [ "apeiris://security" ], "retention": "P7Y" } ] }, "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Identity without integrity is a label, not a control. A model registry entry that can be overwritten or that lacks a cryptographic hash cannot anchor any downstream assurance activity — evaluation results, incident investigations, and regulatory disclosures all depend on asserting 'this exact artifact was deployed.' LI-01 is the prerequisite for the entire LI layer.", "meta": { "authored_on": "2026-06-26", "schema_version": "1.0.0" }, "canonical_id": "apeiris://model/controls/LI-01", "validation_objective": "Every deployed model version must have a globally unique model ID and a SHA-256 content hash computed over the complete artifact bundle (weights, tokenizer, and inference configuration), stored in an append-only registry entry, and verified as a blocking gate before each pipeline promotion stage. Any mismatch between the recomputed artifact hash and the registry entry must produce an auditable rejection event and block the promotion.", "evidence_required": [ "model_registry_entry with unique model ID encoding model-family/provider/version triple, SHA-256 artifact hash, and registration timestamp, stored in an append-only backend where existing version entries cannot be overwritten", "deployment_pipeline_gate_log showing hash recomputation and comparison result for each promotion stage (build to staging, staging to production) with timestamp and approving identity", "inference_api_audit_log_sample demonstrating model_id and artifact_hash present in response headers or structured log fields for at least 10 consecutive sampled inference requests", "registry_duplicate_rejection_log showing that an attempt to register a second artifact under an existing model-family/version/provider triple was rejected" ], "machine_tests": [ "Modify a single byte in the model inference configuration file while retaining the original model ID tag and submit to the deployment pipeline → assert pipeline rejects with hash mismatch error and generates an auditable alert", "Attempt to register a new artifact using an existing model ID and version triple already present in the registry → assert registry returns a uniqueness constraint violation and does not overwrite the existing entry", "Query the inference API for a deployed model and inspect response headers and structured audit log → assert both model_id and artifact_hash fields are present and match the current registry entry", "Recompute SHA-256 over the full production artifact bundle (weights, tokenizer, inference config) and compare to the registry entry hash → assert values match byte-for-byte" ], "human_review": [ "Review the hash computation procedure specification to confirm it covers the weights file(s), tokenizer configuration, and inference configuration as a single bundle and mandates SHA-256 or stronger, not just the compressed archive", "Assess the model registry access log to confirm no existing version entry has been modified or deleted since initial registration, verifying append-only semantics are enforced at the storage layer", "Verify that model ID and artifact hash appear in regulatory documentation, incident reports, and model risk disclosures for each in-scope production model" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Using a mutable human-readable label such as 'gpt4-prod' or 'model-current' as the unique model identifier, allowing silent reassignment to a different artifact without creating an auditable version transition", "Computing the SHA-256 hash of only the weights checkpoint file and omitting the tokenizer configuration and inference settings, allowing behavioral changes introduced through configuration modification to bypass the integrity check while the weights hash remains valid", "Configuring hash verification as a logging step that emits a warning on mismatch rather than a blocking rejection, producing a false audit trail of verified deployments while allowing tampered artifacts to reach production", "Storing the artifact hash in a mutable registry field that can be updated post-deployment to match a substituted artifact, defeating the integrity guarantee", "Omitting model ID and artifact hash from inference API response headers and audit logs, making it impossible to attribute individual inference requests to a specific verified artifact during incident investigation" ], "update_status": "current", "layer_code": "LI" }, { "id": "LI-02", "layer": "LI", "plane": "control", "name": "Model Provenance Chain — Base Model, Fine-Tune, Merge, and Adapter Lineage", "plain": "The full ancestry of a model is recorded — including any base model it was built from, fine-tuning steps, merges, and adapter components — so that inherited risks and license obligations can be traced.", "threat": { "tags": [ "supply-chain-compromise", "undisclosed-model-change", "governance-gap" ], "desc": "Models are rarely trained from scratch; most production models derive from a base model via fine-tuning, merging, or adapter composition. Without explicit provenance tracking, a compromised or backdoored base model (AML.T0018 — Manipulate AI Model) can propagate its behavior into downstream derived models without detection. Similarly, untracked LoRA adapters or merged model components may carry undisclosed behaviors, license violations, or safety regressions. Absent a provenance chain, impact assessment for base model vulnerabilities disclosed by providers is impossible." }, "standard": [ { "id": "nist_rmf", "section": "MAP-4.2", "title": "Internal risk controls for AI system components" }, { "id": "iso_42001", "section": "A.6.2.3", "title": "Documentation of AI system design and development" }, { "id": "aisvs", "section": "C6.2", "title": "Supply chain — AI BOM & supply chain monitoring" }, { "id": "aicm", "section": "MDS-03", "title": "Model documentation — inventory and lineage" } ], "sources": [ { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/LI-02 Model Provenance Chain — Base Model, Fine-Tune, Merge, and Adapter Lineage control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary-paid", "status": "current", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/LI-02 Model Provenance Chain — Base Model, Fine-Tune, Merge, and Adapter Lineage control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_aisvs_v1", "title": "OWASP AI Security Verification Standard v1.0", "authority": "Open Worldwide Application Security Project (OWASP)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2026-06-24", "retrieved_on": "2026-06-26", "canonical_url": "https://github.com/OWASP/AISVS", "license": "CC BY-SA 4.0", "status": "current", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "url": "https://github.com/OWASP/AISVS", "source_id": "owasp_aisvs_v1", "relationship": "implementation_pattern", "rationale": "Establishes OWASP AI Security Verification Standard v1.0 requirements informing the apeiris://model/controls/LI-02 Model Provenance Chain — Base Model, Fine-Tune, Merge, and Adapter Lineage control.", "reviewed_on": "2026-07-01" }, { "id": "mitre_atlas_v5_6_0", "title": "MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems", "authority": "MITRE Corporation", "source_type": "threat-knowledge-base", "normative_force": "best-practice", "version": "5.6.0", "published_on": "2026-05-04", "retrieved_on": "2026-06-26", "canonical_url": "https://atlas.mitre.org", "license": "Apache-2.0", "status": "current", "source_id": "mitre_atlas", "relationship": "informative_reference", "rationale": "Establishes MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems requirements informing the apeiris://model/controls/LI-02 Model Provenance Chain — Base Model, Fine-Tune, Merge, and Adapter Lineage control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Record a structured provenance graph for every registered model artifact: document the base model (with artifact hash and provider version), each fine-tuning step, any merge operations with constituent model hashes, and all attached adapters (LoRA, prefix tuning, etc.) — link the provenance record to the LI-01 registry entry.", "steps": [ "For every model artifact, require a provenance manifest at registration time listing: base model ID and artifact hash, provider and version, fine-tuning dataset reference (pointer to TG-layer record), fine-tuning configuration, and any merge contributors with their hashes.", "Track LoRA adapter and other PEFT component lineage separately: record adapter source, version, base model compatibility hash, and purpose alongside the main model registry entry.", "For merged models (e.g., model soup, SLERP, TIES merging), enumerate all constituent model artifact hashes and merge parameters in the provenance record so the merge is reproducible and auditable.", "Automate provenance graph propagation: when a derived model is registered, automatically copy base-model provenance entries and append the derivation step rather than requiring manual re-entry." ], "anti_patterns": [ "Recording only the immediate parent model and omitting the full ancestry chain — this hides inherited risks from base models several generations back.", "Storing provenance as free-text fields in a model card rather than as a structured, machine-readable graph — free text cannot be queried for impact when a base model vulnerability is disclosed.", "Treating prompt-tuning and prefix-tuning adapters as configuration rather than model components and omitting them from the provenance chain." ] }, "validation": { "design_check": [ "Confirm the model registry schema includes a structured provenance block with typed fields for base-model hash, fine-tuning steps, merge contributors, and adapter components — not just a free-text description field [ref:iso_42001_2023].", "Verify that the provenance manifest format is machine-readable (JSON or similar) and that a query interface exists to find all models derived from a given base model ID [ref:nist_ai_rmf_1_0].", "Review the provenance record for at least one production model end-to-end; confirm it can be traced from the deployed artifact hash back to a documented base model release [ref:owasp_aisvs_v1]." ], "runtime_test": [ "Simulate a base-model vulnerability disclosure: use the provenance graph query to identify all downstream derived models in the registry and confirm the query returns a complete, accurate list within an operationally acceptable time [ref:nist_ai_rmf_1_0].", "Register a new fine-tuned model without providing a required provenance field; confirm the registry rejects the submission [ref:iso_42001_2023].", "Verify that adapter lineage is captured: deploy a model with an attached LoRA adapter and confirm the registry entry records the adapter source, version, and base compatibility hash [unverified]." ], "evidence": [ "model:provenance-manifest — structured provenance graph record per model artifact, covering base model hash, fine-tune steps, merge contributors, and adapters [unverified]", "model:registry-entry — LI-01 registry entry with linked provenance manifest ID [unverified]", "model:base-model-impact-query-result — sample output of a provenance query identifying all models derived from a given base model hash [unverified]" ] }, "lenses": { "engineering": { "summary": "Provenance is a first-class engineering artifact, not documentation. ML engineering must instrument the training pipeline to emit structured provenance manifests automatically at artifact creation time rather than relying on manual recording.", "actions": [ "Instrument the training and fine-tuning pipeline to emit a structured provenance manifest at artifact packaging time", "Build a provenance graph query API on top of the model registry to support downstream-impact queries by base model hash", "Validate provenance manifest completeness as a blocking gate in the model registration step" ], "tools": [ "MLflow Lineage API", "DVC pipeline DAG", "Weights & Biases Artifacts lineage graph", "custom provenance schema on top of PostgreSQL or Neo4j" ], "failure_signals": [ "Provenance fields are free-text — no machine-readable structure", "No query mechanism exists to find derivatives of a given base model", "Adapters and PEFT components are not recorded in the lineage" ] }, "evaluation": { "summary": "Evaluation scope depends on provenance: a safety evaluation of a fine-tuned model must account for behaviors inherited from the base model. Evaluation teams need the full provenance chain to determine which base-model benchmarks can be reused and which require replication.", "actions": [ "Review the provenance chain before scoping a model evaluation to identify which base-model safety properties carry over and which may have been overwritten by fine-tuning", "Flag evaluations where the base model's provenance is unknown or unverified as having incomplete coverage" ], "failure_signals": [ "Evaluation report does not reference base model version or provenance", "Fine-tuned model passes safety evaluation that replicates base model benchmarks only — not testing fine-tune-induced behavioral changes" ] }, "red_team": { "summary": "Red teams targeting derived models must trace the full provenance chain to identify inherited attack surfaces. A backdoor planted in a widely used open-weight base model (AML.T0018) propagates to all derivatives — red teams must test base-model attack vectors on downstream models.", "actions": [ "Retrieve the full provenance chain for the target model before beginning red-team testing", "Test for known base-model attack patterns (jailbreaks, backdoor triggers) on derived models regardless of fine-tuning", "Attempt to register a model with a falsified provenance manifest pointing to a clean base model hash — confirm registry rejects or flags the inconsistency" ], "failure_signals": [ "Red-team report scopes only the fine-tuning layer and does not assess inherited base-model risk", "No mechanism to detect a falsified base-model hash in the provenance manifest" ] }, "grc": { "summary": "Provenance is a prerequisite for license compliance (LI-08) and impact scoping when a base model is disclosed as compromised or recalled. Without a machine-readable provenance chain, the organization cannot answer a regulator's question about which systems are affected by a base model disclosure.", "actions": [ "Confirm provenance records are retained for the lifetime of all derived models plus the applicable regulatory retention period", "Verify that model risk documentation for derived models references the base model provenance record", "Establish a process to trigger impact assessment across all derived models when a base model vulnerability or recall is disclosed" ], "failure_signals": [ "No documented process for base model vulnerability impact scoping across the model portfolio", "Provenance records deleted or archived inaccessibly while derived models remain in production" ] }, "mlops": { "summary": "Provenance enables MLOps to correctly scope rollbacks and incident response: rolling back a fine-tuned model to a prior checkpoint is different from rolling back to the base model, and the provenance record must make these paths explicit.", "actions": [ "Maintain the provenance graph as a live artifact — update it when new fine-tune checkpoints, adapters, or merges are registered", "Use provenance records to scope monitoring: base-model behavioral patterns provide a baseline against which fine-tune drift is measured", "Integrate base-model vulnerability notifications into the MLOps incident response workflow using the provenance query API" ], "failure_signals": [ "Rollback accidentally reverts to a base model checkpoint instead of the intended fine-tuned prior version due to missing provenance distinction", "MLOps team unaware of a base-model provider update because provenance monitoring is not automated" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations track immediate parent models in training logs but lack structured, queryable provenance graphs covering adapters and merge contributors. Achieving 'defined' requires machine-readable provenance manifests enforced at registration." }, "coverage_note": "LI-02 covers model artifact lineage. Training data lineage (pointer to TG-layer dataset records) is covered by LI-05. License and IP obligations inherited through the provenance chain are addressed in LI-08. Supply-chain integrity verification of third-party base models is covered by LI-03.", "capability_risk": { "capability_level": "low", "access_mode": "api", "autonomy": "supervised", "external_reach": false, "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "tiers": [ "frontier-capability" ], "implementers": [ "ML Engineering", "MLOps", "Model Governance" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MAP-4.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MAP-4.2 (MAP function) provides that internal risk controls for AI system components, including third-party AI technologies, are identified and documented. LI-02’s provenance chain documents every component — base model, fine-tunes, merges, adapters — so that component-level risk controls can be identified and verified.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "initial", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.3", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.3 (Documentation of AI system design and development) requires documented development records. LI-02’s machine-readable provenance chain over base models, fine-tunes, merges, and adapters is that record for model composition.", "source_locator": { "section": "Annex A", "clause": "A.6.2.3" }, "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "initial", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aisvs", "requirement_id": "C6.2", "fit": "direct", "direction": "bidirectional", "rationale": "OWASP AISVS C6.2 (AI BOM & Supply Chain Monitoring) requires a version-controlled, machine-readable AI BOM listing datasets, weights, licenses, and data-origin information (req 6.2.1). LI-02's structured provenance chain over base models, fine-tunes, merges, and adapters implements that lineage record.", "source_locator": { "chapter": "C6.2", "chapter_name": "AI BOM & Supply Chain Monitoring" }, "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "initial", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0018", "fit": "partial", "direction": "control-supports-requirement", "rationale": "MITRE ATLAS AML.T0018 (Manipulate AI Model; the backdoor concept is sub-technique AML.T0018.000 Poison AI Model) describes adversaries embedding trigger-activated behaviors into a model artifact that propagate to downstream fine-tunes. A queryable provenance graph enables organizations to identify all models derived from a suspected base model and initiate targeted re-evaluation. LI-02 is a detective and scoping control; mitigation of active backdoor injection requires DT and EV layer controls.", "uncovered_portion": "AML.T0018 mitigation requires backdoor detection during evaluation (EV-04) and training data verification (TG-04); LI-02 only enables impact scoping after a compromise is detected.", "source_version": "v2026.06", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "initial", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "owasp_aitg", "requirement_id": "AITG-INF-01", "fit": "direct", "direction": "control-supports-requirement", "rationale": "AITG-INF-01 (Testing for Supply Chain Tampering) probes whether components in the model supply chain have been tampered with. LI-02's structured provenance graph over base models, fine-tunes, merges, and adapters gives testers the lineage needed to trace and verify every upstream component.", "source_locator": { "test_id": "AITG-INF-01", "test_name": "Testing for Supply Chain Tampering" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "supplychainmanage", "fit": "supporting", "rationale": "Recording base-model, fine-tune, merge, and adapter lineage is the model-component provenance tracking the AI supply-chain-management control calls for.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0023", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every registered model artifact must have a machine-readable provenance manifest…\" enacts ATLAS mitigation AML.M0023 AI Bill of Materials; complements the control’s existing technique mapping AML.T0018 (defends_against) — OpenCRE crosswalks the AI Exchange concept (supplychainmanage) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0014", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every registered model artifact must have a machine-readable provenance manifest…\" enacts ATLAS mitigation AML.M0014 Verify AI Artifacts; complements the control’s existing technique mapping AML.T0018 (defends_against) — OpenCRE crosswalks the AI Exchange concept (supplychainmanage) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.05", "fit": "supporting", "rationale": "Control \"Every registered model artifact must have a machine-readable provenance manifest…\" defends against NIST AI 100-2 attack class NISTAML.05 \"Supply Chain Attacks\"; OpenCRE crosswalks this control’s OWASP AI Exchange concept (supplychainmanage) to this NIST class. (Anchor captures the attack taxonomy, so we cite the threat class as defends_against, not the NIST mitigation named by OpenCRE.)", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against", "mapping_confidence": "medium", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Every fine-tuned model is a derivative work that inherits the risks, limitations, and license obligations of its ancestors. Without a queryable provenance chain, impact assessment for base-model vulnerabilities and regulatory lineage inquiries are manual guesswork. LI-02 makes model ancestry a first-class auditable artifact.", "meta": { "authored_on": "2026-06-26", "schema_version": "1.0.0" }, "canonical_id": "apeiris://model/controls/LI-02", "validation_objective": "Every registered model artifact must have a machine-readable provenance manifest recording the complete ancestry chain including the base model artifact hash and provider version, all fine-tuning steps with dataset references, all merge contributors with their artifact hashes, and all attached adapter components with source and base-model compatibility metadata; and the registry must expose a query interface that returns all derived models for a given base model artifact hash.", "evidence_required": [ "model_provenance_manifest with typed structured fields for base_model_hash, base_model_provider_version, fine_tuning_steps[] each referencing a TG-layer dataset record, merge_contributors[] with per-contributor artifact hashes and merge parameters, and adapter_components[] with source, version, and base_model_compatibility_hash", "provenance_query_api_result showing all registry entries derived from a specified base model artifact hash, confirming complete downstream impact scope is retrievable by automated query", "registry_provenance_rejection_log showing that a model registration attempt with a missing required provenance field (e.g., absent base_model_hash) was blocked", "adapter_lineage_registry_entry for at least one production model with an attached LoRA or PEFT adapter, confirming adapter source and compatibility metadata are recorded" ], "machine_tests": [ "Submit a model registration request omitting the base_model_hash field from the provenance manifest → assert registry rejects the submission and identifies the missing required field", "Register a model with an attached LoRA adapter and retrieve the registry entry → assert the adapter_components[] field contains adapter_source, adapter_version, and base_model_compatibility_hash attributes", "Execute a provenance graph query for all models derived from a known base model artifact hash → assert the result set includes all expected downstream fine-tunes and merged models with their derivation steps enumerated" ], "human_review": [ "Trace the provenance manifest for at least one production model end-to-end from the deployed artifact hash back through all fine-tuning steps to the documented base model release, confirming no ancestor layers are missing or recorded as free text", "Assess the automated provenance graph propagation mechanism to verify that derivation steps are emitted by the training pipeline at artifact packaging time rather than requiring manual entry by the ML engineer", "Evaluate whether the provenance records for any merged model accurately enumerate all constituent model artifact hashes and merge parameters sufficient to reproduce the merge operation and attribute inherited behavioral characteristics" ], "blocking_effect": "blocks-deployment", "normative_status": "certification-standard", "anti_patterns": [ "Recording only the immediate parent model identifier without tracing the full ancestry chain, hiding inherited risks, license propagation, and behavioral characteristics from base models multiple generations back", "Storing provenance information as free-text description fields in the model card rather than as a structured machine-readable graph with typed fields, making it impossible to programmatically query downstream impact when a base model vulnerability is disclosed", "Treating LoRA adapters, prefix-tuning modules, and other PEFT components as inference configuration rather than model lineage artifacts and omitting them from the provenance chain", "Falsifying the base model hash in the provenance manifest to reference a known-clean model while the actual base used during training was different, circumventing impact assessment" ], "update_status": "current", "layer_code": "LI" }, { "id": "LI-03", "layer": "LI", "plane": "control", "name": "Supply Chain Integrity — Third-Party Model Verification and Cryptographic...", "plain": "Before a model from an external source is used, its authenticity and completeness are cryptographically verified using signed checksums and a model bill-of-materials, ensuring the artifact has not been tampered with in transit.", "threat": { "tags": [ "supply-chain-compromise", "unauthorized-deployment", "undisclosed-model-change" ], "desc": "Third-party model artifacts sourced from model hubs, provider APIs, or open-weight repositories traverse infrastructure that may be compromised between publication and deployment (AML.T0018 — Manipulate AI Model). An attacker who compromises a model hub or CDN can substitute a backdoored or trojaned artifact with the same filename and claimed checksum. Without cryptographic verification against a publisher-signed manifest, deployers cannot distinguish a legitimate artifact from a tampered one. Supply chain compromise via this vector (LLM03:2025 — Supply Chain) is a documented and escalating threat pattern for open-weight and API-sourced models." }, "standard": [ { "id": "llm10", "section": "LLM03:2025", "title": "Supply Chain" }, { "id": "nist_rmf", "section": "GOVERN-6.1", "title": "Third-party AI risk policies" }, { "id": "iso_42001", "section": "A.10.3", "title": "Suppliers" }, { "id": "aisvs", "section": "C6.1", "title": "Supply chain — model artifact integrity" } ], "sources": [ { "id": "owasp_llm10_2025", "title": "OWASP Top 10 for Large Language Model Applications 2025", "authority": "Open Worldwide Application Security Project (OWASP)", "source_type": "industry-framework", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-26", "canonical_url": "https://owasp.org/www-project-top-10-for-large-language-model-applications/", "license": "CC BY-SA 4.0", "supersedes": "OWASP LLM Top 10 2023", "status": "current", "flagship": true, "source_id": "owasp_llm10", "relationship": "informative_reference", "rationale": "Establishes OWASP Top 10 for Large Language Model Applications 2025 requirements informing the apeiris://model/controls/LI-03 Supply Chain Integrity — Third-Party Model Verification and Cryptographic... control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/LI-03 Supply Chain Integrity — Third-Party Model Verification and Cryptographic... control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary-paid", "status": "current", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/LI-03 Supply Chain Integrity — Third-Party Model Verification and Cryptographic... control.", "reviewed_on": "2026-07-01" }, { "id": "mitre_atlas_v5_6_0", "title": "MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems", "authority": "MITRE Corporation", "source_type": "threat-knowledge-base", "normative_force": "best-practice", "version": "5.6.0", "published_on": "2026-05-04", "retrieved_on": "2026-06-26", "canonical_url": "https://atlas.mitre.org", "license": "Apache-2.0", "status": "current", "source_id": "mitre_atlas", "relationship": "informative_reference", "rationale": "Establishes MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems requirements informing the apeiris://model/controls/LI-03 Supply Chain Integrity — Third-Party Model Verification and Cryptographic... control.", "reviewed_on": "2026-07-01" }, { "id": "ncsc_cisa_secure_ai_2023", "title": "Guidelines for Secure AI System Development (NCSC/CISA, 2023)", "authority": "UK NCSC & US CISA", "source_type": "government-agency", "normative_force": "supervisory-guidance", "version": "2023", "published_on": "2023-11-27", "retrieved_on": "2026-07-08", "canonical_url": "https://www.ncsc.gov.uk/files/Guidelines-for-secure-AI-system-development.pdf", "relationship": "supporting_guidance", "note": "NCSC/CISA 'Secure your supply chain' supports third-party model verification." } ], "implementation": { "pattern": "Require that every third-party model artifact be verified against a publisher-signed checksum before registration; generate a model SBOM (mSBOM) that enumerates all artifact components, their hashes, and provenance metadata; store the mSBOM as an immutable registry attachment.", "steps": [ "Obtain the publisher's official signed checksum or SHA-256 digest for each third-party artifact from the authoritative source (provider release page, signed manifest, or Sigstore entry). Never use checksums sourced from mirrors or community-generated lists.", "Recompute the SHA-256 hash of the downloaded artifact bundle locally and compare against the publisher-signed digest before registration. Reject and quarantine any artifact with a mismatch.", "Generate a model SBOM (mSBOM) that enumerates all artifact components (weights shards, tokenizer files, configuration files), their individual hashes, the model's license(s), declared provenance, and the verification timestamp and method. Link the mSBOM to the LI-01 registry entry.", "For provider API models where weights are not accessible, document the verification scope limitation explicitly in the mSBOM: record the API endpoint, provider-declared version or model ID, and behavioral regression test results in lieu of artifact hash verification." ], "anti_patterns": [ "Verifying only the compressed archive hash (e.g., the .zip file) and not the extracted artifact bundle — an attacker can craft a valid archive containing a substituted model file.", "Sourcing checksums from the same mirror or repository as the model artifact — a compromised repository can publish a matching checksum for a tampered artifact.", "Skipping mSBOM generation for 'well-known' base models from major providers on the assumption that supply chain risk only affects obscure models." ] }, "validation": { "design_check": [ "Confirm the model onboarding procedure requires publisher-signed checksum verification before registration, with the verification source documented as distinct from the artifact source [ref:owasp_llm10_2025].", "Verify that the mSBOM schema includes individual component hashes, declared license(s), provenance metadata, and verification method — not just a single artifact-level hash [ref:nist_ai_rmf_1_0].", "Confirm the mSBOM is stored as an immutable attachment to the LI-01 registry entry with a creation timestamp and verifier identity [ref:iso_42001_2023]." ], "runtime_test": [ "Corrupt a single byte in a third-party model weight shard and attempt registration; confirm the pipeline detects the mismatch and rejects the artifact [ref:nist_ai_rmf_1_0].", "Verify that the mSBOM for a deployed model is retrievable from the registry and contains all required fields including per-component hashes [ref:iso_42001_2023].", "For a hosted-API model, confirm that the mSBOM documents the verification scope limitation explicitly and includes behavioral regression test results as the substituted evidence [unverified]." ], "evidence": [ "model:msbom — model Software Bill of Materials with per-component hashes, license declarations, provenance metadata, and verification timestamp [unverified]", "model:supply-chain-verification-record — record of publisher-signed checksum retrieval source, comparison result, and verifier identity [unverified]", "model:registry-entry — LI-01 registry entry with linked mSBOM and verification record [unverified]" ] }, "lenses": { "engineering": { "summary": "Supply chain integrity is a pipeline-level control: engineering must implement checksum verification and mSBOM generation as automated, non-bypassable steps in the model acquisition and onboarding pipeline.", "actions": [ "Automate publisher-signed checksum verification in the model acquisition pipeline — no human approval should be required when the hash matches; rejection must be automatic when it does not", "Implement mSBOM generation as a packaging pipeline step that runs immediately after successful verification", "Integrate Sigstore or equivalent artifact signing infrastructure for first-party models to match the verification chain for third-party artifacts" ], "tools": [ "Sigstore/cosign for artifact signing", "CycloneDX or SPDX mSBOM formats", "in-toto framework for pipeline integrity", "sha256sum or cryptographic library verification" ], "failure_signals": [ "Model acquisition pipeline downloads artifacts without checksum verification", "mSBOM is generated manually or is absent for some third-party models", "Checksum verification is a human approval step rather than an automated gate" ] }, "evaluation": { "summary": "Evaluation teams must verify that the model being evaluated matches the registered artifact before running benchmarks. An evaluation performed on an unverified or tampered artifact is invalid.", "actions": [ "Confirm the artifact hash of the model in the evaluation environment matches the registry entry before starting any evaluation", "Record the mSBOM reference in evaluation run metadata so results are tied to the verified artifact" ], "failure_signals": [ "Evaluation environment does not verify artifact hash before running benchmarks", "Evaluation report does not reference the mSBOM or artifact hash" ] }, "red_team": { "summary": "Red teams must probe the supply chain verification pipeline for bypasses: can a tampered artifact be registered by manipulating the checksum source or exploiting gaps in the mSBOM scope?", "actions": [ "Attempt to substitute a model artifact after checksum verification completes but before registration — test whether post-verification integrity is maintained", "Attempt to onboard an artifact with a checksum sourced from a mirror rather than the publisher's authoritative page and verify rejection", "Test whether mSBOM generation can be skipped via pipeline configuration flags or environment overrides" ], "failure_signals": [ "Pipeline allows artifact substitution between verification and registration steps", "mSBOM generation is configurable as optional rather than mandatory" ] }, "grc": { "summary": "The mSBOM is the primary audit artifact for third-party model risk: it documents what was acquired, from whom, when, and with what verification. It also enables license compliance audits by enumerating all model component licenses.", "actions": [ "Confirm mSBOM records are retained for the lifetime of all derived models plus the applicable regulatory retention period", "Verify that mSBOMs are included in model risk documentation for third-party models", "Establish a vendor management process that requires providers to publish signed checksums and notifies deployers of artifact updates" ], "failure_signals": [ "No mSBOM exists for third-party models in production", "Model risk documentation does not reference supply chain verification evidence" ] }, "mlops": { "summary": "MLOps teams must ensure that model updates from providers trigger re-verification and mSBOM regeneration before reaching production. Silent provider-side artifact updates are a supply chain risk that monitoring must detect.", "actions": [ "Configure provider update notifications and trigger re-verification and mSBOM update when a provider publishes a new artifact version", "Monitor the deployed artifact hash against the registry entry on a scheduled basis to detect post-deployment artifact substitution" ], "failure_signals": [ "Provider updates model artifact without triggering re-verification in the deployment pipeline", "No mechanism to detect post-deployment artifact substitution on model serving infrastructure" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations perform informal checksum verification for some models but lack formal mSBOM generation, systematic coverage of all third-party models, and automated pipeline gates. Achieving 'defined' requires automated verification and mSBOM generation for all third-party acquisitions." }, "coverage_note": "LI-03 covers supply chain integrity for model artifacts. Training data supply chain verification is covered by TG-01. License obligations identified in the mSBOM are governed by LI-08. Runtime integrity monitoring (detecting post-deployment artifact changes) is a cross-domain concern addressed in collaboration with securitycontrols.ai.", "capability_risk": { "capability_level": "low", "access_mode": "api", "autonomy": "supervised", "external_reach": false, "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "tiers": [ "generative-ai", "hosted-api", "frontier-capability" ], "implementers": [ "ML Engineering", "Platform Engineering", "Security Engineering" ], "frameworks": [ { "framework": "llm10", "requirement_id": "LLM03:2025", "fit": "direct", "direction": "control-supports-requirement", "rationale": "OWASP LLM03:2025 addresses supply chain risks in LLM deployments including compromised model artifacts, tampered weights, and untrusted third-party components. LI-03 directly implements supply chain integrity controls for model artifacts via cryptographic verification and mSBOM generation.", "source_locator": { "section": "LLM03" }, "source_version": "2025", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "initial", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "nist_rmf", "requirement_id": "GOVERN-6.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-6.1 (GOVERN function) provides that policies address AI risks associated with third-party entities, including IP-infringement risks. LI-03 provides the technical verification mechanism — signed checksums and a model SBOM — that makes third-party model risk policies enforceable.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "initial", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.10.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.10.3 (Suppliers) requires processes to manage risks from suppliers of AI system components. LI-03’s checksum verification and model SBOM give third-party model intake a verifiable integrity control.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "initial", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0010", "fit": "partial", "direction": "control-supports-requirement", "rationale": "MITRE ATLAS AML.T0018 (Manipulate AI Model) includes the supply chain vector where an adversary compromises a model artifact in transit or at the source repository. LI-03's cryptographic verification gates reduce this attack surface by ensuring that any artifact substitution that alters the hash is detected before registration. Backdoors introduced before the publisher's signing step are not mitigated by LI-03.", "uncovered_portion": "AML.T0018 includes backdoor injection at training time or by a malicious publisher — LI-03 only detects post-signing substitution, not a backdoor embedded by the original publisher.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "initial", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "correction": "ai-exchange-verify 2026-07-08", "relation": "defends_against" }, { "framework": "owasp_aitg", "requirement_id": "AITG-INF-01", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AITG-INF-01 (Testing for Supply Chain Tampering) covers tampering with third-party model artifacts in transit or at the source. LI-03's publisher-signed checksum verification and model SBOM (mSBOM) directly address the exposure this test probes.", "source_locator": { "test_id": "AITG-INF-01", "test_name": "Testing for Supply Chain Tampering" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ml_top10", "requirement_id": "ML06:2023", "fit": "supporting", "rationale": "OWASP ML06:2023 AI Supply Chain Attacks maps to this control's third-party model verification requirement.", "normative_force": "industry-framework", "source_version": "2023", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against" }, { "framework": "owasp_ai_exchange", "requirement_id": "supplychainmanage", "fit": "direct", "rationale": "Verifying a third-party model against a publisher-signed digest and generating an mSBOM is exactly AI Exchange's manage-the-AI-supply-chain (models/components) control.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0023", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every third-party model artifact must be verified against a publisher-signed SHA-256…\" enacts ATLAS mitigation AML.M0023 AI Bill of Materials; complements the control’s existing technique mapping AML.T0010 (defends_against) — OpenCRE crosswalks the AI Exchange concept (supplychainmanage) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0014", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every third-party model artifact must be verified against a publisher-signed SHA-256…\" enacts ATLAS mitigation AML.M0014 Verify AI Artifacts; complements the control’s existing technique mapping AML.T0010 (defends_against) — OpenCRE crosswalks the AI Exchange concept (supplychainmanage) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.05", "fit": "supporting", "rationale": "Control \"Every third-party model artifact must be verified against a publisher-signed SHA-256…\" defends against NIST AI 100-2 attack class NISTAML.05 \"Supply Chain Attacks\"; OpenCRE crosswalks this control’s OWASP AI Exchange concept (supplychainmanage) to this NIST class. (Anchor captures the attack taxonomy, so we cite the threat class as defends_against, not the NIST mitigation named by OpenCRE.)", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against", "mapping_confidence": "medium", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "A model artifact that cannot be cryptographically verified against its publisher's signed manifest is an uncontrolled dependency. mSBOM generation for AI models mirrors the software SBOM practice mandated for critical software supply chains — the AI field is behind the software field on this control, and that gap is being actively exploited.", "meta": { "authored_on": "2026-06-26", "schema_version": "1.0.0" }, "canonical_id": "apeiris://model/controls/LI-03", "validation_objective": "Every third-party model artifact must be verified against a publisher-signed SHA-256 digest obtained from an authoritative source that is distinct from the artifact download location before registration, and any artifact failing verification must be quarantined and blocked; a model SBOM (mSBOM) enumerating all artifact components with individual hashes, SPDX license identifiers, and provenance metadata must be generated and stored as an immutable attachment to the registry entry.", "evidence_required": [ "supply_chain_verification_record documenting the publisher-signed checksum retrieval URL (distinct from artifact download location), the comparison result, the verifier identity, and the verification timestamp for each acquired third-party artifact", "model_msbom with individual per-component entries for each weights shard, tokenizer file, and configuration file including SHA-256 hash, SPDX license identifier, declared provenance, and the verification method used", "pipeline_quarantine_log showing detection and quarantine of an artifact with a hash mismatch or absent publisher signature (from test injection or a real event)", "model_registry_entry with an immutable mSBOM attachment link, mSBOM creation timestamp, and reference to the corresponding supply_chain_verification_record" ], "machine_tests": [ "Corrupt a single byte in a model weight shard file and submit the artifact to the registration pipeline → assert the pipeline detects the hash mismatch, quarantines the artifact, and generates a logged rejection event", "Attempt to onboard a third-party artifact providing a checksum sourced from the same mirror URL used to download the artifact rather than the publisher's authoritative source → assert the pipeline flags or rejects the non-authoritative checksum provenance", "Query the registry for a registered third-party model → assert the registry entry includes an immutable mSBOM attachment with per-component SHA-256 hashes and SPDX license identifiers for all enumerated components" ], "human_review": [ "Review the mSBOM generation procedure to confirm it enumerates and hashes all artifact components individually (each weights shard, tokenizer file, and configuration file) rather than producing only a single artifact-level hash", "Assess whether the mSBOM scope limitation documentation for API-hosted models where weights are inaccessible accurately describes the verification gap and provides behavioral regression test results as substituted verification evidence", "Verify that the model onboarding runbook makes mSBOM generation a mandatory non-bypassable step and that no pipeline configuration flag or environment variable can be used to skip it" ], "blocking_effect": "blocks-deployment", "normative_status": "industry-framework", "anti_patterns": [ "Verifying only the compressed archive hash (e.g., the .zip or .tar.gz download file) without verifying the extracted artifact components individually, allowing a crafted archive to pass the outer checksum while containing a substituted model weight file", "Sourcing the verification checksum from the same CDN, mirror, or repository used to download the artifact, allowing a compromised repository to publish a matching hash for a tampered artifact and defeat the integrity check", "Skipping mSBOM generation for models from major providers on the assumption that well-known model hubs do not carry supply chain risk, creating an unmonitored gap that adversaries can exploit via hub account compromise or CDN substitution", "Making mSBOM generation an optional pipeline step configurable via an environment variable or feature flag, enabling it to be bypassed under deployment time pressure or during automated emergency rollouts" ], "update_status": "current", "layer_code": "LI" }, { "id": "LI-04", "layer": "LI", "plane": "control", "name": "Structured Model Documentation — Complete Model Card with All Required Sections", "plain": "Each model has a standardized documentation record covering its purpose, performance, limitations, training data, and ethical considerations so that users can make informed decisions about whether and how to use it.", "threat": { "tags": [ "governance-gap", "accountability-gap", "regulatory-noncompliance" ], "desc": "Without structured documentation, model users — including downstream deployers, regulators, and affected parties — cannot determine the model's intended use, known limitations, demographic performance disparities, or out-of-scope uses. This information asymmetry enables misapplication: deploying a model in contexts it was not designed or evaluated for, or using it with populations underrepresented in training evaluation. Incomplete documentation also prevents regulators from performing mandatory conformity assessments (EU AI Act Art-11) and blocks effective independent validation (SR 26-2 S-3). The absence of documented limitations is not a gap in paper compliance — it is a precondition for harm." }, "standard": [ { "id": "eu_ai_act", "section": "Art-11", "title": "Technical documentation for high-risk AI systems" }, { "id": "nist_rmf", "section": "GOVERN-4.2", "title": "Documentation of AI system risks and impacts" }, { "id": "iso_42001", "section": "A.6.2.3", "title": "Documentation of AI system design and development" }, { "id": "sr262", "section": "Sec. IV", "title": "Model development and model use — development documentation" } ], "sources": [ { "id": "mitchell_2019", "title": "Model Cards for Model Reporting", "authority": "Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I. D., and Gebru, T.", "source_type": "academic-research", "normative_force": "best-practice", "version": "2019", "published_on": "2019-01-01", "retrieved_on": "2026-06-26", "canonical_url": "https://arxiv.org/abs/1810.03993", "license": "CC BY 4.0", "status": "current", "flagship": true, "source_id": "mitchell_2019", "relationship": "informative_reference", "rationale": "Establishes Model Cards for Model Reporting requirements informing the apeiris://model/controls/LI-04 Structured Model Documentation — Complete Model Card with All Required Sections control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "authority": "European Union — European Parliament and Council", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-26", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689", "license": "EU-public-sector-information", "status": "current", "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/LI-04 Structured Model Documentation — Complete Model Card with All Required Sections control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/LI-04 Structured Model Documentation — Complete Model Card with All Required Sections control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "title": "SR 26-2: Revised Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "canonical_url": "https://www.federalreserve.gov/supervisionreg/srletters/sr2602.htm", "license": "us-government-public-domain", "supersedes": "SR 11-7, SR 21-8", "status": "current", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/LI-04 Structured Model Documentation — Complete Model Card with All Required Sections control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "source_type": "voluntary-standard", "retrieved_on": "2026-06-26", "normative_force": "voluntary-standard", "version": "unknown", "status": "current", "authority": "ISO/IEC JTC 1/SC 42", "license": "proprietary-paid", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/LI-04 Structured Model Documentation — Complete Model Card with All Required Sections control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Require a complete model card — conforming to all 9 sections of the Mitchell et al. 2019 framework and supplemented for regulatory jurisdiction — as a mandatory gate before model registration; enforce section completeness programmatically and version-lock the model card to the artifact hash.", "steps": [ "Adopt the Mitchell et al. 2019 model card structure as the organizational baseline requiring all 9 sections: (1) Model Details, (2) Intended Use, (3) Factors, (4) Metrics, (5) Evaluation Data, (6) Training Data, (7) Quantitative Analyses, (8) Ethical Considerations, (9) Caveats and Recommendations. For EU AI Act high-risk systems, supplement with Annex IV fields (design specifications, training methodology, risk management system reference, monitoring procedures).", "Implement schema-based completeness validation: each of the 9 sections must be non-empty and must pass field-level validation (e.g., Metrics section must name at least one metric with a value and a reference evaluation dataset; Intended Use must name at least one out-of-scope use). Reject model registration when any required section is absent or empty.", "Version-lock the model card to the artifact hash: the model card is a registry artifact with its own hash stored alongside the model artifact hash. Any update to the model card generates a new version; the current card version is always derivable from the artifact hash.", "For provider-hosted models where training data details are unavailable, document the limitation explicitly in sections (6) and (9) rather than leaving them blank — an honest acknowledgment of limited information is preferable to a false impression of completeness." ], "anti_patterns": [ "Publishing a model card that contains all 9 section headers but leaves sections (7) Quantitative Analyses and (8) Ethical Considerations as placeholder text — section presence without substantive content does not satisfy the control.", "Treating the model card as a static document created at initial release and never updated — the card must be versioned alongside the model and updated when performance characteristics, intended use, or known limitations change.", "Conflating the model card with marketing copy — model cards must disclose limitations and out-of-scope uses with the same prominence as capabilities." ] }, "validation": { "design_check": [ "Confirm the model card schema enforces the presence and non-emptiness of all 9 Mitchell et al. sections with field-level validation rules, and that registration is blocked when validation fails [ref:mitchell_2019].", "Verify the model card versioning mechanism: confirm that each model card version is linked to a specific artifact hash and that the registry exposes the current card version for any given artifact hash [ref:iso_42001_2023].", "For EU AI Act in-scope deployments, confirm that the model card schema includes Annex IV supplemental fields and that these fields are populated for high-risk classified systems [ref:eu_ai_act_2024]." ], "runtime_test": [ "Attempt to register a model with a card that is missing section (7) Quantitative Analyses or section (8) Ethical Considerations; confirm the pipeline blocks registration and identifies the specific missing section [ref:mitchell_2019].", "Update a production model's performance characteristics and verify that the model card version is incremented and linked to the same artifact hash — confirm the prior card version is retained in the registry [ref:sr262_2026].", "Retrieve the model card for a deployed model and independently assess section completeness using the Mitchell et al. criteria; flag any sections found to be substantively empty or placeholder text [ref:mitchell_2019]." ], "evidence": [ "model:model-card — versioned, schema-validated model card with all 9 Mitchell et al. sections substantively populated, linked to artifact hash [unverified]", "model:card-completeness-validation-report — programmatic completeness validation result showing pass/fail per section and validation timestamp [unverified]", "model:registry-entry — LI-01 registry entry with linked current model card version hash [unverified]" ] }, "lenses": { "engineering": { "summary": "Engineering owns the model card schema and the completeness validation gate. The card must be a machine-validated registry artifact, not a documentation add-on. Incomplete cards must block model registration — not generate warnings.", "actions": [ "Implement a JSON Schema for the model card covering all 9 Mitchell et al. sections with field-level validation rules", "Integrate model card validation as a blocking gate in the model registration pipeline", "Maintain a model card versioning API that links each card version to its corresponding artifact hash" ], "tools": [ "Hugging Face Model Card metadata format", "Google Model Card Toolkit", "custom JSON Schema with AJV or similar validator", "MLflow model registry card attachment API" ], "failure_signals": [ "Model card exists as a free-text README with no schema validation", "Registration pipeline accepts empty section placeholders without blocking", "Model card not linked to artifact hash — can diverge from deployed model" ] }, "evaluation": { "summary": "The model card is the primary reference document for evaluation planning: the Metrics section tells evaluators what the model developers measured; the Factors section identifies population subgroups that require disaggregated evaluation; the Evaluation Data section enables reproducibility checks.", "actions": [ "Review sections (4) Metrics, (5) Evaluation Data, and (7) Quantitative Analyses before designing the evaluation scope to identify gaps in developer-reported evaluation coverage", "Validate that Quantitative Analyses includes disaggregated performance results for the population factors listed in section (3)", "Flag any evaluation plan that accepts developer-reported results without independent verification of at least one benchmark" ], "failure_signals": [ "Quantitative Analyses section lists aggregate metrics only with no disaggregation by population factor", "Evaluation Data section does not name the specific dataset and version used for reported metrics" ] }, "red_team": { "summary": "The model card's Intended Use and Caveats sections are red-team intelligence: stated out-of-scope uses identify the boundaries the model was not tested against and therefore the highest-value targets for adversarial testing.", "actions": [ "Review the Intended Use (section 2) and Caveats (section 9) sections before designing a red-team test plan — out-of-scope uses listed by the developer are first-priority targets", "Verify that the Ethical Considerations section (8) identifies failure modes that red-team testing should attempt to elicit", "Test whether deployers have extended the model beyond its stated Intended Use and document gaps between stated and actual use" ], "failure_signals": [ "Ethical Considerations section is generic boilerplate — no model-specific failure modes identified", "Caveats section does not list any out-of-scope uses despite the model being a fine-tuned or specialized system" ] }, "grc": { "summary": "The model card is the primary regulatory evidence artifact: EU AI Act Art-11 requires technical documentation that substantially overlaps with model card content. SR 26-2 validation requires model purpose, assumptions, and limitations to be documented. A complete, versioned model card is not a best practice for these frameworks — it is a baseline expectation.", "actions": [ "Confirm that the model card completeness standard meets Art-11 and Annex IV requirements for all EU AI Act in-scope deployments", "Verify model cards are retained for the full regulatory retention period — EU AI Act requires post-market retention; SR 26-2 expects records supporting the full model lifecycle", "Include model card version references in all regulatory disclosures and model risk management documentation" ], "metrics": [ "Percentage of registered models with a complete, validated model card (target: 100% for all production models)", "Number of production models with model cards rated incomplete by the schema validator" ], "failure_signals": [ "Any production model lacks a current, schema-valid model card", "Regulatory submission references model documentation that cannot be retrieved from the registry" ] }, "mlops": { "summary": "MLOps must maintain model card currency across the production lifecycle: when monitoring reveals performance changes, model card section (7) must be updated; when operational limitations are discovered, section (9) must reflect them.", "actions": [ "Trigger a model card review process when production monitoring detects material performance changes", "Integrate model card update into the material-change authorization workflow (LI-09) — a model update that changes stated capabilities or limitations requires a new card version", "Ensure model card section (6) Training Data is updated when the model is retrained with new data" ], "failure_signals": [ "Production monitoring reveals performance gaps not reflected in the current model card", "Model retrained with updated data but model card training data section not updated" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Many organizations publish partial model cards or treat them as optional documentation. Achieving 'defined' requires all 9 sections to be schema-validated and the model card to be a registry-linked, version-controlled artifact that gates model registration." }, "coverage_note": "LI-04 covers structured model documentation at the artifact level. Use-case-level impact assessment (required by EU AI Act Art-9 and ISO 42005) is covered in EV-09. Human oversight documentation (Art-14) is covered in OA-02. Post-deployment monitoring documentation (Art-12) is covered in BH-05. LI-04 does not require the model card to be publicly disclosed — only that it exists, is complete, and is accessible to authorized parties including regulators and independent validators.", "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "provision": "Art-11", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "mapping_fit": "direct", "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "notes": "Art-11 requires providers of high-risk AI systems to draw up and maintain technical documentation before placing the system on the market. Annex IV specifies the minimum content of technical documentation, which substantially overlaps with the Mitchell et al. 9-section model card. Effective date is Dec 2, 2027 for standalone Annex III systems (Parliament-approved; Council adoption pending as of 2026-06-26). Product-embedded systems: Aug 2, 2028.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "capability_risk": { "capability_level": "low", "access_mode": "api", "autonomy": "supervised", "external_reach": false, "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "moderate" }, "tiers": [ "general-predictive-ml", "generative-ai", "high-impact-decision", "us-regulated-banking", "eu-high-risk", "frontier-capability" ], "implementers": [ "ML Engineering", "Model Governance", "Compliance" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-4.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-4.2 (GOVERN function) provides that organizational teams document the risks and potential impacts of the AI technology they develop and deploy. A mandatory, schema-validated model card is the primary artifact in which a team documents its model’s risks, limitations, and impacts, directly supporting this documentation practice.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-11", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EU AI Act Art-11 requires providers of high-risk AI systems to prepare and maintain technical documentation before market placement. The Mitchell et al. 9-section model card supplemented with Annex IV fields directly satisfies Art-11's technical documentation requirement. This control supports satisfaction of Art-11 for covered deployments; applicability depends on the deployer's role (provider vs. deployer) and the system's high-risk classification.", "source_locator": { "section": "Chapter III", "clause": "Article 11" }, "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. IV", "fit": "direct", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. IV (Model Development and Model Use) describes documentation of model purpose, design, assumptions, limitations, and performance as part of sound development practice. The Mitchell et al. model card structure organizes exactly this development documentation into a versioned, schema-validated artifact. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "source_locator": { "section": "Sec. IV (Model Development and Model Use)" }, "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.3 (Documentation of AI system design and development) requires documented design and development information. A complete, versioned model card linked to each release satisfies that documentation requirement for models.", "source_locator": { "section": "Annex A", "clause": "A.6.2.3" }, "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0044", "fit": "adjacent", "direction": "tangential", "rationale": "MITRE ATLAS AML.T0044 (Full AI Model Access) is tangentially related to model documentation in that documented model characteristics reduce information asymmetry that adversaries exploit when probing system behavior. However, model card documentation is primarily a governance and transparency control, not a direct mitigation for ATLAS techniques. The adjacency is noted but no direct technique mapping applies.", "source_version": "v2026.06", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "low", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "owasp_ai_exchange", "requirement_id": "aitransparency", "fit": "partial", "rationale": "A complete model card documenting purpose, performance, limitations, and training data supplies the transparency about AI behavior that the AI-transparency control requires.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "directive", "matrix_thesis": "Undocumented limitations are not omissions — they are active risks. Every model deployed without a complete model card is a model whose failure modes are invisible to the people who most need to understand them: downstream deployers, affected parties, independent validators, and regulators. The 9-section model card is not a compliance checkbox; it is the minimum documentation surface that makes responsible deployment possible.", "meta": { "authored_on": "2026-06-26", "schema_version": "1.0.0" }, "canonical_id": "apeiris://model/controls/LI-04", "validation_objective": "Every model submitted for registration must have a schema-validated model card with all nine Mitchell et al. 2019 sections substantively populated and passing field-level validation rules; the model card must be version-locked to the artifact hash and returned as structured metadata from the registry API; and registration must be blocked when any required section is absent, empty, or contains only placeholder text.", "evidence_required": [ "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections" ], "machine_tests": [ "Submit a model registration request with section 7 (Quantitative Analyses) absent from the model card → assert the pipeline blocks registration and returns an error identifying section 7 as missing", "Submit a model card with section 8 (Ethical Considerations) containing only the text 'TBD' or 'N/A' → assert the schema validator rejects the submission as substantively empty and blocks registration", "Update a production model's stated performance characteristics and submit without creating a new model card version linked to the updated artifact hash → assert the registry API returns the prior card version and flags the card-artifact linkage as stale" ], "human_review": [ "Manually assess the Quantitative Analyses section (section 7) of a production model card to confirm it contains actual performance metrics with numeric values, reference evaluation dataset identifiers, and disaggregated results by population factors listed in section 3", "Review the Ethical Considerations section (section 8) to confirm it identifies at least one model-specific failure mode with associated conditions rather than generic boilerplate applicable to any AI system", "Verify that the Caveats and Recommendations section (section 9) lists at least one explicitly stated out-of-scope use with rationale and that the disclosure is presented with equivalent prominence to the stated capabilities in section 2" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Publishing a model card with all nine section headers present but sections 7 (Quantitative Analyses) and 8 (Ethical Considerations) containing only phrases such as 'See evaluation report' or 'N/A' without embedded substantive content", "Treating the model card as a static artifact authored at initial model release and never updating it when production monitoring reveals performance changes, new limitations are discovered, or the intended use scope is revised", "Conflating the model card with marketing material by emphasizing stated capabilities in prominent sections while burying limitation disclosures, demographic performance disparities, and out-of-scope uses in less-visible sections", "Storing the model card as a free-text README or Wiki page not cryptographically linked to the artifact hash, allowing the card and the deployed model artifact to diverge silently across successive deployments", "Accepting section validation as passing when a section contains a single sentence referencing an external report rather than requiring substantive content to be embedded within the card itself" ], "update_status": "current", "layer_code": "LI" }, { "id": "LI-05", "layer": "LI", "plane": "control", "name": "Training Data Lineage Pointer — Link from Model Registry to TG-Layer Dataset...", "plain": "Each registered model includes a reference to the official dataset record that documents what training data was used, so that data governance and model governance are connected rather than siloed.", "threat": { "tags": [ "governance-gap", "accountability-gap", "supply-chain-compromise" ], "desc": "When model artifacts and training data records are managed as separate silos without explicit linkage, it becomes impossible to determine whether a model was trained on data that meets current governance standards — for example, whether training data has since been flagged for quality issues, consent withdrawal, or contamination. This disconnect enables training data poisoning (AML.T0020) or data quality failures to remain undiscovered because there is no path from a deployed model to the data that produced it. SR 26-2 independent validation requires validators to assess training data inputs; without a pointer to the authoritative dataset record, validation is incomplete." }, "standard": [ { "id": "nist_rmf", "section": "MAP-2.3", "title": "Scientific integrity and TEVV documentation (data selection)" }, { "id": "iso_42001", "section": "A.6.2.3", "title": "Documentation of AI system design and development" }, { "id": "aisvs", "section": "C1.1", "title": "Training data — origin inventory and data security" } ], "sources": [ { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/LI-05 Training Data Lineage Pointer — Link from Model Registry to TG-Layer Dataset... control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary-paid", "status": "current", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/LI-05 Training Data Lineage Pointer — Link from Model Registry to TG-Layer Dataset... control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_aisvs_v1", "title": "OWASP AI Security Verification Standard v1.0", "authority": "Open Worldwide Application Security Project (OWASP)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2026-06-24", "retrieved_on": "2026-06-26", "canonical_url": "https://github.com/OWASP/AISVS", "license": "CC BY-SA 4.0", "status": "current", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "url": "https://github.com/OWASP/AISVS", "source_id": "owasp_aisvs_v1", "relationship": "implementation_pattern", "rationale": "Establishes OWASP AI Security Verification Standard v1.0 requirements informing the apeiris://model/controls/LI-05 Training Data Lineage Pointer — Link from Model Registry to TG-Layer Dataset... control.", "reviewed_on": "2026-07-01" }, { "id": "biml_llm_ara", "title": "BIML — Architectural Risk Analysis of LLMs (2024)", "authority": "Berryville Institute of Machine Learning", "source_type": "research-institute", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-24", "retrieved_on": "2026-07-08", "canonical_url": "https://berryvilleiml.com/docs/BIML-LLM24.pdf", "relationship": "supporting_guidance", "note": "BIML 'data debt' / 'poison in the data' motivate training-data lineage tracking." } ], "implementation": { "pattern": "At model registration, require one or more TG-layer dataset record IDs as mandatory foreign-key references in the model registry entry; validate that each referenced dataset record exists and is current; reject registration if any reference is invalid or if the dataset record has been flagged for disqualifying issues.", "steps": [ "Define a structured training-data reference field in the model registry schema that accepts one or more TG-layer dataset record IDs (covering pre-training corpus, fine-tuning dataset, RLHF preference dataset separately if applicable). The field is mandatory and must be non-empty for all non-API-hosted models.", "At registration time, resolve each dataset record reference and validate: the record exists, its status is not flagged as disqualified or recalled, and the dataset version matches the version used during training. Reject registration if any reference is invalid.", "For third-party hosted models where training data details are unknown, document the limitation explicitly: record the provider, provider-stated training data description, and the knowledge gap — do not leave the field empty or omit it.", "When a TG-layer dataset record is subsequently flagged for contamination, consent withdrawal, or data quality failure, trigger an automated alert to all model registry entries that reference that dataset record to initiate impact assessment." ], "anti_patterns": [ "Recording training data as a free-text description in the model card (LI-04 section 6) without a machine-resolvable pointer to the authoritative TG-layer record — free text cannot be queried when a dataset is recalled.", "Using a dataset name or filename as the reference rather than a stable dataset record ID — names and filenames are not unique across versions and can refer to different dataset contents.", "Omitting fine-tuning dataset references and recording only the pre-training corpus — incomplete references mislead independent validators about the full data inputs." ] }, "validation": { "design_check": [ "Confirm that the model registry schema includes a structured training-data reference field that accepts TG-layer record IDs and that the field is mandatory and validated at registration [ref:sr262_2026].", "Verify that the model registry enforces referential integrity: a model cannot be registered with a dataset reference that does not resolve to a valid, non-flagged TG-layer record [ref:iso_42001_2023].", "Review the dataset recall alert mechanism: confirm that when a TG-layer dataset record status changes to flagged or recalled, all model registry entries referencing that record receive an automated impact alert [ref:nist_ai_rmf_1_0]." ], "runtime_test": [ "Attempt to register a model with a dataset reference pointing to a non-existent TG-layer record ID; confirm the pipeline blocks registration [ref:sr262_2026].", "Manually flag a TG-layer dataset record as recalled and verify that an automated alert is generated to all model registry entries referencing that dataset within the defined SLA [ref:nist_ai_rmf_1_0].", "For a production model, trace the training-data pointer to the TG-layer record and verify the record is accessible to the independent validation team without escalation [ref:owasp_aisvs_v1]." ], "evidence": [ "model:registry-entry — model registry entry with one or more TG-layer dataset record ID references, validated at registration time [unverified]", "model:dataset-reference-validation-log — automated validation log confirming each dataset reference resolved to a valid, non-flagged record at registration [unverified]", "model:dataset-recall-alert-record — evidence that dataset recall alerting is operational, showing an alert sent to affected model registry entries for a test or real recall event [unverified]" ] }, "lenses": { "engineering": { "summary": "The training-data pointer is a foreign-key constraint between the model registry and the TG-layer dataset catalog. Engineering must implement it as a schema-level constraint with referential integrity enforcement — not as a documentation convention.", "actions": [ "Implement the training-data reference field as a foreign key with registry-level referential integrity validation", "Build the dataset recall alert notification mechanism to query model registry references when a dataset record status changes", "Extend the model registration API to accept and validate one or more TG-layer record IDs for each training phase (pre-training, fine-tuning, RLHF)" ], "tools": [ "Model registry with foreign-key support", "TG-layer dataset catalog with webhook or event-based status change notifications", "Apache Atlas or similar data governance catalog" ], "failure_signals": [ "Training data is documented only as free text in the model card — no machine-resolvable reference", "Model registry has no connection to the TG-layer dataset catalog", "No alerting mechanism when a training dataset is retroactively flagged" ] }, "evaluation": { "summary": "Independent validation (SR 26-2 S-3) requires access to training data inputs. The training-data pointer enables validators to retrieve the authoritative dataset record without relying on developer-provided summaries.", "actions": [ "Use the training-data pointer to retrieve the TG-layer record during independent validation scoping", "Verify that the dataset record referenced matches the training data described in the model card (LI-04 section 6)", "Flag any model where the training-data pointer is absent, invalid, or acknowledges unknown provenance as having incomplete validation coverage" ], "failure_signals": [ "Independent validation report cannot trace training data inputs to an authoritative record", "Training data described in model card does not match the TG-layer record referenced in the registry" ] }, "red_team": { "summary": "The training-data pointer enables red teams to assess training data attack surface: knowing the specific dataset version and source, red teams can research known contamination, biases, or adversarial examples in that dataset that may have influenced model behavior.", "actions": [ "Retrieve the training-data pointer and TG-layer record before red-team scoping to identify known dataset quality issues or contamination events", "Test whether the model exhibits behaviors consistent with identified dataset artifacts or known contamination in the referenced training data" ], "failure_signals": [ "Red-team report cannot identify training data source — scope is artificially limited", "Known contamination events in training datasets are not surfaced to red teams because pointer linkage is absent" ] }, "grc": { "summary": "SR 26-2 requires model validators to assess training data inputs. The training-data pointer is the mechanism that makes this assessment possible without organizational barriers. For EU AI Act in-scope systems, Art-10 data governance requirements apply to the training data — the pointer creates the audit linkage between model documentation and data governance records.", "actions": [ "Confirm that all models subject to SR 26-2 independent validation have valid training-data pointers accessible to the validation team", "Verify that EU AI Act in-scope systems have training-data pointers linking to TG-layer records that satisfy Art-10 data governance documentation", "Establish a process to review all model registry entries whose training-data pointers reference datasets that have been flagged or recalled since the model was deployed" ], "failure_signals": [ "SR 26-2 validation team cannot access training data record — pointer absent or access denied", "No documented process for responding to training dataset recalls affecting production models" ] }, "mlops": { "summary": "MLOps teams use the training-data pointer to scope retraining: understanding the current training dataset version enables a determination of whether a proposed dataset update constitutes a material change (LI-09) requiring a new authorization cycle.", "actions": [ "Reference the training-data pointer when evaluating whether a dataset update triggers a material-change determination under LI-09", "Update the training-data pointer when a model is retrained on a new dataset version and confirm the new pointer resolves to a valid TG-layer record" ], "failure_signals": [ "Model retrained on updated data but registry training-data pointer still references the prior dataset version", "MLOps team cannot determine whether proposed dataset changes are material without manual investigation" ] } }, "maturity": { "current": "none", "target": "defined", "notes": "Most organizations maintain model registries and dataset catalogs as separate, unconnected systems. Achieving 'defined' requires a schema-level foreign key from the model registry to the dataset catalog with automated referential integrity enforcement." }, "coverage_note": "LI-05 requires only a pointer — a machine-resolvable reference — to the TG-layer dataset record. It does not require the training data itself to be present in the model registry or to be reproduced here. The substantive content of training data governance (quality, consent, bias screening, contamination detection) is owned by the TG layer. LI-05 is the linkage control that ensures model governance and data governance are connected.", "capability_risk": { "capability_level": "low", "access_mode": "api", "autonomy": "supervised", "external_reach": false, "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "tiers": [ "us-regulated-banking", "frontier-capability" ], "implementers": [ "ML Engineering", "Data Engineering", "MLOps" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MAP-2.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MAP-2.3 (MAP function) provides that scientific integrity and TEVV considerations, including data collection and selection, are identified and documented. LI-05’s registry-to-dataset lineage pointer documents which data was selected for training, anchoring the data-collection documentation this subcategory requires.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.3 (Documentation of AI system design and development) covers development documentation, which includes the data used. LI-05’s registry-to-dataset lineage pointer makes the training-data component of that documentation machine-resolvable.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0020", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "MITRE ATLAS AML.T0020 (Poison Training Data) is adjacently relevant: the training-data pointer enables impact scoping when a dataset is found to have been poisoned — all models trained on the contaminated dataset can be identified quickly. LI-05 is a scoping and traceability control, not a poisoning prevention control. Prevention is owned by TG-04.", "source_version": "v2026.06", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "low", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "owasp_ai_exchange", "requirement_id": "supplychainmanage", "fit": "supporting", "rationale": "Linking each model to its training-dataset record extends supply-chain management to the data provenance the control names.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0023", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every model registry entry must contain one or more validated machine-resolvable…\" enacts ATLAS mitigation AML.M0023 AI Bill of Materials; complements the control’s existing technique mapping AML.T0020 (defends_against) — OpenCRE crosswalks the AI Exchange concept (supplychainmanage) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0014", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every model registry entry must contain one or more validated machine-resolvable…\" enacts ATLAS mitigation AML.M0014 Verify AI Artifacts; complements the control’s existing technique mapping AML.T0020 (defends_against) — OpenCRE crosswalks the AI Exchange concept (supplychainmanage) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.05", "fit": "supporting", "rationale": "Control \"Every model registry entry must contain one or more validated machine-resolvable…\" defends against NIST AI 100-2 attack class NISTAML.05 \"Supply Chain Attacks\"; OpenCRE crosswalks this control’s OWASP AI Exchange concept (supplychainmanage) to this NIST class. (Anchor captures the attack taxonomy, so we cite the threat class as defends_against, not the NIST mitigation named by OpenCRE.)", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against", "mapping_confidence": "medium", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "readiness": "approved", "thesis_type": "directive", "matrix_thesis": "Model governance and data governance are typically implemented as separate organizational silos with no machine-readable linkage between them. When a training dataset is recalled, contaminated, or found to violate consent obligations, an organization without training-data pointers cannot determine which deployed models are affected without manual investigation. LI-05 is the minimal linkage control that makes cross-silo impact scoping possible.", "meta": { "authored_on": "2026-06-26", "schema_version": "1.0.0" }, "canonical_id": "apeiris://model/controls/LI-05", "validation_objective": "Every model registry entry must contain one or more validated machine-resolvable references to TG-layer dataset records covering each applicable training phase (pre-training corpus, fine-tuning dataset, and RLHF preference data where applicable); the registry must enforce referential integrity by blocking registration when any referenced dataset record ID is invalid or carries a disqualified status; and an automated alerting mechanism must notify all affected model registry entries within the defined SLA when a referenced TG-layer dataset record is recalled or flagged.", "evidence_required": [ "model_registry_entry containing a structured training_data_references[] field with at least one TG-layer dataset record ID per applicable training phase, validated at registration time and stored as immutable foreign-key references", "dataset_reference_validation_log confirming that each referenced dataset record ID resolved to a valid, non-flagged TG-layer record at registration time, with resolution timestamp and referenced record status", "dataset_recall_alert_record demonstrating that an automated notification was dispatched to all model registry entries referencing a recalled or flagged dataset record within the defined SLA", "independent_validation_access_record showing that the validation team successfully retrieved the TG-layer records referenced by a production model registry entry without requiring escalation or special access" ], "machine_tests": [ "Submit a model registration request with a training_data_reference pointing to a non-existent TG-layer record ID → assert the registry rejects the submission with a referential integrity error identifying the invalid reference", "Set a TG-layer dataset record status to 'recalled' and observe the automated alerting system → assert alert notifications are dispatched to all model registry entries referencing that dataset within the defined SLA window", "Submit a model registration request with the training_data_references field empty or absent → assert the registry rejects the submission with an error requiring at least one training data reference" ], "human_review": [ "Retrieve the TG-layer dataset record referenced in at least one production model registry entry and compare its content against the training data described in the model card section 6, confirming the two records are consistent", "Assess whether the training_data_references field covers all applicable training phases (pre-training corpus, fine-tuning dataset, and RLHF preference data separately where applicable) or whether only the primary dataset phase is referenced while fine-tuning inputs are omitted", "Review the recall alerting mechanism by examining alert delivery timestamps in a test or real recall event record to confirm the SLA is being met in practice" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Recording training data provenance as a free-text description in model card section 6 without a machine-resolvable pointer to the authoritative TG-layer record, making automated downstream impact scoping impossible when a training dataset is recalled", "Using a dataset filename or display name as the training data reference rather than a stable TG-layer record ID, creating ambiguity and broken references when dataset versions are renamed or when multiple datasets share a similar name", "Referencing only the pre-training corpus and omitting fine-tuning dataset and RLHF preference data references, misleading independent validators and regulators about the complete set of training data inputs", "Operating model registries and TG-layer dataset catalogs as disconnected systems with no cross-system referential integrity enforcement, relying on manual coordination to maintain accurate training data linkage" ], "update_status": "current", "layer_code": "LI" }, { "id": "LI-06", "layer": "LI", "plane": "control", "name": "Immutable Version Control with Tested Rollback and Emergency Disable", "plain": "No deployed model can be silently overwritten; every version change is recorded, rollback to any prior approved version is tested and ready, and emergency disable of a model is operable independently of normal deployment tooling.", "threat": { "tags": [ "undisclosed-model-change", "missing-rollback", "unauthorized-deployment", "supply-chain-compromise" ], "desc": "Silent model overwrites — where a production endpoint serves a different artifact than what was approved — are a recurring failure mode in ML operations, occurring both through adversarial substitution (AML.T0044 — Full AI Model Access) and through accidental CI/CD pipeline errors. Without immutable versioning, a deployment pipeline bug or unauthorized actor can replace a validated model with an untested or malicious one with no audit trail. Separately, many organizations discover during incidents that their rollback procedure has never been tested or that their emergency disable capability is entangled with the same CI/CD tooling that may be compromised — making recovery dependent on the compromised path." }, "standard": [ { "id": "nist_rmf", "section": "MANAGE-2.4", "title": "Mechanisms to supersede, disengage, or deactivate AI systems" }, { "id": "iso_42001", "section": "6.3", "title": "Planning of changes" }, { "id": "eu_ai_act", "section": "Art-12", "title": "Record-keeping for high-risk AI systems" }, { "id": "aisvs", "section": "C3.3", "title": "Model lifecycle — controlled deployment & rollback" } ], "sources": [ { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/LI-06 Immutable Version Control with Tested Rollback and Emergency Disable control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary-paid", "status": "current", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/LI-06 Immutable Version Control with Tested Rollback and Emergency Disable control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "authority": "European Union — European Parliament and Council", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-26", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689", "license": "EU-public-sector-information", "status": "current", "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/LI-06 Immutable Version Control with Tested Rollback and Emergency Disable control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Implement append-only model version records in the registry; deploy via blue-green or canary patterns with artifact-hash gating; test rollback to each approved prior version on a scheduled basis; implement an emergency disable path that operates independently of the primary deployment pipeline and can suspend model serving without a full deployment cycle.", "steps": [ "Configure the model registry as append-only for version records: no in-place update or delete of an existing version entry is permitted. Any change to a deployed model (weights, configuration, adapters) requires a new version entry with a new artifact hash.", "Implement blue-green or canary deployment with artifact-hash verification at each promotion gate. The production traffic-switch decision must record the source artifact hash, destination artifact hash, timestamp, and authorizing identity in an immutable deployment log.", "Maintain a rollback map: for each production model version, document the artifact hash, registry entry, and deployment pipeline artifact location for at least the previous two approved versions. Test rollback to each prior approved version on a quarterly basis at minimum; document the test result and rollback time.", "Implement emergency disable as a runtime configuration change — not a deployment pipeline operation. The disable must be triggerable by the MLOps on-call team without requiring access to the CI/CD pipeline, and must take effect within a defined SLA (e.g., 60 seconds). For hosted-API models, the emergency disable is provider API key revocation or traffic routing change — document this path explicitly." ], "anti_patterns": [ "Treating rollback as a theoretical capability that has never been exercised in production — untested rollback is not a rollback capability; the first real incident will reveal that it does not work as expected.", "Implementing emergency disable as a re-deployment of a prior version through the CI/CD pipeline — this is too slow for a genuine safety incident and entangles the disable with the potentially compromised deployment tooling.", "Using mutable deployment labels (e.g., 'production' tag pointing to a changing artifact) without version pinning — label mutation is a silent overwrite that bypasses immutability controls." ] }, "validation": { "design_check": [ "Confirm the model registry schema prevents in-place update or delete of existing version entries; verify by attempting to modify a registry entry directly and confirming rejection [ref:iso_42001_2023].", "Verify the rollback map contains the artifact hash and pipeline artifact location for the previous two approved versions for every production model, and that rollback procedures are documented with time estimates [ref:nist_ai_rmf_1_0].", "Confirm the emergency disable mechanism operates independently of the CI/CD pipeline and has a documented SLA for activation time; verify that on-call personnel have the credentials and access needed to execute it without escalation [ref:sr262_2026]." ], "runtime_test": [ "Execute a rollback test for at least one production model per quarter: roll back to a prior approved version, verify the artifact hash of the serving model matches the prior-version registry entry, and measure rollback time against the documented SLA [ref:nist_ai_rmf_1_0].", "Execute an emergency disable test: activate the emergency disable path in a staging environment, measure time to full suspension of model serving, and confirm the disable operates without requiring CI/CD pipeline access [ref:sr262_2026].", "Inject a hash mismatch event in the deployment monitoring pipeline and confirm the version drift alert fires within the monitoring window defined in the monitoring_schema [ref:iso_42001_2023]." ], "evidence": [ "model:rollback-test-record — quarterly rollback test result including model ID, prior version artifact hash, rollback time measured, and pass/fail status [unverified]", "model:emergency-disable-test-record — emergency disable test result including activation path, time to suspension, and independence from CI/CD pipeline confirmation [unverified]", "model:deployment-log — immutable deployment log entries for each production version transition including source hash, destination hash, timestamp, and authorizing identity [unverified]" ] }, "lenses": { "engineering": { "summary": "Immutable versioning is an architectural constraint on the model registry and deployment pipeline. Engineering must implement append-only registry semantics, blue-green deployment with hash gating, and an emergency disable path that does not share dependencies with the primary pipeline.", "actions": [ "Configure model registry backend to enforce append-only semantics with no update or delete endpoints for existing version records", "Implement blue-green deployment with artifact-hash verification at each promotion gate", "Build emergency disable as a runtime traffic-routing or API-key-revocation mechanism separate from the CI/CD pipeline" ], "tools": [ "Kubernetes blue-green deployment operators", "Istio/Envoy traffic routing for emergency disable", "append-only PostgreSQL table with trigger-enforced insert-only policy", "AWS Parameter Store or similar runtime configuration for emergency disable flag" ], "failure_signals": [ "Model registry allows PUT or PATCH on existing version entries", "Emergency disable requires a new deployment — not a runtime configuration change", "Rollback has never been tested in a non-trivial environment" ] }, "evaluation": { "summary": "Evaluation teams depend on version immutability for reproducibility: a re-evaluation of a prior model version must produce the same artifact being served. If the registry is mutable, prior-version artifact hashes may not correspond to retrievable artifacts.", "actions": [ "Verify that artifact hashes in evaluation records correspond to retrievable artifacts in the model registry before publishing evaluation results", "Confirm that the emergency disable path has been tested and is documented so that evaluation-driven disable recommendations can be acted upon within the SLA" ], "failure_signals": [ "Prior-version artifact hash in evaluation record cannot be resolved to a retrievable artifact in the current registry", "No documented path from evaluation-identified safety failure to emergency disable action" ] }, "red_team": { "summary": "Red teams must probe the immutability controls: can an adversary with pipeline access overwrite a production version record, bypass the emergency disable, or inject a modified artifact via a label mutation?", "actions": [ "Attempt to modify an existing version entry in the model registry via direct database access or API bypass", "Test whether a mutable deployment label (e.g., 'production' tag) can be reassigned to a different artifact hash without creating a new version entry", "Verify that the emergency disable mechanism cannot be blocked by an adversary who also has CI/CD pipeline access" ], "failure_signals": [ "Registry API exposes an update endpoint on version records that is not protected by elevated authorization", "Emergency disable is gated behind the same access control as the deployment pipeline" ] }, "grc": { "summary": "EU AI Act Art-12 requires logging and record-keeping for high-risk AI systems. An immutable deployment log satisfies Art-12's record-keeping requirement by ensuring every version transition is attributable and irrevocable. SR 26-2 expects ongoing monitoring to detect unauthorized model changes.", "actions": [ "Confirm that the immutable deployment log is retained for the applicable regulatory period (EU AI Act: duration determined by post-market monitoring plan; SR 26-2: at minimum 7 years for material models)", "Verify that the deployment log can be produced to regulators on request without manual assembly", "Confirm the rollback and emergency disable test records are included in model risk governance documentation" ], "failure_signals": [ "No immutable deployment log — version transitions are tracked only in mutable CI/CD pipeline metadata", "Rollback and emergency disable have never been tested; no test records exist" ] }, "mlops": { "summary": "MLOps owns the operational health of rollback and emergency disable: quarterly rollback tests, emergency disable drills, and version drift monitoring are MLOps responsibilities. The monitoring_schema below defines the automated version drift detection that MLOps is responsible for operating.", "actions": [ "Schedule and execute quarterly rollback tests for all production models; document results and update rollback time estimates", "Monitor deployed artifact hashes against registry entries on a continuous basis using the version drift metrics defined in monitoring_schema", "Maintain emergency disable runbooks and verify on-call personnel have required access credentials at the start of every on-call rotation" ], "failure_signals": [ "Version drift alert fires but MLOps team has no documented runbook for response", "On-call personnel lack credentials to execute emergency disable without escalation" ] } }, "monitoring_schema": { "sampling_rate": "all", "window_context": "P1D", "metrics": [ { "metric_id": "deployed-hash-match-rate", "metric_type": "drift", "measure": "artifact-hash-match-rate", "population": "all-active-model-serving-endpoints", "baseline_ref": "model-registry-current-approved-entry", "comparison": { "operator": "lt", "value": 1, "window": "rolling-24h", "evaluation_mode": "batch" }, "minimum_sample_size": 1, "severity": "critical", "actions": [ "alert-mlops-team", "engage-incident-response", "restrict-to-supervised-mode", "escalate-to-secops" ], "fallback": "rollback-to-previous-version", "evidence_retention": "P7Y" }, { "metric_id": "unauthorized-version-transitions", "metric_type": "safety", "measure": "unapproved-version-transition-count", "population": "all-production-model-registry-version-entries", "comparison": { "operator": "gt", "value": 0, "window": "P1D", "evaluation_mode": "batch" }, "severity": "critical", "actions": [ "alert-mlops-team", "engage-incident-response", "escalate-to-secops", "suspend-model" ], "fallback": "rollback-to-previous-version", "evidence_retention": "P7Y" }, { "metric_id": "rollback-test-currency", "metric_type": "safety", "measure": "days-since-last-successful-rollback-test", "population": "all-production-models-with-rollback-map-entry", "comparison": { "operator": "gt", "value": 90, "window": "P7D", "evaluation_mode": "batch" }, "severity": "warning", "actions": [ "alert-mlops-team", "open-incident-ticket" ], "evidence_retention": "P3Y" } ] }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations have some version control but lack tested rollback, append-only registry semantics, and independent emergency disable. Achieving 'managed' requires quantitative tracking of rollback test success rates and version drift alert response times." }, "coverage_note": "LI-06 covers versioning and rollback at the model artifact level. System-level change management covering prompt, RAG corpus, and guardrail changes is covered by LI-09 (material-change determination). Post-deployment behavioral monitoring for drift is covered by BH-03 and BH-05. Security access controls on the model registry are a cross-domain concern owned by securitycontrols.ai.", "capability_risk": { "capability_level": "low", "access_mode": "api", "autonomy": "supervised", "external_reach": false, "irreversibility": "partially-reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "moderate" }, "tiers": [ "general-predictive-ml", "generative-ai", "hosted-api", "continuously-learning", "high-impact-decision", "us-regulated-banking", "eu-high-risk", "frontier-capability" ], "implementers": [ "MLOps", "Platform Engineering", "ML Engineering" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE-2.4", "fit": "direct", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MANAGE-2.4 (MANAGE function) provides that mechanisms and assigned responsibilities exist to supersede, disengage, or deactivate AI systems that demonstrate performance inconsistent with intended use. LI-06’s tested rollback and emergency disable are the concrete supersede/deactivate mechanisms this subcategory requires, with authorization responsibilities assigned.", "source_locator": { "subcategory": "MANAGE-2.4" }, "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "initial", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-12", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art-12 requires providers of high-risk AI systems to maintain logging capabilities that ensure traceability of system behavior and enable post-market monitoring. LI-06's immutable deployment log and version records directly support Art-12's traceability requirement. Art-12 also requires logs to be retained for a defined period; LI-06 does not independently specify retention — that is addressed in CR layer controls.", "uncovered_portion": "Art-12 specifies logging content requirements (inputs, outputs, period) beyond version transition records; inference-level logging is addressed in BH-05.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "initial", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "6.3", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 Clause 6.3 (Planning of changes) requires changes to the AI management system and its systems to be carried out in a planned manner. LI-06’s append-only versioning, authorization gates, and tested rollback give model changes that planned, reversible pathway.", "source_locator": { "section": "Clause 6.3" }, "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "initial", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0044", "fit": "partial", "direction": "control-supports-requirement", "rationale": "MITRE ATLAS AML.T0044 (Full AI Model Access) describes an adversary gaining sufficient access to substitute or exfiltrate a model artifact. Immutable version records and hash-mismatch monitoring reduce the window between a substitution event and its detection. LI-06's emergency disable provides a rapid containment mechanism once AML.T0044 activity is detected. Full access control mitigation is owned by securitycontrols.ai.", "uncovered_portion": "AML.T0044 full mitigation requires access control to the model registry and serving infrastructure — cross-domain security responsibility.", "source_version": "v2026.06", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "initial", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "owasp_aitg", "requirement_id": "AITG-MOD-02", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "AITG-MOD-02 (Testing for Runtime Model Poisoning) probes whether a deployed model can be modified without authorization at runtime. LI-06's immutable versioning, authorization-gated promotion, and tested rollback limit exactly the modification pathways this test exercises.", "source_locator": { "test_id": "AITG-MOD-02", "test_name": "Testing for Runtime Model Poisoning" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" } ], "cross_domain": { "references": [ { "uri": "apeiris://security/controls/CM-03", "relationship": "related", "note": "Security domain change management controls enforce access restrictions on model registry writes that LI-06 immutability semantics depend on." } ], "evidence_artifacts": [ { "artifact_type": "model:deployment-log", "producer_verifier": "apeiris://model", "consumer_verifiers": [ "apeiris://security" ], "retention": "P7Y" }, { "artifact_type": "model:rollback-test-record", "producer_verifier": "apeiris://model", "retention": "P3Y" } ] }, "readiness": "approved", "thesis_type": "corrective", "matrix_thesis": "Rollback without testing is a liability, not a control. Organizations routinely discover during incidents that their rollback procedure has never been exercised in a realistic environment, that it takes ten times longer than expected, or that the emergency disable path is entangled with the compromised tooling. LI-06 requires these capabilities to be proven operational before an incident, not assumed.", "meta": { "authored_on": "2026-06-26", "schema_version": "1.0.0" }, "canonical_id": "apeiris://model/controls/LI-06", "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "provision": "Art-12", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "mapping_fit": "partial", "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "notes": "Art-12 requires providers of high-risk AI systems to design systems to automatically record events ('logs') including periods of use, reference databases against which the system has been checked, input data, and information to identify the persons responsible. Minimum 6-month log retention unless Union or national law specifies otherwise. Effective Dec 2, 2027 for standalone Annex III systems (Parliament-approved; Council adoption pending as of 2026-06-26). Product-embedded: Aug 2, 2028.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "Every production model deployment must use an append-only model registry where no existing version entry can be overwritten or deleted; each version transition must be recorded in an immutable deployment log with source hash, destination hash, timestamp, and authorizing identity; rollback to any prior approved version must be tested and documented at least quarterly with measured rollback time; and the emergency disable mechanism must operate independently of the CI/CD pipeline and be exercisable by on-call personnel within the defined SLA.", "evidence_required": [ "immutable_deployment_log with append-only version transition entries recording source artifact hash, destination artifact hash, timestamp, and authorizing identity for each production version change", "quarterly_rollback_test_record including model ID, prior version artifact hash, measured rollback time, and pass/fail outcome, with at least one record per production model dated within the last 90 days", "emergency_disable_test_record documenting the activation path, time from trigger to complete suspension of model serving, and explicit confirmation that the disable did not require access to CI/CD pipeline credentials", "version_drift_monitoring_alert_record demonstrating that a hash mismatch between the serving artifact and the registry entry triggered an alert within the monitoring window defined in the monitoring schema" ], "machine_tests": [ "Attempt to update an existing model version entry via API PUT or PATCH → assert the registry returns a method-not-allowed or permission-denied error enforcing append-only semantics", "Execute a rollback to the prior approved version of a model in staging → assert the artifact hash of the serving model after rollback matches the prior-version registry entry and rollback completes within the documented SLA", "Activate the emergency disable mechanism in staging and measure time to full cessation of model serving → assert suspension occurs within the defined SLA without requiring CI/CD pipeline access", "Inject a synthetic artifact hash mismatch between the deployed serving model and the registry entry → assert the deployed-hash-match-rate monitoring metric triggers a critical alert within the rolling-24h monitoring window" ], "human_review": [ "Review the rollback map to confirm it contains the artifact hash and artifact storage location for at least the prior two approved versions for every production model, and that the documented rollback time estimate reflects the most recent quarterly test result rather than a theoretical estimate", "Verify that the emergency disable procedure is documented in the on-call runbook and that current on-call personnel hold the access credentials required to execute it without escalation to a CI/CD pipeline administrator", "Assess the deployment log retention configuration to confirm log entries are immutable post-write and retained for the full applicable regulatory period, not just for the current deployment tooling lifecycle" ], "blocking_effect": "blocks-deployment", "normative_status": "certification-standard", "anti_patterns": [ "Treating rollback as a theoretical capability documented in runbooks but never exercised in a realistic environment, discovering during a real incident that rollback takes ten times longer than estimated or fails because artifact storage locations have changed", "Implementing emergency disable as a re-deployment of a prior artifact version through the normal CI/CD pipeline, making the disable unavailable when the pipeline itself is compromised or unavailable during the same incident that necessitates the disable", "Using mutable deployment labels such as 'production' or 'latest' that point to a changing artifact without version pinning, allowing silent model substitution through label reassignment that bypasses immutable versioning controls", "Configuring version drift monitoring as an infrequent batch check rather than near-real-time artifact hash verification, allowing substituted artifacts to serve production traffic for hours or days before detection" ], "update_status": "current", "layer_code": "LI" }, { "id": "LI-07", "layer": "LI", "plane": "control", "name": "Capability and Limitation Declaration — Intended Use, Constraints,...", "plain": "Each model formally declares what it is designed to do, what it cannot reliably do, what uses are out of scope, and where its knowledge ends, so that deployers and users can make informed decisions about when to rely on it.", "threat": { "tags": [ "governance-gap", "harmful-output", "accountability-gap" ], "desc": "A model's stated capabilities are not a complete description of its behavior envelope: models are routinely deployed in contexts their developers did not evaluate or intend. Without a formal declaration of intended use, stated limitations, out-of-scope uses, uncertainty bounds, and knowledge cutoff, downstream deployers have no authoritative basis for determining whether a use case is appropriate. This enables harm through misapplication: using a model for consequential decisions in domains it was never evaluated on, or relying on factual outputs past the knowledge cutoff date. EU AI Act Art-13 requires transparency information enabling deployers to make informed deployment decisions; absent a capability and limitation declaration, this obligation cannot be satisfied." }, "standard": [ { "id": "eu_ai_act", "section": "Art-13", "title": "Transparency and provision of information to deployers" }, { "id": "nist_rmf", "section": "MAP-2.2", "title": "Knowledge limits and human oversight documentation" }, { "id": "iso_42001", "section": "A.9.4", "title": "Intended use of the AI system" } ], "sources": [ { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "authority": "European Union — European Parliament and Council", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-26", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689", "license": "EU-public-sector-information", "status": "current", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/LI-07 Capability and Limitation Declaration — Intended Use, Constraints,... control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/LI-07 Capability and Limitation Declaration — Intended Use, Constraints,... control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary-paid", "status": "current", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/LI-07 Capability and Limitation Declaration — Intended Use, Constraints,... control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Require a structured capability and limitation declaration as a mandatory model registry field — separate from the model card but linked to it — covering five required dimensions: intended use, stated limitations, out-of-scope uses, uncertainty bounds by task type, and knowledge cutoff date.", "steps": [ "Define a structured capability-limitation schema with five required top-level fields: (1) intended_uses: list of evaluated and approved use cases with population and context qualifiers; (2) stated_limitations: list of known performance, coverage, or behavioral limitations with associated conditions; (3) out_of_scope_uses: list of explicitly disallowed or unevaluated use cases with rationale; (4) uncertainty_bounds: for each intended use, the conditions under which model outputs should be treated as high-uncertainty (e.g., queries outside training distribution, queries about events post-cutoff); (5) knowledge_cutoff: date-formatted cutoff for factual knowledge with a statement about the model's awareness of the cutoff.", "Populate the declaration at model registration time, enforcing non-emptiness of each dimension. For third-party hosted models where provider declarations are available, import and reference them; for models with no provider-supplied declaration, document the gap explicitly rather than leaving fields empty.", "Version the declaration alongside the model artifact: any update to the capability or limitation statement that would affect downstream deployment decisions constitutes a material change requiring LI-09 authorization and a new model version.", "Surface the declaration at model consumption points: deployers accessing the model via internal API or registry should receive the current capability-limitation declaration as part of the model metadata, not buried in documentation." ], "anti_patterns": [ "Declaring intended use as a single high-level sentence (e.g., 'for customer service applications') without qualifying the population, language, domain, or context — this is legally meaningless and operationally useless for deployers scoping appropriate use.", "Omitting the out-of-scope uses field or leaving it empty — the absence of stated out-of-scope uses implies the model's capabilities are unlimited, which is never accurate and exposes the organization to misapplication liability.", "Setting the knowledge cutoff date but providing no guidance on how the model behaves for queries about events near or after the cutoff — a cutoff date without behavioral uncertainty guidance does not help deployers manage cutoff-related failure modes." ] }, "validation": { "design_check": [ "Confirm the capability-limitation declaration schema enforces non-emptiness of all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) and that registration is blocked when any dimension is absent [ref:eu_ai_act_2024].", "Review the declaration for a production model and verify that intended_uses include population and context qualifiers, and that out_of_scope_uses lists at least one explicitly disallowed use case [ref:nist_ai_rmf_1_0].", "Confirm the declaration is surfaced at model consumption points — verify that the registry API response for a given model ID includes the current capability-limitation declaration in structured form [ref:owasp_aisvs_v1]." ], "runtime_test": [ "Attempt to register a model with an empty out_of_scope_uses field; confirm the pipeline blocks registration and identifies the specific missing dimension [ref:eu_ai_act_2024].", "For a production model with a defined knowledge_cutoff, query the model with a question about a current event post-cutoff; verify the model's response behavior is consistent with the declared uncertainty_bounds (e.g., the model acknowledges the limitation rather than confidently confabulating) [ref:nist_ai_rmf_1_0].", "Verify that a deployer accessing the model via the internal registry API receives the capability-limitation declaration in the model metadata response without requiring separate documentation lookup [ref:owasp_aisvs_v1]." ], "evidence": [ "model:capability-limitation-declaration — structured, schema-validated capability and limitation declaration with all five required dimensions populated and linked to artifact hash [unverified]", "model:registry-api-response-sample — sample registry API response demonstrating that the declaration is returned as structured metadata for model consumption points [unverified]", "model:cutoff-behavior-test-result — test result demonstrating that the model's behavior for post-cutoff queries is consistent with the declared uncertainty bounds [unverified]" ] }, "lenses": { "engineering": { "summary": "Engineering must build the capability-limitation declaration as a structured schema field in the model registry, not a free-text documentation artifact. The declaration must be surfaced programmatically at model consumption points.", "actions": [ "Define and implement the five-field capability-limitation schema in the model registry", "Surface the declaration in model metadata API responses alongside the artifact hash and model ID", "Enforce non-emptiness of all five dimensions as a blocking gate in model registration" ], "failure_signals": [ "Capability and limitation information exists only in documentation, not in structured registry fields", "Registry API does not return capability-limitation data in model metadata responses" ] }, "evaluation": { "summary": "The out_of_scope_uses dimension is the highest-priority red-flag list for evaluation: uses not evaluated by the developer define the highest-uncertainty regions of the model's behavior space and should be prioritized in independent evaluation scoping.", "actions": [ "Review the capability-limitation declaration before scoping evaluation to identify high-uncertainty regions and out-of-scope uses that require independent testing", "Verify that the uncertainty_bounds dimension accurately reflects the model's observed behavior on near-distribution and out-of-distribution inputs", "Flag any production deployment where the declared intended_uses are narrower than the actual deployment context observed in monitoring" ], "failure_signals": [ "Evaluation scope does not include testing of behaviors near stated limitations", "Declared intended_uses do not match the deployment context observed in production" ] }, "red_team": { "summary": "The out_of_scope_uses field is the red team's primary target list. Red teams must test whether the model can be prompted to perform out-of-scope tasks and whether the uncertainty_bounds hold under adversarial pressure.", "actions": [ "Use the out_of_scope_uses list as the primary red-team target: attempt to elicit each out-of-scope use through direct, indirect, and jailbreak prompting", "Test whether the model's uncertainty behavior holds under adversarial pressure: can the model be prompted to respond confidently about post-cutoff events or out-of-distribution topics it should express uncertainty about?", "Probe the boundary between intended_uses and out_of_scope_uses — models often fail at the boundary rather than at the extremes" ], "failure_signals": [ "Model performs stated out-of-scope uses with confidence rather than declining or expressing uncertainty", "Model provides confident factual claims about post-cutoff events without acknowledging the knowledge cutoff" ] }, "grc": { "summary": "EU AI Act Art-13 requires that deployers receive sufficient information to understand a high-risk AI system's capabilities and limitations. A structured capability-limitation declaration directly satisfies Art-13 by providing machine-readable, deployer-facing transparency information.", "actions": [ "Confirm that the capability-limitation declaration satisfies Art-13's transparency requirements for all EU AI Act in-scope systems", "Verify that deployer contracts reference the capability-limitation declaration and include a clause requiring deployers to use the model within declared intended_uses", "Confirm the declaration is updated when capabilities or limitations change and that prior versions are retained" ], "failure_signals": [ "Deployer contracts do not reference the capability-limitation declaration", "Declaration has not been updated despite monitoring evidence of performance changes outside declared bounds" ] }, "mlops": { "summary": "MLOps must monitor whether production usage patterns align with the declared intended_uses and flag deployments where usage drifts into declared out-of-scope territory.", "actions": [ "Monitor inference request patterns to detect deployment contexts drifting outside declared intended_uses", "Trigger a capability-limitation declaration review when monitoring reveals systematic usage in out-of-scope or high-uncertainty contexts", "Integrate the knowledge_cutoff date into monitoring: alert when inference queries are systematically about events near or after the cutoff date" ], "failure_signals": [ "Production usage patterns show systematic querying in declared out-of-scope domains with no escalation", "No monitoring for queries about post-cutoff events in models with a declared knowledge cutoff" ] } }, "maturity": { "current": "none", "target": "defined", "notes": "Most organizations document intended use informally in model cards or README files without structured schemas, without out-of-scope use declarations, and without machine-surfacing at consumption points. Achieving 'defined' requires a structured schema enforced at registration." }, "coverage_note": "LI-07 covers the provider or developer's formal capability and limitation declaration. Whether deployers actually respect the declared constraints is governed by OA-01 (use case oversight) and OA-08 (notice and transparency to affected parties). Behavioral testing of declared limitation boundaries is owned by EV-01 and EV-02.", "capability_risk": { "capability_level": "low", "access_mode": "api", "autonomy": "supervised", "external_reach": false, "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "moderate" }, "tiers": [ "generative-ai", "eu-high-risk", "frontier-capability" ], "implementers": [ "ML Engineering", "Model Governance", "Legal/Compliance" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art-13", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EU AI Act Art-13 requires that high-risk AI systems be designed and developed such that deployers receive sufficient information to understand the system's capabilities and limitations and to implement appropriate human oversight. LI-07's structured capability-limitation declaration directly satisfies Art-13 by providing machine-readable, structured transparency information at the model consumption point.", "source_locator": { "section": "Chapter III", "clause": "Article 13" }, "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_rmf", "requirement_id": "MAP-2.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MAP-2.2 (MAP function) provides that information about the AI system’s knowledge limits and how output may be utilized and overseen by humans is documented. LI-07’s capability and limitation declaration — intended uses, knowledge cutoff, and unsupported domains — is precisely the knowledge-limits documentation this subcategory requires.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.9.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.9.4 (Intended use of the AI system) requires that systems be used according to their intended, documented use. LI-07’s capability and limitation declaration — intended_uses, out-of-scope uses, and knowledge cutoff — is the artifact that makes intended use enforceable.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "llm10", "requirement_id": "LLM09:2025", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OWASP LLM09:2025 addresses misinformation risks from LLMs including overreliance on model outputs beyond their knowledge or capability boundaries. LI-07's knowledge_cutoff and uncertainty_bounds dimensions directly address the transparency prerequisites for managing LLM09 misinformation risk. LI-07 is a transparency control; misinformation detection and measurement are owned by EV-02.", "uncovered_portion": "LLM09:2025 encompasses active misinformation detection, grounding controls, and evaluation of factual accuracy beyond the transparency declaration that LI-07 provides.", "source_version": "2025", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "owasp_ai_exchange", "requirement_id": "aitransparency", "fit": "partial", "rationale": "Declaring intended uses, limitations, out-of-scope uses, and knowledge cutoff is transparency about what the model can and cannot reliably do.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "directive", "matrix_thesis": "A model's intended use statement is not a legal disclaimer — it is an assurance commitment. When a developer fails to declare what a model cannot do, deployers fill the vacuum with optimistic assumptions, and affected parties bear the consequences. LI-07 treats capability and limitation declaration as an engineering-enforced, machine-readable artifact, not a documentation afterthought.", "meta": { "authored_on": "2026-06-26", "schema_version": "1.0.0" }, "canonical_id": "apeiris://model/controls/LI-07", "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "provision": "Art-13", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "mapping_fit": "direct", "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "notes": "Art-13 requires providers of high-risk AI systems to design and develop systems to be sufficiently transparent that deployers can understand the system's capabilities and limitations and can implement appropriate human oversight. Annex VII details minimum content for instructions for use, which substantially overlaps with a structured capability-limitation declaration. Effective Dec 2, 2027 for standalone Annex III systems. Product-embedded: Aug 2, 2028.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "Every registered model must have a structured, schema-validated capability-limitation declaration with all five required dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, and knowledge_cutoff) substantively populated with population- and context-qualified entries, returned as structured metadata in the model registry API response; registration must be blocked when any dimension is absent or empty; and the model's observable behavior for post-knowledge-cutoff queries must be consistent with the declared uncertainty_bounds.", "evidence_required": [ "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension" ], "machine_tests": [ "Attempt to register a model with the out_of_scope_uses field absent or containing an empty array → assert the pipeline blocks registration and returns an error identifying the missing dimension", "Query the model registry API with a valid registered model ID → assert the response body includes a structured capability_limitation_declaration object with all five required dimensions present and non-empty", "Submit an inference request asking about a factual event that occurred after the model's declared knowledge_cutoff date → assert the model response acknowledges the knowledge cutoff or expresses uncertainty rather than producing a confident factual claim" ], "human_review": [ "Review the intended_uses dimension of a production model's capability-limitation declaration to verify each listed use case includes qualifiers for the target population, language, domain, and decision stakes rather than high-level category labels alone", "Assess the out_of_scope_uses dimension to confirm it lists specific disallowed or unevaluated applications with individual rationale statements, not generic disclaimers applicable to any AI system", "Verify that the knowledge_cutoff date and uncertainty_bounds are consistent with the training data documentation in model card section 6 and with observed model behavior on near-cutoff query tests conducted during evaluation" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Declaring intended use as a single generic phrase such as 'for customer service applications' without qualifying the target population, language, query complexity, or decision stakes, rendering the declaration legally insufficient for EU AI Act Art-13 transparency obligations", "Leaving the out_of_scope_uses dimension empty or absent on the premise that no use cases are explicitly prohibited, implying unlimited model capability that no model possesses and exposing the organization to misapplication liability when downstream deployers rely on that implication", "Populating the knowledge_cutoff field with a date but leaving the uncertainty_bounds dimension without any guidance on how the model behaves for queries about events near or after the cutoff, depriving deployers of behavioral information needed to implement appropriate human oversight", "Storing the capability-limitation declaration only in narrative model card documentation rather than as a structured machine-readable registry field surfaced at model consumption points via the registry API", "Failing to update the capability-limitation declaration when production monitoring reveals systematic usage outside the declared intended_uses or when fine-tuning or retrieval-augmentation changes the model's effective knowledge or capability boundaries" ], "update_status": "current", "layer_code": "LI" }, { "id": "LI-08", "layer": "LI", "plane": "control", "name": "License and IP Governance — Dataset License Tracking, Derivative Work...", "plain": "Before any model is deployed, all licenses governing the training data, base models, and adapters used to create it are recorded and checked for compatibility with the intended use, so that the organization does not unknowingly violate IP obligations.", "threat": { "tags": [ "governance-gap", "regulatory-noncompliance", "supply-chain-compromise" ], "desc": "AI models are built from a layered stack of licensed artifacts: training datasets (often under CC BY-SA, non-commercial, or research-only licenses), base models (with varying commercial use, derivative work, and distribution constraints), and adapters or fine-tuning components (inheriting constraints from base models). Without systematic license chain tracking, organizations routinely deploy models in violation of training data licenses (e.g., using non-commercial datasets in production) or base model licenses (e.g., distributing fine-tunes of models with no-derivatives restrictions). Violating ShareAlike or no-commercial-use clauses exposes organizations to legal action from data rights holders. For frontier models, license non-compliance may also violate provider acceptable-use policies in ways that trigger service termination." }, "standard": [ { "id": "nist_rmf", "section": "GOVERN-1.1", "title": "Legal and regulatory requirements (including IP) understood and documented" }, { "id": "iso_42001", "section": "A.5.2", "title": "AI system impact — legal and regulatory considerations" }, { "id": "aisvs", "section": "C6.2", "title": "Supply chain — AI BOM (license tracking)" }, { "id": "aicm", "section": "MDS-03", "title": "Model documentation — licensing and IP constraints" } ], "sources": [ { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary-paid", "status": "current", "flagship": true, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/LI-08 License and IP Governance — Dataset License Tracking, Derivative Work... control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/LI-08 License and IP Governance — Dataset License Tracking, Derivative Work... control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_aisvs_v1", "title": "OWASP AI Security Verification Standard v1.0", "authority": "Open Worldwide Application Security Project (OWASP)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2026-06-24", "retrieved_on": "2026-06-26", "canonical_url": "https://github.com/OWASP/AISVS", "license": "CC BY-SA 4.0", "status": "current", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "url": "https://github.com/OWASP/AISVS", "source_id": "owasp_aisvs_v1", "relationship": "implementation_pattern", "rationale": "Establishes OWASP AI Security Verification Standard v1.0 requirements informing the apeiris://model/controls/LI-08 License and IP Governance — Dataset License Tracking, Derivative Work... control.", "reviewed_on": "2026-07-01" }, { "id": "csa_aicm_v1", "title": "Cloud Security Alliance AI Controls Matrix v1.1", "authority": "Cloud Security Alliance (CSA)", "source_type": "industry-framework", "normative_force": "voluntary-standard", "version": "1.1", "published_on": "2024-06-01", "retrieved_on": "2026-06-26", "canonical_url": "https://cloudsecurityalliance.org/research/topics/ai-controls-matrix", "license": "CC BY-SA 4.0", "status": "current", "source_id": "csa_aicm", "relationship": "implementation_pattern", "rationale": "Establishes Cloud Security Alliance AI Controls Matrix v1.1 requirements informing the apeiris://model/controls/LI-08 License and IP Governance — Dataset License Tracking, Derivative Work... control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Build a license chain record for each model artifact that enumerates the licenses of all training datasets (per TG-layer records), the base model license, and any adapter or merged model licenses; perform automated compatibility analysis against the declared deployment use type (commercial, internal, research, distribution); block deployment when incompatibilities are found.", "steps": [ "At model registration, generate a license chain record by aggregating: (a) dataset licenses from the TG-layer records referenced in LI-05; (b) the base model license from the LI-02 provenance record; (c) any adapter or merged model component licenses. Store all license identifiers using SPDX license identifiers where available.", "Implement automated license compatibility analysis: for each license in the chain, evaluate compatibility against the declared deployment use type (commercial production, internal use, research, distribution/resale). Define clear compatibility rules for common conflicts (CC BY-NC in commercial deployment, CC BY-SA propagation to derivative models, no-derivatives clauses on base models with fine-tunes).", "Block deployment when the compatibility analysis identifies a hard incompatibility (e.g., non-commercial training data in commercial deployment, no-derivatives base model with a fine-tune intended for distribution). Log compatibility analysis results in the model registry entry.", "Require legal review sign-off for any deployment where the compatibility analysis returns ambiguous or contested results — particularly for novel license combinations or for licenses with AI-specific use-restriction clauses introduced after the license was written." ], "anti_patterns": [ "Assuming that because a dataset is publicly available it is freely usable for commercial training — many open datasets carry non-commercial, ShareAlike, or research-only restrictions that are violated by commercial deployment.", "Performing license review only for the final model artifact and ignoring the base model license chain — ShareAlike and derivative work restrictions propagate from base models to all fine-tunes and derivatives.", "Treating license compatibility as a one-time check at initial deployment rather than a continuous obligation — licenses can change, new use cases can create new incompatibilities, and provider acceptable-use policy updates can affect deployed models." ] }, "validation": { "design_check": [ "Confirm the model registry schema includes a license chain record with fields for each dataset license, base model license, and adapter license, and that the record uses SPDX identifiers where available [ref:iso_42001_2023].", "Verify that the automated license compatibility analysis tool covers the declared deployment use types and common AI-specific license restriction patterns (CC BY-NC, CC BY-SA, no-derivatives, non-commercial clauses) [ref:nist_ai_rmf_1_0].", "Confirm that deployment is blocked when a hard compatibility incompatibility is detected and that the incompatibility details are logged in the registry entry [ref:owasp_aisvs_v1]." ], "runtime_test": [ "Attempt to deploy a model whose license chain includes a non-commercial training dataset against a commercial deployment use type; confirm the pipeline blocks deployment and logs the specific incompatibility [ref:iso_42001_2023].", "Register a model fine-tuned from a base model with a no-derivatives license clause; confirm the compatibility analysis flags the fine-tune distribution use case as incompatible [ref:nist_ai_rmf_1_0].", "Verify that the license chain record for a production model is retrievable and contains SPDX-identified licenses for all training datasets referenced in the LI-05 training-data pointer [ref:owasp_aisvs_v1]." ], "evidence": [ "model:license-chain-record — structured license chain record for each model artifact covering training dataset licenses, base model license, adapter licenses, and SPDX identifiers [unverified]", "model:license-compatibility-analysis-result — automated compatibility analysis result against declared deployment use type, with pass/fail/ambiguous status and specific incompatibility details [unverified]", "model:legal-review-sign-off — legal sign-off record for deployments where compatibility analysis returned ambiguous results [unverified]" ] }, "lenses": { "engineering": { "summary": "License chain tracking is a data quality problem that engineering must solve with tooling: automated aggregation of dataset licenses from the TG-layer catalog, base model licenses from the LI-02 provenance record, and compatibility analysis as a pipeline gate.", "actions": [ "Build automated license chain aggregation from TG-layer dataset records and LI-02 provenance records at model registration time", "Integrate license compatibility analysis as a blocking gate in the deployment pipeline for declared deployment use types", "Implement SPDX license identifier normalization to enable automated compatibility reasoning" ], "tools": [ "SPDX License List and identifiers", "FOSSology or similar license scanning tools adapted for ML artifacts", "in-house compatibility rule engine with SPDX compatibility matrix" ], "failure_signals": [ "License chain record does not exist or contains free-text descriptions rather than SPDX identifiers", "Deployment pipeline has no license compatibility gate", "Base model license is not included in the chain — only dataset licenses are tracked" ] }, "evaluation": { "summary": "Evaluation teams working with research or pre-release models must verify that the license conditions of training data and base models permit the evaluation activities being performed (e.g., publication of results, use of outputs for further model development).", "actions": [ "Review the license chain record before publishing evaluation results to confirm that license conditions permit result disclosure", "Flag evaluations where training data licenses may restrict publication of model performance details" ], "failure_signals": [ "Evaluation results published without checking whether training dataset licenses permit disclosure of performance characteristics" ] }, "red_team": { "summary": "Red teams must verify that the license compatibility gate cannot be bypassed and that the license chain is complete — a missing adapter license in the chain is as dangerous as a missing dataset license.", "actions": [ "Attempt to register a model with an incomplete license chain (missing adapter license) and verify the pipeline flags the incompleteness", "Test whether a model with a contested license combination can be deployed by changing the declared use type rather than resolving the incompatibility" ], "failure_signals": [ "Deployment use type can be changed in the registry without triggering a re-analysis of license compatibility", "Adapter and fine-tune licenses are not included in the chain — only base model and dataset licenses are tracked" ] }, "grc": { "summary": "License compliance is a legal obligation, not a best practice. IP violations from training data or base model license breaches create litigation exposure. For frontier models, provider acceptable-use policy violations can result in service termination. Legal must own the compatibility rule definitions; engineering must operationalize them.", "actions": [ "Confirm that legal counsel has reviewed and approved the compatibility rule definitions used in the automated analysis tool", "Verify that all AI-specific acceptable-use policy clauses from model providers are reflected in the compatibility rules", "Establish a periodic review process for license chain records: license conditions can change, and new case law may affect interpretation of existing licenses" ], "failure_signals": [ "Compatibility rules were defined by engineering without legal review", "Provider acceptable-use policy updates have not been reflected in the compatibility rules" ] }, "mlops": { "summary": "MLOps must trigger license chain re-analysis when the deployment use type changes (e.g., scaling from internal to public), when training data is updated, or when a provider issues an acceptable-use policy update that may affect existing deployments.", "actions": [ "Re-run license compatibility analysis when deployment use type changes for any model in production", "Configure alerts for provider acceptable-use policy update notifications and trigger impact assessment across all affected models", "Maintain a review cycle for license chain records that have compatibility ambiguity — schedule legal review before annual production deployment renewals" ], "failure_signals": [ "Deployment use type changed from internal to commercial without triggering license re-analysis", "Provider acceptable-use policy update not captured in the license chain monitoring process" ] } }, "maturity": { "current": "none", "target": "defined", "notes": "Most organizations have no automated license chain tracking for ML models. Training data and base model licenses are typically not aggregated into a machine-readable record. Achieving 'defined' requires automated aggregation, SPDX normalization, and a deployment-blocking compatibility gate." }, "coverage_note": "LI-08 covers license and IP governance at the model artifact level. Data consent and personal data rights obligations (distinct from license obligations) are addressed in the TG layer. Export control and national security restrictions on model distribution are out of scope for LI-08 and require separate legal review.", "capability_risk": { "capability_level": "low", "access_mode": "api", "autonomy": "supervised", "external_reach": false, "irreversibility": "partially-reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "tiers": [ "generative-ai", "hosted-api", "frontier-capability" ], "implementers": [ "ML Engineering", "Legal/Compliance", "Model Governance" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-1.1 (GOVERN function) provides that legal and regulatory requirements involving AI are understood, managed, and documented. LI-08’s license chain tracking and automated compatibility verification manage and document the IP and licensing obligations attached to model training inputs.", "source_locator": { "subcategory": "GOVERN-1.1" }, "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.5.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001:2023 A.5.2 requires that AI system impacts including legal and regulatory considerations be assessed and addressed. License chain analysis is the primary mechanism for identifying legal obligations arising from training data and base model IP rights.", "source_locator": { "section": "Annex A", "clause": "A.5.2" }, "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "llm10", "requirement_id": "LLM03:2025", "fit": "adjacent", "direction": "tangential", "rationale": "OWASP LLM03:2025 (Supply Chain) addresses risks from third-party models and training data including license violations as a supply chain risk vector. LI-08's license chain governance is adjacent to LLM03:2025 supply chain controls: IP non-compliance from untracked licenses is a consequential supply chain failure mode. The primary supply chain integrity control is LI-03; LI-08 addresses the IP obligation layer.", "source_version": "2025", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "low", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "aicm", "requirement_id": "MDS-03", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CSA AICM MDS-03 (Model Documentation) expects model documentation to capture legal and licensing constraints on the model and its training inputs. LI-08’s license chain record and automated compatibility verification supply the IP and licensing evidence that model documentation requires.", "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "source_locator": { "control_id": "MDS-03" }, "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "owasp_aisvs", "requirement_id": "C1.1.5", "fit": "partial", "rationale": "AISVS C1.1.5 dataset watermarking for attribution + unauthorized-use detection.", "normative_force": "industry-framework", "source_version": "1.0", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "checkcompliance", "fit": "partial", "rationale": "Recording and compatibility-checking dataset/base-model/adapter licenses before deployment is a compliance check against IP law and license terms.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "The AI industry treats license non-compliance as a legal technicality rather than an operational risk. It is neither: non-commercial training data in commercial products creates immediate litigation exposure; no-derivatives base model licenses violated by fine-tune distribution are contractual breaches. As data rights holders and model providers become more sophisticated about enforcement, organizations without license chain governance will face avoidable legal liability.", "meta": { "authored_on": "2026-06-26", "schema_version": "1.0.0" }, "canonical_id": "apeiris://model/controls/LI-08", "validation_objective": "A machine-readable license chain record exists for every production model artifact, enumerating SPDX-identified licenses for all training datasets, the base model, and any adapters or fine-tunes; an automated compatibility analysis must confirm the chain is compatible with the declared deployment use type, and deployment must be blocked when a hard incompatibility is detected.", "evidence_required": [ "model_license_chain_record listing SPDX license identifiers for each training dataset, base model, and adapter component, with a link to TG-layer dataset provenance records", "license_compatibility_analysis_result with pass/fail/ambiguous verdict for the declared deployment use type (commercial, internal, research, distribution), including specific incompatibility details where applicable", "deployment_pipeline_block_log showing that a deployment attempt was rejected when an incompatibility was detected, with the specific conflicting license pair recorded", "legal_review_signoff_record for any deployment where compatibility analysis returned an ambiguous verdict, signed by authorized legal counsel" ], "machine_tests": [ "Register a model whose training dataset list includes a CC BY-NC licensed dataset and set deployment use type to 'commercial' → assert pipeline blocks deployment and logs incompatibility identifying the CC BY-NC dataset", "Register a fine-tuned model derived from a base model with a no-derivatives license clause and set distribution as intended use → assert compatibility analysis returns hard incompatibility and deployment is blocked", "Retrieve the license chain record for a currently deployed production model → assert record contains SPDX identifiers for all referenced TG-layer datasets and that base model license field is populated", "Attempt to deploy a model with an incomplete license chain (missing adapter license) → assert pipeline flags chain incompleteness and does not proceed to compatibility analysis" ], "human_review": [ "Review the compatibility rule definitions used by the automated analysis tool to confirm they cover AI-specific license clauses (CC BY-NC, CC BY-SA propagation, no-derivatives on fine-tunes) and that legal counsel has approved the rule set", "Assess whether provider acceptable-use policy updates for any base model in production have been reflected in the license chain records and compatibility rules within the last review cycle", "Verify that the model registry schema enforces SPDX identifier normalization and that free-text license descriptions are not accepted as substitutes" ], "blocking_effect": "blocks-deployment", "normative_status": "certification-standard", "anti_patterns": [ "Assuming publicly available training datasets are freely usable in commercial production without verifying license terms — many open datasets carry NC, SA, or research-only restrictions", "Reviewing only the final model artifact's license and ignoring the base model license chain — ShareAlike and derivative-work restrictions propagate from base models to all fine-tunes", "Storing license information as free-text descriptions rather than SPDX identifiers, making automated compatibility analysis unreliable", "Treating license compatibility as a one-time check at initial deployment without re-running analysis when deployment use type changes or provider acceptable-use policies are updated", "Performing compatibility analysis without legal counsel review of the rule definitions, leaving the organization exposed to license interpretations that engineering alone cannot adjudicate" ], "update_status": "current", "layer_code": "LI" }, { "id": "LI-09", "layer": "LI", "plane": "control", "name": "Material-Change Determination and Authorization Gate", "plain": "A formal process determines whether any planned change to a model or its operating environment is significant enough to require a new evaluation and approval cycle before it goes live — covering model updates, prompt changes, RAG corpus changes, guardrail changes, and provider-version changes.", "threat": { "tags": [ "undisclosed-model-change", "governance-gap", "unauthorized-deployment" ], "desc": "Changes to an AI system's behavior envelope routinely occur without triggering a formal evaluation cycle: a system prompt is modified to enable a new capability; a RAG corpus is updated with data from a new domain; guardrails are loosened to reduce false refusals; a provider silently updates the underlying model version at the same API endpoint. Each of these changes can materially alter model outputs, risk profile, and regulatory compliance status without being classified as a 'model change' under conventional IT change management. SR 26-2 requires re-validation for material model changes; EU AI Act Art-9 requires the risk management system to address all lifecycle phases including changes. The failure to define and operationalize what constitutes a material change is one of the most common gaps in AI governance programs." }, "standard": [ { "id": "nist_rmf", "section": "MANAGE-4.1", "title": "Post-deployment monitoring, change management, and incident response" }, { "id": "iso_42001", "section": "6.3", "title": "Planning of changes" }, { "id": "eu_ai_act", "section": "Art-9", "title": "Risk management system — lifecycle risk assessment" }, { "id": "aisvs", "section": "C3.2", "title": "Model lifecycle — validation & testing (change-triggered re-evaluation)" } ], "sources": [ { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "authority": "European Union — European Parliament and Council", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-26", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689", "license": "EU-public-sector-information", "status": "current", "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/LI-09 Material-Change Determination and Authorization Gate control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/LI-09 Material-Change Determination and Authorization Gate control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary-paid", "status": "current", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/LI-09 Material-Change Determination and Authorization Gate control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define and document a material-change taxonomy covering all seven change categories; implement a change classification workflow that routes each proposed change through a materiality determination before any deployment; require a new authorization cycle (evaluation, validation, approval) for material changes; log all determinations — including determinations of non-materiality — in the model registry.", "steps": [ "Define a written material-change taxonomy that classifies changes across seven categories: (1) model retraining with new data; (2) model replacement with a different base model or architecture; (3) fine-tuning or additional training on existing model; (4) system prompt changes; (5) RAG corpus changes (domain expansion, new data sources, corpus version update); (6) guardrail changes (additions, removals, threshold modifications); (7) provider-version changes (API endpoint model version update, provider migration). For each category, define quantitative or qualitative materiality thresholds (e.g., prompt change adding a new capability domain = material; correcting a typo in an existing instruction = non-material).", "Implement a change classification gate as a mandatory step before any deployment pipeline can execute a change to a production model or its configuration. The gate requires the change proposer to submit a classification and a rationale; the classification is reviewed by a designated model risk reviewer before promotion.", "For material changes: require execution of the full LI-01 through LI-06 registration process for the new version, EV-01 pre-deployment evaluation, and re-validation (EV-06, EV-07) before deployment. For SR 26-2 supervised institutions, re-validation must be independent. Log the authorization decision with reviewer identity and timestamp.", "Implement provider-version change monitoring as an automated process: detect when a provider updates the model serving at an API endpoint (via behavioral regression testing — see BH-10) and automatically trigger a materiality determination review rather than requiring manual discovery." ], "anti_patterns": [ "Defining materiality only for model weight changes and excluding system prompt, RAG corpus, guardrail, and provider-version changes — these non-weight changes routinely produce material behavioral effects and are frequently the vector for unauthorized capability expansion.", "Requiring formal re-evaluation only when the change proposer self-classifies the change as material — self-classification without independent review creates a systematic bias toward non-material classifications.", "Implementing the material-change process for new models but grandfathering all existing production models — models already in production that undergo undocumented changes accumulate risk that is never formally assessed." ] }, "validation": { "design_check": [ "Confirm the material-change taxonomy covers all seven change categories and that quantitative or qualitative materiality thresholds are documented for each category in a written policy [ref:sr262_2026].", "Verify the change classification gate is integrated into all production deployment pipelines for the seven change categories — confirm that at least system prompt, RAG corpus, and guardrail changes are covered in addition to model weight changes [ref:eu_ai_act_2024].", "Review the material-change log for completeness: confirm that all non-material determinations are also logged with rationale, not just material determinations [ref:nist_ai_rmf_1_0]." ], "runtime_test": [ "Submit a system prompt change that adds a new capability domain (e.g., adding medical advice functionality to a general-purpose assistant) and verify the change classification gate correctly classifies it as material and routes it to an authorization cycle [ref:sr262_2026].", "Simulate a provider-version change by detecting a behavioral shift at an API endpoint (via BH-10 monitoring) and verify that the detection automatically triggers a materiality determination review rather than requiring manual discovery [ref:eu_ai_act_2024].", "For a RAG corpus update in production, confirm that the change was classified before deployment and that the classification decision is logged in the model registry with reviewer identity [ref:iso_42001_2023]." ], "evidence": [ "model:material-change-taxonomy — written policy document defining materiality thresholds for all seven change categories, version-controlled and approved [unverified]", "model:material-change-log — registry log of all change classification decisions including category, rationale, classification (material/non-material), reviewer identity, and timestamp [unverified]", "model:authorization-record — authorization record for each material change showing evaluation completion, validation result, approval, and effective date [unverified]" ] }, "lenses": { "engineering": { "summary": "The change classification gate must be implemented as a mandatory workflow step in all production deployment pipelines — not an honor system. Engineering must ensure that system prompt, RAG corpus, and guardrail configuration changes flow through the same gate as model weight changes.", "actions": [ "Integrate the change classification workflow into all deployment pipeline triggers for the seven change categories", "Implement automated provider-version change detection via behavioral regression tests that trigger materiality review when output distributions shift", "Build the material-change log as an immutable, append-only record in the model registry" ], "tools": [ "Feature flag management systems for prompt and guardrail change gating", "A/B testing infrastructure for behavioral regression detection", "workflow management systems for change classification review routing" ], "failure_signals": [ "System prompt changes are deployed via a feature flag pipeline with no model risk review", "RAG corpus updates are treated as data operations with no change classification step", "Provider-version changes are discovered only when behavioral anomalies appear in production monitoring" ] }, "evaluation": { "summary": "Evaluation teams must be notified when material changes are approved and must execute the required re-evaluation before the change goes live. The material-change taxonomy defines which evaluation controls are triggered — evaluators must confirm the scope is adequate.", "actions": [ "Define the evaluation scope triggered by each materiality category — not all material changes require the same evaluation depth", "Execute pre-deployment evaluation for each authorized material change before the change reaches production", "Flag any material change that was deployed without a pre-deployment evaluation record as an unauthorized change" ], "failure_signals": [ "Material changes are deployed without a corresponding evaluation record in the model registry", "Evaluation scope for prompt changes does not include behavioral regression testing against the prior approved behavior baseline" ] }, "red_team": { "summary": "Red teams should probe the change classification gate for bypass vectors: can a material change be deployed by splitting it into multiple non-material-appearing incremental changes? Can system prompt changes be deployed through a configuration path that bypasses the classification workflow?", "actions": [ "Attempt to deploy a material system prompt change by decomposing it into multiple small prompt edits that individually fall below materiality thresholds", "Identify all configuration paths that can modify system prompt, RAG corpus, or guardrail settings and confirm each is covered by the classification gate", "Test whether a provider-version change at the API endpoint triggers the materiality detection or is invisible to the monitoring system" ], "failure_signals": [ "Incremental prompt changes can accumulate to produce a material capability shift without triggering a classification review", "Configuration paths for prompt or guardrail changes bypass the deployment pipeline classification gate" ] }, "grc": { "summary": "SR 26-2 requires re-validation for material model changes. EU AI Act Art-9 requires risk management to address AI system changes throughout the lifecycle. LI-09 is the primary control demonstrating that material-change governance is operational — the material-change log is the primary evidence artifact for both SR 26-2 and Art-9 lifecycle requirements.", "actions": [ "Confirm the material-change taxonomy has been approved by the model risk committee and reflects SR 26-2 re-validation expectations for supervised institutions", "Verify that material-change logs are retained for the applicable regulatory period — SR 26-2 expects records supporting the full validation history", "Provide the material-change log to independent validators for review as part of each validation cycle" ], "metrics": [ "Percentage of material changes with completed authorization records before deployment (target: 100%)", "Number of material changes discovered post-deployment that were not classified before deployment (target: zero)" ], "failure_signals": [ "SR 26-2 validation cycle identifies changes deployed without authorization records", "Material-change taxonomy has not been updated to reflect changes in the deployed model system (e.g., addition of new capability types not in the original taxonomy)" ] }, "mlops": { "summary": "MLOps owns the operational implementation of the change classification gate and the provider-version change detection pipeline. For continuously-learning systems, MLOps must define what learning update magnitude constitutes a material change requiring re-evaluation.", "actions": [ "Operate the behavioral regression monitoring that detects provider-version changes and triggers materiality review", "Define and document the materiality threshold for continuously-learning model updates (e.g., behavioral shift greater than X% on held-out evaluation set = material)", "Maintain the change classification workflow and ensure all pipeline engineers understand which change types require classification before deployment" ], "failure_signals": [ "Provider-version change detected in production monitoring rather than via automated pre-deployment behavioral regression", "Continuously-learning system accumulates behavioral drift over weeks without triggering a materiality determination review" ] } }, "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "provision": "Art-9", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "mapping_fit": "partial", "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "notes": "EU AI Act Art-9 requires providers to implement a risk management system covering the full AI system lifecycle, including changes during the operational phase. LI-09's material-change determination process is the operational mechanism through which Art-9's lifecycle risk management requirement is implemented. Art-9(9) specifically requires risk management to address AI system modifications. Effective Dec 2, 2027 for standalone Annex III (Parliament-approved; Council adoption pending).", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "maturity": { "current": "none", "target": "defined", "notes": "Most organizations have IT change management covering code and infrastructure changes but do not apply it to system prompt, RAG corpus, or guardrail modifications. Achieving 'defined' requires a written taxonomy with thresholds, a mandatory classification gate, and an immutable change log." }, "coverage_note": "LI-09 covers the materiality determination and authorization gate. The specific re-evaluation and re-validation activities triggered for material changes are owned by EV-01 (pre-deployment evaluation), EV-06 (independent validation), and EV-07 (ongoing validation). Provider-version change detection is addressed in BH-10. For continuously-learning systems, the threshold between routine learning updates and material behavioral changes is defined in LI-09 and enforced by CR-03.", "capability_risk": { "capability_level": "low", "access_mode": "api", "autonomy": "supervised", "external_reach": false, "irreversibility": "partially-reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "moderate" }, "tiers": [ "us-regulated-banking", "continuously-learning", "frontier-capability" ], "implementers": [ "MLOps", "Model Governance", "ML Engineering", "Legal/Compliance" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE-4.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MANAGE-4.1 (MANAGE function) provides that post-deployment monitoring plans are implemented, including appeal and override, decommissioning, incident response, and change management. LI-09’s material-change determination and authorization gate implements the change-management component of post-deployment risk management.", "source_locator": { "section": "MANAGE-4", "clause": "MANAGE-4.1" }, "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art-9 requires that the risk management system for high-risk AI systems be ongoing and iterative, covering the full system lifecycle including modifications. LI-09 directly supports Art-9 by providing the operational mechanism for evaluating whether modifications to the AI system require a new risk assessment cycle. Art-9(9) specifically addresses risk management for AI system modifications.", "uncovered_portion": "Art-9 also requires systematic identification and analysis of all risks — LI-09 addresses only the change-triggered re-assessment requirement within Art-9's broader risk management mandate.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "6.3", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 Clause 6.3 (Planning of changes) requires changes to be planned and controlled. LI-09’s material-change taxonomy and authorization gate implement that discipline for models, prompts, and system configurations.", "source_locator": { "section": "Clause 6.3" }, "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "continuousvalidation", "fit": "partial", "rationale": "A material-change gate that forces a full re-evaluation before an updated model goes live operationalizes continuous validation against requirements across the lifecycle.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0008", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every planned change to a deployed AI model or its operating environment is assessed…\" enacts ATLAS mitigation AML.M0008 Validate AI Model; OpenCRE crosswalks this control’s OWASP AI Exchange concept (continuousvalidation) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "readiness": "approved", "thesis_type": "directive", "matrix_thesis": "The most common gap in AI governance programs is not a lack of evaluation for new models — it is the absence of any process for changes to deployed models. System prompts are updated as feature flags. RAG corpora are replaced as data engineering tasks. Provider versions change silently. None of these trigger the evaluation and validation cycles that would be required for a new model. LI-09 closes this gap by making materiality determination a mandatory, logged, independent-reviewed step for all seven change categories.", "meta": { "authored_on": "2026-06-26", "schema_version": "1.0.0" }, "canonical_id": "apeiris://model/controls/LI-09", "validation_objective": "Every planned change to a deployed AI model or its operating environment is assessed against a documented materiality threshold; changes that meet or exceed the threshold must complete a full re-evaluation and authorization cycle before the updated system goes live, and no material change may bypass this gate.", "evidence_required": [ "change_assessment_record documenting the change type (model update, prompt change, RAG corpus change, guardrail change, provider-version change), the materiality determination (material/non-material), and the criteria applied", "re_evaluation_authorization_record for each material change showing completed evaluation cycle, approver identity, approval timestamp, and the specific evaluation artifacts reviewed", "deployment_gate_block_log confirming that attempted deployments of material changes without a completed authorization record were rejected by the pipeline", "change_classification_policy_document defining materiality thresholds for each change type, reviewed and signed by model governance and risk owners" ], "machine_tests": [ "Attempt to deploy a model update tagged as 'material' in the change assessment record without a corresponding completed authorization record → assert deployment pipeline rejects the attempt and logs the missing authorization artifact", "Submit a prompt template change that exceeds the documented character-change or semantic-shift threshold → assert the system classifies the change as material and creates a re-evaluation task rather than permitting immediate deployment", "Deploy a non-material change (patch version bump below threshold) through the pipeline → assert the change proceeds without requiring a full re-evaluation cycle and that the materiality determination is logged", "Attempt to mark a change as non-material when it includes a provider model version increment listed in the materiality policy → assert the system overrides the classification and enforces re-evaluation" ], "human_review": [ "Review the materiality threshold definitions for each change category (model update, prompt, RAG corpus, guardrails, provider version) to confirm thresholds are specific, measurable, and reviewed against current risk appetite", "Assess a sample of recent change assessment records to verify that the materiality classification was applied consistently and that no borderline changes were classified as non-material without documented justification", "Verify that the re-evaluation authorization record for the most recent material change includes sign-off from both a technical reviewer and a risk/governance owner, not solely from the engineering team" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Defining materiality thresholds so broadly that nearly all changes qualify as non-material, effectively nullifying the gate for routine model updates and prompt changes", "Treating provider-hosted model version increments (e.g., GPT-4o to GPT-4o-mini swap) as non-material changes without assessing capability, safety, and behavioral differences", "Requiring re-evaluation documentation as a checkbox rather than a substantive review — filling in the form without actually running evaluation tests", "Allowing individual engineers to self-classify changes as non-material without independent review or audit trail, creating a bypass vector", "Not covering RAG corpus changes or guardrail modifications in the materiality policy — treating only the base model as subject to change governance" ], "update_status": "current", "layer_code": "LI" }, { "id": "LI-10", "layer": "LI", "plane": "control", "name": "Model Retirement and Archive Policy — End-of-Life Procedure, Evidence...", "plain": "When a model is taken out of service, a formal procedure ensures that dependent systems are identified and transitioned, evidence records are preserved for the required retention period, and the decommissioning is documented and authorized.", "threat": { "tags": [ "governance-gap", "stale-evidence", "accountability-gap" ], "desc": "Model retirement is the lifecycle phase most neglected by AI governance programs. Organizations routinely decommission models without: identifying dependent systems that will be silently broken or fall back to undefined behavior; preserving the evidence records (evaluation results, validation reports, audit logs) required by regulatory retention obligations; or documenting the decommissioning decision with appropriate authorization. Untracked model retirement creates regulatory exposure (missing evidence for historical audit periods), operational failure (dependent systems with no fallback), and accountability gaps (no record of who decided to retire the model or when). For continuously-learning or high-impact models, retirement without evidence preservation constitutes a loss of the only record of the model's behavior during the period it was in operation." }, "standard": [ { "id": "nist_rmf", "section": "GOVERN-1.7", "title": "Decommissioning and phase-out of AI systems" }, { "id": "iso_42001", "section": "A.6.2.6", "title": "AI system operation and monitoring" } ], "sources": [ { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/LI-10 Model Retirement and Archive Policy — End-of-Life Procedure, Evidence... control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary-paid", "status": "current", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/LI-10 Model Retirement and Archive Policy — End-of-Life Procedure, Evidence... control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "authority": "European Union — European Parliament and Council", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-26", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689", "license": "EU-public-sector-information", "status": "current", "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/LI-10 Model Retirement and Archive Policy — End-of-Life Procedure, Evidence... control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Require a formal model retirement request and authorization workflow; identify and transition dependent systems before decommissioning; preserve all evidence records for the applicable retention period in an accessible archive; document the decommissioning decision with approver identity and rationale; update the model registry entry to 'retired' status.", "steps": [ "Require a model retirement request that identifies: the model to be retired, the proposed retirement date, the reason for retirement, the replacement model or fallback (if any), and a list of all dependent systems identified via the model registry consumption map. Route the request to model risk governance for authorization.", "Before decommissioning, execute a dependent-system impact assessment: query the model registry for all services, applications, and downstream models that reference the retiring model ID. For each dependent system, require a documented transition plan (migration to replacement model, deployment of fallback, or planned service discontinuation) before the retirement date is confirmed.", "Archive all evidence records associated with the retiring model before decommissioning: model card, evaluation reports, validation reports, deployment logs, material-change logs, audit logs, and incident records. Ensure the archive is stored in a system with the applicable retention period (SR 26-2 expectation: 7 years for material models; EU AI Act Art-12: retention period defined in post-market monitoring plan) and is accessible to authorized parties including regulators.", "Update the model registry entry to 'retired' status with decommissioning date, authorizing approver, and archive location reference. Ensure 'retired' status prevents the artifact from being deployed without explicit re-authorization. Notify all registered consumers of the retirement." ], "anti_patterns": [ "Deleting the model artifact and registry entry when a model is decommissioned rather than marking it 'retired' and archiving — deletion destroys evidence needed for regulatory audits of historical periods.", "Retiring a model without identifying dependent systems first — silent decommissioning produces undefined fallback behavior in dependent systems, ranging from null-model errors to uncontrolled fallback to an unevaluated model.", "Archiving evidence records in a format or system that is inaccessible without the original tooling — evidence archived in a now-obsolete internal tool format cannot be produced to regulators." ] }, "validation": { "design_check": [ "Confirm the model retirement workflow requires an authorized approver, a dependent-system impact assessment, and a confirmed archive location before the retirement date is finalized [ref:sr262_2026].", "Verify the model registry supports a 'retired' status that prevents deployment without explicit re-authorization, and that the 'retired' entry retains all metadata including archive location and retirement approver [ref:iso_42001_2023].", "Confirm the evidence archive system has a documented retention policy meeting applicable regulatory minimums (7 years for SR 26-2 material models; EU AI Act post-market monitoring plan duration for high-risk systems) and is accessible to authorized regulators [ref:nist_ai_rmf_1_0]." ], "runtime_test": [ "Initiate a test model retirement and verify the dependent-system impact assessment correctly identifies all services registered as consumers of the model ID in the registry [ref:nist_ai_rmf_1_0].", "Attempt to deploy a 'retired' model artifact without re-authorization; confirm the deployment pipeline rejects the attempt with a 'retired status' error [ref:iso_42001_2023].", "Retrieve archived evidence records for a previously retired model and verify all required evidence types (evaluation report, validation report, deployment log) are present and readable in the archive [ref:sr262_2026]." ], "evidence": [ "model:retirement-authorization-record — signed retirement authorization record with approver identity, retirement date, reason, replacement or fallback reference, and dependent-system impact assessment [unverified]", "model:archive-manifest — manifest of archived evidence records for the retired model with retention period, archive location, and accessibility verification date [unverified]", "model:consumer-notification-log — log of notifications sent to all registered consumers of the retiring model before decommissioning [unverified]" ] }, "lenses": { "engineering": { "summary": "Engineering must implement the 'retired' status in the model registry as a deployment-blocking state, build the consumer registry map that enables dependent-system discovery, and ensure the evidence archive is stored in a durable, long-lived format that does not depend on current tooling.", "actions": [ "Implement 'retired' as a deployment-blocking registry status that requires explicit re-authorization for any subsequent deployment", "Build a consumer registry map that tracks all services, applications, and downstream models consuming each model ID — this is the data structure used for dependent-system impact assessment", "Design the evidence archive format using open, long-lived standards (e.g., JSON, PDF/A) rather than proprietary tool-dependent formats" ], "tools": [ "Object storage (S3, GCS) with lifecycle policies for long-term evidence retention", "model registry consumer dependency graph", "PDF/A or JSONL for long-lived archive formats" ], "failure_signals": [ "No consumer registry map — dependent systems discovered only after decommissioning causes outages", "Evidence archive stored in a format that requires the original authoring tool to read", "'Retired' status exists in the registry but does not block deployment pipeline" ] }, "evaluation": { "summary": "Evaluation teams must ensure evaluation reports for retiring models are included in the evidence archive in a readable format. These records are the primary evidence for demonstrating what the model's performance profile was during its operational period.", "actions": [ "Confirm that all evaluation run reports for the retiring model are included in the evidence archive before the retirement date", "Verify that evaluation records are stored in a format that can be read without the original evaluation platform" ], "failure_signals": [ "Evaluation reports exist only in the evaluation platform database — not exported to the durable archive before decommissioning", "Evaluation records cannot be retrieved for a retired model because the original evaluation system was decommissioned first" ] }, "red_team": { "summary": "Red teams should verify that retired models cannot be re-activated without authorization and that the evidence archive is not accessible to unauthorized parties — archived models with sensitive training data or behavioral characteristics are high-value targets.", "actions": [ "Verify that a 'retired' model cannot be deployed by reverting the registry status through a direct database write without triggering an authorization workflow", "Confirm that archived evidence records containing sensitive information (e.g., PII in audit logs, proprietary benchmark results) are subject to access control in the archive system" ], "failure_signals": [ "Registry 'retired' status can be reverted by anyone with database write access", "Evidence archive has no access control — any authenticated user can retrieve archived records for any model" ] }, "grc": { "summary": "Model retirement is a regulatory evidence event: the retirement record, archive manifest, and consumer notification log must be maintained for the applicable regulatory retention period. For SR 26-2 supervised institutions, retirement of a material model must be reported through the model risk governance process. EU AI Act Art-12 requires that logging records support post-market monitoring for the duration specified in the monitoring plan.", "actions": [ "Confirm that the retirement authorization workflow includes notification to the model risk committee for SR 26-2 material models", "Verify that the retention period applied to the evidence archive meets the regulatory minimum for all jurisdictions in which the model was deployed", "Confirm the archive is accessible to external auditors and regulators without requiring internal system access" ], "failure_signals": [ "Material model retirements not reported to the model risk committee", "Evidence archive retention period shorter than regulatory minimum", "Archive accessible only via internal tooling — cannot be provided to external auditors" ] }, "mlops": { "summary": "MLOps is responsible for executing the dependent-system impact assessment, coordinating the transition timeline with dependent system owners, and confirming all systems have transitioned before the decommissioning date. MLOps also owns the consumer notification process.", "actions": [ "Query the consumer registry map at retirement request time to produce the complete list of dependent systems", "Coordinate transition timelines with dependent system owners and confirm readiness before confirming the retirement date", "Send consumer notifications with adequate lead time — not less than the defined minimum notice period for planned retirements" ], "failure_signals": [ "Dependent-system discovery is manual rather than queried from the consumer registry map", "Consumer notifications sent after retirement date is confirmed rather than before", "Transition confirmation not obtained from dependent system owners before decommissioning" ] } }, "maturity": { "current": "none", "target": "defined", "notes": "Model retirement is the most commonly ungoverned lifecycle phase in enterprise AI programs. Most organizations retire models informally by stopping deployments without retirement workflows, dependent-system impact assessment, or evidence archiving. Achieving 'defined' requires an authorized retirement workflow and a durable evidence archive." }, "coverage_note": "LI-10 covers model retirement at the artifact and registry level. Evidence retention requirements for specific evidence types (evaluation reports, audit logs) are specified in the producing controls (EV-01, BH-05, CR-01). Long-term evidence archiving infrastructure is a cross-domain concern; LI-10 specifies the model governance requirements for what must be archived and for how long. Data deletion obligations arising from training data personal data rights (applicable when the training data is deleted but the model artifact must be retained) are a tension addressed in the TG layer.", "capability_risk": { "capability_level": "low", "access_mode": "api", "autonomy": "supervised", "external_reach": false, "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "tiers": [ "frontier-capability" ], "implementers": [ "MLOps", "Model Governance", "Platform Engineering", "Legal/Compliance" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.7", "fit": "direct", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-1.7 (GOVERN function) provides that processes are in place for decommissioning and phasing out AI systems safely. LI-10 directly implements this subcategory by requiring authorized retirement decisions, evidence archiving, and dependent-system impact assessment before decommissioning.", "source_locator": { "subcategory": "GOVERN-1.7" }, "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) covers the operation stage of the AI system life cycle, under which controlled end-of-life handling falls. LI-10’s authorized retirement workflow and archive policy give that stage a documented exit.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-12", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art-12 requires high-risk AI system providers to maintain logging capabilities and records for the post-market monitoring period. LI-10's evidence archiving requirement ensures that Art-12 records (including logs, evaluation reports, and deployment records) are preserved after the model is retired rather than deleted. LI-10 does not independently specify Art-12's logging content requirements — those are addressed in BH-05.", "uncovered_portion": "Art-12 addresses the content and duration of logging during active deployment; LI-10 addresses evidence preservation after retirement. Active logging during deployment is addressed in BH-05.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" } ], "readiness": "approved", "thesis_type": "corrective", "matrix_thesis": "Model retirement without evidence preservation is a destruction of the historical record that regulators, auditors, and affected parties rely on. Organizations that delete model artifacts, evaluation records, and audit logs when retiring models do so out of storage cost optimization rather than compliance design — and discover their error when regulators ask for records from a period covered by the retired model. LI-10 treats evidence preservation at retirement as an obligation, not an option.", "meta": { "authored_on": "2026-06-26", "schema_version": "1.0.0" }, "canonical_id": "apeiris://model/controls/LI-10", "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "provision": "Art-12", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "mapping_fit": "partial", "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "notes": "Art-12 requires providers of high-risk AI systems to design systems to automatically record events ('logs') including periods of use, reference databases against which the system has been checked, input data, and information to identify the persons responsible. Minimum 6-month log retention unless Union or national law specifies otherwise. Effective Dec 2, 2027 for standalone Annex III systems (Parliament-approved; Council adoption pending as of 2026-06-26). Product-embedded: Aug 2, 2028.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "When a model is retired from service, a formal decommissioning record exists showing that all dependent systems were identified and transitioned prior to retirement, evidence records are archived for the required retention period, and the retirement was explicitly authorized by a named governance owner.", "evidence_required": [ "decommissioning_authorization_record with model identifier, retirement date, authorizing owner identity, and documented confirmation that dependent system transition is complete", "dependency_transition_log listing each system or integration that relied on the retired model, the transition action taken (migration to successor, decommission, or manual override), and confirmation timestamp", "evidence_archive_record confirming that model evaluation artifacts, training provenance records, and decision audit logs have been transferred to long-term retention storage with the expected retention expiry date", "post_retirement_access_audit_log confirming that the retired model endpoint was disabled and no inference requests were served after the retirement date" ], "machine_tests": [ "Issue an inference request to a model endpoint that has been marked as retired in the registry → assert the endpoint returns a 410 Gone or equivalent rejection and does not serve model output", "Query the dependency registry for a recently retired model → assert all previously registered dependent systems have a documented transition status (migrated, decommissioned, or manually acknowledged)", "Retrieve the evidence archive record for a retired model → assert training provenance records and evaluation artifacts are present in the archive storage and have a retention expiry date set per policy", "Attempt to create a new deployment using a model identifier that has been marked retired → assert the pipeline rejects the request and references the retirement record" ], "human_review": [ "Review the dependency identification process for the most recent retirement to confirm all consumers of the retired model were identified before decommissioning began, not discovered after service disruption", "Verify that the evidence retention period applied matches the required retention schedule for the regulatory frameworks governing the model's use case (e.g., SR 26-2 model risk documentation, EU AI Act technical documentation)", "Assess whether the retirement authorization record was signed by a governance owner with appropriate authority, and that the authorization was not self-granted by the team that operated the model" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Retiring a model by simply disabling the endpoint without first identifying and transitioning dependent systems, causing silent failures in downstream applications", "Deleting model training artifacts, evaluation records, and audit logs upon retirement rather than transferring them to long-term retention storage, destroying evidence needed for post-deployment audits", "Treating model retirement as a purely technical task executed by MLOps without formal authorization from a governance or risk owner", "Failing to maintain a dependency registry that maps models to their consumer systems, making it impossible to identify impact scope before retirement", "Not setting a defined retention expiry date on archived evidence records, resulting in indefinite storage without review or eventual uncontrolled deletion" ], "update_status": "current", "layer_code": "LI" }, { "id": "TG-01", "layer": "TG", "plane": "data", "name": "Training Data Quality Gates", "plain": "Enforce automated schema validation, completeness checks, and provenance verification before any training run is permitted to proceed.", "threat": { "tags": [ "MR-DEV", "LLM04:2025", "AML.T0020" ], "desc": "Corrupted, incomplete, or unverifiable training data produces models with systematic failure modes that are invisible at inference time. Quality gate bypass enables adversarial data injection and introduces silent degradation that persists into deployed model behavior." }, "standard": [ "ISO/IEC 42001:2023 A.7.4", "EU AI Act Art. 10(2)", "NIST AI RMF MAP 2.3", "NIST AI RMF GOVERN 6.1" ], "sources": [ { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/TG-01 Training Data Quality Gates control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_art10", "title": "EU AI Act — Article 10: Data and Data Governance", "authority": "European Parliament and Council", "source_type": "regulation", "license": "public", "artifact_hash": null, "status": "current", "retrieved_on": "2026-06-26", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act — Article 10: Data and Data Governance requirements informing the apeiris://model/controls/TG-01 Training Data Quality Gates control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "NIST", "source_type": "voluntary-standard", "license": "public_domain", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/TG-01 Training Data Quality Gates control.", "reviewed_on": "2026-07-01" }, { "id": "biml_llm_ara", "title": "BIML — Architectural Risk Analysis of LLMs (2024)", "authority": "Berryville Institute of Machine Learning", "source_type": "research-institute", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-24", "retrieved_on": "2026-07-08", "canonical_url": "https://berryvilleiml.com/docs/BIML-LLM24.pdf", "relationship": "supporting_guidance", "note": "BIML data-trustworthiness risks inform training-data quality gates." } ], "implementation": { "pattern": "Gate training pipeline execution behind a multi-stage data quality harness that sequentially validates schema conformance, completeness thresholds, provenance chain integrity, and statistical sanity. Failures produce a signed rejection report; no training job proceeds without a signed quality attestation.", "steps": [ "Define schema contracts (column types, cardinality bounds, null-rate ceilings) for every input dataset and store them in a versioned schema registry.", "Implement completeness checks: minimum record counts per class/subgroup, maximum null/missing-value rates, temporal coverage windows.", "Validate provenance: every dataset shard must reference a signed provenance record (source, collection date, consent basis, processing lineage).", "Run statistical sanity checks: label distribution drift vs. baseline, feature range violations, duplicate-rate thresholds.", "Emit a signed quality attestation artifact for gate-passing datasets; block pipeline and page on-call for gate failures.", "Archive quality gate reports alongside training run metadata in the experiment tracker.", "Integrate gate execution into CI/CD so no training job is submitted without a valid attestation." ], "anti_patterns": [ "Skipping schema validation for 'trusted' internal data sources — all sources must pass.", "Soft-failing quality gates that log warnings but allow training to proceed.", "Defining quality thresholds once and never revisiting them as data pipelines evolve.", "Storing quality attestations in mutable locations where they can be overwritten." ] }, "validation": { "design_check": [ "Schema registry exists and is versioned; all training datasets reference a schema entry. [ref:iso_42001_2023]", "Quality gate is a hard blocker in the training pipeline with cryptographic attestation output. [ref:eu_ai_act_art10]", "Completeness thresholds are documented per dataset and reviewed at least annually. [ref:nist_ai_rmf_1_0]" ], "runtime_test": [ "Inject a dataset with 30% null values in a required field; confirm gate blocks training and issues rejection report. [ref:iso_42001_2023]", "Introduce a schema type mismatch in a test shard; confirm detection and pipeline halt. [ref:eu_ai_act_art10]", "Replay a historical dataset known to have class imbalance beyond threshold; confirm gate failure. [unverified]" ], "evidence": [ "model:signed-quality-attestation-records-for-a — Signed quality attestation records for all completed training runs, retained for audit. [ref:eu_ai_act_art10]", "model:gate-rejection-reports-with-root-cause-c — Gate rejection reports with root-cause classification and remediation timestamps. [ref:iso_42001_2023]", "model:schema-registry-audit-log-showing-versio — Schema registry audit log showing version history and approver identities. [ref:nist_ai_rmf_1_0]" ] }, "monitoring_schema": { "metrics": [ { "name": "data_null_rate", "description": "Fraction of null or missing values per required column across the training dataset", "unit": "ratio", "threshold": { "warn": 0.02, "block": 0.05 }, "window_context": "computed over each training dataset snapshot before training run submission", "metric_id": "data_null_rate", "metric_type": "performance", "measure": "null-value-rate", "population": "all-training-dataset-records", "comparison": { "operator": "greater-than", "value": 0.02, "window": "per-training-run", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "schema_violation_count", "description": "Number of records failing schema type or range constraints", "unit": "count", "threshold": { "warn": 1, "block": 10 }, "window_context": "per training shard, evaluated at gate execution time", "metric_id": "schema_violation_count", "metric_type": "performance", "measure": "constraint-violation-count", "population": "all-training-dataset-records", "comparison": { "operator": "greater-than", "value": 1, "window": "per-training-run", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "provenance_coverage_rate", "description": "Fraction of training records with a valid, signed provenance chain", "unit": "ratio", "threshold": { "warn": 0.99, "block": 0.95 }, "window_context": "per training dataset, evaluated at gate execution time", "metric_id": "provenance_coverage_rate", "metric_type": "performance", "measure": "coverage-ratio", "population": "all-training-dataset-records", "comparison": { "operator": "greater-than", "value": 0.99, "window": "per-training-run", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "label_distribution_kl_divergence", "description": "KL divergence of training label distribution vs. approved baseline", "unit": "nats", "threshold": { "warn": 0.05, "block": 0.15 }, "window_context": "per training run", "metric_id": "label_distribution_kl_divergence", "metric_type": "performance", "measure": "kullback-leibler-divergence", "population": "all-training-dataset-records", "comparison": { "operator": "greater-than", "value": 0.05, "window": "per-training-run", "evaluation_mode": "batch" }, "severity": "medium" } ], "sampling_rate": "100% — all training datasets evaluated; no sampling", "alert_routing": "on-call ML platform team + model owner", "window_context": "rolling-7d" }, "lenses": { "engineering": "Implement quality gate as a composable pipeline stage (e.g., Great Expectations, custom harness) with output artifacts consumed by the experiment tracker. Schema registry should be GitOps-managed.", "evaluation": "Quality gate failures are evaluation signals; track gate pass/fail rates over time as a leading indicator of data pipeline health and model quality risk.", "red_team": "Attempt to bypass the gate by manipulating provenance metadata, submitting datasets under alternate pipeline paths, or exploiting race conditions in the attestation workflow.", "grc": "Quality attestations constitute audit evidence for EU AI Act Art. 10 data governance obligations and ISO 42001 §8.4 compliance. Retain for the full post-deployment audit window.", "mlops": "Integrate gate into ML CI/CD as a blocking step; surface gate metrics on the MLOps observability dashboard; alert on rising null rates as a leading indicator of upstream data-pipeline drift." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers pre-training data validation only; inference-time data quality is addressed in the BH layer. Does not cover feature store validation for streaming features.", "obligations": [ { "id": "eu_ai_act_art10_2", "text": "EU AI Act Art. 10(2) — high-risk AI systems must use training data that meets quality criteria including relevance, representativeness, and freedom from errors", "jurisdiction": [ "eu" ], "binding": true, "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "legal_status": "enacted", "provision": "Article 10", "effective_from": "2027-08-02" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-10", "mapping_fit": "partial", "notes": "Art-10 requires that training, validation and testing data for high-risk AI systems meet quality criteria including relevance, representativeness, freedom from errors and appropriate privacy protections.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MAP-2.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MAP-2.3 (MAP function) provides that scientific integrity and TEVV considerations, including data collection and selection, are identified and documented. TG-01’s automated quality gates enforce documented data-selection and quality standards at pipeline time, supporting scientific integrity of the training process.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.7.4", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.7.4 (Quality of data) requires ensuring that data used for AI systems meets defined quality criteria. TG-01’s schema validation, completeness checks, and quality gates enforce those criteria at pipeline time.", "reviewed_on": "2026-06-26", "source_version": "2023", "source_locator": { "section": "Annex A", "clause": "A.7.4" }, "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-10", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Quality gate operationalizes Art. 10(2) data governance requirements for high-risk AI", "uncovered_portion": "Art. 10(3) examination for biases is covered by TG-02", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. IV", "fit": "direct", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. IV (Model Development and Model Use) describes assessment and documentation of the suitability and quality of data used in model development. TG-01's automated quality gates operationalize that expectation as blocking pipeline checks. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "source_locator": { "section": "Sec. IV (Model Development and Model Use)" }, "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aisvs", "requirement_id": "C1.3", "fit": "direct", "direction": "control-supports-requirement", "rationale": "OWASP AISVS C1.3 (Training Data Quality and Security Assurance) requires quality and integrity checks on training data before use. TG-01's schema validation, completeness checks, and signed provenance gates implement those requirements as blocking pipeline controls.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "chapter": "C1.3", "chapter_name": "Training Data Quality and Security Assurance" }, "normative_force": "voluntary-standard", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "llm10", "requirement_id": "LLM04:2025", "fit": "partial", "direction": "control-mitigates-risk", "rationale": "Quality gates reduce poisoning attack surface by enforcing provenance and integrity checks", "uncovered_portion": "Active adversarial poisoning detection is addressed in TG-04", "reviewed_on": "2026-06-26", "source_version": "2025", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "aicm", "requirement_id": "DSP-23", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Data quality gates are a core AICM data management control", "reviewed_on": "2026-06-26", "source_version": "1.1", "source_locator": { "section": "CSA AI Controls Matrix v1.1", "clause": "DM-01" }, "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0020", "fit": "partial", "direction": "control-mitigates-risk", "rationale": "Quality gates reduce the effectiveness of poisoning by requiring signed provenance chains", "uncovered_portion": "Cryptographic integrity of individual shards is covered in TG-04", "reviewed_on": "2026-06-26", "source_version": "v2026.06", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "owasp_aitg", "requirement_id": "AITG-DAT-03", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AITG-DAT-03 (Testing for Dataset Diversity and Coverage) evaluates whether training data adequately covers the intended input space. TG-01's schema validation, completeness checks, and quality gates produce the dataset quality evidence this test consumes, though coverage analysis itself is TG-02's focus.", "source_locator": { "test_id": "AITG-DAT-03", "test_name": "Testing for Dataset Diversity and Coverage" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "dataqualitycontrol", "fit": "direct", "rationale": "Blocking training runs until the dataset passes schema, completeness, and provenance checks is precisely AI Exchange's control-training-data-quality control.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0007", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"No training run may be initiated unless the designated training dataset has passed…\" enacts ATLAS mitigation AML.M0007 Sanitize Training Data; complements the control’s existing technique mapping AML.T0020 (defends_against) — OpenCRE crosswalks the AI Exchange concept (dataqualitycontrol) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "profiles": [ { "id": "high-impact-decision", "note": "Mandatory; stricter completeness thresholds required for protected-class subgroups" }, { "id": "eu-high-risk", "note": "Mandatory; quality attestation must be included in technical documentation per EU AI Act Annex IV" }, { "id": "us-regulated-banking", "note": "Required per SR 26-2; gate evidence must be retained per model risk management policy" }, { "id": "continuously-learning", "note": "Apply gate to each incremental data batch, not only the initial training corpus" } ], "enforcement_point": "training-pipeline-entry", "canonical_id": "apeiris://model/controls/TG-01", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "validation_objective": "No training run may be initiated unless the designated training dataset has passed automated schema validation, completeness checks, and provenance verification in the current pipeline run; all gate results must be logged with pass/fail status and linked to the training job record.", "evidence_required": [ "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead" ], "machine_tests": [ "Submit a training dataset with 15% null values in a field marked as required in the schema → assert the quality gate rejects the dataset and blocks the training job before compute is allocated", "Modify a training shard's content after computing its integrity hash and attempt to initiate training → assert the provenance verification step detects the hash mismatch and blocks the run", "Submit a training dataset missing the required provenance record (no source identifier or chain-of-custody reference) → assert the pipeline rejects the training job with an error identifying the missing provenance artifact", "Submit a valid training dataset that passes all quality gates → assert the gate report is generated and linked to the training job record with a 'pass' status for all three gate categories" ], "human_review": [ "Review the quality threshold configuration to confirm that completeness thresholds, schema requirements, and provenance checks are calibrated to the specific risk level and use case of the model being trained — not set to generic defaults", "Assess a sample of training job records to verify that quality gate reports are consistently linked to the job and that no training runs exist without an associated gate result", "Verify that the quality gate configuration is version-controlled and that threshold changes require documented review approval, preventing silent relaxation of standards" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Running quality checks as post-hoc monitoring reports rather than blocking gates — allowing training jobs to proceed on low-quality data and relying on evaluation to catch problems later", "Applying the same quality thresholds to all datasets regardless of the model's risk level or deployment context, failing to enforce stricter standards for high-impact or regulated use cases", "Checking schema structure without verifying data provenance — a structurally valid dataset can still contain poisoned or rights-violated data if chain-of-custody is not verified", "Treating quality gate results as one-time checks at initial dataset registration rather than re-running them before each training job, allowing stale or modified data to enter training pipelines", "Storing quality gate results separately from training job records, making it impossible to reconstruct the quality state of the data used in a specific training run during audit" ], "update_status": "current", "layer_code": "TG" }, { "id": "TG-02", "layer": "TG", "plane": "data", "name": "Bias and Representativeness Assessment", "plain": "Conduct subgroup and intersectional fairness analysis on training data to document population coverage, identify underrepresentation, and establish bias baselines before model training and after each data refresh.", "threat": { "tags": [ "MR-DEV", "MR-VAL", "EU-AIA-AnnexIII" ], "desc": "Undetected demographic or intersectional underrepresentation in training data produces models with disparate error rates across protected groups, creating legal exposure and systematic harm at scale that is difficult to remediate post-deployment." }, "standard": [ "EU AI Act Art. 10(2)(f) and Art. 10(3)", "ISO/IEC 42001:2023 A.7.4", "NIST AI RMF MEASURE 2.11", "SR 26-2 Sec. IV (Model Development and Model Use)" ], "sources": [ { "id": "eu_ai_act_art10", "title": "EU AI Act — Article 10: Data and Data Governance", "authority": "European Parliament and Council", "source_type": "regulation", "license": "public", "artifact_hash": null, "status": "current", "retrieved_on": "2026-06-26", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act — Article 10: Data and Data Governance requirements informing the apeiris://model/controls/TG-02 Bias and Representativeness Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "NIST", "source_type": "voluntary-standard", "license": "public_domain", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/TG-02 Bias and Representativeness Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/TG-02 Bias and Representativeness Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "title": "SR 26-2: Revised Guidance on Model Risk Management", "authority": "Federal Reserve Board", "source_type": "supervisory-guidance", "license": "public", "artifact_hash": null, "supersedes": [ "SR 11-7", "SR 21-8" ], "status": "current", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/TG-02 Bias and Representativeness Assessment control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Run automated subgroup representativeness analysis at dataset finalization and produce a Bias Assessment Report (BAR) documenting population coverage, intersectional gaps, and approved mitigation actions. BAR must be signed by the responsible model owner before training proceeds.", "steps": [ "Map training dataset schema to demographic and protected-class attributes; document which attributes are available, proxied, or absent.", "Compute per-subgroup record counts and compare against target-population proportions derived from authoritative census or domain reference data.", "Perform intersectional analysis across combinations of protected attributes (e.g., gender × race, age × disability status) to surface compound underrepresentation.", "Flag subgroups below minimum representation threshold and document whether the gap is addressable by resampling, data augmentation, or requires a model-card coverage limitation.", "Produce a signed Bias Assessment Report with subgroup coverage statistics, identified gaps, approved mitigations, and residual limitations.", "Store BAR in the model card system and reference it in the training run metadata.", "Re-run assessment whenever training data is refreshed or resampled." ], "anti_patterns": [ "Using proxy variables (e.g., zip code, surname) as substitutes for protected attributes without documenting proxy validity and accuracy.", "Assessing representativeness only at the aggregate level and missing intersectional gaps.", "Treating resampling as a complete mitigation without validating that augmented data preserves real-world distributional properties.", "Signing off on the BAR before intersectional analysis is complete." ] }, "validation": { "design_check": [ "BAR template includes per-subgroup counts, target-population comparisons, intersectional analysis, and residual limitations. [ref:eu_ai_act_art10]", "Process requires sign-off from model owner before training proceeds; sign-off is recorded in the experiment tracker. [ref:iso_42001_2023]", "Minimum representation thresholds are defined per deployment domain and reviewed at least annually. [ref:nist_ai_rmf_1_0]" ], "runtime_test": [ "Inject a dataset with an underrepresented subgroup (<1% of records for a 15%-prevalent population); confirm BAR flags the gap. [ref:eu_ai_act_art10]", "Verify that intersectional analysis runs and produces non-null output for all defined attribute combinations. [ref:nist_ai_rmf_1_0]", "Confirm training pipeline is blocked when BAR is absent or unsigned. [ref:iso_42001_2023]" ], "evidence": [ "model:signed-bias-assessment-reports-for-each — Signed Bias Assessment Reports for each training run, retained in model documentation repository. [ref:eu_ai_act_art10]", "model:subgroup-representativeness-dashboards-s — Subgroup representativeness dashboards showing coverage over time and across model versions. [ref:nist_ai_rmf_1_0]", "model:audit-log-of-bar-approvals-with-approver — Audit log of BAR approvals with approver identity and timestamp. [ref:iso_42001_2023]" ] }, "monitoring_schema": { "metrics": [ { "name": "subgroup_representation_gap", "description": "Maximum absolute difference between observed subgroup proportion in training data and target-population proportion", "unit": "percentage_points", "threshold": { "warn": 5, "block": 15 }, "window_context": "computed at dataset finalization; re-evaluated on each data refresh", "metric_id": "subgroup_representation_gap", "metric_type": "performance", "measure": "gap-measure", "population": "all-training-dataset-records", "comparison": { "operator": "greater-than", "value": 5, "window": "per-training-run", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "intersectional_minimum_count", "description": "Minimum record count across all defined intersectional subgroup cells", "unit": "count", "threshold": { "warn": 100, "block": 30 }, "window_context": "per training dataset snapshot", "metric_id": "intersectional_minimum_count", "metric_type": "performance", "measure": "event-count", "population": "all-training-dataset-records", "comparison": { "operator": "greater-than", "value": 100, "window": "per-training-run", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "bias_drift_delta", "description": "Change in per-subgroup error rate disparity between consecutive model versions", "unit": "percentage_points", "threshold": { "warn": 2, "block": 5 }, "window_context": "post-evaluation, compared to prior production model version", "metric_id": "bias_drift_delta", "metric_type": "performance", "measure": "score-delta", "population": "all-training-dataset-records", "comparison": { "operator": "greater-than", "value": 2, "window": "per-training-run", "evaluation_mode": "batch" }, "severity": "medium" } ], "sampling_rate": "100% of training dataset; no sampling for representativeness analysis", "alert_routing": "model owner + responsible AI / fairness team", "window_context": "rolling-7d" }, "lenses": { "engineering": "Integrate representativeness analysis as a pipeline step post-data-assembly; use fairness libraries (e.g., Fairlearn, AIF360) with pinned versions. Output structured BAR JSON consumed by model card tooling.", "evaluation": "BAR is a prerequisite artifact for the independent validation gate (EV-01). Evaluators must verify BAR completeness and that flagged gaps have approved mitigations, not just that the document exists.", "red_team": "Probe whether intersectional underrepresentation escapes detection by testing model performance on low-count intersectional groups not explicitly listed in the BAR. Attempt to manipulate population reference data used as the representativeness baseline.", "grc": "BAR is required technical documentation for EU AI Act Art. 10(3) and is an audit artifact for SR 26-2 fair-lending and model risk reviews. Ensure retention policy covers the post-deployment audit window.", "mlops": "Track subgroup representation as a dataset version attribute in the feature store / experiment tracker. Alert on representation drift between successive dataset builds." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers training-data representativeness. Post-deployment subgroup performance monitoring is addressed in BH-05 and CR-01. Does not cover fairness of synthetic data augmentation — that requires separate treatment.", "obligations": [ { "id": "eu_ai_act_art10_3", "text": "EU AI Act Art. 10(3) — high-risk AI systems must examine training data for possible biases that may affect fundamental rights or lead to discrimination", "jurisdiction": [ "eu" ], "binding": true, "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "legal_status": "enacted", "provision": "Article 10", "effective_from": "2027-08-02" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-10", "mapping_fit": "partial", "notes": "Art-10 requires that training, validation and testing data for high-risk AI systems meet quality criteria including relevance, representativeness, freedom from errors and appropriate privacy protections.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.11", "fit": "direct", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.11 (MEASURE function) provides that fairness and bias are evaluated and results are documented. TG-02’s subgroup and intersectional representativeness analysis produces the documented bias evaluation this subcategory requires, applied at the training-data stage.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "subcategory": "MEASURE-2.11" }, "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.7.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.7.4 (Quality of data) includes ensuring data is appropriate for its purpose; representativeness across populations is a quality dimension. TG-02’s subgroup representativeness analysis documents that assessment.", "reviewed_on": "2026-06-26", "source_version": "2023", "source_locator": { "section": "Annex A", "clause": "A.7.4" }, "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-10", "fit": "direct", "direction": "control-supports-requirement", "rationale": "BAR directly implements Art. 10(3) bias examination mandate for high-risk AI", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "source_locator": { "section": "Chapter III, Section 2 — Requirements for high-risk AI systems", "clause": "Article 10" }, "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. IV", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. IV (Model Development and Model Use) describes documenting the characteristics and limitations of development data, including whether it is representative of the intended use. TG-02's subgroup representativeness analysis provides that evidence for supervised institutions. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "source_locator": { "section": "Sec. IV (Model Development and Model Use)" }, "uncovered_portion": "Sec. IV addresses development practice broadly — design, methodology, and data suitability — beyond the representativeness assessment TG-02 provides.", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aisvs", "requirement_id": "C1.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OWASP AISVS C1.3 (Training Data Quality and Security Assurance) includes evaluating data and models for bias patterns (req 1.3.3). TG-02's subgroup and intersectional representativeness analysis supplies that assessment for training data.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "chapter": "C1.3", "chapter_name": "Training Data Quality and Security Assurance" }, "normative_force": "voluntary-standard", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "llm10", "requirement_id": "LLM04:2025", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Representativeness gaps can be exploited to skew model behavior; bias assessment reduces attack surface", "reviewed_on": "2026-06-26", "source_version": "2025", "source_locator": { "section": "OWASP LLM Top 10 2025", "clause": "LLM04:2025" }, "uncovered_portion": "LLM04:2025 Data and Model Poisoning additionally covers fine-tuning data poisoning, reward model manipulation, and inference-time retrieval corpus poisoning.", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "aicm", "requirement_id": "GRC-11", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CSA AICM GRC-11 covers assessment of AI bias and fairness risk within the governance program. TG-02’s subgroup and intersectional representativeness analysis is the training-data instantiation of that assessment.", "reviewed_on": "2026-06-26", "source_version": "1.1", "source_locator": { "control_id": "GRC-11" }, "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0020", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Representativeness analysis can surface adversarially injected demographic skew in training data", "uncovered_portion": "Active poisoning detection is TG-04", "reviewed_on": "2026-06-26", "source_version": "v2026.06", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "owasp_aitg", "requirement_id": "AITG-DAT-03", "fit": "direct", "direction": "control-supports-requirement", "rationale": "AITG-DAT-03 (Testing for Dataset Diversity and Coverage) evaluates dataset diversity and population coverage. TG-02's subgroup and intersectional representativeness analysis is a direct implementation of the assessment this test performs.", "source_locator": { "test_id": "AITG-DAT-03", "test_name": "Testing for Dataset Diversity and Coverage" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "dataqualitycontrol", "fit": "supporting", "rationale": "Assessing training-data representativeness and subgroup coverage is a training-data-quality dimension the data-quality-control control governs.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "unwantedbiastesting", "fit": "partial", "rationale": "Establishing training-data bias baselines is the upstream precursor to the model-level unwanted-bias testing the AI Exchange control requires.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0007", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Before each training run and after each data refresh, a documented subgroup and…\" enacts ATLAS mitigation AML.M0007 Sanitize Training Data; complements the control’s existing technique mapping AML.T0020 (defends_against) — OpenCRE crosswalks the AI Exchange concept (dataqualitycontrol) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0008", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Before each training run and after each data refresh, a documented subgroup and…\" enacts ATLAS mitigation AML.M0008 Validate AI Model; complements the control’s existing technique mapping AML.T0020 (defends_against) — OpenCRE crosswalks the AI Exchange concept (unwantedbiastesting) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "profiles": [ { "id": "high-impact-decision", "note": "Mandatory; intersectional analysis required across all legally protected attributes relevant to the decision domain" }, { "id": "eu-high-risk", "note": "Mandatory; BAR must be included in technical documentation per EU AI Act Annex IV §2(c)" }, { "id": "us-regulated-banking", "note": "Required for credit/lending models per ECOA/Reg B; coordinate with fair-lending counsel on proxy analysis" }, { "id": "general-predictive-ml", "note": "Strongly recommended; minimum: per-class representation check against target population" }, { "id": "generative-ai", "note": "Apply to instruction-tuning and RLHF datasets; representativeness analysis must cover dialogue styles and demographic representation in preference data" } ], "enforcement_point": "dataset-finalization", "canonical_id": "apeiris://model/controls/TG-02", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "validation_objective": "Before each training run and after each data refresh, a documented subgroup and intersectional fairness analysis is completed for the training dataset, producing a bias baseline report that identifies population coverage gaps and subgroup representation rates; this report must be reviewed and accepted before training proceeds.", "evidence_required": [ "bias_assessment_report containing subgroup representation rates across all demographic dimensions relevant to the model's use case, intersectional analysis results, identification of underrepresented populations, and comparison to the prior baseline where applicable", "data_refresh_trigger_record showing that a new bias assessment was initiated whenever the training dataset was updated, not only at initial training", "bias_baseline_acceptance_record with reviewer identity, acceptance timestamp, and documented acknowledgment of any known representation gaps and their accepted risk level", "subgroup_definition_document specifying which demographic dimensions and proxy features were analyzed, reviewed against the model's deployment context and affected populations" ], "machine_tests": [ "Ingest a training dataset with a documented 3:1 male-to-female ratio in a classification task relevant to gender → assert the bias assessment report flags the imbalance and quantifies the representation gap against a target distribution", "Refresh the training dataset by adding 10,000 new records and initiate a training job without triggering a new bias assessment → assert the pipeline requires a new bias assessment before the training run can proceed", "Submit a training dataset with no intersectional analysis capability configured (e.g., single-dimension only) for a model requiring multi-attribute fairness coverage → assert the assessment tool flags the configuration gap and does not issue a passing report", "Retrieve the bias assessment report for the current production model → assert the report exists, is linked to the training job record, and was accepted by a named reviewer" ], "human_review": [ "Review the subgroup definition document to confirm that demographic dimensions and proxy features analyzed are appropriate for the model's actual affected populations and use case, not selected for convenience of measurement", "Assess whether representation gaps documented in the bias baseline report were accepted with substantive risk justification or whether the acceptance record is a routine sign-off without documented consideration of impact on affected groups", "Verify that the bias assessment methodology accounts for intersectional effects — e.g., disparate impacts on individuals who are members of multiple underrepresented groups simultaneously — and not only single-attribute subgroup analysis" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Conducting bias assessment only at initial model training and not re-running it when training data is refreshed or augmented, allowing representation drift to go undetected", "Analyzing only single demographic dimensions in isolation rather than intersectional combinations, missing disparate impacts on populations defined by multiple attributes", "Treating the bias assessment as a compliance checkbox that is reviewed and accepted without substantive analysis of impact on affected populations or documented justification for accepting known gaps", "Defining subgroups based solely on features that are easy to measure in the existing dataset rather than the demographic dimensions actually relevant to the model's deployment context and affected populations", "Using representation rate as the only metric without assessing whether subgroup representation translates to equivalent model performance across groups" ], "update_status": "current", "layer_code": "TG" }, { "id": "TG-03", "layer": "TG", "plane": "data", "name": "Data Rights, Lawful Authority and Permitted Use", "plain": "Establish and document the specific legal basis, consent mechanism, contractual right, or statutory authority for each training dataset, with jurisdiction-specific treatment of consent, purpose limitation, opt-out rights, copyright, and license restrictions.", "threat": { "tags": [ "MR-DEV", "EU-AIA-AnnexIII" ], "desc": "Training on data without documented lawful authority creates regulatory liability, copyright infringement exposure, and model outputs that embed unlicensed intellectual property — resulting in forced model withdrawal, regulatory fines, and litigation. A single cross-jurisdictional framework fails because GDPR, CCPA, UK GDPR, and other regimes have materially different legal bases and opt-out mechanisms." }, "standard": [ "GDPR Art. 6, 9, 17", "EU AI Act Art. 10(2)(c)", "CCPA/CPRA Cal. Civ. Code §1798.100 et seq.", "UK GDPR Art. 6", "ISO/IEC 42001:2023 A.7.5", "SR 26-2 Sec. IV (Model Development and Model Use)" ], "sources": [ { "id": "gdpr", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council", "source_type": "regulation", "license": "public", "artifact_hash": null, "status": "current", "normative_force": "binding-law", "version": "2016/679", "published_on": "2018-05-25", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://model/controls/TG-03 Data Rights, Lawful Authority and Permitted Use control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_art10", "title": "EU AI Act — Article 10: Data and Data Governance", "authority": "European Parliament and Council", "source_type": "regulation", "license": "public", "artifact_hash": null, "status": "current", "retrieved_on": "2026-06-26", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act — Article 10: Data and Data Governance requirements informing the apeiris://model/controls/TG-03 Data Rights, Lawful Authority and Permitted Use control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra", "title": "California Consumer Privacy Act / California Privacy Rights Act — Cal. Civ. Code §1798.100 et seq.", "authority": "California Legislature", "source_type": "regulation", "license": "public", "artifact_hash": null, "status": "current", "normative_force": "binding-law", "version": "2023", "published_on": "2023-01-01", "retrieved_on": "2026-06-26", "source_id": "ccpa", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act / California Privacy Rights Act — Cal. Civ. Code §1798.100 et seq. requirements informing the apeiris://model/controls/TG-03 Data Rights, Lawful Authority and Permitted Use control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/TG-03 Data Rights, Lawful Authority and Permitted Use control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "title": "SR 26-2: Revised Guidance on Model Risk Management", "authority": "Federal Reserve Board", "source_type": "supervisory-guidance", "license": "public", "artifact_hash": null, "supersedes": [ "SR 11-7", "SR 21-8" ], "status": "current", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/TG-03 Data Rights, Lawful Authority and Permitted Use control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Maintain a Data Rights Registry (DRR) that records the specific legal basis, jurisdiction-level treatment, permitted-use scope, and associated restrictions for every training dataset. Legal review is required before a new dataset is approved; opt-out and deletion requests trigger automated dataset quarantine and model retraining assessment workflows.", "steps": [ "For each training dataset, determine applicable jurisdictions based on data subject residence and data collection location.", "Document the specific legal basis per jurisdiction: EU/UK GDPR Art. 6 lawful basis (consent, legitimate interest, legal obligation, vital interests, public task, contract); CCPA/CPRA business purpose and opt-out rights; statutory authority for government data; contractual license terms for third-party data.", "For special-category data (GDPR Art. 9), document the additional Art. 9 condition (explicit consent, substantial public interest, etc.) per jurisdiction.", "Map copyright and IP licensing constraints: Creative Commons variants, proprietary data licenses, scraping terms-of-service analysis, robots.txt compliance review — do not assume public availability equals training permission.", "Record purpose limitations and confirm that model training is within the originally stated or consented purpose. If not, document the legal basis for purpose extension per jurisdiction.", "Implement opt-out and deletion request workflows that quarantine affected records from training datasets and trigger impact assessment for already-trained models.", "Require legal counsel sign-off for datasets relying on legitimate interest or statutory authority claims.", "Review the DRR annually and upon material change to applicable law or vendor contract." ], "anti_patterns": [ "Treating GDPR and CCPA as equivalent and applying a single consent framework to both — they have materially different legal bases and opt-out mechanisms.", "Assuming web-scraped public data is freely usable for AI training — robots.txt, ToS, and copyright law impose jurisdiction-specific restrictions.", "Documenting a single legal basis for a dataset covering data subjects in multiple jurisdictions with different requirements.", "Failing to build opt-out propagation from the DRR to training pipeline exclusion lists.", "Conflating the data processor / data controller distinction when training data is licensed from a third-party controller." ] }, "validation": { "design_check": [ "DRR is structured to capture jurisdiction-specific legal basis, permitted-use scope, opt-out rights, and copyright/license constraints per dataset. [ref:gdpr]", "Legal counsel sign-off is required and recorded for datasets using legitimate interest or statutory authority as the legal basis. [ref:eu_ai_act_art10]", "Opt-out and deletion request workflows are documented and tested end-to-end, including training pipeline exclusion propagation. [ref:ccpa_cpra]" ], "runtime_test": [ "Submit a simulated GDPR Art. 17 deletion request; verify that affected records are quarantined from training pipelines within the required timeframe and impact assessment for trained models is triggered. [ref:gdpr]", "Attempt to add a new dataset to the training pipeline without a DRR entry; confirm pipeline gate blocks submission. [ref:eu_ai_act_art10]", "Verify that web-scraped datasets have documented ToS and copyright review before approval. [unverified]" ], "evidence": [ "model:data-rights-registry-with-full-entry-for — Data Rights Registry with full entry for each training dataset, including legal basis, jurisdiction treatment, and legal counsel approval. [ref:gdpr]", "model:opt-out-and-deletion-request-processing — Opt-out and deletion request processing logs with resolution timestamps and artifact-deletion records. [ref:ccpa_cpra]", "model:copyright-and-license-review-records-for — Copyright and license review records for all non-internally-generated training data. [ref:eu_ai_act_art10]" ] }, "lenses": { "engineering": "Build DRR as a structured database with training-pipeline integration; implement automated gates that query DRR status before training job submission. Build opt-out propagation as an automated workflow that produces signed exclusion lists.", "evaluation": "Independent validation (EV-01) must verify that all training datasets used in a model have valid, unexpired DRR entries at the time of training. Flag any model trained on datasets with contested or expired legal basis.", "red_team": "Probe whether datasets can be added to training pipelines without DRR entries via alternate ingestion paths. Attempt to submit training jobs referencing datasets with expired or legally contested entries.", "grc": "DRR is the primary evidence artifact for data rights compliance across GDPR, CCPA/CPRA, UK GDPR, and EU AI Act Art. 10. Ensure retention aligns with the longest applicable audit/litigation hold period. Engage privacy counsel for jurisdiction-specific legal basis determinations. Non-EU/US jurisdictions (PIPL, LGPD, PDPA) require jurisdiction-specific DRR addenda.", "mlops": "Surface DRR status in the dataset catalog and experiment tracker. Alert on DRR entries approaching expiry (e.g., time-limited consent) or flagged for legal review." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers training-time data rights. Inference-time data rights (e.g., user query data used for fine-tuning) require a separate assessment. Does not cover output copyright — a distinct legal question. Non-EU/US jurisdictions require DRR addenda.", "obligations": [ { "id": "gdpr_art6", "text": "GDPR Art. 6 — processing of personal data requires a lawful basis; purpose limitation applies", "jurisdiction": [ "eu" ], "binding": true, "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2016/679", "source_ref": "gdpr", "normative_force": "binding-law", "legal_status": "enacted", "provision": "Article 6", "effective_from": "2018-05-25" }, { "id": "gdpr_art9", "text": "GDPR Art. 9 — additional conditions required for processing special-category data", "jurisdiction": [ "eu" ], "binding": true, "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2016/679", "source_ref": "gdpr", "normative_force": "binding-law", "legal_status": "enacted", "provision": "Article 9", "effective_from": "2018-05-25" }, { "id": "gdpr_art17", "text": "GDPR Art. 17 — right to erasure must be operationalized in training data pipelines", "jurisdiction": [ "eu" ], "binding": true, "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2016/679", "source_ref": "gdpr", "normative_force": "binding-law", "legal_status": "enacted", "provision": "Article 17", "effective_from": "2018-05-25" }, { "id": "eu_ai_act_art10_2c", "text": "EU AI Act Art. 10(2)(c) — training data must meet data governance requirements including lawful collection", "jurisdiction": [ "eu" ], "binding": true, "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "legal_status": "enacted", "provision": "Article 10(2c)", "effective_from": "2027-08-02" }, { "id": "ccpa_cpra", "text": "CCPA/CPRA — California residents have opt-out and deletion rights that apply to training data where personal information is used for commercial AI development", "jurisdiction": [ "us-california" ], "binding": true, "reviewed_on": "2026-06-26", "authority": "California Privacy Protection Agency", "instrument": "California Consumer Privacy Act (CCPA/CPRA)", "source_ref": "ccpa_cpra", "normative_force": "binding-law", "legal_status": "enacted", "provision": "CCPA/CPRA", "effective_from": "2023-01-01" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-10", "mapping_fit": "partial", "notes": "Art-10 requires that training, validation and testing data for high-risk AI systems meet quality criteria including relevance, representativeness, freedom from errors and appropriate privacy protections.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-1.1 (GOVERN function) provides that legal and regulatory requirements involving AI are understood, managed, and documented. TG-03’s Data Rights Registry documents the legal basis and permitted use for every training dataset, directly implementing this subcategory for training data.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "subcategory": "GOVERN-1.1" }, "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.7.5", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.7.5 (Data provenance) requires documenting the provenance of data used in AI systems. TG-03’s Data Rights Registry records origin, legal basis, and permitted use for every training dataset.", "reviewed_on": "2026-06-26", "source_version": "2023", "source_locator": { "section": "Annex A", "clause": "A.7.5" }, "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-10", "fit": "partial", "direction": "control-supports-requirement", "rationale": "DRR operationalizes EU AI Act data governance requirements for high-risk AI", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "source_locator": { "section": "Chapter III, Section 2 — Requirements for high-risk AI systems", "clause": "Article 10" }, "uncovered_portion": "Article 10 covers all high-risk AI training data requirements as a whole; this control addresses one specific sub-article provision rather than the full Article 10 obligation set.", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. IV", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. IV (Model Development and Model Use) describes documenting the sources of data used in model development. TG-03's Data Rights Registry documents source, legal basis, and permitted use for each training dataset, which covers the data-source documentation expectation for regulated institution models. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "source_locator": { "section": "Sec. IV (Model Development and Model Use)" }, "uncovered_portion": "Sec. IV addresses development data suitability and documentation generally; legal-basis and permitted-use analysis is TG-03's extension beyond the guidance text.", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OWASP AISVS C1.1 (Training Data Origin & Data Security) requires an up-to-date inventory of every training-data source including origin, license, and intended-use constraints (req 1.1.2). TG-03's Data Rights Registry records exactly this legal and permitted-use metadata.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "chapter": "C1.1", "chapter_name": "Training Data Origin & Data Security" }, "normative_force": "voluntary-standard", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "llm10", "requirement_id": "LLM03:2025", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Legal authority verification is part of supply chain due diligence for training data", "reviewed_on": "2026-06-26", "source_version": "2025", "source_locator": { "section": "OWASP LLM Top 10 2025", "clause": "LLM03:2025" }, "uncovered_portion": "LLM03:2025 Supply Chain additionally covers vulnerable pre-trained model adoption, third-party plugin risks, outdated component risks, and model provider dependency management.", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "aicm", "requirement_id": "DSP-12", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DRR is the primary data rights governance control", "reviewed_on": "2026-06-26", "source_version": "1.1", "source_locator": { "section": "CSA AI Controls Matrix v1.1", "clause": "DM-01" }, "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0018", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Verifying data provenance and legal authority reduces supply chain compromise risk", "uncovered_portion": "Active supply chain integrity checks are in TG-04 and TG-07", "reviewed_on": "2026-06-26", "source_version": "v2026.06", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "nist_ai_600_1", "requirement_id": "DATA-PRIVACY", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI 600-1 DATA-PRIVACY covers risks from models trained on personal data — including memorization, membership inference attacks, and unintended output of personal information. TG-03 addresses the training-time component by governing how sensitive and protected-attribute data is handled during dataset assembly and preprocessing.", "uncovered_portion": "DATA-PRIVACY in NIST AI 600-1 also covers inference-time privacy risks (model outputs revealing training data) — those are addressed by EV-04 red-teaming and BH-05 audit logging, not TG-03.", "source_version": "2024", "reviewed_on": "2026-06-26", "mapping_confidence": "medium", "provisional": true, "provisional_note": "NIST AI 600-1 GenAI Profile uses category-level identifiers (e.g., CONFABULATION, CBRN); action-level subcategory mapping was not possible from the category reference. Treat as category-level guidance only.", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_aitg", "requirement_id": "AITG-DAT-05", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AITG-DAT-05 (Testing for Data Minimization and Consent) checks that training data is collected and used with a lawful basis and appropriate consent. TG-03's Data Rights Registry documents legal basis, jurisdiction treatment, and permitted-use scope — the evidence this test verifies.", "source_locator": { "test_id": "AITG-DAT-05", "test_name": "Testing for Data Minimization and Consent" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "alloweddata", "fit": "direct", "rationale": "Requiring a documented legal basis (consent, contract, statute, or license) for every training dataset is the use-only-allowed-and-lawful-data control.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "profiles": [ { "id": "eu-high-risk", "note": "Mandatory; DRR entries required for all training data; GDPR Art. 6 lawful basis and Art. 10(2)(c) compliance must be documented" }, { "id": "us-regulated-banking", "note": "Required; data sourcing documentation required by SR 26-2; privacy counsel review for any consumer-data training sets" }, { "id": "generative-ai", "note": "Heightened scrutiny required for web-scraped pre-training corpora; copyright and ToS review is mandatory before corpus approval" }, { "id": "frontier-capability", "note": "Large-scale pre-training corpora must have documented legal review for all major content source categories" } ], "enforcement_point": "dataset-approval", "canonical_id": "apeiris://model/controls/TG-03", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "validation_objective": "For every dataset used in training, a specific and documented legal basis exists — identifying the consent mechanism, contractual right, statutory authority, or license entitlement that permits collection and use for the declared training purpose — and no training run may proceed on a dataset whose legal basis record is absent, expired, or jurisdiction-mismatched.", "evidence_required": [ "data_rights_record for each training dataset specifying the legal basis type (consent, legitimate interest, contract, statutory authority, or license), the jurisdiction(s) covered, the permitted purpose scope, and any opt-out or withdrawal obligations", "purpose_limitation_compliance_record confirming that the declared training purpose falls within the scope of the legal basis established for the dataset, with documented mapping between use case and authorized purpose", "opt_out_enforcement_log showing that data subjects who exercised withdrawal or opt-out rights had their records removed from training datasets before any training run that included the affected dataset", "legal_basis_expiry_alert showing that datasets with time-limited legal bases (e.g., consents with expiry dates, contracts with end dates) are flagged for renewal review before expiry and blocked from training if the basis lapses" ], "machine_tests": [ "Attempt to initiate a training job on a dataset with no data_rights_record in the registry → assert the training pipeline rejects the job and requires a legal basis record before proceeding", "Register a dataset with a consent-based legal basis scoped to 'product improvement' and attempt to use it for a training job tagged 'third-party model resale' → assert the pipeline flags a purpose limitation mismatch and blocks the training run", "Set a dataset's consent expiry date to a past date and attempt to initiate a training job using that dataset → assert the pipeline identifies the expired legal basis and blocks the training run with an expiry notification", "Submit an opt-out request for a named data subject in a training dataset and then verify the training pipeline refuses to use the dataset until the opt-out record is processed and the subject's records removed" ], "human_review": [ "Review a sample of data_rights_records to confirm that the legal basis specified is substantive and jurisdiction-specific — not a generic reference to 'consent' without documentation of how consent was collected, its scope, and its currency", "Assess whether purpose limitation compliance records are maintained with sufficient granularity to trace each training use case back to its authorized legal basis, and whether cross-purpose use has been identified and addressed", "Verify that the opt-out and data subject rights enforcement process is operationally capable of removing individual records from training datasets within the required regulatory timeframes before a training run that would use the affected dataset" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Using publicly scraped web content for training without verifying that the scraping terms of service, copyright status, and applicable consent frameworks permit AI training use — 'publicly available' does not mean 'lawfully usable'", "Documenting a single legal basis record at dataset onboarding and never reviewing it for changes in jurisdiction, purpose scope expansion, or expiry — legal bases are not static", "Relying on contractual data rights from a third-party data vendor without independently verifying that the vendor's upstream consent chain and rights are sufficient to support the intended training use", "Treating GDPR legitimate interest as a blanket authorization for all AI training without conducting and documenting a legitimate interest assessment (LIA) balancing test as required by the regulation", "Failing to implement operational opt-out enforcement — accepting that data subjects may withdraw consent but not having a pipeline mechanism to remove their records before training runs" ], "update_status": "current", "layer_code": "TG" }, { "id": "TG-04", "layer": "TG", "plane": "data", "name": "Data Poisoning Prevention", "plain": "Protect training datasets from adversarial manipulation through cryptographic integrity verification of training shards, supply-chain integrity checks, adversarial input screening at ingestion, and chain-of-custody controls for all data transformations.", "threat": { "tags": [ "LLM04:2025", "AML.T0020", "AML.T0018", "MR-DEV" ], "desc": "Adversaries who can inject, manipulate, or substitute training data can cause targeted model misbehavior — backdoors, biased outputs, capability suppression — that persists through deployment and is difficult to detect without specific probing. Supply chain compromise of third-party datasets (AML.T0018) is the highest-scale vector; insider-path injection (AML.T0020) is the highest-stealth vector." }, "standard": [ "NIST AI RMF MEASURE 2.7", "ISO/IEC 42001:2023 A.7.5", "EU AI Act Art. 10(2)", "OWASP LLM Top 10 2025 LLM04", "MITRE ATLAS v5.6.0 AML.T0020, AML.T0018" ], "sources": [ { "id": "mitre_atlas_v5_6_0", "title": "MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems", "authority": "MITRE Corporation", "source_type": "threat-knowledge-base", "license": "public", "artifact_hash": null, "status": "current", "normative_force": "best-practice", "version": "5.6.0", "published_on": "2026-05-04", "retrieved_on": "2026-06-26", "source_id": "mitre_atlas", "relationship": "informative_reference", "rationale": "Establishes MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems requirements informing the apeiris://model/controls/TG-04 Data Poisoning Prevention control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_llm10_2025", "title": "OWASP Top 10 for LLM Applications 2025", "authority": "OWASP Foundation", "source_type": "voluntary-standard", "license": "CC BY-SA 4.0", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2025", "published_on": "2024-11-17", "retrieved_on": "2026-06-26", "source_id": "owasp_llm10", "relationship": "implementation_pattern", "rationale": "Establishes OWASP Top 10 for LLM Applications 2025 requirements informing the apeiris://model/controls/TG-04 Data Poisoning Prevention control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "NIST", "source_type": "voluntary-standard", "license": "public_domain", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/TG-04 Data Poisoning Prevention control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/TG-04 Data Poisoning Prevention control.", "reviewed_on": "2026-07-01" }, { "id": "etsi_gr_sai_005", "title": "ETSI GR SAI 005 — Mitigation Strategy Report", "authority": "ETSI", "source_type": "standards-body", "normative_force": "voluntary-standard", "version": "V1.1.1", "published_on": "2021-03-01", "retrieved_on": "2026-07-08", "canonical_url": "https://www.etsi.org/deliver/etsi_gr/SAI/001_099/005/01.01.01_60/gr_SAI005v010101p.pdf", "relationship": "supporting_guidance", "note": "ETSI SAI 005 poisoning mitigations (clause 5.2) inform data-poisoning prevention." }, { "id": "bsi_ai_fundamentals", "title": "BSI — Security of AI-Systems: Fundamentals", "authority": "Federal Office for Information Security (BSI)", "source_type": "government-agency", "normative_force": "supervisory-guidance", "version": "0.9", "published_on": "2022-06-14", "retrieved_on": "2026-07-08", "canonical_url": "https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/Security-of-AI-systems_fundamentals.pdf", "relationship": "supporting_guidance", "note": "BSI poisoning/backdoor-defense best practices (1.2.3) inform data-poisoning prevention." } ], "implementation": { "pattern": "Implement a layered data integrity framework: cryptographic hash-pinning for all training shards, provenance chain-of-custody logging, adversarial content screening at ingestion, and supply-chain integrity verification for all externally sourced datasets. Any integrity chain break triggers automatic quarantine and security incident review.", "steps": [ "Compute and store SHA-256 (minimum) or SHA-3-256 hashes for every training data shard immediately upon ingestion; store hashes in an append-only, access-controlled integrity registry separate from the data store.", "Verify stored hashes before every training run; hash mismatch blocks training with no bypass except CISO approval and a logged incident record.", "Implement chain-of-custody logging: record every transformation, merge, filter, and augmentation applied to each dataset with the identity of the executing process, inputs, outputs, and timestamp.", "Deploy adversarial input screening at ingestion: statistical anomaly detection for label flips, outlier injection, and distributional shifts in newly ingested data batches.", "For externally sourced data (see also TG-07): verify vendor-provided checksums and independently re-derive hashes from source downloads; do not rely on CDN or mirror copies without re-verification.", "Implement write-once / append-only storage for training datasets; restrict mutation access to privileged accounts subject to dual-approval workflow.", "Conduct periodic integrity audits: re-verify stored hashes against archives on a scheduled basis and on any suspicion of compromise.", "Define and exercise a poisoning incident response playbook: detection → quarantine → root cause → retraining assessment → recovery." ], "anti_patterns": [ "Relying on perimeter security alone without hashing individual data shards.", "Storing integrity hashes in the same mutable system as the training data, enabling coordinated hash-and-data substitution.", "Screening only at initial ingestion and not re-verifying before each training run.", "Treating hash mismatch as a warning rather than a hard pipeline blocker.", "Not logging data transformations in the chain-of-custody, making it impossible to trace a poisoning event to its source step." ] }, "validation": { "design_check": [ "SHA-256 or stronger hash is computed and stored for every training shard in an append-only integrity registry separate from the training data store. [ref:nist_ai_rmf_1_0]", "Hash verification is a mandatory, non-bypassable step in the training pipeline with CISO-escalation required for any override. [ref:mitre_atlas_v5_6_0]", "Chain-of-custody logging captures all data transformations with process identity, timestamp, and input/output hashes. [ref:owasp_llm10_2025]", "Adversarial input screening is deployed at data ingestion and is tuned with documented sensitivity/specificity targets. [ref:mitre_atlas_v5_6_0]" ], "runtime_test": [ "Modify 0.1% of records in a training shard and re-run hash verification; confirm mismatch is detected and training is blocked. [ref:mitre_atlas_v5_6_0]", "Inject a batch of adversarially crafted records (label-flip attack on a minority class) at the ingestion point; verify screening detects statistical anomaly. [ref:owasp_llm10_2025]", "Attempt to submit a training job that bypasses hash verification via an alternate pipeline path; confirm gate blocks submission. [ref:nist_ai_rmf_1_0]", "Simulate supply chain compromise by substituting a third-party dataset shard with a modified version; verify checksum mismatch is caught before training. [ref:mitre_atlas_v5_6_0]" ], "evidence": [ "model:integrity-registry-with-hash-entries-for — Integrity registry with hash entries for all training shards, showing hash algorithm, timestamp, and verifying process identity. [ref:nist_ai_rmf_1_0]", "model:pre-training-hash-verification-logs-for — Pre-training hash verification logs for each training run, showing pass/fail status and any overrides with CISO approval records. [ref:mitre_atlas_v5_6_0]", "model:chain-of-custody-audit-trail-for-each-tr — Chain-of-custody audit trail for each training dataset version. [ref:owasp_llm10_2025]", "model:adversarial-screening-alert-logs-and-inv — Adversarial screening alert logs and investigation records. [ref:mitre_atlas_v5_6_0]" ] }, "lenses": { "engineering": "Implement integrity registry as an immutable ledger (append-only log store or cryptographic accumulator). Integrate hash verification as a native pipeline step, not a pre-job script that can be bypassed. Use hardware-isolated key management for signing processes.", "evaluation": "Red-team the data integrity system before each major model release. Include poisoning detection efficacy in the evaluation report. Verify that chain-of-custody logs are complete for all datasets used in the evaluated model.", "red_team": "Attempt label-flip attacks, backdoor triggers, and distributional poisoning via the data ingestion pipeline. Test whether hash stores can be substituted. Probe for alternate ingestion paths that bypass screening. Evaluate detection latency — how many poisoned batches can enter before screening alerts?", "grc": "Data poisoning incidents must be classified as security incidents under the incident response policy. MITRE ATLAS AML.T0020 and AML.T0018 provide the threat taxonomy for risk register entries. Maintain poisoning incident history as evidence for regulatory reporting.", "mlops": "Monitor hash verification failure rates and adversarial screening alert rates as operational security metrics. Sudden spikes in screening alerts warrant immediate pipeline suspension and investigation." }, "maturity": { "current": "initial", "target": "managed" }, "coverage_note": "Covers integrity of training data. Runtime input integrity (prompt injection, inference-time manipulation) is addressed in the BH layer. Model weight integrity post-training is in BH-03.", "capability_risk": { "capability_level": "elevated", "autonomy": "bounded", "access_mode": "internal", "irreversibility": "partially-reversible", "deployment_scale": "enterprise", "affected_party_impact": "moderate", "external_reach": false, "data_sensitivity": "internal", "notes": "risk level: critical | relevant profiles: frontier-capability, continuously-learning, eu-high-risk | description: Successful undetected poisoning of a frontier model's training data could compromise safety behaviors or create targeted capability suppression. Impact scales with model capability level." }, "obligations": [ { "id": "eu_ai_act_art10_2", "text": "EU AI Act Art. 10(2) — training data for high-risk AI must meet quality criteria; data integrity is a prerequisite", "jurisdiction": [ "eu" ], "binding": true, "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "legal_status": "enacted", "provision": "Article 10", "effective_from": "2027-08-02" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-10", "mapping_fit": "partial", "notes": "Art-10 requires that training, validation and testing data for high-risk AI systems meet quality criteria including relevance, representativeness, freedom from errors and appropriate privacy protections.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.7", "fit": "direct", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.7 (MEASURE function) provides that AI system security and resilience are evaluated and documented. TG-04’s poisoning prevention controls address the training-data attack surface within security-and-resilience evaluation; the RMF has no subcategory prescribing cryptographic data integrity specifically.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "subcategory": "MEASURE-2.7" }, "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.7.5", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.7.5 (Data provenance) requires verifiable records of where data came from and how it changed. TG-04’s hash-pinning and chain-of-custody controls make training-data provenance tamper-evident.", "reviewed_on": "2026-06-26", "source_version": "2023", "source_locator": { "section": "Annex A", "clause": "A.7.5" }, "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-10", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Data integrity controls support EU AI Act data quality requirements for high-risk AI", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "source_locator": { "section": "Chapter III, Section 2 — Requirements for high-risk AI systems", "clause": "Article 10" }, "uncovered_portion": "Article 10 covers all high-risk AI training data requirements as a whole; this control addresses one specific sub-article provision rather than the full Article 10 obligation set.", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. IV", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. IV (Model Development and Model Use) describes ensuring the quality and integrity of data used in model development. TG-04's hash-pinning and chain-of-custody controls provide integrity evidence for that expectation; the guidance does not address adversarial poisoning specifically. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "source_locator": { "section": "Sec. IV (Model Development and Model Use)" }, "uncovered_portion": "Sec. IV addresses general data quality and integrity in development; adversarial poisoning defenses are beyond the guidance text.", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aisvs", "requirement_id": "C1.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OWASP AISVS C1.3 (Training Data Quality and Security Assurance) requires poisoning detection in training pipelines (req 1.3.1) and defenses against clean-label poisoning (1.3.5). TG-04's hash-pinning, chain-of-custody, and adversarial content screening implement those requirements.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "chapter": "C1.3", "chapter_name": "Training Data Quality and Security Assurance" }, "normative_force": "voluntary-standard", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "llm10", "requirement_id": "LLM04:2025", "fit": "partial", "direction": "control-mitigates-risk", "rationale": "This control directly mitigates the LLM04 data poisoning attack vector", "uncovered_portion": "Model weight poisoning addressed in BH-03", "reviewed_on": "2026-06-26", "source_version": "2025", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "aicm", "requirement_id": "STA-01", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Data integrity controls are a primary AICM supply chain security mechanism", "reviewed_on": "2026-06-26", "source_version": "1.1", "source_locator": { "section": "CSA AI Controls Matrix v1.1", "clause": "SUP-01" }, "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0020", "fit": "partial", "direction": "control-mitigates-risk", "rationale": "Hash pinning and chain-of-custody directly mitigate ATLAS Poison Training Data and Supply Chain Compromise techniques", "uncovered_portion": "Inference API exfiltration (AML.T0024) is addressed in BH layer", "reviewed_on": "2026-06-26", "source_version": "v2026.06", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "owasp_aitg", "requirement_id": "AITG-MOD-03", "fit": "direct", "direction": "control-supports-requirement", "rationale": "AITG-MOD-03 (Testing for Poisoned Training Sets) probes for poisoned or manipulated training data. TG-04's hash-pinning, chain-of-custody logging, and adversarial content screening are the defensive controls this test evaluates.", "source_locator": { "test_id": "AITG-MOD-03", "test_name": "Testing for Poisoned Training Sets" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ml_top10", "requirement_id": "ML02:2023", "fit": "supporting", "rationale": "OWASP ML02:2023 Data Poisoning Attack names the exact threat this control prevents; supporting taxonomy reference.", "normative_force": "industry-framework", "source_version": "2023", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against" }, { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.013", "fit": "supporting", "rationale": "NIST AI 100-2 Data Poisoning (NISTAML.013) is the training-time threat this control prevents.", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against" }, { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.012", "fit": "partial", "rationale": "NIST AI 100-2 Clean-label Poisoning — a poisoning subtype that passes label+hash checks.", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against" }, { "framework": "owasp_ai_exchange", "requirement_id": "poisonrobustmodel", "fit": "supporting", "rationale": "Cryptographic shard-integrity verification, adversarial ingestion screening, and chain-of-custody are the data-side defenses that make a model robust to poisoning.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "dataqualitycontrol", "fit": "supporting", "rationale": "Integrity verification and adversarial screening of training shards enforce the training-data quality the data-quality-control control protects.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0007", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every training shard must pass cryptographic integrity verification against a…\" enacts ATLAS mitigation AML.M0007 Sanitize Training Data; complements the control’s existing technique mapping AML.T0020 (defends_against) — OpenCRE crosswalks the AI Exchange concept (dataqualitycontrol) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "profiles": [ { "id": "continuously-learning", "note": "Highest risk profile; apply integrity controls to every incremental update batch, not only the initial training corpus" }, { "id": "frontier-capability", "note": "Critical; adversarial screening sensitivity thresholds must be elevated; any poisoning incident triggers mandatory safety review" }, { "id": "eu-high-risk", "note": "Required; integrity controls are a prerequisite for EU AI Act Art. 10 compliance" }, { "id": "hosted-api", "note": "Apply to fine-tuning data submitted by API customers; implement tenant-isolation in integrity registry" } ], "enforcement_point": "data-ingestion and training-pipeline-entry", "canonical_id": "apeiris://model/controls/TG-04", "validation_objective": "Every training shard must pass cryptographic integrity verification against a pre-ingestion hash before it is admitted to a training run; adversarial input screening must be applied at ingestion for all external or third-party data sources; and a chain-of-custody record must exist for every data transformation applied to the training corpus.", "evidence_required": [ "training_shard_integrity_manifest listing the cryptographic hash (SHA-256 or stronger) for each shard, the verification timestamp, and the verification result (pass/fail/recomputed) for the current training run", "adversarial_screening_report for each external data source ingested, including the screening method applied, the number of records inspected, any detected anomalies or suspicious patterns, and the disposition (accepted/quarantined/rejected)", "chain_of_custody_record for each data transformation applied to the training corpus, including the transformation type, operator identity, input hash, output hash, and transformation timestamp", "supply_chain_integrity_check_record confirming that third-party training data packages (datasets, pretrained weights, synthetic data) were verified against vendor-provided manifests or signatures before use" ], "machine_tests": [ "Modify a single record in a training shard after computing its integrity hash and attempt to admit the shard to a training run → assert the integrity verification step detects the hash mismatch and rejects the shard", "Ingest a synthetic data package from an external provider without a vendor-provided manifest or signature and attempt to use it in training → assert the supply chain check rejects the package and requires a verified manifest before admission", "Inject a batch of records into the training corpus that contain anomalous label distributions consistent with backdoor poisoning patterns → assert the adversarial screening report flags the batch as suspicious and places it in quarantine pending review", "Attempt to initiate a training run on a dataset with a gap in the chain-of-custody record (a transformation step with no operator identity or output hash) → assert the pipeline requires the gap to be resolved before the training job proceeds" ], "human_review": [ "Review the adversarial screening methodology to confirm it is calibrated to detect backdoor triggers, label poisoning, and targeted corruption patterns relevant to the model's task domain — not only statistical outlier detection", "Assess the supply chain integrity process for third-party pretrained weights and synthetic datasets to verify that vendor manifests are verified against an independent source of truth, not accepted on the vendor's assertion alone", "Verify that the chain-of-custody record covers all transformation steps from raw ingestion through preprocessing, filtering, augmentation, and final dataset assembly — and that gaps in the record prevent training rather than being noted as warnings" ], "blocking_effect": "blocks-deployment", "normative_status": "voluntary-standard", "anti_patterns": [ "Computing integrity hashes only at dataset registration and not re-verifying them before each training run, leaving a window for undetected modification between registration and use", "Applying adversarial screening only to new data ingested after a poisoning incident rather than as a routine gate for all external data sources at every ingestion", "Treating the chain-of-custody record as a post-hoc audit log rather than a blocking gate — allowing training runs to proceed when transformation records are incomplete and noting the gap after the fact", "Using weak hash functions (MD5, SHA-1) for training shard integrity verification, which are vulnerable to collision attacks that could allow substitution of poisoned shards while maintaining a matching hash", "Relying solely on statistical anomaly detection for adversarial screening without targeted tests for known poisoning attack patterns (backdoor triggers, clean-label attacks, gradient-based poisoning signatures)" ], "update_status": "current", "layer_code": "TG" }, { "id": "TG-05", "layer": "TG", "plane": "data", "name": "Train/Evaluation/Test Separation and Contamination Prevention", "plain": "Maintain strict separation between training, evaluation, and test splits; detect and prevent benchmark contamination, semantic duplicates, temporal leakage, retrieval leakage, synthetic-data leakage, and evaluation overfitting across all model development phases.", "threat": { "tags": [ "MR-DEV", "MR-VAL", "MR-PERFORMANCE" ], "desc": "Contamination between training and evaluation data produces inflated performance metrics that do not reflect real-world capability, causing unsafe or inadequate models to pass release gates. Benchmark contamination is especially dangerous for frontier models evaluated on standard public benchmarks where it may be undetectable without specific analysis." }, "standard": [ "ISO/IEC 42001:2023 A.7.4", "NIST AI RMF MAP 2.3", "SR 26-2 Sec. V (Model Validation and Monitoring)" ], "sources": [ { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/TG-05 Train/Evaluation/Test Separation and Contamination Prevention control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "NIST", "source_type": "voluntary-standard", "license": "public_domain", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/TG-05 Train/Evaluation/Test Separation and Contamination Prevention control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "title": "SR 26-2: Revised Guidance on Model Risk Management", "authority": "Federal Reserve Board", "source_type": "supervisory-guidance", "license": "public", "artifact_hash": null, "supersedes": [ "SR 11-7", "SR 21-8" ], "status": "current", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/TG-05 Train/Evaluation/Test Separation and Contamination Prevention control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Establish and enforce a documented data partitioning policy that defines split creation methodology, contamination detection procedures, and the governance process for managing test-set access. Contamination checks run automatically before training and validation; detected contamination is a hard blocker.", "steps": [ "Define a formal data partitioning policy specifying: split ratios, stratification methodology, temporal cutoff approach, and access control for each split — test sets must be held out from all model training personnel.", "Implement exact-match deduplication across all splits using content hashes before training begins.", "Implement near-duplicate and semantic-similarity detection (e.g., MinHash LSH, embedding-based similarity) to catch paraphrased or reformatted benchmark contamination.", "Apply temporal leakage checks: for time-series or temporally structured data, ensure no future-dated records appear in training relative to the evaluation period.", "For RAG and retrieval-augmented models: verify that retrieval corpora do not contain evaluation benchmark content; implement retrieval leakage detection as a first-class check.", "For synthetic-data pipelines: trace synthetic records to their generation source; if the generative model was trained on benchmark data, flag the synthetic split for contamination review.", "Implement evaluation overfitting controls: limit the number of times evaluation metrics can be computed against the same benchmark; rotate internal benchmark sets; use held-out external benchmarks managed by a separate team.", "Maintain a contamination-check audit log for each training run and evaluation cycle.", "Re-run contamination checks whenever training data is expanded or evaluation benchmarks are added." ], "anti_patterns": [ "Relying on random split assignment without checking for semantic duplicates across splits.", "Allowing model development personnel unrestricted access to test set content.", "Reusing the same test set across multiple model iterations without contamination controls, enabling evaluation overfitting.", "Ignoring retrieval corpus contamination in RAG systems — the retrieval index is part of the effective training surface.", "Not re-checking contamination after synthetic data is added to training." ] }, "validation": { "design_check": [ "Data partitioning policy is documented and specifies stratification methodology, temporal cutoff rules, and access controls for test splits. [ref:nist_ai_rmf_1_0]", "Exact-match and near-duplicate deduplication runs automatically across all splits before training. [ref:iso_42001_2023]", "Test split access is restricted to the validation function; model training team members do not have read access to test set content. [ref:sr262_2026]", "Evaluation overfitting controls are documented: benchmark rotation policy, maximum evaluation runs per benchmark, use of held-out external benchmarks. [ref:nist_ai_rmf_1_0]" ], "runtime_test": [ "Inject 1% of evaluation benchmark examples verbatim into the training set; verify contamination detection flags them before training proceeds. [ref:iso_42001_2023]", "Inject paraphrased versions of benchmark examples (semantic duplicates) and verify near-duplicate detection catches them. [ref:nist_ai_rmf_1_0]", "For a RAG model, insert a benchmark question-answer pair into the retrieval corpus; verify retrieval leakage detection flags the contamination. [unverified]", "Verify that a training run submitted with a missing contamination-check attestation is blocked at the pipeline gate. [ref:sr262_2026]" ], "evidence": [ "model:contamination-check-audit-logs-for-each — Contamination-check audit logs for each training run and evaluation cycle, showing contamination counts per split pair. [ref:nist_ai_rmf_1_0]", "model:deduplication-reports-showing-exact-matc — Deduplication reports showing exact-match and near-duplicate counts per split pair. [ref:iso_42001_2023]", "model:test-set-access-control-audit-logs-showi — Test-set access control audit logs showing who accessed test data and when. [ref:sr262_2026]" ] }, "lenses": { "engineering": "Implement contamination detection as a pipeline stage using content-addressable hashing for exact matches and LSH/embedding similarity for near-duplicates. Enforce test-set access controls at the storage layer, not just the application layer. Version-pin evaluation benchmarks.", "evaluation": "The independent validation team (EV-01) must own and control test sets. Evaluate models on externally managed benchmarks not accessible to the development team. Document any known contamination and its estimated effect on reported metrics.", "red_team": "Probe whether benchmark examples from known public datasets (e.g., MMLU, HumanEval) can be found in the training corpus using fuzzy matching. Test whether evaluation personnel can inadvertently leak test-set content to the development team. Probe for retrieval leakage in RAG deployments.", "grc": "Contamination check audit logs are model validation evidence required by SR 26-2 §IV.C and ISO 42001. Reported benchmark scores must be accompanied by contamination check results in regulatory filings and model documentation.", "mlops": "Track contamination rates and near-duplicate counts as dataset-quality metrics in the experiment tracker. Alert if contamination rate exceeds threshold after data pipeline changes." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers data-level contamination prevention. Evaluation independence and benchmark selection are addressed in EV-01. Does not fully address contamination from model memorization — that requires separate membership inference analysis.", "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MAP-2.3", "fit": "direct", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MAP-2.3 (MAP function) provides that scientific integrity and TEVV considerations, including data collection and selection, are identified and documented. TG-05’s enforced train/evaluation/test separation protects the experimental design and construct validity this subcategory requires TEVV to document.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "subcategory": "MAP-2.3" }, "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.7.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.7.4 (Quality of data) requires data quality management across the data used for AI systems. TG-05’s split separation and contamination detection protect the integrity of evaluation data as a quality property.", "reviewed_on": "2026-06-26", "source_version": "2023", "source_locator": { "section": "Annex A", "clause": "A.7.4" }, "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Test independence supports EU AI Act testing requirements for high-risk AI", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "source_locator": { "section": "Chapter III, Section 2 — Requirements for high-risk AI systems", "clause": "Article 9" }, "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. V", "fit": "direct", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes validation testing on data separate from development data, including out-of-sample analysis. TG-05's enforced train/evaluation/test separation and contamination detection preserve the independence that such testing depends on. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "source_locator": { "section": "Sec. V (Model Validation and Monitoring)" }, "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aisvs", "requirement_id": "C1.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OWASP AISVS C1.3 (Training Data Quality and Security Assurance) covers integrity and quality assurance of training data. TG-05's split separation and contamination detection protect evaluation integrity, an adjacent aspect of that assurance; AISVS does not address split contamination explicitly.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "chapter": "C1.3", "chapter_name": "Training Data Quality and Security Assurance" }, "normative_force": "voluntary-standard", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "llm10", "requirement_id": "LLM04:2025", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Contamination prevention reduces risk of evaluation gaming and capability misrepresentation", "reviewed_on": "2026-06-26", "source_version": "2025", "source_locator": { "section": "OWASP LLM Top 10 2025", "clause": "LLM04:2025" }, "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "mitre", "requirement_id": "AML.T0020", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Detecting contamination provides signal that training data may have been adversarially manipulated", "uncovered_portion": "Active poisoning attack detection is TG-04", "reviewed_on": "2026-06-26", "source_version": "v2026.06", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" } ], "profiles": [ { "id": "frontier-capability", "note": "Critical; benchmark contamination invalidates safety evaluations — mandatory contamination disclosure in model cards and eval reports" }, { "id": "generative-ai", "note": "High priority; pre-training corpora frequently contain public benchmark data; contamination analysis required before any benchmark reporting" }, { "id": "continuously-learning", "note": "Re-run contamination checks on each incremental training batch; online evaluation requires streaming contamination detection" }, { "id": "eu-high-risk", "note": "Test-set independence required; validation team access controls must be documented for EU AI Act technical documentation" }, { "id": "us-regulated-banking", "note": "SR 26-2 requires independent validation with documented data separation controls" } ], "enforcement_point": "dataset-finalization and training-pipeline-entry", "canonical_id": "apeiris://model/controls/TG-05", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-9", "mapping_fit": "partial", "notes": "Art-9 requires providers to establish, implement, document and maintain a risk management system throughout the lifecycle of a high-risk AI system.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "Training, evaluation, and test data splits contain no contaminating examples from other splits, verified by automated exact-match and near-duplicate detection before each training run commences. The training pipeline blocks any run where contamination detection has not completed with a clean result and produced a signed attestation.", "evidence_required": [ "contamination_check_audit_log with training_run_id, benchmark names checked, exact_match_count, near_duplicate_count, retrieval_leakage_count, and pass/block outcome per split pair for every training run", "split_deduplication_report listing content-hash comparison results for all training-test and training-eval split pairs, with deduplication method (exact-match hash, MinHash LSH, embedding cosine similarity) and similarity threshold used", "test_set_access_control_record showing storage-layer ACL configuration restricting test split access to validation personnel only, with last-verified date", "evaluation_overfitting_policy document specifying maximum benchmark reuse count per model version, rotation schedule, and use of held-out external benchmarks not accessible to the model development team" ], "machine_tests": [ "Inject 1% of evaluation benchmark examples verbatim into the training dataset → assert contamination detection flags run as blocked with contamination_count > 0 and training pipeline halts before any training step executes", "Insert paraphrased benchmark examples (semantic duplicates at cosine similarity > 0.85) into training data → assert near-duplicate detection catches ≥ 90% and flags the split pair for review", "Submit a training run without a completed contamination-check attestation → assert pipeline gate returns status=blocked with error=missing_contamination_attestation", "For RAG pipeline: insert a benchmark QA pair into the retrieval corpus → assert retrieval leakage detection flags the corpus as contaminated before evaluation proceeds" ], "human_review": [ "Review contamination detection thresholds (hash algorithm, similarity distance cutoffs, LSH band configuration) to confirm they are calibrated to the training corpus characteristics and cannot be trivially bypassed by minor rephrasing", "Examine test-set access control audit logs for evidence of unauthorized access by model development personnel during the review period", "Review evaluation overfitting controls — benchmark rotation policy, maximum evaluation run counts, and any granted exceptions — to confirm that reported performance metrics reflect genuine held-out capability" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Using random train/test splits without performing content-addressable hash deduplication across split boundaries, allowing duplicate examples to persist undetected across training and evaluation sets", "Granting model development personnel read access to test set content without storage-layer access controls, relying solely on policy compliance to maintain separation", "Reusing the same benchmark suite across multiple model iterations without rotation or external benchmark use, enabling evaluation overfitting as hyperparameters are tuned against benchmark results", "Skipping retrieval corpus contamination checks for RAG models on the grounds that the retrieval index is not 'training data', despite retrieved content being injected at inference time and functionally expanding the model's knowledge surface", "Not re-running contamination detection after adding synthetic data to training, treating synthetic records as inherently contamination-free without tracing them to their generation source" ], "update_status": "current", "layer_code": "TG" }, { "id": "TG-06", "layer": "TG", "plane": "data", "name": "Sensitive-Data Necessity, Minimization and Controlled Use", "plain": "Limit PII and protected-class data in training to what is strictly necessary; apply de-identification, anonymization, or synthetic replacement where feasible; and implement tightly governed access controls when protected attributes must be retained for bias auditing or regulatory compliance.", "threat": { "tags": [ "MR-DEV", "EU-AIA-AnnexIII", "LLM04:2025" ], "desc": "Over-retention of PII and protected-class data in training corpora creates privacy harm, regulatory liability, and a model that can memorize and regurgitate personal information. Protected attributes are simultaneously a privacy risk and a fairness control instrument — their handling requires careful governance to serve both goals without conflating them." }, "standard": [ "GDPR Art. 5(1)(c) — data minimisation", "GDPR Art. 25 — data protection by design", "EU AI Act Art. 10(5)", "ISO/IEC 42001:2023 A.7.2", "NIST AI RMF MEASURE 2.10" ], "sources": [ { "id": "gdpr", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council", "source_type": "regulation", "license": "public", "artifact_hash": null, "status": "current", "normative_force": "binding-law", "version": "2016/679", "published_on": "2018-05-25", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://model/controls/TG-06 Sensitive-Data Necessity, Minimization and Controlled Use control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_art10", "title": "EU AI Act — Article 10: Data and Data Governance", "authority": "European Parliament and Council", "source_type": "regulation", "license": "public", "artifact_hash": null, "status": "current", "retrieved_on": "2026-06-26", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act — Article 10: Data and Data Governance requirements informing the apeiris://model/controls/TG-06 Sensitive-Data Necessity, Minimization and Controlled Use control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "NIST", "source_type": "voluntary-standard", "license": "public_domain", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/TG-06 Sensitive-Data Necessity, Minimization and Controlled Use control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/TG-06 Sensitive-Data Necessity, Minimization and Controlled Use control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Apply necessity and minimization review to every training dataset before approval. PII is de-identified or replaced with synthetic proxies by default. When protected attributes must be retained for fairness auditing, they are stored in a separately access-controlled fairness audit vault with time-bounded, logged access.", "steps": [ "Conduct a data necessity assessment: for each field/feature, document whether its inclusion in training is strictly necessary for model performance. Default to exclusion for PII and protected-class attributes.", "Apply de-identification to PII fields: direct identifiers removed or pseudonymized; quasi-identifiers assessed for re-identification risk (k-anonymity, l-diversity, or differential privacy metrics).", "For NLP/LLM training corpora: run PII scanning (names, addresses, SSNs, health data, financial account numbers) using automated scanners; manually review samples; define redaction or replacement policy.", "When protected attributes (race, gender, disability status, etc.) are needed for bias auditing (TG-02, BH-05): store them in a fairness audit vault with role-based access control, logging, and time-bounded access grants.", "Implement synthetic data replacement for scenarios where real PII is currently used; document the synthetic generation approach and validate that synthetic data does not re-introduce re-identification risk.", "Apply EU AI Act Art. 10(5) carve-out: if protected attributes must be processed for bias detection and correction, document the explicit legal basis and implement additional safeguards.", "Run minimization review at each data refresh cycle; re-assess necessity as model capabilities and use cases evolve." ], "anti_patterns": [ "Retaining PII 'just in case' it improves model quality — necessity must be demonstrated, not assumed.", "Using protected-class attributes freely throughout the data pipeline and only restricting them at model deployment — control must be applied at the data layer.", "Conflating de-identification with anonymization — pseudonymized data remains personal data under GDPR; full anonymization requires meeting a high technical bar.", "Not logging access to the fairness audit vault — retention of access logs is itself a compliance requirement.", "Scanning for PII at ingestion only and not re-scanning after data transformations that might recombine quasi-identifiers." ] }, "validation": { "design_check": [ "Data necessity assessment is conducted for each training dataset; results are documented and approved before dataset is used in training. [ref:gdpr]", "PII scanning covers direct identifiers, quasi-identifiers, and sensitive categories and is applied after each transformation step. [ref:gdpr]", "Fairness audit vault has documented access controls, time-bounded grants, and access logging; access is restricted to roles with explicit need. [ref:eu_ai_act_art10]", "Synthetic data replacement policy is documented and synthetic datasets have re-identification risk assessments. [ref:nist_ai_rmf_1_0]" ], "runtime_test": [ "Run PII scanner against a training dataset sample known to contain PII; verify detection rate exceeds documented threshold. [ref:gdpr]", "Attempt to access fairness audit vault without the required role; verify access is denied and alert is generated. [ref:eu_ai_act_art10]", "Submit a training dataset with undeclared PII fields; verify that the pipeline gate blocks training until necessity assessment is completed. [ref:gdpr]" ], "evidence": [ "model:data-necessity-assessment-records-for-al — Data necessity assessment records for all training datasets, with approval signatures. [ref:gdpr]", "model:pii-scanning-run-logs-with-detection-cou — PII scanning run logs with detection counts and remediation records. [ref:gdpr]", "model:fairness-audit-vault-access-logs-for-the — Fairness audit vault access logs for the retention window. [ref:eu_ai_act_art10]" ] }, "lenses": { "engineering": "Integrate PII scanning into the data ingestion pipeline using automated scanners (e.g., Microsoft Presidio, custom NER models) with scanning after each transformation step. Implement vault access as a service with short-lived tokens and mandatory access-reason logging.", "evaluation": "Verify that models trained on de-identified data do not memorize PII from pre-training — run membership inference and PII extraction probes as part of evaluation (EV-06). Validate that fairness audit vault access does not create a side channel for PII exposure.", "red_team": "Probe model outputs for PII memorization via targeted prompting and extraction attacks. Attempt vault access bypass through indirect paths. Test whether de-identified training records can be re-identified using auxiliary data.", "grc": "GDPR Art. 5(1)(c) minimization and Art. 25 by-design requirements must be documented with necessity assessments as evidence. EU AI Act Art. 10(5) provides the specific carve-out for protected attribute processing for bias detection — document this legal basis explicitly when invoked. Coordinate with DPA for high-risk processing.", "mlops": "Track PII scan detection rates and false-positive rates as data pipeline quality metrics. Alert on unexpected spikes in PII detections after pipeline changes. Monitor vault access frequency as an anomaly signal." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers training-data minimization. Inference-time PII in user inputs is addressed in BH layer. Model memorization probing is addressed in EV-06. Differential privacy for training is a separate engineering control not fully specified here.", "obligations": [ { "id": "gdpr_art5_1c", "text": "GDPR Art. 5(1)(c) — data minimisation: personal data must be adequate, relevant and limited to what is necessary for the purpose", "jurisdiction": [ "eu" ], "binding": true, "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2016/679", "source_ref": "gdpr", "normative_force": "binding-law", "legal_status": "enacted", "provision": "Article 5(1)", "effective_from": "2018-05-25" }, { "id": "gdpr_art25", "text": "GDPR Art. 25 — data protection by design and by default: controller must implement minimisation by design", "jurisdiction": [ "eu" ], "binding": true, "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2016/679", "source_ref": "gdpr", "normative_force": "binding-law", "legal_status": "enacted", "provision": "Article 25", "effective_from": "2018-05-25" }, { "id": "eu_ai_act_art10_5", "text": "EU AI Act Art. 10(5) — processing of special category data is permitted to the extent strictly necessary for bias detection and correction, with appropriate safeguards", "jurisdiction": [ "eu" ], "binding": true, "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "legal_status": "enacted", "provision": "Article 10", "effective_from": "2027-08-02" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-10", "mapping_fit": "partial", "notes": "Art-10 requires that training, validation and testing data for high-risk AI systems meet quality criteria including relevance, representativeness, freedom from errors and appropriate privacy protections.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.10", "fit": "direct", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.10 (MEASURE function) provides that privacy risk of the AI system is examined and documented. TG-06’s sensitive-data necessity assessment and minimization controls examine and reduce the privacy risk carried into the model through training data.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "subcategory": "MEASURE-2.10" }, "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.7.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.7.2 (Data for development and enhancement) requires defining and documenting the data needed for development. TG-06’s necessity assessment and minimization controls keep that definition limited to justified data.", "reviewed_on": "2026-06-26", "source_version": "2023", "source_locator": { "section": "Annex A", "clause": "A.7.2" }, "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-10", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Minimization controls implement EU AI Act data governance and special-category processing requirements", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "source_locator": { "section": "Chapter III, Section 2 — Requirements for high-risk AI systems", "clause": "Article 10" }, "uncovered_portion": "Article 10 covers all high-risk AI training data requirements as a whole; this control addresses one specific sub-article provision rather than the full Article 10 obligation set.", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OWASP AISVS C1.1 (Training Data Origin & Data Security) requires that training data include only features required for the model's stated purpose (req 1.1.1), and C1.2 requires sensitive label content to be redacted or encrypted (1.2.3). TG-06's necessity and minimization controls implement these requirements.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "chapter": "C1.1", "chapter_name": "Training Data Origin & Data Security" }, "normative_force": "voluntary-standard", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "llm10", "requirement_id": "LLM04:2025", "fit": "partial", "direction": "control-supports-requirement", "rationale": "PII minimization reduces the PII payload available for model memorization and exfiltration", "reviewed_on": "2026-06-26", "source_version": "2025", "source_locator": { "section": "OWASP LLM Top 10 2025", "clause": "LLM04:2025" }, "uncovered_portion": "LLM04:2025 Data and Model Poisoning additionally covers fine-tuning data poisoning, reward model manipulation, and inference-time retrieval corpus poisoning.", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "aicm", "requirement_id": "DSP-16", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CSA AICM DSP-16 (Data Retention and Deletion) limits how long and in what form data may be held. TG-06’s necessity assessment and minimization controls apply the same restraint at collection and use time, keeping sensitive data out of training sets unless justified.", "reviewed_on": "2026-07-08", "source_version": "1.1", "source_locator": { "control_id": "DSP-16" }, "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "correction": "ai-exchange-verify 2026-07-08", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0024", "fit": "partial", "direction": "control-mitigates-risk", "rationale": "Minimizing PII in training data reduces the information available for model inversion and PII exfiltration attacks (AML.T0024 — Exfiltration via AI Inference API; membership inference and model inversion are its sub-techniques).", "uncovered_portion": "Runtime exfiltration controls addressed in BH layer", "reviewed_on": "2026-06-26", "source_version": "v2026.06", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "owasp_aitg", "requirement_id": "AITG-DAT-05", "fit": "direct", "direction": "control-supports-requirement", "rationale": "AITG-DAT-05 (Testing for Data Minimization and Consent) verifies that only necessary data is used and that sensitive data is handled with consent and controls. TG-06's necessity assessment, minimization, and controlled-use requirements directly implement what this test checks.", "source_locator": { "test_id": "AITG-DAT-05", "test_name": "Testing for Data Minimization and Consent" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "dataminimize", "fit": "direct", "rationale": "Limiting PII and protected-class data in training to what is strictly necessary is the minimize-sensitive-data-used control.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "obfuscatetrainingdata", "fit": "supporting", "rationale": "Applying de-identification, anonymization, or synthetic replacement to training data is the obfuscate-training-data-to-protect-privacy control.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "profiles": [ { "id": "eu-high-risk", "note": "Mandatory; GDPR minimization and EU AI Act Art. 10(5) safeguards must be documented; DPA consultation recommended before processing special-category data for bias detection" }, { "id": "us-regulated-banking", "note": "PII minimization required; coordinate with privacy counsel on GLBA, FCRA, and ECOA constraints on consumer data use in training" }, { "id": "generative-ai", "note": "Highest PII exposure risk from large-scale pre-training; PII scanning and redaction required before corpus inclusion; model memorization probing required post-training" }, { "id": "high-impact-decision", "note": "Protected-class attribute access controls are critical for decision-making models subject to anti-discrimination law — document Art. 10(5) or equivalent legal basis" }, { "id": "continuously-learning", "note": "Re-apply minimization controls to each incremental update batch; user interaction data used for online learning requires heightened scrutiny" } ], "enforcement_point": "dataset-approval and data-ingestion", "canonical_id": "apeiris://model/controls/TG-06", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "validation_objective": "Every training dataset containing PII or protected-class attributes has a documented necessity assessment with named approver sign-off confirming that the data cannot be substituted with de-identified or synthetic alternatives. When protected attributes are retained for bias auditing, they are stored exclusively in a separately access-controlled fairness audit vault — not in the general training corpus — with time-bounded, logged access for each session.", "evidence_required": [ "data_necessity_assessment_record with dataset_id, PII categories identified (name/email/SSN/biometric/protected-class), justification for necessity over de-identified alternatives, and approver_identity with approval_timestamp", "PII_scan_run_log showing scanner tool, dataset version, detection count per PII category, and remediation action per detected item (de-identified / synthetic-replaced / retained-in-fairness-vault)", "fairness_audit_vault_access_log for the retention window, listing accessor_identity, purpose, authorization_record_id, and session_duration for every vault access", "synthetic_data_provenance_record for any PII replaced with synthetic proxies, confirming generation method and confirming synthetic records cannot be re-linked to real individuals via quasi-identifiers" ], "machine_tests": [ "Run PII scanning tool against a dataset containing injected known-PII examples (email, SSN, full name, phone) → assert scanner detects 100% of injected instances with no false negatives for standard PII categories", "Attempt to access protected-attribute vault data without a valid time-bounded authorization record → assert access is denied with error=unauthorized_vault_access", "Submit a training dataset for pipeline approval without a completed necessity assessment record → assert approval workflow blocks the dataset from entering the training pipeline with error=missing_necessity_assessment" ], "human_review": [ "Review necessity assessment records for genuine evaluation of less-invasive alternatives: confirm that each PII category is individually justified and that de-identification and synthetic replacement were substantively considered rather than cursorily dismissed", "Assess fairness audit vault access logs to confirm that protected-attribute access is scoped exclusively to documented bias auditing activities and that no vault sessions were used for model training data preparation purposes" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Retaining full PII in training corpora without a documented necessity justification, treating data minimization as a post-processing step rather than a pre-training approval gate", "Conflating fairness audit access to protected attributes with permission to include those attributes directly in the training corpus, bypassing minimization requirements on the grounds that the data serves a legitimate fairness purpose", "Applying de-identification techniques such as name replacement without scanning the residual dataset for PII that persists in free-text fields, metadata, or quasi-identifier combinations", "Maintaining a single access-controlled dataset containing both the full training corpus and the fairness audit protected-attribute subset, rather than a separately vaulted protected-attribute store with distinct access controls", "Treating synthetic data replacement as automatically GDPR-compliant without verifying that synthetic records cannot be re-linked to source individuals via shared quasi-identifiers present in the training corpus" ], "update_status": "current", "layer_code": "TG" }, { "id": "TG-07", "layer": "TG", "plane": "data", "name": "Third-Party Dataset Governance", "plain": "Establish due-diligence, contracting, and ongoing monitoring requirements for all externally sourced training datasets, including provenance verification, license term compliance, version pinning, update notification, access controls, and supply-chain integrity verification.", "threat": { "tags": [ "AML.T0018", "LLM04:2025", "MR-DEV" ], "desc": "Third-party datasets are the highest-risk supply chain vector for training data poisoning, license violations, and unknown data quality defects. Vendors may update datasets without notice, removing quality assurances relied upon at training time and introducing new risks silently." }, "standard": [ "ISO/IEC 42001:2023 A.7.5", "NIST AI RMF GOVERN 6.1", "MITRE ATLAS v5.6.0 AML.T0018", "EU AI Act Art. 10(2)(c)", "SR 26-2 Sec. VII (Vendor and Other Third-Party Products)" ], "sources": [ { "id": "mitre_atlas_v5_6_0", "title": "MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems", "authority": "MITRE Corporation", "source_type": "threat-knowledge-base", "license": "public", "artifact_hash": null, "status": "current", "normative_force": "best-practice", "version": "5.6.0", "published_on": "2026-05-04", "retrieved_on": "2026-06-26", "source_id": "mitre_atlas", "relationship": "informative_reference", "rationale": "Establishes MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems requirements informing the apeiris://model/controls/TG-07 Third-Party Dataset Governance control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_llm10_2025", "title": "OWASP Top 10 for LLM Applications 2025", "authority": "OWASP Foundation", "source_type": "voluntary-standard", "license": "CC BY-SA 4.0", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2025", "published_on": "2024-11-17", "retrieved_on": "2026-06-26", "source_id": "owasp_llm10", "relationship": "implementation_pattern", "rationale": "Establishes OWASP Top 10 for LLM Applications 2025 requirements informing the apeiris://model/controls/TG-07 Third-Party Dataset Governance control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/TG-07 Third-Party Dataset Governance control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "NIST", "source_type": "voluntary-standard", "license": "public_domain", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/TG-07 Third-Party Dataset Governance control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_art10", "title": "EU AI Act — Article 10: Data and Data Governance", "authority": "European Parliament and Council", "source_type": "regulation", "license": "public", "artifact_hash": null, "status": "current", "retrieved_on": "2026-06-26", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act — Article 10: Data and Data Governance requirements informing the apeiris://model/controls/TG-07 Third-Party Dataset Governance control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "title": "SR 26-2: Revised Guidance on Model Risk Management", "authority": "Federal Reserve Board", "source_type": "supervisory-guidance", "license": "public", "artifact_hash": null, "supersedes": [ "SR 11-7", "SR 21-8" ], "status": "current", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/TG-07 Third-Party Dataset Governance control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Maintain a Third-Party Dataset Registry (TPDR) that captures due-diligence findings, license terms, provenance claims, version pins, and ongoing monitoring status for every externally sourced dataset. New datasets require security and legal review before approval; dataset updates require re-review before training use.", "steps": [ "Create a TPDR entry for every third-party dataset before it enters the training pipeline: vendor identity, dataset version/release, provenance claims, license type and terms, collection methodology, intended use restrictions, and contact for update notifications.", "Conduct security due diligence: verify vendor-provided checksums independently; review vendor's data collection and quality assurance practices; assess vendor security posture.", "Conduct legal due diligence: review license terms for AI training permissions, sublicensing rights, attribution requirements, and any use-case restrictions.", "Pin to a specific versioned release; block training pipelines from pulling 'latest' from external sources without a new TPDR review.", "Establish update notification agreements with vendors; define SLAs for reviewing and approving dataset updates before they enter training.", "Apply the same TG-04 integrity controls (hash pinning, chain-of-custody) to all third-party dataset shards without exception.", "Monitor vendor security posture and supply chain integrity; subscribe to vendor security advisories.", "Conduct annual re-review of all active third-party dataset TPDR entries." ], "anti_patterns": [ "Pinning to a version range or 'latest' tag instead of an exact versioned release.", "Treating public domain or Creative Commons datasets as requiring no due diligence — license terms and data quality still require review.", "Not establishing update notification channels with vendors — dataset changes can introduce new legal or quality risks silently.", "Using a dataset in training that was approved for a different model or use case without re-reviewing applicability.", "Omitting hash verification for datasets obtained from CDNs or mirrors — the canonical source hash must be verified." ] }, "validation": { "design_check": [ "TPDR exists and has entries for all third-party datasets; entries include version pin, license terms, provenance claims, and security/legal review sign-offs. [ref:iso_42001_2023]", "Training pipelines are configured to pull only pinned versioned releases; 'latest' references are blocked at the pipeline gate. [ref:nist_ai_rmf_1_0]", "Update notification process is established with vendors; pipeline blocks updated dataset versions pending re-review. [ref:mitre_atlas_v5_6_0]", "TG-04 integrity controls (hash pinning, chain-of-custody) are applied to all third-party dataset shards without exception. [ref:mitre_atlas_v5_6_0]" ], "runtime_test": [ "Attempt to add an unpinned ('latest') dataset reference to the training pipeline; verify the gate blocks submission. [ref:nist_ai_rmf_1_0]", "Simulate a dataset update from a vendor (new version with modified records); verify pipeline detects version mismatch and requires re-review before training. [ref:mitre_atlas_v5_6_0]", "Substitute a third-party dataset shard with a modified version and verify TG-04 hash verification catches the substitution. [ref:mitre_atlas_v5_6_0]" ], "evidence": [ "model:third-party-dataset-registry-with-entrie — Third-Party Dataset Registry with entries for all active third-party datasets, showing current approval status and review dates. [ref:iso_42001_2023]", "model:security-and-legal-due-diligence-records — Security and legal due-diligence records for each TPDR entry. [ref:nist_ai_rmf_1_0]", "model:update-notification-logs-and-re-review-r — Update notification logs and re-review records for dataset updates received during the retention window. [ref:mitre_atlas_v5_6_0]" ] }, "lenses": { "engineering": "Implement TPDR as a machine-readable catalog integrated with the training pipeline gate. Use cryptographically signed TPDR entries to prevent tampering. Implement automated version-pin enforcement in data ingestion tooling.", "evaluation": "Independent validation (EV-01) must verify that all third-party datasets used in a model have valid, current TPDR entries. Evaluators should probe for datasets used in training that are not listed in TPDR.", "red_team": "Attempt supply chain attacks via compromised vendor CDN, DNS hijacking of dataset download URLs, or man-in-the-middle substitution. Test whether unpinned dataset references can be introduced through indirect pipeline paths. Probe for datasets used in training with no TPDR entry.", "grc": "TPDR is the primary evidence artifact for third-party data supply chain governance. SR 26-2 §V third-party risk requirements apply to dataset vendors. EU AI Act Art. 10(2)(c) requires documentation of data origin — TPDR entries satisfy this requirement.", "mlops": "Surface TPDR status in the dataset catalog UI. Alert on TPDR entries approaching annual re-review deadline. Integrate vendor security advisory feeds into TPDR monitoring workflow." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers governance of externally sourced batch datasets. Governance of third-party model components (foundation models, embeddings) is addressed in the LI layer. API-sourced streaming data pipelines require a separate streaming data governance framework.", "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-6.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-6.1 (GOVERN function) provides that policies address AI risks associated with third-party entities, including IP-infringement risks. TG-07’s third-party dataset registry, version pinning, and due-diligence records implement those policies for externally sourced training data.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "subcategory": "GOVERN-6.1" }, "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.7.5", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.7.5 (Data provenance) requires provenance documentation for data used in AI systems. TG-07’s third-party dataset registry and vendor checksum verification extend provenance assurance to externally sourced data.", "reviewed_on": "2026-06-26", "source_version": "2023", "source_locator": { "section": "Annex A", "clause": "A.7.5" }, "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-10", "fit": "partial", "direction": "control-supports-requirement", "rationale": "TPDR provides documentation of data origin required by EU AI Act for high-risk AI", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "source_locator": { "section": "Chapter III, Section 2 — Requirements for high-risk AI systems", "clause": "Article 10" }, "uncovered_portion": "Article 10 covers all high-risk AI training data requirements as a whole; this control addresses one specific sub-article provision rather than the full Article 10 obligation set.", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OWASP AISVS C1.1 (Training Data Origin & Data Security) requires a source inventory with origin, responsible party, and collection method for every training-data source (req 1.1.2). TG-07's third-party dataset registry and due-diligence records satisfy that inventory for external data.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "chapter": "C1.1", "chapter_name": "Training Data Origin & Data Security" }, "normative_force": "voluntary-standard", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "llm10", "requirement_id": "LLM03:2025", "fit": "partial", "direction": "control-mitigates-risk", "rationale": "Third-party dataset governance directly mitigates LLM supply chain and poisoning risks", "reviewed_on": "2026-06-26", "source_version": "2025", "source_locator": { "section": "OWASP LLM Top 10 2025", "clause": "LLM03:2025" }, "uncovered_portion": "LLM03:2025 Supply Chain additionally covers vulnerable pre-trained model adoption, third-party plugin risks, outdated component risks, and model provider dependency management.", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "aicm", "requirement_id": "STA-08", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CSA AICM STA-08 (supply chain risk management) covers assessing and monitoring risks from third-party suppliers. TG-07’s dataset vendor due diligence, checksum verification, and version pinning implement supply-chain risk management for training data.", "reviewed_on": "2026-06-26", "source_version": "1.1", "source_locator": { "control_id": "STA-08" }, "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0018", "fit": "partial", "direction": "control-mitigates-risk", "rationale": "TPDR and version pinning directly mitigate the ATLAS supply chain compromise technique for training data", "uncovered_portion": "Model supply chain compromise (foundation models) is addressed in LI layer", "reviewed_on": "2026-06-26", "source_version": "v2026.06", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "owasp_aitg", "requirement_id": "AITG-INF-01", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AITG-INF-01 (Testing for Supply Chain Tampering) includes tampering with externally sourced components of the training pipeline. TG-07's vendor checksum validation and third-party dataset due diligence reduce the exposure this test probes for training data specifically.", "source_locator": { "test_id": "AITG-INF-01", "test_name": "Testing for Supply Chain Tampering" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "sr262", "requirement_id": "Sec. VII", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. VII (Vendor and Other Third-Party Products) describes due diligence and risk management for third-party products used in modeling, which extends to externally sourced data. TG-07's third-party dataset due diligence and integrity verification support that expectation. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "source_locator": { "section": "Sec. VII (Vendor and Other Third-Party Products)" }, "source_version": "SR 26-2", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "supervisory-guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "supplychainmanage", "fit": "direct", "rationale": "Due diligence, version pinning, and integrity verification for externally sourced datasets is managing the data portion of the AI supply chain.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0023", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every externally sourced training dataset in active use has a current Third-Party Dataset…\" enacts ATLAS mitigation AML.M0023 AI Bill of Materials; complements the control’s existing technique mapping AML.T0018 (defends_against) — OpenCRE crosswalks the AI Exchange concept (supplychainmanage) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0014", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every externally sourced training dataset in active use has a current Third-Party Dataset…\" enacts ATLAS mitigation AML.M0014 Verify AI Artifacts; complements the control’s existing technique mapping AML.T0018 (defends_against) — OpenCRE crosswalks the AI Exchange concept (supplychainmanage) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.05", "fit": "supporting", "rationale": "Control \"Every externally sourced training dataset in active use has a current Third-Party Dataset…\" defends against NIST AI 100-2 attack class NISTAML.05 \"Supply Chain Attacks\"; OpenCRE crosswalks this control’s OWASP AI Exchange concept (supplychainmanage) to this NIST class. (Anchor captures the attack taxonomy, so we cite the threat class as defends_against, not the NIST mitigation named by OpenCRE.)", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against", "mapping_confidence": "medium", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "profiles": [ { "id": "frontier-capability", "note": "Critical; large-scale pre-training corpora sourced from third parties require elevated due diligence and continuous vendor monitoring" }, { "id": "eu-high-risk", "note": "Required; TPDR entries must be included in EU AI Act technical documentation; data origin documentation is mandatory per Annex IV" }, { "id": "us-regulated-banking", "note": "Required per SR 26-2 §V; third-party dataset vendors may constitute third-party service providers requiring vendor risk management program coverage" }, { "id": "generative-ai", "note": "Apply to all pre-training corpus sources; copyright and license review is critical given generative AI IP litigation environment" } ], "enforcement_point": "dataset-approval and training-pipeline-entry", "canonical_id": "apeiris://model/controls/TG-07", "capability_risk": { "capability_level": "frontier", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-10", "mapping_fit": "partial", "notes": "Art-10 requires that training, validation and testing data for high-risk AI systems meet quality criteria including relevance, representativeness, freedom from errors and appropriate privacy protections.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "Every externally sourced training dataset in active use has a current Third-Party Dataset Registry entry with a valid security and legal review, version-pinned artifact hash, and license compliance record. No third-party dataset update enters training without a completed re-review gate, and artifact integrity is verified by hash comparison against vendor-published checksums before each training use.", "evidence_required": [ "third_party_dataset_registry_entry for each active external dataset containing: dataset_id, vendor_name, license_terms, version_pin with artifact_hash, approval_date, reviewer_identity, legal_review_outcome, and security_review_outcome", "artifact_integrity_verification_log per training run showing hash comparison between locally stored dataset artifact and vendor-published checksum, with pass/fail result", "update_notification_record documenting each vendor-issued dataset update notice received, with quarantine status and re-review outcome (approved / rejected / paused-pending-review)", "license_compliance_attestation confirming permitted training use, output rights, and any attribution or restriction requirements for each active third-party dataset" ], "machine_tests": [ "Modify a third-party dataset artifact locally without updating the registry hash → assert pipeline integrity check detects hash mismatch and blocks the training run with error=artifact_integrity_failure", "Submit a training job referencing a third-party dataset with an expired or absent registry approval → assert pipeline gate returns error=third_party_dataset_unapproved and training does not proceed", "Simulate receipt of a vendor update notification for a pinned dataset → assert the updated artifact is quarantined from training use until re-review completes and a new approval record is issued" ], "human_review": [ "Review Third-Party Dataset Registry entries for completeness: confirm that license terms were reviewed by legal counsel and that training use is explicitly permitted under each dataset's current terms — not assumed from initial acquisition", "Assess security due-diligence records for high-risk external datasets (large web crawls, social media corpora) to confirm that data poisoning risk and quality defect analysis was performed and documented before approval", "Verify that dataset update notification processes are operational and monitored: registry entries with no update activity for > 12 months should be flagged for active revalidation with the vendor" ], "blocking_effect": "blocks-deployment", "normative_status": "voluntary-standard", "anti_patterns": [ "Re-downloading third-party datasets without verifying artifact hashes against registry-pinned checksums, allowing silently modified or substituted dataset content to enter training without detection", "Treating a one-time legal review at initial acquisition as permanent license clearance, without re-checking when datasets are updated or vendor licensing terms change", "Version-pinning dataset names (e.g., 'CommonCrawl 2024') without pinning artifact hashes, allowing vendor-side content changes to silently affect training data composition", "Relying exclusively on vendor security assurances rather than performing an independent data quality and poisoning risk assessment for high-risk web-crawled or social-media-sourced datasets", "Maintaining no vendor update notification mechanism, discovering dataset composition changes only retrospectively when training metrics shift unexpectedly" ], "update_status": "current", "layer_code": "TG" }, { "id": "TG-08", "layer": "TG", "plane": "data", "name": "Dataset Retention, Deletion and Lifecycle", "plain": "Define and enforce a training artifact lifecycle policy covering retention periods, deletion procedures for raw and derived artifacts, GDPR Art. 17 and CCPA erasure operationalization, and audit trail preservation distinct from operational data deletion.", "threat": { "tags": [ "MR-DEV", "EU-AIA-AnnexIII" ], "desc": "Unmanaged retention of training data and derived artifacts creates ongoing regulatory liability under GDPR and CCPA erasure obligations, security exposure from stale sensitive data, and operational confusion from training on superseded or legally contested data. Failure to distinguish raw training data from derived model artifacts leads to incorrect deletion scope and potential regulatory non-compliance." }, "standard": [ "GDPR Art. 5(1)(e) — storage limitation", "GDPR Art. 17 — right to erasure", "CCPA/CPRA §1798.105", "EU AI Act Art. 10(2), Annex IV §2", "ISO/IEC 42001:2023 A.7.2" ], "sources": [ { "id": "gdpr", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council", "source_type": "regulation", "license": "public", "artifact_hash": null, "status": "current", "normative_force": "binding-law", "version": "2016/679", "published_on": "2018-05-25", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://model/controls/TG-08 Dataset Retention, Deletion and Lifecycle control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_annex_iv", "title": "EU AI Act — Annex IV: Technical Documentation", "authority": "European Parliament and Council", "source_type": "regulation", "license": "public", "artifact_hash": null, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act — Annex IV: Technical Documentation requirements informing the apeiris://model/controls/TG-08 Dataset Retention, Deletion and Lifecycle control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra", "title": "California Consumer Privacy Act / California Privacy Rights Act — Cal. Civ. Code §1798.100 et seq.", "authority": "California Legislature", "source_type": "regulation", "license": "public", "artifact_hash": null, "status": "current", "normative_force": "binding-law", "version": "2023", "published_on": "2023-01-01", "retrieved_on": "2026-06-26", "source_id": "ccpa", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act / California Privacy Rights Act — Cal. Civ. Code §1798.100 et seq. requirements informing the apeiris://model/controls/TG-08 Dataset Retention, Deletion and Lifecycle control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "authority": "ISO/IEC JTC 1/SC 42", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/TG-08 Dataset Retention, Deletion and Lifecycle control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Implement a Data Lifecycle Policy (DLP) that classifies training artifacts into categories and assigns retention periods, deletion procedures, and hold exceptions for each. Erasure requests trigger automated propagation across all artifact categories with documented impact assessment for trained models.", "steps": [ "Classify all training-related artifacts: raw source data, ingested and processed training datasets, training data shards, model checkpoints, evaluation datasets, experiment metadata, quality attestations, and audit logs.", "Define retention periods per artifact class and jurisdiction: raw training data (shortest operationally feasible period; minimum legally required where mandated); model checkpoints (aligned to post-deployment audit window); audit logs (longest applicable regulatory retention — typically 7-10 years for financial institutions).", "Distinguish between deletion of raw training data (fully deletable) and removal from derived model artifacts (machine unlearning or model retraining may be required — document the technical limitations and legal position explicitly).", "Implement GDPR Art. 17 erasure workflows: deletion request received → search across all artifact categories → deletion of raw records → impact assessment for derived models → documented response to data subject within Art. 17 timeframe (one month, extendable to three with notice).", "For CCPA §1798.105 deletion requests from California residents: implement equivalent workflow with 45-day response timeline.", "Implement litigation hold procedures that freeze deletion of specified artifacts without extending retention for non-held artifacts.", "Enforce deletion at the storage layer using cryptographic key destruction (for encrypted stores) or verified overwrite with deletion certificates.", "Conduct annual lifecycle policy reviews to incorporate regulatory developments in machine unlearning obligations." ], "anti_patterns": [ "Treating model weights as containing no personal data and therefore outside the scope of erasure obligations — regulators are increasingly examining this position.", "Retaining all training artifacts indefinitely 'for reproducibility' without a documented legal basis for extended retention.", "Using a single retention period for all artifact types — raw PII-containing training data and anonymized evaluation artifacts have different requirements.", "Responding to erasure requests by deleting only the raw data store without propagating to processed datasets, training shards, and checkpoints.", "Providing misleading assurances that trained models have been 'cleansed' of erased data without documenting the technical limitations of machine unlearning." ] }, "validation": { "design_check": [ "Data Lifecycle Policy documents retention periods and deletion procedures for each artifact class with jurisdiction-specific treatment. [ref:gdpr]", "GDPR Art. 17 and CCPA §1798.105 erasure workflows are documented, tested, and include impact assessment for derived model artifacts. [ref:gdpr]", "Deletion is implemented at the storage layer (key destruction or verified overwrite) with deletion certificates produced. [ref:gdpr]", "Audit logs are subject to a separate, longer retention period and excluded from standard data deletion workflows; litigation hold procedures exist. [ref:sr262_2026]" ], "runtime_test": [ "Submit a simulated GDPR Art. 17 erasure request; verify deletion propagates across all artifact categories within the required timeframe and a deletion certificate is produced. [ref:gdpr]", "Verify that audit logs are not deleted when raw training data is purged on schedule. [ref:sr262_2026]", "Attempt to use an artifact past its documented retention date; verify the lifecycle management system flags or blocks access. [ref:iso_42001_2023]", "Submit a CCPA deletion request and verify the response timeline and artifact deletion scope meet California requirements. [ref:ccpa_cpra]" ], "evidence": [ "model:data-lifecycle-policy-document-with-rete — Data Lifecycle Policy document with retention schedules, deletion procedures, and jurisdiction-specific treatment. [ref:gdpr]", "model:erasure-request-processing-logs-with-art — Erasure request processing logs with artifact-category deletion records and deletion certificates. [ref:gdpr]", "model:annual-lifecycle-policy-review-records-s — Annual lifecycle policy review records showing consideration of regulatory developments including machine unlearning. [ref:iso_42001_2023]" ] }, "lenses": { "engineering": "Implement the DLP in the data catalog and storage management system as enforced metadata rules, not just documentation. Use cryptographic key destruction for encrypted training data stores to ensure deletion is technically verifiable. Automate retention schedule enforcement.", "evaluation": "Include DLP compliance in the model card: document which training dataset versions were used, their current retention status, and any erasure events that occurred post-training. Evaluators should flag models where training data retention status is unknown.", "red_team": "Probe whether erased data records can be recovered from backup systems, derivative datasets, or model outputs via memorization probing. Test whether litigation holds can be applied and released without affecting non-held artifact deletion schedules.", "grc": "GDPR Art. 5(1)(e) storage limitation and Art. 17 erasure are hard legal requirements. CCPA §1798.105 imposes parallel obligations in California. SR 26-2 requires record-keeping sufficient to support model validation and regulatory examination — coordinate with legal to ensure audit log retention satisfies both the longest retention obligation and applicable data protection minimization requirements. These obligations may conflict; document the resolution.", "mlops": "Integrate retention schedule enforcement into the data catalog; automate deletion triggers on retention expiry. Surface erasure request status in the ML platform dashboard. Alert on artifact stores approaching retention expiry that have not been scheduled for deletion." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers training-data and training-artifact lifecycle. Inference log retention is addressed in the CR layer. Machine unlearning is an emerging technical area; this control documents the obligation and current technical limitations but does not specify implementation — see cross_domain pointer to privacy controls domain.", "obligations": [ { "id": "gdpr_art5_1e", "text": "GDPR Art. 5(1)(e) — storage limitation: personal data must not be kept for longer than necessary for the specified purpose", "jurisdiction": [ "eu" ], "binding": true, "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2016/679", "source_ref": "gdpr", "normative_force": "binding-law", "legal_status": "enacted", "provision": "Article 5(1)", "effective_from": "2018-05-25" }, { "id": "gdpr_art17", "text": "GDPR Art. 17 — right to erasure: data subjects can request deletion; controller must comply within one month, extendable to three with notice", "jurisdiction": [ "eu" ], "binding": true, "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2016/679", "source_ref": "gdpr", "normative_force": "binding-law", "legal_status": "enacted", "provision": "Article 17", "effective_from": "2018-05-25" }, { "id": "ccpa_1798_105", "text": "CCPA/CPRA §1798.105 — California consumers have the right to request deletion of personal information; businesses must comply within 45 days", "jurisdiction": [ "us-california" ], "binding": true, "reviewed_on": "2026-06-26", "authority": "California Privacy Protection Agency", "instrument": "California Consumer Privacy Act (CCPA/CPRA)", "source_ref": "ccpa_cpra", "normative_force": "binding-law", "legal_status": "enacted", "provision": "§ 1798.105", "effective_from": "2023-01-01" }, { "id": "eu_ai_act_annex_iv", "text": "EU AI Act Annex IV §2 — technical documentation must include description of training data including provenance, requiring sufficient retention to reconstruct the documentation during the post-market monitoring period", "jurisdiction": [ "eu" ], "binding": true, "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "legal_status": "enacted", "provision": "Annex IV", "effective_from": "2027-08-02" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-10", "mapping_fit": "partial", "notes": "Art-10 requires that training, validation and testing data for high-risk AI systems meet quality criteria including relevance, representativeness, freedom from errors and appropriate privacy protections.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-1.1 (GOVERN function) provides that legal and regulatory requirements involving AI are understood, managed, and documented. TG-08’s retention and deletion controls operationalize the retention and erasure obligations that apply to training data under privacy and sector law.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "subcategory": "GOVERN-1.1" }, "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.7.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.7.2 (Data for development and enhancement) covers management of development data. TG-08’s retention, deletion, and lifecycle controls govern that data through end-of-life.", "reviewed_on": "2026-06-26", "source_version": "2023", "source_locator": { "section": "Annex A", "clause": "A.7.2" }, "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-10", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Retention for technical documentation and erasure obligations jointly shape the lifecycle policy for EU high-risk AI; these may conflict and the resolution must be documented", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "source_locator": { "section": "Chapter III, Section 2 — Requirements for high-risk AI systems", "clause": "Article 10" }, "uncovered_portion": "Article 10 covers all high-risk AI training data requirements as a whole; this control addresses one specific sub-article provision rather than the full Article 10 obligation set.", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OWASP AISVS C1.1 (Training Data Origin & Data Security) requires the training-data source inventory to track processing history and intended-use constraints (req 1.1.2). TG-08's retention, deletion, and lifecycle controls keep that inventory accurate through end-of-life; AISVS does not itself set retention requirements.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "chapter": "C1.1", "chapter_name": "Training Data Origin & Data Security" }, "normative_force": "voluntary-standard", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "llm10", "requirement_id": "LLM04:2025", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Lifecycle management reduces stale-data attack surface and enables removal of poisoned training data", "reviewed_on": "2026-06-26", "source_version": "2025", "source_locator": { "section": "OWASP LLM Top 10 2025", "clause": "LLM04:2025" }, "uncovered_portion": "LLM04:2025 Data and Model Poisoning additionally covers fine-tuning data poisoning, reward model manipulation, and inference-time retrieval corpus poisoning.", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "aicm", "requirement_id": "DSP-16", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CSA AICM DSP-16 (Data Retention and Deletion) requires defined retention periods and secure deletion for data. TG-08’s dataset retention schedule, deletion workflows, and right-to-erasure operationalization implement that lifecycle discipline for training data.", "reviewed_on": "2026-06-26", "source_version": "1.1", "source_locator": { "control_id": "DSP-16" }, "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0024", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Deleting unnecessary PII-containing training data reduces the payload available for inference-time exfiltration and model inversion attacks (AML.T0024 — Exfiltration via AI Inference API; membership inference and model inversion are its sub-techniques).", "reviewed_on": "2026-06-26", "source_version": "v2026.06", "source_locator": { "section": "MITRE ATLAS v5.6.0", "clause": "AML.T0024" }, "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "owasp_aitg", "requirement_id": "AITG-DAT-05", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AITG-DAT-05 (Testing for Data Minimization and Consent) treats retention limits and erasure as part of data minimization. TG-08's retention, deletion, and lifecycle controls (including right-to-erasure operationalization) supply the evidence this test looks for.", "source_locator": { "test_id": "AITG-DAT-05", "test_name": "Testing for Data Minimization and Consent" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "shortretain", "fit": "supporting", "rationale": "Enforcing retention periods and erasure-driven deletion of training artifacts implements the retain-data-for-the-shortest-necessary-time control.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "profiles": [ { "id": "eu-high-risk", "note": "Mandatory; GDPR Art. 17 erasure workflows required; EU AI Act Annex IV documentation retention must be balanced against storage limitation obligations — document the legal resolution" }, { "id": "us-regulated-banking", "note": "SR 26-2 minimum retention periods for model documentation apply; coordinate with legal on CCPA applicability for consumer-data training sets; retention and deletion obligations may conflict across regimes" }, { "id": "generative-ai", "note": "Machine unlearning obligations for large pre-training corpora are legally and technically complex — engage legal counsel; document current technical limitations in DLP explicitly" }, { "id": "frontier-capability", "note": "Long retention periods for safety-relevant training documentation may be required by applicable safety frameworks; document legal basis for extended retention and obtain DPA consultation if personal data is involved" } ], "cross_domain": { "pointer": "privacy-controls:PC-08", "relationship": "machine_unlearning_technical_implementation", "note": "Machine unlearning technical implementation standards are defined in the privacy-controls domain. TG-08 documents the obligation; PC-08 specifies the implementation pattern." }, "enforcement_point": "data-catalog and storage-management", "canonical_id": "apeiris://model/controls/TG-08", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "validation_objective": "All training artifacts are classified under the Data Lifecycle Policy with documented retention periods and deletion procedures, and erasure requests trigger automated deletion propagation across all affected artifact categories within the defined SLA. Audit trail records for erasure events are retained separately from the deleted data and remain accessible for the full compliance retention window after deletion.", "evidence_required": [ "data_lifecycle_policy_document with retention schedules per artifact category (raw training data, derived features, trained model weights, evaluation results, experiment tracker copies, backups), deletion procedures, and jurisdiction-specific treatment for GDPR Art. 17 and CCPA erasure", "erasure_request_processing_log with request_id, requesting_party, data_subject_reference, artifact_categories_affected, deletion_timestamp per category, and deletion_certificate signed by the processing system", "model_impact_assessment_record for each erasure request affecting data used in a trained model, documenting residual memorization risk, whether retraining or machine unlearning is required, and the decision rationale with named approver", "annual_lifecycle_policy_review_record confirming that retention schedules and deletion procedures were reviewed against current regulatory requirements including machine unlearning developments and GPAI data governance obligations" ], "machine_tests": [ "Submit a synthetic erasure request for a data subject whose records exist across training data, derived features, and experiment tracker → assert deletion is propagated to all artifact categories within SLA and a multi-category deletion_certificate is issued", "Attempt to retrieve a training artifact whose retention period has elapsed and deletion was executed → assert retrieval returns error=artifact_deleted with reference to the deletion_certificate_id", "Verify that deletion of raw training data does not remove the corresponding erasure audit trail record → assert audit log entry for the deleted artifact remains accessible in the compliance audit store after deletion" ], "human_review": [ "Review model impact assessment records for erasure requests to confirm that residual risk from trained model memorization is substantively addressed — either through documented machine unlearning, model retraining, or named risk-acceptance with a remediation timeline", "Assess annual lifecycle policy review records to confirm that deletion procedures address GDPR Art. 17 and CCPA requirements, and that the organization has a documented, current position on machine unlearning obligations rather than treating them as a deferred future consideration", "Verify that deletion certificates are retained in a compliance audit trail that is physically and logically separate from the deleted data stores, and can be produced for regulatory inspection without requiring access to systems that held the deleted data" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Treating trained model weights as outside the scope of GDPR Art. 17 erasure obligations because they are 'derived artifacts', without assessing whether the model memorized and can reproduce the erased individual's personal data", "Applying a single retention period to all training artifact categories regardless of sensitivity and regulatory classification, risking both over-retention of PII and under-retention of artifacts needed for model validation audit", "Deleting erasure audit trail records concurrently with the operational data they document, destroying the evidence needed to demonstrate GDPR Art. 17 compliance to a supervisory authority", "Processing erasure requests only against the primary training dataset storage location without propagating deletion to derived features, experiment tracker copies, evaluation result stores, and backup systems", "Maintaining no documented organizational position on machine unlearning, treating model retraining upon erasure requests as a future capability rather than a current compliance risk requiring a defined response policy" ], "update_status": "current", "layer_code": "TG" }, { "id": "EV-01", "layer": "EV", "plane": "both", "name": "Pre-Deployment Evaluation Gate", "plain": "No model reaches production without a documented, signed, and auditable evaluation run. The gate is enforced as a blocking pipeline stage; a passing signed evaluation manifest is a mandatory precondition for any deployment decision.", "threat": { "tags": [ "MR-VAL", "MR-PERFORMANCE" ], "desc": "Deploying models without formal evaluation gates allows undetected capability regressions, safety failures, or policy violations to reach production users with no audit trail of the decision basis." }, "standard": [ "NIST AI RMF GOVERN 1.4", "NIST AI RMF MANAGE 1.1", "ISO/IEC 42001:2023 A.6.2.4", "EU AI Act Art. 9", "SR 26-2 Sec. V (Model Validation and Monitoring)" ], "obligations": [ { "id": "EU-AIA-Art9-risk-mgmt", "text": "EU AI Act Article 9 requires high-risk AI systems to establish, implement, and document a risk management system that includes evaluation and testing procedures, and that these are completed before market placement or putting into service.", "jurisdiction": [ "eu" ], "binding": true, "effective_date_standalone_high_risk": "2027-12-02", "effective_date_product_embedded": "2028-08-02", "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "legal_status": "enacted", "provision": "Article 9", "effective_from": "2027-12-02" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-9", "mapping_fit": "partial", "notes": "Art-9 requires providers to establish, implement, document and maintain a risk management system throughout the lifecycle of a high-risk AI system.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://airc.nist.gov/RMF", "source_type": "voluntary-standard", "license": "public-domain", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/EV-01 Pre-Deployment Evaluation Gate control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "url": "https://www.iso.org/standard/81230.html", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/EV-01 Pre-Deployment Evaluation Gate control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "authority": "European Parliament and Council", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "source_type": "regulation", "license": "public", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/EV-01 Pre-Deployment Evaluation Gate control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Revised Guidance on Model Risk Management", "url": "https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm", "source_type": "supervisory-guidance", "license": "public", "artifact_hash": null, "supersedes": [ "SR 11-7", "SR 21-8" ], "status": "current", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/EV-01 Pre-Deployment Evaluation Gate control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Gate-based deployment pipeline with signed evaluation manifests as mandatory, blocking preconditions for production promotion.", "steps": [ "Define the minimum evaluation suite required for each model risk tier before any deployment decision; document in the model governance policy.", "Integrate the evaluation gate as a blocking stage in the CI/CD or MLOps pipeline — deployment cannot proceed without a valid, signed evaluation manifest that references the exact model artifact hash.", "Generate a signed evaluation manifest capturing: model artifact hash, evaluation suite version and hash, run timestamp, environment specification, approver identities, and overall pass/fail determination.", "Store evaluation manifests in an append-only, tamper-evident log (e.g., Sigstore Rekor, internal transparency log) with entries linked to the artifact hash.", "Require dual-approval — authoring team lead and an independent reviewer — before the gate is marked passed; see EV-08 for separation-of-duties requirements.", "Retain signed manifests for the operational lifetime of the model plus any regulatory minimum retention period applicable to the deployment jurisdiction." ], "anti_patterns": [ "Allowing pipeline bypass under time pressure without a documented, risk-accepted exception with named approver and time-bound remediation commitment.", "Treating evaluation as a post-deployment activity or retroactive documentation exercise.", "Signing evaluation records with shared or role-based credentials that prevent individual attribution of approval decisions.", "Re-using a prior model version's evaluation manifest for a new artifact without re-running evaluation on the new artifact hash." ] }, "validation": { "design_check": [ "Pipeline configuration enforces evaluation gate as a blocking stage with no undocumented bypass path; gate failure produces an auditable rejection record. [ref:nist_ai_rmf_1_0]", "Evaluation manifest schema includes required fields: model_artifact_hash, eval_suite_version, eval_suite_hash, run_timestamp, environment_spec, approver_ids, gate_result. [ref:iso_42001_2023]", "Signing infrastructure uses non-repudiable, individually attributed key material (HSM-backed or equivalent); shared signing keys are prohibited. [ref:iso_42001_2023]", "Retention policy for evaluation manifests meets or exceeds the longer of: operational model lifetime or applicable regulatory minimum for each jurisdiction in scope. [ref:eu_ai_act_2024]" ], "runtime_test": [ "{'test': 'Attempt a deployment without a valid signed evaluation manifest and verify the pipeline blocks with an auditable rejection record containing the attempted artifact hash.', 'unverified': True} [unverified]", "{'test': 'Verify that the model artifact hash embedded in the evaluation manifest exactly matches the hash of the artifact being promoted to production.', 'ref': 'nist_rmf_v1'} [ref:nist_ai_rmf_1_0]", "{'test': 'Confirm that evaluation manifests appear in the tamper-evident log and that log integrity verification (inclusion proof) passes for each manifest.', 'unverified': True} [unverified]" ], "evidence": [ "model:signed-evaluation-manifest-for-each-prod — Signed evaluation manifest for each production model version, stored in the tamper-evident log. [ref:iso_42001_2023]", "model:pipeline-execution-logs-showing-the-eval — Pipeline execution logs showing the evaluation gate blocking a promotion attempt when the manifest is absent or invalid. [unverified]", "model:dual-approval-records-linking-named-appr — Dual-approval records linking named approver identities to specific evaluation manifest hashes. [ref:sr262_2026]", "model:exception-log-documenting-any-gate-bypas — Exception log documenting any gate bypass approvals with named risk-accepter, rationale, and time-bound remediation commitment. [ref:sr262_2026]" ] }, "lenses": { "engineering": "Implement as a pipeline stage that consumes a signed evaluation manifest artifact; fail-closed with no default bypass; expose gate status as a first-class deployment artifact in the model registry.", "evaluation": "Define and version-control the minimum evaluation suite for each risk tier; sign all run outputs with individually attributed key material; ensure the manifest captures sufficient environment detail for reproducibility.", "red_team": "Attempt to forge or replay a prior evaluation manifest for a new artifact; probe for undocumented bypass paths in pipeline configuration; test whether the dual-approval mechanism can be circumvented by a single actor.", "grc": "Map gate requirements to EU AI Act Art. 9, SR 26-2 §III.B; document the exception approval chain; include evaluation gate policy in the model governance framework; track exception frequency as a governance KRI.", "mlops": "Integrate the gate as a first-class blocking stage in the MLOps platform; surface gate status and manifest hash on model registry cards; alert on any gate bypass event." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "EV-01 enforces gate existence and process. EV-10 enforces content-addressed provenance of evaluation records. Both controls are required together for complete deployment assurance.", "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE-1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MANAGE-1.1 (MANAGE function) provides that a determination is made whether the AI system achieves its intended purposes and whether development or deployment should proceed. EV-01’s pre-deployment evaluation gate is the mechanism that produces and enforces that go/no-go determination before release.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.4 (AI system verification and validation) requires verification and validation before deployment. EV-01’s evaluation gate is the blocking control where those results are checked.", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Art. 9 mandates testing and evaluation as part of the risk management system for high-risk AI systems before market placement.", "uncovered_portion": "EU AI Act does not specify pipeline-level technical enforcement or signing requirements.", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. V", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes validation of models before they are placed into use, with documented results. EV-01's pre-deployment evaluation gate operationalizes that expectation as a blocking release control. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 applies to $30B+ asset institutions; sub-threshold entities have no binding equivalent.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aisvs", "requirement_id": "C3.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OWASP AISVS C3.2 (Model Validation & Testing) requires models to undergo automated validation, safety evaluation, and output testing before deployment (req 3.2.1). EV-01's pre-deployment evaluation gate is the blocking control where that testing is enforced.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "chapter": "C3.2", "chapter_name": "Model Validation & Testing" }, "normative_force": "voluntary-standard", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "GRC-01", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CSA AICM GRC-01 (governance program policies and procedures) requires documented governance procedures; EV-01’s evaluation gate is the documented, enforced procedure governing model release decisions.", "uncovered_portion": "AICM does not specify technical gate enforcement or signing requirements.", "reviewed_on": "2026-06-26", "source_version": "1.1", "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "direction": "out-of-scope", "rationale": "MITRE ATLAS v5.6.0 addresses adversarial ML attack tactics, not deployment gate governance processes.", "reviewed_on": "2026-06-26", "source_version": "v2026.06", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "owasp_aitg", "requirement_id": "AITG-MOD-06", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AITG-MOD-06 (Testing for Robustness to New Data) evaluates whether a model performs reliably on data beyond its training distribution. EV-01's pre-deployment evaluation gate — benchmark selection, metric definition, and disaggregated accuracy assessment — is where that generalization evidence is produced and enforced.", "source_locator": { "test_id": "AITG-MOD-06", "test_name": "Testing for Robustness to New Data" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "continuousvalidation", "fit": "supporting", "rationale": "A blocking pre-deployment evaluation gate is the deployment-time enforcement point of validating the model against its requirements.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0008", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"No model artifact is promoted to production unless a signed evaluation manifest…\" enacts ATLAS mitigation AML.M0008 Validate AI Model; complements the control’s existing technique mapping AML.T0043 (defends_against) — OpenCRE crosswalks the AI Exchange concept (continuousvalidation) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "profiles": [ "general-predictive-ml", "generative-ai", "hosted-api", "continuously-learning", "high-impact-decision", "us-regulated-banking", "eu-high-risk", "frontier-capability" ], "assurance_target": { "what": "Every model artifact promoted to production has a signed, complete evaluation manifest in the tamper-evident log.", "how": "Pipeline gate enforcement + inclusion-proof verification against the transparency log.", "frequency": "Per deployment event." }, "canonical_id": "apeiris://model/controls/EV-01", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "validation_objective": "No model artifact is promoted to production unless a signed evaluation manifest referencing that artifact's exact hash is present in the tamper-evident evaluation log and has received dual approval from named, authorized approvers. The deployment pipeline enforces this as a cryptographic gate — an absent, unsigned, or hash-mismatched manifest results in an automatic pipeline block with no override path except a logged exception with named risk-accepter.", "evidence_required": [ "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory" ], "machine_tests": [ "Initiate a production deployment of a model artifact with no evaluation manifest in the log → assert pipeline returns status=blocked with error=missing_evaluation_manifest and deployment does not proceed", "Submit a deployment with a manifest signed by a key not in the trust store → assert pipeline gate rejects with error=invalid_manifest_signature", "Submit a deployment with a valid manifest referencing a different artifact hash than the candidate model → assert hash mismatch is detected and deployment is blocked with error=artifact_hash_mismatch", "Attempt deployment approval with a single approver identity when dual approval is required → assert pipeline returns error=insufficient_approvers and deployment does not proceed" ], "human_review": [ "Review dual-approval records to confirm that approvers are named individuals with documented authority for deployment decisions — not shared service accounts, group identities, or automated system principals — and that approver identities are verifiable from the credential store", "Examine any exception log entries for gate bypasses: review the rationale, named risk-accepter, time-bound remediation commitment, and escalation path for each bypass to confirm it represents a controlled exception rather than routine circumvention of the evaluation gate" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Implementing the evaluation gate as an advisory check that logs a warning but allows deployment to proceed when the evaluation manifest is absent or fails signature verification", "Using a shared approval account or role-based group identity for deployment approvals rather than named individual approvers with individual credentials, making dual-approval requirements unauditable", "Allowing the model development team to author and self-approve evaluation manifests rather than requiring the independent validation function to perform and sign evaluations, undermining the independence requirement of SR 26-2", "Storing signed evaluation manifests in the same mutable storage system as the model artifacts, where a system administrator could delete or replace the manifest and redeploy without leaving an audit trail", "Reusing a previously passing evaluation manifest across updated model artifact versions without re-evaluation, treating the gate as a one-time certification rather than a per-version deployment requirement" ], "update_status": "current", "layer_code": "EV" }, { "id": "EV-02", "layer": "EV", "plane": "both", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "plain": "Before deployment, every model is evaluated against documented criteria for task fitness, safety, reliability, and conformance with applicable policies. GenAI-specific refusal and alignment evaluations are scoped to the generative-ai profile only.", "threat": { "tags": [ "MR-VAL", "MR-PERFORMANCE", "LLM09:2025" ], "desc": "Models deployed without structured fitness and safety evaluation may produce harmful, unreliable, or policy-violating outputs at scale. Misinformation risk (LLM09) is particularly acute for generative models without policy-conformance testing." }, "standard": [ "NIST AI RMF MEASURE 2.3", "NIST AI RMF MEASURE 2.5", "ISO/IEC 42001:2023 A.6.2.4", "ISO/IEC 42005:2025 — AI system impact assessment", "EU AI Act Art. 9(5)(6)" ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://airc.nist.gov/RMF", "source_type": "voluntary-standard", "license": "public-domain", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/EV-02 Fitness, Safety, Reliability and Policy-Conformance Evaluation control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "url": "https://www.iso.org/standard/81230.html", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/EV-02 Fitness, Safety, Reliability and Policy-Conformance Evaluation control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42005_2025", "authority": "ISO/IEC", "title": "ISO/IEC 42005:2025 — Artificial Intelligence — AI system impact assessment", "url": "https://www.iso.org/standard/44546.html", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "supersedes": null, "status": "current", "retrieved_on": "2026-06-26", "normative_force": "voluntary-standard", "version": "2025", "published_on": "2025-05-01", "source_id": "iso_42005_2025", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42005:2025 — Artificial Intelligence — AI system impact assessment requirements informing the apeiris://model/controls/EV-02 Fitness, Safety, Reliability and Policy-Conformance Evaluation control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "authority": "European Parliament and Council", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "source_type": "regulation", "license": "public", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/EV-02 Fitness, Safety, Reliability and Policy-Conformance Evaluation control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_llm10_2025", "authority": "OWASP", "title": "OWASP Top 10 for LLM Applications 2025", "url": "https://genai.owasp.org", "source_type": "voluntary-standard", "license": "CC BY-SA 4.0", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "2025", "published_on": "2024-11-17", "retrieved_on": "2026-06-26", "source_id": "owasp_llm10", "relationship": "implementation_pattern", "rationale": "Establishes OWASP Top 10 for LLM Applications 2025 requirements informing the apeiris://model/controls/EV-02 Fitness, Safety, Reliability and Policy-Conformance Evaluation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Structured evaluation protocol executed against a versioned test suite covering fitness, safety, reliability, and policy-conformance dimensions; results documented per dimension with pass/fail thresholds defined pre-evaluation.", "steps": [ "Prior to evaluation, define and document: (a) task fitness metrics and acceptance thresholds, (b) safety scenarios and prohibited-output categories, (c) reliability measures (latency, error rates, calibration), (d) policy-conformance criteria tied to the specific deployment context.", "Select or construct evaluation datasets that are representative of the intended deployment distribution and disjoint from training data; document dataset provenance and version.", "Execute evaluation in a controlled environment that matches the production serving configuration; record all environment parameters.", "Score each dimension independently; record dimension-level results with thresholds applied; overall gate pass requires all dimensions to meet their defined thresholds.", "For generative-ai profile only: include refusal-rate evaluation on policy-violating prompt categories and alignment evaluation against the model's stated policy document; document refusal thresholds.", "Document trade-offs where dimension goals conflict (e.g., safety threshold vs. task utility); obtain explicit risk-acceptance sign-off for any trade-off decision." ], "anti_patterns": [ "Defining acceptance thresholds after seeing evaluation results, allowing post-hoc rationalization of failures.", "Using a single aggregate score that masks failures in individual dimensions (e.g., a safety failure hidden by a high fitness score).", "Applying generative-AI refusal/alignment evaluation to non-generative models without documented justification.", "Omitting reliability evaluation (calibration, latency, failure modes) and treating fitness alone as sufficient for production readiness." ] }, "validation": { "design_check": [ "Evaluation protocol document pre-specifies thresholds for each dimension before evaluation runs begin; thresholds are version-controlled and signed. [ref:nist_ai_rmf_1_0]", "Evaluation datasets are versioned, provenance-documented, and verified as disjoint from training data before evaluation. [ref:iso_42001_2023]", "Safety evaluation scenarios cover the prohibited-output categories defined in the deployment use-case policy. [ref:eu_ai_act_2024]", "For generative-ai profile: refusal-rate evaluation is included with explicit refusal thresholds per policy-violating prompt category. [ref:owasp_llm10_2025]" ], "runtime_test": [ "{'test': 'Run the evaluation suite on a known-deficient model variant and confirm that each failing dimension produces an explicit fail record that blocks the gate.', 'ref': 'nist_rmf_v1'} [ref:nist_ai_rmf_1_0]", "{'test': 'Verify that evaluation environment configuration matches production serving configuration for all relevant parameters (hardware, serving framework version, quantization).', 'unverified': True} [unverified]", "{'test': 'Confirm that dimension-level results are recorded independently and that a safety dimension failure cannot be overridden by fitness dimension pass.', 'unverified': True} [unverified]" ], "evidence": [ "model:pre-specified-evaluation-protocol-docume — Pre-specified evaluation protocol document with per-dimension thresholds, signed before evaluation execution. [ref:iso_42001_2023]", "model:dimension-level-evaluation-results-linke — Dimension-level evaluation results linked to the model artifact hash and evaluation suite version. [ref:nist_ai_rmf_1_0]", "model:dataset-provenance-records-confirming-tr — Dataset provenance records confirming training-evaluation disjointness. [ref:iso_42001_2023]", "model:risk-acceptance-records-for-any-dimensio — Risk-acceptance records for any dimension threshold trade-off decisions. [ref:eu_ai_act_2024]" ] }, "lenses": { "engineering": "Implement evaluation as a structured, dimension-isolated pipeline stage; expose per-dimension results as structured artifacts; prevent aggregate scoring from masking dimension failures.", "evaluation": "Own threshold definition, dataset curation, and environment specification; ensure refusal/alignment evals are scoped correctly to generative profiles; document all trade-off decisions.", "red_team": "Test whether a model that fails a safety dimension can be promoted by manipulating the aggregate scoring logic; probe safety scenarios for coverage gaps.", "grc": "Map dimension requirements to EU AI Act Art. 9(5)(6) and ISO 42005:2025 impact assessment; track dimension failure rates as governance KRIs; ensure trade-off decisions are board-visible for high-impact-decision profile.", "mlops": "Automate dimension-level evaluation as part of the model pipeline; surface dimension results on model cards; alert on any dimension threshold breach." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "EV-02 covers structured fitness/safety/reliability/policy evaluation. Fairness evaluation is EV-05. Adversarial probing is EV-04. Regression testing is EV-07.", "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.3 (MEASURE function) provides that AI system performance or assurance criteria are measured and demonstrated for conditions similar to deployment. EV-02’s fitness, safety, reliability, and policy-conformance dimensions measure and demonstrate the system’s assurance criteria before deployment.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.4 (AI system verification and validation) requires defined verification and validation measures. EV-02’s structured fitness, safety, reliability, and policy-conformance dimensions define those measures for models.", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Art. 9(5) requires testing against defined metrics and probabilistic thresholds; Art. 9(6) requires accuracy, robustness, and cybersecurity evaluation for high-risk systems.", "uncovered_portion": "EU AI Act does not prescribe specific evaluation datasets or dimension isolation methodology.", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. V", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes evaluation of conceptual soundness and analysis of model outcomes. EV-02's structured fitness, safety, reliability, and policy-conformance dimensions operationalize that validation scope. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 predates generative AI and does not address refusal/alignment evaluation.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aisvs", "requirement_id": "C3.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OWASP AISVS C3.2 (Model Validation & Testing) requires pre-deployment safety-evaluation testing (req 3.2.1). EV-02's structured fitness, safety, reliability, and policy-conformance dimensions define the evaluation content for that requirement.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "chapter": "C3.2", "chapter_name": "Model Validation & Testing" }, "normative_force": "voluntary-standard", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "llm10", "requirement_id": "LLM09:2025", "fit": "partial", "direction": "control-supports-requirement", "rationale": "LLM09 (Misinformation) is addressed by policy-conformance and accuracy evaluation in the generative-ai profile.", "uncovered_portion": "LLM Top 10 does not address structured pre-deployment evaluation protocol design.", "reviewed_on": "2026-06-26", "source_version": "2025", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "aicm", "requirement_id": "A&A-02", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CSA AICM A&A-02 (Independent Assessments) aligns with structured, evidence-producing model evaluation before deployment; EV-02’s dimension scores are the assessable artifacts.", "uncovered_portion": "AICM does not specify dimension isolation or pre-specified threshold requirements.", "reviewed_on": "2026-06-26", "source_version": "1.1", "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "direction": "out-of-scope", "rationale": "MITRE ATLAS v5.6.0 addresses adversarial ML attack tactics; pre-deployment fitness/safety evaluation is not an adversarial threat category.", "reviewed_on": "2026-06-26", "source_version": "v2026.06", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "nist_ai_600_1", "requirement_id": "CONFABULATION", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EV-02 requires structured evaluation of generative model output quality, safety, and policy conformance. NIST AI 600-1 identifies Confabulation as a primary GenAI risk — models producing false, hallucinated, or ungrounded outputs — and calls for systematic evaluation to measure and reduce confabulation rates before deployment. This control directly supports that outcome by establishing the evaluation gate and criteria.", "source_locator": { "section": "CONFABULATION" }, "source_version": "2024", "reviewed_on": "2026-06-26", "mapping_confidence": "medium", "provisional": true, "provisional_note": "NIST AI 600-1 GenAI Profile uses category-level identifiers (e.g., CONFABULATION, CBRN); action-level subcategory mapping was not possible from the category reference. Treat as category-level guidance only.", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_aitg", "requirement_id": "AITG-APP-05", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AITG-APP-05 (Testing for Unsafe Outputs) probes whether a model produces unsafe or policy-violating outputs. EV-02's safety and policy-conformance evaluation dimensions produce the pre-deployment evidence corresponding to this runtime test.", "source_locator": { "test_id": "AITG-APP-05", "test_name": "Testing for Unsafe Outputs" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "continuousvalidation", "fit": "supporting", "rationale": "Evaluating fitness, safety, reliability, and policy-conformance against pre-set thresholds is validating the model against documented requirements.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0008", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Before deployment, every model has been evaluated against pre-specified, dimension-level…\" enacts ATLAS mitigation AML.M0008 Validate AI Model; complements the control’s existing technique mapping AML.T0043 (defends_against) — OpenCRE crosswalks the AI Exchange concept (continuousvalidation) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "profiles": [ "general-predictive-ml", "generative-ai", "hosted-api", "continuously-learning", "high-impact-decision", "us-regulated-banking", "eu-high-risk", "frontier-capability" ], "assurance_target": { "what": "Every model has documented, dimension-isolated evaluation results against pre-specified thresholds before production promotion.", "how": "Structured evaluation protocol execution + signed dimension-level result artifacts.", "frequency": "Per deployment event; per significant capability update." }, "canonical_id": "apeiris://model/controls/EV-02", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-9", "mapping_fit": "partial", "notes": "Art-9 requires providers to establish, implement, document and maintain a risk management system throughout the lifecycle of a high-risk AI system.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds — fitness, safety, reliability, and policy-conformance — with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins — not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "machine_tests": [ "Submit a model for evaluation under a protocol whose thresholds were modified after the evaluation run began (version timestamp after first result timestamp) → assert evaluation system detects protocol mutation and flags results as invalid", "Run evaluation suite against a model variant with a known injected safety degradation → assert safety dimension fails and the pipeline receives a failed evaluation manifest that blocks deployment", "Submit a generative model evaluation without policy-conformance test cases for the applicable content policies → assert evaluation completeness check flags missing dimension and blocks manifest generation" ], "human_review": [ "Review pre-specified evaluation protocols to confirm thresholds were determined by deployment risk profile before any model results were visible — look for evidence of threshold-setting dates preceding model evaluation run dates, and flag any protocol where thresholds appear calibrated to match known performance", "Assess risk-acceptance records for threshold trade-offs: confirm each record identifies the specific capability gap, the concrete deployment risk consequence, and a remediation commitment with a defined deadline — not an open-ended deferral or a blanket acceptance of ongoing risk" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Setting evaluation thresholds after reviewing initial model performance metrics, creating circular evaluation where the model is guaranteed to pass the thresholds by retroactive calibration", "Reusing the same evaluation dataset for both hyperparameter tuning and final fitness evaluation, making the final assessment an in-distribution check that does not reflect genuine held-out capability", "Applying a single composite pass/fail score that averages across dimensions, allowing a severe safety failure to be masked by high fitness accuracy scores and produce a passing overall result", "Treating GenAI refusal and alignment evaluation as optional for all deployment profiles rather than scoping it specifically to generative-AI use cases where harmful content generation is a material risk", "Accepting vendor-provided evaluation results without independent replication for safety dimensions, where vendor incentives may not align with conservative assessment of harmful output rates" ], "update_status": "current", "layer_code": "EV" }, { "id": "EV-03", "layer": "EV", "plane": "both", "name": "Dangerous Capability Threshold Assessment", "plain": "Models at or near frontier capability must be assessed for dangerous capabilities — CBRN uplift, cyberweapons, autonomous AI R&D, and mass-influence operations — against defined thresholds before deployment. Thresholds and assessment methodology are defined by the applicable responsible scaling or capability policy.", "threat": { "tags": [ "MR-VAL", "EU-AIA-AnnexIII" ], "desc": "Frontier AI models may develop dangerous capabilities that, if deployed without assessment, could provide meaningful uplift to actors seeking to cause catastrophic harm. No current MITRE ATLAS technique directly represents this pre-deployment assurance gap." }, "matrix_thesis": true, "thesis_type": "detective", "standard": [ "Anthropic Responsible Scaling Policy v3.3 (May 26, 2026) — ASL-2/ASL-3 standards (ASL-4+ to be defined)", "OpenAI Preparedness Framework v2 — Tracked Categories", "Google DeepMind Frontier Safety Framework v3.1 (April 17, 2026) — TCLs", "EU AI Act Art. 51 — GPAI models with systemic risk", "EU AI Act Art. 55 — Obligations for systemic risk GPAI" ], "sources": [ { "id": "anthropic_rsp_v3_3", "authority": "Anthropic", "title": "Anthropic Responsible Scaling Policy v3.3", "url": "https://www.anthropic.com/responsible-scaling-policy", "source_type": "vendor-framework", "license": "proprietary", "artifact_hash": null, "supersedes": [ "RSP v3.2", "RSP v3.1", "RSP v3.0" ], "effective_date": "2026-05-26", "status": "current", "normative_force": "voluntary-standard", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-26", "source_id": "anthropic_rsp", "relationship": "implementation_pattern", "rationale": "Establishes Responsible Scaling Policy v3.3 requirements informing the apeiris://model/controls/EV-03 Dangerous Capability Threshold Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "openai_preparedness_v2", "authority": "OpenAI", "title": "OpenAI Preparedness Framework v2", "url": "https://openai.com/preparedness", "source_type": "vendor-framework", "license": "proprietary", "artifact_hash": null, "supersedes": [ "Preparedness Framework v1" ], "status": "current", "normative_force": "voluntary-standard", "version": "2.0", "published_on": "2025-01-01", "retrieved_on": "2026-06-26", "source_id": "openai_preparedness_v2", "relationship": "implementation_pattern", "rationale": "Establishes OpenAI Preparedness Framework v2 requirements informing the apeiris://model/controls/EV-03 Dangerous Capability Threshold Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "gdm_fsf_v3_1", "authority": "Google DeepMind", "title": "Frontier Safety Framework v3.1", "url": "https://deepmind.google/frontier-safety-framework", "source_type": "vendor-framework", "license": "proprietary", "artifact_hash": null, "supersedes": [ "FSF v3.0" ], "effective_date": "2026-04-17", "status": "current", "normative_force": "voluntary-standard", "version": "3.1", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "source_id": "gdm_fsf_v3_1", "relationship": "implementation_pattern", "rationale": "Establishes Frontier Safety Framework v3.1 requirements informing the apeiris://model/controls/EV-03 Dangerous Capability Threshold Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "authority": "European Parliament and Council", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "source_type": "regulation", "license": "public", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/EV-03 Dangerous Capability Threshold Assessment control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Structured capability elicitation and assessment against defined thresholds before deployment of any frontier-class model; results reviewed by an independent safety committee before production authorization.", "steps": [ "Identify whether the model falls within scope of the organization's frontier assurance policy based on compute budget, parameter count, benchmark performance, or a capability screen; document the scoping determination.", "Select applicable threshold framework(s) — Anthropic RSP v3.3 ASL standards, OpenAI Preparedness Framework v2 Tracked Categories, Google DeepMind FSF v3.1 TCLs — based on organizational affiliation or analogous threshold definitions for independent developers.", "Execute structured capability elicitation for each dangerous capability domain: CBRN (biological, chemical, radiological, nuclear) uplift potential; cyberweapons and offensive cyber automation; autonomous AI research and development; mass-influence and deception operations.", "Use best-effort red-team elicitation — including domain-expert evaluators — to probe for capability with and without scaffolding; document elicitation methodology, assumptions, and limitations.", "Compare elicitation results against the defined threshold for each capability domain; document whether the model is below threshold, near threshold, or above threshold.", "For models at or above any threshold: halt deployment; escalate to safety committee; apply required safeguards or capability limitations before re-evaluation.", "Document assessment methodology, elicitation results, threshold comparisons, evaluator identities, and deployment decision with explicit risk-acceptance chain for models below threshold." ], "anti_patterns": [ "Applying dangerous capability assessment only to models from known frontier labs and omitting assessment for internally fine-tuned derivatives of frontier base models.", "Treating a below-threshold result as permanent — capability thresholds must be re-evaluated on each significant update or when new elicitation techniques are discovered.", "Using domain-naive evaluators for CBRN elicitation; domain expertise is required for meaningful assessment.", "Conflating dangerous capability assessment with standard safety evaluation; these are distinct assessment types with distinct methodologies." ] }, "validation": { "design_check": [ "Scoping criteria for dangerous capability assessment are documented and version-controlled; all frontier-class models and their fine-tuned derivatives fall within scope. [ref:anthropic_rsp_v3_3]", "Each capability domain (CBRN, cyberweapons, autonomous AI R&D, mass-influence) has a defined threshold and a documented elicitation methodology. [ref:anthropic_rsp_v3_3]", "Assessment team includes domain-expert evaluators for each capability domain; evaluator qualifications are documented. [ref:eu_ai_act_2024]", "For EU-scope GPAI models: assessment addresses Art. 51 systemic risk classification criteria. [ref:eu_ai_act_2024]" ], "runtime_test": [ "{'test': 'Verify that a model scoped as frontier-class cannot be promoted to production without a completed, signed dangerous capability assessment record.', 'unverified': True} [unverified]", "{'test': 'Confirm that the assessment record references the exact model artifact hash and that the hash matches the artifact being deployed.', 'unverified': True} [unverified]", "{'test': 'For a model with a known above-threshold synthetic capability indicator: verify that the assessment process correctly classifies it and blocks deployment.', 'unverified': True} [unverified]" ], "evidence": [ "model:scoping-determination-record-for-each-ev — Scoping determination record for each evaluated model, referencing the applicable threshold framework. [ref:anthropic_rsp_v3_3]", "model:capability-elicitation-results-per-domai — Capability elicitation results per domain with methodology documentation, evaluator identities, and threshold comparison. [ref:anthropic_rsp_v3_3]", "model:safety-committee-review-and-deployment-a — Safety committee review and deployment authorization record for models evaluated as below threshold. [unverified]", "model:for-eu-scope-gpai-models-systemic-risk — For EU-scope GPAI models: systemic risk classification record per EU AI Act Art. 51. [ref:eu_ai_act_2024]" ] }, "capability_risk": { "capability_level": "frontier", "autonomy": "supervised", "access_mode": "api", "irreversibility": "irreversible", "deployment_scale": "enterprise", "affected_party_impact": "moderate", "external_reach": false, "data_sensitivity": "internal", "notes": "domains: CBRN, cyberweapons, autonomous-AI-RD, mass-influence | threshold frameworks: Anthropic RSP v3.3 ASL standards, OpenAI Preparedness Framework v2 Tracked Categories, Google DeepMind FSF v3.1 Critical Capability Levels (CCLs) | re evaluation trigger: Any significant capability update, new elicitation methodology, or threshold framework revision." }, "lenses": { "engineering": "Integrate capability assessment as a mandatory gate for frontier-class models in the deployment pipeline; implement scoping classifier to automatically flag models requiring full assessment.", "evaluation": "Own elicitation methodology design and threshold calibration; recruit and manage domain-expert evaluators; document elicitation limitations and coverage gaps honestly.", "red_team": "Design best-effort elicitation protocols; use scaffolding, fine-tuning, and multi-step prompting to probe for capability uplift; document novel elicitation techniques discovered during assessment.", "grc": "Map assessment requirements to applicable RSP/Preparedness/FSF obligations; track assessment cadence and threshold breaches as governance KRIs; ensure board-level visibility for any above-threshold finding.", "mlops": "Build scoping classifier into the model registry onboarding workflow; surface capability assessment status on model cards; block promotion pipelines for frontier-class models without completed assessment." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "This control addresses a frontier assurance gap with no direct MITRE ATLAS mapping in v5.6.0. ATLAS techniques address post-deployment adversarial exploitation, not pre-deployment capability elicitation. EV-04 (adversarial red-team) is complementary but distinct.", "profiles": [ "frontier-capability" ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.6 (MEASURE function) provides that the AI system is evaluated regularly for safety risks, demonstrated to be safe within risk tolerance, and able to fail safely. EV-03’s dangerous-capability threshold assessment is the frontier-scale form of regular safety evaluation against defined risk tolerances; the RMF does not address capability thresholds specifically.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "6.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 §6.1 requires identification and assessment of AI risks; dangerous capability assessment extends this to frontier-specific risks.", "uncovered_portion": "ISO 42001 does not define dangerous capability domains or threshold frameworks.", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-55", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Art. 51 only classifies GPAI models as systemic-risk (including the 10^25 FLOP training-compute presumption); the substantive evaluation obligations attach under Art. 55 — model evaluation with adversarial testing, systemic-risk assessment and mitigation, and serious-incident reporting. EV-03's dangerous-capability assessment operationalizes the Art. 55 evaluation duty.", "uncovered_portion": "EU AI Act systemic risk threshold (10^25 FLOPs) may not capture all dangerous capability risks; capability-based assessment extends beyond compute-based classification.", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "aicm", "requirement_id": "A&A-02", "fit": "adjacent", "direction": "out-of-scope", "rationale": "CSA AICM A&A-02 (Independent Assessments) is the nearest control: frontier dangerous-capability assessment is an independent-assessment activity, but the AICM does not itself address capability thresholds, so the mapping is adjacent.", "reviewed_on": "2026-06-26", "source_version": "1.1", "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "direction": "out-of-scope", "rationale": "MITRE ATLAS v5.6.0 addresses adversarial ML attack tactics post-deployment; no ATLAS technique directly maps to pre-deployment dangerous capability elicitation. This is an identified frontier assurance gap in the ATLAS taxonomy.", "uncovered_portion": "N/A — no false mapping applied.", "reviewed_on": "2026-06-26", "source_version": "v2026.06", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "nist_ai_600_1", "requirement_id": "CBRN", "fit": "direct", "direction": "control-supports-requirement", "rationale": "NIST AI 600-1 identifies CBRN (Chemical, Biological, Radiological, Nuclear) information or capabilities as a critical GenAI risk — models that can provide meaningful uplift for weapons of mass destruction. EV-03 establishes the structured dangerous-capability assessment process that directly addresses this risk by requiring systematic evaluation before any elevated-capability model is deployed.", "source_locator": { "section": "CBRN" }, "source_version": "2024", "reviewed_on": "2026-06-26", "mapping_confidence": "medium", "provisional": true, "provisional_note": "NIST AI 600-1 GenAI Profile uses category-level identifiers (e.g., CONFABULATION, CBRN); action-level subcategory mapping was not possible from the category reference. Treat as category-level guidance only.", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_aitg", "requirement_id": "AITG-INF-04", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AITG-INF-04 (Testing for Capability Misuse) probes whether model capabilities can be misused for harmful ends. EV-03's dangerous-capability threshold assessment is the structured, pre-deployment form of that inquiry for frontier-risk domains.", "source_locator": { "test_id": "AITG-INF-04", "test_name": "Testing for Capability Misuse" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" } ], "assurance_target": { "what": "Every frontier-class model and its fine-tuned derivatives have a completed, signed dangerous capability assessment before production deployment.", "how": "Scoping classifier + structured elicitation + safety committee review + signed assessment record.", "frequency": "Per deployment event; re-evaluation required on significant capability updates or new elicitation methodology." }, "canonical_id": "apeiris://model/controls/EV-03", "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-51", "mapping_fit": "partial", "notes": "Art-51 classifies general-purpose AI models as having systemic risk (including the 10^25 FLOP training-compute presumption); the evaluation, adversarial-testing, and incident-reporting obligations for such models attach under Art-55.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "Every model at or near frontier capability has been assessed against the organization's applicable responsible scaling or capability policy thresholds for CBRN uplift, cyberweapon generation, autonomous AI R&D, and mass-influence operations before deployment authorization is granted. The safety committee has reviewed elicitation results and issued a signed deployment authorization for models below all thresholds; any model at or above threshold in any domain is not deployed pending safety committee escalation.", "evidence_required": [ "scoping_determination_record for each evaluated model referencing the applicable capability policy (responsible scaling policy version or equivalent), with rationale for frontier-class determination including FLOPs estimate, capability benchmark scores, or elicitation pre-screen results", "capability_elicitation_results per domain (CBRN, cyberweapons, autonomous AI R&D, mass-influence operations) with methodology documentation, red-team evaluator identities, uplift elicitation protocol reference, and threshold comparison showing assessed level vs. defined threshold for each domain", "safety_committee_review_record with committee composition, deliberation notes, quorum confirmation, majority determination, any dissenting positions, and signed deployment_authorization or deployment_block decision", "EU_AI_Act_systemic_risk_classification_record for models meeting Art. 51 GPAI thresholds (≥10²⁵ FLOPs training compute or equivalent capability), documenting systemic risk determination and applicable GPAI obligations" ], "machine_tests": [ "Submit a frontier-class model (meeting compute or benchmark scoping criteria) for production deployment without a completed capability elicitation record → assert deployment pipeline gate blocks with error=missing_capability_assessment", "Submit a safety committee authorization record with a quorum flag below the required minimum committee size → assert deployment authorization is rejected with error=insufficient_safety_committee_quorum", "Submit a model with a capability elicitation result flagged at or above threshold for any domain → assert deployment is automatically blocked and an escalation alert is generated to the safety committee with the domain and assessed level" ], "human_review": [ "Review capability elicitation methodology for completeness: confirm that red-team evaluators used uplift elicitation protocols — not just refusal-rate testing — and that methodology documentation is sufficient for independent replication by a qualified third-party evaluator", "Assess safety committee composition and deliberation records to confirm that deployment authorization decisions are made by qualified, independent reviewers not solely drawn from the model development team, and that dissenting positions are documented rather than suppressed", "Verify that the threshold framework referenced in each scoping determination reflects the current version of the applicable responsible scaling policy — flag any assessment referencing a superseded policy version without documented justification for using the earlier thresholds" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Performing capability threshold assessment only through refusal-rate testing rather than uplift elicitation — a model can exhibit high refusal rates on surface-level queries while still providing meaningful expert-level assistance to malicious actors when probed with context-appropriate prompting", "Delegating the entire safety committee review to the model development team, eliminating independent oversight and creating conflicts of interest in deployment authorization for models the same team built and optimized", "Treating capability assessment as a one-time pre-deployment exercise rather than re-triggering it when the model undergoes fine-tuning, RLHF updates, or capability expansions that could shift dangerous capability levels", "Using an outdated version of the responsible scaling policy or capability threshold framework without verifying that referenced thresholds still reflect current organizational and regulatory requirements", "Relying solely on compute-based scoping criteria (FLOPs threshold) while ignoring emergent capability benchmarks that may indicate frontier-level performance in a target domain at compute levels below published thresholds" ], "update_status": "current", "layer_code": "EV" }, { "id": "EV-04", "layer": "EV", "plane": "both", "name": "Adversarial Red-Team Testing", "plain": "Structured adversarial probing is conducted before deployment by a team independent of model development. Red-team exercises probe for exploitable failure modes including prompt injection, jailbreaks, harmful content elicitation, and misuse patterns. Required for generative-AI, frontier, and externally-reachable (hosted-API) profiles.", "threat": { "tags": [ "AML.T0051", "LLM01:2025", "LLM04:2025", "MR-VAL" ], "desc": "Without structured red-teaming, exploitable failure modes — including LLM prompt injection (AML.T0051 / LLM01:2025) and data-and-model poisoning effects (LLM04:2025) — may reach production. Automated evaluation suites do not replicate the adversarial creativity of structured human red-team exercises." }, "standard": [ "EU AI Act Art. 55(1)(a) — Adversarial testing for GPAI systemic risk models", "NIST AI RMF MEASURE 2.7", "ISO/IEC 42001:2023 A.6.2.4", "OWASP AISVS v1.0 C11 — Adversarial Robustness" ], "sources": [ { "id": "mitre_atlas_v5_6_0", "authority": "MITRE", "title": "MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems", "url": "https://atlas.mitre.org", "source_type": "voluntary-standard", "license": "CC BY 4.0", "artifact_hash": null, "supersedes": null, "effective_date": "2026-05-04", "status": "current", "retrieved_on": "2026-06-26", "normative_force": "best-practice", "version": "5.6.0", "published_on": "2026-05-04", "source_id": "mitre_atlas", "relationship": "informative_reference", "rationale": "Establishes MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems requirements informing the apeiris://model/controls/EV-04 Adversarial Red-Team Testing control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_llm10_2025", "authority": "OWASP", "title": "OWASP Top 10 for LLM Applications 2025", "url": "https://genai.owasp.org", "source_type": "voluntary-standard", "license": "CC BY-SA 4.0", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "2025", "published_on": "2024-11-17", "retrieved_on": "2026-06-26", "source_id": "owasp_llm10", "relationship": "implementation_pattern", "rationale": "Establishes OWASP Top 10 for LLM Applications 2025 requirements informing the apeiris://model/controls/EV-04 Adversarial Red-Team Testing control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_aisvs_v1", "authority": "OWASP", "title": "OWASP AI Security Verification Standard v1.0", "url": "https://github.com/OWASP/AISVS", "source_type": "voluntary-standard", "license": "CC BY-SA 4.0", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2026-06-26", "retrieved_on": "2026-06-26", "source_id": "owasp_aisvs_v1", "relationship": "implementation_pattern", "rationale": "Establishes OWASP AI Security Verification Standard v1.0 requirements informing the apeiris://model/controls/EV-04 Adversarial Red-Team Testing control.", "reviewed_on": "2026-07-01", "canonical_url": "https://github.com/OWASP/AISVS" }, { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://airc.nist.gov/RMF", "source_type": "voluntary-standard", "license": "public-domain", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/EV-04 Adversarial Red-Team Testing control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "authority": "European Parliament and Council", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "source_type": "regulation", "license": "public", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/EV-04 Adversarial Red-Team Testing control.", "reviewed_on": "2026-07-01" }, { "id": "etsi_gr_sai_005", "title": "ETSI GR SAI 005 — Mitigation Strategy Report", "authority": "ETSI", "source_type": "standards-body", "normative_force": "voluntary-standard", "version": "V1.1.1", "published_on": "2021-03-01", "retrieved_on": "2026-07-08", "canonical_url": "https://www.etsi.org/deliver/etsi_gr/SAI/001_099/005/01.01.01_60/gr_SAI005v010101p.pdf", "relationship": "supporting_guidance", "note": "ETSI SAI 005 evasion mitigations (clause 6.2) inform adversarial red-team scope." }, { "id": "bsi_ai_fundamentals", "title": "BSI — Security of AI-Systems: Fundamentals", "authority": "Federal Office for Information Security (BSI)", "source_type": "government-agency", "normative_force": "supervisory-guidance", "version": "0.9", "published_on": "2022-06-14", "retrieved_on": "2026-07-08", "canonical_url": "https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/Security-of-AI-systems_fundamentals.pdf", "relationship": "supporting_guidance", "note": "BSI evasion-defense best practices (1.2.2) inform robustness testing." } ], "implementation": { "pattern": "Structured red-team exercises conducted by a team independent of model development, using a documented threat model and coverage plan, with findings triaged and remediated before deployment gate.", "steps": [ "Define the red-team scope and threat model for the specific model and deployment context: identify the adversarial personas, attack surfaces, and priority failure modes to probe.", "For generative-AI and hosted-API profiles: include prompt injection (AML.T0051), jailbreak, harmful content elicitation, identity fabrication, and policy-violating instruction following.", "For frontier-capability profile: include capability-elicitation red-teaming aligned with EV-03 dangerous capability domains; escalate findings immediately if threshold-level capability is elicited.", "Assemble a red team that is independent of the model development team (see EV-08); include domain experts for the deployment context (e.g., medical, legal, financial for high-impact-decision profile).", "Execute red-team exercises in an environment that matches production configuration; document all elicited failures with reproduction steps, severity classification, and affected user populations.", "Triage all findings: critical and high severity findings must be remediated and re-tested before the deployment gate; medium findings require documented risk-acceptance; low findings are tracked in backlog.", "Produce a signed red-team report documenting: scope, threat model, methodology, findings by severity, remediation status, and residual risk statement." ], "anti_patterns": [ "Using only automated adversarial evaluation tools without structured human red-team exercises; automated tools do not replicate adversarial creativity.", "Conducting red-team exercises with the model development team; this defeats the independence requirement and produces optimistic results.", "Treating red-team scope as fixed; threat models must be updated for each deployment context and model capability level.", "Closing critical findings by adding refusals to the specific tested inputs without addressing the underlying vulnerability pattern." ] }, "validation": { "design_check": [ "Red-team scope document and threat model are version-controlled and approved before exercise begins; scope covers AML.T0051 (prompt injection) for generative-AI and hosted-API profiles. [ref:mitre_atlas_v5_6_0]", "Red-team team composition confirms independence from model development team; team includes domain experts for the deployment context. [ref:nist_ai_rmf_1_0]", "Finding severity classification criteria are defined and documented before the exercise begins; criteria are not modified post-exercise. [ref:nist_ai_rmf_1_0]", "For EU-scope GPAI models: red-team exercise satisfies Art. 55(1)(a) adversarial testing requirements. [ref:eu_ai_act_2024]" ], "runtime_test": [ "{'test': 'Verify that the deployment pipeline blocks if the red-team report is missing or if any critical/high findings remain open (unremediated).', 'unverified': True} [unverified]", "{'test': 'Confirm that at least one prompt injection attempt (AML.T0051 pattern) is documented in the red-team scope for generative-AI and hosted-API profiles.', 'ref': 'mitre_atlas_v5_6_0'} [ref:mitre_atlas_v5_6_0]", "{'test': 'For a model with a known exploitable failure mode: confirm the red-team exercise correctly identifies and documents it.', 'unverified': True} [unverified]" ], "evidence": [ "model:signed-red-team-scope-and-threat-model-d — Signed red-team scope and threat model document, version-controlled, approved before exercise. [ref:nist_ai_rmf_1_0]", "model:red-team-findings-log-with-severity-clas — Red-team findings log with severity classifications, reproduction steps, affected populations, and remediation status. [ref:owasp_aisvs_v1]", "model:signed-red-team-report-with-residual-ris — Signed red-team report with residual risk statement, linked to the model artifact hash. [ref:nist_ai_rmf_1_0]", "model:evidence-of-remediation-for-all-critical — Evidence of remediation for all critical and high findings, including re-test results. [unverified]", "model:for-frontier-capability-profile-escalat — For frontier-capability profile: escalation records for any capability elicited that approaches threshold levels. [ref:mitre_atlas_v5_6_0]" ] }, "lenses": { "engineering": "Provide production-equivalent red-team environment; build tooling to capture and structure red-team findings; integrate finding triage into the deployment gate as a blocking check on critical/high open findings.", "evaluation": "Design red-team scope and threat model; select adversarial datasets and scenarios; own the signed red-team report; ensure prompt injection (AML.T0051) coverage for applicable profiles.", "red_team": "Execute structured adversarial probing with genuine adversarial creativity; document findings with full reproduction steps; do not self-censor findings to avoid blocking deployment; escalate capability findings immediately.", "grc": "Map red-team requirements to EU AI Act Art. 55(1)(a) for systemic risk GPAI models; track critical finding rates and time-to-remediation as governance KRIs; ensure red-team cadence is defined in model governance policy.", "mlops": "Surface red-team report status on model registry cards; block promotion pipeline on open critical/high findings; track red-team finding trends across model versions." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "EV-04 covers pre-deployment adversarial red-team testing. Runtime adversarial monitoring is covered in BH layer. EV-03 covers dangerous capability elicitation for frontier models as a distinct exercise type.", "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.7", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.7 (MEASURE function) provides that AI system security and resilience are evaluated and documented. EV-04’s adversarial red-team exercises are the security evaluation this subcategory requires, documented as pre-deployment evidence.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.4 (AI system verification and validation) covers validation of AI systems; EV-04’s adversarial red-team exercises extend validation to hostile-input scenarios.", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-55", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Art. 55(1)(a) requires providers of GPAI models with systemic risk to conduct adversarial testing prior to deployment.", "uncovered_portion": "EU AI Act requirement applies only to systemic-risk GPAI; this control extends adversarial testing to all externally-reachable and generative-AI profile models.", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. V", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes testing models under a range of conditions as part of validation. Adversarial red-team testing extends that principle to hostile inputs; the guidance does not itself prescribe adversarial testing. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 does not address LLM-specific adversarial testing methodology.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aisvs", "requirement_id": "C11.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OWASP AISVS C11.1 (Model Alignment, Safety, and Robustness Testing and Training) requires adversarial robustness testing of models. EV-04's structured red-team exercises — jailbreak, prompt injection, and evasion probing — implement that verification.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "chapter": "C11.1", "chapter_name": "Model Alignment, Safety, and Robustness Testing and Training" }, "normative_force": "voluntary-standard", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "llm10", "requirement_id": "LLM01:2025", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Red-team exercises must probe for LLM01 (prompt injection) and residual effects of LLM04 (data and model poisoning) for generative-AI profiles.", "uncovered_portion": "LLM Top 10 2025 describes threat categories but does not specify red-team methodology or independence requirements.", "reviewed_on": "2026-06-26", "source_version": "2025", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "aicm", "requirement_id": "TVM-07", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AICM adversarial testing controls align with structured red-team exercise requirements.", "uncovered_portion": "AICM does not specify threat model documentation or deployment gate integration.", "reviewed_on": "2026-06-26", "source_version": "1.1", "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0051", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AML.T0051 (LLM Prompt Injection) must be probed in red-team exercises for generative-AI and hosted-API profiles. AML.T0044 (Full AI Model Access) represents the threat scenario motivating adversarial capability probing for frontier models.", "uncovered_portion": "MITRE ATLAS describes attack techniques; it does not specify evaluation methodology for pre-deployment red-teaming.", "reviewed_on": "2026-06-26", "source_version": "v2026.06", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "nist_ai_600_1", "requirement_id": "INFO-SECURITY", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI 600-1 identifies Information Security as a GenAI risk category covering adversarial attacks, prompt injection, extraction of training data, and supply chain threats against AI systems. EV-04 red-team testing directly addresses this by requiring structured adversarial probing before deployment.", "uncovered_portion": "NIST AI 600-1 INFO-SECURITY also covers runtime detection and incident response to adversarial attacks — those aspects are owned by securitycontrols.ai runtime controls, not by this pre-deployment evaluation control.", "source_version": "2024", "reviewed_on": "2026-06-26", "mapping_confidence": "medium", "provisional": true, "provisional_note": "NIST AI 600-1 GenAI Profile uses category-level identifiers (e.g., CONFABULATION, CBRN); action-level subcategory mapping was not possible from the category reference. Treat as category-level guidance only.", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_aitg", "requirement_id": "AITG-MOD-01", "fit": "direct", "direction": "control-supports-requirement", "rationale": "AITG-MOD-01 (Testing for Evasion Attacks) covers adversarial inputs crafted to defeat model behavior; EV-04's red-team exercises execute this test class directly, alongside prompt-injection probing (AITG-APP-01) for generative profiles.", "source_locator": { "test_id": "AITG-MOD-01", "test_name": "Testing for Evasion Attacks" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.022", "fit": "supporting", "rationale": "NIST AI 100-2 Evasion (NISTAML.022) is the adversarial-example threat this control's red-team testing targets.", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against" }, { "framework": "owasp_ai_exchange", "requirement_id": "continuousvalidation", "fit": "supporting", "rationale": "Independent adversarial red-team probing for injection, jailbreaks, and misuse is structured validation testing of the model before release.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0008", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"The model system has a signed red-team report produced by a team organizationally…\" enacts ATLAS mitigation AML.M0008 Validate AI Model; complements the control’s existing technique mapping AML.T0051 (defends_against) — OpenCRE crosswalks the AI Exchange concept (continuousvalidation) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "profiles": [ "generative-ai", "hosted-api", "frontier-capability", "high-impact-decision", "eu-high-risk" ], "assurance_target": { "what": "Every model in-scope has a signed red-team report with all critical and high findings remediated before production deployment.", "how": "Structured red-team exercise + signed report + deployment gate check on open finding severity.", "frequency": "Per deployment event; re-run on significant capability updates; annually at minimum for continuously-deployed models." }, "canonical_id": "apeiris://model/controls/EV-04", "capability_risk": { "capability_level": "elevated", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "gpai_model_systemic_risk" ], "classification": [ "gpai-systemic-risk" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2025-08-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-55", "mapping_fit": "partial", "notes": "Art-55 requires providers of GPAI models with systemic risk to perform model evaluation including adversarial testing to identify and mitigate systemic risks.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "The model system has a signed red-team report produced by a team organizationally independent of model development, documenting structured adversarial probing that covers all required attack categories for the applicable profiles, with all critical and high findings remediated and re-tested before the deployment gate clears.", "evidence_required": [ "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action" ], "machine_tests": [ "Check deployment pipeline for model lacking red_team_report in evaluation manifest → assert pipeline blocks promotion with blocking_finding=red_team_report_missing", "Query red_team_findings_log for findings with severity in [critical, high] and status != remediated → assert count equals zero before deployment gate passes", "Verify red_team_scope document includes at least one prompt_injection test case (AML.T0051 pattern) for generative-ai and hosted-api profiles → assert scope_field prompt_injection_coverage=true", "Submit a model artifact hash to the provenance chain and verify it links to a signed red_team_report with report_hash matching the manifest reference → assert signature valid and hashes match" ], "human_review": [ "Review red-team team composition to confirm all members are organizationally independent of the model development function and that the team includes domain experts relevant to the deployment context", "Assess the red-team scope and threat model for completeness relative to the intended deployment context, verifying adversarial persona coverage is realistic for the expected user population and attack surface", "Examine the findings log to verify severity classification criteria were pre-defined and consistently applied, with no post-hoc downgrading of critical findings to avoid triggering the deployment block" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Using only automated adversarial evaluation tools and counting the output as equivalent to a structured human red-team exercise, omitting the adversarial creativity that automated suites cannot replicate", "Conducting red-team exercises with members of the model development team or individuals reporting to the same management chain, producing optimistic results that defeat the independence requirement", "Modifying the severity classification criteria after the exercise concludes to reclassify critical findings as medium, avoiding the blocking finding without addressing the underlying vulnerability", "Treating the red-team scope as fixed across model versions and deployment contexts rather than updating the threat model for each new deployment or capability level", "Closing critical findings by patching the specific tested prompts without addressing the underlying vulnerability class, leaving trivially variant inputs able to still elicit the failure mode" ], "update_status": "current", "layer_code": "EV" }, { "id": "EV-05", "layer": "EV", "plane": "both", "name": "Fairness and Bias Evaluation", "plain": "Before deployment, the model is evaluated for fairness and bias across documented population groups, harm types, and use-case-appropriate metrics. No universal fairness definition applies; the evaluation documents the specific populations, harms, metrics, legal basis, thresholds, and trade-offs selected for each deployment context.", "threat": { "tags": [ "MR-VAL", "MR-PERFORMANCE", "EU-AIA-AnnexIII" ], "desc": "Models deployed without documented fairness evaluation may produce systematically disparate outcomes across protected population groups, causing discriminatory harm and legal liability. The absence of a universal fairness metric makes documentation of the selection rationale essential." }, "standard": [ "EU AI Act Art. 9(7) — Non-discrimination testing for high-risk systems", "EU AI Act Annex III — High-risk AI system categories", "ISO/IEC 42001:2023 §6.1.2 — AI risk assessment", "ISO/IEC 42005:2025 — AI system impact assessment", "NIST AI RMF MEASURE 2.11", "NIST AI 600-1 — Generative AI Profile" ], "sources": [ { "id": "eu_ai_act_2024", "authority": "European Parliament and Council", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "source_type": "regulation", "license": "public", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/EV-05 Fairness and Bias Evaluation control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42005_2025", "authority": "ISO/IEC", "title": "ISO/IEC 42005:2025 — Artificial Intelligence — AI system impact assessment", "url": "https://www.iso.org/standard/44546.html", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "supersedes": null, "status": "current", "retrieved_on": "2026-06-26", "normative_force": "voluntary-standard", "version": "2025", "published_on": "2025-05-01", "source_id": "iso_42005_2025", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42005:2025 — Artificial Intelligence — AI system impact assessment requirements informing the apeiris://model/controls/EV-05 Fairness and Bias Evaluation control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "url": "https://www.iso.org/standard/81230.html", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/EV-05 Fairness and Bias Evaluation control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://airc.nist.gov/RMF", "source_type": "voluntary-standard", "license": "public-domain", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/EV-05 Fairness and Bias Evaluation control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_600_1", "authority": "NIST", "title": "NIST AI 600-1: Artificial Intelligence — Generative AI Profile", "url": "https://airc.nist.gov/Docs/1", "source_type": "voluntary-standard", "license": "public-domain", "artifact_hash": null, "supersedes": null, "status": "current", "retrieved_on": "2026-06-26", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2024-07-26", "source_id": "nist_ai_600_1", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI 600-1: Artificial Intelligence — Generative AI Profile requirements informing the apeiris://model/controls/EV-05 Fairness and Bias Evaluation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Use-case-specific fairness evaluation protocol that explicitly documents population groups, harm types, metric selection rationale, legal basis, acceptance thresholds, and trade-off decisions before evaluation execution.", "steps": [ "Identify the relevant population groups for the deployment context based on: protected characteristics under applicable law, historically disadvantaged groups, and use-case-specific subpopulations likely to experience differential impact.", "Define the harm types to evaluate: outcome disparity, representation disparity, performance disparity (accuracy/error rates), calibration disparity, and language/cultural harm for generative-AI profiles.", "Select fairness metrics appropriate for the use case and document the selection rationale explicitly; acknowledge metric trade-offs (e.g., demographic parity vs. equalized odds) and state which constraint takes precedence for this deployment.", "Document the legal basis for metric selection — applicable anti-discrimination law, regulatory guidance, and organizational equity commitments.", "Define acceptance thresholds for each metric and population group before evaluation execution; thresholds must be pre-specified, not post-hoc.", "Execute evaluation using representative data for each identified population group; document data sources, group sizes, and coverage limitations.", "Document all threshold violations, trade-off decisions, and residual disparity with explicit risk-acceptance; obtain legal review for deployments involving legally protected characteristics." ], "anti_patterns": [ "Selecting a single fairness metric and presenting it as universally sufficient without documenting metric trade-offs and the deployment-specific rationale.", "Defining acceptance thresholds after seeing evaluation results.", "Reporting only aggregate performance metrics and omitting disaggregated analysis by population group.", "Using training data as the evaluation dataset for fairness assessment, masking distributional bias.", "Omitting fairness evaluation for models that make decisions affecting legally protected characteristics under the assumption that the model 'does not see' protected attributes." ] }, "validation": { "design_check": [ "Evaluation protocol pre-specifies: target population groups, harm types, fairness metrics, selection rationale, legal basis, and acceptance thresholds — all version-controlled and signed before evaluation. [ref:eu_ai_act_2024]", "Population group coverage in evaluation data is documented; groups with insufficient representation are flagged as evaluation limitations. [ref:iso_42005_2025]", "Metric trade-off documentation explicitly states which competing fairness constraints take precedence for this deployment context and the reasoning. [ref:iso_42001_2023]", "For high-impact-decision and eu-high-risk profiles: legal review is obtained for threshold decisions affecting protected characteristics. [ref:eu_ai_act_2024]" ], "runtime_test": [ "{'test': 'Run the fairness evaluation suite on a model variant with a known synthetic disparity and confirm that the disparity is correctly detected and exceeds the defined threshold.', 'unverified': True} [unverified]", "{'test': 'Verify that disaggregated performance metrics are reported per population group independently, not only as aggregate metrics.', 'ref': 'nist_rmf_v1'} [ref:nist_ai_rmf_1_0]", "{'test': 'Confirm that evaluation data for each population group is disjoint from training data.', 'ref': 'iso_42001_2023'} [ref:iso_42001_2023]" ], "evidence": [ "model:fairness-evaluation-protocol-document-wi — Fairness evaluation protocol document with pre-specified populations, harms, metrics, rationale, legal basis, and thresholds. [ref:eu_ai_act_2024]", "model:disaggregated-evaluation-results-per-pop — Disaggregated evaluation results per population group and harm type, linked to model artifact hash. [ref:nist_ai_rmf_1_0]", "model:trade-off-decision-record-with-explicit — Trade-off decision record with explicit rationale and risk-acceptance sign-off. [unverified]", "model:legal-review-record-for-deployments-invo — Legal review record for deployments involving legally protected characteristics. [ref:eu_ai_act_2024]", "model:iso-42005-2025-impact-assessment-record — ISO 42005:2025 impact assessment record for high-impact-decision and eu-high-risk profiles. [ref:iso_42005_2025]" ] }, "lenses": { "engineering": "Build disaggregated evaluation infrastructure that reports per-group metrics independently; integrate threshold check as a deployment gate component; ensure evaluation datasets include adequate population group representation.", "evaluation": "Own metric selection and rationale documentation; identify population group coverage gaps; ensure pre-specification of thresholds; document all trade-offs honestly including where fairness constraints conflict.", "red_team": "Probe for demographic disparities not covered by the selected metrics; test edge cases for specific subpopulations; attempt to identify proxy discrimination through correlated features.", "grc": "Map fairness evaluation to EU AI Act Art. 9(7) and Annex III; obtain legal review for protected characteristic decisions; track fairness disparity rates as governance KRIs; ensure impact assessment under ISO 42005:2025 for high-impact deployments.", "mlops": "Surface disaggregated fairness metrics on model registry cards; alert on fairness metric drift in production (see CR layer); track metric trends across model versions." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "EV-05 covers pre-deployment fairness and bias evaluation. Ongoing fairness monitoring in production is covered in the CR layer. EV-09 determines which deployment risk classification triggers mandatory fairness evaluation.", "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.11", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.11 (MEASURE function) provides that fairness and bias are evaluated and results are documented. EV-05’s disaggregated error-rate measurement across protected subgroups produces the documented fairness and bias evaluation this subcategory requires.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "6.1.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 risk assessment and evaluation requirements apply to fairness and bias dimensions.", "uncovered_portion": "ISO 42001 does not prescribe fairness metric selection methodology.", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Art. 9(7) requires high-risk AI systems to be tested for non-discrimination; Annex III identifies categories where fairness failures are particularly high-risk.", "uncovered_portion": "EU AI Act does not specify which fairness metrics satisfy Art. 9(7); metric selection remains implementation-defined.", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. V", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes outcomes analysis comparing model results against expectations. For credit and lending models, disaggregated fairness evaluation is a natural extension of that outcomes analysis; fair-lending obligations themselves arise under other law. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 predates comprehensive fairness evaluation methodology for AI systems.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "llm10", "requirement_id": "LLM09:2025", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Misinformation generation (LLM09) includes representation disparities; fairness evaluation covers this for generative-AI profiles.", "uncovered_portion": "LLM Top 10 2025 does not address structured fairness evaluation methodology.", "reviewed_on": "2026-06-26", "source_version": "2025", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "aicm", "requirement_id": "GRC-11", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AICM bias and fairness assessment controls align with structured fairness evaluation requirements.", "uncovered_portion": "AICM does not specify pre-specification of thresholds or metric trade-off documentation requirements.", "reviewed_on": "2026-06-26", "source_version": "1.1", "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "nist_ai_600_1", "requirement_id": "HUMAN-AI-CONFIG", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI 600-1 identifies Human-AI Configuration as a GenAI risk encompassing automation bias, over-reliance, and the erosion of human oversight capacity — dynamics that intensify when models produce systematically biased outputs across demographic groups. EV-05 fairness evaluation supports this risk category by measuring demographic performance disparities that can exacerbate biased automated decisions.", "uncovered_portion": "HUMAN-AI-CONFIG addresses the full human-oversight configuration problem beyond just measurement of bias; interface design, user calibration, and override mechanisms are not covered by EV-05.", "source_version": "2024", "reviewed_on": "2026-06-26", "mapping_confidence": "medium", "provisional": true, "provisional_note": "NIST AI 600-1 GenAI Profile uses category-level identifiers (e.g., CONFABULATION, CBRN); action-level subcategory mapping was not possible from the category reference. Treat as category-level guidance only.", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_aitg", "requirement_id": "AITG-APP-10", "fit": "direct", "direction": "control-supports-requirement", "rationale": "AITG-APP-10 (Testing for Content Bias) measures biased or disparate model outputs. EV-05's disaggregated error-rate measurement across protected attribute subgroups directly implements this test.", "source_locator": { "test_id": "AITG-APP-10", "test_name": "Testing for Content Bias" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "unwantedbiastesting", "fit": "direct", "rationale": "Pre-deployment fairness evaluation with disaggregated per-group metrics against thresholds is the test-for-unwanted-bias control.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0008", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"The model system has a documented, pre-specified fairness evaluation protocol executed on…\" enacts ATLAS mitigation AML.M0008 Validate AI Model; OpenCRE crosswalks this control’s OWASP AI Exchange concept (unwantedbiastesting) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "profiles": [ "general-predictive-ml", "generative-ai", "high-impact-decision", "us-regulated-banking", "eu-high-risk" ], "assurance_target": { "what": "Every model in-scope has documented, disaggregated fairness evaluation results against pre-specified thresholds with explicit trade-off decisions and legal review where required.", "how": "Pre-specified evaluation protocol + disaggregated metric reporting + threshold check + trade-off documentation.", "frequency": "Per deployment event; on significant distribution shift; annually for high-impact-decision profile." }, "canonical_id": "apeiris://model/controls/EV-05", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-9", "mapping_fit": "partial", "notes": "Art-9 requires providers to establish, implement, document and maintain a risk management system throughout the lifecycle of a high-risk AI system.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "The model system has a documented, pre-specified fairness evaluation protocol executed on data disjoint from training data, with disaggregated results per population group and harm type measured against pre-specified acceptance thresholds, and legal review obtained for any deployment affecting legally protected characteristics.", "evidence_required": [ "fairness_evaluation_protocol document with pre-specified population_groups, harm_types, metric_selections, selection_rationale, legal_basis, and acceptance_thresholds — version-controlled and signed before any evaluation run begins", "disaggregated_evaluation_results report showing per-group performance metrics independently for each identified population group, with group_id, sample_count, and metric_values per harm type", "metric_tradeoff_decision_record explicitly stating which competing fairness constraints (e.g., demographic parity vs. equalized odds) take precedence for this deployment context and the documented rationale", "evaluation_data_disjointness_attestation confirming evaluation data for each population group does not overlap with the training corpus, with data_source_ids and overlap_check_method documented", "legal_review_record for any deployment affecting legally protected characteristics, with reviewing_authority identity and review_date" ], "machine_tests": [ "Run fairness evaluation suite on a model variant with a known synthetic 20% accuracy disparity between population groups → assert disparity is detected, reported in per-group output, and flagged as threshold_violation", "Check evaluation results artifact for aggregate-only metric reporting → assert per_group_results field is present and populated with results for each pre-specified population group", "Verify evaluation dataset identifiers for each population group against the training corpus manifest → assert overlap_fraction equals zero for all groups", "Query evaluation manifest for threshold_specification_timestamp relative to evaluation_run_timestamp → assert thresholds were recorded before the evaluation run began, not after" ], "human_review": [ "Review metric selection rationale to verify the chosen fairness metrics are appropriate for the use case and that metric trade-offs are explicitly documented with a stated precedence decision rather than left implicit", "Assess population group coverage for adequacy — verify that historically disadvantaged groups relevant to the deployment context are included and that groups with insufficient representation are flagged as evaluation limitations rather than silently omitted", "Examine threshold violation records and risk-acceptance decisions to confirm they were made with explicit rationale and appropriate authority, and were not set to levels that trivially pass known disparities" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Selecting a single fairness metric such as demographic parity and presenting it as universally sufficient without documenting the explicit trade-offs between competing fairness definitions for the specific deployment", "Defining acceptance thresholds after observing the evaluation results, enabling post-hoc selection of thresholds that the existing data happen to satisfy", "Reporting only aggregate performance metrics across the full evaluation population and omitting disaggregated analysis by each identified population group", "Using the model's training data or a subset of it as the fairness evaluation dataset, which masks distributional bias learned during training and produces artificially favorable disparity measurements", "Omitting fairness evaluation for models that make high-impact decisions affecting legally protected characteristics on the basis that the model does not directly observe protected attributes, when proxy features correlated with those attributes are present" ], "update_status": "current", "cross_domain": { "feeds": [ "apeiris://ethics/controls/EG-08" ] }, "layer_code": "EV" }, { "id": "EV-06", "layer": "EV", "plane": "both", "name": "Reproducible Evaluation Design", "plain": "Evaluation designs are documented with sufficient detail — benchmark selection criteria, anti-contamination measures, environment specification, random seeds, and software dependency versions — to allow independent reproduction of results. Evaluation artifacts are signed and content-addressed.", "threat": { "tags": [ "MR-VAL", "MR-PERFORMANCE" ], "desc": "Irreproducible evaluation designs allow cherry-picked results, benchmark contamination, and evaluation gaming to go undetected, undermining the reliability of deployment gate decisions and eroding trust in reported capabilities." }, "standard": [ "NIST AI RMF MEASURE 2.1 — TEVV test sets, metrics, and tool documentation", "ISO/IEC 42001:2023 A.6.2.4", "NIST AI 600-1 — Generative AI Profile" ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://airc.nist.gov/RMF", "source_type": "voluntary-standard", "license": "public-domain", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/EV-06 Reproducible Evaluation Design control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "url": "https://www.iso.org/standard/81230.html", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/EV-06 Reproducible Evaluation Design control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_600_1", "authority": "NIST", "title": "NIST AI 600-1: Artificial Intelligence — Generative AI Profile", "url": "https://airc.nist.gov/Docs/1", "source_type": "voluntary-standard", "license": "public-domain", "artifact_hash": null, "supersedes": null, "status": "current", "retrieved_on": "2026-06-26", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2024-07-26", "source_id": "nist_ai_600_1", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI 600-1: Artificial Intelligence — Generative AI Profile requirements informing the apeiris://model/controls/EV-06 Reproducible Evaluation Design control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_aisvs_v1", "authority": "OWASP", "title": "OWASP AI Security Verification Standard v1.0", "url": "https://github.com/OWASP/AISVS", "source_type": "voluntary-standard", "license": "CC BY-SA 4.0", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2026-06-26", "retrieved_on": "2026-06-26", "source_id": "owasp_aisvs_v1", "relationship": "implementation_pattern", "rationale": "Establishes OWASP AI Security Verification Standard v1.0 requirements informing the apeiris://model/controls/EV-06 Reproducible Evaluation Design control.", "reviewed_on": "2026-07-01", "canonical_url": "https://github.com/OWASP/AISVS" } ], "implementation": { "pattern": "Evaluation design document captures all parameters required for independent reproduction; evaluation artifacts are signed and content-addressed; contamination screening is applied before benchmark selection is finalized.", "steps": [ "Document benchmark selection criteria before evaluation: why each benchmark was chosen, what it measures, what its known limitations are, and whether any alternatives were considered and rejected.", "Screen selected benchmarks for contamination against the model's training data corpus; document the contamination screening methodology and results; exclude or flag contaminated benchmarks.", "Capture all parameters required for reproduction: random seeds, software dependency versions and hashes, hardware configuration, serving framework configuration, evaluation script version and hash, prompt templates, and any post-processing steps.", "Version-control the evaluation design document alongside the evaluation script; tag the evaluation design document version in the signed evaluation manifest (EV-01).", "Sign all evaluation artifacts — design document, scripts, datasets, results — with individually attributed key material; record artifact hashes in the evaluation manifest.", "Run evaluation in a containerized or otherwise reproducible environment; capture the container image hash or equivalent environment fingerprint.", "For new benchmark additions: conduct an independent reproduction run using only the design document as input; accept the benchmark if reproduction results are within defined tolerance." ], "anti_patterns": [ "Selecting benchmarks after observing model performance on them; benchmark selection must be pre-specified.", "Omitting contamination screening for training data vs. evaluation benchmark overlap.", "Treating evaluation scripts as implicit documentation; scripts must be version-controlled, signed, and accompanied by explicit parameter documentation.", "Mixing different evaluation environments (hardware, framework versions) across runs without documenting the difference and its impact." ] }, "validation": { "design_check": [ "Benchmark selection criteria are documented and version-controlled before any evaluation run begins; selection is pre-specified, not post-hoc. [ref:nist_ai_rmf_1_0]", "Contamination screening methodology is documented and applied to all benchmarks before final selection; contaminated benchmarks are excluded or flagged. [ref:nist_ai_600_1]", "Evaluation design document captures all parameters required for reproduction at sufficient granularity for independent replication. [ref:iso_42001_2023]", "All evaluation artifacts are signed with individually attributed key material and their hashes are recorded in the evaluation manifest. [ref:iso_42001_2023]" ], "runtime_test": [ "{'test': 'Conduct an independent reproduction run using only the design document as input; verify results match within the defined tolerance.', 'ref': 'nist_rmf_v1'} [ref:nist_ai_rmf_1_0]", "{'test': 'Verify that the evaluation script hash recorded in the manifest matches the hash of the script used in the current run.', 'unverified': True} [unverified]", "{'test': 'Confirm that contamination screening results are present for each benchmark and that contaminated benchmarks are absent from the final evaluation suite.', 'ref': 'nist_ai_600_1'} [ref:nist_ai_600_1]" ], "evidence": [ "model:version-controlled-signed-benchmark-sel — Version-controlled, signed benchmark selection document with pre-specified selection criteria. [ref:nist_ai_rmf_1_0]", "model:contamination-screening-report-documenti — Contamination screening report documenting methodology, training corpus reference, and benchmark-level results. [ref:nist_ai_600_1]", "model:evaluation-design-document-capturing-all — Evaluation design document capturing all reproduction parameters, version-controlled and signed. [ref:iso_42001_2023]", "model:independent-reproduction-run-results-wit — Independent reproduction run results within tolerance, confirming design document sufficiency. [unverified]", "model:signed-evaluation-artifacts-scripts-da — Signed evaluation artifacts (scripts, datasets, results) with hashes recorded in the evaluation manifest. [unverified]" ] }, "lenses": { "engineering": "Containerize evaluation environments to enable reproducibility; implement artifact signing pipeline; build contamination screening tooling integrated into benchmark selection workflow.", "evaluation": "Own benchmark selection criteria and contamination screening; define reproduction tolerance thresholds; ensure design document granularity is sufficient for independent replication.", "red_team": "Attempt to reproduce evaluation results using only the design document; identify parameters that are underdocumented or environment-specific; probe for contaminated benchmarks missed by screening.", "grc": "Track reproduction success rates as a governance KRI for evaluation integrity; include reproducibility requirements in model governance policy; audit evaluation design documents as part of annual governance review.", "mlops": "Integrate containerized evaluation environments into the MLOps platform; surface benchmark contamination screening status on model cards; alert on evaluation environment configuration drift." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "EV-06 covers reproducible evaluation design and anti-contamination measures. EV-10 covers content-addressed provenance of evaluation results. EV-07 uses reproducible evaluation design as the baseline for regression testing.", "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.1 (MEASURE function) provides that test sets, metrics, and details about the tools used during TEVV are documented. EV-06’s reproducible evaluation design pins the test sets, metrics, seeds, and environments so the TEVV documentation this subcategory requires is complete and re-runnable.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.4 (AI system verification and validation) requires validation to be specified and documented; EV-06’s reproducible design makes documented validation independently re-runnable.", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Art. 9(5) requires testing procedures to be documented; reproducible design operationalizes this requirement.", "uncovered_portion": "EU AI Act does not specify benchmark contamination screening or reproduction testing.", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. V", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes documenting validation work in enough detail for others to review and rely on it. EV-06's reproducibility manifest gives validators the artifacts needed to independently re-run and confirm reported results. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 does not address benchmark contamination or AI-specific reproducibility requirements.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aisvs", "requirement_id": "C3.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OWASP AISVS C3.2 (Model Validation & Testing) requires documented, repeatable pre-deployment validation. EV-06's reproducible evaluation design — pinned datasets, seeds, and environments — makes C3.2's re-testing requirements (e.g., re-evaluation after quantization, req 3.2.2) verifiable.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "chapter": "C3.2", "chapter_name": "Model Validation & Testing" }, "normative_force": "voluntary-standard", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "MDS-05", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CSA AICM MDS-05 (Model Security domain) is mapped as partial: EV-06’s reproducibility manifest — pinned datasets, seeds, and environments — gives AICM assessors the artifacts needed to independently re-run and verify model evaluations.", "uncovered_portion": "AICM does not specify contamination screening or artifact signing.", "reviewed_on": "2026-06-26", "source_version": "1.1", "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" } ], "profiles": [ "general-predictive-ml", "generative-ai", "hosted-api", "continuously-learning", "high-impact-decision", "us-regulated-banking", "eu-high-risk", "frontier-capability" ], "assurance_target": { "what": "Every evaluation run can be independently reproduced from the design document within defined tolerance; contamination screening is documented for all benchmarks.", "how": "Pre-specified design document + contamination screening + independent reproduction test + signed artifact hashes.", "frequency": "Per deployment event; on benchmark suite changes." }, "canonical_id": "apeiris://model/controls/EV-06", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-9", "mapping_fit": "partial", "notes": "Art-9 requires providers to establish, implement, document and maintain a risk management system throughout the lifecycle of a high-risk AI system.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "Every evaluation run against a model artifact can be independently reproduced from the evaluation design document alone within the defined tolerance by a party who was not involved in the original run; all benchmarks have documented contamination screening results; and all evaluation artifacts are signed with SHA-256 content-addressed hashes recorded in the evaluation manifest.", "evidence_required": [ "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered — signed and committed before any evaluation run begins", "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier" ], "machine_tests": [ "Execute independent reproduction run using only the design document as input → assert final metric deltas are within the defined tolerance bounds for all benchmarks in the suite", "Compare evaluation script hash recorded in the signed manifest against the hash of the script used in the current run → assert hashes match exactly", "Query contamination screening report for each benchmark in the active evaluation suite → assert no benchmark has contamination_result=flagged without an accompanying exclusion_record or documented exception with risk-acceptance", "Verify benchmark selection document commit timestamp precedes the first evaluation run timestamp for this model version → assert selection was pre-specified and not post-hoc" ], "human_review": [ "Review benchmark selection criteria to assess whether the chosen benchmarks measure what they claim for the intended deployment context and whether any rejected alternatives were documented with rationale", "Assess contamination screening methodology for sufficiency — verify that the screening covers the actual training corpus at adequate granularity and that exclusion decisions for flagged benchmarks are justified rather than waived", "Examine the evaluation design document for underdocumented or environment-specific parameters that would prevent independent reproduction, particularly hardware configuration and serving framework settings that may differ between evaluation and production" ], "blocking_effect": "blocks-deployment", "normative_status": "voluntary-standard", "anti_patterns": [ "Selecting benchmarks after observing model performance on candidate benchmark sets, then presenting the final selection as a pre-specified evaluation design", "Omitting contamination screening for training data vs. evaluation benchmark overlap, allowing inflated benchmark scores that reflect memorization rather than genuine capability", "Treating evaluation scripts as implicit documentation — not version-controlling them or capturing dependency versions — making independent reproduction structurally impossible", "Mixing hardware configurations or framework versions across evaluation runs without documenting the difference and its measured impact on metric values", "Accepting a benchmark into the active suite without conducting an independent reproduction test, leaving the design document's reproduction claim unverified" ], "update_status": "current", "layer_code": "EV" }, { "id": "EV-07", "layer": "EV", "plane": "both", "name": "Regression Testing on Updates", "plain": "Every fine-tune, RLHF update, guardrail change, or other model update triggers a regression evaluation run against a versioned baseline. Neither capability regression nor safety regression is permitted to pass silently; any regression finding blocks promotion unless explicitly accepted.", "threat": { "tags": [ "MR-PERFORMANCE", "MR-VAL", "LLM04:2025" ], "desc": "Model updates — including RLHF fine-tunes and guardrail modifications — can silently degrade previously-verified capabilities or safety properties. LLM04 (Data and Model Poisoning) effects may emerge or regress across updates. Silent regression reaches production users without opportunity for detection." }, "standard": [ "NIST AI RMF MANAGE 2.4 — Supersede or deactivate systems inconsistent with intended use", "ISO/IEC 42001:2023 §10.2 — Nonconformity and corrective action", "EU AI Act Art. 9(4) — Iterative risk management", "SR 26-2 Sec. V — Model Validation and Monitoring (ongoing monitoring)" ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://airc.nist.gov/RMF", "source_type": "voluntary-standard", "license": "public-domain", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/EV-07 Regression Testing on Updates control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "url": "https://www.iso.org/standard/81230.html", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/EV-07 Regression Testing on Updates control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "authority": "European Parliament and Council", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "source_type": "regulation", "license": "public", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/EV-07 Regression Testing on Updates control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Revised Guidance on Model Risk Management", "url": "https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm", "source_type": "supervisory-guidance", "license": "public", "artifact_hash": null, "supersedes": [ "SR 11-7", "SR 21-8" ], "status": "current", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/EV-07 Regression Testing on Updates control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_llm10_2025", "authority": "OWASP", "title": "OWASP Top 10 for LLM Applications 2025", "url": "https://genai.owasp.org", "source_type": "voluntary-standard", "license": "CC BY-SA 4.0", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "2025", "published_on": "2024-11-17", "retrieved_on": "2026-06-26", "source_id": "owasp_llm10", "relationship": "implementation_pattern", "rationale": "Establishes OWASP Top 10 for LLM Applications 2025 requirements informing the apeiris://model/controls/EV-07 Regression Testing on Updates control.", "reviewed_on": "2026-07-01" } ], "monitoring_schema": { "metrics": [ { "name": "capability_regression_rate", "description": "Fraction of capability benchmark tasks where the updated model scores below the signed baseline threshold. Measured per benchmark category.", "type": "ratio", "threshold": 0.02, "alert_on": "exceed", "unit": "fraction", "metric_id": "capability_regression_rate", "metric_type": "performance", "measure": "percentage-regression-from-baseline", "population": "all-evaluated-model-versions", "comparison": { "operator": "greater-than", "value": 0.02, "window": "per-evaluation-run", "evaluation_mode": "batch" }, "severity": "high" }, { "name": "safety_regression_rate", "description": "Fraction of safety evaluation scenarios where the updated model violates policy relative to the signed baseline. Zero tolerance: any safety regression is a blocking finding.", "type": "ratio", "threshold": 0, "alert_on": "exceed", "unit": "fraction", "metric_id": "safety_regression_rate", "metric_type": "performance", "measure": "percentage-regression-from-baseline", "population": "all-evaluated-model-versions", "comparison": { "operator": "greater-than", "value": 0, "window": "per-evaluation-run", "evaluation_mode": "batch" }, "severity": "high" }, { "name": "alignment_drift_delta", "description": "Absolute delta in policy-conformance evaluation score between the updated model and the signed baseline. Applies to generative-AI profile only.", "type": "delta", "threshold": 0.05, "alert_on": "exceed", "unit": "score_delta", "metric_id": "alignment_drift_delta", "metric_type": "performance", "measure": "score-delta", "population": "all-evaluated-model-versions", "comparison": { "operator": "greater-than", "value": 0.05, "window": "per-evaluation-run", "evaluation_mode": "batch" }, "severity": "high" }, { "name": "refusal_rate_delta", "description": "Absolute delta in refusal rate on policy-violating prompt categories between the updated model and the signed baseline. Applies to generative-AI profile only.", "type": "delta", "threshold": 0.03, "alert_on": "exceed", "unit": "rate_delta", "metric_id": "refusal_rate_delta", "metric_type": "performance", "measure": "score-delta", "population": "all-evaluated-model-versions", "comparison": { "operator": "greater-than", "value": 0.03, "window": "per-evaluation-run", "evaluation_mode": "batch" }, "severity": "high" }, { "name": "fairness_disparity_delta", "description": "Change in maximum fairness disparity metric between the updated model and the signed baseline. Applies to profiles with mandatory fairness evaluation.", "type": "delta", "threshold": 0.02, "alert_on": "exceed", "unit": "disparity_delta", "metric_id": "fairness_disparity_delta", "metric_type": "performance", "measure": "score-delta", "population": "all-evaluated-model-versions", "comparison": { "operator": "greater-than", "value": 0.02, "window": "per-evaluation-run", "evaluation_mode": "batch" }, "severity": "high" } ], "window_context": "Per-update: triggered on every fine-tune, RLHF update, guardrail change, serving-framework change, or quantization change. Compared against the most recent signed baseline evaluation manifest.", "sampling_rate": "100% of the defined regression suite for safety metrics. Capability metrics may use stratified sampling at ≥50% coverage only when suite size exceeds 10,000 tasks and latency constraints prevent full evaluation — sampling must be documented and consistent across runs." }, "implementation": { "pattern": "Per-update regression evaluation triggered automatically in the deployment pipeline, comparing against a signed baseline; safety regression is zero-tolerance; capability regression triggers a blocking finding above the defined threshold.", "steps": [ "Define and version-control the regression evaluation suite as a distinct artifact from the full evaluation suite; the regression suite prioritizes: safety scenarios, alignment/refusal scenarios (generative-AI profile), previously-reported failure modes, and benchmark coverage representative of the intended distribution.", "Store a signed baseline evaluation result for each model version promoted to production; the baseline result is the reference for all subsequent regression comparisons.", "On each update trigger (fine-tune, RLHF update, guardrail change, serving-framework change, quantization), run the full regression suite against the updated model artifact before promotion.", "Compute regression metrics per the monitoring schema; apply zero-tolerance threshold to safety_regression_rate — any safety regression is an automatic blocking finding requiring root-cause analysis before re-evaluation.", "For capability regression: block promotion if capability_regression_rate exceeds the defined threshold; allow promotion with documented risk-acceptance and time-bound remediation commitment if regression is below threshold but non-zero.", "Record all regression results in a signed regression manifest linked to: the updated model artifact hash, the baseline artifact hash, the regression suite version, and the run timestamp.", "Update the signed baseline to the new version only after a successful regression evaluation that passes all thresholds." ], "anti_patterns": [ "Skipping regression evaluation for 'minor' updates such as prompt template changes, system-prompt modifications, or serving-framework version upgrades — any of these can introduce regression.", "Treating safety regression as a threshold metric rather than a zero-tolerance finding.", "Updating the signed baseline before completing regression evaluation, effectively erasing the reference point.", "Running regression evaluation on a different environment configuration than the production serving environment, masking environment-specific regressions." ] }, "validation": { "design_check": [ "Regression suite is defined, versioned, and covers safety scenarios, alignment scenarios (generative-AI profile), and known failure modes from prior red-team exercises. [ref:nist_ai_rmf_1_0]", "Pipeline configuration triggers regression evaluation automatically on all defined update types with no manual bypass path except documented exception. [ref:iso_42001_2023]", "Safety regression threshold is documented as zero-tolerance; the pipeline blocks on any non-zero safety_regression_rate without manual override. [ref:eu_ai_act_2024]", "Signed baseline artifact is version-locked and cannot be updated without a successful regression evaluation pass. [ref:iso_42001_2023]" ], "runtime_test": [ "{'test': 'Introduce a synthetic safety regression in a test model variant and verify the pipeline blocks promotion with an auditable blocking record.', 'unverified': True} [unverified]", "{'test': 'Verify that the regression manifest references both the updated model artifact hash and the signed baseline artifact hash.', 'ref': 'nist_rmf_v1'} [ref:nist_ai_rmf_1_0]", "{'test': 'Confirm that sampling (if used for capability metrics) meets the defined minimum coverage threshold and is documented consistently.', 'unverified': True} [unverified]" ], "evidence": [ "model:versioned-regression-evaluation-suite-ar — Versioned regression evaluation suite artifact with signed hash. [ref:iso_42001_2023]", "model:signed-regression-manifests-for-each-upd — Signed regression manifests for each update event, linked to updated artifact hash, baseline artifact hash, and regression suite version. [ref:nist_ai_rmf_1_0]", "model:signed-baseline-evaluation-results-for-e — Signed baseline evaluation results for each production model version. [ref:sr262_2026]", "model:blocking-records-for-any-regression-find — Blocking records for any regression finding, including root-cause analysis for safety regressions. [unverified]", "model:risk-acceptance-records-for-sub-threshol — Risk-acceptance records for sub-threshold capability regression findings with time-bound remediation commitments. [ref:sr262_2026]" ] }, "lenses": { "engineering": "Automate regression suite execution as a blocking pipeline stage on all defined update types; implement zero-tolerance enforcement for safety_regression_rate; version-lock the signed baseline to prevent unauthorized updates.", "evaluation": "Define and maintain the regression suite; ensure safety scenario coverage is comprehensive; own threshold calibration for capability regression; require root-cause analysis for all safety regression findings.", "red_team": "Test the regression suite for coverage gaps; attempt to introduce regressions through update patterns not covered by the current trigger list; verify zero-tolerance enforcement cannot be bypassed.", "grc": "Map regression testing requirements to SR 26-2 §III.C ongoing monitoring and EU AI Act Art. 9(4) iterative risk management; track regression rates as governance KRIs; escalate safety regression findings to governance committee.", "mlops": "Integrate regression evaluation into the model update pipeline with automatic triggers; surface regression metric trends on model dashboards; alert on any safety regression finding immediately; track regression suite coverage over time." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "EV-07 covers pre-deployment regression testing on updates. Ongoing production monitoring for regression is covered in the CR layer. EV-06 (reproducible evaluation design) provides the baseline design that makes regression comparison valid.", "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE-2.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MANAGE-2.4 (MANAGE function) provides that mechanisms and assigned responsibilities exist to supersede, disengage, or deactivate AI systems that demonstrate performance inconsistent with intended use. EV-07’s regression gate detects when an updated model’s behavior is inconsistent with intended use before it supersedes the incumbent, giving the supersede/deactivate mechanism a pre-deployment trigger.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "10.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 Clause 10.2 (Nonconformity and corrective action) requires reacting to nonconformities and correcting them. EV-07’s regression findings are structured nonconformity detections raised before an update ships.", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Art. 9(4) requires the risk management system to be updated when the AI system is modified; regression testing operationalizes this for model updates.", "uncovered_portion": "EU AI Act does not specify regression suite design or monitoring schema.", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. V", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes ongoing monitoring to confirm models continue to perform as intended; regression testing before each update is the pre-deployment component of that continuing assurance. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 does not address generative-AI-specific regression categories (alignment drift, refusal rate delta).", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aisvs", "requirement_id": "C3.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OWASP AISVS C3.2 (Model Validation & Testing) requires that model, version, or routing changes trigger security re-evaluation before continued use (req 3.2.3). EV-07's regression testing on every update directly implements that requirement.", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "chapter": "C3.2", "chapter_name": "Model Validation & Testing" }, "normative_force": "voluntary-standard", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "llm10", "requirement_id": "LLM04:2025", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Regression testing detects emerging or changed LLM04 (Data and Model Poisoning) effects across model updates.", "uncovered_portion": "LLM Top 10 2025 does not address regression testing methodology or update-triggered evaluation.", "reviewed_on": "2026-06-26", "source_version": "2025", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "aicm", "requirement_id": "CCC-02", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AICM regression testing controls align with structured regression evaluation on model updates.", "uncovered_portion": "AICM does not specify monitoring schema structure or safety regression zero-tolerance policy.", "reviewed_on": "2026-06-26", "source_version": "1.1", "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "direction": "out-of-scope", "rationale": "MITRE ATLAS v5.6.0 addresses adversarial attack techniques; regression testing on model updates is not an adversarial threat category.", "reviewed_on": "2026-06-26", "source_version": "v2026.06", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "owasp_ai_exchange", "requirement_id": "continuousvalidation", "fit": "supporting", "rationale": "Triggering regression evaluation against a baseline on every fine-tune, RLHF, or guardrail change is continuous re-validation on updates.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0008", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every model update — including fine-tunes, RLHF updates, guardrail changes,…\" enacts ATLAS mitigation AML.M0008 Validate AI Model; complements the control’s existing technique mapping AML.T0043 (defends_against) — OpenCRE crosswalks the AI Exchange concept (continuousvalidation) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "profiles": [ "general-predictive-ml", "generative-ai", "hosted-api", "continuously-learning", "high-impact-decision", "us-regulated-banking", "eu-high-risk", "frontier-capability" ], "assurance_target": { "what": "Every model update is evaluated against a signed baseline before promotion; safety regression is zero-tolerance; capability regression above threshold is blocking.", "how": "Automated regression suite execution + monitoring schema metrics + signed regression manifests + zero-tolerance enforcement.", "frequency": "Per update event (fine-tune, RLHF, guardrail change, serving-framework change, quantization change)." }, "canonical_id": "apeiris://model/controls/EV-07", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-9", "mapping_fit": "partial", "notes": "Art-9 requires providers to establish, implement, document and maintain a risk management system throughout the lifecycle of a high-risk AI system.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "Every model update — including fine-tunes, RLHF updates, guardrail changes, serving-framework changes, and quantization changes — triggers a full regression evaluation against a signed baseline before promotion; safety_regression_rate is zero-tolerance with any non-zero value producing an automatic blocking finding; and capability_regression_rate exceeding the defined threshold blocks promotion unless a signed risk-acceptance record is present.", "evidence_required": [ "versioned_regression_suite_artifact with signed hash covering safety scenarios, alignment/refusal scenarios for generative-ai profile, and failure modes documented in prior red-team exercises", "signed_regression_manifest for each update event linking updated_model_artifact_hash, baseline_artifact_hash, regression_suite_version, run_timestamp, and per-metric regression_results including safety_regression_rate and capability_regression_rate", "signed_baseline_evaluation_results for the production model version serving as the regression reference, version-locked before the update is applied", "blocking_record for any regression finding including root_cause_analysis for safety regressions and proposed remediation with estimated completion date", "risk_acceptance_record for any sub-threshold capability regression finding with explicit rationale, accepting_authority identity, and time_bound_remediation_commitment" ], "machine_tests": [ "Introduce a synthetic safety regression (deliberate policy-violating response rate increase) in a test model variant and trigger the pipeline → assert pipeline blocks promotion with blocking_finding=safety_regression_detected and root_cause_analysis_required=true", "Verify regression manifest for each update event references both updated_model_artifact_hash and signed_baseline_artifact_hash → assert both fields are non-null and link to verifiable signed artifacts", "Submit a model update introducing a capability regression exceeding the defined threshold → assert pipeline blocks promotion unless a signed risk_acceptance_record with accepting_authority is present in the manifest", "Attempt to update the signed baseline artifact before regression evaluation completes on the current update → assert baseline update is rejected with error baseline_locked_during_active_evaluation" ], "human_review": [ "Review regression suite scope to verify it adequately covers safety and alignment scenarios most likely to regress given the nature of the specific update, including failure modes from recent red-team exercises not yet captured in the suite", "Assess root-cause analyses for safety regression findings to determine whether the proposed remediation addresses the underlying vulnerability pattern or only patches the specific tested inputs", "Examine risk-acceptance records for sub-threshold capability regression findings to confirm the accepting authority had sufficient information and that the time-bound remediation commitment is actionable with an assigned owner" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Skipping regression evaluation for updates classified as minor — including prompt template changes, system-prompt modifications, or serving-framework version upgrades — on the assumption they cannot affect model behavior", "Treating safety regression as a threshold metric rather than a zero-tolerance finding, allowing small safety regressions to pass with documented acceptance rather than triggering a blocking finding", "Updating the signed baseline evaluation result to the new model version before completing regression evaluation, eliminating the stable reference point and making regression comparison meaningless", "Running regression evaluation in a different environment configuration than the production serving environment, allowing environment-specific regressions to pass evaluation and reach production undetected", "Defining the regression suite only at initial model development and not updating it to incorporate failure modes discovered in subsequent red-team exercises or production incidents" ], "update_status": "current", "layer_code": "EV" }, { "id": "EV-08", "layer": "EV", "plane": "both", "name": "Independent Validation", "plain": "The team or individual that develops a model does not also validate it for deployment. Validation — including evaluation design review, result review, and deployment authorization — is performed by parties who are independent of the model development function. This implements the SR 26-2 'effective challenge' principle.", "threat": { "tags": [ "MR-VAL" ], "desc": "Without independence between development and validation, confirmation bias and incentive misalignment systematically produce optimistic validation outcomes. Model failures that should block deployment are rationalized rather than escalated." }, "standard": [ "SR 26-2 Sec. V — Model Validation and Monitoring (independence and effective challenge)", "EU AI Act Art. 9 — Risk management system (implied independence)", "ISO/IEC 42001:2023 §9.2 — Internal audit", "NIST AI RMF GOVERN 2.1 — Documented roles and responsibilities" ], "obligations": [ { "id": "SR262-effective-challenge", "text": "SR 26-2 §III.B requires that model validation be conducted by parties who are independent from the model development function, with the authority and ability to provide effective challenge. Independence must be organizational, not merely nominal. For $30B+ asset financial institutions, this is a supervisory expectation subject to examination.", "jurisdiction": [ "us" ], "binding": false, "note": "SR 26-2 is supervisory guidance, not binding regulation; however, non-compliance is subject to supervisory action for in-scope institutions.", "in_scope_threshold": "$30B+ total assets", "reviewed_on": "2026-06-26", "authority": "Federal Reserve System", "instrument": "SR 26-2", "source_ref": "sr262_2026", "normative_force": "supervisory-guidance", "legal_status": "enacted", "provision": "SR 26-2" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-9", "mapping_fit": "partial", "notes": "Art-9 requires providers to establish, implement, document and maintain a risk management system throughout the lifecycle of a high-risk AI system.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "sources": [ { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Revised Guidance on Model Risk Management", "url": "https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm", "source_type": "supervisory-guidance", "license": "public", "artifact_hash": null, "supersedes": [ "SR 11-7", "SR 21-8" ], "status": "current", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/EV-08 Independent Validation control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "authority": "European Parliament and Council", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "source_type": "regulation", "license": "public", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/EV-08 Independent Validation control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "url": "https://www.iso.org/standard/81230.html", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/EV-08 Independent Validation control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://airc.nist.gov/RMF", "source_type": "voluntary-standard", "license": "public-domain", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/EV-08 Independent Validation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Organizational separation of model development and model validation functions, with independent validators having authority to block deployment and escalate findings outside the development team's control.", "steps": [ "Define and document the organizational boundary between model development and model validation functions; establish that validators do not report to the same management chain as model developers for the specific model being validated.", "Grant the validation function explicit authority to: (a) request additional evaluation runs, (b) require remediation of findings, and (c) withhold deployment authorization — without requiring development team approval for these actions.", "Define the validation scope for each model risk tier: what the independent validator reviews, what attestations they sign, and what findings they must document.", "Require independent validator sign-off as a named, attributed approval in the evaluation manifest (EV-01); the validator identity must be distinct from the development team lead.", "Establish an escalation path for validation disputes: if the development team disagrees with a validation finding, escalation goes to a governance committee — not to the development team's management.", "Document the validation function's independence structure annually and make it available to regulators and auditors for in-scope institutions.", "For us-regulated-banking and eu-high-risk profiles: ensure the validation function has access to sufficient technical resources and domain expertise to conduct effective challenge, not merely procedural review." ], "anti_patterns": [ "Treating independence as nominal (different job title, same reporting chain) rather than organizational.", "Granting the development team veto authority over validation findings, which neutralizes the effective challenge function.", "Allowing the same individual to author the evaluation design and approve the validation outcome.", "Scoping independent validation only to final deployment authorization without also covering evaluation design review — late-stage review cannot correct design flaws.", "Using external contractors for validation without ensuring they have the domain expertise and information access required for effective challenge." ] }, "validation": { "design_check": [ "Organizational chart confirms that model validators do not report to the same management chain as model developers for in-scope models. [ref:sr262_2026]", "Validation function authority is documented in policy: right to request additional evaluation, require remediation, and withhold authorization. [ref:sr262_2026]", "Evaluation manifests contain named, attributed validator approval that is distinct from the development team lead identity. [ref:nist_ai_rmf_1_0]", "Escalation path for validation disputes routes to a governance committee independent of the development management chain. [ref:iso_42001_2023]" ], "runtime_test": [ "{'test': 'Attempt a deployment where the development team lead has signed as both author and validator; verify the pipeline rejects the manifest.', 'unverified': True} [unverified]", "{'test': 'Verify that the escalation path for a validation dispute is functional: submit a test dispute and confirm it routes to the governance committee, not development management.', 'unverified': True} [unverified]", "{'test': 'Confirm that validator identity in the evaluation manifest can be independently verified (e.g., via PKI certificate or directory lookup).', 'ref': 'sr262_2026'} [ref:sr262_2026]" ], "evidence": [ "model:organizational-chart-and-reporting-struc — Organizational chart and reporting structure documentation confirming validator independence from development function. [ref:sr262_2026]", "model:validation-function-authority-policy-doc — Validation function authority policy document, version-controlled and approved by governance committee. [ref:sr262_2026]", "model:evaluation-manifests-with-named-attribu — Evaluation manifests with named, attributed validator approvals distinct from development team lead. [ref:nist_ai_rmf_1_0]", "model:validation-dispute-log-if-any-confirmi — Validation dispute log (if any) confirming escalation to governance committee. [unverified]", "model:annual-independence-structure-review-doc — Annual independence structure review documentation for us-regulated-banking profile. [ref:sr262_2026]" ] }, "lenses": { "engineering": "Implement pipeline-level enforcement that rejects evaluation manifests where validator and development lead identities are the same; expose validator identity as a required, attributed field in the manifest schema.", "evaluation": "Operate as an independent function with genuine authority to block deployment; conduct evaluation design review — not just result review — to catch design flaws before evaluation execution; escalate disputes outside the development chain.", "red_team": "Probe whether the independence boundary can be compromised through informal influence; test whether validator authority is nominal or functional by attempting to push a finding-laden model through the gate.", "grc": "Map independence requirements to SR 26-2 §III.B effective challenge for us-regulated-banking profile; document independence structure for regulator review; track validation dispute frequency and outcomes as governance KRIs.", "mlops": "Enforce validator ≠ developer identity check in the pipeline manifest validation step; surface validator identity on model registry cards; alert on any attempt to self-approve a validation." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "EV-08 covers organizational independence of the validation function. EV-01 covers the gate mechanism. EV-10 covers provenance of evaluation records. Together these three controls implement the full SR 26-2 model validation chain.", "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-2.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-2.1 (GOVERN function) provides that roles, responsibilities, and lines of communication for AI risk management are documented and clear. EV-08’s organizationally independent validation function is a documented role separation within AI risk management, giving effective challenge a defined organizational home.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "9.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 §9.2 requires independent internal audits of the AI management system; independent validation applies this principle to model evaluation.", "uncovered_portion": "ISO 42001 internal audit requirements are process-level; model-level validation independence requires additional policy.", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 9 implies independent risk management review for high-risk AI; independent validation supports this requirement.", "uncovered_portion": "EU AI Act does not explicitly mandate model-level validation independence equivalent to SR 26-2 effective challenge.", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. V", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) is the primary source for this control: it describes validation performed with organizational independence, technical competence, and the standing to provide effective challenge to model developers and users. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 applies to $30B+ asset institutions; sub-threshold entities have no binding equivalent though the principle is best practice.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "MDS-03", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CSA AICM MDS-03 (Model Documentation) requires complete, current model documentation. EV-08’s independent validation depends on — and audits — that documentation, so the mapping is supporting rather than direct: documentation is the substrate independent validators review.", "uncovered_portion": "AICM does not specify the organizational depth of independence required for effective challenge.", "reviewed_on": "2026-06-26", "source_version": "1.1", "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" } ], "profiles": [ "general-predictive-ml", "generative-ai", "hosted-api", "continuously-learning", "high-impact-decision", "us-regulated-banking", "eu-high-risk", "frontier-capability" ], "assurance_target": { "what": "Every model deployment authorization is signed by a validator who is organizationally independent of the development team.", "how": "Pipeline-level identity check on manifest + organizational independence policy + governance committee escalation path.", "frequency": "Per deployment event." }, "canonical_id": "apeiris://model/controls/EV-08", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "validation_objective": "Every model deployment authorization is signed by a validator who is organizationally independent of the model development function with no shared management chain at a meaningful level; the validator has documented authority to withhold authorization and escalate findings to a governance committee; and the deployment pipeline rejects any manifest where the validator and development lead share the same organizational identity.", "evidence_required": [ "organizational_chart_and_reporting_structure_document confirming validator independence from the development team for each model system, with management_chain_separation explicitly documented to a meaningful organizational level", "validation_function_authority_policy document version-controlled and governance-committee-approved, explicitly granting rights to request additional evaluation runs, require remediation, and withhold deployment authorization without development team approval", "evaluation_manifests containing named, attributed validator approvals with validator_identity distinct from development_team_lead_identity, linked to verifiable PKI certificate or directory record", "escalation_path_verification_record demonstrating that a test dispute routes to the governance committee and not to the development management chain", "annual_independence_structure_review_document for us-regulated-banking profile, available to regulators and auditors on request" ], "machine_tests": [ "Attempt to deploy a model artifact where the evaluation manifest lists the same identity for both model_author and validator_approver → assert pipeline rejects with error validator_identity_conflict", "Submit a test validation dispute through the escalation path and verify the routing audit record → assert escalation routes to governance_committee_role and not to development_management_chain", "Resolve validator identity in the evaluation manifest via PKI certificate lookup or directory resolution → assert certificate is valid, not expired, and maps to the named individual in the manifest", "Attempt to advance a model system to the production stage without an evaluation manifest containing a named validator approval → assert pipeline blocks with error missing_independent_validation_approval" ], "human_review": [ "Review the organizational chart and reporting structure to confirm that independence is genuine — different management chains at a meaningful organizational level — rather than nominal, where validators and developers share the same reporting hierarchy with only different job titles", "Assess whether the validation function has sufficient technical expertise and information access to conduct effective challenge for this specific model risk level, rather than only procedural sign-off that does not engage with the technical substance of evaluation findings", "Examine validation dispute records, if any, to confirm findings were escalated to the governance committee and that the development team management chain did not exercise veto authority over validation outcomes" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Treating independence as nominal by assigning a different job title to the validator while keeping the validator within the same management reporting chain as the model development team", "Granting the development team veto authority over validation findings — even informally through influence on escalation outcomes — which eliminates the effective challenge function regardless of org chart separation", "Allowing the same individual to author the evaluation design document and approve the validation outcome for the same model system", "Scoping independent validation only to final deployment authorization without also reviewing the evaluation design before execution, making late-stage review unable to correct evaluation design flaws", "Using external contractors for independent validation without verifying they have both the domain expertise required for effective challenge and the information access needed to review all relevant evaluation artifacts" ], "update_status": "current", "layer_code": "EV" }, { "id": "EV-09", "layer": "EV", "plane": "both", "name": "Risk and Applicability Classification", "plain": "Before any evaluation or deployment work begins, each model system is formally classified by deployment risk, use-case type, and applicable regulatory category. The classification determines which evaluation controls, profiles, and obligations apply. EU AI Act system classification, SR 26-2 model risk tier, and capability tier are all recorded.", "threat": { "tags": [ "MR-VAL", "EU-AIA-AnnexIII" ], "desc": "Without formal risk classification, evaluation requirements are applied inconsistently — high-risk models may receive inadequate evaluation while low-risk models receive disproportionate overhead. Misclassification allows high-risk deployments to evade mandatory controls." }, "standard": [ "EU AI Act Art. 6 — Classification rules for high-risk AI systems", "EU AI Act Art. 9 — Risk management system", "EU AI Act Annex III — High-risk AI system categories", "EU AI Act Art. 51 — Classification of GPAI models with systemic risk", "SR 26-2 Sec. VI — Governance and Controls (risk-based application of MRM)", "ISO/IEC 42001:2023 §6.1 — Risk assessment", "ISO/IEC 42005:2025 — AI system impact assessment", "NIST AI RMF MAP 1.5 — Documented organizational risk tolerances" ], "obligations": [ { "id": "EU-AIA-Art6-classification", "text": "EU AI Act Article 6 requires providers to determine whether their AI system falls within Annex III high-risk categories or product-embedded high-risk categories. This classification is mandatory before market placement. Misclassification that results in failing to apply Chapter III obligations is subject to enforcement.", "jurisdiction": [ "eu" ], "binding": true, "effective_date_standalone_high_risk": "2027-12-02", "effective_date_product_embedded": "2028-08-02", "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "legal_status": "enacted", "provision": "Article 6", "effective_from": "2027-12-02" }, { "id": "SR262-model-risk-tiering", "text": "SR 26-2 requires financial institutions to implement a model risk tiering framework that determines the scope and rigor of validation required for each model. Tier assignment must be documented and subject to periodic review. Applies to $30B+ total asset institutions as a supervisory expectation.", "jurisdiction": [ "us" ], "binding": false, "note": "Supervisory guidance; non-compliance subject to supervisory action for in-scope institutions.", "in_scope_threshold": "$30B+ total assets", "reviewed_on": "2026-06-26", "authority": "Federal Reserve System", "instrument": "SR 26-2", "source_ref": "sr262_2026", "normative_force": "supervisory-guidance", "legal_status": "enacted", "provision": "SR 26-2" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-6", "mapping_fit": "partial", "notes": "Art-6 defines the classification criteria for high-risk AI systems. The assurance target classification drives which Article 9-15 requirements apply.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "sources": [ { "id": "eu_ai_act_2024", "authority": "European Parliament and Council", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "source_type": "regulation", "license": "public", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/EV-09 Risk and Applicability Classification control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Revised Guidance on Model Risk Management", "url": "https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm", "source_type": "supervisory-guidance", "license": "public", "artifact_hash": null, "supersedes": [ "SR 11-7", "SR 21-8" ], "status": "current", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/EV-09 Risk and Applicability Classification control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "url": "https://www.iso.org/standard/81230.html", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/EV-09 Risk and Applicability Classification control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42005_2025", "authority": "ISO/IEC", "title": "ISO/IEC 42005:2025 — Artificial Intelligence — AI system impact assessment", "url": "https://www.iso.org/standard/44546.html", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "supersedes": null, "status": "current", "retrieved_on": "2026-06-26", "normative_force": "voluntary-standard", "version": "2025", "published_on": "2025-05-01", "source_id": "iso_42005_2025", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42005:2025 — Artificial Intelligence — AI system impact assessment requirements informing the apeiris://model/controls/EV-09 Risk and Applicability Classification control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://airc.nist.gov/RMF", "source_type": "voluntary-standard", "license": "public-domain", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/EV-09 Risk and Applicability Classification control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Structured classification process applied at model system registration, producing a signed classification record that gates which evaluation controls and profiles are mandatory before any evaluation work begins.", "steps": [ "At model system registration in the model registry, initiate the classification process using a structured classification questionnaire covering: intended use cases, affected populations, decision automation level, human oversight mechanisms, deployment jurisdiction, compute budget, and parameter count.", "Determine EU AI Act classification: (a) prohibited practice under Art. 5, (b) GPAI with systemic risk under Art. 51 (10^25 FLOPs threshold), (c) high-risk under Art. 6 / Annex III, (d) limited-risk transparency obligations under Art. 50, or (e) minimal-risk with no mandatory obligations. Document the classification rationale with reference to specific provisions.", "Determine SR 26-2 model risk tier for US-regulated-banking profile: Tier 1 (high risk — broad use, significant impact, complex methodology), Tier 2 (moderate risk), or Tier 3 (low risk — narrow use, limited impact). Document the tier rationale.", "Assign the applicable Apeiris profiles from the 11 Apeiris profiles based on classification outcomes: general-predictive-ml, generative-ai, multimodal, hosted-api, continuously-learning, high-impact-decision, us-regulated-banking, eu-high-risk, gpai-provider, gpai-systemic-risk, frontier-capability.", "Record the capability tier based on benchmark performance, compute budget, and dangerous capability screen results from EV-03 (for frontier-class models).", "Produce a signed classification record containing: EU AI Act classification, SR 26-2 tier, capability tier, applicable profiles, mandatory controls list, and obligations inventory. Link this record to the model system identifier in the model registry.", "Review and update the classification record on every significant change to use case, deployment context, capability level, or applicable regulation; re-classification triggers re-evaluation of all downstream controls." ], "anti_patterns": [ "Classifying at the model artifact level rather than the model system level (model + deployment context + use case); the same model artifact may receive different classifications in different deployment contexts.", "Self-classifying as 'not high-risk' without documented rationale referencing specific EU AI Act provisions; absence of documentation is not evidence of minimal-risk classification.", "Treating classification as a one-time event; use-case scope creep after initial classification is a common path to misclassified high-risk deployments.", "Conflating EU AI Act classification with SR 26-2 tiering; these are distinct frameworks with distinct criteria and must be determined independently." ] }, "validation": { "design_check": [ "Classification questionnaire covers all required dimensions: use case, affected populations, decision automation level, human oversight, deployment jurisdiction, compute budget, parameter count. [ref:eu_ai_act_2024]", "EU AI Act classification rationale references specific provisions (Art. 5, Art. 6, Art. 50, Art. 51, Annex III) for each system; non-high-risk classification includes an Annex III exclusion rationale. [ref:eu_ai_act_2024]", "SR 26-2 tier rationale is documented for us-regulated-banking profile systems with reference to tier criteria. [ref:sr262_2026]", "Signed classification record is produced before any evaluation work begins and is linked to the model system identifier in the model registry. [ref:iso_42001_2023]", "Classification review trigger process is defined for use-case changes, capability updates, and regulatory changes. [ref:eu_ai_act_2024]" ], "runtime_test": [ "{'test': 'Verify that the model registry cannot be advanced to evaluation stage without a signed classification record for the model system.', 'unverified': True} [unverified]", "{'test': 'For a system with characteristics matching Annex III: verify that the classification process correctly assigns eu-high-risk profile and mandatory Chapter III obligations.', 'ref': 'eu_ai_act_2024'} [ref:eu_ai_act_2024]", "{'test': 'Confirm that a change to use case scope triggers a classification review notification in the model registry.', 'unverified': True} [unverified]" ], "evidence": [ "model:signed-classification-record-for-each-mo — Signed classification record for each model system, containing EU AI Act classification, SR 26-2 tier (where applicable), capability tier, profiles, and obligations inventory. [ref:eu_ai_act_2024]", "model:classification-questionnaire-responses-a — Classification questionnaire responses and rationale documentation, version-controlled. [ref:iso_42001_2023]", "model:classification-review-records-for-all-re — Classification review records for all re-classification events, documenting the trigger, prior classification, new classification, and rationale. [ref:sr262_2026]", "model:iso-42005-2025-impact-assessment-for-hig — ISO 42005:2025 impact assessment for high-impact-decision and eu-high-risk profile systems. [ref:iso_42005_2025]" ] }, "lenses": { "engineering": "Integrate classification record as a mandatory model registry field; block advancement to evaluation stage without signed classification; implement use-case scope change detection to trigger classification review.", "evaluation": "Use the signed classification record to determine mandatory evaluation controls and profiles for each model system; flag classification-evaluation mismatches for governance review.", "red_team": "Probe for classification loopholes: use cases that circumvent Annex III categories through narrow framing; test whether use-case scope creep triggers re-classification correctly.", "grc": "Own the classification policy and questionnaire; track classification distribution (EU AI Act category, SR 26-2 tier) as governance KRIs; coordinate regulatory notifications required for high-risk and systemic-risk GPAI models; commission ISO 42005:2025 impact assessments for high-impact deployments.", "mlops": "Surface classification record and applicable profiles on model registry cards; enforce classification gate in the pipeline; alert on use-case scope changes that require re-classification." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "EV-09 determines which profiles and controls apply to each model system — it is the applicability gate for the entire EV layer and for cross-domain obligations. LI-01 (Unique Model Identity and Content-Addressed Version Hash) is a prerequisite; classification records must be linked to LI-01 asset records.", "cross_domain": { "navigation": [ { "domain": "securitycontrols.ai", "control": "SC-ASSET-01", "rationale": "Asset classification in modelverifier.ai must align with security asset classification to ensure consistent risk treatment across domains." }, { "domain": "apeiris-control-core", "artifact": "classification-record-schema-v1", "rationale": "The signed classification record follows the shared core schema for cross-domain evidence linkage." } ] }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MAP-1.5", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MAP-1.5 (MAP function) provides that organizational risk tolerances are determined and documented. EV-09’s risk and applicability classification turns documented risk tolerances into a per-system determination of which controls and obligations apply.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "6.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 §6.1 requires risk assessment including determination of the significance of identified risks; formal classification operationalizes this.", "uncovered_portion": "ISO 42001 does not specify a multi-framework classification schema (EU AI Act + SR 26-2 + capability tier).", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act classification is a mandatory legal determination; this control operationalizes Articles 6, 51, and Annex III classification into a structured, documented process.", "uncovered_portion": "EU AI Act does not specify how to integrate EU classification with non-EU frameworks (SR 26-2, capability tiers).", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. VI", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. VI (Governance and Controls) describes applying model risk management with an intensity commensurate with a model's materiality and risk. EV-09's classification produces and maintains the documented risk basis that risk-commensurate governance depends on; the guidance does not prescribe a specific tiering scheme. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 tiering criteria predate generative AI capability categories and do not address GPAI systemic risk classification.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "GRC-10", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AICM risk classification controls align with the structured classification process.", "uncovered_portion": "AICM does not specify EU AI Act Article 6 / Annex III classification methodology.", "reviewed_on": "2026-06-26", "source_version": "1.1", "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "checkcompliance", "fit": "partial", "rationale": "Classifying each system under EU AI Act articles and SR 26-2 tiers to determine obligations is a check-compliance-with-laws-and-standards activity.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "profiles": [ "general-predictive-ml", "generative-ai", "hosted-api", "continuously-learning", "high-impact-decision", "us-regulated-banking", "eu-high-risk", "frontier-capability" ], "assurance_target": { "what": "Every model system has a signed classification record before evaluation begins, with EU AI Act classification, SR 26-2 tier (where applicable), capability tier, and applicable profiles documented.", "how": "Classification questionnaire + signed classification record + model registry gate + re-classification triggers.", "frequency": "At model system registration; on significant use-case, capability, or regulatory change." }, "canonical_id": "apeiris://model/controls/EV-09", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "validation_objective": "Every model system has a signed classification record produced before any evaluation work begins, containing a documented EU AI Act classification with provision-specific rationale referencing Articles 5, 6, 50, 51, and Annex III as applicable, an SR 26-2 model risk tier for in-scope institutions, a capability tier, and the full applicable Apeiris profiles list; the model registry gate prevents advancement to evaluation stage without this record; and re-classification is triggered on any significant change to use case, capability level, or applicable regulation.", "evidence_required": [ "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory — produced before any evaluation artifact is created", "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025" ], "machine_tests": [ "Attempt to advance a model system from registration to evaluation stage in the model registry without a signed classification record → assert model registry blocks advancement with error missing_classification_record", "Submit a model system with characteristics matching EU AI Act Annex III (e.g., biometric categorization or employment decision support) through the classification process → assert output includes eu_ai_act_classification=high-risk-annex-iii and eu-high-risk in applicable_profiles", "Trigger a use-case scope change on a classified model system → assert the model registry emits a re_classification_required notification linked to the change_event_id", "Verify signed classification record timestamp precedes the earliest evaluation artifact timestamp for the same model system identifier → assert classification completed before evaluation began" ], "human_review": [ "Review EU AI Act classification rationale for adequacy — verify that each relevant Annex III category was explicitly evaluated and that non-high-risk classifications include documented Annex III exclusion rationale with specific provision references", "Assess whether the classification covers the model system (artifact plus deployment context plus use case) rather than the model artifact in isolation, since the same artifact may receive different risk classifications across different deployment contexts", "Examine re-classification records to confirm that use-case scope changes — including informal expansions of the model's applied use cases after initial deployment — were captured and triggered re-classification review" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Classifying at the model artifact level rather than the model system level (artifact plus deployment context plus use case), causing the same artifact to be systematically under-classified when reused in higher-risk deployment contexts", "Self-classifying as minimal-risk or limited-risk without documented rationale referencing specific Annex III categories evaluated and excluded, treating absence of documentation as evidence of low-risk classification", "Treating classification as a one-time event at initial registration and not triggering re-classification when use-case scope expands informally to higher-risk applications after the initial deployment", "Conflating EU AI Act classification with SR 26-2 model risk tiering as if the frameworks measure the same risk dimensions, applying one framework's criteria to satisfy the other's classification requirement", "Using the 10^25 FLOPs GPAI systemic risk compute threshold as the sole classification criterion and omitting assessment of use-case risk and Annex III category applicability for non-GPAI systems" ], "update_status": "current", "layer_code": "EV" }, { "id": "EV-10", "layer": "EV", "plane": "both", "name": "Evaluation Result Provenance", "plain": "Every evaluation result is cryptographically linked to the exact model artifact version and evaluation suite version that produced it. Evaluation records are content-addressed, signed, stored in a tamper-evident log, and sufficient to reconstruct the chain of evidence from model artifact to deployment decision.", "threat": { "tags": [ "MR-VAL", "MR-PERFORMANCE" ], "desc": "Without content-addressed, signed evaluation records, results can be silently substituted, version provenance can be lost, and the chain of evidence from artifact to deployment decision is unverifiable. This makes post-incident forensics, regulatory audit, and meaningful governance impossible." }, "standard": [ "EU AI Act Art. 12 — Record-keeping for high-risk AI systems", "EU AI Act Art. 18 — Documentation obligations", "SR 26-2 Sec. V — Model Validation and Monitoring (validation documentation)", "ISO/IEC 42001:2023 §7.5 — Documented information", "NIST AI RMF MEASURE 2.1 — TEVV documentation" ], "sources": [ { "id": "eu_ai_act_2024", "authority": "European Parliament and Council", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "source_type": "regulation", "license": "public", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/EV-10 Evaluation Result Provenance control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Revised Guidance on Model Risk Management", "url": "https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm", "source_type": "supervisory-guidance", "license": "public", "artifact_hash": null, "supersedes": [ "SR 11-7", "SR 21-8" ], "status": "current", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/EV-10 Evaluation Result Provenance control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "url": "https://www.iso.org/standard/81230.html", "source_type": "certification-standard", "license": "commercial", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/EV-10 Evaluation Result Provenance control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://airc.nist.gov/RMF", "source_type": "voluntary-standard", "license": "public-domain", "artifact_hash": null, "supersedes": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/EV-10 Evaluation Result Provenance control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Every evaluation result artifact is content-addressed (SHA-256 hash), cryptographically signed with individually attributed key material, and recorded in an append-only tamper-evident log with inclusion proofs. The complete provenance chain — model artifact → evaluation suite → result → deployment decision — is machine-verifiable.", "steps": [ "Define the evaluation result artifact schema to include: model_artifact_hash, eval_suite_id, eval_suite_version, eval_suite_hash, run_timestamp, environment_fingerprint, per-dimension results, overall gate determination, and signer identity.", "After each evaluation run, compute the SHA-256 hash of the result artifact before signing; the hash is the content address that links the result to the specific artifact and suite versions.", "Sign the content-addressed result artifact using individually attributed key material (HSM-backed or equivalent); record signer identity and key identifier in the artifact.", "Submit the signed result artifact to an append-only, tamper-evident log (e.g., Sigstore Rekor, internal transparency log); record the log entry inclusion proof alongside the artifact.", "Verify the inclusion proof independently at the time of deployment gate evaluation; reject any manifest where inclusion proof verification fails.", "Retain signed result artifacts and inclusion proofs for the operational lifetime of the model plus the applicable regulatory retention period for each jurisdiction.", "Implement a provenance chain verification tool that, given a deployed model artifact hash, can traverse: model artifact → evaluation result(s) → deployment manifest → production deployment record — and verify signatures at each step.", "For EU-high-risk profile: ensure evaluation records satisfy EU AI Act Art. 12 record-keeping requirements and are available to national competent authorities on request." ], "anti_patterns": [ "Storing evaluation results in mutable storage where results can be overwritten without detection.", "Using the model's version label or name as the provenance link rather than the content hash; labels are mutable and do not guarantee artifact integrity.", "Signing evaluation records with shared or service-account credentials that prevent attribution to a named individual.", "Retaining only aggregate or summary results; full per-dimension results must be retained to support post-incident forensics.", "Treating the deployment gate manifest (EV-01) as sufficient provenance without also retaining the full evaluation result artifacts it references." ] }, "validation": { "design_check": [ "Evaluation result artifact schema includes all required provenance fields: model_artifact_hash, eval_suite_hash, run_timestamp, environment_fingerprint, per-dimension results, gate determination, signer identity. [ref:iso_42001_2023]", "Signing infrastructure uses individually attributed, non-repudiable key material; shared signing credentials are absent from the evaluation signing workflow. [ref:iso_42001_2023]", "Tamper-evident log is configured in append-only mode; log entries cannot be deleted or modified without detection. [ref:eu_ai_act_2024]", "Retention policy for signed result artifacts meets or exceeds the longer of: operational model lifetime or applicable regulatory minimum per jurisdiction. [ref:eu_ai_act_2024]" ], "runtime_test": [ "{'test': 'Given a deployed model artifact hash, traverse the provenance chain to the evaluation result and verify all signatures and inclusion proofs in the tamper-evident log.', 'ref': 'nist_rmf_v1'} [ref:nist_ai_rmf_1_0]", "{'test': 'Attempt to modify a stored evaluation result artifact and verify that the tamper-evident log detects the modification (inclusion proof verification fails).', 'unverified': True} [unverified]", "{'test': 'Verify that the deployment gate rejects a manifest where the referenced evaluation result artifact cannot be found in the tamper-evident log or where inclusion proof verification fails.', 'unverified': True} [unverified]", "{'test': 'Confirm that signer identity in evaluation result artifacts can be independently verified via PKI or equivalent directory lookup.', 'ref': 'sr262_2026'} [ref:sr262_2026]" ], "evidence": [ "model:signed-content-addressed-evaluation-res — Signed, content-addressed evaluation result artifacts for each evaluation run, stored in the tamper-evident log with inclusion proofs. [ref:iso_42001_2023]", "model:provenance-chain-traversal-records-demon — Provenance chain traversal records demonstrating machine-verifiable linkage from model artifact to deployment decision for each production model version. [ref:nist_ai_rmf_1_0]", "model:tamper-evident-log-integrity-verificatio — Tamper-evident log integrity verification records (inclusion proofs) for all evaluation result submissions. [unverified]", "model:retention-compliance-records-confirming — Retention compliance records confirming artifact availability for the required retention period. [ref:eu_ai_act_2024]", "model:for-eu-high-risk-profile-record-keeping — For eu-high-risk profile: record-keeping compliance assessment per EU AI Act Art. 12 and Art. 18. [ref:eu_ai_act_2024]" ] }, "lenses": { "engineering": "Implement content-addressing (SHA-256) as the standard provenance mechanism for all evaluation artifacts; integrate tamper-evident log submission and inclusion proof verification into the evaluation pipeline; build provenance chain traversal tooling as a first-class platform capability.", "evaluation": "Ensure evaluation result artifacts are complete (per-dimension results, not only aggregate); verify content-addressing is applied before signing; own the evaluation result schema and ensure it captures sufficient context for post-incident forensics.", "red_team": "Attempt to substitute a passing evaluation result for a failing one without detection; probe for provenance chain gaps where a model artifact hash is not linked to any evaluation result in the log; test whether mutable storage paths exist that bypass the tamper-evident log.", "grc": "Map record-keeping requirements to EU AI Act Art. 12 and SR 26-2 §III.B documentation requirements; track provenance chain completeness as a governance KRI; ensure evaluation records are accessible to regulators and auditors on request; include retention policy in model governance framework.", "mlops": "Surface provenance chain verification status on model registry cards; alert on inclusion proof verification failures; automate retention policy enforcement for signed evaluation artifacts; integrate provenance chain traversal into incident response runbooks." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "EV-10 completes the evaluation assurance chain: EV-01 (gate), EV-06 (reproducible design), EV-08 (independent validation), and EV-10 (result provenance) together provide a fully auditable, tamper-evident record of every deployment decision. CR-01 and CR-02 depend on EV-10 provenance for continuous assurance evidence linkage.", "cross_domain": { "navigation": [ { "domain": "apeiris-control-core", "artifact": "tamper-evident-log-schema-v1", "rationale": "The tamper-evident log entry format follows the shared core evidence artifact pattern for cross-domain provenance linkage." }, { "domain": "securitycontrols.ai", "control": "SC-CHAIN-CUSTODY", "rationale": "Evaluation result provenance is an instance of the broader chain-of-custody pattern from the security controls domain." } ] }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.1 (MEASURE function) provides that test sets, metrics, and details about the tools used during TEVV are documented. EV-10’s content-addressed, signed evaluation records preserve the test sets, metrics, and tool details this subcategory requires as tamper-evident documentation.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "7.5", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 §7.5 requires documented information to be controlled, retained, and protected; tamper-evident, signed evaluation records operationalize this for evaluation artifacts.", "uncovered_portion": "ISO 42001 does not specify content-addressing or tamper-evident log requirements.", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-12", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Art. 12 requires high-risk AI systems to automatically log events; Art. 18 requires technical documentation including testing results. Content-addressed, signed evaluation records directly satisfy these requirements.", "uncovered_portion": "EU AI Act does not specify tamper-evident log technology requirements.", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. V", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes validation documentation sufficient for independent review and supervisory examination; content-addressed, signed evaluation records strengthen the reliability of that documentation. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 does not specify tamper-evident storage or content-addressing for validation records.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "A&A-04", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CSA AICM A&A-04 (Requirements Compliance) requires evidence that requirements are met and auditable. EV-10’s content-addressed, signed evaluation records provide that compliance evidence in tamper-evident form.", "uncovered_portion": "AICM does not specify tamper-evident log technology or provenance chain traversal tooling.", "reviewed_on": "2026-06-26", "source_version": "1.1", "mapping_confidence": "medium", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" } ], "profiles": [ "general-predictive-ml", "generative-ai", "hosted-api", "continuously-learning", "high-impact-decision", "us-regulated-banking", "eu-high-risk", "frontier-capability" ], "assurance_target": { "what": "Every evaluation result is content-addressed, signed, stored in a tamper-evident log, and linkable to the model artifact and deployment decision via a machine-verifiable provenance chain.", "how": "SHA-256 content addressing + individual key signing + tamper-evident log submission + inclusion proof verification + provenance chain traversal tooling.", "frequency": "Per evaluation run; provenance chain verification at each deployment gate." }, "canonical_id": "apeiris://model/controls/EV-10", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-12", "mapping_fit": "partial", "notes": "Art-12 requires high-risk AI systems to be designed and developed with logging capabilities to enable automatic recording of events during operation.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "Every evaluation result artifact is SHA-256 content-addressed, cryptographically signed with individually attributed non-repudiable key material, submitted to an append-only tamper-evident log with a recorded inclusion proof, and linked to the model artifact hash and evaluation suite hash such that the complete chain from model artifact to deployment decision is machine-verifiable; the deployment gate rejects any manifest where inclusion proof verification fails.", "evidence_required": [ "signed_content_addressed_evaluation_result_artifacts for each run containing model_artifact_hash, eval_suite_id, eval_suite_version, eval_suite_hash, run_timestamp, environment_fingerprint, per_dimension_results, gate_determination, and signer_identity with key_identifier", "tamper_evident_log_inclusion_proofs for each signed evaluation result submission, with log_entry_id and inclusion_proof_bytes sufficient for independent verification", "provenance_chain_traversal_records demonstrating machine-verifiable linkage from model_artifact_hash through evaluation_result to deployment_manifest for each production model version", "signing_key_attribution_records mapping each signer_identity in evaluation artifacts to a named individual via PKI certificate or directory lookup, confirming no shared or service-account signing credentials were used", "retention_compliance_records confirming signed artifacts and inclusion proofs remain available for the required period covering the operational model lifetime plus the applicable regulatory minimum per jurisdiction" ], "machine_tests": [ "Given a deployed model artifact hash, traverse the provenance chain to the evaluation result in the tamper-evident log and verify all signatures and inclusion proofs → assert all_signatures_valid=true and all_inclusion_proofs_valid=true", "Modify the content of a stored evaluation result artifact and attempt inclusion proof re-verification against the tamper-evident log → assert verification fails with error content_hash_mismatch", "Attempt to advance a model to deployment where the evaluation manifest references an evaluation result artifact not present in the tamper-evident log → assert deployment gate blocks with error inclusion_proof_not_found", "Resolve signer_identity fields in evaluation result artifacts via PKI certificate lookup → assert all signers map to named person entities and no shared_credential or service_account flag is set" ], "human_review": [ "Review signing key management procedures to confirm that individually attributed, non-repudiable key material is required for all evaluation artifact signing and that service-account or shared credentials are structurally excluded from the evaluation signing workflow", "Assess the tamper-evident log configuration to verify it is genuinely append-only — log entries cannot be deleted or modified without detection even by administrators with elevated access — and that the log backend is independent of the evaluation pipeline that writes to it", "Examine retention policy documentation to confirm it covers the full period required by each applicable jurisdiction and that documented procedures exist for responding to regulator or auditor requests for historical evaluation records" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Storing evaluation results in mutable object storage where results can be silently overwritten without detection, enabling substitution of a passing result for a failing one after the fact", "Using the model version label or name as the provenance link rather than the SHA-256 content hash of the model artifact, since labels are mutable and do not guarantee artifact integrity across registry operations", "Signing evaluation result artifacts with shared service-account or team-level credentials that prevent attribution to a named individual, making non-repudiation structurally impossible", "Retaining only summary or aggregate evaluation results and discarding per-dimension results, making it impossible to reconstruct the specific findings that informed the deployment decision during post-incident forensics or regulatory audit", "Treating the signed deployment gate manifest (EV-01) as sufficient provenance evidence without retaining the full evaluation result artifacts it references, leaving a gap in the provenance chain if manifest references become stale or the artifacts are deleted" ], "update_status": "current", "layer_code": "EV" }, { "id": "OA-01", "layer": "OA", "plane": "control", "name": "Model Ownership Assignment", "plain": "Every AI model in production must have a named human owner with accountability for its outcomes, a team responsible for day-to-day operation, and an executive sponsor. These assignments must be recorded in the model register and reviewed whenever the model changes scope.", "threat": { "tags": [ "MR-DEV", "EU-AIA-AnnexIII" ], "desc": "Unowned models accumulate silent risk — no one monitors drift, responds to incidents, or gates scope changes. Absent clear accountability, high-impact failures have no clear owner for remediation or regulatory response." }, "standard": [ "Every production model MUST have a named owner who is a current employee with performance accountability for model outcomes.", "Owner assignment MUST be recorded in the model register within five business days of deployment.", "Owner register MUST include: owner name, team, executive sponsor, effective date, and review date.", "Ownership MUST be reassigned within ten business days of any owner departure or role change.", "The executive sponsor MUST be at director level or above for high-impact-decision models." ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "source_type": "voluntary-standard", "url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public domain", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/OA-01 Model Ownership Assignment control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "source_type": "certification-standard", "url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/OA-01 Model Ownership Assignment control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "authority": "European Union", "title": "EU Artificial Intelligence Act 2024/1689", "source_type": "regulation", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "public", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU Artificial Intelligence Act 2024/1689 requirements informing the apeiris://model/controls/OA-01 Model Ownership Assignment control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC / FDIC", "title": "SR 26-2: Revised Guidance on Model Risk Management", "source_type": "supervisory-guidance", "url": "https://www.federalreserve.gov/supervisionreg/srletters/sr2602.htm", "license": "public", "artifact_hash": null, "supersedes": [ "SR 11-7", "SR 21-8" ], "unverified": true, "status": "current", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/OA-01 Model Ownership Assignment control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Register-and-review: maintain a living model ownership register integrated with the model registry; trigger ownership review on scope change, owner departure, or annual cadence.", "steps": [ "Add owner, team, and executive-sponsor fields to the model registry schema.", "Create an onboarding checklist that blocks production deployment until ownership fields are populated.", "Integrate the model register with HR systems to detect owner departures and trigger reassignment workflows.", "Schedule annual ownership review as part of the model governance committee agenda.", "For high-impact models, require executive sponsor sign-off on the owner nomination." ], "anti_patterns": [ "Listing a team or committee as owner with no named individual — diffuse accountability is equivalent to no accountability.", "Ownership records that live only in a spreadsheet outside the model registry.", "Allowing ownership to lapse during organizational restructuring without a documented interim owner." ] }, "validation": { "design_check": [ "Model registry schema includes required ownership fields (owner, team, sponsor, effective_date, review_date). [ref:nist_ai_rmf_1_0]", "Deployment pipeline has an automated gate that blocks production push when ownership fields are null. [ref:eu_ai_act_2024]", "HR integration or manual process exists to trigger ownership reassignment on employee departure. [ref:iso_42001_2023]" ], "runtime_test": [ "Query model registry — every production model must return a non-null owner with a current employee ID. [unverified]", "Simulate owner departure; verify reassignment workflow triggers within ten business days SLA. [unverified]", "Verify annual review completion rate across all production models. [unverified]" ], "evidence": [ "model:model-ownership-register-extract-masked — Model ownership register extract (masked PII) showing 100% coverage of production models. [unverified]", "model:deployment-pipeline-gate-logs-showing-bl — Deployment pipeline gate logs showing blocked deployments for missing ownership. [unverified]", "model:governance-committee-minutes-showing-own — Governance committee minutes showing ownership review agenda items. [unverified]" ] }, "lenses": { "engineering": "Enforce ownership as a registry schema constraint and pipeline gate; integrate with HR event bus for departure detection.", "evaluation": "Verify that owner and sponsor are meaningful roles with relevant domain knowledge, not nominal assignments.", "red_team": "Test pipeline gate bypass paths; verify whether deployment automation can circumvent ownership requirements.", "grc": "Ownership register is the primary evidence artifact for regulator inquiries about AI accountability structure.", "mlops": "Integrate ownership fields into model registry; surface ownership staleness in model health dashboards." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers human accountability assignment. Does not cover the substantive quality of oversight — see OA-02 for meaningful human oversight requirements.", "profiles": [ { "profile": "general-predictive-ml", "applicability": "required", "tailoring": "Standard ownership register sufficient." }, { "profile": "generative-ai", "applicability": "required", "tailoring": "Owner must include generative output risk in accountability scope." }, { "profile": "hosted-api", "applicability": "required", "tailoring": "Vendor models require an internal owner responsible for vendor oversight." }, { "profile": "continuously-learning", "applicability": "required", "tailoring": "Owner must acknowledge drift monitoring as an ongoing accountability." }, { "profile": "high-impact-decision", "applicability": "required", "tailoring": "Executive sponsor must be at director level or above; review cadence reduced to 6 months." }, { "profile": "us-regulated-banking", "applicability": "required", "tailoring": "SR 26-2 requires documented model owner in validation documentation." }, { "profile": "eu-high-risk", "applicability": "required", "tailoring": "EU AI Act Art-16 imposes quality management, technical documentation, transparency, and human oversight obligations on high-risk AI system providers; a named accountable owner is a prerequisite for discharging these obligations. Non-EU providers must also designate an authorized representative under Art. 22." }, { "profile": "frontier-capability", "applicability": "required", "tailoring": "Owner must be senior enough to invoke capability containment protocols." } ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-2.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-2.1 (GOVERN function) provides that roles, responsibilities, and lines of communication for AI risk management are documented and clear. OA-01’s named-owner register documents the ownership and accountability lines this subcategory requires for every production model.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "5.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 Clause 5.3 requires assignment of roles, responsibilities, and authorities.", "uncovered_portion": "Competence requirements covered separately in OA-03.", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-17", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Art-17 requires providers of high-risk AI systems to operate a quality management system that includes an accountability framework setting out the responsibilities of management and other staff (Art. 17(1)(m)); Art. 16(c) obliges providers to have such a QMS in place. OA-01's named-owner register implements the accountability component.", "uncovered_portion": "Conformity assessment obligations covered in OA-05.", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. VI", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. VI (Governance and Controls) describes clearly assigned roles and responsibilities across model owners, developers, validators, and users. OA-01's named-owner register operationalizes the ownership component of that expectation. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "Validation independence requirements covered in EV layer.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "GRC-06", "fit": "direct", "direction": "control-supports-requirement", "rationale": "OA-01 mandates that every production AI model is assigned a named human owner with performance accountability, a team responsible for day-to-day operation, and an executive sponsor at director level or above for high-impact models — all recorded in the model register and reviewed at defined intervals. This directly satisfies GOV-05's requirement for AI system ownership and accountability role assignment by establishing the named, role-bound accountability structure that regulators and auditors require to answer who is accountable for a model's outcomes.", "source_locator": { "section": "Governance and Organizational Accountability" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "aiprogram", "fit": "partial", "rationale": "Assigning named owners, responsible teams, and executive sponsors for every production model is part of running an AI program under governance.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "assurance_target": { "accountability": "named-individual", "coverage": "all-production-models", "review_cadence": "annual-or-on-change" }, "canonical_id": "apeiris://model/controls/OA-01", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-17", "mapping_fit": "partial", "notes": "Art-16(c) requires providers of high-risk AI systems to have a quality management system complying with Art-17, which includes an accountability framework defining management and staff responsibilities (Art. 17(1)(m)).", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "Every AI model in the production model registry must have a non-null named human owner who is a current employee, a responsible team, and an executive sponsor at director level or above for high-impact models, all recorded within five business days of deployment. No production model may exist without a current ownership record, and ownership must be reassigned within ten business days of any owner departure.", "evidence_required": [ "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date — showing 100% coverage of production models with non-null values", "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period" ], "machine_tests": [ "Query model registry for all production models → assert zero records return with null owner_name, owner_employee_id, team, executive_sponsor, or review_date", "Attempt to promote a test model with ownership fields set to null through the deployment pipeline → assert promotion is blocked with error code MISSING_OWNER", "Cross-reference owner_employee_id values against current HR active employee feed → assert zero stale or departed employee IDs in active ownership records", "For all models tagged high-impact-decision, verify executive_sponsor role level field → assert all values are director-level or above" ], "human_review": [ "Review a sample of ownership records for quality: confirm named owners have genuine domain accountability (not nominal assignments), that the executive sponsor role is appropriate, and that review dates reflect actual review activity rather than auto-populated defaults", "Assess the HR departure integration process for completeness — confirm the notification-to-reassignment workflow is documented, tested, and covers all HR departure types including long-term leave", "Verify that governance committee minutes reflect substantive ownership review, not just a checkbox acknowledgment of the agenda item" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Listing a team name or committee as the model owner with no named individual — diffuse accountability is equivalent to no accountability during incident response or regulatory inquiry", "Populating ownership fields with a departed employee's name without triggering reassignment because the HR system integration was not implemented", "Allowing the model development team to self-assign ownership without an independent accountability check or governance committee awareness", "Maintaining ownership records only in a spreadsheet outside the model registry, creating a single point of failure and no audit trail", "Setting review_date to a fixed future date without a mechanism to enforce that review actually occurs, allowing records to become perpetually stale" ], "update_status": "current", "layer_code": "OA" }, { "id": "OA-02", "layer": "OA", "plane": "control", "name": "Meaningful Human Oversight for High-Stakes Decisions", "plain": "When an AI model produces outputs that affect significant decisions about people's lives, liberty, finances, or safety, a human must be in a position to understand, evaluate, and override that output before it takes effect. A human being physically present is not sufficient — they must have the time, information, authority, competence, and genuine ability to override.", "threat": { "tags": [ "EU-AIA-AnnexIII", "MR-MONITORING", "MR-PERFORMANCE" ], "desc": "Automation bias causes human reviewers to rubber-stamp AI outputs without genuine review. Speed pressure, information asymmetry, lack of authority, or inadequate training can all render nominally human-in-the-loop processes functionally automated. Regulatory frameworks (EU AI Act Art-14) mandate substantive, not ceremonial, oversight." }, "obligations": [ { "id": "eu-ai-act-art-14", "regulation": "EU AI Act", "article": "Article 14", "title": "Human Oversight", "requirement": "High-risk AI systems shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use.", "applicability": "eu-high-risk profile", "deadline": "2027-12-02", "enforcement_body": "National market surveillance authority", "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "legal_status": "enacted", "jurisdiction": [ "eu" ], "provision": "Article 14", "effective_from": "2027-12-02" }, { "id": "eu-ai-act-art-14-sub3", "regulation": "EU AI Act", "article": "Article 14(3)", "title": "Human Oversight — Operator Obligations", "requirement": "Operators of high-risk AI systems shall assign the oversight to natural persons who have the necessary competence, training and authority to carry out that role.", "applicability": "eu-high-risk profile — deployer obligation", "deadline": "2027-12-02", "enforcement_body": "National market surveillance authority", "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "legal_status": "enacted", "jurisdiction": [ "eu" ], "provision": "Article 14(3)", "effective_from": "2027-12-02" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-14", "mapping_fit": "partial", "notes": "Art-14 requires high-risk AI systems to allow natural persons to oversee their operation effectively, including the ability to override, interrupt or stop operation.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "standard": [ "For high-impact-decision and eu-high-risk models, the human reviewer MUST have: (1) sufficient time to review the output before it takes effect, (2) access to the input data and model reasoning used to produce the output, (3) organizational authority to override the model output without penalty, (4) domain competence adequate to evaluate the output, and (5) a genuine override mechanism that is technically effective.", "Override rates MUST be monitored; a sustained rate near zero MAY indicate automation bias and MUST trigger a governance review.", "Human reviewers MUST receive initial training and annual recertification covering automation bias, model limitations, and override procedures.", "The oversight mechanism design MUST be documented and reviewed by the AI governance committee annually.", "Threshold-based automation (where model confidence above a threshold bypasses human review) MUST be explicitly approved by the governance committee with documented risk rationale." ], "sources": [ { "id": "eu_ai_act_2024", "authority": "European Union", "title": "EU Artificial Intelligence Act 2024/1689", "source_type": "regulation", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "public", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU Artificial Intelligence Act 2024/1689 requirements informing the apeiris://model/controls/OA-02 Meaningful Human Oversight for High-Stakes Decisions control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "source_type": "voluntary-standard", "url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public domain", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/OA-02 Meaningful Human Oversight for High-Stakes Decisions control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "source_type": "certification-standard", "url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/OA-02 Meaningful Human Oversight for High-Stakes Decisions control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Five-factor oversight design: for each high-stakes use case, document and validate all five factors (time, information, authority, competence, override mechanism) before deployment.", "steps": [ "Map each model use case against the high-stakes threshold — document the decision type, affected population, and consequence severity.", "For qualifying use cases, conduct a five-factor oversight design review: (1) specify minimum review time per decision, (2) design the information display for reviewers, (3) confirm reviewer authority chain, (4) define competence requirements and training program, (5) build and test the override workflow.", "Instrument override rate tracking per reviewer and per model; set governance review thresholds.", "Establish reviewer training and annual recertification program with attendance records.", "Conduct quarterly automation bias simulation exercises — present reviewers with seeded incorrect outputs and measure detection rate." ], "anti_patterns": [ "Declaring human-in-the-loop because a human can technically click a button in under three seconds with no context.", "Penalizing or discouraging overrides through performance metrics that reward throughput over accuracy.", "Treating high model confidence as a substitute for human review.", "Using the same person as both model developer and human oversight reviewer for the same decision.", "Designing the review interface to make the override action harder to locate than the approve action." ] }, "validation": { "design_check": [ "Five-factor oversight design document exists for each high-stakes use case. [ref:eu_ai_act_2024]", "Override mechanism is technically implemented and tested — confirm override propagates correctly through downstream systems. [ref:eu_ai_act_2024]", "Reviewer competence requirements and training curriculum are documented. [ref:eu_ai_act_2024]", "Information display design provides model inputs, confidence, and reasoning — not only the final output. [ref:nist_ai_rmf_1_0]" ], "runtime_test": [ "Inject seeded incorrect model outputs into the review queue; measure reviewer detection rate. [unverified]", "Monitor override rate by reviewer, model, and decision type; alert when rate drops below governance-defined floor for 30 consecutive days. [unverified]", "Time-in-review audit: confirm reviewers are spending sufficient time per decision against documented minimum. [unverified]", "Verify reviewer authority: confirm that override decisions propagate without requiring secondary approval that negates reviewer authority. [unverified]" ], "evidence": [ "model:five-factor-oversight-design-documents-f — Five-factor oversight design documents for each high-stakes use case. [unverified]", "model:override-rate-time-series-for-past-12-mo — Override rate time series for past 12 months, by model and reviewer cohort. [unverified]", "model:reviewer-training-completion-records-and — Reviewer training completion records and competence assessment results. [ref:eu_ai_act_2024]", "model:automation-bias-simulation-exercise-resu — Automation bias simulation exercise results and trend analysis. [unverified]" ] }, "lenses": { "engineering": "Instrument every model output that enters a human review queue with timing data, reviewer ID, and override flag. Build override mechanism as a first-class workflow action, not an edge-case UI element.", "evaluation": "Evaluate oversight effectiveness as part of model validation — not only model accuracy. Seeded-output detection rate is a key evaluation metric.", "red_team": "Probe for automation bias paths: can a reviewer approve an output without seeing the inputs? Is there time pressure that incentivizes approval? Are override paths technically obstructed?", "grc": "EU AI Act Art-14 compliance requires documented oversight design per use case. Oversight records are primary evidence in conformity assessment and supervisory examination.", "mlops": "Surface override rate alongside model performance metrics in operational dashboards. Implement alerts for override rate anomalies." }, "monitoring_schema": { "metrics": [ { "name": "override_rate", "description": "Fraction of model outputs that a human reviewer overrides", "unit": "ratio", "alert_threshold": { "floor": 0.001, "note": "sustained near-zero triggers governance review" }, "window_context": "30-day rolling", "sampling_rate": "per decision event", "metric_id": "override_rate", "metric_type": "performance", "measure": "event-rate", "population": "all-production-decisions", "comparison": { "operator": "less-than", "value": 0.001, "window": "30d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "review_time_per_decision_seconds", "description": "Time in seconds a reviewer spends before approving or overriding", "unit": "seconds", "alert_threshold": { "floor_seconds": 5, "note": "sub-threshold review time flags automation bias risk" }, "window_context": "per session", "sampling_rate": "per decision event", "metric_id": "review_time_per_decision_seconds", "metric_type": "performance", "measure": "elapsed-seconds", "population": "all-production-decisions", "comparison": { "operator": "less-than", "value": 5, "window": "rolling-30d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "seeded_error_detection_rate", "description": "Fraction of intentionally seeded incorrect outputs detected in quarterly exercises", "unit": "ratio", "alert_threshold": { "floor": 0.7, "note": "below 70% detection triggers remedial training" }, "window_context": "quarterly exercise", "sampling_rate": "quarterly", "metric_id": "seeded_error_detection_rate", "metric_type": "performance", "measure": "event-rate", "population": "all-production-decisions", "comparison": { "operator": "less-than", "value": 0.7, "window": "90d", "evaluation_mode": "batch" }, "severity": "medium" } ], "window_context": "rolling-30d", "sampling_rate": "100%" }, "capability_risk": { "capability_level": "none", "autonomy": "supervised", "access_mode": "internal", "irreversibility": "partially-reversible", "deployment_scale": "enterprise", "affected_party_impact": "moderate", "external_reach": false, "data_sensitivity": "internal", "notes": "primary concern: automation-bias | secondary concern: authority-gap | consequence if failed: high-impact decisions taken without genuine human judgment; regulatory non-compliance under EU AI Act Art-14 | risk amplifiers: time_pressure, high_throughput, high_model_confidence_scores, reviewer_performance_incentives_tied_to_volume" }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Profile-conditional: required for high-impact-decision and eu-high-risk profiles. For general-predictive-ml where decisions are low-stakes, standard monitoring may be substituted with documented justification.", "profiles": [ { "profile": "general-predictive-ml", "applicability": "conditional", "tailoring": "Apply only where outputs affect individuals in material ways. Document applicability determination." }, { "profile": "generative-ai", "applicability": "conditional", "tailoring": "Required for generative AI outputs used in high-stakes decisions or communications. Not required for internal drafting assistance." }, { "profile": "hosted-api", "applicability": "conditional", "tailoring": "Deployer must implement oversight mechanism even when using hosted model — provider technical capability does not substitute for deployer oversight obligation." }, { "profile": "continuously-learning", "applicability": "required", "tailoring": "Oversight review must include assessment of whether model drift has changed the information presented to reviewers." }, { "profile": "high-impact-decision", "applicability": "required", "tailoring": "All five factors must be verified and documented. Override rate monitoring mandatory." }, { "profile": "us-regulated-banking", "applicability": "required", "tailoring": "SR 26-2 requires model risk management to include human review of model outputs in credit and risk decisions." }, { "profile": "eu-high-risk", "applicability": "required", "tailoring": "EU AI Act Art-14 is directly applicable. Conformity assessment must include oversight mechanism review." }, { "profile": "frontier-capability", "applicability": "required", "tailoring": "Frontier models require enhanced oversight with senior reviewer competence and direct escalation authority." } ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art-14", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Art-14 mandates human oversight design for high-risk AI. The five-factor framework operationalizes Art-14(3) requirements.", "uncovered_portion": "Art-14(4) self-monitoring provisions require additional instrumentation addressed in CR layer.", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_rmf", "requirement_id": "GOVERN-3.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-3.2 (GOVERN function) provides that policies define and differentiate roles and responsibilities for human-AI configurations and oversight. OA-02’s five-factor oversight adequacy framework defines and verifies the human-oversight roles this subcategory calls for.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "6.1.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 requires controls for human oversight of AI systems in high-risk contexts.", "uncovered_portion": "None significant for this control.", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "sr262", "requirement_id": "Sec. IV", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. IV (Model Development and Model Use) describes sound model use, including understanding model limitations and applying informed judgment to model output. OA-02's oversight adequacy framework operationalizes informed human judgment for high-stakes uses; the guidance does not itself mandate human review of individual outputs. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "None significant.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "GRC-15", "fit": "direct", "direction": "control-supports-requirement", "rationale": "OA-02 operationalizes genuine human oversight through a five-factor adequacy framework that verifies reviewers have sufficient time, access to model reasoning, authority to override without penalty, domain competence, and a technically effective override mechanism — all of which HO-01 requires for consequential AI decisions. The control additionally mandates override rate monitoring and quarterly automation bias simulation exercises, producing measurable evidence that HO-01 uses to assess whether oversight is substantive rather than nominal.", "source_locator": { "section": "Human Oversight and Control" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "owasp_aitg", "requirement_id": "AITG-APP-13", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "AITG-APP-13 (Testing for Over-Reliance on AI) probes whether humans defer to model output without adequate scrutiny. OA-02's override-rate monitoring and five-factor oversight adequacy assessment produce exactly the automation-bias evidence this test evaluates.", "source_locator": { "test_id": "AITG-APP-13", "test_name": "Testing for Over-Reliance on AI" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "oversight", "fit": "direct", "rationale": "Requiring a competent human with authority and an effective override before high-stakes AI output takes effect is the maintain-human-oversight control.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0020", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"For every high-impact-decision or eu-high-risk model, a human reviewer must have…\" enacts ATLAS mitigation AML.M0020 Generative AI Guardrails; OpenCRE crosswalks this control’s OWASP AI Exchange concept (oversight) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0029", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"For every high-impact-decision or eu-high-risk model, a human reviewer must have…\" enacts ATLAS mitigation AML.M0029 Human In-the-Loop for AI Agent Actions; OpenCRE crosswalks this control’s OWASP AI Exchange concept (oversight) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0030", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"For every high-impact-decision or eu-high-risk model, a human reviewer must have…\" enacts ATLAS mitigation AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data; OpenCRE crosswalks this control’s OWASP AI Exchange concept (oversight) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "assurance_target": { "oversight_design": "five-factor-verified", "override_mechanism": "technically-effective", "reviewer_competence": "documented-and-certified" }, "canonical_id": "apeiris://model/controls/OA-02", "validation_objective": "For every high-impact-decision or eu-high-risk model, a human reviewer must have documented access to model inputs, confidence scores, and reasoning; organizational authority to override without penalty; domain competence verified through training records; and a technically effective override mechanism before any AI output takes effect. Override rates must be monitored and a rate near zero for 30 consecutive days must automatically trigger a governance review.", "evidence_required": [ "five_factor_oversight_design_document per high-stakes use case, signed by the AI governance committee, covering: review time allocation, information display design, override authority documentation, competence requirements, and override mechanism technical specification", "override_rate_time_series report for the past 12 months broken down by model, decision type, and reviewer cohort — with governance-defined floor thresholds annotated", "reviewer_training_completion_record including initial onboarding completion date, annual recertification dates, competence assessment scores, and automation-bias module completion", "override_mechanism_test_log confirming that override actions propagate correctly through downstream systems without requiring secondary approval" ], "machine_tests": [ "Inject seeded incorrect model outputs into the review queue across a statistically significant sample → assert reviewer detection rate meets governance-defined minimum threshold", "Measure time-in-review per decision for a rolling 30-day window → assert no reviewer cohort has average review time below the documented minimum threshold per decision type", "Simulate an override action in the review interface → assert downstream systems reflect the human decision within the documented propagation SLA without requiring additional approval steps", "Monitor override rate for each model over a 30-day rolling window → assert alert fires when rate drops below governance-defined floor for 30 consecutive days" ], "human_review": [ "Review the review interface design for each high-stakes use case: confirm that the override action is at least as prominent as the approve action, that model inputs and reasoning are surfaced — not only the final output — and that confidence scores are displayed in a format reviewers can meaningfully interpret", "Assess reviewer performance records for signs of automation bias: elevated throughput, near-zero override rates, or minimal time-in-review that suggests rubber-stamping rather than genuine evaluation", "Verify that reviewer authority is genuine: confirm no performance metric penalizes overrides and no secondary approval is required after a reviewer overrides a model output" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Declaring human-in-the-loop because a reviewer can technically click an approve button in under three seconds with no context, no model inputs displayed, and no time allocated for review", "Designing performance metrics that reward reviewer throughput (decisions per hour) without any accuracy or override-rate floor — creating financial incentives for rubber-stamping", "Treating high model confidence score as a valid substitute for human review, bypassing oversight for outputs above a confidence threshold without explicit governance committee approval", "Using the same individual as both model developer and human oversight reviewer for the same decision type, eliminating independent review", "Implementing a technical override button that requires a secondary manager approval, effectively negating the reviewer's authority and deterring overrides" ], "update_status": "current", "layer_code": "OA" }, { "id": "OA-03", "layer": "OA", "plane": "control", "name": "AI Model Governance Committee", "plain": "The organization must establish a cross-functional body with defined authority to approve high-risk model deployments, review incidents, set risk appetite, and adjudicate governance disputes. The committee must have a formal charter, clear decision rights, a quorum requirement, and a regular meeting cadence.", "threat": { "tags": [ "MR-DEV", "EU-AIA-AnnexIII" ], "desc": "Without a chartered body with authority over AI deployment decisions, risk appetite, and incident response, consequential decisions default to individual teams with narrow visibility. This produces inconsistent risk treatment, uncoordinated incident response, and regulatory accountability gaps." }, "standard": [ "An AI Model Governance Committee (AIGC) MUST be formally chartered with documented membership, decision rights, quorum requirements, and meeting cadence.", "The AIGC MUST include representation from: AI/ML engineering, model validation or evaluation, legal or compliance, risk management, and at least one business line representative.", "The AIGC MUST meet at minimum quarterly, with provision for emergency sessions convened within 48 hours for material incidents.", "The AIGC MUST have exclusive authority to: (1) approve deployment of high-risk models, (2) approve risk appetite thresholds for AI, (3) approve autonomy tier assignments at Tier 3 and above, (4) authorize exceptions to AI governance policy.", "AIGC minutes MUST be retained for a minimum of seven years and made available to internal audit and regulators on request.", "A quorum of at least 60% of voting members MUST be present for binding decisions." ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "source_type": "voluntary-standard", "url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public domain", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/OA-03 AI Model Governance Committee control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "source_type": "certification-standard", "url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/OA-03 AI Model Governance Committee control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "authority": "European Union", "title": "EU Artificial Intelligence Act 2024/1689", "source_type": "regulation", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "public", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU Artificial Intelligence Act 2024/1689 requirements informing the apeiris://model/controls/OA-03 AI Model Governance Committee control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC / FDIC", "title": "SR 26-2: Revised Guidance on Model Risk Management", "source_type": "supervisory-guidance", "url": "https://www.federalreserve.gov/supervisionreg/srletters/sr2602.htm", "license": "public", "artifact_hash": null, "supersedes": [ "SR 11-7", "SR 21-8" ], "unverified": true, "status": "current", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/OA-03 AI Model Governance Committee control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Charter-first governance: approve a formal committee charter at executive level before operationalizing any AI governance processes.", "steps": [ "Draft and approve a committee charter covering: purpose, membership, roles, decision rights, quorum, meeting cadence, and escalation paths.", "Appoint a committee chair with sufficient organizational authority to enforce decisions across business units.", "Establish a model risk register as the committee's primary working document — all production models above the materiality threshold appear on it.", "Define a decision rights matrix: distinguish what the committee decides versus what it reviews versus what it is only notified of.", "Set up a secure meeting management system for minutes, votes, and document retention with defined access controls." ], "anti_patterns": [ "Committee membership that excludes legal, compliance, or risk — resulting in blind spots on regulatory and ethical issues.", "Advisory-only committee with no binding authority — governance becomes theater.", "Meeting cadence that is too infrequent to respond to a rapidly changing model portfolio.", "Quorum rules so loose that a two-person majority can approve high-stakes model deployments." ] }, "validation": { "design_check": [ "Committee charter exists, is approved at executive level, and specifies all required elements. [ref:iso_42001_2023]", "Charter decision rights matrix includes explicit authority for high-risk model approvals. [ref:iso_42001_2023]", "Membership includes all required functional areas. [ref:eu_ai_act_2024]" ], "runtime_test": [ "Verify meeting minutes exist for all scheduled quarterly sessions in the past 12 months. [unverified]", "Select a sample of high-risk model deployments from the past year; verify AIGC approval records exist for each. [unverified]", "Confirm minutes are retained in a document management system with access controls and audit trail. [unverified]" ], "evidence": [ "model:committee-charter-current-version-with — Committee charter (current version, with approval signature and date). [unverified]", "model:meeting-minutes-for-preceding-12-month-p — Meeting minutes for preceding 12-month period. [unverified]", "model:decision-log-showing-high-risk-model-app — Decision log showing high-risk model approvals and risk appetite decisions. [unverified]", "model:membership-list-with-functional-affiliat — Membership list with functional affiliations. [unverified]" ] }, "lenses": { "engineering": "Integrate AIGC approval as a required gate in the model deployment pipeline for models above the governance threshold.", "evaluation": "Model evaluation reports should be tabled at AIGC before deployment approval. The committee reviews evaluation independence and adequacy.", "red_team": "Test whether deployment automation can bypass AIGC approval; verify that threshold criteria cannot be manipulated to avoid committee review.", "grc": "The AIGC is the primary governance body for AI risk. Its charter and minutes are key artifacts for regulatory examination and ISO 42001 certification audits.", "mlops": "Surface AIGC approval status in the model registry; block production promotion for models requiring committee approval until status is confirmed." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers governance structure and authority. Incident-specific escalation authority chain is covered in OA-07. Model validation independence is covered in EV layer.", "profiles": [ { "profile": "general-predictive-ml", "applicability": "required", "tailoring": "Lightweight governance committee acceptable if model portfolio is small and low-risk." }, { "profile": "generative-ai", "applicability": "required", "tailoring": "Committee must include content policy and safety expertise for generative AI models." }, { "profile": "hosted-api", "applicability": "required", "tailoring": "Committee must review vendor change notifications and approve responses to material vendor model changes." }, { "profile": "high-impact-decision", "applicability": "required", "tailoring": "Committee approval required for initial deployment and any scope change." }, { "profile": "us-regulated-banking", "applicability": "required", "tailoring": "SR 26-2 requires a model risk management governance structure with senior leadership involvement." }, { "profile": "eu-high-risk", "applicability": "required", "tailoring": "Committee must include compliance officer with EU AI Act knowledge." }, { "profile": "frontier-capability", "applicability": "required", "tailoring": "Committee must include safety and capability assessment experts; board-level reporting required." } ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-2.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-2.3 (GOVERN function) provides that executive leadership takes responsibility for decisions about risks associated with AI development and deployment. OA-03’s chartered governance committee gives executive leadership a standing forum in which those risk decisions are taken and recorded.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "5.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 Clause 5.3 (Organizational roles, responsibilities and authorities) requires top management to assign and communicate relevant roles and authorities. OA-03’s chartered committee documents those authorities for AI model decisions.", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "sr262", "requirement_id": "Sec. VI", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. VI (Governance and Controls) describes board and senior management responsibility for the model risk management framework. OA-03's chartered governance committee provides the standing senior forum that this oversight expectation contemplates. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 validation independence requirements addressed in EV layer.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-17", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art-17 requires providers of high-risk AI to implement quality management systems including governance structures.", "uncovered_portion": "Technical documentation requirements addressed in LI layer.", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "aicm", "requirement_id": "GRC-10", "fit": "direct", "direction": "control-supports-requirement", "rationale": "OA-03 establishes a formally chartered cross-functional AI Model Governance Committee with documented membership spanning engineering, validation, legal, compliance, risk, and business lines — giving collective authority to approve high-risk deployments, set risk appetite, review incidents, and adjudicate threshold decisions. This directly implements GOV-06 by creating the institutional body and decision-making structure that a cross-functional AI governance review board requires, including quorum requirements, binding decision rights, and mandatory seven-year record retention.", "source_locator": { "section": "Governance and Organizational Accountability" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "aiprogram", "fit": "supporting", "rationale": "A chartered governance committee with approval authority and risk-appetite ownership is the governance backbone of an AI program under GRC.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://model/controls/OA-03", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-9", "mapping_fit": "partial", "notes": "Art-9 requires providers to establish, implement, document and maintain a risk management system throughout the lifecycle of a high-risk AI system.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "The organization must have a formally chartered AI Model Governance Committee with documented membership covering all required functional areas, exclusive approval authority over high-risk model deployments and risk appetite thresholds, and auditable meeting minutes retained for seven years. The committee must have met at minimum quarterly in each of the preceding four quarters, with quorum achieved for all binding decisions.", "evidence_required": [ "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line" ], "machine_tests": [ "Query document management system for committee meeting minutes → assert records exist for all four scheduled quarterly sessions in the preceding 12 months with quorum attestation", "Cross-reference high-risk model registry entries with AIGC approval records → assert every high-risk model deployed in the past 12 months has a corresponding AIGC approval decision record with date and voting outcome", "Verify document retention: query records management system for AIGC minutes older than one year → assert all are retained and accessible with access control audit trail" ], "human_review": [ "Review a sample of AIGC meeting minutes for substantive decision-making: confirm that high-risk model approvals include documented risk rationale, not just a vote count, and that dissenting views are captured when present", "Assess the committee membership roster against the functional representation requirements: verify that legal/compliance and risk management members have sufficient seniority and relevant expertise to meaningfully challenge model deployment proposals", "Evaluate the AIGC charter's decision rights matrix to confirm that the committee has genuine binding authority — not advisory-only status — and that exceptions or overrides by executive management are documented" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Establishing an AIGC with advisory-only authority that can only recommend decisions — governance without binding authority becomes theater when business pressure favors deployment", "Committee membership that excludes legal, compliance, or independent risk functions, creating blind spots on regulatory exposure and creating approval capture by engineering or product teams", "Quorum rules so permissive that a small subset of engineering and product members can approve high-stakes model deployments without risk or compliance representation", "Infrequent meeting cadence (annual or semi-annual) that is structurally unable to respond to a rapidly evolving model portfolio or regulatory landscape within required timeframes" ], "update_status": "current", "layer_code": "OA" }, { "id": "OA-04", "layer": "OA", "plane": "control", "name": "Delegated Autonomy Tier Governance", "plain": "AI models must be assigned to an autonomy tier that defines the scope of actions the model may take without human approval. The Security Verifier domain owns the tier taxonomy definition and technical enforcement. The Model Assurance domain consumes tier assignments to calibrate evaluation requirements and evidence standards — it does not duplicate tier enforcement. This control governs the governance process for requesting, approving, and reviewing tier assignments.", "threat": { "tags": [ "MR-DEV", "MR-MONITORING" ], "desc": "Unconstrained autonomy scope expansion — models gradually acquiring the ability to take irreversible actions beyond their original charter — creates compounding risk. Without formal tier governance, autonomy scope creep occurs through infrastructure convenience rather than deliberate risk decision." }, "standard": [ "Every AI model or agent MUST have an explicit autonomy tier assignment documented in the model register.", "Tier assignment MUST be approved by the AI Governance Committee for Tier 3 and above.", "The Security Verifier domain owns the autonomy tier taxonomy and enforcement controls — this control governs the governance process for requesting and approving tier assignments only. Model Assurance does not duplicate tier enforcement.", "Model Assurance evaluation requirements MUST be calibrated to the assigned tier — higher tiers require more rigorous pre-deployment evaluation and monitoring evidence.", "Tier escalation (upgrading to a higher autonomy tier) MUST go through formal change control and AIGC approval.", "Tier assignment MUST be reviewed when the model's action scope, data access, or operational context changes materially." ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "source_type": "voluntary-standard", "url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public domain", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/OA-04 Delegated Autonomy Tier Governance control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "source_type": "certification-standard", "url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/OA-04 Delegated Autonomy Tier Governance control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Consumer-producer split: Security Verifier domain defines and enforces the tier taxonomy and technical controls; Model Assurance domain reads tier from the model register and uses it as an input to evaluation scoping — never as a control surface to duplicate.", "steps": [ "Confirm the autonomy tier taxonomy is defined and maintained in the Security Verifier domain (see cross_domain reference).", "Add autonomy_tier field to the model registry schema, populated from the Security Verifier's tier registry.", "Define an evaluation requirement lookup table: for each tier level, specify the minimum evaluation evidence required (e.g., Tier 1 = standard benchmark; Tier 3 = red team + containment test).", "Integrate tier escalation requests into the AIGC approval workflow (OA-03).", "Implement monitoring alert for tier-action scope mismatches — where a model's observed action surface exceeds its assigned tier.", "Review all tier assignments annually as part of the model register review." ], "anti_patterns": [ "Duplicating tier enforcement in Model Assurance — creating two competing tier control surfaces with potential for inconsistency.", "Allowing development teams to self-assign autonomy tiers without governance approval.", "Using tier solely as a label without calibrating evaluation requirements to tier level.", "Treating tier escalation as a routine model update rather than a governance decision requiring AIGC approval." ] }, "validation": { "design_check": [ "Model registry schema includes autonomy_tier field with reference to Security Verifier tier taxonomy. [ref:nist_ai_rmf_1_0]", "Evaluation requirement lookup table maps each tier to specific evidence requirements. [ref:iso_42001_2023]", "AIGC decision rights matrix includes tier escalation approval authority. [ref:iso_42001_2023]" ], "runtime_test": [ "Query model registry — every production model must have a non-null tier assignment. [unverified]", "Select a sample of Tier 3+ models; verify AIGC approval records exist for their tier assignments. [unverified]", "Check for tier-action scope mismatches: verify models are not observed taking actions outside their tier-permitted scope. [unverified]" ], "evidence": [ "model:model-register-extract-showing-tier-assi — Model register extract showing tier assignments for all production models. [unverified]", "model:aigc-approval-records-for-tier-3-tier-a — AIGC approval records for Tier 3+ tier assignments. [unverified]", "model:tier-escalation-change-control-records — Tier escalation change control records. [unverified]", "model:tier-assignment-model-id-version-jso — tier_assignment_{model_id}_{version}.json artifacts consumed from Security Verifier domain. [unverified]" ] }, "lenses": { "engineering": "Tier assignment is read from the model registry by evaluation tooling to determine required test suite configuration. Derive tier-based logic from registry — never hardcode.", "evaluation": "Tier level drives evaluation scope — evaluation team uses tier assignment to select benchmark suites, red team requirements, and evidence standards.", "red_team": "Test whether a model can be induced to take actions outside its assigned tier scope; probe for tier escalation paths not gated by governance.", "grc": "Tier assignment records document the organization's deliberate risk decisions about AI autonomy scope. These are primary governance artifacts for regulatory inquiry.", "mlops": "Instrument action logs to detect tier boundary violations; alert when a model's observed action surface exceeds its tier permission set." }, "cross_domain": { "domain": "securitycontrols.ai", "layer": "IA", "relationship": "Security Verifier domain owns the autonomy tier taxonomy, technical enforcement controls, and tier registry. Model Assurance consumes tier assignments as a read-only input — this is a one-way dependency. Tier changes in Security Verifier domain trigger evaluation re-scoping in Model Assurance.", "navigation": "See securitycontrols.ai IA layer for Identity and Access controls governing agent action scope enforcement.", "evidence_artifact_pattern": "tier_assignment_{model_id}_{version}.json — produced by Security Verifier domain, consumed by Model Assurance evaluation pipeline as an input to evaluation scoping", "feeds": [ "apeiris://agentic/controls/AA-03" ] }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "This control governs the governance process for tier assignment and review. Technical enforcement of tier boundaries is the Security Verifier's exclusive responsibility. Evaluation requirements calibrated to tier are detailed in the EV layer.", "profiles": [ { "profile": "general-predictive-ml", "applicability": "required", "tailoring": "Most predictive ML models will be Tier 1 or 2; standard evaluation evidence sufficient." }, { "profile": "generative-ai", "applicability": "required", "tailoring": "Generative AI with tool use or action capability requires explicit tier assignment; default is not lowest tier without documented assessment." }, { "profile": "hosted-api", "applicability": "required", "tailoring": "Vendor-hosted models must still receive a tier assignment based on the deployer's use case and integration scope." }, { "profile": "continuously-learning", "applicability": "required", "tailoring": "Tier may need review if continuous learning expands the model's effective action scope over time." }, { "profile": "high-impact-decision", "applicability": "required", "tailoring": "Tier 3+ models in high-impact-decision contexts require AIGC approval and enhanced evaluation evidence." }, { "profile": "frontier-capability", "applicability": "required", "tailoring": "Frontier models default to highest evaluation tier pending explicit downgrade with documented rationale approved by AIGC." } ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-1.3 (GOVERN function) provides that processes determine the needed level of risk management activities based on the organization’s risk tolerance. OA-04’s autonomy tier assignments calibrate the level of evaluation and oversight to the risk each deployment can tolerate, operationalizing risk-proportionate governance.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "6.1.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 requires risk classification and proportionate controls.", "uncovered_portion": "None significant for the governance aspect of tier management.", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "GRC-02", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "OA-04 implements the governance process for assigning AI models to autonomy tiers that define the permissible scope of actions without human approval, with AIGC approval required for Tier 3 and above and formal change control for any tier escalation. By calibrating evaluation requirements to tier level and integrating tier assignment into the model registry, this control provides the classification and boundary definition component of RM-01's AI risk tier classification and autonomy scope management requirement.", "uncovered_portion": "RM-01 covers the full risk classification and treatment lifecycle including ongoing risk monitoring and treatment adequacy assessment; OA-04 addresses only the model-side tier classification and boundary definition governance — enforcement of tier boundaries and authorization of specific actions within tiers is owned by the Security Verifier domain.", "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "owasp_aitg", "requirement_id": "AITG-APP-06", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "AITG-APP-06 (Testing for Agentic Behavior Limits) verifies that agentic systems respect defined behavioral limits. OA-04's autonomy tier assignments define the limits that this test then exercises at runtime.", "source_locator": { "test_id": "AITG-APP-06", "test_name": "Testing for Agentic Behavior Limits" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "leastmodelprivilege", "fit": "supporting", "rationale": "Assigning autonomy tiers that bound the actions a model may take without human approval enforces least privilege on the model.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0028", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every AI model or agent in the production registry must have an explicitly documented…\" enacts ATLAS mitigation AML.M0028 AI Agent Tools Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0026", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every AI model or agent in the production registry must have an explicitly documented…\" enacts ATLAS mitigation AML.M0026 Privileged AI Agent Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0027", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every AI model or agent in the production registry must have an explicitly documented…\" enacts ATLAS mitigation AML.M0027 Single-User AI Agent Permissions Configuration; OpenCRE crosswalks this control’s OWASP AI Exchange concept (leastmodelprivilege) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "assurance_target": { "tier_coverage": "all-production-models", "escalation_governance": "aigc-approved-tier3-plus", "evaluation_calibration": "tier-lookup-table-enforced", "boundary": "Model Assurance consumes tier; Security Verifier enforces tier" }, "canonical_id": "apeiris://model/controls/OA-04", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "validation_objective": "Every AI model or agent in the production registry must have an explicitly documented autonomy tier assignment sourced from the Security Verifier domain taxonomy, with AIGC approval records present for all Tier 3 and above assignments, and evaluation evidence requirements calibrated to the assigned tier. No model may take actions outside its tier-permitted scope without triggering an escalation event.", "evidence_required": [ "model_register_extract showing autonomy_tier field populated for every production model, with reference to the Security Verifier tier taxonomy version in use", "aigc_approval_records for all Tier 3 and above tier assignments, including the date, voting outcome, and risk rationale", "tier_assignment_artifact (tier_assignment_{model_id}_{version}.json) consumed from Security Verifier domain for each model, confirming cross-domain provenance", "evaluation_requirement_lookup_table mapping each tier level to specific evidence requirements, with version date and approval signature from model governance committee" ], "machine_tests": [ "Query production model registry → assert zero records have null or missing autonomy_tier field", "For all models with tier field set to Tier 3 or above, cross-reference against AIGC approval records → assert every such model has a corresponding AIGC approval record with date prior to or equal to deployment date", "Parse runtime action logs for all production models and cross-reference against tier-permitted action scope definitions → assert zero instances of models executing actions outside their tier-permitted scope without an escalation record" ], "human_review": [ "Review a sample of Tier 3 and above tier assignment AIGC decisions: confirm that risk rationale reflects a genuine assessment of action scope, data access, and operational context — not a formulaic approval", "Assess the evaluation requirement lookup table for tier-proportionality: verify that higher tiers require meaningfully more rigorous pre-deployment evaluation evidence and monitoring cadence", "Verify that tier escalation events (upgrades to higher tiers) went through formal change control with AIGC approval, and that no development team performed self-escalation outside the change process" ], "blocking_effect": "blocks-deployment", "normative_status": "voluntary-standard", "anti_patterns": [ "Development teams self-assigning autonomy tiers without AIGC approval, circumventing the governance process for Tier 3 and above designations", "Treating tier assignment as a one-time label that never requires review when the model's action scope, data access, or operational context materially changes", "Duplicating tier enforcement controls in Model Assurance rather than consuming tier assignments from the Security Verifier domain, creating two inconsistent control surfaces", "Using tier level solely as a documentation label without calibrating evaluation evidence requirements and monitoring intensity to the assigned tier level" ], "update_status": "current", "layer_code": "OA" }, { "id": "OA-05", "layer": "OA", "plane": "control", "name": "Regulatory and Legal Review Sign-Off", "plain": "Before deploying AI models in regulated use cases, compliance counsel must review and sign off on regulatory applicability, legal risk, and required documentation. For EU high-risk AI systems, a conformity assessment must be completed before market placement. Sign-off is a hard deployment gate — not a post-hoc review.", "threat": { "tags": [ "EU-AIA-AnnexIII", "MR-DEV" ], "desc": "Deploying regulated AI without legal review creates regulatory liability, enforcement risk, and reputational harm. EU AI Act non-compliance with high-risk obligations carries fines up to EUR 15 million or 3% of global annual turnover (Art. 99(4)); prohibited-practice violations carry up to EUR 35 million or 7% (Art. 99(3)). Banking regulators can impose remediation requirements and model use restrictions." }, "obligations": [ { "id": "eu-ai-act-art-43", "regulation": "EU AI Act", "article": "Article 43", "title": "Conformity Assessment", "requirement": "Providers of high-risk AI systems listed in Annex III shall carry out a conformity assessment prior to placing the system on the market or putting it into service.", "applicability": "eu-high-risk profile", "deadline": "2027-12-02", "enforcement_body": "National market surveillance authority", "note": "For most Annex III categories (except biometric and critical infrastructure), providers may use self-assessment against Annex IV technical documentation requirements.", "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "legal_status": "enacted", "jurisdiction": [ "eu" ], "provision": "Article 43", "effective_from": "2027-12-02" }, { "id": "eu-ai-act-art-17", "regulation": "EU AI Act", "article": "Article 17", "title": "Quality Management System", "requirement": "Providers of high-risk AI systems shall implement a quality management system including procedures for regulatory compliance review.", "applicability": "eu-high-risk profile", "deadline": "2027-12-02", "enforcement_body": "National market surveillance authority", "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "legal_status": "enacted", "jurisdiction": [ "eu" ], "provision": "Article 17", "effective_from": "2027-12-02" }, { "id": "eu-ai-act-art-47", "regulation": "EU AI Act", "article": "Article 47", "title": "EU Declaration of Conformity", "requirement": "Providers shall draw up an EU declaration of conformity for each high-risk AI system and keep it at the disposal of the national competent authorities for 10 years after the system has been placed on the market or put into service.", "applicability": "eu-high-risk profile", "deadline": "2027-12-02", "enforcement_body": "National market surveillance authority", "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "legal_status": "enacted", "jurisdiction": [ "eu" ], "provision": "Article 47", "effective_from": "2027-12-02" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-9", "mapping_fit": "partial", "notes": "Art-9 requires providers to establish, implement, document and maintain a risk management system throughout the lifecycle of a high-risk AI system.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "standard": [ "Compliance counsel MUST review and sign off on all regulated-use AI model deployments before production promotion.", "The sign-off MUST document: applicable regulations identified, assessment of compliance posture, required documentation status, and any residual legal risks accepted.", "For EU high-risk AI (Annex III), a conformity assessment MUST be completed and an EU Declaration of Conformity issued before deployment.", "For US-regulated banking models, SR 26-2 validation documentation MUST be reviewed and approved by the model risk function before deployment.", "Legal sign-off MUST be re-obtained when the regulatory landscape materially changes (new regulation enacted, enforcement action in the sector, or material change in model use case).", "Sign-off records MUST be retained for the model's operational life plus seven years." ], "sources": [ { "id": "eu_ai_act_2024", "authority": "European Union", "title": "EU Artificial Intelligence Act 2024/1689", "source_type": "regulation", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "public", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU Artificial Intelligence Act 2024/1689 requirements informing the apeiris://model/controls/OA-05 Regulatory and Legal Review Sign-Off control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC / FDIC", "title": "SR 26-2: Revised Guidance on Model Risk Management", "source_type": "supervisory-guidance", "url": "https://www.federalreserve.gov/supervisionreg/srletters/sr2602.htm", "license": "public", "artifact_hash": null, "supersedes": [ "SR 11-7", "SR 21-8" ], "unverified": true, "status": "current", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/OA-05 Regulatory and Legal Review Sign-Off control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "source_type": "certification-standard", "url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/OA-05 Regulatory and Legal Review Sign-Off control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Deployment gate with legal sign-off: regulatory review is embedded in the model deployment checklist as a required step, not an optional advisory.", "steps": [ "Maintain a regulatory applicability matrix mapping model use cases to applicable regulatory frameworks.", "Create a legal review request workflow triggered by the model deployment pipeline for models above the materiality threshold.", "Develop a standardized regulatory review template covering: use case description, data inputs, output types, affected population, applicable regulations, and compliance posture assessment.", "For EU high-risk models, designate an EU AI Act compliance officer responsible for coordinating conformity assessments.", "Establish a legal sign-off registry integrated with the model registry; block production deployment until sign-off artifact is recorded.", "Set up a regulatory monitoring process to detect changes in applicable law and trigger re-review." ], "anti_patterns": [ "Treating legal review as a formality to be obtained after deployment — post-hoc reviews do not satisfy EU AI Act conformity assessment requirements.", "Using legal sign-off from a prior deployment as a blanket approval for expanded scope without re-review.", "Allowing business units to self-certify regulatory applicability without compliance counsel involvement.", "Conflating OCC 2026-13 (non-binding supervisory guidance) with binding regulatory requirements." ] }, "validation": { "design_check": [ "Legal sign-off is a required gate in the model deployment pipeline for models above the materiality threshold. [ref:eu_ai_act_2024]", "Regulatory applicability matrix exists and is maintained by the compliance function. [ref:eu_ai_act_2024]", "EU AI Act conformity assessment process is documented for eu-high-risk profile models. [ref:eu_ai_act_2024]" ], "runtime_test": [ "Select a sample of regulated-use model deployments from the past year; verify legal sign-off records exist for each. [unverified]", "Verify EU high-risk models have a current EU Declaration of Conformity in the model record. [ref:eu_ai_act_2024]", "Verify sign-off records are retained in the document management system with the required retention period. [unverified]" ], "evidence": [ "model:legal-sign-off-records-for-all-regulated — Legal sign-off records for all regulated-use models deployed in the past 12 months. [unverified]", "model:eu-declaration-of-conformity-for-eu-high — EU Declaration of Conformity for eu-high-risk models. [ref:eu_ai_act_2024]", "model:sr-26-2-validation-reports-for-banking-m — SR 26-2 validation reports for banking models. [ref:sr262_2026]", "model:regulatory-applicability-matrix-current — Regulatory applicability matrix (current version). [unverified]" ] }, "lenses": { "engineering": "Pipeline gate must require a sign-off artifact ID from the legal registry before promoting a regulated-use model to production.", "evaluation": "Evaluation documentation must be structured to support regulatory review — evaluation reports feed the legal sign-off process.", "red_team": "Test whether deployment automation can bypass legal sign-off gates for models meeting the materiality threshold.", "grc": "Legal sign-off is primary compliance evidence. Maintain a regulatory calendar to track review expiry and trigger re-reviews on schedule.", "mlops": "Surface legal sign-off status in the model registry dashboard; flag models with expired or missing sign-off for compliance review." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers regulatory and legal review at the deployment gate. Ongoing regulatory compliance monitoring is covered in CR layer. Technical documentation requirements for EU AI Act Annex IV are covered in LI layer.", "profiles": [ { "profile": "general-predictive-ml", "applicability": "conditional", "tailoring": "Required only where use case falls within a regulated domain (credit, employment, healthcare, insurance)." }, { "profile": "generative-ai", "applicability": "conditional", "tailoring": "Required for generative AI used in regulated contexts (legal advice, medical information, financial recommendations)." }, { "profile": "hosted-api", "applicability": "required", "tailoring": "Deployer retains regulatory obligation even when using a hosted model; sign-off covers the deployer's use case." }, { "profile": "high-impact-decision", "applicability": "required", "tailoring": "Legal review must cover adverse action notice requirements (FCRA, ECOA, GDPR Art-22 where applicable)." }, { "profile": "us-regulated-banking", "applicability": "required", "tailoring": "SR 26-2 validation report and model risk function approval required before deployment." }, { "profile": "eu-high-risk", "applicability": "required", "tailoring": "Conformity assessment and Declaration of Conformity required before market placement. Self-assessment permissible for most Annex III categories." }, { "profile": "frontier-capability", "applicability": "required", "tailoring": "Legal review must include assessment of RSP and FSF compliance obligations and potential regulatory notification requirements." } ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art-43", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Art-43 requires conformity assessment; Art-47 requires EU Declaration of Conformity for high-risk AI before market placement.", "uncovered_portion": "Post-market monitoring obligations addressed in CR layer.", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. VI", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. VI (Governance and Controls) describes documented policies and internal review and approval processes governing model use. For US-regulated banking models, OA-05's pre-deployment legal and model-risk sign-off aligns with those governance expectations. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "Ongoing monitoring and annual validation requirements addressed in CR layer.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "4.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 Clause 4.2 (Understanding the needs and expectations of interested parties) requires determining the legal and regulatory requirements relevant to the AI management system. OA-05’s pre-deployment legal review identifies and documents those requirements per deployment.", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_rmf", "requirement_id": "GOVERN-1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-1.1 (GOVERN function) provides that legal and regulatory requirements involving AI are understood, managed, and documented. OA-05’s pre-deployment legal review identifies the applicable regulations and documents the compliance posture, operationalizing this subcategory for regulated model deployments.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "GRC-07", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CSA AICM GRC-07 (Regulatory Mapping) requires mapping applicable legal and regulatory requirements to the systems they govern. OA-05’s counsel sign-off documents exactly that mapping — applicable regulations identified and compliance posture assessed — per model deployment.", "source_locator": { "control_id": "GRC-07" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "checkcompliance", "fit": "supporting", "rationale": "Mandatory legal/compliance sign-off and conformity assessment before deploying regulated models is a check-compliance-with-laws-and-regulations gate.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://model/controls/OA-05", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "validation_objective": "Every AI model deployed in a regulated use case must have a documented legal sign-off record from compliance counsel before production promotion, specifying applicable regulations, compliance posture assessment, documentation status, and accepted residual legal risks. EU high-risk AI systems must have a completed conformity assessment and a current EU Declaration of Conformity. Sign-off records must be retained for the model's operational life plus seven years.", "evidence_required": [ "legal_signoff_record for each regulated-use model deployment, including: counsel name, date, applicable regulations identified, compliance posture assessment, documentation status, and accepted residual legal risks — pre-dating the production deployment timestamp", "eu_declaration_of_conformity for each model classified as eu-high-risk, with conformity assessment completion date, notified body reference if applicable, and model version scope", "sr_26_2_validation_report for each US-regulated banking model, reviewed and approved by the independent model risk function prior to deployment", "regulatory_applicability_matrix current version maintained by the compliance function, showing which regulations apply to each model classification" ], "machine_tests": [ "Cross-reference all production model deployments tagged regulated-use against legal sign-off records → assert zero regulated-use models have a deployment timestamp prior to a corresponding signed legal sign-off record", "For all models tagged eu-high-risk, query the document management system for EU Declaration of Conformity → assert all current records are present, version-matched to deployed model, and not expired", "Verify document retention: query legal sign-off records for models decommissioned in the past seven years → assert all records are retained and accessible" ], "human_review": [ "Review a sample of legal sign-off records for substantive assessment quality: confirm that the compliance posture assessment addresses the specific use case and model functionality, not just a generic regulatory reference, and that residual legal risks are explicitly accepted by an authorized individual", "Assess the regulatory applicability matrix for completeness and currency: verify that recent regulatory changes (new EU AI Act guidance, SR 26-2 amendments, sector-specific AI rules) are reflected in the matrix", "Evaluate whether any sign-off records were obtained post-deployment or retroactively applied, which would indicate the control is not functioning as a genuine pre-deployment gate" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Treating legal review as a post-deployment formality or obtaining sign-off after production promotion — post-hoc review does not satisfy EU AI Act conformity assessment or SR 26-2 pre-deployment validation requirements", "Using legal sign-off from a prior model version or deployment as implicit blanket approval for an expanded scope or material change without re-review", "Allowing business units to self-certify regulatory applicability and determine whether legal review is required, bypassing the compliance function's role in the applicability matrix", "Conflating non-binding supervisory guidance with binding regulatory requirements, or treating voluntary frameworks as substitutes for mandatory conformity assessments", "Maintaining sign-off records outside the document management system with no retention policy enforcement, creating records destruction risk during organizational restructuring" ], "update_status": "current", "layer_code": "OA" }, { "id": "OA-06", "layer": "OA", "plane": "control", "name": "Third-Party Model and Vendor Risk Oversight", "plain": "When the organization uses AI models or components from third parties — including foundation model providers, model-as-a-service APIs, and fine-tuned model vendors — it must apply proportionate vendor governance: risk-based due diligence before first use, contract terms covering model change notification and audit rights, and ongoing performance and risk monitoring.", "threat": { "tags": [ "LLM03:2025", "AML.T0018", "MR-DEV" ], "desc": "Third-party models introduce supply chain risk: model updates can silently change behavior, vendor security incidents can compromise inference confidentiality, and vendor-side training data contamination (AML.T0018 Supply Chain Compromise) can propagate to production. Lack of contractual protections leaves organizations unable to respond effectively to vendor-side failures." }, "standard": [ "All third-party AI models and components used in production MUST be inventoried in the model register with vendor, model version, intake date, and use cases.", "Due diligence MUST be conducted before first use of any third-party model, covering: security practices, data governance, model documentation, and track record.", "Vendor contracts MUST include: (1) model change notification with minimum 30-day advance notice for material changes, (2) right to audit or acceptance of third-party audit, (3) SLA for incident notification (maximum 24 hours for security incidents), (4) data residency and confidentiality terms.", "Vendor risk MUST be reviewed annually and upon material vendor incidents or model version changes.", "For high-risk use cases, vendor evaluation MUST include assessment of the vendor's own AI governance and safety practices.", "Organizations MUST maintain the ability to substitute a critical third-party model — single-vendor lock-in for critical AI functions is a governance risk requiring documented mitigation." ], "sources": [ { "id": "owasp_llm10_2025", "authority": "OWASP", "title": "OWASP Top 10 for LLM Applications 2025", "source_type": "supervisory-guidance", "url": "https://owasp.org/www-project-top-10-for-large-language-model-applications/", "license": "CC BY-SA 4.0", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "voluntary-standard", "version": "2025", "published_on": "2024-11-17", "retrieved_on": "2026-06-26", "source_id": "owasp_llm10", "relationship": "implementation_pattern", "rationale": "Establishes OWASP Top 10 for LLM Applications 2025 requirements informing the apeiris://model/controls/OA-06 Third-Party Model and Vendor Risk Oversight control.", "reviewed_on": "2026-07-01" }, { "id": "mitre_atlas_v5_6_0", "authority": "MITRE", "title": "MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems", "source_type": "voluntary-standard", "url": "https://atlas.mitre.org/", "license": "Apache 2.0", "artifact_hash": null, "unverified": true, "status": "current", "retrieved_on": "2026-06-26", "normative_force": "best-practice", "version": "5.6.0", "published_on": "2026-05-04", "source_id": "mitre_atlas", "relationship": "informative_reference", "rationale": "Establishes MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems requirements informing the apeiris://model/controls/OA-06 Third-Party Model and Vendor Risk Oversight control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "source_type": "voluntary-standard", "url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public domain", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/OA-06 Third-Party Model and Vendor Risk Oversight control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC / FDIC", "title": "SR 26-2: Revised Guidance on Model Risk Management", "source_type": "supervisory-guidance", "url": "https://www.federalreserve.gov/supervisionreg/srletters/sr2602.htm", "license": "public", "artifact_hash": null, "supersedes": [ "SR 11-7", "SR 21-8" ], "unverified": true, "status": "current", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/OA-06 Third-Party Model and Vendor Risk Oversight control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Vendor risk lifecycle: pre-contract due diligence → contract terms → version pinning → ongoing monitoring → periodic re-assessment → exit planning.", "steps": [ "Create a third-party AI model inventory as part of the model register — include vendor, model name, version pinned, use cases, and risk tier.", "Develop a vendor due diligence questionnaire covering: training data governance, security practices, model change management, incident history, and safety evaluations.", "Establish a contract review checklist for AI vendor agreements covering the required clauses (notification, audit, SLA, confidentiality).", "Set up vendor model version monitoring — alert when a vendor releases a new model version that affects production integrations.", "Conduct annual vendor risk reviews including performance data, incident history, and governance practice reassessment.", "For critical vendors, document a substitution plan and test it annually." ], "anti_patterns": [ "Relying solely on vendor self-attestation for security and governance practices without independent verification.", "Accepting vendor contracts with no model change notification obligation — silent updates can break production behavior.", "Treating foundation model APIs as commodity infrastructure without AI-specific risk assessment.", "No version pinning — allowing vendor to silently update model version without triggering internal review." ] }, "validation": { "design_check": [ "Third-party AI model inventory exists as part of or linked to the model register. [ref:sr262_2026]", "Vendor contract template includes required AI-specific clauses (notification, audit, SLA, confidentiality). [ref:sr262_2026]", "Due diligence questionnaire covers AI-specific governance and safety practices. [ref:sr262_2026]" ], "runtime_test": [ "Select a sample of active third-party model vendors; verify annual risk review records exist. [unverified]", "Verify version pinning is implemented for production API integrations — confirm model version in use matches registry record. [unverified]", "Simulate vendor incident notification: verify internal escalation path and response SLA. [unverified]" ], "evidence": [ "model:third-party-ai-model-inventory-current — Third-party AI model inventory (current). [unverified]", "model:vendor-due-diligence-records-for-all-act — Vendor due diligence records for all active AI model vendors. [unverified]", "model:contract-review-checklist-completion-rec — Contract review checklist completion records for vendor agreements. [unverified]", "model:annual-vendor-risk-review-reports — Annual vendor risk review reports. [unverified]" ] }, "lenses": { "engineering": "Implement version pinning for all vendor model API integrations; instrument vendor model response logging to detect silent behavioral changes.", "evaluation": "Vendor model evaluation must include testing against the organization's specific use cases — vendor benchmarks are not sufficient for use-case-specific validation.", "red_team": "Test vendor model behavior for prompt injection vulnerabilities (AML.T0051), data exfiltration via inference (AML.T0024), and supply chain manipulation risks (AML.T0018).", "grc": "Vendor governance is a third-party risk management function. AI vendor risk must be integrated into the enterprise TPRM program with AI-specific criteria.", "mlops": "Monitor vendor model version in production; trigger review workflow when vendor announces deprecation or update. Track vendor SLA compliance against contractual terms." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers governance and contractual aspects of third-party model risk. Technical supply chain security controls (artifact verification, SBOM, model card review) are covered in TG layer.", "profiles": [ { "profile": "general-predictive-ml", "applicability": "conditional", "tailoring": "Required when using third-party model components or APIs." }, { "profile": "generative-ai", "applicability": "required", "tailoring": "Most generative AI deployments rely on foundation model vendors — vendor governance is critical." }, { "profile": "hosted-api", "applicability": "required", "tailoring": "This profile is the vendor risk scenario — all controls apply at maximum rigor." }, { "profile": "continuously-learning", "applicability": "required", "tailoring": "Vendor-side continuous learning may change model behavior without notice — contractual notification requirements are essential." }, { "profile": "high-impact-decision", "applicability": "required", "tailoring": "Vendor must provide sufficient transparency into model behavior to support meaningful human oversight (OA-02)." }, { "profile": "us-regulated-banking", "applicability": "required", "tailoring": "SR 26-2 vendor model provisions require validation documentation from vendor or internal re-validation." }, { "profile": "eu-high-risk", "applicability": "required", "tailoring": "EU AI Act places obligations on deployers even when using third-party AI — contract must address these obligations." }, { "profile": "frontier-capability", "applicability": "required", "tailoring": "Frontier model vendor safety practices (RSP, FSF) must be reviewed as part of vendor due diligence." } ], "frameworks": [ { "framework": "llm10", "requirement_id": "LLM03:2025", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OWASP LLM03:2025 (Supply Chain) addresses third-party model risk through dependency management and vendor governance; OA-06's vendor due diligence, contract requirements, and substitution planning mitigate this risk category.", "uncovered_portion": "Technical supply chain artifact verification addressed in TG layer.", "reviewed_on": "2026-06-26", "source_version": "2025", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "mitre", "requirement_id": "AML.T0010", "fit": "partial", "direction": "control-mitigates-risk", "rationale": "MITRE ATLAS AML.T0010 (AI Supply Chain Compromise) covers compromise of models, data, and tooling obtained from third parties. OA-06's vendor due diligence, version pinning, and behavioral monitoring mitigate this technique for externally sourced models.", "uncovered_portion": "Technical artifact integrity checks addressed in TG layer.", "reviewed_on": "2026-06-26", "source_version": "v2026.06", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "sr262", "requirement_id": "Sec. VII", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. VII (Vendor and Other Third-Party Products) describes due diligence, ongoing monitoring, and documentation expectations for vendor and third-party models. OA-06's vendor inventory, due diligence, and contract requirements operationalize that section. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "None significant.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_rmf", "requirement_id": "GOVERN-6.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-6.1 (GOVERN function) provides that policies address AI risks associated with third-party entities, including IP-infringement risks. OA-06’s vendor due diligence, contract requirements, and substitution planning implement the third-party risk policies this subcategory requires.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.10.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.10.3 (Suppliers) requires processes for managing AI-related risks from suppliers. OA-06’s vendor due diligence, contract requirements, and annual review implement supplier risk management for third-party models.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "supplychainmanage", "fit": "direct", "rationale": "Vendor due diligence, version pinning, and ongoing risk monitoring of third-party models and APIs is managing the model/component AI supply chain.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0023", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every third-party AI model or component used in production must appear in the model…\" enacts ATLAS mitigation AML.M0023 AI Bill of Materials; complements the control’s existing technique mapping AML.T0010 (defends_against) — OpenCRE crosswalks the AI Exchange concept (supplychainmanage) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0014", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every third-party AI model or component used in production must appear in the model…\" enacts ATLAS mitigation AML.M0014 Verify AI Artifacts; complements the control’s existing technique mapping AML.T0010 (defends_against) — OpenCRE crosswalks the AI Exchange concept (supplychainmanage) to this ATLAS mitigation (a control).", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.05", "fit": "supporting", "rationale": "Control \"Every third-party AI model or component used in production must appear in the model…\" defends against NIST AI 100-2 attack class NISTAML.05 \"Supply Chain Attacks\"; OpenCRE crosswalks this control’s OWASP AI Exchange concept (supplychainmanage) to this NIST class. (Anchor captures the attack taxonomy, so we cite the threat class as defends_against, not the NIST mitigation named by OpenCRE.)", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against", "mapping_confidence": "medium", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "canonical_id": "apeiris://model/controls/OA-06", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "validation_objective": "Every third-party AI model or component used in production must appear in the model inventory with vendor, model version, intake date, and use case documented. All active third-party vendors must have completed due diligence records and current annual risk reviews. Production integrations must implement version pinning verified against the registry, and vendor contracts must include model change notification, audit rights, and incident notification SLA clauses.", "evidence_required": [ "third_party_ai_model_inventory current snapshot with fields: vendor, model_name, model_version, api_version, intake_date, use_cases, production_status — covering all active third-party AI components", "vendor_due_diligence_record for each active vendor, including security practices assessment, data governance review, model documentation review, and governance/safety practice assessment for high-risk use cases", "contract_clause_compliance_checklist for each vendor agreement, confirming presence of: 30-day material change notification, audit rights or third-party audit acceptance, 24-hour security incident SLA, and data residency/confidentiality terms", "annual_vendor_risk_review_report for each active vendor covering the preceding 12 months, with risk rating, material incidents noted, and recommended actions" ], "machine_tests": [ "Query production API integration configurations for all third-party model endpoints → assert every integration has version pinning enabled and the pinned version matches the version recorded in the third-party AI model inventory", "Cross-reference third-party AI model inventory against active production systems → assert zero production AI systems are using third-party models not present in the inventory", "For all active vendors, check annual risk review records → assert every vendor has a review record dated within the preceding 12 months" ], "human_review": [ "Review a sample of vendor due diligence records for high-risk use case vendors: confirm that the AI governance and safety practice assessment goes beyond vendor self-attestation and includes independent verification evidence such as third-party audits, certifications, or structured questionnaire responses", "Assess vendor contracts for the required AI-specific clauses: verify that the 30-day material change notification obligation is specific enough to cover model architecture changes, training data updates, and behavioral modifications — not just versioning", "Evaluate the organization's documented mitigation strategy for single-vendor lock-in in critical AI functions: confirm a credible substitution plan or alternative exists for each vendor dependency classified as critical" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Relying solely on vendor self-attestation via completed questionnaires for security and governance assurance without any independent verification, third-party audit review, or certification validation", "Accepting vendor contracts with no model change notification clause, allowing vendors to silently update model architecture, training data, or behavioral characteristics without triggering internal impact assessment", "Treating foundation model APIs as commodity infrastructure (equivalent to a database or cloud storage service) and bypassing AI-specific risk assessment because the model is provided as a managed service", "Deploying integrations without version pinning, allowing vendors to silently update the model version in use without triggering the internal due diligence and impact assessment process" ], "update_status": "current", "layer_code": "OA" }, { "id": "OA-07", "layer": "OA", "plane": "control", "name": "Incident Escalation Authority Chain", "plain": "When an AI model incident occurs, there must be a named escalation chain with defined decision rights at each level, time bounds for escalation steps, and a clear threshold at which the board or equivalent governing body must be notified. Ambiguity in who can authorize containment, public disclosure, or regulatory notification is itself an incident risk.", "threat": { "tags": [ "MR-MONITORING", "EU-AIA-AnnexIII" ], "desc": "During an active incident, decision latency caused by unclear authority chains causes harm to accumulate. Absent defined escalation authority, teams default to waiting for consensus that never arrives, or taking uncoordinated actions that compound the incident. Regulatory notification obligations have time bounds that cannot be met without pre-defined escalation paths." }, "standard": [ "A documented incident escalation authority chain MUST exist for AI model incidents, covering: (1) Level 1 — operational response (model owner plus on-call team), (2) Level 2 — model governance committee engagement, (3) Level 3 — executive decision-making authority, (4) Level 4 — board or equivalent notification.", "Decision rights at each level MUST be explicitly documented: what can each level authorize without escalating further?", "Time bounds MUST be specified for each escalation step: the maximum time at Level 1 before Level 2 must be notified.", "Board-level notification threshold MUST be defined: events that automatically require board notification (e.g., regulatory notice issued, significant customer harm, public safety risk).", "The escalation chain MUST be tested at minimum annually through tabletop exercises.", "Regulatory notification obligations and their time bounds MUST be mapped to escalation levels (e.g., EU AI Act Art-73 serious incident reporting: 15 days for serious incidents generally, no more than 10 days in the event of a death, and no more than 2 days for widespread infringement or serious incidents involving critical infrastructure; an initial incomplete report followed by a complete report is permitted)." ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "source_type": "voluntary-standard", "url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public domain", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/OA-07 Incident Escalation Authority Chain control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "authority": "European Union", "title": "EU Artificial Intelligence Act 2024/1689", "source_type": "regulation", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "public", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU Artificial Intelligence Act 2024/1689 requirements informing the apeiris://model/controls/OA-07 Incident Escalation Authority Chain control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "source_type": "certification-standard", "url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/OA-07 Incident Escalation Authority Chain control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Tiered escalation authority with pre-defined decision rights: document who can authorize what at each level, with time-triggered automatic escalation if the current level does not resolve or escalate within the defined window.", "steps": [ "Define incident severity tiers (e.g., S1–S4) with criteria for each tier relevant to AI model incidents.", "For each severity tier, document: who owns the response, what decisions they can make without escalating, when they must escalate, and to whom.", "Map regulatory notification obligations to severity tiers — identify which incidents trigger mandatory notification and within what timeframe.", "Define the board-level visibility threshold: criteria for incidents requiring board notification.", "Conduct an annual tabletop exercise simulating a S1 AI model incident; document gaps and remediate within 90 days.", "Integrate the escalation chain with the model owner register (OA-01) — owner is always the starting point for escalation." ], "anti_patterns": [ "Escalation chain that lists committees rather than named individuals with authority — during an incident, committees cannot make real-time decisions.", "No time bounds on escalation steps — allowing indefinite dwell at Level 1 while harm accumulates.", "Regulatory notification obligations not mapped to the escalation chain — compliance team learns about notifications after the time window has closed.", "Escalation chains that are documented but never tested — untested chains fail at the moment of an actual incident." ] }, "validation": { "design_check": [ "Escalation authority chain document exists with named individuals (not just roles) at each level. [ref:eu_ai_act_2024]", "Decision rights matrix is documented for each escalation level. [ref:iso_42001_2023]", "Regulatory notification obligations and time bounds are mapped to escalation levels. [ref:eu_ai_act_2024]", "Board-level notification threshold is defined and approved by the board or audit committee. [ref:eu_ai_act_2024]" ], "runtime_test": [ "Conduct annual tabletop exercise; verify all levels of the escalation chain respond within defined time bounds. [unverified]", "Review past 12 months of incidents; verify escalation chain was followed and time bounds were met. [unverified]", "Verify escalation contact list is current — no departed employees or invalid contact information. [unverified]" ], "evidence": [ "model:escalation-authority-chain-document-cur — Escalation authority chain document (current version, with approval date). [unverified]", "model:annual-tabletop-exercise-record-includi — Annual tabletop exercise record, including identified gaps and remediation actions. [unverified]", "model:incident-post-mortem-records-showing-esc — Incident post-mortem records showing escalation chain adherence. [unverified]", "model:regulatory-notification-log-if-any-noti — Regulatory notification log (if any notifications were required in the past 12 months). [unverified]" ] }, "lenses": { "engineering": "Instrument model incident detection to automatically page the relevant owner based on model ID. Integrate with on-call tooling with escalation rules mirroring the authority chain.", "evaluation": "Evaluation team is a key resource during incidents — their model knowledge informs rapid impact assessment. Ensure evaluation team is explicitly named in Level 1 or Level 2 response.", "red_team": "Test incident response by simulating a significant model failure; verify escalation chain activates correctly and within defined time bounds.", "grc": "Escalation chain is a key governance artifact. Regulatory notification mapping is a compliance obligation under EU AI Act Art-73 and sector-specific incident reporting requirements.", "mlops": "MLOps on-call is typically Level 1 responder. Ensure on-call rotation is integrated with the model owner register and model-specific runbooks exist for each production model." }, "monitoring_schema": { "metrics": [ { "name": "time_to_escalation_minutes", "description": "Time from incident detection to escalation to next level, per severity tier", "unit": "minutes", "alert_threshold": { "maximum_minutes_per_level": 30, "note": "exceeding threshold triggers automatic escalation to next level" }, "window_context": "per incident", "sampling_rate": "per escalation event", "metric_id": "time_to_escalation_minutes", "metric_type": "performance", "measure": "elapsed-minutes", "population": "all-production-decisions", "comparison": { "operator": "greater-than", "value": 30, "window": "rolling-30d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "escalation_chain_test_days_since_last", "description": "Days since last tabletop exercise or live drill", "unit": "days", "alert_threshold": { "maximum_days": 365, "note": "exceeding triggers scheduling requirement" }, "window_context": "rolling", "sampling_rate": "continuous", "metric_id": "escalation_chain_test_days_since_last", "metric_type": "performance", "measure": "days-elapsed", "population": "all-production-decisions", "comparison": { "operator": "greater-than", "value": 365, "window": "rolling-30d", "evaluation_mode": "batch" }, "severity": "medium" } ], "window_context": "rolling-30d", "sampling_rate": "100%" }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "In the 15-control baseline. Covers escalation authority and decision rights. Incident detection and monitoring triggering escalation is covered in CR layer. Incident response procedures (what to do operationally) are distinct from escalation authority (who can authorize which actions).", "profiles": [ { "profile": "general-predictive-ml", "applicability": "required", "tailoring": "Standard escalation chain sufficient; board notification threshold may be set higher for lower-risk models." }, { "profile": "generative-ai", "applicability": "required", "tailoring": "Generative AI incidents may require rapid public communications — add communications team to escalation chain at Level 2." }, { "profile": "hosted-api", "applicability": "required", "tailoring": "Vendor incident notification is a Level 1 trigger. Map vendor SLA (OA-06) to internal escalation timeline." }, { "profile": "high-impact-decision", "applicability": "required", "tailoring": "Board notification threshold must be set lower — consumer harm incidents require rapid board visibility." }, { "profile": "us-regulated-banking", "applicability": "required", "tailoring": "Banking regulatory notification requirements (OCC, Fed, FDIC) must be mapped to escalation levels with specific time bounds." }, { "profile": "eu-high-risk", "applicability": "required", "tailoring": "EU AI Act Art-73 requires serious incident notification to the market surveillance authority within 15 days (2 days for widespread infringement or critical-infrastructure incidents; 10 days for death)." }, { "profile": "frontier-capability", "applicability": "required", "tailoring": "Safety incidents involving frontier models require immediate escalation to the highest governance level; board notification threshold is effectively zero for catastrophic risk incidents." } ], "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE-2.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MANAGE-2.4 (MANAGE function) provides that mechanisms and assigned responsibilities exist to supersede, disengage, or deactivate AI systems that demonstrate performance inconsistent with intended use. OA-07’s escalation authority chain assigns and documents who may authorize superseding, disengaging, or deactivating a model at each severity level.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-73", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Art-73 requires providers to notify market surveillance authorities of serious incidents — the escalation chain must ensure this notification obligation is met within the Art-73 deadlines (15 days generally; 10 days for death; 2 days for widespread infringement or critical-infrastructure incidents).", "uncovered_portion": "Post-incident corrective action requirements addressed in CR layer.", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "10.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 requires documented nonconformity and corrective action processes, which includes incident escalation authority.", "uncovered_portion": "None significant.", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "sr262", "requirement_id": "Sec. VI", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. VI (Governance and Controls) describes reporting on model risk to senior management and the board. OA-07's escalation authority chain gives material model incidents a defined path to those governance levels. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "None significant.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "SEF-01", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "OA-07 defines the governance structure of the incident escalation authority chain — specifying named individuals at four escalation levels with explicit decision rights, time bounds, board-level notification thresholds, and mapping to regulatory notification obligations — which IR-01 requires as the organizational authority prerequisite for AI incident response. This control enables the IR-01 process by establishing who has authority to escalate and halt deployments, while the full operational incident response procedures that IR-01 encompasses are implemented by CR-04.", "uncovered_portion": "IR-01 covers the full AI incident response and recovery lifecycle including detection, containment, remediation, and recovery procedures; OA-07 addresses only the escalation authority chain governance structure — the operational incident detection, containment, and response procedures are covered by CR-04.", "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" } ], "canonical_id": "apeiris://model/controls/OA-07", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-73", "mapping_fit": "partial", "notes": "Art-73 requires market surveillance authorities to be notified of serious incidents; providers of high-risk systems must report to authorities.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "The organization must have a documented incident escalation authority chain for AI model incidents with named individuals at each of four levels, explicit decision rights at each level, time bounds for escalation steps, a defined board-level notification threshold, and annual tabletop exercise completion records. For EU high-risk AI systems, the escalation chain must map EU AI Act Art-73 serious incident reporting obligations (15-day general deadline; 10 days for death; 2 days for widespread infringement or critical-infrastructure incidents) to a specific escalation level.", "evidence_required": [ "escalation_authority_chain_document current version with named individuals (not just roles) at each of the four escalation levels, decision rights matrix, time bounds per level, and board-level notification threshold definition — with approval date", "annual_tabletop_exercise_record for the preceding 12 months, including scenario description, participant list, escalation chain performance against time bounds, gaps identified, and remediation actions", "incident_post_mortem_records for AI model incidents in the preceding 12 months showing escalation chain adherence, time-bound compliance, and regulatory notification actions taken", "regulatory_notification_obligation_mapping document linking EU AI Act Art-73, sector-specific incident reporting requirements, and other applicable obligations to specific escalation levels and time bounds" ], "machine_tests": [ "Query the escalation contact directory against current HR active employee records → assert zero departed employees or invalid contact entries appear at any escalation level", "Review the most recent tabletop exercise record → assert all four escalation levels were exercised, all time bounds were documented, and a post-exercise remediation action log exists", "For any AI model incidents logged in the past 12 months, cross-reference incident timestamp against escalation event records → assert all escalations occurred within the documented time bounds for each level transition" ], "human_review": [ "Assess the escalation authority chain for named individuals at each level: confirm that Level 3 and Level 4 designees have genuine organizational authority to make time-critical decisions — including model shutdown — without additional approvals that would violate time bounds", "Review the board-level notification threshold definition: confirm it is specific enough to be consistently applied (not subject to discretionary interpretation that could delay notification) and that it covers the regulatory notification scenarios required under EU AI Act Art-73 and sector-specific rules", "Evaluate tabletop exercise realism: confirm scenarios tested include realistic AI-specific incident types (model behavioral failure, data poisoning discovery, third-party model compromise) and not only generic cybersecurity incident scenarios" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Defining escalation levels with committee or team names rather than named individuals with authority — during an active incident, a committee cannot make a real-time decision within a 15-minute time bound", "Omitting time bounds on escalation steps, allowing unlimited dwell at Level 1 while harm to affected parties accumulates and regulatory notification windows close", "Failing to map regulatory notification obligations (EU AI Act Art-73 tiered deadlines (15d general / 10d death / 2d widespread or critical infrastructure), sector-specific rules) to a specific escalation level and named individual responsible for filing, resulting in compliance team awareness arriving after the notification window has passed", "Documenting the escalation chain but never testing it through tabletop or simulation exercises — untested chains fail structurally at the moment of an actual incident when time pressure exposes missing authority and unclear decision rights" ], "update_status": "current", "layer_code": "OA" }, { "id": "OA-08", "layer": "OA", "plane": "control", "name": "Notice, Explanation Support, Human Review and Contestability", "plain": "Where required by applicable law or where AI outputs materially affect individuals, the organization must provide affected parties with: (1) notice that an AI system was used, (2) a meaningful explanation of the basis for the decision, (3) access to genuine human review, and (4) a process to contest the outcome. This control is conditionally applicable — the specific obligations vary by jurisdiction, use case, and applicable legal framework. Not all deployments require all four elements.", "matrix_thesis": true, "thesis_type": "directive", "threat": { "tags": [ "EU-AIA-AnnexIII", "MR-PERFORMANCE", "LLM09:2025" ], "desc": "AI systems producing consequential outputs without adequate explanation, human review access, or contestability pathways harm affected individuals and create legal liability. Lack of explanation also masks model errors and discriminatory patterns. LLM09:2025 (Misinformation) is relevant where AI outputs are presented as authoritative without adequate notice of AI provenance." }, "obligations": [ { "id": "eu-ai-act-art-13", "regulation": "EU AI Act", "article": "Article 13", "title": "Transparency and Provision of Information to Deployers", "requirement": "High-risk AI systems shall be designed and developed in such a way as to ensure that their operation is sufficiently transparent to enable deployers to understand the system's output and use it appropriately.", "applicability": "eu-high-risk profile", "deadline": "2027-12-02", "enforcement_body": "National market surveillance authority", "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "legal_status": "enacted", "jurisdiction": [ "eu" ], "provision": "Article 13", "effective_from": "2027-12-02" }, { "id": "eu-ai-act-art-50", "regulation": "EU AI Act", "article": "Article 50", "title": "Transparency Obligations — AI Interaction Notice", "requirement": "Providers of AI systems intended to interact with natural persons shall design and develop systems such that persons are notified that they are interacting with an AI system.", "applicability": "AI systems interacting directly with natural persons", "deadline": "2025-08-02", "enforcement_body": "National market surveillance authority", "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "legal_status": "enacted", "jurisdiction": [ "eu" ], "provision": "Article 50", "effective_from": "2025-08-02" }, { "id": "gdpr-art-22", "regulation": "GDPR", "article": "Article 22", "title": "Automated Individual Decision-Making", "requirement": "Data subjects shall have the right not to be subject to a decision based solely on automated processing which produces legal or similarly significant effects, and where the right applies, the right to human review and meaningful information about the logic involved.", "applicability": "EU data subjects; solely automated decisions with legal or similarly significant effects — NOT all AI use cases", "deadline": "in effect", "enforcement_body": "National data protection authority", "note": "GDPR Art-22 is specifically scoped. It does not apply to all AI decisions — only those that are solely automated and produce legal or similarly significant effects.", "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2016/679", "source_ref": "gdpr", "normative_force": "binding-law", "legal_status": "enacted", "jurisdiction": [ "eu" ], "provision": "Article 22" }, { "id": "us-fcra-adverse-action", "regulation": "Fair Credit Reporting Act (US)", "article": "15 U.S.C. § 1681m", "title": "Adverse Action Notice", "requirement": "Creditors must provide adverse action notices explaining the reasons for adverse credit decisions, including those based on AI models.", "applicability": "US consumer credit decisions — jurisdiction-specific", "deadline": "in effect", "enforcement_body": "CFPB and FTC", "note": "AI-generated reasons must be translatable to human-interpretable adverse action codes. OCC 2026-13 provides non-binding guidance on this translation.", "reviewed_on": "2026-06-26", "authority": "US Congress / CFPB", "instrument": "Fair Credit Reporting Act (FCRA)", "source_ref": "us_fcra", "normative_force": "binding-law", "legal_status": "enacted", "jurisdiction": [ "us" ], "provision": "15 U.S.C. § 1681m" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-13", "mapping_fit": "partial", "notes": "Art-13 requires providers to design high-risk AI systems to be sufficiently transparent to enable deployers to understand capabilities and limitations.", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "standard": [ "Where required by applicable law or governance policy, affected individuals MUST receive notice that an AI system materially influenced a decision affecting them.", "For regulated decisions (credit, employment, insurance, benefits), the explanation provided MUST be sufficient for the affected individual to understand the basis of the decision and take meaningful action in response.", "Human review access MUST be a genuine option — not a nominal right obstructed by procedure, cost, or delay. The human reviewer must have the authority and information to change the outcome.", "A contestability process MUST exist with defined response timelines and a genuine re-evaluation mechanism — a process structurally designed to always confirm the original decision is not compliant.", "Applicability of each element (notice, explanation, human review, contestability) MUST be determined per use case based on applicable jurisdiction, use case type, and legal framework. Not all four elements apply universally.", "Explanation mechanisms for regulated models MUST be validated for accuracy — inaccurate explanations create additional legal and ethical liability beyond the original decision." ], "sources": [ { "id": "eu_ai_act_2024", "authority": "European Union", "title": "EU Artificial Intelligence Act 2024/1689", "source_type": "regulation", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "public", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU Artificial Intelligence Act 2024/1689 requirements informing the apeiris://model/controls/OA-08 Notice, Explanation Support, Human Review and Contestability control.", "reviewed_on": "2026-07-01" }, { "id": "gdpr", "authority": "European Union", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "source_type": "regulation", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "public", "artifact_hash": null, "unverified": true, "status": "current", "retrieved_on": "2026-06-26", "normative_force": "binding-law", "version": "2016/679", "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://model/controls/OA-08 Notice, Explanation Support, Human Review and Contestability control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "source_type": "voluntary-standard", "url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public domain", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/OA-08 Notice, Explanation Support, Human Review and Contestability control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_llm10_2025", "authority": "OWASP", "title": "OWASP Top 10 for LLM Applications 2025", "source_type": "supervisory-guidance", "url": "https://owasp.org/www-project-top-10-for-large-language-model-applications/", "license": "CC BY-SA 4.0", "artifact_hash": null, "unverified": true, "status": "current", "normative_force": "voluntary-standard", "version": "2025", "published_on": "2024-11-17", "retrieved_on": "2026-06-26", "source_id": "owasp_llm10", "relationship": "implementation_pattern", "rationale": "Establishes OWASP Top 10 for LLM Applications 2025 requirements informing the apeiris://model/controls/OA-08 Notice, Explanation Support, Human Review and Contestability control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Applicability-first: conduct a per-use-case determination of which obligations apply before designing implementation. Do not assume universal applicability of all four elements.", "steps": [ "For each AI use case, complete an applicability assessment: (1) jurisdiction of affected individuals, (2) applicable legal framework, (3) decision type and effect severity, (4) whether the decision is solely automated or involves genuine human review.", "For use cases where obligations apply: design notice, explanation, human review, and contestability mechanisms appropriate to the decision context.", "Implement explanation mechanisms that are technically accurate — validate that explanations correctly describe the factors that influenced the model output, not post-hoc rationalization.", "Design the contestability process with defined timelines and a genuine re-evaluation workflow; document reviewer authority to change outcomes.", "Maintain an applicability determination log — document the assessment for each use case, including legal basis, conclusions, and reviewing counsel.", "Review applicability determinations when law changes or use case scope changes materially." ], "anti_patterns": [ "Treating this control as universally applicable without per-use-case assessment — imposes unnecessary burden on low-stakes deployments and may misrepresent legal obligations.", "Providing explanation outputs that are technically inaccurate — post-hoc rationalization that does not reflect actual model attribution.", "Human review process that requires the individual to bear unreasonable cost or delay — nominal access that is practically unavailable is not genuine access.", "Contestability process structurally designed to always confirm the original decision — provides false assurance and does not satisfy rights-based obligations.", "Treating GDPR Art-22 as applying to all AI use cases — it is specifically scoped to solely automated decisions with legal or similarly significant effects." ] }, "validation": { "design_check": [ "Per-use-case applicability determination exists, documenting which obligations apply and the legal basis. [ref:eu_ai_act_2024]", "Explanation mechanism has been technically validated to confirm accuracy against model behavior — not visual inspection only. [ref:eu_ai_act_2024]", "Human review process design verified to provide genuine access (cost, timeline, reviewer authority). [ref:eu_ai_act_2024]", "Contestability process design reviewed by legal counsel to confirm it meets applicable legal requirements. [ref:eu_ai_act_2024]" ], "runtime_test": [ "For regulated decision use cases, sample decisions and verify notice was provided to affected individuals. [unverified]", "Verify explanation outputs against model feature attributions for a sample of decisions — confirm factual accuracy. [unverified]", "Review contestability requests in the past 12 months; verify response timelines were met and re-evaluations were substantive. [unverified]", "Audit human review requests; verify reviewers had authority and information to change outcomes. [ref:eu_ai_act_2024]" ], "evidence": [ "model:applicability-determination-log-for-all — Applicability determination log for all production use cases. [unverified]", "model:explanation-mechanism-validation-test-re — Explanation mechanism validation test results. [unverified]", "model:contestability-process-documentation-and — Contestability process documentation and response timeline compliance records. [ref:eu_ai_act_2024]", "model:sample-of-adverse-action-notices-or-equi — Sample of adverse action notices or equivalent disclosure documents (redacted). [unverified]", "model:human-review-access-log-showing-request — Human review access log showing request volume, outcomes, and reviewer qualification. [unverified]" ] }, "lenses": { "engineering": "Build notice delivery, explanation generation, human review routing, and contestability tracking as platform capabilities — not one-off per-use-case implementations. Explanation accuracy validation must be automated where possible.", "evaluation": "Evaluate explanation mechanism accuracy as part of model evaluation — not only model performance metrics. Inaccurate explanations are a model quality defect, not only a compliance issue.", "red_team": "Probe for explanation gaming — can model behavior be designed to generate favorable-looking explanations that do not reflect actual decision factors? Test whether contestability process can be exploited to extract model internals.", "grc": "Applicability determination log is primary compliance evidence. Legal review of applicability determinations is required for regulated use cases. Track jurisdiction-specific obligation timelines and review cycles.", "mlops": "Monitor contestability request volume and response time SLA compliance. Sudden increases in contestability requests may indicate model quality degradation — surface as a model health signal." }, "monitoring_schema": { "metrics": [ { "name": "contestability_response_sla_compliance", "description": "Fraction of contestability requests responded to within the defined SLA", "unit": "ratio", "alert_threshold": { "floor": 0.95, "note": "below 95% triggers operational review" }, "window_context": "30-day rolling", "sampling_rate": "per contestability event", "metric_id": "contestability_response_sla_compliance", "metric_type": "performance", "measure": "sla-compliance-ratio", "population": "all-production-decisions", "comparison": { "operator": "less-than", "value": 0.95, "window": "30d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "explanation_accuracy_validation_score", "description": "Fraction of sampled explanations that accurately reflect model feature attributions", "unit": "ratio", "alert_threshold": { "floor": 0.9, "note": "below 90% triggers explanation mechanism review and possible model hold" }, "window_context": "quarterly sample", "sampling_rate": "quarterly", "metric_id": "explanation_accuracy_validation_score", "metric_type": "performance", "measure": "composite-score", "population": "all-production-decisions", "comparison": { "operator": "less-than", "value": 0.9, "window": "90d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "contestability_request_rate_per_thousand", "description": "Rate of contestability requests per thousand decisions, used as a model quality and applicant experience proxy", "unit": "per-thousand", "alert_threshold": { "spike_multiplier": 2, "note": "2x baseline spike triggers model quality review" }, "window_context": "30-day rolling", "sampling_rate": "per decision event", "metric_id": "contestability_request_rate_per_thousand", "metric_type": "performance", "measure": "event-rate", "population": "all-production-decisions", "comparison": { "operator": "greater-than", "value": 2, "window": "30d", "evaluation_mode": "batch" }, "severity": "medium" } ], "window_context": "rolling-30d", "sampling_rate": "100%" }, "capability_risk": { "capability_level": "none", "autonomy": "supervised", "access_mode": "internal", "irreversibility": "partially-reversible", "deployment_scale": "enterprise", "affected_party_impact": "moderate", "external_reach": false, "data_sensitivity": "internal", "notes": "primary concern: accountability-gap | secondary concern: explainability-deficit | consequence if failed: regulatory non-compliance, harm to affected individuals, reputational damage, litigation exposure, loss of operating license in regulated sectors | risk amplifiers: high_decision_volume, opaque_model_architecture, cross_border_operations, vulnerable_affected_population, fully_automated_pipeline" }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Applicability is conditional and varies by jurisdiction and use case. This control does NOT assert universal contestability requirements. Legal review of applicability is mandatory before implementation design. Matrix thesis elevated: this control addresses a consequential rights protection obligation where the temptation exists to treat nominal compliance as substantive compliance.", "profiles": [ { "profile": "general-predictive-ml", "applicability": "conditional", "tailoring": "Apply only where outputs affect individuals in regulated or high-impact ways. Document applicability determination with legal sign-off." }, { "profile": "generative-ai", "applicability": "conditional", "tailoring": "Notice that output is AI-generated applies broadly under EU AI Act Art-50. Explanation and contestability apply only where outputs constitute regulated decisions." }, { "profile": "hosted-api", "applicability": "conditional", "tailoring": "Deployer retains obligation even when using hosted model. Notice must reflect actual AI involvement — vendor branding does not satisfy disclosure requirements." }, { "profile": "continuously-learning", "applicability": "conditional", "tailoring": "Explanation mechanisms must remain valid as model updates — validate explanation accuracy after each significant model update." }, { "profile": "high-impact-decision", "applicability": "required", "tailoring": "All four elements (notice, explanation, human review, contestability) apply. Human review must be genuine per OA-02 five-factor standard." }, { "profile": "us-regulated-banking", "applicability": "required", "tailoring": "FCRA adverse action notice requirements apply for credit decisions. Explanation must support human-interpretable adverse action reason codes; see OCC 2026-13 for non-binding guidance." }, { "profile": "eu-high-risk", "applicability": "required", "tailoring": "EU AI Act Art-13 (transparency) and GDPR Art-22 (where applicable) create specific obligations. Conformity assessment must include review of explanation mechanisms." }, { "profile": "frontier-capability", "applicability": "conditional", "tailoring": "Notice and transparency obligations apply broadly; other elements conditional on specific use case and affected population." } ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art-13", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Art-13 requires transparency to deployers; Art-14 requires human oversight; Art-50 requires AI interaction notice where the system interacts directly with natural persons.", "uncovered_portion": "Art-13 technical documentation requirements (instructions for use) are addressed in LI layer.", "reviewed_on": "2026-06-26", "source_version": "2024/1689", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_rmf", "requirement_id": "MANAGE-4.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MANAGE-4.1 (MANAGE function) provides that post-deployment monitoring plans are implemented, including appeal and override, decommissioning, incident response, and change management. OA-08’s notice, explanation, human-review, and contestability mechanisms implement the appeal-and-override component of post-deployment risk management.", "reviewed_on": "2026-06-26", "source_version": "1.0", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.8.5", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.8.5 (Information for interested parties) requires determining and providing information to interested parties about the AI system. OA-08’s notice, explanation, and contestability mechanisms deliver that information to affected individuals.", "reviewed_on": "2026-06-26", "source_version": "2023", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "llm10", "requirement_id": "LLM09:2025", "fit": "partial", "direction": "control-mitigates-risk", "rationale": "OWASP LLM09:2025 (Misinformation) is mitigated in part by OA-08's AI-involvement notice and validated explanation accuracy requirements, which reduce unwarranted reliance on model output for consequential decisions.", "uncovered_portion": "Factual accuracy of model outputs is a separate concern addressed in EV layer.", "reviewed_on": "2026-06-26", "source_version": "2025", "normative_force": "industry-framework", "basis": "asserted", "relation": "defends_against" }, { "framework": "aicm", "requirement_id": "GRC-13", "fit": "direct", "direction": "control-supports-requirement", "rationale": "OA-08 implements the notice, explanation, human review, and contestability obligations for individuals affected by consequential AI outputs — directly addressing GRC-13's expectations for transparency, notice, and contestability by mandating per-use-case applicability determination, technically accurate explanation mechanisms validated against model attribution, genuine human review access, and a re-evaluation-capable contestability process. The control's phased applicability model and legal-counsel-reviewed determination log provide the structured compliance evidence that GRC-13 requires across diverse jurisdictions and decision types.", "source_locator": { "section": "Transparency and Explainability" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "owasp_aitg", "requirement_id": "AITG-APP-14", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AITG-APP-14 (Testing for Explainability and Interpretability) evaluates whether model decisions can be meaningfully explained. OA-08's validated explanation mechanisms for regulated decisions supply the explanation quality this test measures; notice and contestability obligations sit outside the test's scope.", "source_locator": { "test_id": "AITG-APP-14", "test_name": "Testing for Explainability and Interpretability" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "aitransparency", "fit": "supporting", "rationale": "Providing notice that an AI system was used is the disclosure obligation of the AI-transparency control.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "explainability", "fit": "supporting", "rationale": "Providing a meaningful explanation of the basis for an AI decision is the explainability control.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "assurance_target": { "applicability_determination": "documented-per-use-case-with-legal-sign-off", "explanation_accuracy": "validated-against-model-attribution", "human_review_access": "genuine-not-nominal", "contestability": "re-evaluation-capable-with-authority-to-change" }, "canonical_id": "apeiris://model/controls/OA-08", "validation_objective": "The system must have a documented, legally-reviewed per-use-case applicability determination confirming which of the four obligations (notice, explanation, human review, contestability) apply; for each applicable obligation, the corresponding mechanism must be implemented, technically accurate, and operationally accessible to affected individuals without unreasonable barrier.", "evidence_required": [ "per-use-case applicability determination log with legal basis, applicable jurisdiction, conclusions, and reviewing counsel sign-off for each production AI deployment", "explanation mechanism validation test results confirming explanation outputs match model feature attribution (e.g., SHAP/LIME correlation > 0.8) for a representative sample of regulated decisions", "contestability process documentation showing defined SLA timelines, reviewer authority scope, and re-evaluation workflow design reviewed by legal counsel", "human review access log for trailing 12 months showing request volume, response times, reviewer qualifications, and rate of outcome changes", "sample of adverse action notices or equivalent AI disclosure documents (redacted) confirming notice delivery for regulated decision use cases" ], "machine_tests": [ "Submit a regulated-decision-profile inference and query the notice delivery log → assert a record exists with decision_id, recipient_channel, delivery_timestamp, and ai_disclosure_flag=true", "Request a decision explanation and compare explanation feature weights against SHAP attribution for the same input → assert Spearman rank correlation >= 0.8 between explanation and model attribution", "Submit a contestability request via the defined process → assert response_timestamp minus request_timestamp is within the documented SLA and outcome field is one of [upheld, modified, reversed, under-review]", "Initiate a human review request and verify the reviewer record → assert reviewer_id is present, reviewer_has_change_authority=true, and review_completed_timestamp is populated" ], "human_review": [ "Review applicability determinations for at least three production use cases and confirm that legal basis, scope boundaries, and counsel sign-off are documented — not inferred from a blanket policy", "Assess the contestability process design for structural bias by verifying that process steps and reviewer incentives do not systematically favor confirming the original AI decision over genuine re-evaluation", "Evaluate explanation mechanism accuracy for a sample of complex decisions by comparing generated explanations against model internals documentation and confirming factual alignment" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Treating this control as universally applicable to all AI deployments without a per-use-case applicability determination — imposes unjustified burden on low-stakes uses and misrepresents the scope of legal obligations", "Implementing a contestability process with mandatory fees, excessive documentation requirements, or 90-plus-day response timelines that make the right practically inaccessible to affected individuals", "Generating explanation outputs from a separate post-hoc rationalization model rather than from actual model attribution — produces legally inaccurate disclosures and creates additional liability", "Staffing the human review option with reviewers who lack the authority or contextual information to change the outcome — nominal access that cannot alter results is not genuine review", "Applying GDPR Art-22 automated decision rights to AI use cases that involve genuine human review in the decision loop or that do not produce legal or similarly significant effects on individuals" ], "update_status": "current", "layer_code": "OA" }, { "id": "BH-01", "layer": "BH", "plane": "data", "name": "Output Anomaly Detection", "plain": "Continuously monitor model outputs using statistical process control to detect when output distributions deviate from established baselines, triggering alerts before users are harmed at scale.", "threat": { "tags": [ "MR-MONITORING", "AML.T0024", "LLM04:2025" ], "desc": "Undetected output drift or adversarial manipulation of model outputs can cause cascading harm, biased decisions, or undetected exfiltration via inference outputs. Without statistical monitoring, regressions and attacks go unnoticed until user complaints surface." }, "standard": [ { "id": "nist_rmf", "ref": "MEASURE 2.4" }, { "id": "iso_42001", "ref": "A.6.2.6" }, { "id": "eu_ai_act", "ref": "Art. 9(7), Art. 72" }, { "id": "aisvs", "ref": "C12.3 — Model, Data, and Performance Drift Detection" } ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://doi.org/10.6028/NIST.AI.100-1", "source_type": "supervisory-guidance", "license": "public_domain", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/BH-01 Output Anomaly Detection control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "source_type": "certification-standard", "license": "proprietary", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/BH-01 Output Anomaly Detection control.", "reviewed_on": "2026-07-01" }, { "id": "mitre_atlas_v5_6_0", "authority": "MITRE", "title": "MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems", "url": "https://atlas.mitre.org", "source_type": "threat-knowledge-base", "license": "apache_2_0", "version": "5.6.0", "effective_date": "2026-05-04", "artifact_hash": null, "status": "current", "normative_force": "best-practice", "published_on": "2026-05-04", "retrieved_on": "2026-06-26", "source_id": "mitre_atlas", "relationship": "informative_reference", "rationale": "Establishes MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems requirements informing the apeiris://model/controls/BH-01 Output Anomaly Detection control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_aisvs_v1", "authority": "OWASP", "title": "OWASP AI Security Verification Standard v1.0", "url": "https://github.com/OWASP/AISVS", "source_type": "voluntary-standard", "license": "CC-BY-SA-4.0", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2026-06-26", "retrieved_on": "2026-06-26", "source_id": "owasp_aisvs_v1", "relationship": "implementation_pattern", "rationale": "Establishes OWASP AI Security Verification Standard v1.0 requirements informing the apeiris://model/controls/BH-01 Output Anomaly Detection control.", "reviewed_on": "2026-07-01", "canonical_url": "https://github.com/OWASP/AISVS" } ], "implementation": { "pattern": "Deploy a statistical process control (SPC) pipeline that continuously samples model output distributions, computes control chart statistics, and fires alerts when outputs fall outside control limits derived from a validated baseline window.", "steps": [ "Instrument inference endpoints to capture a stratified sample (5–20% of volume) with metadata: timestamp, input_hash, caller_id, model_version.", "Establish a baseline output distribution from a 30-day post-deployment stable window; store baseline statistics (mean, std_dev, p5/p50/p95/p99) in a versioned, signed artifact in the model registry.", "Implement Shewhart X-bar and R control charts for continuous numeric outputs; use CUSUM or EWMA for detecting small persistent shifts.", "For classification outputs, track class distribution stability using PSI: alert at PSI > 0.2, escalate at PSI > 0.25.", "For generative outputs, monitor token entropy, output length distribution, refusal rate, and toxicity score distribution.", "Route severity=critical alerts to on-call MLOps within 15 minutes; severity=warning to model owner within 4 hours.", "Store all anomaly events in the evidence registry with control linkage BH-01." ], "anti_patterns": [ "Logging outputs without statistical comparison to a fixed baseline — produces noise without signal.", "Setting control limits from overall historical average without seasonality adjustment — causes alert fatigue.", "Monitoring only error rates without output distribution — misses silent degradations.", "Using real PII in the sampled output stream without masking before storage." ] }, "monitoring_schema": { "metric_objects": [ { "name": "output_psi", "type": "psi_score", "description": "PSI comparing current output distribution to the 30-day post-deployment baseline.", "alert_threshold": 0.2, "critical_threshold": 0.25, "unit": "dimensionless", "metric_id": "output_psi", "metric_type": "drift", "measure": "population-stability-index", "population": "all-production-inferences", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "output_entropy_mean", "type": "gauge", "description": "Rolling mean of token-level entropy for generative outputs.", "alert_threshold_delta_pct": 25, "unit": "bits_per_token", "metric_id": "output_entropy_mean", "metric_type": "performance", "measure": "output-entropy-mean", "population": "all-production-inferences", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "refusal_rate", "type": "rate", "description": "Fraction of outputs classified as refusals or out-of-scope deflections.", "alert_threshold_delta_pct": 50, "unit": "fraction", "metric_id": "refusal_rate", "metric_type": "safety", "measure": "event-rate", "population": "all-production-inferences", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "output_length_p95", "type": "percentile", "description": "95th percentile output length in tokens.", "alert_threshold_delta_pct": 30, "unit": "tokens", "metric_id": "output_length_p95", "metric_type": "performance", "measure": "output-length-p95", "population": "all-production-inferences", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" } ], "window_context": { "type": "sliding", "duration_minutes": 60, "minimum_sample_size": 200, "baseline_window_days": 30 }, "sampling_rate": 0.1, "sampling_strategy": "stratified_by_caller" }, "validation": { "design_check": [ "SPC baseline was computed from a validated stable post-deployment window and stored as a versioned signed artifact. [ref:nist_ai_rmf_1_0]", "PSI alert and critical thresholds are documented and reviewed by the model owner at minimum quarterly. [ref:iso_42001_2023]", "Anomaly alert routing SLA (15 min critical, 4 hours warning) is defined in the incident response runbook. [ref:nist_ai_rmf_1_0]", "Sampled outputs pass through a PII masking pipeline before storage. [ref:nist_ai_rmf_1_0]" ], "runtime_test": [ "{'test': 'Inject a known-anomalous output batch (distribution shifted 2 sigma) and verify SPC fires within one monitoring window.', 'ref': 'nist_rmf_1_0'} [ref:nist_ai_rmf_1_0]", "{'test': 'Verify sampled outputs contain no direct PII fields after the masking pipeline.', 'unverified': True} [unverified]", "{'test': 'Confirm anomaly events appear in evidence registry with BH-01 control linkage and required metadata.', 'unverified': True} [unverified]", "{'test': 'Inject low-amplitude persistent shift (0.5 sigma over 6 hours) and verify EWMA detects it.', 'ref': 'atlas_v560'} [ref:mitre_atlas_v5_6_0]" ], "evidence": [ "model:baseline-distribution-artifact-with-vers — Baseline distribution artifact with version, timestamp, and statistical parameters for current production model. [ref:nist_ai_rmf_1_0]", "model:spc-alert-log-for-trailing-90-days-with — SPC alert log for trailing 90 days with alert count, resolution time, and outcome classification. [unverified]", "model:quarterly-threshold-review-sign-off-from — Quarterly threshold review sign-off from model owner. [ref:iso_42001_2023]" ] }, "lenses": { "engineering": "Implement as a sidecar or streaming pipeline consuming inference telemetry; use efficient reservoir sampling to add no measurable inference latency.", "evaluation": "SPC control limits must be re-derived after each model update; the post-deployment evaluation run defines the new baseline window — evaluation team owns baseline publication.", "red_team": "Probe whether slow-drip adversarial inputs evade single-window SPC; test EWMA sensitivity to multi-modal output distribution attacks.", "grc": "EU AI Act Art. 72 requires post-market monitoring for high-risk AI; the SPC alert log and baseline artifact are primary evidence for that obligation.", "mlops": "Integrate PSI computation as a non-blocking async task; auto-trigger model review workflow when critical threshold is crossed." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers output-layer statistical monitoring only. Input distribution monitoring is in BH-02. Security-layer anomaly detection is owned by securitycontrols.ai.", "canonical_id": "apeiris://model/controls/BH-01", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. BH-01’s statistical process control over output distributions is production monitoring of system behavior, with signed baselines and tiered alerting.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) requires monitoring the AI system in operation. BH-01’s statistical process control over output distributions implements that monitoring with signed baselines and tiered alerts.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "MDS-10", "fit": "direct", "direction": "control-supports-requirement", "rationale": "BH-01 deploys a statistical process control pipeline that continuously samples model output distributions, computes PSI against a signed 30-day post-deployment baseline, and fires tiered alerts when outputs deviate beyond control limits — directly implementing MON-01's runtime output monitoring and anomaly detection requirement. The control produces a signed baseline artifact, an anomaly event log linked to BH-01 in the evidence registry, and quarterly threshold review records that together constitute the evidence chain MON-01 expects from a production output monitoring system.", "source_locator": { "section": "Monitoring and Alerting" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "owasp_aitg", "requirement_id": "AITG-MOD-06", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AITG-MOD-06 (Testing for Robustness to New Data) addresses model behavior as production data departs from training assumptions. BH-01's statistical process control over output distributions detects exactly the behavioral shift this test anticipates.", "source_locator": { "test_id": "AITG-MOD-06", "test_name": "Testing for Robustness to New Data" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-15", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 15 requires high-risk AI systems to achieve an appropriate level of accuracy, robustness and cybersecurity; BH-01's statistical process control and PSI-based output anomaly detection directly supports the robustness dimension by detecting production anomalies before they cause downstream harm.", "uncovered_portion": "Art. 15 encompasses cybersecurity hardening, accuracy benchmarks, and testing under all conditions of intended use; BH-01 addresses runtime statistical monitoring only, not adversarial robustness, model accuracy certification, or security hardening.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. V", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes ongoing monitoring of model performance and behavior; BH-01 operationalizes this by detecting statistical distribution shifts in model outputs that may indicate degraded performance or data-quality problems. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 applies only to supervised banking organizations with $30B+ in assets; does not apply to general or GenAI deployments. BH-01 alone does not cover SR 26-2's requirement for outcome analysis and back-testing against realized results.", "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_aisvs", "requirement_id": "C11.2.3", "fit": "partial", "rationale": "AISVS C11.2.3 output calibration to reduce overconfident predictions.", "normative_force": "industry-framework", "source_version": "1.0", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "monitoruse", "fit": "supporting", "rationale": "Continuously sampling inference outputs and alerting on distribution shift is monitoring model use for anomalies.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0024", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"The production inference endpoint must be continuously sampled and output distributions…\" enacts ATLAS mitigation AML.M0024 AI Telemetry Logging; OpenCRE crosswalks this control’s OWASP AI Exchange concept (monitoruse) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-15", "mapping_fit": "partial", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "The production inference endpoint must be continuously sampled and output distributions must be statistically compared against a versioned, SHA-256-signed baseline artifact using PSI and Shewhart/EWMA control chart methods, such that any distribution shift exceeding PSI 0.2 fires a tiered alert within one monitoring window of the shift occurring and all anomaly events are stored in the evidence registry with BH-01 control linkage.", "evidence_required": [ "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context" ], "machine_tests": [ "Inject a synthetic output batch with PSI = 0.22 against the stored baseline → assert SPC fires a severity=warning alert within one 60-minute monitoring window", "Inject a sustained low-amplitude shift of 0.5 sigma over a 6-hour period → assert the EWMA detector generates an alert before end of the 6-hour window", "Submit sampled outputs through the logging pipeline and inspect stored records → assert zero fields matching direct PII patterns (SSN, email, full name) are present in any stored output sample", "Load the baseline artifact and compute its SHA-256 hash → assert the computed hash matches the registry entry before any PSI comparison is allowed to proceed" ], "human_review": [ "Review the baseline artifact and confirm it was derived from a validated stable post-deployment window, not from data containing known anomalies or model-version transitions", "Assess quarterly threshold review records to verify the model owner evaluated PSI thresholds against the current deployment context and output distribution characteristics rather than rubber-stamping prior values", "Inspect the alert routing runbook to confirm on-call escalation paths are current, contact information is accurate, and the 15-minute critical SLA is operationally achievable given current staffing" ], "blocking_effect": "advisory", "normative_status": "certification-standard", "anti_patterns": [ "Storing raw model output text without passing through the PII masking pipeline — creates GDPR breach risk and defeats the privacy-safe monitoring design", "Setting SPC control limits from the entire deployment history average rather than a validated stable post-deployment window — makes thresholds insensitive to genuine output shifts", "Monitoring only error rates or latency as proxies for output quality — misses semantic distribution shifts that do not affect system error rates or response times", "Applying a single PSI threshold to all model output types regardless of output dimensionality — high-dimensional generative outputs require different calibration than binary classification outputs", "Reusing the same baseline artifact after a planned model update instead of re-deriving it from the new model's post-deployment stable window — invalidates all subsequent PSI comparisons" ], "update_status": "current", "layer_code": "BH" }, { "id": "BH-02", "layer": "BH", "plane": "data", "name": "Concept and Data Drift Detection", "plain": "Detect when production data diverges from the training distribution, triggering review or retraining before performance silently degrades — with stricter thresholds and shorter windows for continuously-learning deployments.", "threat": { "tags": [ "MR-MONITORING", "MR-PERFORMANCE", "AML.T0020" ], "desc": "Covariate shift and concept drift silently erode model reliability. For continuously-learning models, undetected drift initiates feedback loops that effectively poison the model over time, analogous to a slow training-data poisoning attack (AML.T0020)." }, "standard": [ { "id": "nist_rmf", "ref": "MEASURE 2.4" }, { "id": "iso_42001", "ref": "A.6.2.6" }, { "id": "eu_ai_act", "ref": "Art. 9(7), Art. 72" }, { "id": "sr262", "ref": "Sec. V — Model Validation and Monitoring (ongoing monitoring)", "section": "Sec. V", "title": "Model validation and monitoring — ongoing monitoring" } ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://doi.org/10.6028/NIST.AI.100-1", "source_type": "supervisory-guidance", "license": "public_domain", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/BH-02 Concept and Data Drift Detection control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "source_type": "certification-standard", "license": "proprietary", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/BH-02 Concept and Data Drift Detection control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Revised Guidance on Model Risk Management", "source_type": "supervisory-guidance", "license": "public_domain", "supersedes": [ "SR 11-7", "SR 21-8" ], "artifact_hash": null, "status": "current", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/BH-02 Concept and Data Drift Detection control.", "reviewed_on": "2026-07-01" }, { "id": "mitre_atlas_v5_6_0", "authority": "MITRE", "title": "MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems", "url": "https://atlas.mitre.org", "source_type": "threat-knowledge-base", "license": "apache_2_0", "version": "5.6.0", "effective_date": "2026-05-04", "artifact_hash": null, "status": "current", "normative_force": "best-practice", "published_on": "2026-05-04", "retrieved_on": "2026-06-26", "source_id": "mitre_atlas", "relationship": "informative_reference", "rationale": "Establishes MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems requirements informing the apeiris://model/controls/BH-02 Concept and Data Drift Detection control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Compute feature-level and prediction-level drift statistics on a rolling basis against a training-time DriftReference artifact. Apply profile-conditional thresholds and retraining triggers: general-predictive-ml uses 24-hour windows with PSI > 0.2; continuously-learning uses 6-hour windows with PSI > 0.1 and automatic online-learning suspension.", "steps": [ "At training time, serialize a DriftReference artifact: per-feature statistics (mean, std, histogram, KDE), joint covariance matrix, prediction distribution histogram, SHA-256 artifact hash. Store in model registry alongside weights.", "In production, compute PSI and KS-test p-values for each monitored feature per profile window, enforcing minimum_sample_size before reporting any statistic.", "Track prediction drift separately: compare current prediction distribution to training-time validation set distribution using PSI.", "general-predictive-ml: when feature PSI > 0.2 on any tier-1 feature OR prediction PSI > 0.2, raise drift_alert and auto-open a model review ticket.", "continuously-learning: stricter threshold PSI > 0.1 on 6-hour window; trigger emergency review and suspend online updates until model owner signs a resume authorization.", "Maintain drift event log per alert: feature_name, test_statistic, p_value, window_start, window_end, sample_count, action_taken.", "Monthly drift summary reports to model owner and governance board." ], "anti_patterns": [ "Single aggregate drift score across all features — masks per-feature shifts.", "Skipping minimum_sample_size guard — noisy statistics on small windows cause false urgency.", "Not versioning the DriftReference artifact — makes comparison to original training distribution impossible after retraining.", "Triggering full retraining automatically without human review for high-impact-decision models.", "Monitoring only the prediction column — masks root cause of covariate shift." ] }, "monitoring_schema": { "metric_objects": [ { "name": "feature_psi_max", "type": "psi_score", "description": "Maximum PSI across all tier-1 monitored input features in the current window.", "alert_threshold": 0.2, "critical_threshold": 0.25, "profile_override": { "continuously-learning": { "alert_threshold": 0.1, "critical_threshold": 0.15 } }, "unit": "dimensionless", "metric_id": "feature_psi_max", "metric_type": "drift", "measure": "population-stability-index", "population": "all-production-inferences", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "prediction_psi", "type": "psi_score", "description": "PSI of current prediction distribution vs. training-time DriftReference.", "alert_threshold": 0.2, "critical_threshold": 0.3, "unit": "dimensionless", "metric_id": "prediction_psi", "metric_type": "drift", "measure": "population-stability-index", "population": "all-production-inferences", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "ks_test_p_value_min", "type": "p_value", "description": "Minimum KS-test p-value across monitored continuous features.", "alert_threshold": 0.05, "unit": "probability", "metric_id": "ks_test_p_value_min", "metric_type": "performance", "measure": "ks-test-p-value-min", "population": "all-production-inferences", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "drift_event_count_7d", "type": "counter", "description": "Number of distinct drift alert events in trailing 7 days.", "alert_threshold": 3, "unit": "count", "metric_id": "drift_event_count_7d", "metric_type": "performance", "measure": "event-count", "population": "all-production-inferences", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" } ], "window_context": { "type": "sliding", "duration_hours": 24, "minimum_sample_size": 500, "baseline_artifact": "DriftReference_v{model_version}", "profile_conditional_windows": { "general-predictive-ml": { "duration_hours": 24, "minimum_sample_size": 500 }, "continuously-learning": { "duration_hours": 6, "minimum_sample_size": 200 } } }, "sampling_rate": 1, "sampling_strategy": "full_population_with_feature_hash" }, "profiles": [ "general-predictive-ml", "continuously-learning" ], "validation": { "design_check": [ "DriftReference artifact is versioned, SHA-256 signed, and stored in the model registry alongside model weights at training time. [ref:nist_ai_rmf_1_0]", "minimum_sample_size is configured per profile and enforced before any statistic is reported. [ref:iso_42001_2023]", "Profile-conditional thresholds are documented in the drift configuration YAML and version-controlled. [ref:sr262_2026]", "SR 26-2 ongoing monitoring requirement: drift detection policy and review cadence are documented in the model risk file. [ref:sr262_2026]" ], "runtime_test": [ "{'test': 'Inject synthetic shifted feature distribution (mean offset 2 sigma on tier-1 feature) and verify drift alert fires within one window period.', 'ref': 'nist_rmf_1_0'} [ref:nist_ai_rmf_1_0]", "{'test': 'Verify system refuses to report drift statistics when sample count < minimum_sample_size.', 'unverified': True} [unverified]", "{'test': 'continuously-learning profile: inject PSI=0.12 and verify online learning is suspended pending signed resume authorization.', 'unverified': True} [unverified]", "{'test': 'Confirm DriftReference artifact hash is validated on load before any comparison proceeds.', 'unverified': True} [unverified]" ], "evidence": [ "model:driftreference-artifact-for-current-prod — DriftReference artifact for current production model with version, training date, and per-feature statistics. [ref:nist_ai_rmf_1_0]", "model:drift-event-log-for-trailing-90-days-wit — Drift event log for trailing 90 days with per-feature statistics and action-taken records. [ref:sr262_2026]", "model:monthly-drift-summary-report-signed-by-m — Monthly drift summary report signed by model owner. [ref:iso_42001_2023]" ] }, "lenses": { "engineering": "Serialize DriftReference as a lightweight JSON artifact at training time; implement drift computation as a stateless function reading reference from object storage, keeping monitoring path independent of serving path.", "evaluation": "Post-deployment evaluation establishes the initial drift baseline; include drift alert rate and time-to-drift in the model health dashboard.", "red_team": "Test whether gradual adversarial input manipulation below the per-window PSI threshold accumulates across windows to cause undetected performance degradation.", "grc": "SR 26-2 mandates ongoing monitoring for $30B+ asset institutions; drift event log is primary evidence for model risk management attestation.", "mlops": "Drift alerts auto-create issue tickets; retraining triggers require human approval for high-impact-decision and continuously-learning profiles before any production weight update." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers input feature drift and prediction drift. Concept drift requiring labeled ground truth is handled in the EV layer. Online learning governance is detailed in BH-10.", "canonical_id": "apeiris://model/controls/BH-02", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. BH-02’s PSI/KS drift detection continuously monitors production input behavior against a versioned DriftReference artifact.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) requires monitoring during operation. BH-02’s PSI/KS drift detection against a versioned DriftReference artifact provides the input-drift component.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "MDS-10", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-02 computes PSI and KS-test statistics on production input features against a versioned DriftReference artifact, applying profile-conditional thresholds and triggering model review workflows when distribution shift exceeds safe bounds — directly implementing MON-02's production data and concept drift detection requirement. The control's separate handling of feature drift versus prediction drift, and its stricter thresholds for continuously-learning models, give MON-02 the granularity needed to distinguish different categories of distributional change and their risk implications.", "source_locator": { "section": "Monitoring and Alerting" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "uncovered_portion": "MDS-10 additionally requires ongoing security event correlation, adversarial input monitoring, and model artifact integrity checks beyond the scope of this control.", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "owasp_aitg", "requirement_id": "AITG-MOD-06", "fit": "direct", "direction": "control-supports-requirement", "rationale": "AITG-MOD-06 (Testing for Robustness to New Data) evaluates model reliability as input data drifts. BH-02's PSI and KS-test drift detection against a versioned DriftReference artifact continuously measures the condition this test probes.", "source_locator": { "test_id": "AITG-MOD-06", "test_name": "Testing for Robustness to New Data" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-72", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 72 requires providers and deployers of high-risk AI systems to establish and document post-market monitoring plans; BH-02's drift detection operationalizes the monitoring dimension by tracking input feature distribution and prediction shifts using PSI and KS-test statistics against signed baseline artifacts.", "uncovered_portion": "Art. 72 encompasses the full post-market monitoring plan including user feedback collection, serious incident correlation, and systematic anomaly reporting; BH-02 covers input distribution and prediction drift only and does not address labelled ground-truth concept drift or incident reporting.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. V", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes ongoing monitoring for performance deterioration and distributional change in model inputs; BH-02 directly implements this by computing PSI statistics against a versioned DriftReference artifact. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 applies only to supervised banking organizations with $30B+ in assets. BH-02 does not address SR 26-2's requirement for outcomes analysis or comparison against realized results.", "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "continuousvalidation", "fit": "supporting", "rationale": "Detecting concept and data drift against a signed reference and suspending online updates keeps the model continuously validated against requirements.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0008", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"The production inference pipeline must compare input feature distributions and prediction…\" enacts ATLAS mitigation AML.M0008 Validate AI Model; OpenCRE crosswalks this control’s OWASP AI Exchange concept (continuousvalidation) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-72", "mapping_fit": "partial", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "The production inference pipeline must compare input feature distributions and prediction distributions against a versioned, SHA-256-signed DriftReference artifact using PSI and KS-test statistics for every monitoring window that meets minimum_sample_size, such that drift exceeding profile-conditional PSI thresholds triggers tiered alert actions, and for continuously-learning profiles, automatically suspends online updates pending a signed model-owner resume authorization.", "evidence_required": [ "versioned DriftReference artifact for the current production model with SHA-256 hash, training date, and per-feature statistics (mean, std, histogram bins, and KDE parameters) for all tier-1 monitored features", "drift event log for trailing 90 days with fields: feature_name, test_statistic, p_value, window_start, window_end, sample_count, alert_severity, and action_taken for each drift event", "monthly drift summary report signed by the model owner, including trend analysis across tier-1 features and prediction distribution PSI over the reporting period", "profile-conditional drift threshold configuration (YAML or equivalent) showing per-profile PSI alert and critical thresholds, minimum_sample_size, and window duration, stored under version control" ], "machine_tests": [ "Inject a synthetic feature distribution shifted 2 sigma on a tier-1 feature → assert PSI exceeds profile-conditional threshold and a drift alert fires within one monitoring window with the correct feature_name in the alert payload", "Attempt to compute drift statistics with a sample count below minimum_sample_size → assert the system returns a data-insufficient status code rather than a potentially noisy PSI estimate", "For a continuously-learning profile, inject feature PSI = 0.12 → assert online learning is suspended and a resume_authorization_required flag is set in the drift event record", "Load the DriftReference artifact and compute its SHA-256 hash → assert a hash mismatch returns a validation-failed status and prevents any drift comparison from proceeding" ], "human_review": [ "Review the DriftReference artifact for the current production model and confirm it was generated from the actual training-time dataset — not from a prior model version's reference — and that per-feature statistics are plausible for the training data domain", "Assess the profile-conditional threshold configuration to verify that continuously-learning model thresholds (PSI 0.1) are materially stricter than general-predictive-ml thresholds (PSI 0.2) and that the rationale for each threshold is documented", "Review the last three drift event resolution records to confirm that action_taken was proportionate to drift severity and that human sign-off was obtained before any production weight update was applied" ], "blocking_effect": "advisory", "normative_status": "supervisory-guidance", "anti_patterns": [ "Computing a single aggregate drift score across all features rather than per-feature statistics — masks the root cause of covariate shift and makes targeted remediation impossible", "Not versioning the DriftReference artifact or not linking it to the model registry entry — makes comparison to original training distribution impossible after retraining and defeats the audit trail", "Triggering automatic retraining and production deployment for high-impact-decision models without human review — amplifies the drift signal into the new training set if the source cause is adversarial", "Monitoring only the prediction output distribution without computing per-feature drift statistics — provides a late and indirect signal on covariate shift that has already propagated to predictions", "Applying the same minimum_sample_size guard to both the 6-hour continuously-learning window and the 24-hour general-predictive-ml window — produces unreliable statistics on the shorter window at equivalent volume thresholds" ], "update_status": "current", "layer_code": "BH" }, { "id": "BH-03", "layer": "BH", "plane": "data", "name": "Production Performance Degradation Alerting", "plain": "Compare live production metrics against a signed evaluation baseline established at release, firing threshold-based tiered alerts when performance regresses beyond accepted tolerances before degradation impacts users at scale.", "threat": { "tags": [ "MR-PERFORMANCE", "MR-MONITORING" ], "desc": "Silent performance degradation — where accuracy, latency, or calibration degrades in production without triggering any alert — leads to scaled harm. Regressions can stem from infrastructure changes, model updates, distribution shifts, or adversarial inputs that degrade subgroup performance while keeping aggregate metrics within tolerance." }, "standard": [ { "id": "nist_rmf", "ref": "MEASURE 2.4" }, { "id": "iso_42001", "ref": "A.6.2.6" }, { "id": "eu_ai_act", "ref": "Art. 9(7), Art. 72" }, { "id": "sr262", "ref": "Sec. V — Model Validation and Monitoring (ongoing monitoring and outcomes analysis)", "section": "Sec. V", "title": "Model validation and monitoring — ongoing monitoring and outcomes analysis" } ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://doi.org/10.6028/NIST.AI.100-1", "source_type": "supervisory-guidance", "license": "public_domain", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/BH-03 Production Performance Degradation Alerting control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "source_type": "certification-standard", "license": "proprietary", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/BH-03 Production Performance Degradation Alerting control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Revised Guidance on Model Risk Management", "source_type": "supervisory-guidance", "license": "public_domain", "supersedes": [ "SR 11-7", "SR 21-8" ], "artifact_hash": null, "status": "current", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/BH-03 Production Performance Degradation Alerting control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "authority": "European Parliament and Council", "title": "EU AI Act (Regulation (EU) 2024/1689)", "source_type": "regulation", "license": "public_domain", "artifact_hash": null, "effective_dates": { "standalone_high_risk": "2027-12-02", "product_embedded": "2028-08-02" }, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) requirements informing the apeiris://model/controls/BH-03 Production Performance Degradation Alerting control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Anchor all production performance metrics against a signed EvaluationBaseline artifact published at each release gate. Compute rolling production estimates and fire tiered alerts (warning / critical / sev1) when metrics breach thresholds expressed as percentage regression from baseline.", "steps": [ "At the release gate (EV layer), publish a signed EvaluationBaseline artifact: {model_id, version, eval_date, primary_metrics [{metric_name, value, confidence_interval}], eval_dataset_hash, artifact_sha256}.", "Deploy a metrics aggregation service that continuously estimates production values of the same primary metrics using available signals (labeled ground truth, proxy metrics, user correction rate).", "Define alert thresholds as percentage regression from baseline: tier-1 metrics alert at 5% regression / critical at 10%; tier-2 metrics (calibration, latency p95) alert at 15%.", "When no labeled ground truth is available, use calibrated proxy metrics documented in the proxy_metric_registry.", "Route warning to MLOps on-call (acknowledge within 4 hours); critical to model owner + MLOps (1 hour); sev1 escalates to incident commander (15 minutes).", "Track each alert to resolution: root cause, remediation action, closure sign-off stored in the incident registry linked to BH-03.", "Re-anchor baseline after each planned model update; require new signed EvaluationBaseline from the evaluation team." ], "anti_patterns": [ "Using absolute metric targets rather than regression-from-baseline — breaks after model updates.", "Relying solely on latency as a proxy for model quality.", "Not versioning the EvaluationBaseline artifact — makes auditing impossible.", "Measuring only aggregate metrics — masks subgroup performance drops." ] }, "monitoring_schema": { "metric_objects": [ { "name": "primary_metric_regression_pct", "type": "regression_from_baseline", "description": "Percentage regression in the primary task metric relative to the signed EvaluationBaseline.", "alert_threshold_pct": 5, "critical_threshold_pct": 10, "unit": "percent", "metric_id": "primary_metric_regression_pct", "metric_type": "performance", "measure": "percentage-regression-from-baseline", "population": "all-production-inferences", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "calibration_ece", "type": "gauge", "description": "Expected Calibration Error of production probability outputs vs. baseline ECE.", "alert_threshold_delta_pct": 15, "unit": "absolute_error", "metric_id": "calibration_ece", "metric_type": "performance", "measure": "calibration-ece", "population": "all-production-inferences", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "latency_p95_ms", "type": "percentile", "description": "95th percentile inference latency vs. baseline p95.", "alert_threshold_delta_pct": 20, "unit": "milliseconds", "metric_id": "latency_p95_ms", "metric_type": "performance", "measure": "latency-percentile", "population": "all-production-inferences", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "subgroup_metric_regression_pct", "type": "regression_from_baseline", "description": "Worst-case regression across defined subgroup slices vs. baseline subgroup metrics.", "alert_threshold_pct": 7, "critical_threshold_pct": 15, "unit": "percent", "metric_id": "subgroup_metric_regression_pct", "metric_type": "performance", "measure": "percentage-regression-from-baseline", "population": "all-production-inferences", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" } ], "window_context": { "type": "sliding", "duration_hours": 24, "minimum_sample_size": 1000, "baseline_artifact": "EvaluationBaseline_v{model_version}" }, "sampling_rate": 1, "sampling_strategy": "full_population_with_stratified_subgroup_tracking" }, "validation": { "design_check": [ "EvaluationBaseline artifact is published, signed, and stored in the model registry at every release. [ref:nist_ai_rmf_1_0]", "Alert thresholds are documented as percentage-regression-from-baseline and reviewed by the model owner at minimum quarterly. [ref:iso_42001_2023]", "SR 26-2 requires performance benchmarks and monitoring thresholds be documented and reviewed annually. [ref:sr262_2026]", "Subgroup slice metrics are defined and included in the EvaluationBaseline artifact. [ref:eu_ai_act_2024]" ], "runtime_test": [ "{'test': 'Replay a degraded production stream (simulated 8% accuracy drop) and verify critical alert fires within one monitoring window.', 'ref': 'nist_rmf_1_0'} [ref:nist_ai_rmf_1_0]", "{'test': 'Verify that an EvaluationBaseline artifact with an invalid hash is rejected by the metrics comparison service.', 'unverified': True} [unverified]", "{'test': 'Confirm subgroup regression alerts fire independently of aggregate metric alerts.', 'unverified': True} [unverified]" ], "evidence": [ "model:evaluationbaseline-artifact-for-current — EvaluationBaseline artifact for current production model version. [ref:nist_ai_rmf_1_0]", "model:alert-log-for-trailing-90-days-with-root — Alert log for trailing 90 days with root cause and remediation records. [ref:sr262_2026]", "model:quarterly-threshold-review-sign-off-by-m — Quarterly threshold review sign-off by model owner. [ref:iso_42001_2023]" ] }, "lenses": { "engineering": "The metrics aggregation service must be independent of the inference serving path — a serving failure must not also disable performance monitoring.", "evaluation": "EvaluationBaseline artifact is the authoritative linkage between pre-release evaluation (EV layer) and production monitoring; evaluation team owns baseline publication.", "red_team": "Test whether adversarial inputs can selectively degrade subgroup performance while keeping aggregate metrics within alert thresholds.", "grc": "SR 26-2 and EU AI Act Art. 72 both require evidence of ongoing performance monitoring; EvaluationBaseline artifact and alert log are primary audit evidence.", "mlops": "Automate baseline re-anchoring as part of the deployment pipeline; require human sign-off before alerting thresholds are adjusted." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers performance metric regression alerting anchored to the release baseline. Feature drift driving performance loss is in BH-02. Pre-release performance evaluation is in EV-01.", "canonical_id": "apeiris://model/controls/BH-03", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. BH-03’s regression alerting monitors production performance against a signed EvaluationBaseline, satisfying the production-monitoring expectation for performance.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) requires operational monitoring. BH-03’s regression alerting against a signed EvaluationBaseline keeps release-time performance claims continuously verified.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "LOG-14", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CSA AICM LOG-14 (Failures and Anomalies) requires logging and alerting on failures and anomalous behavior. BH-03’s tiered performance-regression alerts against a signed EvaluationBaseline implement that anomaly detection for model quality.", "source_locator": { "control_id": "LOG-14" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "owasp_aitg", "requirement_id": "AITG-MOD-06", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AITG-MOD-06 (Testing for Robustness to New Data) concerns sustained performance on evolving data. BH-03's regression alerting against a signed EvaluationBaseline detects when production performance falls below the robustness this test verifies.", "source_locator": { "test_id": "AITG-MOD-06", "test_name": "Testing for Robustness to New Data" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-72", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 72 requires high-risk AI system providers to implement post-market monitoring covering performance evaluation; BH-03's performance regression alerting — tracking accuracy, AUC, and F1 against a signed performance baseline — directly operationalizes the performance monitoring component of a post-market monitoring plan.", "uncovered_portion": "Art. 72 requires a documented post-market monitoring plan with systematic anomaly identification, user feedback loops, and reporting obligations; BH-03 covers runtime metric alerting only and does not address fairness monitoring, serious incident reporting, or systematic anomaly reporting to authorities.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. V", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes ongoing monitoring of model performance and periodic comparison of results against expectations; BH-03's automated performance alerts provide the continuous monitoring layer that supports this expectation. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 applies to supervised banking organizations with $30B+ in assets. BH-03 does not cover SR 26-2's back-testing requirement against realized outcomes or qualitative assessment of model conceptual soundness.", "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "continuousvalidation", "fit": "supporting", "rationale": "Comparing live production metrics to a signed release baseline and alerting on regression is continuous validation of the deployed model.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0008", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every production model version must have a corresponding signed EvaluationBaseline…\" enacts ATLAS mitigation AML.M0008 Validate AI Model; OpenCRE crosswalks this control’s OWASP AI Exchange concept (continuousvalidation) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-72", "mapping_fit": "partial", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "Every production model version must have a corresponding signed EvaluationBaseline artifact containing primary task metrics and subgroup slice metrics from the release evaluation gate; the metrics aggregation service must continuously compare production estimates against this baseline and fire tiered alerts when primary metrics regress 5% (warning) or 10% (critical) from the signed baseline values, including independent subgroup regression alerts.", "evidence_required": [ "signed EvaluationBaseline artifact for the current production model version containing model_id, version, eval_date, primary_metrics with confidence intervals, subgroup slice metrics, eval_dataset_hash, and artifact SHA-256", "performance alert log for trailing 90 days with fields: alert_id, metric_name, regression_pct, severity, triggered_at, acknowledged_at, root_cause, and remediation_action for each alert", "quarterly threshold review sign-off from model owner confirming 5%/10% regression thresholds remain appropriate for the current model type and deployment context", "proxy_metric_registry documenting which proxy metrics substitute for labeled ground truth when unavailable, including calibration methodology and documented limitations" ], "machine_tests": [ "Replay a simulated production stream with an 8% regression in the primary task metric against the signed EvaluationBaseline → assert a critical alert fires within one 24-hour monitoring window with correct metric_name and regression_pct fields", "Load an EvaluationBaseline artifact with a tampered SHA-256 hash and start the metrics comparison service → assert the service rejects the artifact and raises an integrity alert before processing any production metrics", "Inject a 10% regression in one subgroup slice while keeping the aggregate primary metric within the 5% warning threshold → assert a subgroup_regression alert fires independently of any aggregate metric alert" ], "human_review": [ "Review the EvaluationBaseline artifact for the current production model to confirm it was published from the pre-release evaluation gate (EV layer) and was not manually constructed, back-dated, or derived from a different model version", "Assess whether the subgroup slice definitions in the EvaluationBaseline cover the population segments most relevant to fairness obligations and regulatory requirements for this model's specific use case", "Review the proxy_metric_registry for use cases where labeled ground truth is unavailable and confirm proxy metric calibration is documented, periodically validated, and reviewed at least annually" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Using absolute performance targets (e.g., accuracy > 85%) rather than percentage regression from the signed baseline — breaks comparison after model updates that legitimately shift baseline performance levels", "Measuring only aggregate model metrics without per-subgroup slice tracking — adversarial inputs or distribution shifts can degrade performance for specific demographic groups while keeping aggregate metrics within alert thresholds", "Not versioning the EvaluationBaseline artifact or not linking it to the model registry entry — makes historical performance comparison impossible and violates audit and regulatory evidence requirements", "Adjusting alert thresholds downward without human sign-off to suppress alerts during a known performance regression — disguises model degradation as an administrative operational decision" ], "update_status": "current", "layer_code": "BH" }, { "id": "BH-04", "layer": "BH", "plane": "data", "name": "Behavioral Boundary Performance Testing", "plain": "Measure how effectively the model's behavioral boundaries hold in production — Model Assurance quantifies boundary adherence rates and trends; detection and enforcement of violations is owned by securitycontrols.ai.", "threat": { "tags": [ "MR-PERFORMANCE", "LLM01:2025", "AML.T0051" ], "desc": "Behavioral boundaries (topic restrictions, capability limits, refusal policies) can erode due to model updates, new user populations, or adversarial pressure. Without measurement, boundary adherence is assumed rather than known. AML.T0051 (LLM Prompt Injection) is the primary vector exploiting boundary weaknesses." }, "standard": [ { "id": "nist_rmf", "ref": "MEASURE 2.7" }, { "id": "iso_42001", "ref": "A.6.2.6" }, { "id": "eu_ai_act", "ref": "Art. 9(1)(b), Art. 15" }, { "id": "aisvs", "ref": "C11.1 — Model Alignment, Safety, and Robustness Testing" } ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://doi.org/10.6028/NIST.AI.100-1", "source_type": "supervisory-guidance", "license": "public_domain", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/BH-04 Behavioral Boundary Performance Testing control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "source_type": "certification-standard", "license": "proprietary", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/BH-04 Behavioral Boundary Performance Testing control.", "reviewed_on": "2026-07-01" }, { "id": "mitre_atlas_v5_6_0", "authority": "MITRE", "title": "MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems", "url": "https://atlas.mitre.org", "source_type": "threat-knowledge-base", "license": "apache_2_0", "version": "5.6.0", "effective_date": "2026-05-04", "artifact_hash": null, "status": "current", "normative_force": "best-practice", "published_on": "2026-05-04", "retrieved_on": "2026-06-26", "source_id": "mitre_atlas", "relationship": "informative_reference", "rationale": "Establishes MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems requirements informing the apeiris://model/controls/BH-04 Behavioral Boundary Performance Testing control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_aisvs_v1", "authority": "OWASP", "title": "OWASP AI Security Verification Standard v1.0", "url": "https://github.com/OWASP/AISVS", "source_type": "voluntary-standard", "license": "CC-BY-SA-4.0", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2026-06-26", "retrieved_on": "2026-06-26", "source_id": "owasp_aisvs_v1", "relationship": "implementation_pattern", "rationale": "Establishes OWASP AI Security Verification Standard v1.0 requirements informing the apeiris://model/controls/BH-04 Behavioral Boundary Performance Testing control.", "reviewed_on": "2026-07-01", "canonical_url": "https://github.com/OWASP/AISVS" } ], "implementation": { "pattern": "Run a continuous behavioral boundary test harness against production model endpoints using a curated BoundaryTestSuite. Model Assurance measures and reports BoundaryAdherenceRate per category. securitycontrols.ai owns detection of active violations and enforcement response.", "steps": [ "Maintain a versioned BoundaryTestSuite: probe inputs per boundary category (topic restriction, capability limit, policy compliance, refusal boundary). Include novel adversarial formulations, not only published datasets.", "Schedule BoundaryTestSuite runs against the production endpoint: minimum daily; high-impact-decision and frontier-capability profiles: every 6 hours.", "Compute BoundaryAdherenceRate per category: (passing_probes / total_probes); track trend over a 30-day rolling window.", "Fire alerts: BoundaryAdherenceRate < 95% (warning), < 90% (critical). Route critical alerts to model owner and securitycontrols.ai cross-domain channel.", "Log all probe results — pass and fail — with probe_id, timestamp, model_version, response_hash; store in the evidence registry.", "When a boundary adherence drop is detected, notify securitycontrols.ai via the cross-domain alert channel for enforcement action. Model Assurance does NOT modify guardrails.", "Re-run BoundaryTestSuite as part of every pre-release evaluation gate (EV layer) to establish a new baseline." ], "anti_patterns": [ "Model Assurance modifying guardrail logic or enforcement rules — this is the securitycontrols.ai boundary; Model Assurance measures, Security enforces.", "Using only published probe inputs — probes must include novel adversarial formulations unavailable to the model's safety training.", "Running boundary tests only at release and not in production — misses post-release boundary drift.", "Sharing probe inputs publicly in a way that enables adversarial optimization." ] }, "cross_domain": { "domain": "securitycontrols.ai", "boundary_note": "Model Assurance (modelverifier.ai / BH-04) measures behavioral boundary adherence rates and trends. Detection of active boundary violations and enforcement responses (guardrail updates, blocking, rate limiting) are owned by securitycontrols.ai. BH-04 results are shared with securitycontrols.ai via the cross-domain alert channel. Neither domain modifies the other's controls without a formal governance handoff.", "navigation_pointer": "securitycontrols.ai > Runtime Enforcement layer > Guardrail Control", "evidence_artifact_pattern": "BoundaryTestResult_{model_id}_{date}.json written to both domain evidence registries" }, "validation": { "design_check": [ "BoundaryTestSuite is version-controlled and reviewed by model owner and security team at minimum quarterly. [ref:nist_ai_rmf_1_0]", "Cross-domain alert channel to securitycontrols.ai is documented and the measure-vs-enforce boundary is explicitly stated in the runbook. [ref:iso_42001_2023]", "BoundaryAdherenceRate alert thresholds (95% warning, 90% critical) are documented in the model health runbook. [ref:nist_ai_rmf_1_0]", "AISVS C11.1 (model alignment, safety, and robustness testing) boundary probe coverage requirements are mapped to BoundaryTestSuite categories. [ref:owasp_aisvs_v1]" ], "runtime_test": [ "{'test': 'Run the full BoundaryTestSuite in shadow mode and verify results are logged with correct probe_id linkage.', 'ref': 'nist_rmf_1_0'} [ref:nist_ai_rmf_1_0]", "{'test': 'Simulate boundary adherence drop to 88% in one category and verify critical alert fires and cross-domain notification is sent.', 'unverified': True} [unverified]", "{'test': 'Verify probe inputs are not accessible via any public API or logging endpoint.', 'ref': 'atlas_v560'} [ref:mitre_atlas_v5_6_0]" ], "evidence": [ "model:boundarytestsuite-artifact-with-version — BoundaryTestSuite artifact with version and review date. [ref:nist_ai_rmf_1_0]", "model:boundaryadherencerate-time-series-for-tr — BoundaryAdherenceRate time-series for trailing 90 days per boundary category. [ref:iso_42001_2023]", "model:cross-domain-alert-log-showing-securityc — Cross-domain alert log showing securitycontrols.ai notifications for boundary adherence drops. [unverified]" ] }, "lenses": { "engineering": "BoundaryTestSuite runner authenticates to the production endpoint as a dedicated test identity; results are isolated from real traffic logs.", "evaluation": "Evaluation team curates and updates the BoundaryTestSuite; novel adversarial probes from red team exercises must be added within 30 days of discovery.", "red_team": "Primary threat model: AML.T0051 (LLM Prompt Injection). Red team provides novel boundary probe inputs; exercises at minimum quarterly.", "grc": "EU AI Act Art. 9(1)(b) and Art. 15 require that high-risk AI achieve consistent performance across intended use conditions; BoundaryAdherenceRate is the measurable proxy.", "mlops": "BoundaryTestSuite runs are a deployment gate; new model versions must not regress vs. previous BoundaryAdherenceRate before reaching production." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers measurement of behavioral boundary adherence. Enforcement actions are owned by securitycontrols.ai. Injection-resistance measurement specifically is in BH-06.", "canonical_id": "apeiris://model/controls/BH-04", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "monitoring_schema": { "metrics": [ { "metric_id": "bh-04-pass-rate", "metric_type": "performance", "measure": "control-verification-pass-rate", "population": "all-assessed-deployments", "comparison": { "operator": "lt", "value": 1, "window": "7d", "evaluation_mode": "batch" }, "severity": "critical" } ], "sampling_rate": "100%", "window_context": "rolling-7d" }, "frameworks": [ { "framework": "nist_ai_600_1", "requirement_id": "INFO-SECURITY", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-04 monitors for prompt injection attempts and runtime adversarial activity against model systems. NIST AI 600-1 INFO-SECURITY covers adversarial prompt injection as a primary GenAI threat. This control contributes to the production monitoring component of information security risk management for GenAI deployments.", "uncovered_portion": "EV-04 (red-team evaluation) handles the pre-deployment adversarial testing component; BH-04 handles runtime detection only.", "source_version": "2024", "reviewed_on": "2026-06-26", "mapping_confidence": "medium", "provisional": true, "provisional_note": "NIST AI 600-1 GenAI Profile uses category-level identifiers (e.g., CONFABULATION, CBRN); action-level subcategory mapping was not possible from the category reference. Treat as category-level guidance only.", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_rmf", "requirement_id": "MEASURE-2.7", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.7 (MEASURE function) provides that AI system security and resilience are evaluated and documented. BH-04’s continuous BoundaryTestSuite keeps the security-and-resilience evaluation current in production rather than only at release.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) requires monitoring system behavior in operation. BH-04’s scheduled BoundaryTestSuite measures behavioral boundary adherence in production.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "TVM-13", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-04 runs a continuous BoundaryTestSuite against production inference endpoints, computing BoundaryAdherenceRate per behavioral boundary category and trending results over a 30-day rolling window, with critical alerts routed to both the model owner and securitycontrols.ai — directly implementing the measurement component of SEC-04's runtime behavioral security boundary testing requirement. Because this control quantifies boundary adherence from the Model Assurance perspective while enforcement and guardrail modification remain with the Security Verifier domain, the fit is partial.", "uncovered_portion": "SEC-04 covers the full behavioral security boundary enforcement regime including detection of active violations and enforcement mechanisms such as blocking and guardrail updates; BH-04 addresses only the measurement and quantification of boundary adherence from the Model Assurance perspective — enforcement infrastructure is owned by the Security Verifier domain.", "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "owasp_aitg", "requirement_id": "AITG-APP-05", "fit": "direct", "direction": "control-supports-requirement", "rationale": "AITG-APP-05 (Testing for Unsafe Outputs) probes whether a model emits outputs that violate its safety boundaries. BH-04's continuous BoundaryTestSuite computes BoundaryAdherenceRate per boundary category in production, directly operationalizing this test.", "source_locator": { "test_id": "AITG-APP-05", "test_name": "Testing for Unsafe Outputs" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-15", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 15 requires high-risk AI systems to be robust against attempts to manipulate outputs through adversarial inputs; BH-04's behavioral boundary enforcement — including guardrail compliance monitoring and injection-resistance metrics — supports the cybersecurity and robustness dimensions of Art. 15.", "uncovered_portion": "Art. 15 addresses the full robustness and cybersecurity design requirements; BH-04 covers boundary monitoring and enforcement at runtime but does not address the underlying system design, adversarial testing during development (covered by EV-04), or cybersecurity hardening of the deployment infrastructure.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "owasp_ai_exchange", "requirement_id": "continuousvalidation", "fit": "supporting", "rationale": "Daily boundary-adherence probing and trending in production is ongoing validation that the model still meets its behavioral requirements.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0008", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"A versioned BoundaryTestSuite must be executed at minimum daily against the production…\" enacts ATLAS mitigation AML.M0008 Validate AI Model; OpenCRE crosswalks this control’s OWASP AI Exchange concept (continuousvalidation) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-15", "mapping_fit": "partial", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "A versioned BoundaryTestSuite must be executed at minimum daily against the production inference endpoint, BoundaryAdherenceRate must be computed per boundary category and trended over a 30-day rolling window, and critical alerts plus cross-domain notifications to securitycontrols.ai must fire within one probe cycle when any category drops below 90% adherence — with all probe results logged in the evidence registry under BH-04 control linkage.", "evidence_required": [ "versioned BoundaryTestSuite artifact with probe categories covered, probe count per category, probe source documentation, and last review date signed by the model owner and security team", "BoundaryAdherenceRate time-series for trailing 90 days per boundary category, including probe_id, timestamp, model_version, response_hash, and pass/fail for each probe execution", "cross-domain alert log showing securitycontrols.ai notifications for adherence drops with triggered_at, affected_category, adherence_rate, and acknowledgment timestamp for each event in the trailing 90 days", "pre-release BoundaryTestSuite run results for the current production model version establishing the BoundaryAdherenceRate baseline at deployment" ], "machine_tests": [ "Run the full BoundaryTestSuite in shadow mode against the production endpoint → assert all probe results are logged with probe_id, timestamp, model_version, and pass/fail and appear in the evidence registry with BH-04 control linkage", "Simulate a BoundaryAdherenceRate drop to 88% in the topic-restriction category → assert a critical alert fires and a cross-domain notification is sent to securitycontrols.ai within one probe cycle (maximum 6 hours for high-impact profiles)", "Query the inference API and operational traffic logs for BoundaryTestSuite probe inputs → assert no probe input content is accessible or appears in any public-facing log endpoint or inference response payload" ], "human_review": [ "Review the BoundaryTestSuite for the current model version and confirm it includes novel adversarial formulations beyond published benchmark datasets in at least three distinct boundary categories, with sources documented", "Verify that the measure-versus-enforce boundary between Model Assurance and securitycontrols.ai is explicitly stated in the operational runbook and that the Model Assurance team has no access to modify guardrail logic, system prompts, or refusal filters", "Assess whether BoundaryTestSuite probe diversity is sufficient to detect post-update boundary drift and whether the quarterly refresh cadence produces enough novel inputs relative to the known threat model" ], "blocking_effect": "advisory", "normative_status": "certification-standard", "anti_patterns": [ "Model Assurance team modifying guardrail logic, system prompts, or refusal filters in response to BoundaryAdherenceRate drops — enforcement authority belongs to securitycontrols.ai and all boundary changes require a formal cross-domain governance handoff", "Using only published open-source adversarial datasets as the sole source of probe inputs — models may be safety-fine-tuned against known datasets while remaining vulnerable to novel adversarial formulations", "Running the BoundaryTestSuite only at model release and not continuously in production — post-release fine-tuning, prompt injection pressure, or new tool integrations can erode behavioral boundaries without detection", "Logging BoundaryTestSuite probe inputs in the same pipeline as operational traffic — exposes probe library contents to adversarial discovery and contaminates operational metrics with synthetic traffic", "Applying a single uniform BoundaryAdherenceRate threshold across all boundary categories — safety-critical categories such as CBRN and CSAM require near-zero tolerance thresholds rather than the 90% general-use floor" ], "update_status": "current", "layer_code": "BH" }, { "id": "BH-05", "layer": "BH", "plane": "data", "name": "Usage Telemetry and Decision Logging", "plain": "Log every model inference with caller identity, masked/hashed inputs, sampled outputs, and latency — creating a tamper-evident audit trail for incident response, regulatory audit, and model improvement — while enforcing a retention policy that protects user privacy.", "threat": { "tags": [ "MR-MONITORING", "AML.T0024", "EU-AIA-AnnexIII" ], "desc": "Without structured decision logging, AI-driven decisions cannot be audited, contested, or investigated. Missing telemetry prevents detection of misuse patterns, bulk inference for model extraction (AML.T0024), and accountability gaps in high-impact decisions." }, "standard": [ { "id": "nist_rmf", "ref": "GOVERN 1.2, MANAGE 4.1" }, { "id": "iso_42001", "ref": "Clause 7.5" }, { "id": "eu_ai_act", "ref": "Art. 12, Art. 26(5), Annex III" }, { "id": "sr262", "ref": "Sec. VI — Governance and Controls (documentation and records)", "section": "Sec. VI", "title": "Governance and controls — documentation and records" }, { "id": "aicm", "ref": "LOG-07" } ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://doi.org/10.6028/NIST.AI.100-1", "source_type": "supervisory-guidance", "license": "public_domain", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/BH-05 Usage Telemetry and Decision Logging control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "source_type": "certification-standard", "license": "proprietary", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/BH-05 Usage Telemetry and Decision Logging control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Revised Guidance on Model Risk Management", "source_type": "supervisory-guidance", "license": "public_domain", "supersedes": [ "SR 11-7", "SR 21-8" ], "artifact_hash": null, "status": "current", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/BH-05 Usage Telemetry and Decision Logging control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "authority": "European Parliament and Council", "title": "EU AI Act (Regulation (EU) 2024/1689)", "source_type": "regulation", "license": "public_domain", "artifact_hash": null, "effective_dates": { "standalone_high_risk": "2027-12-02", "product_embedded": "2028-08-02" }, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) requirements informing the apeiris://model/controls/BH-05 Usage Telemetry and Decision Logging control.", "reviewed_on": "2026-07-01" }, { "id": "mitre_atlas_v5_6_0", "authority": "MITRE", "title": "MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems", "url": "https://atlas.mitre.org", "source_type": "threat-knowledge-base", "license": "apache_2_0", "version": "5.6.0", "effective_date": "2026-05-04", "artifact_hash": null, "status": "current", "normative_force": "best-practice", "published_on": "2026-05-04", "retrieved_on": "2026-06-26", "source_id": "mitre_atlas", "relationship": "informative_reference", "rationale": "Establishes MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems requirements informing the apeiris://model/controls/BH-05 Usage Telemetry and Decision Logging control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Instrument every model inference endpoint to emit a structured DecisionLog record. Apply three-tier logging: full metadata always logged; inputs masked/hashed before logging; outputs sampled at a configurable rate. Enforce tiered retention aligned to regulatory requirements.", "steps": [ "Define the DecisionLog schema: {log_id, model_id, model_version, timestamp_utc, caller_id, session_id, input_hash (HMAC-SHA-256), input_sensitivity_tier, output_sample (at sampling rate), output_hash, latency_ms, inference_cost_tokens, decision_outcome, confidence_score, flags[]}.", "Apply input masking: strip direct identifiers before logging; hash PII fields using HMAC-SHA-256 with a key-per-tenant stored in the key management system.", "Implement deterministic output sampling: 10% default; 100% for high-impact-decision profile; output samples encrypted at rest.", "Enforce retention tiers: raw inference logs 90 days; aggregated anonymized logs 3 years; EU high-risk AI deployments minimum 10 years per Art. 12.", "Make logs tamper-evident: append-only store; compute a daily Merkle tree root hash and publish to a separate tamper-evident log.", "Expose a DecisionLog query API to model owner, compliance team, and authorized regulators; all access logged for access audit trail.", "Enrich caller_id to human-readable identity (service name, user role) at log time; never log raw auth tokens." ], "anti_patterns": [ "Logging raw user inputs containing PII — creates GDPR liability and breach risk.", "Logging all outputs without sampling at high volume — uneconomical and may expose model internals.", "Using a mutable logging store — allows log tampering, defeating the audit purpose.", "Not logging caller identity — makes attribution impossible during incident response.", "Logging only errors — misses the normal baseline needed for anomaly detection." ] }, "obligations": [ { "id": "eu-aia-art12-logging", "text": "EU AI Act Art. 12: high-risk AI systems must automatically log events; logs must be kept for the period prescribed by applicable sectoral law (minimum 6 months unless law requires longer).", "jurisdiction": [ "eu" ], "binding": true, "normative_force": "binding-law", "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "legal_status": "enacted", "provision": "Article 12", "effective_from": "2027-12-02" }, { "id": "eu-aia-art26-deployer-logs", "text": "EU AI Act Art. 26(5): deployers of high-risk AI systems must keep the automatically generated logs for the prescribed period and make them available to national competent authorities on request.", "jurisdiction": [ "eu" ], "binding": true, "normative_force": "binding-law", "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "legal_status": "enacted", "provision": "Article 26", "effective_from": "2027-12-02" }, { "id": "sr262-documentation-records", "text": "SR 26-2 Section IV.D: model documentation and records must support ongoing monitoring, audit, and supervisory examination for banking organizations with total assets over $30B.", "jurisdiction": [ "us" ], "binding": false, "normative_force": "supervisory-guidance", "reviewed_on": "2026-06-26", "authority": "Federal Reserve System", "instrument": "SR 26-2", "source_ref": "sr262_2026", "legal_status": "enacted", "provision": "SR 26-2" }, { "id": "gdpr-art5-data-minimization", "text": "GDPR Art. 5(1)(e): storage limitation principle — logged personal data must be anonymized, pseudonymized, or deleted when no longer necessary for the stated purpose. Inference logs containing personal data require a legal basis and retention schedule.", "jurisdiction": [ "eu" ], "binding": true, "normative_force": "binding-law", "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2016/679", "source_ref": "gdpr", "legal_status": "enacted", "provision": "Article 5", "effective_from": "2018-05-25" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-12", "mapping_fit": "direct", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "profiles": [ "high-impact-decision", "eu-high-risk", "us-regulated-banking" ], "validation": { "design_check": [ "DecisionLog schema is documented and includes all required fields: input_hash, caller_id, model_version, latency_ms. [ref:nist_ai_rmf_1_0]", "Input masking pipeline is reviewed by the privacy team; no direct PII fields appear in stored logs. [ref:eu_ai_act_2024]", "Retention tiers are documented and configured in log storage, aligned to Art. 12 for EU high-risk deployments. [ref:eu_ai_act_2024]", "SR 26-2 records requirement: DecisionLog configuration is included in the model risk documentation. [ref:sr262_2026]", "Tamper-evident mechanism (Merkle tree or equivalent) is designed and daily root hash publication is documented. [ref:eu_ai_act_2024]" ], "runtime_test": [ "{'test': 'Issue 100 test inferences and verify all 100 DecisionLog records appear with correct fields and no raw PII.', 'ref': 'nist_rmf_1_0'} [ref:nist_ai_rmf_1_0]", "{'test': 'Attempt to modify a historical log record and verify the tamper-evident mechanism raises an integrity alert.', 'unverified': True} [unverified]", "{'test': 'Verify output sampling rate (10% default; 100% for high-impact-decision profile) is correctly applied.', 'unverified': True} [unverified]", "{'test': 'Verify caller_id resolves to human-readable identity; no raw auth tokens in logs.', 'ref': 'atlas_v560'} [ref:mitre_atlas_v5_6_0]" ], "evidence": [ "model:decisionlog-schema-documentation-with-fi — DecisionLog schema documentation with field definitions and masking policy. [ref:nist_ai_rmf_1_0]", "model:privacy-review-sign-off-confirming-no-di — Privacy review sign-off confirming no direct PII in stored logs. [ref:eu_ai_act_2024]", "model:retention-policy-configuration-and-autom — Retention policy configuration and automated deletion audit log. [ref:iso_42001_2023]", "model:daily-merkle-root-hash-publication-log-f — Daily Merkle root hash publication log for trailing 90 days. [unverified]" ] }, "lenses": { "engineering": "Log emission must be async and non-blocking; inference latency must not increase due to logging. Use a write-ahead log pattern with a dedicated logging service.", "evaluation": "DecisionLogs feed the continuous evaluation pipeline — sampled outputs are scored by the evaluation harness to estimate production performance.", "red_team": "Test whether the output sampling pattern can be inferred and exploited by an adversary to prefer outputs that appear in the log.", "grc": "EU AI Act Art. 12 and SR 26-2 both require structured logging; BH-05 is the primary control satisfying both obligations. Obligations mapping must be documented.", "mlops": "DecisionLog volume must be budgeted in infrastructure cost; log ingestion pipeline SLA must be monitored separately from model serving SLA." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers inference-level telemetry and decision logging. Session-level behavioral analytics for security purposes are owned by securitycontrols.ai. Drift monitoring using logged data is in BH-02.", "canonical_id": "apeiris://model/controls/BH-05", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "monitoring_schema": { "metrics": [ { "metric_id": "bh-05-pass-rate", "metric_type": "performance", "measure": "control-verification-pass-rate", "population": "all-assessed-deployments", "comparison": { "operator": "lt", "value": 1, "window": "7d", "evaluation_mode": "batch" }, "severity": "critical" } ], "sampling_rate": "100%", "window_context": "rolling-7d" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-1.2 (GOVERN function) provides that the characteristics of trustworthy AI are integrated into organizational policies, processes, and practices. BH-05’s tamper-evident DecisionLog gives accountability and transparency — trustworthy-AI characteristics this subcategory integrates into organizational policy — an enforceable runtime record for every inference.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "7.5", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-05 implements structured documented information controls for AI inference records — including a defined schema, HMAC-SHA-256 input masking, tiered retention aligned to EU AI Act Art. 12 obligations, and a daily Merkle tree tamper-evidence mechanism — directly satisfying ISO 42001 Clause 7.5's requirement for documented information necessary for the effectiveness of the AI management system. Clause 9.1 is additionally relevant because DecisionLogs provide the raw telemetry foundation for the operational monitoring and measurement activities implemented by BH-01 through BH-04.", "uncovered_portion": "Clause 7.5 encompasses the full documented information lifecycle including governance policies, risk assessment records, and management system procedures; BH-05 covers only inference-level decision logging and does not address broader documented information requirements such as management decisions or policy documentation.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "LOG-07", "fit": "direct", "direction": "control-supports-requirement", "rationale": "BH-05 instruments every model inference endpoint to emit a structured DecisionLog record capturing caller identity, HMAC-masked inputs, sampled outputs, latency, and decision outcomes, stored in a tamper-evident append-only store with daily Merkle tree root hash publication — directly implementing MON-04's AI system usage telemetry, decision logging, and audit trail requirement. The control's tiered retention schedules, access-controlled query API, and PII masking pipeline provide the privacy-safe, regulatory-ready logging infrastructure that MON-04 requires across deployment profiles.", "source_locator": { "section": "Monitoring and Alerting" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-12", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 12 requires high-risk AI systems to have the capability to automatically generate logs of operation; BH-05 directly implements this by mandating structured log emission for every inference — capturing input hash, output hash, decision path, confidence score, and latency — with 7-year retention using WORM-locked storage and a structured schema. Art. 16(h) additionally requires providers to keep automatically generated logs.", "uncovered_portion": "Art. 12(1) specifies logs must enable post-market monitoring and detection of risks; BH-05 covers operational logging but does not address Art. 12(2)'s requirement that logging capabilities align with the intended purpose and the risk level of the AI system.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "source_locator": { "section": "Art. 12 — Record-keeping" }, "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. VI", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. VI (Governance and Controls) describes documentation sufficient to support ongoing monitoring, audit, and supervisory examination; BH-05's structured decision audit trail supplies inference-level records that strengthen that documentation. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 applies to supervised banking organizations with $30B+ in assets. BH-05 addresses technical log capture only; SR 26-2 §IV.D also requires documentation of model theory, design choices, and validation results which are addressed by the EV and OA layers.", "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "monitoruse", "fit": "supporting", "rationale": "Per-inference decision logging with caller identity and tamper-evident storage is the audit-trail substrate of the monitor-model-use control.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0024", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every model inference endpoint must emit a structured DecisionLog record containing…\" enacts ATLAS mitigation AML.M0024 AI Telemetry Logging; OpenCRE crosswalks this control’s OWASP AI Exchange concept (monitoruse) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "validation_objective": "Every model inference endpoint must emit a structured DecisionLog record containing input_hash (HMAC-SHA-256), caller_id, model_version, output_sample at the configured sampling rate, latency_ms, and decision_outcome; logs must be stored in an append-only tamper-evident store with daily Merkle root hash publication; and no direct PII must appear in any stored log field.", "evidence_required": [ "DecisionLog schema documentation with field definitions, HMAC masking policy, key management system references, and output sampling rate configuration per deployment profile", "privacy review sign-off from the data protection team confirming no direct PII identifiers appear in stored log records, based on a regex scan of a trailing 30-day sample", "daily Merkle root hash publication log for trailing 90 days with fields: root_hash, computation_timestamp, and publication_destination for each daily entry", "retention policy configuration and automated deletion audit log confirming tiered retention enforcement (90-day raw, 3-year aggregated, 10-year minimum for EU high-risk deployments)", "DecisionLog query access audit trail for trailing 90 days showing all access events with requester_id, query_timestamp, and authorization_basis" ], "machine_tests": [ "Issue 100 test inferences against the instrumented endpoint and query the DecisionLog store → assert all 100 records appear with required fields: log_id, model_id, model_version, timestamp_utc, caller_id, input_hash, latency_ms, and output_hash", "Attempt to modify a historical DecisionLog record directly in the backing store → assert the daily Merkle root hash integrity check detects the modification and raises a tamper alert within 24 hours", "Issue inferences under the high-impact-decision profile and query DecisionLog records → assert output_sample is populated in 100% of records rather than the 10% default sampling rate", "Scan 50 stored DecisionLog records using PII regex patterns for email address, SSN, phone number, and full name → assert zero direct identifier matches are found in any stored field" ], "human_review": [ "Review the HMAC-SHA-256 key management configuration to confirm input hashing keys are per-tenant, rotated per the documented rotation policy, and stored in the designated key management system — not hardcoded in application configuration", "Assess inference latency impact by comparing p99 latency for the logging-instrumented endpoint against an uninstrumented baseline, confirming that logging adds no more than 5ms at p99 under peak production load", "Verify that the DecisionLog query API access control policy restricts access to model owner, compliance team, and authorized regulators only, and that all query access events are written to a separate access audit trail" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Logging raw user input text without passing through the HMAC-SHA-256 masking pipeline — creates GDPR Art. 5 liability and exposure in the event of a log store breach", "Using a mutable logging store with DELETE or UPDATE permissions available to application accounts — allows log tampering, defeating the tamper-evidence requirement that EU AI Act Art. 12 and audit obligations demand", "Not logging caller_id or resolving it to a human-readable identity at log time — makes attribution impossible during incident response and violates regulatory accountability requirements", "Logging all inference outputs at 100% rate without an approved sampling policy at high volume — uneconomical at scale and may expose model internals through systematic output accumulation", "Applying a single 90-day retention period to all deployments regardless of regulatory profile — EU AI Act Art. 12 high-risk deployments require minimum 10-year retention and US regulated banking contexts require SR 26-2 documentation periods" ], "update_status": "current", "layer_code": "BH" }, { "id": "BH-06", "layer": "BH", "plane": "data", "name": "Injection-Resistance Evaluation in Production", "plain": "Continuously measure the production model's resistance to prompt injection and adversarial input attacks using a structured probe suite; Model Assurance owns measurement and scoring; securitycontrols.ai owns detection and blocking of actual production attacks.", "threat": { "tags": [ "LLM01:2025", "AML.T0051", "MR-PERFORMANCE" ], "desc": "Prompt injection (LLM01:2025, AML.T0051) is the leading attack vector against deployed language models. Models that resisted injection at evaluation time can become more vulnerable after fine-tuning updates, context window changes, or new tool integrations. Production measurement of injection resistance is distinct from one-time red-team exercises." }, "standard": [ { "id": "nist_rmf", "ref": "MEASURE 2.7" }, { "id": "iso_42001", "ref": "Clause 6.1" }, { "id": "eu_ai_act", "ref": "Art. 9(1)(b), Art. 15" }, { "id": "aisvs", "ref": "C2.1 — Prompt Injection Defenses; C11.1 — Adversarial Robustness Testing" }, { "id": "llm10", "ref": "LLM01:2025" } ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://doi.org/10.6028/NIST.AI.100-1", "source_type": "supervisory-guidance", "license": "public_domain", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/BH-06 Injection-Resistance Evaluation in Production control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_llm10_2025", "authority": "OWASP", "title": "OWASP Top 10 for LLM Applications 2025", "url": "https://owasp.org/www-project-top-10-for-large-language-model-applications/", "source_type": "voluntary-standard", "license": "CC-BY-SA-4.0", "version": "2025", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "published_on": "2024-11-17", "retrieved_on": "2026-06-26", "source_id": "owasp_llm10", "relationship": "implementation_pattern", "rationale": "Establishes OWASP Top 10 for LLM Applications 2025 requirements informing the apeiris://model/controls/BH-06 Injection-Resistance Evaluation in Production control.", "reviewed_on": "2026-07-01" }, { "id": "mitre_atlas_v5_6_0", "authority": "MITRE", "title": "MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems", "url": "https://atlas.mitre.org", "source_type": "threat-knowledge-base", "license": "apache_2_0", "version": "5.6.0", "effective_date": "2026-05-04", "artifact_hash": null, "status": "current", "normative_force": "best-practice", "published_on": "2026-05-04", "retrieved_on": "2026-06-26", "source_id": "mitre_atlas", "relationship": "informative_reference", "rationale": "Establishes MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems requirements informing the apeiris://model/controls/BH-06 Injection-Resistance Evaluation in Production control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_aisvs_v1", "authority": "OWASP", "title": "OWASP AI Security Verification Standard v1.0", "url": "https://github.com/OWASP/AISVS", "source_type": "voluntary-standard", "license": "CC-BY-SA-4.0", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2026-06-26", "retrieved_on": "2026-06-26", "source_id": "owasp_aisvs_v1", "relationship": "implementation_pattern", "rationale": "Establishes OWASP AI Security Verification Standard v1.0 requirements informing the apeiris://model/controls/BH-06 Injection-Resistance Evaluation in Production control.", "reviewed_on": "2026-07-01", "canonical_url": "https://github.com/OWASP/AISVS" }, { "id": "nist_ai_100_2", "title": "NIST AI 100-2e2025 — Adversarial ML Taxonomy", "authority": "National Institute of Standards and Technology", "source_type": "standards-body", "normative_force": "informative-reference", "version": "100-2e2025", "published_on": "2025-03-20", "retrieved_on": "2026-07-08", "canonical_url": "https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf", "relationship": "supporting_guidance", "note": "NIST AI 100-2 Prompt Injection (NISTAML.018) grounds this injection-resistance evaluation." } ], "implementation": { "pattern": "Operate a continuous InjectionProbeLibrary that runs structured adversarial inputs against the production endpoint on a scheduled basis. Compute InjectionResistanceScore per attack category. Publish scores to the model health dashboard and notify securitycontrols.ai when scores degrade. Detection and blocking remain with securitycontrols.ai.", "steps": [ "Maintain a versioned InjectionProbeLibrary organized by attack category: direct prompt injection, indirect injection via context, jailbreak, role confusion, instruction override. Source probes from red team exercises, published datasets, and MITRE ATLAS AML.T0051 patterns.", "Schedule InjectionProbeLibrary runs against the production endpoint: every 6 hours for generative-ai and frontier-capability profiles; daily for others. Run from a dedicated probe identity filtered from operational metrics.", "Compute InjectionResistanceScore = (probes_resisted / total_probes) per attack category; track trend over a 30-day rolling window.", "Alert when InjectionResistanceScore drops below 90% in any category (warning) or 80% (critical). Route critical alerts to model owner and securitycontrols.ai.", "For novel injection techniques discovered in production (via securitycontrols.ai alert), add a corresponding probe to InjectionProbeLibrary within 30 days.", "Do NOT implement blocking or guardrail updates in this control — all enforcement routed to securitycontrols.ai via the cross-domain alert channel.", "Publish monthly InjectionResistanceScore trend reports to the governance board." ], "anti_patterns": [ "Model Assurance implementing blocking rules or guardrail modifications — enforcement is owned by securitycontrols.ai.", "Using only publicly known injection probes — models may resist published datasets while remaining vulnerable to novel variants.", "Running probe suite so infrequently that resistance degradation is detected days after it occurs.", "Publishing probe library contents in a way that enables adversarial optimization against them." ] }, "cross_domain": { "domain": "securitycontrols.ai", "boundary_note": "Model Assurance (modelverifier.ai / BH-06) measures injection resistance via structured probe suites and publishes InjectionResistanceScore metrics. Detection of actual injection attacks in production traffic and enforcement responses (blocking, rate limiting, guardrail updates) are owned exclusively by securitycontrols.ai. BH-06 feeds measurement data to securitycontrols.ai; securitycontrols.ai feeds novel attack patterns back to the InjectionProbeLibrary. Neither domain implements the other's controls.", "navigation_pointer": "securitycontrols.ai > Runtime Enforcement layer > Injection Defense Control", "evidence_artifact_pattern": "InjectionResistanceScore_{model_id}_{date}.json shared to both domain registries; novel_attack_patterns fed back from securitycontrols.ai to InjectionProbeLibrary" }, "validation": { "design_check": [ "InjectionProbeLibrary is version-controlled and includes probes from at least three attack categories (direct, indirect, jailbreak). [ref:mitre_atlas_v5_6_0]", "Cross-domain alert channel to securitycontrols.ai is documented and the measure-vs-enforce boundary is explicitly stated in the runbook. [ref:nist_ai_rmf_1_0]", "InjectionResistanceScore thresholds (90% warning, 80% critical) are documented. [ref:nist_ai_rmf_1_0]", "AISVS C2.1 (prompt injection defenses) and C11.1 (adversarial robustness testing) probe coverage requirements are mapped to InjectionProbeLibrary categories. [ref:owasp_aisvs_v1]" ], "runtime_test": [ "{'test': 'Run the full InjectionProbeLibrary against the production endpoint and verify InjectionResistanceScore is computed and published to the health dashboard.', 'ref': 'atlas_v560'} [ref:mitre_atlas_v5_6_0]", "{'test': 'Simulate resistance drop to 78% in the jailbreak category and verify critical alert fires and cross-domain notification is sent.', 'unverified': True} [unverified]", "{'test': 'Verify probe runs do not appear in operational traffic metrics (probe identity correctly filtered).', 'unverified': True} [unverified]" ], "evidence": [ "model:injectionprobelibrary-artifact-with-vers — InjectionProbeLibrary artifact with version, category coverage, and last review date. [ref:mitre_atlas_v5_6_0]", "model:injectionresistancescore-time-series-for — InjectionResistanceScore time-series for trailing 90 days per attack category. [ref:owasp_llm10_2025]", "model:cross-domain-alert-log-showing-securityc — Cross-domain alert log showing securitycontrols.ai notifications. [unverified]", "model:monthly-injectionresistancescore-trend-r — Monthly InjectionResistanceScore trend report to governance board. [ref:nist_ai_rmf_1_0]" ] }, "lenses": { "engineering": "Probe runner uses a separate credential from production users; probe inputs must be syntactically indistinguishable from real inputs to test actual production behavior.", "evaluation": "InjectionResistanceScore is a first-class model health metric alongside accuracy and latency; evaluation team updates probe library after each red team exercise.", "red_team": "Primary threat model: AML.T0051 (LLM Prompt Injection) and OWASP LLM01:2025. Red team provides novel probe inputs; exercises at minimum quarterly.", "grc": "EU AI Act Art. 15 requires robustness against manipulation attempts; InjectionResistanceScore is the measurable evidence artifact for this obligation.", "mlops": "InjectionProbeLibrary runs are a deployment gate; new model versions must not regress vs. previous InjectionResistanceScore before reaching production." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers measurement of injection resistance. Actual attack detection and blocking are owned by securitycontrols.ai. General behavioral boundary adherence is in BH-04. Pre-release adversarial evaluation is in EV-06 and EV-07.", "canonical_id": "apeiris://model/controls/BH-06", "capability_risk": { "capability_level": "elevated", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "monitoring_schema": { "metrics": [ { "metric_id": "bh-06-pass-rate", "metric_type": "performance", "measure": "control-verification-pass-rate", "population": "all-assessed-deployments", "comparison": { "operator": "lt", "value": 1, "window": "7d", "evaluation_mode": "batch" }, "severity": "critical" } ], "sampling_rate": "100%", "window_context": "rolling-7d" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.7", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.7 (MEASURE function) provides that AI system security and resilience are evaluated and documented. BH-06’s scheduled injection-probe runs measure prompt-injection resilience of the production endpoint, extending security evaluation into operation.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) requires operational monitoring; BH-06’s scheduled injection-probe runs monitor the production endpoint’s injection resistance.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "AIS-09", "fit": "direct", "direction": "control-supports-requirement", "rationale": "BH-06 implements a continuous production probe suite that measures prompt injection resistance and adversarial input failure rates against live model endpoints. SEC-03 requires adversarial and security testing of AI systems in production contexts; BH-06 directly satisfies this by running structured injection probes, recording failure rates, and triggering remediation workflows when resistance degrades below threshold.", "source_locator": { "section": "Security Controls and Adversarial Testing" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "owasp_aitg", "requirement_id": "AITG-APP-01", "fit": "direct", "direction": "control-supports-requirement", "rationale": "AITG-APP-01 (Testing for Prompt Injection) probes whether crafted inputs can override system instructions. BH-06's runtime injection detection and scheduled InjectionProbeLibrary runs execute this test continuously against the production endpoint.", "source_locator": { "test_id": "AITG-APP-01", "test_name": "Testing for Prompt Injection" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-55", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 55(1)(d) requires providers of GPAI models with systemic risk to ensure adequate cybersecurity protections; BH-06's prompt injection detection and adversarial input monitoring operationalizes the continuous cybersecurity assurance dimension for GPAI systems. Art. 15 additionally requires high-risk AI systems to be robust against attempts to alter outputs through adversarial inputs.", "uncovered_portion": "Art. 55 addresses the full cybersecurity obligation for GPAI systemic risk providers; BH-06 covers monitoring and detection of injection attempts but not the underlying model hardening, responsible disclosure processes, or cybersecurity incident reporting obligations.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "owasp_ai_exchange", "requirement_id": "promptinjectioniohandling", "fit": "supporting", "rationale": "Continuously probing production injection resistance and scoring direct/indirect/jailbreak categories measures the effectiveness of prompt-injection I/O handling.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0015", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"A versioned InjectionProbeLibrary covering at least three attack categories (direct…\" enacts ATLAS mitigation AML.M0015 Adversarial Input Detection; OpenCRE crosswalks this control’s OWASP AI Exchange concept (promptinjectioniohandling) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "gpai_model_systemic_risk" ], "classification": [ "gpai-systemic-risk" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2025-08-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-55", "mapping_fit": "partial", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "A versioned InjectionProbeLibrary covering at least three attack categories (direct prompt injection, indirect context injection, and jailbreak) must execute against the production model endpoint at minimum every 6 hours for generative-ai and frontier-capability profiles; InjectionResistanceScore must be computed per category and published to the model health dashboard; and any category score dropping below 90% must trigger a warning alert and cross-domain notification to securitycontrols.ai within one probe cycle.", "evidence_required": [ "versioned InjectionProbeLibrary artifact with attack categories covered, probe count per category, sourcing documentation (red team exercises, MITRE ATLAS AML.T0051, published datasets), and last review date", "InjectionResistanceScore time-series for trailing 90 days per attack category with probe_id, timestamp, model_version, and pass/fail result for each probe execution", "cross-domain alert log showing securitycontrols.ai notifications for resistance score drops with triggered_at, attack_category, score_at_trigger, and acknowledgment timestamp for each event", "monthly InjectionResistanceScore trend report to the governance board showing 30-day rolling score per category, trend direction, and any model versions where scores regressed", "deployment gate certification records for the current production model version confirming InjectionResistanceScore at or above the 90% threshold at time of release across all probe categories" ], "machine_tests": [ "Run the full InjectionProbeLibrary against the production endpoint using the dedicated probe identity → assert InjectionResistanceScore is computed per attack category and published to the health dashboard within one probe cycle", "Simulate a jailbreak category InjectionResistanceScore drop to 78% → assert a critical alert fires and a cross-domain notification is sent to securitycontrols.ai within 15 minutes of the probe cycle completing", "Query the inference API and operational traffic logs for probe input content from the InjectionProbeLibrary → assert all probe run records show the dedicated probe identity and no probe input content is accessible via any production-facing interface", "Attempt to access the production endpoint for a new model version before the InjectionProbeLibrary deployment gate run is marked complete → assert deployment access is blocked until a gate run result is recorded with sign-off" ], "human_review": [ "Review the InjectionProbeLibrary for the current quarter and confirm it contains at least 10 novel adversarial probe inputs added from red team exercises or securitycontrols.ai attack pattern feedback within the last 90 days", "Assess the cross-domain boundary documentation to confirm Model Assurance has no access to securitycontrols.ai enforcement mechanisms (blocking rules, guardrail updates, rate limits) and that the alert routing path is strictly one-directional", "Verify that the deployment gate records for the current production model show InjectionResistanceScore at or above the 90% warning threshold at time of release across all defined probe categories" ], "blocking_effect": "blocks-deployment", "normative_status": "voluntary-standard", "anti_patterns": [ "Model Assurance implementing blocking rules, rate limits, or guardrail modifications in response to injection resistance findings — enforcement authority is exclusively with securitycontrols.ai and cross-domain protocol requires a formal governance handoff", "Relying solely on publicly published injection datasets (e.g., AdvBench, HarmBench) as the only probe source — models may be fine-tuned against published adversarial sets while remaining vulnerable to novel injection variants not in those datasets", "Running the InjectionProbeLibrary only at model release time and not in continuous production — post-release fine-tuning updates, context window expansions, or new tool integrations can re-introduce injection vulnerabilities that the release gate did not detect", "Publishing InjectionProbeLibrary contents in technical documentation or making them accessible via any API endpoint — exposure enables adversarial optimization specifically targeting the known probe inputs", "Applying the same InjectionResistanceScore thresholds (90% warning, 80% critical) uniformly to a low-stakes classification model and a GPAI systemic-risk model — frontier capability and systemic risk profiles require stricter thresholds and shorter probe intervals" ], "update_status": "current", "layer_code": "BH" }, { "id": "BH-07", "layer": "BH", "plane": "data", "name": "Resource and Cost Anomaly Monitoring", "plain": "Monitor compute spend, token consumption, and API call volume in real time; detect cost spikes that may indicate abuse, runaway automation, or adversarial resource exhaustion before they cause material financial or operational harm.", "threat": { "tags": [ "MR-MONITORING", "AML.T0024", "LLM10:2025" ], "desc": "Uncontrolled resource consumption through abuse, compromised API keys, runaway agents, or adversarial resource exhaustion causes significant financial harm and service degradation. Sudden cost spikes may also indicate bulk inference for model extraction (AML.T0024) where an adversary runs high-volume queries to steal model knowledge." }, "standard": [ { "id": "nist_rmf", "ref": "MANAGE 2.4" }, { "id": "iso_42001", "ref": "Clause 7.1" }, { "id": "aisvs", "ref": "C12.2 — Detection and Alerting (resource budgets)" }, { "id": "llm10", "ref": "LLM10:2025" } ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://doi.org/10.6028/NIST.AI.100-1", "source_type": "supervisory-guidance", "license": "public_domain", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/BH-07 Resource and Cost Anomaly Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_llm10_2025", "authority": "OWASP", "title": "OWASP Top 10 for LLM Applications 2025", "url": "https://owasp.org/www-project-top-10-for-large-language-model-applications/", "source_type": "voluntary-standard", "license": "CC-BY-SA-4.0", "version": "2025", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "published_on": "2024-11-17", "retrieved_on": "2026-06-26", "source_id": "owasp_llm10", "relationship": "implementation_pattern", "rationale": "Establishes OWASP Top 10 for LLM Applications 2025 requirements informing the apeiris://model/controls/BH-07 Resource and Cost Anomaly Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "mitre_atlas_v5_6_0", "authority": "MITRE", "title": "MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems", "url": "https://atlas.mitre.org", "source_type": "threat-knowledge-base", "license": "apache_2_0", "version": "5.6.0", "effective_date": "2026-05-04", "artifact_hash": null, "status": "current", "normative_force": "best-practice", "published_on": "2026-05-04", "retrieved_on": "2026-06-26", "source_id": "mitre_atlas", "relationship": "informative_reference", "rationale": "Establishes MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems requirements informing the apeiris://model/controls/BH-07 Resource and Cost Anomaly Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_aisvs_v1", "authority": "OWASP", "title": "OWASP AI Security Verification Standard v1.0", "url": "https://github.com/OWASP/AISVS", "source_type": "voluntary-standard", "license": "CC-BY-SA-4.0", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2026-06-26", "retrieved_on": "2026-06-26", "source_id": "owasp_aisvs_v1", "relationship": "implementation_pattern", "rationale": "Establishes OWASP AI Security Verification Standard v1.0 requirements informing the apeiris://model/controls/BH-07 Resource and Cost Anomaly Monitoring control.", "reviewed_on": "2026-07-01", "canonical_url": "https://github.com/OWASP/AISVS" } ], "implementation": { "pattern": "Deploy a cost and resource telemetry pipeline aggregating compute spend, token usage, and API call volume per caller, model, and time window. Apply Z-score and EWMA anomaly detection against rolling baselines. Fire tiered alerts for spend spikes; enforce configurable per-caller budget guardrails.", "steps": [ "Instrument the inference serving layer to emit a CostEvent per request: {caller_id, model_id, timestamp, input_tokens, output_tokens, compute_seconds, cost_usd_estimated}.", "Aggregate CostEvents in a time-series store; compute rolling baselines per caller and per model for: total_cost_per_hour, total_tokens_per_hour, call_volume_per_minute.", "Apply Z-score anomaly detection: alert when any metric exceeds baseline_mean + 3*std_dev within the monitoring window; use EWMA smoothing to reduce false positives on short spikes.", "Tiered alert structure: cost_spike_warning (>2x baseline over 1 hour), cost_spike_critical (>5x baseline over 1 hour OR >10x in any 15-minute window).", "Implement per-caller budget guardrails: configurable monthly spend cap; when cap is reached, requests are queued and the caller notified; hard stop after 120% of cap.", "Route cost_spike_critical alerts to MLOps on-call and finance operations, including: caller_id, time_window, observed_cost, baseline_cost, anomaly_score.", "Correlate cost spikes with inference volume patterns consistent with AML.T0024 (bulk inference for model extraction); route correlated events to securitycontrols.ai for enforcement." ], "anti_patterns": [ "Alerting only on absolute spend thresholds — misses relative spikes for low-volume callers.", "Not segmenting by caller_id — makes attribution impossible during a cost incident.", "Setting budget guardrails so high that meaningful abuse occurs before any alert fires.", "Not correlating cost anomalies with the AML.T0024 pattern of bulk inference for model extraction." ] }, "monitoring_schema": { "metric_objects": [ { "name": "cost_usd_per_hour", "type": "rate", "description": "Total estimated cost in USD per hour, aggregated across all callers and models.", "alert_threshold_multiplier": 2, "critical_threshold_multiplier": 5, "unit": "usd_per_hour", "metric_id": "cost_usd_per_hour", "metric_type": "cost", "measure": "cost-per-request-usd", "population": "all-production-inferences", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "tokens_per_hour", "type": "rate", "description": "Total tokens (input + output) consumed per hour across all callers.", "alert_threshold_multiplier": 2, "critical_threshold_multiplier": 5, "unit": "tokens_per_hour", "metric_id": "tokens_per_hour", "metric_type": "performance", "measure": "tokens-per-hour", "population": "all-production-inferences", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "call_volume_per_minute", "type": "rate", "description": "API call volume per minute per caller; detects automated abuse patterns.", "alert_threshold_multiplier": 3, "critical_threshold_multiplier": 10, "unit": "calls_per_minute", "metric_id": "call_volume_per_minute", "metric_type": "performance", "measure": "call-volume-per-minute", "population": "all-production-inferences", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" }, { "name": "cost_per_caller_pct_of_cap", "type": "fraction", "description": "Per-caller monthly spend as a fraction of their configured budget cap.", "alert_threshold": 0.8, "critical_threshold": 1, "unit": "fraction", "metric_id": "cost_per_caller_pct_of_cap", "metric_type": "performance", "measure": "cost-per-request-usd", "population": "all-production-inferences", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" } ], "window_context": { "type": "sliding", "duration_minutes": 60, "minimum_sample_size": 10, "short_window_minutes": 15, "baseline_window_days": 14 }, "sampling_rate": 1, "sampling_strategy": "full_population" }, "validation": { "design_check": [ "CostEvent schema is documented and includes all required fields: caller_id, model_id, input_tokens, output_tokens, cost_usd_estimated. [ref:nist_ai_rmf_1_0]", "Per-caller budget caps are defined, documented, and enforced in serving infrastructure configuration. [ref:nist_ai_rmf_1_0]", "EWMA smoothing parameters are documented; false positive rate is evaluated against 30 days of historical data. [ref:nist_ai_rmf_1_0]", "AISVS C12.2 (detection and alerting) requirements are reviewed against the budget guardrail implementation. [ref:owasp_aisvs_v1]" ], "runtime_test": [ "{'test': 'Simulate a 6x cost spike (automated high-volume requests) and verify critical alert fires within one monitoring window with correct caller attribution.', 'ref': 'nist_rmf_1_0'} [ref:nist_ai_rmf_1_0]", "{'test': 'Verify per-caller hard stop triggers at 120% of monthly cap and caller receives notification.', 'unverified': True} [unverified]", "{'test': 'Confirm cost spikes correlated with high call volume (potential AML.T0024 pattern) are routed to securitycontrols.ai.', 'ref': 'atlas_v560'} [ref:mitre_atlas_v5_6_0]" ], "evidence": [ "model:costevent-time-series-for-trailing-90-da — CostEvent time-series for trailing 90 days with per-caller attribution. [ref:nist_ai_rmf_1_0]", "model:alert-log-for-cost-anomalies-with-root-c — Alert log for cost anomalies with root cause and resolution records. [unverified]", "model:budget-cap-configuration-document-review — Budget cap configuration document reviewed by finance operations and model owner. [unverified]" ] }, "lenses": { "engineering": "CostEvent emission must be non-blocking; cost estimation uses token-count-based pricing at inference time; actual billing reconciliation runs in a separate async pipeline.", "evaluation": "Evaluation runs (BoundaryTestSuite, InjectionProbeLibrary) must use a dedicated cost bucket excluded from production baselines to avoid polluting anomaly detection.", "red_team": "Test whether a low-and-slow bulk inference attack (AML.T0044 / AML.T0024) evades per-minute call volume thresholds by staying within per-window limits across multiple windows.", "grc": "Cost monitoring provides financial controls evidence for governance reporting; budget cap enforcement supports NIST AI RMF GOVERN function accountability requirements.", "mlops": "Monthly cost reports generated per model and per caller; cost efficiency regressions (cost per correct prediction) tracked alongside accuracy metrics." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers resource consumption and cost anomaly monitoring. Model extraction attacks are handled jointly with securitycontrols.ai (BH-07 detects cost signal; securitycontrols.ai investigates and blocks). Compute infrastructure security is out of scope.", "canonical_id": "apeiris://model/controls/BH-07", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE-2.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MANAGE-2.4 (MANAGE function) provides that mechanisms and assigned responsibilities exist to supersede, disengage, or deactivate AI systems that demonstrate performance inconsistent with intended use. BH-07’s resource and cost anomaly alerts provide an early signal feeding the decision to throttle, disengage, or deactivate a model whose runtime behavior deviates from intended use.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "7.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-07 monitors compute resource consumption, token usage, and API call volumes in real time against per-caller budget caps — supporting the resource adequacy monitoring obligations of ISO 42001 Clause 7.1, which requires organizations to determine and provide adequate resources for AI system operation. Clause 9.1 is additionally relevant because BH-07's cost anomaly metrics contribute to the operational monitoring evidence base that Clause 9.1 requires for evaluating AI system performance and detecting abnormal operational conditions.", "uncovered_portion": "Clause 7.1 addresses resource planning and adequacy for the full AI management system scope including human resources, infrastructure, and financial resources for governance; BH-07 covers only runtime compute cost monitoring and does not address AI governance resource planning or management system resourcing.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-55", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 55(1)(d) requires systemic GPAI providers to ensure adequate cybersecurity; BH-07's resource anomaly detection — monitoring GPU utilization, memory consumption, and inference latency for anomalies — provides an adjacent signal for detecting infrastructure-level attacks and resource exhaustion patterns that may indicate cybersecurity incidents.", "uncovered_portion": "Art. 55 is focused on model-level cybersecurity and systemic risk; BH-07 is a cost and infrastructure monitoring control that provides partial supporting evidence. It does not address model-level security hardening, adversarial testing, or incident notification obligations.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "owasp_ai_exchange", "requirement_id": "limitresources", "fit": "supporting", "rationale": "Per-caller budget guardrails that queue or block requests at a spend cap implement the limit-resources control against resource exhaustion.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "ratelimit", "fit": "supporting", "rationale": "Throttling or blocking callers whose token/API volume spikes above baseline is the rate-limit control applied to the model.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "monitoruse", "fit": "supporting", "rationale": "Real-time detection of cost and token anomalies that may indicate abuse is monitoring model use for abuse and anomalies.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0004", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"The system must continuously monitor compute spend, token consumption, and API call…\" enacts ATLAS mitigation AML.M0004 Restrict Number of AI Model Queries; OpenCRE crosswalks this control’s OWASP AI Exchange concept (ratelimit) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0024", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"The system must continuously monitor compute spend, token consumption, and API call…\" enacts ATLAS mitigation AML.M0024 AI Telemetry Logging; OpenCRE crosswalks this control’s OWASP AI Exchange concept (monitoruse) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "gpai_model_systemic_risk" ], "classification": [ "gpai-systemic-risk" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2025-08-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-55", "mapping_fit": "adjacent", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "The system must continuously monitor compute spend, token consumption, and API call volume per caller and model, with anomaly detection alerting within one operational window when any metric exceeds 2× the rolling baseline; per-caller budget guardrails must automatically queue or block requests when the configured monthly spend cap is reached.", "evidence_required": [ "cost_telemetry_pipeline_record showing CostEvent emission per request with caller_id, model_id, input_tokens, output_tokens, and cost_usd_estimated fields", "anomaly_detection_configuration_record showing baseline computation method (Z-score or EWMA), threshold multipliers, and evaluation window duration per caller and model", "budget_guardrail_configuration_record showing per-caller monthly spend cap, queue-activation threshold percentage, and hard-stop cap percentage for each active caller", "cost_spike_alert_log for any triggered alerts showing caller_id, time_window, observed_cost, baseline_cost, and anomaly_score with routing confirmation to MLOps on-call", "aml_t0024_correlation_record linking cost spike events to bulk inference volume patterns consistent with model extraction detection" ], "machine_tests": [ "Replay 100× normal call volume from a single caller_id within a 15-minute window → assert cost_spike_critical alert fires within the monitoring window with correct caller_id and anomaly_score", "Send requests until a caller reaches 80% of monthly budget cap → assert cost_per_caller_pct_of_cap metric is logged and a warning alert is emitted with correct caller_id", "Inject a CostEvent with cost_usd_estimated equal to baseline_mean + 6*std_dev → assert anomaly detection flags the event and routes alert to MLOps on-call", "Simulate a caller at 121% of monthly budget cap → assert subsequent requests are blocked (hard stop) and caller receives a cap-exceeded notification" ], "human_review": [ "Review baseline computation methodology and anomaly detection thresholds for calibration against production traffic patterns and seasonal variation", "Assess AML.T0024 correlation rules for coverage of known model extraction query patterns and acceptable false-positive rate", "Verify per-caller budget cap values reflect current business authorization levels and are reviewed at least quarterly by finance operations and MLOps" ], "blocking_effect": "advisory", "normative_status": "voluntary-standard", "anti_patterns": [ "Alerting only on absolute cost thresholds rather than relative deviation from per-caller rolling baselines, causing low-volume callers to evade anomaly detection", "Aggregating cost metrics across all callers without per-caller_id segmentation, making attribution impossible during a cost incident or model extraction investigation", "Setting monthly budget guardrail caps at levels that permit thousands of USD of abuse or thousands of bulk inference requests before any enforcement action fires", "Not correlating cost spikes with high-volume inference patterns consistent with AML.T0024 model extraction, missing a key adversarial signal", "Using static alerting windows instead of rolling baselines, causing alert fatigue during legitimate load spikes while missing sustained low-amplitude abuse" ], "update_status": "current", "layer_code": "BH" }, { "id": "BH-08", "layer": "BH", "plane": "data", "name": "Shadow and Canary Deployment Governance", "plain": "Require formal authorization gates before routing production traffic to new model versions; define canary rollout criteria, shadow scoring comparison requirements, and rollback trigger conditions so unvalidated models cannot reach full production.", "threat": { "tags": [ "MR-DEV", "MR-PERFORMANCE" ], "desc": "Deploying new model versions without structured rollout controls risks exposing users to regressions, behavioral boundary violations, or unexpected capability changes at scale. Rushed deployments bypass evaluation gates established in the EV layer and create accountability gaps." }, "standard": [ { "id": "nist_rmf", "ref": "MANAGE 1.1" }, { "id": "iso_42001", "ref": "A.6.2.5" }, { "id": "eu_ai_act", "ref": "Art. 9, Art. 15" } ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://doi.org/10.6028/NIST.AI.100-1", "source_type": "supervisory-guidance", "license": "public_domain", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/BH-08 Shadow and Canary Deployment Governance control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "source_type": "certification-standard", "license": "proprietary", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/BH-08 Shadow and Canary Deployment Governance control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Implement a four-stage deployment pipeline: (1) shadow deployment for offline comparison, (2) canary rollout with configurable traffic percentage and exit criteria, (3) progressive rollout with automated health gates, (4) full production with rollback arm. Each stage requires a signed authorization artifact before advancing.", "steps": [ "Shadow Stage: route a copy of production traffic to the new model version; compare shadow outputs to current production using automated scoring (BoundaryAdherenceRate, InjectionResistanceScore, primary metric delta). Require shadow comparison report showing <5% output divergence on safety-critical categories before advancing.", "Canary Authorization Gate: require signed approval from model owner + evaluation team lead before routing live user traffic to the new version. Approval must reference the EvaluationBaseline artifact from EV layer and the shadow comparison report.", "Canary Rollout: route 5% of production traffic to the new model version; monitor for 24 hours minimum with all BH-layer health metrics active at elevated alert sensitivity.", "Canary Exit Criteria (advance to progressive rollout): primary metric regression <3%, BoundaryAdherenceRate >=97%, InjectionResistanceScore >=95%, no sev1 incidents during canary window.", "Canary Rollback Triggers: auto-rollback within 5 minutes when primary metric regression >8% OR BoundaryAdherenceRate <90% OR any sev1 incident occurs during canary.", "Progressive Rollout: 25% -> 50% -> 100% with 6-hour soak periods at each stage; same health gates apply.", "Document all stage transitions, authorization records, and rollback events in the DeploymentGovernanceLog linked to the model version." ], "anti_patterns": [ "Skipping shadow stage for 'minor' model updates — all changes to model weights require shadow comparison.", "Using informal approval (Slack message) rather than a signed authorization artifact — makes audit impossible.", "Setting canary rollback triggers after the fact rather than pre-defining them in deployment configuration.", "Advancing canary percentage based on elapsed time alone without checking health gate criteria." ] }, "validation": { "design_check": [ "Deployment pipeline configuration documents all four stages with authorization gate requirements. [ref:iso_42001_2023]", "Canary exit criteria and rollback trigger thresholds are pre-defined in deployment configuration before any rollout begins. [ref:nist_ai_rmf_1_0]", "SR 26-2 deployment controls requirement: DeploymentGovernanceLog satisfies the documented procedures requirement. [ref:sr262_2026]", "Shadow comparison scoring methodology references the current EvaluationBaseline artifact. [ref:nist_ai_rmf_1_0]" ], "runtime_test": [ "{'test': 'Run a canary deployment with simulated 9% metric regression; verify auto-rollback triggers within 5 minutes.', 'ref': 'nist_rmf_1_0'} [ref:nist_ai_rmf_1_0]", "{'test': 'Verify canary cannot advance to progressive rollout without a signed authorization artifact from the model owner.', 'unverified': True} [unverified]", "{'test': 'Confirm shadow comparison report is generated and stored before any canary authorization gate is presented.', 'unverified': True} [unverified]" ], "evidence": [ "model:deploymentgovernancelog-for-all-producti — DeploymentGovernanceLog for all production deployments in trailing 12 months. [ref:sr262_2026]", "model:signed-authorization-artifacts-for-each — Signed authorization artifacts for each canary deployment. [ref:iso_42001_2023]", "model:shadow-comparison-reports-with-output-di — Shadow comparison reports with output divergence metrics for each deployment. [ref:nist_ai_rmf_1_0]", "model:rollback-event-log-with-trigger-conditio — Rollback event log with trigger condition and resolution time. [unverified]" ] }, "lenses": { "engineering": "Implement authorization gates as pipeline-as-code checks that block stage advancement without a valid signed artifact; automate rollback using infrastructure-level traffic weight controls, not application-layer switches.", "evaluation": "Shadow comparison report and EvaluationBaseline artifact from EV layer are inputs to the canary authorization gate; evaluation team co-signs canary advancement.", "red_team": "Probe whether shadow scoring can be gamed by a model that behaves differently on shadow vs. live traffic (detecting shadow via timing or request metadata).", "grc": "SR 26-2 requires model deployment be subject to independent validation and documented controls; the four-stage pipeline with signed authorizations satisfies this.", "mlops": "Canary rollout is orchestrated by MLOps; auto-rollback must be tested in staging quarterly; rollback SLA (5 minutes) is included in the service level objective." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Covers model deployment governance from shadow through full production. Pre-release evaluation (EV layer) is a prerequisite. Infrastructure-level deployment automation is out of scope; this control governs authorization and monitoring requirements.", "canonical_id": "apeiris://model/controls/BH-08", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "monitoring_schema": { "metrics": [ { "metric_id": "bh-08-pass-rate", "metric_type": "performance", "measure": "control-verification-pass-rate", "population": "all-assessed-deployments", "comparison": { "operator": "lt", "value": 1, "window": "30d", "evaluation_mode": "batch" }, "severity": "critical" } ], "sampling_rate": "100%", "window_context": "rolling-30d" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE-1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MANAGE-1.1 (MANAGE function) provides that a determination is made whether the AI system achieves its intended purposes and whether development or deployment should proceed. BH-08’s canary authorization gates and pre-defined exit criteria operationalize that proceed/do-not-proceed determination for each new model version.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.5", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.5 (AI system deployment) requires deployment according to defined requirements. BH-08’s signed authorization artifacts, canary exit criteria, and automated rollback give deployment transitions that controlled pathway.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-15", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 15 requires high-risk AI systems to achieve appropriate accuracy, robustness and cybersecurity throughout their lifecycle; BH-08's canary deployment gates — limiting initial traffic exposure and requiring performance equivalence checks before full rollout — provide an adjacent robustness assurance mechanism that reduces the risk of deploying degraded models.", "uncovered_portion": "Art. 15 addresses the overall design and development requirements for robustness; BH-08 addresses deployment process governance only and does not satisfy Art. 15's requirements for systematic accuracy benchmarking, robustness testing, or cybersecurity by design.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" } ], "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-15", "mapping_fit": "adjacent", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "No new model version may receive production traffic without a formal authorization record confirming that pre-specified canary rollout criteria have been met and that shadow scoring comparison against the current production model satisfies defined pass thresholds; rollback trigger conditions must be documented and operational before any canary traffic begins.", "evidence_required": [ "canary_deployment_authorization_record with model_version_id, authorized_traffic_percentage, rollout_criteria_met confirmation, authorized_by, and authorized_at timestamp", "shadow_scoring_comparison_report showing metric-level comparison between the shadow candidate and production model over the evaluation window with a pass/fail determination against pre-specified thresholds", "rollback_trigger_specification_document defining measurable thresholds (e.g., latency_p99 > X ms, error_rate > Y%) that automatically or manually initiate rollback before canary traffic begins", "canary_traffic_routing_log confirming the percentage of production traffic routed to the canary model version at each rollout stage with timestamps", "deployment_gate_decision_record showing the final authorization gate outcome (proceed to full production or rollback) with rationale and decision-maker identity" ], "machine_tests": [ "Attempt to route production traffic to a new model_version_id without a canary_deployment_authorization_record → assert the routing request is blocked with error=missing_deployment_authorization", "Configure a canary with rollback threshold error_rate > 2% and inject synthetic errors exceeding that threshold → assert rollback is triggered within the defined monitoring window", "Submit a shadow scoring comparison report where the candidate underperforms production by 15% on the primary metric (assuming a 5% pass threshold) → assert the deployment gate rejects promotion and logs a gate_rejection_record" ], "human_review": [ "Review canary rollout criteria and shadow scoring pass thresholds for completeness against the model's intended use case, risk classification, and business impact requirements", "Assess rollback trigger condition definitions for specificity and operational feasibility, confirming on-call runbooks reference and can execute these triggers", "Verify that deployment authorization records require named human approvers and cannot be self-authorized by automated CI/CD pipeline components" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Promoting a model from canary to full production based on elapsed time rather than verified metric thresholds against a pre-specified shadow scoring comparison", "Running shadow scoring without a documented pass/fail criterion defined before the evaluation begins, making the gate outcome subjective", "Allowing CI/CD pipeline automation to self-authorize canary promotion gates without a named human approver in the authorization record", "Not specifying rollback trigger conditions before canary traffic begins, requiring ad hoc threshold decisions during a live production incident", "Setting canary traffic allocation so low that statistical significance cannot be achieved within the evaluation window, producing unreliable shadow comparison results" ], "update_status": "current", "layer_code": "BH" }, { "id": "BH-09", "layer": "BH", "plane": "data", "name": "Synthetic-Content Provenance, Disclosure and Traceability", "plain": "For generative AI deployments, embed cryptographic provenance metadata in AI-generated content, apply mandatory disclosure labels, and maintain a traceability chain linking content back to the generating model version — enabling verification and regulatory compliance.", "matrix_thesis": true, "thesis_type": "directive", "threat": { "tags": [ "LLM09:2025", "MR-PERFORMANCE", "EU-AIA-AnnexIII" ], "desc": "AI-generated content without provenance metadata enables disinformation, fraudulent attribution, and regulatory non-compliance. The inability to trace generated content to a model version prevents incident investigation and accountability. LLM09:2025 (Misinformation) is the primary threat vector; EU AI Act Art. 50 creates a binding disclosure obligation." }, "standard": [ { "id": "nist_rmf", "ref": "GOVERN 1.2, MANAGE 4.1" }, { "id": "iso_42001", "ref": "A.8.2" }, { "id": "eu_ai_act", "ref": "Art. 50 — Transparency obligations for AI-generated content" }, { "id": "llm10", "ref": "LLM09:2025" } ], "sources": [ { "id": "c2pa_spec_v2", "authority": "Coalition for Content Provenance and Authenticity (C2PA)", "title": "C2PA Technical Specification v2.x", "url": "https://c2pa.org/specifications/specifications/2.x/specs/C2PA_Specification.html", "source_type": "voluntary-standard", "license": "CC BY 4.0", "artifact_hash": null, "status": "current", "retrieved_on": "2026-06-26", "normative_force": "voluntary-standard", "version": "2.1", "published_on": "2024-11-01", "source_id": "c2pa_spec_v2", "relationship": "implementation_pattern", "rationale": "Establishes C2PA Technical Specification v2.x requirements informing the apeiris://model/controls/BH-09 Synthetic-Content Provenance, Disclosure and Traceability control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_100_4", "authority": "NIST", "title": "NIST AI 100-4: Reducing Risks Posed by Synthetic Content", "url": "https://doi.org/10.6028/NIST.AI.100-4", "source_type": "supervisory-guidance", "license": "public_domain", "artifact_hash": null, "status": "current", "retrieved_on": "2026-06-26", "normative_force": "voluntary-standard", "version": "1.0", "source_id": "nist_ai_100_4", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI 100-4: Reducing Risks Posed by Synthetic Content requirements informing the apeiris://model/controls/BH-09 Synthetic-Content Provenance, Disclosure and Traceability control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "authority": "European Parliament and Council", "title": "EU AI Act (Regulation (EU) 2024/1689)", "source_type": "regulation", "license": "public_domain", "artifact_hash": null, "effective_dates": { "standalone_high_risk": "2027-12-02", "product_embedded": "2028-08-02" }, "status": "current", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) requirements informing the apeiris://model/controls/BH-09 Synthetic-Content Provenance, Disclosure and Traceability control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_llm10_2025", "authority": "OWASP", "title": "OWASP Top 10 for LLM Applications 2025", "url": "https://owasp.org/www-project-top-10-for-large-language-model-applications/", "source_type": "voluntary-standard", "license": "CC-BY-SA-4.0", "version": "2025", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "published_on": "2024-11-17", "retrieved_on": "2026-06-26", "source_id": "owasp_llm10", "relationship": "implementation_pattern", "rationale": "Establishes OWASP Top 10 for LLM Applications 2025 requirements informing the apeiris://model/controls/BH-09 Synthetic-Content Provenance, Disclosure and Traceability control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://doi.org/10.6028/NIST.AI.100-1", "source_type": "supervisory-guidance", "license": "public_domain", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/BH-09 Synthetic-Content Provenance, Disclosure and Traceability control.", "reviewed_on": "2026-07-01" }, { "id": "biml_llm_ara", "title": "BIML — Architectural Risk Analysis of LLMs (2024)", "authority": "Berryville Institute of Machine Learning", "source_type": "research-institute", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-24", "retrieved_on": "2026-07-08", "canonical_url": "https://berryvilleiml.com/docs/BIML-LLM24.pdf", "relationship": "supporting_guidance", "note": "BIML 'recursive pollution' motivates synthetic-content provenance + disclosure." } ], "implementation": { "pattern": "For generative-ai profile deployments, embed C2PA-compliant provenance assertions in all generated content artifacts. Apply mandatory AI-generated disclosure labels for text outputs. Maintain a GenerationTraceabilityRegistry linking content back to model version. CONDITIONAL: this control applies only to the generative-ai profile.", "steps": [ "Classify all generative AI deployments under the generative-ai profile; confirm with the model owner that BH-09 applies before implementation.", "For image, audio, and video outputs: implement C2PA Content Credentials embedding at the point of generation. C2PA manifest must include: model_id, model_version, generation_timestamp_utc, inference_endpoint_id, content_hash. Sign with the organization's C2PA signing certificate.", "For text outputs: apply a mandatory disclosure label at the application layer ('Generated by AI' tag in metadata and, where required by EU AI Act Art. 50, in the visible interface). Do not rely solely on watermarking for text — current techniques are not robust as a sole mechanism.", "Implement model watermarking following NIST AI 100-4 approaches per output modality: image (visible/invisible watermarking), audio (spectral watermarking), text (token-bias watermarking as secondary layer only).", "Maintain a GenerationTraceabilityRegistry: {artifact_hash, model_id, model_version, generation_timestamp, c2pa_manifest_hash}. Retention: minimum 1 year for EU deployments per Art. 50 obligations.", "Implement a provenance verification endpoint: given a content artifact, return the associated C2PA manifest and model version if traceable.", "Perform quarterly C2PA manifest integrity audits: verify a random sample of stored manifests against the signing certificate chain." ], "anti_patterns": [ "Applying this control to predictive/classification-only deployments — BH-09 is conditional on the generative-ai profile.", "Relying solely on text watermarking as the primary disclosure mechanism — current token-bias techniques are fragile and detectable.", "Embedding C2PA manifests without maintaining the GenerationTraceabilityRegistry — makes it impossible to resolve manifests during incident investigation.", "Not updating C2PA signing certificates on a regular rotation — a compromised cert invalidates all provenance assertions." ] }, "profiles": [ "generative-ai" ], "obligations": [ { "id": "eu-aia-art50-ai-content-labeling", "text": "EU AI Act Art. 50: AI-generated content must be labeled as AI-generated in a machine-readable format. GPAI model providers must ensure their model outputs are detectable as AI-generated or manipulated where technically feasible. Applies to providers and deployers.", "jurisdiction": [ "eu" ], "binding": true, "normative_force": "binding-law", "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "legal_status": "enacted", "provision": "Article 50(ai)", "effective_from": "2026-08-02" }, { "id": "nist-ai-100-4-provenance", "text": "NIST AI 100-4: recommends provenance metadata and watermarking approaches for synthetic content, including C2PA-compatible implementations. Voluntary guidance — not a federal binding requirement.", "jurisdiction": [ "us" ], "binding": false, "normative_force": "best-practice", "reviewed_on": "2026-06-26", "authority": "NIST", "instrument": "NIST AI 100-4", "source_ref": "nist_ai_100_4", "legal_status": "enacted", "provision": "Synthetic Content Guidance" }, { "id": "c2pa-content-provenance", "text": "C2PA (Coalition for Content Provenance and Authenticity): industry standard for embedding cryptographic provenance metadata in AI-generated media. Voluntary adoption required for interoperability with platform-level content authenticity checks.", "jurisdiction": [ "global" ], "binding": false, "normative_force": "voluntary-standard", "reviewed_on": "2026-06-26", "authority": "Coalition for Content Provenance and Authenticity", "instrument": "C2PA Specification", "source_ref": "c2pa", "legal_status": "enacted", "provision": "C2PA Content Credentials" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-50", "mapping_fit": "direct", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "capability_risk": { "capability_level": "none", "autonomy": "bounded", "access_mode": "api", "irreversibility": "irreversible", "deployment_scale": "enterprise", "affected_party_impact": "moderate", "external_reach": true, "data_sensitivity": "internal", "notes": "domain: synthetic_content | risk level: high | rationale: Unlabeled AI-generated content at scale enables disinformation operations, fraudulent identity claims, and regulatory non-compliance. Risk is proportional to the realism and reach of generated content." }, "validation": { "design_check": [ "The generative-ai profile is assigned and confirmed by the model owner before BH-09 is implemented. [ref:nist_ai_rmf_1_0]", "C2PA signing certificate is issued, stored in the key management system, and has a defined rotation schedule. [ref:c2pa_spec_v2]", "EU AI Act Art. 50 disclosure requirements are mapped to specific implementation points in the application architecture. [ref:eu_ai_act_2024]", "NIST AI 100-4 watermarking approach selection is documented with rationale per output modality. [ref:nist_ai_100_4]" ], "runtime_test": [ "{'test': 'Generate a sample artifact and verify the C2PA manifest is embedded, signed with the correct certificate, and includes all required fields.', 'ref': 'c2pa_spec_v2'} [ref:c2pa_spec_v2]", "{'test': 'Submit the sample artifact to the provenance verification endpoint and confirm model_id and model_version are correctly returned.', 'ref': 'c2pa_spec_v2'} [ref:c2pa_spec_v2]", "{'test': 'Verify text outputs include mandatory disclosure labels in both metadata and visible UI where required by Art. 50.', 'ref': 'eu_ai_act_2024'} [ref:eu_ai_act_2024]", "{'test': 'Attempt to remove the C2PA manifest from a generated image and verify the verification endpoint detects tampering.', 'ref': 'c2pa_spec_v2'} [ref:c2pa_spec_v2]" ], "evidence": [ "model:c2pa-signing-certificate-and-rotation-sc — C2PA signing certificate and rotation schedule documentation. [ref:c2pa_spec_v2]", "model:generationtraceabilityregistry-sample-au — GenerationTraceabilityRegistry sample audit for trailing 90 days. [ref:nist_ai_100_4]", "model:quarterly-c2pa-manifest-integrity-audit — Quarterly C2PA manifest integrity audit report. [ref:c2pa_spec_v2]", "model:eu-ai-act-art-50-compliance-mapping-doc — EU AI Act Art. 50 compliance mapping document. [ref:eu_ai_act_2024]" ] }, "lenses": { "engineering": "C2PA manifest embedding must be atomic with content generation — manifests added as post-processing risk being stripped. Use a generation wrapper that produces content and manifest together.", "evaluation": "Evaluate watermark robustness: test whether common post-processing (compression, transcoding, cropping) destroys provenance signals; document robustness limits in the model card.", "red_team": "Test whether the C2PA manifest can be stripped, replayed from a different artifact, or forged using a stolen signing certificate. Test whether watermarks survive common evasion transformations.", "grc": "EU AI Act Art. 50 is an active obligation for GPAI models; it applies from August 2026, making this a near-term compliance priority. Non-compliance carries Art. 99 penalties.", "mlops": "GenerationTraceabilityRegistry must be budgeted as separate storage and retention cost; artifact volume for high-throughput generative deployments can be significant." }, "maturity": { "current": "none", "target": "developing" }, "coverage_note": "Applies ONLY to the generative-ai profile. Not applicable to predictive-ml, classification, or non-generative deployments. Text watermarking is a secondary layer; EU AI Act Art. 50 disclosure labels are the primary obligation for text outputs.", "canonical_id": "apeiris://model/controls/BH-09", "monitoring_schema": { "metrics": [ { "metric_id": "bh-09-pass-rate", "metric_type": "performance", "measure": "control-verification-pass-rate", "population": "all-assessed-deployments", "comparison": { "operator": "lt", "value": 1, "window": "30d", "evaluation_mode": "batch" }, "severity": "critical" } ], "sampling_rate": "100%", "window_context": "rolling-30d" }, "frameworks": [ { "framework": "nist_ai_600_1", "requirement_id": "INFO-INTEGRITY", "fit": "direct", "direction": "control-supports-requirement", "rationale": "NIST AI 600-1 identifies Information Integrity as a GenAI risk — AI-generated content used for disinformation, synthetic media, or misleading purposes at scale. BH-09 directly addresses this by requiring provenance marking, disclosure mechanisms, and traceability for all synthetic model outputs, enabling downstream verification and limiting information integrity harms.", "source_locator": { "section": "INFO-INTEGRITY" }, "source_version": "2024", "reviewed_on": "2026-06-26", "mapping_confidence": "medium", "provisional": true, "provisional_note": "NIST AI 600-1 GenAI Profile uses category-level identifiers (e.g., CONFABULATION, CBRN); action-level subcategory mapping was not possible from the category reference. Treat as category-level guidance only.", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_rmf", "requirement_id": "GOVERN-1.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-1.2 (GOVERN function) provides that the characteristics of trustworthy AI are integrated into organizational policies, processes, and practices. BH-09’s C2PA provenance assertions and disclosure labels operationalize transparency — one of the trustworthy-AI characteristics this subcategory integrates into policy — for generated content.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.8.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.8.2 (System documentation and information for users) requires providing users with necessary information about the AI system. BH-09’s C2PA provenance assertions and disclosure labels inform recipients that content is AI-generated.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "DSP-20", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-09 embeds C2PA-compliant cryptographic provenance assertions in all AI-generated content artifacts, maintains a GenerationTraceabilityRegistry linking every output to the generating model version with a provenance verification endpoint, and applies mandatory disclosure labels to satisfy EU AI Act Art. 50 — directly implementing TE-02's AI-generated content provenance, disclosure labeling, and traceability requirement. The quarterly manifest integrity audits and certificate rotation schedule provide the ongoing assurance that the cryptographic provenance chain remains valid over the content lifecycle.", "source_locator": { "section": "Transparency and Explainability" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "uncovered_portion": "DSP-20 additionally covers data provenance for input datasets, third-party data origin attestation, and lineage documentation requirements beyond AI-generated output provenance.", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-50", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 50 requires providers of AI systems that generate synthetic audio, image, video or text content to ensure outputs are marked in a machine-readable format and detectable as artificially generated; BH-09's synthetic content provenance framework — using C2PA manifest attachment, cryptographic signing, and automated provenance-token injection — directly implements this transparency obligation. Art. 50(2) specifically applies to GPAI models generating synthetic images, audio, or video.", "uncovered_portion": "Art. 50 applies to synthetic image, audio, and video for which technical standards are still being developed; BH-09 covers provenance marking but cannot guarantee detection in all distribution channels or by all downstream consumers. Deepfake exception testing under Art. 50(3) is not covered.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "source_locator": { "section": "Art. 50 — Transparency obligations for certain AI systems and GPAI models" }, "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "owasp_ai_exchange", "requirement_id": "aitransparency", "fit": "supporting", "rationale": "Mandatory disclosure labels and provenance metadata on AI-generated content are the transparency-about-AI-use obligation.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "validation_objective": "Every AI-generated content artifact must carry verifiable cryptographic provenance metadata linking it to the generating model version, include a mandatory disclosure label visible to recipients, and be resolvable through a complete traceability chain from generation event to content delivery with no gaps in the provenance record.", "evidence_required": [ "content_provenance_record per generated artifact showing model_version_id, generation_timestamp, content_hash, and cryptographic signature (C2PA manifest or equivalent) attached at generation time", "disclosure_label_audit_log confirming that AI-generated disclosure labels were applied and rendered for each content delivery event, with delivery_channel and recipient_context recorded", "traceability_chain_record linking content_id to generation_event_id, model_version_id, and serving_endpoint_id for each production output", "provenance_metadata_schema_validation_report confirming all required provenance fields are present and signature validity checks pass across a sampled period", "regulatory_disclosure_mapping_record showing how disclosure label format and placement satisfies jurisdiction-specific requirements (EU AI Act Art. 50 and equivalent)" ], "machine_tests": [ "Generate content via the production model endpoint → assert the response or attached metadata includes model_version_id, generation_timestamp, content_hash, cryptographic signature, and disclosure label", "Retrieve a content artifact by content_id from the traceability store → assert the full chain resolves to a verified model_version_id and generation_event_id without any broken links", "Tamper with the content_hash field in a provenance record → assert signature verification fails and the artifact is flagged as integrity_violated", "Submit a content delivery request with disclosure label configuration disabled → assert the system rejects the request or enforces label application rather than delivering unlabeled AI content" ], "human_review": [ "Review provenance metadata schema for completeness against C2PA or equivalent standard and all applicable regulatory disclosure requirements by jurisdiction", "Assess disclosure label rendering across all active content delivery channels (API response body, rendered UI, PDF export, email) for consistency, legibility, and recipient visibility", "Verify that provenance records are stored in an immutable archive with retention period covering regulatory requirements and are accessible for regulatory inquiry without prior notice" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Embedding AI disclosure labels only in HTTP response headers or metadata fields not visible to end recipients rather than in the content presentation layer", "Using informal model name strings or mutable version tags in provenance records instead of cryptographically bound, immutable model version identifiers", "Treating provenance attachment as an asynchronous post-processing step rather than a synchronous operation at content generation time, creating gaps under high load", "Not retaining provenance and traceability records for content that was subsequently deleted or modified, breaking the audit chain for that content", "Applying disclosure labels conditionally based on perceived AI-content proportion rather than unconditionally on all outputs from generative AI systems" ], "update_status": "current", "layer_code": "BH" }, { "id": "BH-10", "layer": "BH", "plane": "data", "name": "Feedback Loop Integrity and Online Learning Governance", "plain": "Govern all feedback loops that influence model behavior after deployment — including RLHF/RLAIF labeler quality controls, reward hacking prevention, online learning authorization gates, feedback poisoning detection, and self-reinforcing error monitoring.", "threat": { "tags": [ "AML.T0020", "LLM04:2025", "MR-MONITORING", "MR-DEV" ], "desc": "Feedback loops that update model behavior post-deployment create a continuous attack surface. Poisoned human feedback, reward hacking, unauthorized online learning updates, and self-reinforcing errors can silently degrade model quality, introduce bias, or create exploitable behavioral patterns. RLHF labeler compromise is analogous to training data poisoning (AML.T0020, LLM04:2025) but operates continuously after deployment." }, "standard": [ { "id": "nist_rmf", "ref": "MANAGE 4.1" }, { "id": "iso_42001", "ref": "A.7.2" }, { "id": "eu_ai_act", "ref": "Art. 9(1)(c), Art. 12" }, { "id": "aisvs", "ref": "C3.5 — Pipeline Fine-Tuning (RLHF integrity)" } ], "sources": [ { "id": "nist_ai_rmf_1_0", "authority": "NIST", "title": "NIST AI Risk Management Framework 1.0", "url": "https://doi.org/10.6028/NIST.AI.100-1", "source_type": "supervisory-guidance", "license": "public_domain", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/BH-10 Feedback Loop Integrity and Online Learning Governance control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "authority": "ISO/IEC", "title": "ISO/IEC 42001:2023 — AI Management System", "source_type": "certification-standard", "license": "proprietary", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 — AI Management System requirements informing the apeiris://model/controls/BH-10 Feedback Loop Integrity and Online Learning Governance control.", "reviewed_on": "2026-07-01" }, { "id": "mitre_atlas_v5_6_0", "authority": "MITRE", "title": "MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems", "url": "https://atlas.mitre.org", "source_type": "threat-knowledge-base", "license": "apache_2_0", "version": "5.6.0", "effective_date": "2026-05-04", "artifact_hash": null, "status": "current", "normative_force": "best-practice", "published_on": "2026-05-04", "retrieved_on": "2026-06-26", "source_id": "mitre_atlas", "relationship": "informative_reference", "rationale": "Establishes MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems requirements informing the apeiris://model/controls/BH-10 Feedback Loop Integrity and Online Learning Governance control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_llm10_2025", "authority": "OWASP", "title": "OWASP Top 10 for LLM Applications 2025", "url": "https://owasp.org/www-project-top-10-for-large-language-model-applications/", "source_type": "voluntary-standard", "license": "CC-BY-SA-4.0", "version": "2025", "artifact_hash": null, "status": "current", "normative_force": "voluntary-standard", "published_on": "2024-11-17", "retrieved_on": "2026-06-26", "source_id": "owasp_llm10", "relationship": "implementation_pattern", "rationale": "Establishes OWASP Top 10 for LLM Applications 2025 requirements informing the apeiris://model/controls/BH-10 Feedback Loop Integrity and Online Learning Governance control.", "reviewed_on": "2026-07-01" }, { "id": "owasp_aisvs_v1", "authority": "OWASP", "title": "OWASP AI Security Verification Standard v1.0", "url": "https://github.com/OWASP/AISVS", "source_type": "voluntary-standard", "license": "CC-BY-SA-4.0", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "status": "current", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2026-06-26", "retrieved_on": "2026-06-26", "source_id": "owasp_aisvs_v1", "relationship": "implementation_pattern", "rationale": "Establishes OWASP AI Security Verification Standard v1.0 requirements informing the apeiris://model/controls/BH-10 Feedback Loop Integrity and Online Learning Governance control.", "reviewed_on": "2026-07-01", "canonical_url": "https://github.com/OWASP/AISVS" } ], "implementation": { "pattern": "Implement a multi-layer feedback loop governance framework covering: (1) labeler quality controls for RLHF/RLAIF, (2) reward model monitoring and hacking detection, (3) online learning authorization gates, (4) feedback poisoning detection, and (5) self-reinforcing error circuit breakers. All feedback loop updates to model weights require a signed authorization artifact before taking effect.", "steps": [ "RLHF/RLAIF Labeler Quality Controls: monitor inter-rater reliability (IRR) using Cohen's Kappa; alert when Kappa drops below 0.6 (moderate agreement threshold). Apply adversarial screening: randomly insert known-correct calibration items; flag labelers who fail >10% of calibration items. All labels must be associated with labeler_id, timestamp, and confidence score.", "Reward Model Monitoring: track reward score distribution over time; detect reward hacking patterns (abnormally high reward scores correlating with semantically degenerate outputs). Alert when mean reward score exceeds the 99th percentile of training-time reward distribution.", "Online Learning Authorization Gate: all online learning updates (gradient steps, fine-tuning, RLHF policy updates) require a signed authorization artifact from the model owner before being applied to the production model. Unauthorized updates are rejected and logged.", "Feedback Poisoning Detection: apply anomaly detection to incoming feedback batches; flag when label distribution deviates from historical norms (PSI > 0.2); flag coordinated feedback from a small set of labeler_ids (potential sybil attack); quarantine suspicious batches pending review.", "Self-Reinforcing Error Circuit Breaker: monitor correlation between model outputs at time T and the feedback/labels received at T+delta; if outputs are systematically influencing the feedback they train on, suspend online learning and raise an alert.", "RLAIF Quality Controls: apply secondary human review sample (minimum 10%) to verify AI labeler quality; track RLAIF model version and labeling consistency against the human-reviewed sample.", "Maintain a FeedbackGovernanceLog: all authorized feedback batches, source, labeler quality metrics, anomaly flags, and authorization records stored for audit." ], "anti_patterns": [ "Allowing automatic model updates from production feedback without a human authorization gate — creates an uncontrolled update loop.", "Not monitoring inter-rater reliability over time — labeler quality can degrade without any signal.", "Treating RLAIF (AI-labeled) feedback as equivalent to gold-label human feedback without quality verification.", "No circuit breaker for self-reinforcing errors — the model trains on its own outputs, amplifying existing bias or error.", "Allowing feedback to bypass the poisoning detection pipeline in 'emergency' retraining scenarios." ] }, "profiles": [ "continuously-learning", "generative-ai" ], "capability_risk": { "capability_level": "elevated", "autonomy": "bounded", "access_mode": "internal", "irreversibility": "partially-reversible", "deployment_scale": "enterprise", "affected_party_impact": "moderate", "external_reach": false, "data_sensitivity": "internal", "notes": "domain: feedback_loop_integrity | risk level: high | rationale: Compromised feedback loops can silently align model behavior with adversarial objectives, degrade quality, or introduce systematic bias at scale. For continuously-learning models, the attack surface is persistent and continuous post-deployment." }, "validation": { "design_check": [ "RLHF/RLAIF labeler quality controls including IRR monitoring (Cohen's Kappa) are documented and the Kappa=0.6 alert threshold is configured. [ref:nist_ai_rmf_1_0]", "Online learning authorization gate is implemented and requires a signed artifact before any production model weight update. [ref:iso_42001_2023]", "Feedback poisoning detection pipeline is designed with PSI threshold (0.2) for label distribution anomalies. [ref:mitre_atlas_v5_6_0]", "SR 26-2 ongoing monitoring: model updates driven by feedback loops are subject to model risk management controls; FeedbackGovernanceLog satisfies the documentation requirement. [ref:sr262_2026]", "Self-reinforcing error monitoring mechanism is designed with a defined correlation threshold that triggers the circuit breaker. [ref:iso_42001_2023]", "AISVS C3.5 (pipeline fine-tuning) RLHF integrity requirements are reviewed against implemented controls. [ref:owasp_aisvs_v1]" ], "runtime_test": [ "{'test': 'Inject a batch of adversarially uniform labels (all positive) from a small set of labeler_ids and verify feedback poisoning detection fires within one monitoring window.', 'ref': 'atlas_v560'} [ref:mitre_atlas_v5_6_0]", "{'test': 'Attempt to apply an online learning update without a signed authorization artifact and verify the update is rejected and logged.', 'ref': 'nist_rmf_1_0'} [ref:nist_ai_rmf_1_0]", "{'test': 'Simulate IRR drop to Kappa=0.5 and verify the alert fires with labeler_id attribution.', 'unverified': True} [unverified]", "{'test': 'Run reward hacking probe: submit semantically degenerate outputs and verify reward model health monitor detects the abnormal score distribution.', 'ref': 'nist_rmf_1_0'} [ref:nist_ai_rmf_1_0]", "{'test': 'Simulate self-reinforcing error pattern (output-to-label correlation exceeding threshold) and verify circuit breaker suspends online learning.', 'unverified': True} [unverified]" ], "evidence": [ "model:feedbackgovernancelog-for-trailing-90-da — FeedbackGovernanceLog for trailing 90 days with labeler quality metrics and anomaly flags. [ref:nist_ai_rmf_1_0]", "model:signed-authorization-artifacts-for-all-o — Signed authorization artifacts for all online learning updates applied to production models in trailing 90 days. [ref:iso_42001_2023]", "model:artifact-irr-cohen-s-kappa-time-s — {'artifact': \"IRR (Cohen's Kappa) time-series for RLHF labeler pool.\", 'unverified': True} [unverified]", "model:feedback-poisoning-detection-alert-log-f — Feedback poisoning detection alert log for trailing 90 days. [ref:mitre_atlas_v5_6_0]", "model:reward-model-health-report-showing-rewar — Reward model health report showing reward score distribution vs. training-time baseline. [ref:nist_ai_rmf_1_0]" ] }, "lenses": { "engineering": "The online learning authorization gate must be enforced at the model serving infrastructure level, not the application layer — application-layer gates can be bypassed by direct API calls to the model update endpoint.", "evaluation": "Evaluation team reviews RLAIF labeler quality at minimum monthly; novel RLAIF quality failure modes must be added to the calibration item set within 30 days of discovery.", "red_team": "Test whether coordinated feedback manipulation from a small labeler pool (sybil attack) can shift model behavior while staying below per-labeler anomaly thresholds. Test reward hacking via semantically degenerate but reward-maximizing outputs.", "grc": "SR 26-2 requires model updates driven by feedback loops be subject to the same model risk management controls as initial deployment. FeedbackGovernanceLog is primary evidence.", "mlops": "Feedback pipeline SLA must be monitored: feedback latency (time from inference to label availability) affects online learning staleness; track staleness as a model health metric." }, "maturity": { "current": "none", "target": "defined" }, "coverage_note": "Covers post-deployment feedback loop integrity for RLHF, RLAIF, and online learning. Training-time data poisoning is addressed in the TG layer. Drift driven by feedback loop effects is addressed in BH-02. This control was moved from the training lifecycle to the behavior layer because the threat surface is active and continuous during deployment.", "canonical_id": "apeiris://model/controls/BH-10", "monitoring_schema": { "metrics": [ { "metric_id": "bh-10-pass-rate", "metric_type": "performance", "measure": "control-verification-pass-rate", "population": "all-assessed-deployments", "comparison": { "operator": "lt", "value": 1, "window": "30d", "evaluation_mode": "batch" }, "severity": "critical" } ], "sampling_rate": "100%", "window_context": "rolling-30d" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE-4.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MANAGE-4.1 (MANAGE function) provides that post-deployment monitoring plans are implemented, including appeal and override, decommissioning, incident response, and change management. BH-10’s feedback-loop governance is the change-management component of post-deployment monitoring for models whose behavior evolves after release.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.7.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.7.2 (Data for development and enhancement) covers data used to develop and improve AI systems. BH-10’s feedback-loop integrity controls govern post-deployment enhancement data — RLHF telemetry, preference signals, and reward data.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "DSP-21", "fit": "direct", "direction": "control-supports-requirement", "rationale": "BH-10 governs all post-deployment feedback loops influencing model behavior — requiring inter-rater reliability monitoring via Cohen's Kappa for RLHF labelers, PSI-based feedback poisoning detection, reward hacking monitoring, a signed authorization gate before any online learning update is applied to production weights, and a self-reinforcing error circuit breaker — directly implementing DM-02's feedback data integrity, labeler quality, and online learning governance requirement. The FeedbackGovernanceLog provides the documented audit trail that DM-02 requires to demonstrate that model behavior changes driven by post-deployment feedback are authorized, monitored, and free from adversarial manipulation.", "source_locator": { "section": "Data Management and Lifecycle" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "owasp_aitg", "requirement_id": "AITG-INF-05", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AITG-INF-05 (Testing for Fine-tuning Poisoning) probes whether fine-tuning inputs can poison model behavior. BH-10's feedback-loop integrity controls over RLHF telemetry, preference signals, and reward data close the attack surface this test exercises.", "source_locator": { "test_id": "AITG-INF-05", "test_name": "Testing for Fine-tuning Poisoning" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-72", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 72 requires high-risk AI system providers to establish post-market monitoring systems that include collection and analysis of user feedback; BH-10's feedback loop integrity controls — preventing label poisoning, reviewer bias injection, and reward model manipulation in continuously-learning systems — provide adjacent assurance that feedback collection mechanisms in post-market monitoring are trustworthy.", "uncovered_portion": "Art. 72 addresses the full post-market monitoring plan including anomaly reporting to authorities; BH-10 is specific to continuously-learning systems and feedback integrity and does not address static model post-market monitoring, serious incident reporting, or the broader monitoring plan documentation requirements.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "owasp_ai_exchange", "requirement_id": "poisonrobustmodel", "fit": "supporting", "rationale": "Feedback-poisoning detection and authorization gates on RLHF/online-learning inputs defend the model against post-deployment poisoning.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.023", "fit": "supporting", "rationale": "Control \"All feedback pathways that influence model behavior after deployment — including…\" defends against NIST AI 100-2 attack class NISTAML.023 \"Backdoor Poisoning\"; OpenCRE crosswalks this control’s OWASP AI Exchange concept (poisonrobustmodel) to this NIST class. (Anchor captures the attack taxonomy, so we cite the threat class as defends_against, not the NIST mitigation named by OpenCRE.)", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against", "mapping_confidence": "medium", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-72", "mapping_fit": "adjacent", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "All feedback pathways that influence model behavior after deployment — including RLHF/RLAIF labeler inputs, online learning update triggers, and reward signal channels — must pass through authorization gates with poisoning detection active at each ingestion point; no unreviewed, anomalous, or flagged feedback must modify model weights or behavior in production without an explicit authorization record.", "evidence_required": [ "feedback_authorization_gate_record per feedback batch showing batch_id, inter-annotator agreement score, outlier labeler flags, approver_id, and authorization_timestamp before pipeline ingestion", "labeler_quality_control_report showing inter-annotator agreement scores, outlier labeler detection results, and remediation action taken for any flagged labeler within the reporting period", "feedback_poisoning_detection_log showing anomaly detection results on incoming feedback signals including label distribution shift analysis, adversarial pattern flags, and disposition per batch", "online_learning_authorization_record per model update triggered by live feedback, showing trigger_condition, validation_check_results, authorized_parameter_bounds, and authorization_decision", "reward_model_evaluation_report confirming the reward model was evaluated for reward hacking vulnerability and known adversarial prompting strategies before deployment to RLHF pipeline" ], "machine_tests": [ "Submit a feedback batch with 40% adversarially flipped labels (label poisoning simulation) → assert poisoning detection flags the batch and blocks it from entering the training pipeline with batch_id and anomaly_score", "Trigger an online learning update without a matching online_learning_authorization_record → assert the model update is blocked with error=missing_update_authorization", "Submit feedback from a labeler with inter-annotator agreement below the configured quality threshold → assert the labeler's inputs are quarantined and a human_review_required flag is raised" ], "human_review": [ "Review the inter-annotator agreement threshold and outlier labeler detection methodology for calibration against the complexity and subjectivity of the labeling task", "Assess the online learning authorization gate for completeness — confirm authorized updates are bounded to specific parameter ranges and that rollback capability is in place before each update", "Verify that reward model evaluation for reward hacking covers known adversarial prompting strategies and edge cases relevant to the deployment domain and population" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Allowing labeler feedback to flow directly into training pipelines without inter-annotator agreement checks or outlier detection, enabling undetected quality degradation", "Treating all feedback from deployed systems as trusted signal without poisoning detection, enabling adversarial data injection through normal API usage patterns", "Running online learning in continuous auto-update mode without per-update authorization gates, allowing any feedback signal to modify production model behavior", "Not evaluating reward models for reward hacking vulnerability prior to RLHF training, resulting in unintended and hard-to-detect behavioral reinforcement", "Conflating individual labeler quality control with overall feedback distribution integrity monitoring, missing coordinated poisoning attacks where each individual labeler appears normal" ], "update_status": "current", "layer_code": "BH" }, { "id": "CR-01", "layer": "CR", "plane": "lifecycle", "name": "Continuous Production Monitoring and Risk Aggregation", "plain": "Aggregate all runtime signals — performance, drift, fairness, safety, and incident flags — into a unified risk dashboard with automated alerting thresholds so degradation is detected within one operational window.", "matrix_thesis": true, "thesis_type": "detective", "readiness": "approved", "threat": { "tags": [ "silent-model-degradation", "undetected-drift", "compliance-gap", "late-incident-detection" ], "desc": "Production models degrade silently. Without aggregated continuous monitoring, performance decay (AML.T0020 — Poison Training Data downstream effects), fairness regressions, and safety boundary violations accumulate undetected until regulatory examination or customer harm surfaces them. The risk aggregation gap means no single owner sees the full picture; individual teams observe local signals but the compound risk is invisible." }, "standard": [ { "id": "nist_rmf", "section": "MEASURE-2.4", "title": "Production monitoring of AI system functionality and behavior" }, { "id": "iso_42001", "section": "A.6.2.6", "title": "AI system operation and monitoring" }, { "id": "sr262", "section": "Sec. V", "title": "Model validation and monitoring — ongoing monitoring and outcomes analysis" }, { "id": "eu_ai_act", "section": "Art-72", "title": "Post-market monitoring by providers" } ], "sources": [ { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/CR-01 Continuous Production Monitoring and Risk Aggregation control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "title": "SR 26-2: Revised Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "canonical_url": "https://www.federalreserve.gov/supervisionreg/srletters/sr2602.htm", "license": "us-government-public-domain", "supersedes": "SR 11-7, SR 21-8", "status": "current", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/CR-01 Continuous Production Monitoring and Risk Aggregation control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-26", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "eur-lex-open-access", "status": "current", "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/CR-01 Continuous Production Monitoring and Risk Aggregation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Instrument all production inference endpoints with structured metric emission. Route metrics to a time-series store. Define alert thresholds per metric type. Maintain a risk-aggregation dashboard that combines performance, drift, fairness, safety, and incident signals into a single risk score updated on each operational window (typically ≤24h).", "steps": [ "Define metric taxonomy: performance (accuracy, latency, error rate), drift (PSI, KL-divergence on inputs), fairness (demographic parity delta), safety (refusal rate, toxicity flag rate), cost (inference cost per request) [ref:nist_ai_rmf_1_0]", "Instrument all serving endpoints with OpenTelemetry or equivalent to emit structured metric events at inference time", "Configure time-series retention: 90-day hot store, 3-year cold archive minimum for regulated contexts [ref:sr262_2026]", "Implement alert rules: performance metric outside baseline ±2σ triggers P2 alert; fairness delta >0.05 triggers P1; safety metric exceeds threshold triggers immediate escalation [ref:eu_ai_act_2024]", "Build aggregated risk dashboard combining all metric streams into a composite risk score; expose via read-only API to GRC consumers", "Test alert routing with synthetic anomaly injection quarterly; document test results as evidence artifact" ], "anti_patterns": [ "Monitoring only aggregate accuracy — misses subgroup regression and fairness drift", "Alert thresholds set once at deployment and never reviewed as baseline shifts", "Risk signals siloed per team with no cross-layer aggregation view", "Sampling rate too low (e.g., 0.1%) on high-volume endpoints — statistical power insufficient to detect rare-but-critical failures" ] }, "validation": { "design_check": [ "Verify metric taxonomy covers all five types: performance, drift, fairness, safety, cost [ref:nist_ai_rmf_1_0]", "Confirm alert thresholds are documented with rationale and signed by model owner [ref:sr262_2026]", "Confirm risk dashboard is accessible to GRC function with read-only access [ref:nist_ai_rmf_1_0]" ], "runtime_test": [ "Inject synthetic drift event; confirm P2 alert fires within one operational window [ref:nist_ai_rmf_1_0]", "Inject synthetic fairness violation; confirm P1 alert fires and escalation path is triggered [ref:eu_ai_act_2024]", "Verify cold-archive retrieval for a 24-month-old metric batch completes within SLA [unverified]" ], "evidence": [ "model:metric-taxonomy-document-signed-by-model — Metric taxonomy document signed by model owner [unverified]", "model:alert-threshold-rationale-document-with — Alert threshold rationale document with review date [unverified]", "model:quarterly-synthetic-anomaly-injection-te — Quarterly synthetic anomaly injection test report (artifact_hash: sha256:TBD) [unverified]" ] }, "lenses": { "engineering": "Instrument with OpenTelemetry; emit to time-series (Prometheus/ClickHouse); alert via PagerDuty or equivalent; 90-day hot retention.", "evaluation": "Review metric taxonomy at each evaluation cycle; recalibrate thresholds when baseline model is retrained.", "red_team": "Attempt to suppress monitoring signals via adversarial inputs; verify that evasion does not create a silent gap in the risk dashboard.", "grc": "Confirm risk dashboard covers all five metric types expected under SR 26-2 Sec. V (ongoing monitoring) and EU AI Act Art. 72; include dashboard in audit evidence package.", "mlops": "Build monitoring as code: thresholds in version control, alert configs deployed via IaC, dashboard definitions exported as JSON for reproducibility." }, "monitoring_schema": { "metrics": [ { "name": "composite_risk_score", "type": "performance", "threshold": { "op": "gt", "value": 0.7 }, "alert_level": "P1", "metric_id": "composite_risk_score", "metric_type": "performance", "measure": "composite-score", "population": "all-production-models", "comparison": { "operator": "greater-than", "value": 0.7, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "critical" }, { "name": "input_distribution_psi", "type": "drift", "threshold": { "op": "gt", "value": 0.2 }, "alert_level": "P2", "metric_id": "input_distribution_psi", "metric_type": "drift", "measure": "population-stability-index", "population": "all-production-models", "comparison": { "operator": "greater-than", "value": 0.2, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "high" }, { "name": "fairness_demographic_parity_delta", "type": "fairness", "threshold": { "op": "gt", "value": 0.05 }, "alert_level": "P1", "metric_id": "fairness_demographic_parity_delta", "metric_type": "fairness", "measure": "score-delta", "population": "all-production-models", "comparison": { "operator": "greater-than", "value": 0.05, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "critical" }, { "name": "safety_flag_rate", "type": "safety", "threshold": { "op": "gt", "value": 0.01 }, "alert_level": "P1", "metric_id": "safety_flag_rate", "metric_type": "safety", "measure": "flagging-rate", "population": "all-production-models", "comparison": { "operator": "greater-than", "value": 0.01, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "critical" }, { "name": "inference_cost_per_request_usd", "type": "cost", "threshold": { "op": "gt", "value": 0.05 }, "alert_level": "P3", "metric_id": "inference_cost_per_request_usd", "metric_type": "cost", "measure": "cost-per-request-usd", "population": "all-production-models", "comparison": { "operator": "greater-than", "value": 0.05, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" } ], "sampling_rate": "100%", "window_context": "24h rolling" }, "maturity": { "current": "none", "target": "defined" }, "coverage_note": "Aggregates signals from BH-01, BH-02, BH-03, EV-05, EV-06, EV-07, TG-05. Cross-references OA-04 escalation paths. Feeds CR-02 evidence archive.", "obligations": [ { "id": "OB-CR-01-EU", "framework": "eu_ai_act", "article": "Art-72", "requirement_summary": "Providers of high-risk AI systems must operate a post-market monitoring plan that actively collects, documents, and analyses data on the performance of AI systems throughout their lifetime.", "legal_status": "enacted", "applicability_conditions": [ { "field": "jurisdiction", "op": "eq", "value": "EU" } ], "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "jurisdiction": [ "eu" ], "provision": "Art-72", "effective_from": "2026-08-02" }, { "id": "OB-CR-01-SR", "framework": "sr262", "article": "Sec. V", "requirement_summary": "Ongoing monitoring must track model performance outcomes, input distributions, and material changes in the use environment. Results must be reviewed at a frequency commensurate with model risk.", "legal_status": "enacted", "applicability_conditions": [ { "field": "sector", "op": "eq", "value": "banking" }, { "field": "asset_size_usd", "op": "gte", "value": 30000000000 } ], "reviewed_on": "2026-06-26", "authority": "Federal Reserve System", "instrument": "SR 26-2", "source_ref": "sr262_2026", "normative_force": "supervisory-guidance", "jurisdiction": [ "us" ], "provision": "Sec. V", "effective_from": "2026-04-01" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-72", "mapping_fit": "partial", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "capability_risk": { "capability_level": "none", "autonomy": "bounded", "access_mode": "internal", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "low", "external_reach": false, "data_sensitivity": "internal", "notes": "risk level: elevated | relevant profiles: frontier-capability, high-impact-decision, continuously-learning | description: Monitoring gap compounds capability risk: the higher the system capability, the more damaging undetected degradation or deviation becomes." }, "canonical_id": "apeiris://model/controls/CR-01", "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. CR-01 aggregates production monitoring signals — performance, drift, fairness, safety, cost — into a single risk view with calibrated alert thresholds.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) requires monitoring the AI system in operation. CR-01 aggregates the operational monitoring signals — performance, drift, fairness, safety, cost — into one governed risk view.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "MDS-10", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CR-01 aggregates all runtime risk signals — performance, drift, fairness, safety, cost, and incident flags — into a unified composite risk dashboard with documented P1/P2 alerting thresholds calibrated at ±2σ from baseline, providing the continuous assurance posture view that MON-06's aggregated AI risk monitoring dashboard requirement specifies. The quarterly synthetic anomaly injection test and read-only GRC dashboard access ensure the risk aggregation function remains demonstrably operational and accessible to decision-makers throughout the model's production lifetime.", "source_locator": { "section": "Monitoring and Alerting" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "uncovered_portion": "MDS-10 additionally requires ongoing security event correlation, adversarial input monitoring, and model artifact integrity checks beyond the scope of this control.", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-72", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 72 requires high-risk AI system providers to establish, document, and implement a post-market monitoring plan; CR-01's continuous risk aggregation dashboard — collecting signals from BH-01 through BH-10 layers and applying tiered alerting calibrated at ±2σ from baseline — operationalizes the systematic performance collection and anomaly identification components of a post-market monitoring plan.", "uncovered_portion": "Art. 72 requires the post-market monitoring plan to be documented and submitted as part of conformity assessment, and to include systematic collection from market feedback channels; CR-01 addresses the technical monitoring aggregation layer only and does not cover documentation of the monitoring plan or feedback collection from external users.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. V", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes ongoing monitoring that surfaces performance problems and escalates material deterioration to appropriate stakeholders; CR-01's P1/P2/P3 tiered alert structure implements that expectation. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 applies to supervised banking organizations with $30B+ in assets. CR-01 does not address SR 26-2's back-testing requirements or qualitative model review components.", "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "monitoruse", "fit": "supporting", "rationale": "Aggregating performance, drift, fairness, and safety signals into a risk dashboard with alerting thresholds is monitoring model use for anomalies at scale.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0024", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"All runtime monitoring signals — performance, drift, fairness, safety incidents, and…\" enacts ATLAS mitigation AML.M0024 AI Telemetry Logging; OpenCRE crosswalks this control’s OWASP AI Exchange concept (monitoruse) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "validation_objective": "All runtime monitoring signals — performance, drift, fairness, safety incidents, and deployment event flags — must be continuously aggregated into a unified risk dashboard with pre-configured automated alerting thresholds; any degradation in a monitored dimension must be detected and an alert dispatched within one operational window.", "evidence_required": [ "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned" ], "machine_tests": [ "Inject a synthetic performance_degradation_event (accuracy drop below the configured alert threshold) into the monitoring pipeline → assert an alert fires within the defined operational window with correct signal_type and model_id", "Deploy a new model version without creating a monitoring configuration profile → assert the deployment pipeline rejects the version with error=missing_monitoring_config", "Disable an escalation_recipient channel for an active model → assert the monitoring health check detects the channel suppression and raises a monitoring_health_degraded alert" ], "human_review": [ "Review alert thresholds across all monitoring dimensions for calibration against acceptable performance bounds established in the model risk assessment and validated evaluation report", "Assess the risk aggregation methodology for completeness — confirm composite risk scores correctly reflect simultaneous degradation across multiple independent dimensions", "Verify post-market monitoring reports are generated on schedule, reviewed by a named risk owner, and that findings are actioned before the close of each monitoring period" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Operating separate monitoring dashboards per team (MLOps, fairness, security) without a unified risk aggregation layer, creating blind spots for cross-dimension degradation patterns", "Setting alert thresholds as fixed absolute values rather than as bounds derived from the model's validated acceptable performance range in the risk assessment", "Treating continuous monitoring as a deployment-time task that completes at go-live rather than an ongoing obligation covering the full production lifetime", "Not defining escalation routing per alert severity level, causing all alerts to enter the same queue and burying critical signals among low-priority notifications", "Generating post-market monitoring reports without routing them to a named risk owner for sign-off, leaving findings without a responsible party for remediation" ], "update_status": "current", "layer_code": "CR" }, { "id": "CR-02", "layer": "CR", "plane": "lifecycle", "name": "Model Evidence Archive and Audit Trail", "plain": "Maintain an immutable, content-addressed archive of all evaluation results, monitoring snapshots, incident records, and regulatory submissions so that any audit question can be answered with a tamper-evident evidence chain.", "matrix_thesis": true, "thesis_type": "corrective", "readiness": "approved", "threat": { "tags": [ "evidence-tampering", "audit-failure", "regulatory-non-compliance", "incident-attribution-loss" ], "desc": "Without an immutable evidence archive, post-incident investigation and regulatory examination cannot establish a reliable chain of custody. Adversaries (including insider threats) can alter or delete evaluation records after a harm event. EU AI Act Art. 12 and Art. 18 require records for high-risk AI systems, SR 26-2 Sec. VI describes documentation sufficient for supervisory examination, and ISO/IEC 42001 Clause 7.5 requires control of documented information that can demonstrate compliance retroactively. Loss of evidence is treated as a compliance failure equivalent to the underlying violation." }, "standard": [ { "id": "nist_rmf", "section": "GOVERN-1.4", "title": "Transparent, documented risk management outcomes" }, { "id": "iso_42001", "section": "7.5", "title": "Documented information" }, { "id": "sr262", "section": "Sec. VI", "title": "Governance and controls — documentation" }, { "id": "eu_ai_act", "section": "Art-12", "title": "Record-keeping" } ], "sources": [ { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-26", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "eur-lex-open-access", "status": "current", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/CR-02 Model Evidence Archive and Audit Trail control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "title": "SR 26-2: Revised Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "canonical_url": "https://www.federalreserve.gov/supervisionreg/srletters/sr2602.htm", "license": "us-government-public-domain", "supersedes": "SR 11-7, SR 21-8", "status": "current", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/CR-02 Model Evidence Archive and Audit Trail control.", "reviewed_on": "2026-07-01" }, { "id": "sigstore_rekor", "title": "Sigstore Rekor — Immutable Transparency Log", "authority": "Sigstore Project (OpenSSF)", "source_type": "product-documentation", "normative_force": "best-practice", "version": "1.3.0", "published_on": "2024-01-15", "retrieved_on": "2026-06-26", "canonical_url": "https://docs.sigstore.dev/logging/overview/", "license": "apache-2.0", "status": "current", "source_id": "sigstore_rekor", "relationship": "informative_reference", "rationale": "Establishes Sigstore Rekor — Immutable Transparency Log requirements informing the apeiris://model/controls/CR-02 Model Evidence Archive and Audit Trail control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Generate a content-addressed SHA-256 manifest for every evaluation artifact, monitoring snapshot, and incident record at creation time. Anchor the manifest hash to a transparency log (Sigstore Rekor or equivalent). Store the full artifact in append-only cold storage. Expose a read-only evidence retrieval API. Retention schedule: 3 years minimum; 10 years for regulated banking contexts.", "steps": [ "Define evidence artifact types: evaluation-manifest, monitoring-snapshot, incident-record, regulatory-submission, model-card-version [ref:eu_ai_act_2024]", "For each artifact at creation, compute artifact_hash = sha256:<64-hex> over the canonical JSON serialization (sorted keys, no trailing whitespace) [ref:nist_ai_rmf_1_0]", "Anchor artifact_hash to Sigstore Rekor transparency log; store the rekor_log_entry_uuid alongside the artifact [ref:sigstore_rekor]", "Write artifact and metadata to append-only object storage (S3 Object Lock COMPLIANCE mode or equivalent); no delete permission for any IAM role [ref:sr262_2026]", "Index artifacts in a queryable metadata store (artifact_id, control_ids[], date_range, audit_tags[]) for retrieval", "Implement evidence retrieval API: GET /evidence/{evidence_id} returns artifact + metadata + rekor proof; available to auditors with read-only credentials", "Test retrieval of 3-year-old artifact annually; document test result as a CR-02 runtime_test evidence item" ], "anti_patterns": [ "Storing evaluation records in a mutable database with no append-only enforcement", "Using artifact_hash: 'TBD' in production records — TBD must fail the validate:schema check", "Retention policy set per-team rather than at infrastructure level — inconsistent deletion risk", "Skipping transparency log anchoring for 'internal only' evaluations — all artifacts must be anchored" ] }, "validation": { "design_check": [ "Confirm object storage is configured with Object Lock in COMPLIANCE mode or equivalent; no IAM role can delete [ref:sr262_2026]", "Verify Sigstore Rekor anchoring is implemented for all artifact types [ref:sigstore_rekor]", "Confirm retention schedule is documented: 3-year default, 10-year for SR 26-2 banking contexts [ref:sr262_2026]" ], "runtime_test": [ "Attempt to delete an archived artifact; confirm the operation is rejected [ref:eu_ai_act_2024]", "Retrieve a transparency log proof for an archived artifact; verify the proof validates against the Rekor public key [ref:sigstore_rekor]", "Simulate a regulatory evidence request; confirm retrieval of all artifacts for a given model version within 4-hour SLA [unverified]" ], "evidence": [ "model:object-storage-compliance-mode-configura — Object storage COMPLIANCE mode configuration screenshot or IaC code reference [unverified]", "model:rekor-anchoring-integration-test-results — Rekor anchoring integration test results (artifact_hash: sha256:TBD) [unverified]", "model:annual-evidence-retrieval-test-report — Annual evidence retrieval test report [unverified]" ] }, "lenses": { "engineering": "Implement append-only S3 bucket with Object Lock COMPLIANCE; integrate Rekor client in the evaluation pipeline at artifact emit time.", "evaluation": "Every evaluation result — benchmark score, red-team report, bias audit — must generate a signed artifact before the evaluation is considered complete.", "red_team": "Attempt to retrieve an un-anchored artifact or forge an artifact_hash; verify the retrieval API rejects or flags tampered hashes.", "grc": "Evidence archive is the primary record for regulatory examinations under EU AI Act Art. 12 and SR 26-2 Sec. VI. GRC must review the retention schedule annually.", "mlops": "Build evidence emission into the CD pipeline: artifact creation, hash computation, Rekor anchoring, and index write must all complete before deployment gate passes." }, "monitoring_schema": { "metrics": [ { "name": "evidence_archive_gap_hours", "type": "safety", "threshold": { "op": "gt", "value": 4 }, "alert_level": "P1", "metric_id": "evidence_archive_gap_hours", "metric_type": "safety", "measure": "gap-measure", "population": "all-production-models", "comparison": { "operator": "greater-than", "value": 4, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "critical" }, { "name": "rekor_anchoring_failure_rate", "type": "safety", "threshold": { "op": "gt", "value": 0 }, "alert_level": "P1", "metric_id": "rekor_anchoring_failure_rate", "metric_type": "safety", "measure": "event-rate", "population": "all-production-models", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "critical" }, { "name": "evidence_retrieval_latency_p99_ms", "type": "performance", "threshold": { "op": "gt", "value": 30000 }, "alert_level": "P2", "metric_id": "evidence_retrieval_latency_p99_ms", "metric_type": "performance", "measure": "latency-percentile", "population": "all-production-models", "comparison": { "operator": "greater-than", "value": 30000, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "high" } ], "sampling_rate": "100%", "window_context": "real-time" }, "maturity": { "current": "none", "target": "defined" }, "coverage_note": "Receives artifacts from all 53 other controls. Is cited as the primary evidence store by LI-01, LI-06, EV-01, EV-03, EV-08, OA-07, BH-01, BH-09. Feeds CR-05 regulatory submissions.", "obligations": [ { "id": "OB-CR-02-EU", "framework": "eu_ai_act", "article": "Art-12", "requirement_summary": "Providers of high-risk AI systems shall keep logs generated automatically by the AI system to the extent such logs are under their control, for a period appropriate to the intended purpose of the AI system.", "legal_status": "enacted", "applicability_conditions": [ { "field": "jurisdiction", "op": "eq", "value": "EU" } ], "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "jurisdiction": [ "eu" ], "provision": "Art-12", "effective_from": "2026-08-02" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-11", "mapping_fit": "partial", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "capability_risk": { "capability_level": "none", "autonomy": "bounded", "access_mode": "internal", "irreversibility": "reversible", "deployment_scale": "enterprise", "affected_party_impact": "low", "external_reach": false, "data_sensitivity": "internal", "notes": "risk level: elevated | relevant profiles: frontier-capability, eu-high-risk, us-regulated-banking | description: Frontier-capability systems require deeper evidence chains including dangerous capability evaluation manifests; evidence archive must support structured findings sub-arrays." }, "canonical_id": "apeiris://model/controls/CR-02", "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-1.4 (GOVERN function) provides that the risk management process and its outcomes are established through transparent policies, procedures, and controls. CR-02’s immutable, content-addressed evidence archive preserves the documented outcomes of the risk management process so they remain reviewable and transparent over time.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "7.5", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CR-02 creates and maintains documented information for every AI system lifecycle event — evaluation manifests, monitoring snapshots, incident records, and regulatory submissions — in an immutable, content-addressed archive with SHA-256 hash verification and defined retention schedules of 3-year default and 10-year banking, directly satisfying ISO 42001 Clause 7.5's requirements for documented information necessary for the effectiveness of the AI management system. The Sigstore Rekor transparency-log anchoring provides the integrity assurance that Clause 7.5 requires for retained documented information.", "uncovered_portion": "Clause 7.5 encompasses the full documented information lifecycle including creation, update, distribution, and disposal of management system documentation; CR-02 covers only the evidence retention and tamper-evident archival dimension and does not address creation and update governance for management system documents such as policies and procedures.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "LOG-10", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CSA AICM LOG-10 (Audit Records Protection) requires audit records to be protected from alteration and deletion. CR-02’s content-addressed archive with transparency-log anchoring and object-lock storage provides that protection with cryptographic verifiability.", "source_locator": { "control_id": "LOG-10" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-11", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 11 requires providers of high-risk AI systems to draw up technical documentation that includes records of evaluation results and post-market monitoring findings; CR-02's immutable content-addressed evidence archive — anchored to Sigstore Rekor and locked with S3 Object Lock COMPLIANCE mode — provides the tamper-evident records infrastructure required to produce and maintain the Art. 11 technical documentation over the required retention period.", "uncovered_portion": "Art. 11 requires a structured technical documentation package covering model description, general information, capability and limitations, training data, design specifications, and post-market monitoring results; CR-02 addresses archival and integrity of evidence artifacts but does not generate the technical documentation package itself.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. VI", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. VI (Governance and Controls) describes comprehensive model documentation that supports ongoing monitoring, audit, and supervisory examination; CR-02's immutable evidence archive preserves those records with verifiable integrity. The guidance does not itself set retention periods. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 applies to supervised banking organizations with $30B+ in assets. SR 26-2 §IV.D also requires documentation of model development theory and validation methodology, which is covered by LI-04 and EV-06, not CR-02.", "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" } ], "validation_objective": "All evaluation results, monitoring snapshots, incident records, and regulatory submissions must be stored in an immutable, content-addressed archive with cryptographic integrity protection; any audit query for a model's historical evidence must resolve to a complete, tamper-evident chain spanning the full production lifetime of that model version.", "evidence_required": [ "archive_integrity_configuration_record showing content-addressed storage settings, hash algorithm (minimum SHA-256), write-once immutability enforcement, and retention policy duration per record type", "evidence_chain_completeness_audit confirming that evaluation results, monitoring snapshots, and incident records for each production model version are present in the archive with no missing lifecycle entries", "tamper_detection_scan_report from periodic archive integrity verification showing all stored records produce matching content hashes with zero reported mismatches", "regulatory_submission_evidence_linkage_record linking each regulatory submission to its archived evidence artifact with submission_id, submission_date, submitting_entity, and archive_content_hash", "archive_access_control_audit_log confirming write operations are restricted to authorized pipeline components only and all access attempts are logged with actor_id and timestamp" ], "machine_tests": [ "Attempt to overwrite an archived evaluation record via the archive API → assert the operation is rejected with error=immutable_archive_write_denied and an integrity_violation_attempt is logged", "Query the archive for all evaluation results associated with a specific model_version_id → assert the response includes a complete, unbroken chain from initial evaluation through all monitoring periods with no gaps", "Run a full archive integrity verification scan → assert all stored records produce matching content hashes and the scan report shows zero integrity mismatches", "Attempt to write to the archive using an unauthorized service account credential → assert the write is rejected with error=unauthorized_archive_write and the attempt is logged with actor_id" ], "human_review": [ "Review archive retention policy for compliance with the longest-applicable regulatory retention requirement across all governing frameworks (EU AI Act, SR 26-2, ISO 42001)", "Assess evidence chain completeness for a sample of model versions across their full lifecycle — confirm no gaps between evaluation phases, monitoring periods, and incident records exist", "Verify that access control audit logs are reviewed on a defined schedule and that unauthorized access attempts trigger a documented investigation procedure" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Storing evaluation results in mutable file systems or relational databases without write-once guarantees, allowing records to be altered or deleted without detection", "Using sequential database identifiers instead of content-addressed storage, making it cryptographically impossible to detect record tampering after the fact", "Archiving evaluation results but not monitoring snapshots and incident records, creating gaps that prevent complete lifecycle audit trail reconstruction", "Not linking regulatory submissions to their specific archived evidence artifacts, making it impossible to reconstruct the evidence basis for past submissions under audit", "Granting broad write access to the archive to simplify pipeline integration, undermining the tamper-evident integrity properties required for regulatory defensibility" ], "update_status": "current", "layer_code": "CR" }, { "id": "CR-03", "layer": "CR", "plane": "lifecycle", "name": "Scheduled Model Re-validation", "plain": "Run full benchmark, bias, and safety evaluation suites on a defined schedule — not only at deployment — so that performance changes that occur post-deployment due to distribution shift, world-knowledge changes, or infrastructure updates are caught before they reach harm thresholds.", "thesis_type": "corrective", "readiness": "approved", "threat": { "tags": [ "silent-model-degradation", "distribution-shift", "world-knowledge-staleness", "infrastructure-induced-regression" ], "desc": "Post-deployment model behavior changes through mechanisms outside any single deployment event: the world changes (facts become stale), input distribution shifts, library updates alter numeric precision, and hardware firmware updates alter floating-point behavior. Without scheduled re-validation, these cumulative changes can push a model across a safety or regulatory threshold long after the last formal evaluation. SR 26-2 Sec. V describes ongoing monitoring and periodic review; EU AI Act Art. 43 requires conformity re-assessment when substantial modifications occur." }, "standard": [ { "id": "nist_rmf", "section": "MEASURE-2.6", "title": "Regular safety evaluation of the AI system" }, { "id": "sr262", "section": "Sec. V", "title": "Model validation and monitoring — periodic review" }, { "id": "eu_ai_act", "section": "Art-43", "title": "Conformity assessment" }, { "id": "iso_42001", "section": "A.6.2.4", "title": "AI system verification and validation" } ], "sources": [ { "id": "sr262_2026", "title": "SR 26-2: Revised Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "canonical_url": "https://www.federalreserve.gov/supervisionreg/srletters/sr2602.htm", "license": "us-government-public-domain", "supersedes": "SR 11-7, SR 21-8", "status": "current", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/CR-03 Scheduled Model Re-validation control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-26", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "eur-lex-open-access", "status": "current", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/CR-03 Scheduled Model Re-validation control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "source_type": "voluntary-standard", "retrieved_on": "2026-06-26", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "status": "current", "authority": "NIST", "license": "public-domain", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/CR-03 Scheduled Model Re-validation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define re-validation cadences by model risk tier: Tier 1 (frontier/high-impact) quarterly, Tier 2 (standard predictive) semi-annually, Tier 3 (low-risk) annually. Re-validation runs the full evaluation suite from EV-01 through EV-10. Results are archived via CR-02. Trigger unscheduled re-validation on: CR-01 P1 alert, significant input distribution shift (PSI >0.25), or provider-announced model update.", "steps": [ "Assign each deployed model a risk tier (1/2/3) in the assurance target registry; document tier rationale [ref:sr262_2026]", "Schedule automated re-validation pipeline runs at cadence determined by tier; pipeline is identical to pre-deployment evaluation suite", "Re-validation results compared to baseline evaluation results; delta report generated and signed", "Delta report archived in CR-02 evidence archive; if any metric degrades beyond threshold, trigger CR-04 incident response [ref:eu_ai_act_2024]", "For EU high-risk: if re-validation reveals substantial modification as defined in Art. 43, initiate conformity re-assessment process [ref:eu_ai_act_2024]", "Re-validation schedule and results exposed in model card (LI-04); model card re-published after each re-validation" ], "anti_patterns": [ "Treating initial deployment evaluation as sufficient for the model lifecycle", "Risk tier assignment done once and never reviewed as the use case expands", "Re-validation pipeline different from pre-deployment pipeline — inconsistent baselines", "Skipping re-validation when the model weights haven't changed but serving infrastructure has" ] }, "validation": { "design_check": [ "Confirm risk tier assignments exist for all deployed models in the assurance target registry [ref:sr262_2026]", "Verify re-validation pipeline is identical to pre-deployment evaluation pipeline (same benchmark suite, same datasets) [ref:nist_ai_rmf_1_0]", "Confirm EU high-risk models have a documented conformity re-assessment trigger for substantial modifications [ref:eu_ai_act_2024]" ], "runtime_test": [ "Trigger an unscheduled re-validation via CR-01 P1 alert simulation; confirm pipeline executes within 24h [ref:sr262_2026]", "Review last 4 re-validation reports for a Tier-1 model; confirm all were completed within quarterly cadence [ref:sr262_2026]", "Verify delta report is automatically archived in CR-02 and retrievable [unverified]" ], "evidence": [ "model:risk-tier-assignment-register-with-ratio — Risk tier assignment register with rationale (artifact_hash: sha256:TBD) [unverified]", "model:quarterly-re-validation-pipeline-executi — Quarterly re-validation pipeline execution logs for all Tier-1 models [unverified]", "model:delta-reports-for-last-two-re-validation — Delta reports for last two re-validation cycles per deployed model [unverified]" ] }, "lenses": { "engineering": "Implement re-validation as an automated CI/CD pipeline stage triggered by scheduler and by alert webhook. Pin all benchmark dataset versions to prevent evaluation drift.", "evaluation": "Re-validation must use the same benchmark datasets as pre-deployment evaluation (LI-06 immutable versioning). Any dataset change requires a new baseline establishment.", "red_team": "Verify that re-validation includes adversarial robustness and red-team evaluation, not only benchmark accuracy.", "grc": "Re-validation schedule aligns with SR 26-2 Sec. V ongoing-monitoring and periodic-review guidance (supervisory guidance, not binding law). Document tier assignments and cadence in model risk register. Track overdue re-validations as open findings.", "mlops": "Re-validation pipeline should be idempotent and runnable on demand. Build result archiving into the pipeline exit step; failed archiving should fail the pipeline." }, "monitoring_schema": { "metrics": [ { "name": "days_since_last_revalidation", "type": "safety", "threshold": { "op": "gt", "value": 90 }, "alert_level": "P2", "metric_id": "days_since_last_revalidation", "metric_type": "safety", "measure": "days-elapsed", "population": "all-production-models", "comparison": { "operator": "greater-than", "value": 90, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "high" }, { "name": "revalidation_delta_accuracy", "type": "performance", "threshold": { "op": "decrease-greater-than", "value": 0.05 }, "alert_level": "P1", "metric_id": "revalidation_delta_accuracy", "metric_type": "performance", "measure": "score-delta", "population": "all-production-models", "comparison": { "operator": "decrease-greater-than", "value": 0.05, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "critical" }, { "name": "conformity_reassessment_overdue", "type": "safety", "threshold": { "op": "gt", "value": 0 }, "alert_level": "P1", "metric_id": "conformity_reassessment_overdue", "metric_type": "safety", "measure": "overdue-days", "population": "all-production-models", "comparison": { "operator": "greater-than", "value": 0, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "critical" } ], "sampling_rate": "per-run", "window_context": "90d rolling" }, "maturity": { "current": "none", "target": "developing" }, "coverage_note": "Extends EV-01 through EV-10; re-validation results feed CR-02. Triggers CR-04 on threshold breach. For EU high-risk systems, links to LI-04 model card republication.", "canonical_id": "apeiris://model/controls/CR-03", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.6 (MEASURE function) provides that the AI system is evaluated regularly for safety risks, demonstrated to be safe within risk tolerance, and able to fail safely. CR-03’s scheduled re-validation re-runs the safety and evaluation suites on a defined cadence, keeping the regular safety evaluation this subcategory requires current.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.4 (AI system verification and validation) requires validation evidence to remain valid; CR-03’s scheduled re-validation re-produces that evidence on a risk-tiered cadence.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "A&A-02", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CSA AICM A&A-02 (Independent Assessments) requires periodic independent assessment of controls and systems. CR-03’s scheduled re-validation — full benchmark, bias, and safety suites on a risk-tiered cadence with signed delta reports — implements that recurring assessment for models.", "source_locator": { "section": "Evaluation and Validation" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "owasp_aitg", "requirement_id": "AITG-MOD-06", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AITG-MOD-06 (Testing for Robustness to New Data) verifies that model quality holds as the world changes. CR-03's scheduled re-validation re-runs the benchmark, bias, and safety suites to produce current robustness evidence on a defined cadence.", "source_locator": { "test_id": "AITG-MOD-06", "test_name": "Testing for Robustness to New Data" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-72", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 72 requires high-risk AI system providers to establish post-market monitoring systems that systematically collect and analyse data about model performance; CR-03's scheduled re-evaluation cadence and event-driven re-evaluation triggers directly implement the continuous monitoring and periodic review requirements that underpin Art. 72 compliance.", "uncovered_portion": "Art. 72 specifies that the post-market monitoring plan must be part of the quality management system and documented in technical documentation; CR-03 governs the scheduling and triggering logic but does not produce the plan documentation or integrate with the formal conformity assessment record.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. V", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes ongoing monitoring and periodic review so that validation conclusions remain current; CR-03's scheduled re-evaluation cadence operationalizes periodic review for deployed models. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 applies to supervised banking organizations with $30B+ in assets. SR 26-2 §III.C.2 also requires qualitative re-assessment of conceptual soundness, which is not addressed by CR-03's quantitative trigger mechanisms.", "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "continuousvalidation", "fit": "direct", "rationale": "Running full benchmark, bias, and safety suites on a recurring schedule post-deployment is the continuously-validate-the-model control.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0008", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"A full benchmark, bias, and safety evaluation suite must execute against every production…\" enacts ATLAS mitigation AML.M0008 Validate AI Model; OpenCRE crosswalks this control’s OWASP AI Exchange concept (continuousvalidation) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-72", "mapping_fit": "partial", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "A full benchmark, bias, and safety evaluation suite must execute against every production model version on the defined re-validation schedule; results must be compared to the deployment-time baseline metrics, and any performance degradation beyond configured thresholds must trigger a formal response documented and initiated before the next operational window closes.", "evidence_required": [ "re_validation_schedule_record per model version showing configured re-validation frequency, last_run_timestamp, next_run_due, and scheduled_suite_identifier with no unmonitored production versions", "scheduled_evaluation_report for each re-validation run showing benchmark results, bias metrics, and safety evaluation scores with explicit comparison to the deployment-time baseline", "threshold_comparison_record showing the delta between current re-validation results and baseline for each metric with a pass/fail determination against the configured degradation threshold", "re_validation_response_record for any threshold breach, documenting the triggered response action (rollback, retraining, or escalation), responsible_party, and closure_timestamp", "re_validation_coverage_audit confirming all active production model versions are enrolled in re-validation schedules and that no version has exceeded its next_run_due without a completed run" ], "machine_tests": [ "Advance a model's next_run_due timestamp to the past without a completed re_validation_report in the archive → assert the monitoring system raises a re_validation_overdue alert with model_version_id and days_overdue", "Inject a synthetic re-validation result showing accuracy 8% below the deployment-time baseline (assuming a 5% degradation threshold) → assert a threshold_breach_event is created and a response workflow is initiated", "Deploy a new model version and query the re-validation schedule registry → assert the version appears with a scheduled next_run_due within the configured maximum re-validation interval" ], "human_review": [ "Review re-validation schedule frequency against model risk classification — confirm higher-risk models in dynamic environments are scheduled more frequently than the minimum interval defined in the policy", "Assess the scheduled evaluation suite for coverage completeness against the original deployment evaluation — confirm no benchmark dimension, bias category, or safety test has been omitted or simplified", "Verify that re_validation_response_records for past threshold breaches are closed with documented remediation actions and are not left indefinitely open without a responsible party" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Running re-validation only when a model is being replaced or retired rather than on a proactive scheduled interval throughout the production lifetime", "Using a reduced or simplified evaluation suite for scheduled re-validation rather than the same full benchmark, bias, and safety suite used at initial deployment", "Comparing re-validation results to the most recent prior re-validation result instead of the deployment-time baseline, masking gradual cumulative performance degradation", "Not enrolling newly deployed model versions in the re-validation schedule at deployment time, creating unmonitored production versions", "Treating threshold breach alerts as informational without a required response workflow, allowing degraded models to remain in production past the next operational window" ], "update_status": "current", "layer_code": "CR" }, { "id": "CR-04", "layer": "CR", "plane": "lifecycle", "name": "AI Incident Response Management", "plain": "Define, test, and execute a documented AI-specific incident response plan that covers model-caused harms, safety threshold breaches, and adversarial attack events — with clear escalation paths, containment playbooks, and post-incident review requirements.", "thesis_type": "corrective", "readiness": "approved", "threat": { "tags": [ "uncontained-model-harm", "slow-incident-escalation", "regulatory-notification-failure", "adversarial-attack-response-gap" ], "desc": "AI incidents differ from software incidents: they are often ambiguous in onset, may affect many users simultaneously before detection, and regulatory obligations (EU AI Act Art. 73, SR 26-2 S-6) require notification within defined time windows. Without an AI-specific incident response plan, general IT incident playbooks will be applied by responders who may not understand model-specific containment options (rollback, traffic shaping, output filtering enforcement), causing extended harm duration and regulatory notification failure." }, "standard": [ { "id": "nist_rmf", "section": "MANAGE-4.1", "title": "Post-deployment monitoring, incident response, and recovery" }, { "id": "sr262", "section": "Sec. V", "title": "Model validation and monitoring — escalation of monitoring findings" }, { "id": "eu_ai_act", "section": "Art-73", "title": "Reporting of serious incidents" }, { "id": "iso_42001", "section": "10.2", "title": "Nonconformity and corrective action" } ], "sources": [ { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-26", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "eur-lex-open-access", "status": "current", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/CR-04 AI Incident Response Management control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "title": "SR 26-2: Revised Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "canonical_url": "https://www.federalreserve.gov/supervisionreg/srletters/sr2602.htm", "license": "us-government-public-domain", "supersedes": "SR 11-7, SR 21-8", "status": "current", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/CR-04 AI Incident Response Management control.", "reviewed_on": "2026-07-01" }, { "id": "mitre_atlas_v5_6_0", "title": "MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems", "authority": "MITRE Corporation", "source_type": "threat-knowledge-base", "normative_force": "best-practice", "version": "5.6.0", "published_on": "2024-10-01", "retrieved_on": "2026-06-26", "canonical_url": "https://atlas.mitre.org", "license": "apache-2.0", "status": "current", "source_id": "mitre_atlas", "relationship": "informative_reference", "rationale": "Establishes MITRE ATLAS v5.6.0 — Adversarial Threat Landscape for Artificial-Intelligence Systems requirements informing the apeiris://model/controls/CR-04 AI Incident Response Management control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "source_type": "voluntary-standard", "retrieved_on": "2026-06-26", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "status": "current", "authority": "NIST", "license": "public-domain", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/CR-04 AI Incident Response Management control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Maintain an AI Incident Response Plan (AIRP) as a versioned document. Define 4 severity levels (P1: immediate user harm or regulatory trigger; P2: threshold breach without confirmed user harm; P3: anomaly with investigation required; P4: informational). Define containment playbooks for: model rollback, traffic shaping, output filtering override, full model shutdown. Run tabletop exercises quarterly. Integrate with CR-05 for regulatory notification triggers.", "steps": [ "Draft AI Incident Response Plan with severity classification criteria, escalation contacts, and notification timelines [ref:eu_ai_act_2024]", "Define containment playbooks specific to AI model incidents: (1) rollback to prior version via LI-06, (2) output-filter enforcement via BH-10, (3) traffic shaping to reduce exposure, (4) full model shutdown with fallback path [ref:sr262_2026]", "Map severity levels to regulatory notification triggers: P1 events that meet EU AI Act Art. 73 'serious incident' definition trigger CR-05 within the Art. 73 deadline (15 days generally; 10 days for death; 2 days for widespread infringement or critical-infrastructure incidents) [ref:eu_ai_act_2024]", "Establish post-incident review process: 5-day post-incident report for P1/P2, covering root cause, impact scope, timeline, and remediation [ref:nist_ai_rmf_1_0]", "Test AIRP via tabletop exercise quarterly using MITRE ATLAS adversarial scenario cards; document exercise results [ref:mitre_atlas_v5_6_0]", "Archive all incident records, post-incident reports, and exercise results in CR-02 evidence archive" ], "anti_patterns": [ "Using a generic IT security incident response plan without AI-specific containment options", "Severity classification that requires human judgment without defined criteria — leads to inconsistent escalation", "Post-incident review conducted only after P1 events — P2 and P3 reviews often reveal systemic patterns", "No pre-defined fallback path for full model shutdown — results in extended harm while engineering implements a workaround" ] }, "validation": { "design_check": [ "Confirm AI Incident Response Plan exists as a versioned, reviewed document [ref:nist_ai_rmf_1_0]", "Verify containment playbooks cover all four options: rollback, filtering, traffic shaping, shutdown [ref:sr262_2026]", "Confirm EU Art. 73 notification trigger is documented with the correct Art. 73 timeline per incident class (15d general / 10d death / 2d widespread or critical infrastructure) [ref:eu_ai_act_2024]" ], "runtime_test": [ "Execute tabletop exercise using AML.T0020 (Poison Training Data) scenario; verify containment playbook execution and notification timeline [ref:mitre_atlas_v5_6_0]", "Review last 12 months of incident records; confirm all P1/P2 events have 5-day post-incident reports [ref:sr262_2026]", "Simulate a P1 severity event in staging; confirm CR-05 notification workflow is triggered [unverified]" ], "evidence": [ "model:current-ai-incident-response-plan-versi — Current AI Incident Response Plan (version-controlled, signed by CISO/AI risk owner) [unverified]", "model:last-4-tabletop-exercise-reports-artifa — Last 4 tabletop exercise reports (artifact_hash: sha256:TBD) [unverified]", "model:post-incident-reports-for-any-p1-events — Post-incident reports for any P1 events in last 12 months [unverified]" ] }, "lenses": { "engineering": "Implement model rollback as a one-command operation (LI-06 prerequisite). Build output-filter enforcement as an emergency flag in the inference pipeline that can be set without redeployment.", "evaluation": "After each P1/P2 incident, run targeted evaluation to understand the performance envelope that led to the incident; feed findings into EV-03 dangerous capability registry if applicable.", "red_team": "Use MITRE ATLAS adversarial scenarios in tabletop exercises. Specifically test AML.T0020 (poisoning), AML.T0051 (prompt injection), and AML.T0044 (model access) response paths.", "grc": "AIRP must be reviewed and approved by legal, compliance, and AI risk functions annually. Regulatory notification triggers must be reviewed by legal counsel for each jurisdiction.", "mlops": "Incident response automation: auto-rollback on P1 CR-01 alert if auto_rollback_enabled flag is set. Paging integrations must reach on-call ML engineer within 5 minutes." }, "maturity": { "current": "none", "target": "developing" }, "coverage_note": "Triggered by CR-01 P1/P2 alerts and CR-03 threshold breaches. Triggers CR-05 for regulatory notifications. References BH-10 (output filtering), LI-06 (rollback), OA-04 (oversight escalation). Post-incident reports archived in CR-02.", "canonical_id": "apeiris://model/controls/CR-04", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "monitoring_schema": { "metrics": [ { "metric_id": "cr-04-pass-rate", "metric_type": "performance", "measure": "control-verification-pass-rate", "population": "all-assessed-deployments", "comparison": { "operator": "lt", "value": 1, "window": "30d", "evaluation_mode": "batch" }, "severity": "critical" } ], "sampling_rate": "100%", "window_context": "rolling-30d" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MANAGE-4.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MANAGE-4.1 (MANAGE function) provides that post-deployment monitoring plans are implemented, including appeal and override, decommissioning, incident response, and change management. CR-04’s AI-specific incident response plan implements the incident-response and recovery components of post-deployment risk management, tested through recurring tabletop exercises.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "10.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 Clause 10.2 (Nonconformity and corrective action) requires responding to nonconformities and correcting root causes. CR-04’s incident response plan, containment playbooks, and post-incident reviews implement that cycle for AI incidents.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "SEF-03", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CR-04 defines and maintains an AI-specific Incident Response Plan covering four severity levels with model-specific containment playbooks for rollback, output-filter enforcement, traffic shaping, and full shutdown with fallback — mapping P1 events to EU AI Act Art. 73 notification triggers in CR-05 and requiring 5-day post-incident reviews for P1/P2 events — directly implementing IR-02's AI-specific incident response plan requirement for detection, containment, remediation, and recovery. The quarterly MITRE ATLAS tabletop exercises with signed results archives provide the testing evidence that IR-02 requires to demonstrate the plan is operationally viable.", "source_locator": { "section": "Incident Response and Recovery" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-73", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 73 requires providers of high-risk AI systems to report serious incidents to national market surveillance authorities without undue delay; CR-04's model-specific incident response management — including P1/P2/P3 severity classification, mean-time-to-respond SLAs, and structured incident post-mortems — supports the incident triage and escalation processes required upstream of regulatory notification.", "uncovered_portion": "Art. 73 specifies notification must go to national competent authorities within defined timeframes and include prescribed content; CR-04 addresses internal incident management and does not implement the regulatory notification workflow, which is addressed by CR-06.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. V", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes escalating material model performance issues identified through monitoring; CR-04's incident management framework provides adjacent coverage of that escalation expectation. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 applies to supervised banking organizations with $30B+ in assets. SR 26-2 does not specifically address AI model-specific incident response; this is an interpretive analog.", "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "secprogram", "fit": "partial", "rationale": "An AI-specific incident response plan with containment playbooks and tabletop exercises is part of a security program covering the AI lifecycle.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-73", "mapping_fit": "partial", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "The organization must have a documented, version-controlled AI Incident Response Plan (AIRP) with AI-specific containment playbooks covering model rollback, output-filter enforcement, traffic shaping, and full model shutdown — tested via at least four quarterly tabletop exercises per year using MITRE ATLAS adversarial scenarios — and P1/P2 post-incident review records produced within 5 days of event resolution for all qualifying events in the trailing 12 months.", "evidence_required": [ "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)" ], "machine_tests": [ "Query CR-02 archive for artifact type=airp with version_date > (today minus 366 days) → assert at least one current signed AIRP artifact exists", "Parse containment_playbooks[] field in most recent AIRP artifact → assert entries exist for each of: model_rollback, output_filter_enforcement, traffic_shaping, model_shutdown", "Query CR-02 for tabletop_exercise_report artifacts with created_at > (today minus 366 days) → assert count >= 4 and each record has status=completed and reviewer_signature present", "Query P1_P2_incident_records[] → for each record assert post_incident_report_date is within 5 calendar days of incident_resolved_date" ], "human_review": [ "Review each containment playbook for operational completeness: confirm the runbook provides step-by-step instructions an on-call responder without prior AI incident context could execute under time pressure without requiring real-time engineering escalation", "Assess tabletop exercise scenarios for adversarial AI coverage: verify that scenarios include at least one AML.T0020 (training data poisoning), AML.T0051 (prompt injection), and AML.T0044 (full model access) scenario card across the four annual exercises", "Verify that EU Art. 73 notification triggers have been reviewed by legal counsel and reflect current regulatory interpretation for every jurisdiction where a high-risk AI system is deployed" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Adapting an existing IT security incident response plan for AI incidents by appending a 'model section' without defining AI-specific containment playbooks or severity criteria calibrated to model harm onset patterns", "Conducting tabletop exercises only at AIRP launch and treating the plan as perpetually tested, rather than maintaining quarterly cadence with updated MITRE ATLAS adversarial scenario cards", "Using severity classification criteria that require subjective professional judgment rather than pre-defined, measurable thresholds — leading to inconsistent P1/P2 designation and missed regulatory notification windows", "Defining the EU Art. 73 notification trigger in CR-05 independently from the incident severity criteria in CR-04, creating a workflow gap where a P1 event can be closed without verifying whether the applicable Art. 73 notification window (15d/10d/2d by incident class) was opened", "No pre-authorized decision chain for model shutdown execution, requiring real-time executive approval during an active P1 incident and extending harm duration" ], "update_status": "current", "layer_code": "CR" }, { "id": "CR-05", "layer": "CR", "plane": "lifecycle", "name": "Regulatory Notification and Statutory Reporting", "plain": "Execute mandatory regulatory notifications and statutory disclosures within prescribed timelines whenever an AI system incident, substantial modification, or capability threshold event occurs — with pre-drafted templates, a designated regulatory liaison, and a notification audit trail.", "thesis_type": "directive", "readiness": "approved", "threat": { "tags": [ "regulatory-notification-failure", "statutory-deadline-miss", "enforcement-action-risk", "cross-jurisdiction-compliance-gap" ], "desc": "Missing regulatory notification timelines is a distinct legal violation that compounds the underlying incident. EU AI Act Art. 73 requires providers to notify market surveillance authorities of serious incidents without undue delay. SR 26-2 Sec. VI describes model risk reporting to senior management and the board (supervisory guidance rather than a statutory notification duty). Notification failures are independently sanctionable and represent reputational harm beyond the original model incident." }, "standard": [ { "id": "eu_ai_act", "section": "Art-73", "title": "Reporting of serious incidents" }, { "id": "sr262", "section": "Sec. VI", "title": "Governance and controls — board and senior management reporting" }, { "id": "nist_rmf", "section": "GOVERN-4.3", "title": "Incident identification and information sharing" } ], "sources": [ { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-26", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "eur-lex-open-access", "status": "current", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/CR-05 Regulatory Notification and Statutory Reporting control.", "reviewed_on": "2026-07-01" }, { "id": "sr262_2026", "title": "SR 26-2: Revised Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "supervisory-guidance", "version": "SR 26-2", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "canonical_url": "https://www.federalreserve.gov/supervisionreg/srletters/sr2602.htm", "license": "us-government-public-domain", "supersedes": "SR 11-7, SR 21-8", "status": "current", "source_id": "sr26_2", "relationship": "supporting_guidance", "rationale": "Establishes SR 26-2: Revised Guidance on Model Risk Management requirements informing the apeiris://model/controls/CR-05 Regulatory Notification and Statutory Reporting control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Maintain a regulatory notification matrix mapping trigger events to jurisdictions, notification timelines, designated liaison contacts, and template references. Integrate notification workflow into CR-04 incident response so that P1 events automatically initiate a notification task with a countdown timer. Store all notifications and their delivery confirmations in CR-02 evidence archive.", "steps": [ "Build regulatory notification matrix: columns = jurisdiction, authority, trigger_event, timeline_days, liaison_contact, template_ref [ref:eu_ai_act_2024]", "EU high-risk systems: map Art. 73 'serious incident' criteria to CR-04 severity classification; P1 with user harm or rights impact triggers Art. 73 notification (15 days generally; 10 days for death; 2 days for widespread infringement or critical-infrastructure incidents) [ref:eu_ai_act_2024]", "US banking: align CR-04 escalation levels with the institution's internal model-risk reporting expectations to senior management and the board (SR 26-2 Sec. VI), with immediate escalation for material events [ref:sr262_2026]", "Pre-draft notification templates for each regulatory authority; have templates reviewed by legal counsel annually", "Automate notification task creation in CR-04 workflow for P1 events meeting notification criteria; assign countdown timer; page regulatory liaison", "Archive notification submission, delivery confirmation, and any regulatory response in CR-02 with artifact_hash" ], "anti_patterns": [ "Relying on legal team to know when notifications are required — notification triggers must be pre-defined, not situation-dependent", "Single regulatory liaison with no backup — key person dependency in a time-sensitive workflow", "Notification matrix not reviewed after new regulations take effect — stale matrix is a compliance gap", "Treating SR 26-2 as binding law in the notification matrix — it is supervisory guidance (legal_status: enacted, normative_force: guidance)" ] }, "validation": { "design_check": [ "Confirm regulatory notification matrix covers all jurisdictions in which the system is deployed [ref:eu_ai_act_2024]", "Verify legal counsel has reviewed notification triggers and timelines in last 12 months [ref:sr262_2026]", "Confirm notification workflow is integrated into CR-04 P1 escalation path [ref:eu_ai_act_2024]" ], "runtime_test": [ "Simulate a P1 incident in the EU jurisdiction; verify Art. 73 notification task is created with the correct countdown for the incident class (15d general / 10d death / 2d widespread or critical infrastructure) [ref:eu_ai_act_2024]", "Review all notification records in CR-02 for last 12 months; confirm delivery confirmations are present [ref:sr262_2026]", "Confirm notification matrix was updated within 30 days of EU AI Act Art. 50 effective date (August 2026) [unverified]" ], "evidence": [ "model:current-regulatory-notification-matrix — Current regulatory notification matrix (version-controlled, legal-reviewed, dated) [unverified]", "model:all-notification-submissions-and-deliver — All notification submissions and delivery confirmations in CR-02 archive [unverified]", "model:legal-counsel-review-sign-off-on-notific — Legal counsel review sign-off on notification triggers (annual) [unverified]" ] }, "lenses": { "engineering": "Build notification task automation as a webhook consumer of CR-04 incident severity events. Countdown timer must be visible to the regulatory liaison dashboard.", "evaluation": "No evaluation-specific obligations, but post-incident evaluation findings (CR-03, EV-03) may be required attachments to regulatory notifications.", "red_team": "No red-team-specific obligations.", "grc": "Regulatory notification matrix is a primary GRC governance artifact. Review quarterly. SR 26-2 must be mapped as normative_force: guidance, not binding-law (FWMAP-007).", "mlops": "No MLOps-specific implementation. MLOps team is responsible for providing incident timeline data to the regulatory liaison within 2 hours of P1 declaration." }, "maturity": { "current": "none", "target": "developing" }, "coverage_note": "Triggered by CR-04. Notification submissions archived in CR-02. For EU high-risk systems, links to LI-04 model card and EV-03 dangerous capability registry as potential attachments. Cross-references OA-05 (human oversight escalation) for incident narrative.", "obligations": [ { "id": "OB-CR-05-EU", "framework": "eu_ai_act", "article": "Art-73", "requirement_summary": "Providers of high-risk AI systems shall report any serious incident to the market surveillance authorities of the Member States where that incident occurred without undue delay and, in any event, immediately after the provider has established a causal link.", "legal_status": "enacted", "applicability_conditions": [ { "field": "jurisdiction", "op": "eq", "value": "EU" } ], "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "jurisdiction": [ "eu" ], "provision": "Art-73", "effective_from": "2026-08-02" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-72", "mapping_fit": "partial", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "canonical_id": "apeiris://model/controls/CR-05", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "monitoring_schema": { "metrics": [ { "metric_id": "cr-05-pass-rate", "metric_type": "performance", "measure": "control-verification-pass-rate", "population": "all-assessed-deployments", "comparison": { "operator": "lt", "value": 1, "window": "30d", "evaluation_mode": "batch" }, "severity": "critical" } ], "sampling_rate": "100%", "window_context": "rolling-30d" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-4.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-4.3 (GOVERN function) provides that organizational practices enable AI testing, identification of incidents, and information sharing. CR-05’s notification matrix and countdown tracking give incident identification and external information sharing a tested operational pathway.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.8.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.8.4 (Communication of incidents) requires determining and documenting how incidents are communicated to interested parties. CR-05’s notification matrix and countdown tracking operationalize incident communication to regulators.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "SEF-07", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CSA AICM SEF-07 (Security Breach Notification) requires defined processes for notifying regulators and affected parties of qualifying incidents. CR-05’s notification matrix, countdown timers, and liaison assignments implement that notification discipline for AI incidents.", "source_locator": { "control_id": "SEF-07" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-72", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 72 requires post-market monitoring to cover systematic collection and analysis of user feedback and actual model performance outcomes; CR-05's outcomes and disparate impact analysis — comparing actual decisions against predicted outcomes and testing for differential impact across demographic cohorts — directly implements the outcome analysis component of post-market monitoring.", "uncovered_portion": "Art. 72 addresses the full post-market monitoring plan; CR-05 covers outcomes and disparate impact analysis only and does not address the documentation of monitoring results in technical documentation or their submission to conformity assessment bodies.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. VI", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. VI (Governance and Controls) describes reporting on model risk to senior management and the board. CR-05 addresses statutory and regulatory notification, which SR 26-2 — non-enforceable supervisory guidance — does not itself require; the alignment is limited to the internal-reporting pathway. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 applies to supervised banking organizations with $30B+ in assets. SR 26-2 §III.C outcomes analysis is focused on model accuracy rather than demographic disparate impact, which is addressed by CR-05 as a supplementary dimension.", "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "checkcompliance", "fit": "partial", "rationale": "Executing statutory incident notifications within regulator-mandated deadlines is a compliance-with-laws-and-regulations obligation.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "validation_objective": "The organization must maintain a current, legal-counsel-reviewed regulatory notification matrix mapping P1 severity incident events to all applicable jurisdictions, notification timelines (EU Art. 73: ≤15 calendar days for serious incidents; SR 26-2: immediate for material events), designated liaison and backup contacts, and pre-approved notification templates — with an automated countdown timer creation integrated into the CR-04 P1 escalation workflow and a complete archive of all notification submissions and delivery confirmations in CR-02.", "evidence_required": [ "Regulatory notification matrix document (version-controlled, legal-counsel reviewed within 12 months) listing jurisdiction, authority, trigger_event, timeline_days, liaison_contact, backup_contact, and template_ref for each row", "Pre-approved notification templates for each regulatory authority and jurisdiction, with legal counsel review date and version on record", "Notification task creation records showing automated countdown timers initiated for each P1 incident meeting notification criteria, with regulatory liaison page confirmation and timer expiry date", "All notification submissions and delivery confirmations archived in CR-02 with artifact_hash for the trailing 36 months", "Legal counsel sign-off record confirming annual review of all notification triggers and timelines, dated within 12 months" ], "machine_tests": [ "Simulate a P1 incident event in the EU jurisdiction in the test environment → assert a notification task is created within 5 minutes with jurisdiction=EU, authority=national-market-surveillance, and deadline=created_at+15days", "Query notification_matrix for rows where jurisdiction=EU → assert at least one row with trigger_type=serious_incident and timeline_days<=15 and template_ref is non-null", "Query CR-02 for notification_submission artifacts in the trailing 36 months → for each assert delivery_confirmation_id is present and archived_at is within 24h of submitted_at", "Query legal_review_records for the notification_matrix artifact → assert most_recent_review_date > (today minus 366 days)" ], "human_review": [ "Assess the notification matrix for jurisdiction completeness: verify every jurisdiction where the AI system is deployed or where affected users reside has a corresponding matrix row, and no jurisdiction-authority pairing is missing or stale", "Review EU Art. 73 notification templates for prescribed content completeness: confirm templates include causal link, affected parties, corrective measures, and follow-up timeline fields as required by Art. 73(4)", "Verify backup regulatory liaison contacts are current and that the notification countdown workflow can be triggered and completed if the primary liaison is unavailable" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Relying on ad hoc legal escalation when a P1 incident occurs rather than a pre-built notification matrix — regulatory notification timelines begin running at incident detection, not when legal analysis is complete", "Single regulatory liaison with no designated backup contact or documented unavailability escalation path, creating a single point of failure in a time-critical workflow", "Notification matrix covering only EU AI Act without rows for SR 26-2 board reporting or other applicable jurisdiction requirements, creating compliance gaps for multi-region or US-banking deployments", "Notification templates that have not been reviewed by legal counsel since the EU AI Act August 2026 effective date, potentially omitting Art. 73(4) detailed reporting content requirements introduced under the regulation", "Treating SR 26-2 supervisory guidance as equivalent in normative_force to EU AI Act binding law in the notification matrix, causing incorrect prioritization of notification obligations under resource constraints" ], "update_status": "current", "layer_code": "CR" }, { "id": "CR-06", "layer": "CR", "plane": "lifecycle", "name": "Post-Market Surveillance", "plain": "Implement a structured post-market surveillance program that actively seeks user harm reports, adverse outcome data, and external security disclosures beyond the passive monitoring covered by CR-01 — using feedback channels, vulnerability disclosure programs, and literature monitoring.", "thesis_type": "detective", "readiness": "approved", "threat": { "tags": [ "unknown-harm-accumulation", "vulnerability-disclosure-gap", "user-harm-under-reporting", "third-party-research-blind-spot" ], "desc": "Passive runtime monitoring (CR-01) detects harms visible in system metrics but misses harms that users experience and do not report to the provider, harms discovered by third-party researchers, and harms that emerge from the intersection of the model with external systems. EU AI Act Art. 72 explicitly requires a proactive post-market surveillance plan. The absence of a feedback channel means harm data accumulates in user populations while the provider has no visibility." }, "standard": [ { "id": "eu_ai_act", "section": "Art-72", "title": "Post-market monitoring by providers of high-risk AI systems" }, { "id": "iso_42001", "section": "A.6.2.6", "title": "AI system operation and monitoring" }, { "id": "nist_rmf", "section": "MEASURE-2.4", "title": "Production monitoring of AI system functionality and behavior" } ], "sources": [ { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-26", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "eur-lex-open-access", "status": "current", "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/CR-06 Post-Market Surveillance control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/CR-06 Post-Market Surveillance control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Establish three surveillance channels: (1) in-product user feedback mechanism for harm/error reporting; (2) coordinated vulnerability disclosure (CVD) program with security.txt and a responsible disclosure policy; (3) quarterly literature and media monitoring for third-party findings on your model or similar systems. Aggregate all signals into a monthly surveillance report reviewed by the AI risk function.", "steps": [ "Deploy user-facing harm reporting mechanism: in-app feedback form with structured fields (harm_type, severity_self_assessed, description); store in CR-02 archive [ref:eu_ai_act_2024]", "Publish coordinated vulnerability disclosure policy at /security.txt and a dedicated CVD page; designate a security email alias with monitored inbox [ref:nist_ai_rmf_1_0]", "Establish quarterly AI research literature monitoring process: assign analyst to review arXiv, CVE, AI safety publications for findings relevant to deployed models", "Aggregate user reports, CVD submissions, and literature findings into a monthly post-market surveillance report", "Monthly report reviewed by AI risk function; any item meeting P1/P2 severity criteria triggers CR-04 incident response", "Annual summary of surveillance findings included in EU high-risk AI technical documentation (LI-04) [ref:eu_ai_act_2024]" ], "anti_patterns": [ "Treating CR-01 runtime monitoring as sufficient for post-market surveillance — passive metrics miss user-reported harms", "CVD program that routes to a generic security inbox with no AI-specific triage criteria", "Literature monitoring done ad hoc by individual engineers without systematic coverage or archival", "User harm reports siloed in customer support systems with no aggregation to the AI risk function" ] }, "validation": { "design_check": [ "Confirm user-facing harm reporting mechanism is deployed and accessible [ref:eu_ai_act_2024]", "Verify CVD policy is published and security email is monitored [ref:nist_ai_rmf_1_0]", "Confirm monthly surveillance report process is documented with designated owner [ref:nist_ai_rmf_1_0]" ], "runtime_test": [ "Submit a test harm report via the user feedback mechanism; verify it is archived in CR-02 within 24h [ref:eu_ai_act_2024]", "Submit a test CVD disclosure via the security email; verify acknowledgement is received within 5 business days [ref:nist_ai_rmf_1_0]", "Review last 12 monthly surveillance reports; confirm consistent production and review sign-off [unverified]" ], "evidence": [ "model:user-feedback-mechanism-screenshot-and-a — User feedback mechanism screenshot and archive path [unverified]", "model:published-cvd-policy-url-and-last-review — Published CVD policy URL and last review date [unverified]", "model:last-12-monthly-post-market-surveillance — Last 12 monthly post-market surveillance reports (artifact_hash: sha256:TBD each) [unverified]" ] }, "lenses": { "engineering": "Build harm reporting endpoint that writes structured records directly to CR-02 archive. CVD submission should also go directly to archive with automatic acknowledgement email.", "evaluation": "Literature monitoring findings should be assessed by the evaluation team for benchmark relevance — third-party findings often reveal evaluation gaps.", "red_team": "CVD submissions from external researchers are a primary red-team intelligence source. Route to red-team function for reproduction attempts before archiving findings.", "grc": "Post-market surveillance program is required by EU AI Act Art. 72 for high-risk systems. Annual surveillance summary must be included in technical documentation. GRC owns the monthly report review.", "mlops": "No MLOps-specific implementation beyond ensuring the harm reporting API endpoint is maintained in production and not deprecated without replacement." }, "monitoring_schema": { "metrics": [ { "name": "unreviewed_harm_reports_count", "type": "safety", "threshold": { "op": "gt", "value": 5 }, "alert_level": "P2", "metric_id": "unreviewed_harm_reports_count", "metric_type": "safety", "measure": "event-count", "population": "all-production-models", "comparison": { "operator": "greater-than", "value": 5, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "high" }, { "name": "cvd_unacknowledged_days", "type": "safety", "threshold": { "op": "gt", "value": 5 }, "alert_level": "P2", "metric_id": "cvd_unacknowledged_days", "metric_type": "safety", "measure": "days-elapsed", "population": "all-production-models", "comparison": { "operator": "greater-than", "value": 5, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "high" }, { "name": "surveillance_report_overdue_days", "type": "performance", "threshold": { "op": "gt", "value": 7 }, "alert_level": "P3", "metric_id": "surveillance_report_overdue_days", "metric_type": "performance", "measure": "days-elapsed", "population": "all-production-models", "comparison": { "operator": "greater-than", "value": 7, "window": "rolling-7d", "evaluation_mode": "batch" }, "severity": "medium" } ], "sampling_rate": "daily", "window_context": "30d rolling" }, "maturity": { "current": "none", "target": "developing" }, "coverage_note": "Complements CR-01 (runtime signals). Feeds CR-04 (incident response) and CR-05 (regulatory notifications). Annual surveillance summary feeds LI-04 (model card). Third-party research findings may trigger CR-03 (re-validation).", "obligations": [ { "id": "OB-CR-06-EU", "framework": "eu_ai_act", "article": "Art-72", "requirement_summary": "Providers of high-risk AI systems shall establish and document a post-market monitoring system that actively collects, documents, and analyses data on the performance of high-risk AI systems throughout their lifetime.", "legal_status": "enacted", "applicability_conditions": [ { "field": "jurisdiction", "op": "eq", "value": "EU" } ], "reviewed_on": "2026-06-26", "authority": "European Union", "instrument": "Regulation (EU) 2024/1689", "source_ref": "eu_ai_act", "normative_force": "binding-law", "jurisdiction": [ "eu" ], "provision": "Art-72", "effective_from": "2026-08-02" }, { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-73", "mapping_fit": "direct", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "canonical_id": "apeiris://model/controls/CR-06", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. CR-06 extends production monitoring beyond runtime metrics to externally reported harms via structured surveillance channels.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) requires monitoring in operation; CR-06 extends it to externally reported harms via structured post-market surveillance channels.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "TVM-08", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CR-06 establishes three structured post-market surveillance channels — in-product user harm reporting with structured fields, a coordinated vulnerability disclosure program with a monitored security alias, and quarterly AI research literature monitoring — aggregated into a monthly report reviewed by the AI risk function, directly implementing MON-07's post-deployment surveillance and external harm signal collection requirement. The annual surveillance summary included in EU high-risk AI technical documentation fulfills MON-07's expectation that surveillance findings are formally documented and incorporated into the model's assurance record.", "source_locator": { "section": "Monitoring and Alerting" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-73", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 73 requires providers of high-risk AI systems and GPAI models with systemic risk to notify national competent authorities of serious incidents without undue delay; CR-06 directly implements this obligation by defining the incident severity thresholds that trigger regulatory notification, the 72-hour notification SLA, and the structured notification content including affected parties, root cause, and corrective actions.", "uncovered_portion": "Art. 73 specifies detailed content requirements for the notification and follow-up reporting; CR-06 addresses the notification workflow but the specific Art. 73(4) detailed reporting content requirements depend on the incident type and may require supplementary documentation.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "source_locator": { "section": "Art. 73 — Reporting of serious incidents and malfunctioning" }, "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. V", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes ongoing monitoring of models in use; CR-06's post-market surveillance channels extend that monitoring to externally reported harms and findings, providing adjacent coverage. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 applies to supervised banking organizations with $30B+ in assets. SR 26-2 focuses on internal escalation and supervisory examination support, not formal regulatory notification; CR-06's primary driver is EU AI Act Art. 73 and Art. 55(c).", "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "monitoruse", "fit": "partial", "rationale": "Proactive harm reporting, vulnerability disclosure, and literature monitoring extend monitoring of model use to post-market abuse and failure signals.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0024", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"The organization must operate three distinct proactive surveillance channels — a…\" enacts ATLAS mitigation AML.M0024 AI Telemetry Logging; OpenCRE crosswalks this control’s OWASP AI Exchange concept (monitoruse) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "validation_objective": "The organization must operate three distinct proactive surveillance channels — a structured user-facing harm reporting mechanism, a coordinated vulnerability disclosure (CVD) program with a monitored security inbox, and a quarterly AI literature and media monitoring process — with outputs aggregated into a monthly post-market surveillance report reviewed and signed by the AI risk function, and an annual surveillance summary included in the model's EU high-risk AI technical documentation (LI-04).", "evidence_required": [ "User-facing harm reporting mechanism deployment record showing endpoint URL, structured input schema (harm_type, severity_self_assessed, description), and CR-02 archive path", "Published CVD policy document at a canonical URL with designated security email alias and monitored inbox confirmation, including acknowledgement SLA statement", "Last 12 monthly post-market surveillance reports with AI risk function reviewer name, sign-off signature, and review date on each report", "Annual surveillance summary document aggregating user reports, CVD submissions, and literature findings — present in the model's LI-04 technical documentation with review date", "CVD acknowledgement records showing each submission received an acknowledgement within 5 business days of receipt" ], "machine_tests": [ "Submit a synthetic harm report via the user feedback endpoint with harm_type=output_accuracy_failure → assert HTTP 200 response and assert record appears in CR-02 archive within 24h with harm_type and description fields populated", "Submit a test CVD disclosure to the security email alias → assert automated acknowledgement email is received within 5 business days (check inbox at T+6 business days, assert acknowledgement present)", "Query CR-02 for surveillance_report artifacts with type=monthly and created_at within trailing 13 months → assert count >= 12 and each record has reviewer_signature present", "Query unreviewed_harm_reports_count metric for the rolling 7-day window → assert value < 5 (alert threshold not breached)" ], "human_review": [ "Assess the most recent monthly surveillance report for channel completeness: confirm signals from all three channels (user harm reports, CVD submissions, literature monitoring) are represented, not just passive runtime alerts from CR-01", "Review CVD triage criteria for AI-specific coverage: verify that AI harm categories (model-caused harm, output accuracy failure, adversarial exploitation via AML.T0051 or similar) are included alongside traditional security vulnerability types", "Verify the annual surveillance summary is present in the LI-04 technical documentation and accurately reflects the aggregate volume and nature of harm signals received in the preceding 12 months, including any signals that triggered CR-04 escalation" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Treating CR-01 runtime metric monitoring as sufficient for EU AI Act Art. 72 post-market surveillance compliance — passive instrumentation cannot capture user-experienced harms that do not manifest as system-level metrics", "CVD program that routes AI harm disclosures to a generic IT security inbox without AI-specific triage criteria, resulting in model harm reports being triaged as low-severity software defects and never reaching the AI risk function", "Quarterly literature monitoring conducted informally by individual engineers with no defined scope, no coverage verification checklist, and no archival of findings in CR-02", "User harm reports captured in customer support ticketing systems with no integration path to the AI risk function, preventing harm signal aggregation in the monthly surveillance report", "Monthly surveillance report produced but not formally reviewed by the AI risk function before month-end, creating a governance gap where harm signals accumulate without risk function acknowledgement or escalation decision" ], "update_status": "current", "layer_code": "CR" }, { "id": "CR-07", "layer": "CR", "plane": "lifecycle", "name": "Model Retirement and Evidence Archival", "plain": "Execute a formal model retirement process that decommissions serving infrastructure, enforces data retention obligations, migrates assurance evidence to long-term archive, and produces a final retirement record — so that retired models leave no orphaned risk exposure.", "thesis_type": "corrective", "readiness": "approved", "threat": { "tags": [ "orphaned-model-exposure", "evidence-loss-at-retirement", "data-retention-violation", "ghost-endpoint-attack-surface" ], "desc": "Retired models that leave orphaned inference endpoints, stale credentials, or incomplete evidence handoff create persistent attack surface (AML.T0044 — Full AI Model Access via forgotten endpoints) and regulatory liability. EU AI Act record-keeping obligations and ISO/IEC 42001 life-cycle management (A.6.2.6) expect decommissioning to be handled and documented in a controlled manner." }, "standard": [ { "id": "iso_42001", "section": "A.6.2.6", "title": "AI system operation and monitoring" }, { "id": "eu_ai_act", "section": "Art-13", "title": "Transparency and provision of information to users" }, { "id": "nist_rmf", "section": "GOVERN-1.7", "title": "Decommissioning and phase-out of AI systems" } ], "sources": [ { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — Artificial Intelligence Act", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-26", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "eur-lex-open-access", "status": "current", "flagship": true, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — Artificial Intelligence Act requirements informing the apeiris://model/controls/CR-07 Model Retirement and Evidence Archival control.", "reviewed_on": "2026-07-01" }, { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "source_type": "voluntary-standard", "retrieved_on": "2026-06-26", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "status": "current", "authority": "NIST", "license": "public-domain", "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/CR-07 Model Retirement and Evidence Archival control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Retirement checklist driven by a signed retirement decision record. Steps: (1) announce retirement with notice period (≥30 days for external users); (2) drain traffic; (3) revoke all API credentials; (4) decommission serving infrastructure; (5) confirm evidence archive completeness; (6) move all CR-02 artifacts to long-term cold archive; (7) produce final retirement record. GDPR Art. 17 right-to-erasure compliance for any training data linked to the retired model must be evaluated at retirement.", "steps": [ "Designate model for retirement; obtain approval from model owner and AI risk function; produce signed retirement decision record [ref:nist_ai_rmf_1_0]", "Issue retirement notice to affected users/deployers with ≥30-day notice period and migration path documentation", "Execute traffic drain: route traffic to successor model or return 410 Gone; verify zero traffic on retired endpoint for 7 days before decommission", "Revoke all API keys, service accounts, and OAuth credentials associated with the retired model; audit IAM for orphaned permissions", "Decommission serving infrastructure: destroy VM/container images, delete endpoints, remove DNS records [ref:sr262_2026]", "Verify CR-02 evidence archive completeness: all evaluation manifests, monitoring snapshots, and incident records are archived", "Execute GDPR Art. 17 evaluation: identify any personal data in training set; verify right-to-erasure obligations are satisfied or document lawful retention basis [ref:eu_ai_act_2024]", "Produce final retirement record archived in CR-02 with artifact_hash; mark model as 'retired' in model registry (LI-01)" ], "anti_patterns": [ "Informal retirement — endpoint left running with no monitoring, traffic fades to zero, credentials remain active", "Evidence archive not audited at retirement — artifacts for the retired model may be missing from CR-02", "No notice period — users encounter unexpected 404/500 errors and lose access without migration path", "GDPR right-to-erasure not evaluated at retirement — unresolved erasure obligations become a post-retirement liability" ] }, "validation": { "design_check": [ "Confirm retirement checklist exists as a documented, version-controlled process [ref:nist_ai_rmf_1_0]", "Verify GDPR Art. 17 evaluation step is included in the retirement checklist [ref:eu_ai_act_2024]", "Confirm long-term archive tier is configured for retired model evidence (10-year retention for banking) [ref:sr262_2026]" ], "runtime_test": [ "Review last 3 model retirements; confirm each has a signed retirement decision record and final retirement record in CR-02 [ref:sr262_2026]", "Verify that a retired model's API credentials are not resolvable after retirement [ref:nist_ai_rmf_1_0]", "Confirm a retired model's CR-02 evidence is accessible 12 months after retirement [unverified]" ], "evidence": [ "model:signed-retirement-decision-records-for-a — Signed retirement decision records for all retired models [unverified]", "model:final-retirement-records-in-cr-02-with-a — Final retirement records in CR-02 with artifact_hash for each retired model [unverified]", "model:gdpr-art-17-evaluation-records-for-mode — GDPR Art. 17 evaluation records for models with personal data in training set [unverified]" ] }, "lenses": { "engineering": "Automate infrastructure decommissioning via IaC destroy scripts executed as a pipeline stage after traffic drain confirmation. Never manual deletion.", "evaluation": "At retirement, produce a final evaluation snapshot (re-run last benchmark suite) for the historical record. This provides a definitive final state for the retired model.", "red_team": "Attempt to reach retired model endpoints 30 days after decommission; verify all return 410 or connection refused. Check for orphaned credentials in secret management system.", "grc": "Retirement decision requires AI risk function sign-off. The final retirement record supports EU AI Act record-keeping obligations; SR 26-2 does not itself address post-retirement retention. GDPR Art. 17 evaluation must be conducted by legal/privacy function.", "mlops": "Retire models via pipeline, not manually. Evidence archive verification step must complete before infrastructure destroy scripts execute — order enforced by pipeline dependency." }, "maturity": { "current": "none", "target": "developing" }, "coverage_note": "Terminal lifecycle step; triggered after CR-04 and CR-06 closeout for the model. References LI-01 (model registry), LI-06 (version history), CR-02 (evidence archive). GDPR Art. 17 interaction links to TG-02 (data subject rights tracking).", "canonical_id": "apeiris://model/controls/CR-07", "capability_risk": { "capability_level": "frontier", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "monitoring_schema": { "metrics": [ { "metric_id": "cr-07-pass-rate", "metric_type": "performance", "measure": "control-verification-pass-rate", "population": "all-assessed-deployments", "comparison": { "operator": "lt", "value": 1, "window": "30d", "evaluation_mode": "batch" }, "severity": "critical" } ], "sampling_rate": "100%", "window_context": "rolling-30d" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.7", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-1.7 (GOVERN function) provides that processes are in place for decommissioning and phasing out AI systems safely. CR-07’s retirement checklist — signed decision record, traffic drain verification, credential revocation, and evidence archival — is the safe decommissioning process this subcategory requires.", "uncovered_portion": "GOVERN-1.7 covers organizational decommissioning processes for all AI systems; CR-07 provides the runtime execution and evidence-archival mechanics for models specifically.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) covers the operation stage through end-of-life. CR-07’s decommissioning checklist — traffic drain, credential revocation, evidence archival — closes that stage in a controlled, documented manner.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "DSP-02", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CSA AICM DSP-02 (Secure Disposal) requires secure, verifiable disposal of data and assets at end-of-life. CR-07’s decommissioning checklist — credential revocation, infrastructure teardown, and verified archive handoff — implements secure disposal for retired models.", "source_locator": { "control_id": "DSP-02" }, "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-16", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 16 specifies obligations of providers of high-risk AI systems throughout the system's lifecycle, including maintaining technical documentation and post-market monitoring; CR-07's structured decommissioning process — including traffic drain, data retention, dependency notification, and evidence archival — implements the lifecycle-end obligations implied by Art. 16's scope.", "uncovered_portion": "Art. 16 does not explicitly address decommissioning procedures; CR-07's coverage is an interpretive extension of the lifecycle scope to include end-of-life governance. Explicit decommissioning requirements may be imposed by sectoral law or by the deployer's own governance obligations.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" } ], "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-16", "mapping_fit": "adjacent", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "Every retired AI model must have a complete retirement record in the CR-02 evidence archive covering: a signed retirement decision record, user notification dispatched ≥30 days before decommission with a migration path, verified traffic drain to zero for 7 consecutive days, revocation of all associated API credentials and IAM permissions, complete infrastructure decommissioning with no orphaned endpoints or container images, a GDPR Art. 17 right-to-erasure evaluation, and the model marked as 'retired' in the LI-01 model registry with a final retirement record artifact_hash.", "evidence_required": [ "Signed retirement decision record with model_id, retirement_date, approving_model_owner, approving_ai_risk_function, and decision_rationale", "User retirement notification artifact showing dispatch_date >= 30 days before decommission_date, recipient list or audience scope, and migration_path_documentation link", "Traffic drain verification log showing zero-traffic state on the retired inference endpoint for 7 consecutive days prior to infrastructure decommission execution", "IAM credential revocation audit log listing all revoked API keys, service accounts, OAuth tokens, and service mesh credentials with revoked_at timestamps for the retired model", "Infrastructure decommission confirmation record (IaC destroy plan output or equivalent) documenting endpoint URLs, VM or container image IDs, and DNS records removed", "GDPR Art. 17 evaluation record documenting personal data assessment outcome for the training set and either erasure completion confirmation or documented lawful retention basis with legal sign-off", "Final retirement record in CR-02 with artifact_hash, model_id status=retired confirmed in LI-01, and archive tier set to long-term cold storage with retention_period documented" ], "machine_tests": [ "Query LI-01 model registry for model_id of each retired model → assert status=retired and retirement_record_uri is present and resolves to a valid artifact in CR-02", "Attempt HTTP GET on the retired model's inference endpoint 30 days post-decommission → assert response is 410 Gone or TCP connection refused (not 200, 404, or 500)", "Query IAM system for all service accounts and API keys associated with retired model_id → assert zero active credentials returned", "Query CR-02 for type=gdpr_art17_evaluation artifacts with model_id= → assert at least one record exists with evaluation_date present and legal_sign_off present" ], "human_review": [ "Review the GDPR Art. 17 evaluation record for completeness: confirm the personal data assessment was conducted by the privacy or legal function and that any outstanding erasure obligations have a documented resolution timeline with ownership assigned", "Assess the infrastructure decommission record for thoroughness: verify DNS entries, container registry images, API gateway route definitions, and internal service mesh service discovery entries were removed in addition to compute instances", "Verify the long-term evidence archive contains all evaluation manifests, monitoring snapshots, incident records, and post-incident reviews for the retired model, and that the archive retention period meets applicable requirements (10 years for banking under SR 26-2; 10 years for EU high-risk AI technical documentation)" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Informal retirement where traffic fades to zero on an idle endpoint with no formal process, leaving active credentials, orphaned DNS records, and stale container images that represent a persistent AML.T0044 attack surface", "Decommissioning serving infrastructure before verifying CR-02 evidence archive completeness for the retiring model, creating an irrecoverable evidence gap if missing artifacts are discovered post-decommission", "Conducting the GDPR Art. 17 right-to-erasure evaluation after infrastructure decommission, when the ability to identify and purge personal data from training artifacts has already been diminished", "Retirement notice that omits a migration path to a successor model, causing users to encounter unexpected 410 Gone errors without recourse", "IAM credential revocation limited to API keys only, leaving OAuth refresh tokens, service account IAM role bindings, and internal service mesh certificates active and unmonitored post-retirement" ], "update_status": "current", "layer_code": "CR" }, { "id": "CR-08", "layer": "CR", "plane": "lifecycle", "name": "Cross-Domain Assurance Coordination", "plain": "Resolve apeiris:// cross-domain evidence references at audit time, synchronize assurance state between modelverifier.ai and securitycontrols.ai (and future Apeiris domains), and ensure that no control gap in one domain creates an uncompensated blind spot across the assurance federation.", "thesis_type": "compensating", "readiness": "approved", "threat": { "tags": [ "cross-domain-assurance-gap", "unresolved-uri-reference", "siloed-compliance-view", "inter-domain-control-overlap" ], "desc": "Apeiris is a multi-domain assurance federation. Controls in modelverifier.ai (BH-04, BH-06) reference evidence artifacts in securitycontrols.ai via apeiris:// URIs. Without coordinated resolution, these references become dangling pointers — an auditor sees a cross-domain evidence claim that cannot be verified. The gap is systemic: as more Apeiris domains are added (privacy, compliance, finance), the number of cross-domain dependencies grows and the risk of uncoordinated gaps compounds. Gap 3 (cross-domain assurance federation) is explicitly unresolved at v1 and is compensated by this control." }, "standard": [ { "id": "nist_rmf", "section": "GOVERN-1.4", "title": "Transparent, documented risk management outcomes" }, { "id": "iso_42001", "section": "7.5", "title": "Documented information" } ], "sources": [ { "id": "apeiris_thesis", "title": "Apeiris Namespace Registry and Multi-Domain Architecture Thesis", "authority": "Apeiris", "source_type": "apeiris-thesis", "normative_force": "informative-reference", "version": "1.0", "published_on": "2026-06-26", "retrieved_on": "2026-06-26", "canonical_url": "apeiris://model/core/namespace-registry", "license": "proprietary", "status": "current" }, { "id": "nist_ai_rmf_1_0", "title": "NIST AI Risk Management Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_rmf", "relationship": "implementation_pattern", "rationale": "Establishes NIST AI Risk Management Framework 1.0 requirements informing the apeiris://model/controls/CR-08 Cross-Domain Assurance Coordination control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "At build time, the audit:cross-domain check (audit-mappings.mjs) resolves all apeiris:// URIs against the namespace-registry.json resolver_map. At audit time, cross-domain evidence references are resolved to their canonical HTTP URLs or flagged as unresolved. Maintain a cross-domain dependency map (model→security, model→privacy) updated when any control gains a cross-domain reference. Gap 3 is tracked as an open finding until a dedicated cross-domain federation protocol is implemented.", "steps": [ "Enumerate all cross_domain.references[] fields across all 54 controls; build a dependency map (source_control → target_domain → target_control) [ref:apeiris_thesis]", "For each apeiris:// URI, resolve against namespace-registry.json resolver_map; any URI with no resolver entry must be flagged as unresolved and documented as a gap finding [ref:nist_ai_rmf_1_0]", "Establish a quarterly cross-domain sync review: model-domain owners and security-domain owners review mutual evidence references for staleness", "For gap3 (cross-domain assurance federation): document compensating measures — all cross-domain references in BH-04 and BH-06 are additionally verified by the security-domain owner at each quarterly sync", "As new Apeiris domains are added, run namespace-registry.json update before adding cross_domain.references[] in controls", "Build audit:cross-domain check output into the release manifest so every release documents which cross-domain URIs were resolved vs. flagged" ], "anti_patterns": [ "Adding cross_domain.references[] without first verifying the target URI is registered in namespace-registry.json", "Cross-domain sync reviews conducted only at major releases — quarterly cadence required to catch drift", "Treating gap3 as permanently acceptable without a roadmap to full federation protocol implementation", "Siloing the cross-domain dependency map in one team's documentation — it must be a first-class artifact in the release manifest" ] }, "validation": { "design_check": [ "Confirm namespace-registry.json resolver_map has entries for all domains referenced in cross_domain.references[] fields [ref:apeiris_thesis]", "Verify audit:cross-domain check runs in CI and fails on unresolved URIs that are not documented as gap findings [ref:nist_ai_rmf_1_0]", "Confirm cross-domain dependency map is produced as a release manifest artifact [ref:nist_ai_rmf_1_0]" ], "runtime_test": [ "Add a deliberate unregistered apeiris:// URI to a test control; confirm audit:cross-domain check fails [ref:apeiris_thesis]", "Review last quarterly cross-domain sync record; confirm both model-domain and security-domain owners signed off [ref:nist_ai_rmf_1_0]", "Verify gap3 is documented as an open finding in the release manifest with compensating control reference (this control, CR-08) [unverified]" ], "evidence": [ "model:cross-domain-dependency-map-produced-by — Cross-domain dependency map (produced by audit:cross-domain, archived in CR-02) [unverified]", "model:last-4-quarterly-cross-domain-sync-revie — Last 4 quarterly cross-domain sync review records [unverified]", "model:gap3-open-finding-documentation-with-com — Gap3 open finding documentation with compensating control reference [unverified]" ] }, "lenses": { "engineering": "The audit:cross-domain check is the primary implementation artifact. Maintain namespace-registry.json as a first-class schema file in apeiris-control-core/. URI resolution is offline — no HTTP calls; resolver_map provides the canonical mapping.", "evaluation": "No evaluation-specific implementation. Cross-domain references to evaluation artifacts (e.g., securitycontrols.ai evidence for BH-06) must be included in the evidence package for any evaluation that cites them.", "red_team": "Test cross-domain URI resolution in an adversarial manner: can a false reference be added that passes the namespace check but resolves to an empty or incorrect artifact? Verify the audit check validates the artifact hash, not just the URI.", "grc": "Cross-domain assurance coordination is a governance obligation — no single domain's compliance picture is complete without resolving its dependencies. Gap3 must appear in the AI risk register as an open finding until federation protocol is implemented.", "mlops": "Namespace-registry.json must be pinned by commit hash in CI to prevent silent resolver_map changes from breaking URI resolution without a pipeline failure." }, "cross_domain": { "references": [ { "relationship": "composes-with", "uri": "apeiris://security/controls/RT-04", "name": "Detect anomalies and trigger pause, kill switch, or containment", "note": "CR-08 signals cross-domain evidence discrepancies; RT-04 owns the enforcement response (pause, kill switch, containment) on the security side." } ], "evidence_artifacts": [], "feeds": [ "apeiris://finance/controls/MR-02", "apeiris://resilience/controls/RE-05", "apeiris://compliance/controls/AU-08" ] }, "maturity": { "current": "none", "target": "initial" }, "coverage_note": "Compensates gap3 (cross-domain assurance federation). References BH-04, BH-06 (controls with cross-domain references). Reads namespace-registry.json. Output consumed by sign-release-manifest.mjs. Is itself a continuous-assurance control — it is always in scope regardless of profile.", "canonical_id": "apeiris://model/controls/CR-08", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "monitoring_schema": { "metrics": [ { "metric_id": "cr-08-pass-rate", "metric_type": "performance", "measure": "control-verification-pass-rate", "population": "all-assessed-deployments", "comparison": { "operator": "lt", "value": 1, "window": "30d", "evaluation_mode": "batch" }, "severity": "critical" } ], "sampling_rate": "100%", "window_context": "rolling-30d" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-1.4 (GOVERN function) provides that the risk management process and its outcomes are established through transparent policies, procedures, and controls. CR-08’s cross-domain evidence assembly makes the risk management process and its outcomes transparent and reviewable across domain boundaries.", "source_version": "1.0", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "7.5", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001 Clause 7.5 (Documented information) requires documented information to be controlled and available where needed. CR-08’s cross-domain evidence resolution and dependency map keep multi-domain compliance documentation coherent and retrievable.", "source_version": "2023", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aicm", "requirement_id": "A&A-04", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "CSA AICM A&A-04 (Requirements Compliance) expects compliance evidence to be assembled and auditable across the control set. CR-08’s cross-domain evidence resolution and dependency map support that assembly across Apeiris domains.", "uncovered_portion": "GOV-09 covers the full organizational AI governance coordination framework including policy alignment, reporting lines, and cross-functional accountability structures; CR-08 addresses only the technical evidence synchronization and reference resolution mechanism between Apeiris verifier domains — organizational governance coordination is addressed by OA-03 (governance committee) and OA-07 (escalation authority chain).", "source_version": "1.1", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "provisional": true, "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art-11", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "EU AI Act Art. 11 requires technical documentation that references all applicable regulatory obligations and the evidence that supports compliance; CR-08's cross-domain evidence collection and correlation provides adjacent coverage of the multi-obligation evidence assembly requirement in Art. 11.", "uncovered_portion": "Art. 11 requires a specific structured technical documentation package; CR-08 is an evidence coordination mechanism and does not produce the formal technical documentation or register it with conformity assessment bodies.", "source_version": "2024/1689", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "sr262", "requirement_id": "Sec. VI", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "SR 26-2 Sec. VI (Governance and Controls) describes documentation that supports supervisory examination; CR-08's cross-domain evidence assembly provides adjacent coverage by collecting compliance evidence that examiners may draw on. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope.", "uncovered_portion": "SR 26-2 applies to supervised banking organizations with $30B+ in assets. SR 26-2's records requirement is focused on model-specific documentation rather than cross-domain compliance evidence aggregation.", "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "equivalent_to" } ], "obligations": [ { "authority": "European Union — European Parliament and Council", "instrument": "Regulation (EU) 2024/1689", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "actor_roles": [ "provider" ], "subject_types": [ "high-risk-ai-system" ], "classification": [ "high-risk-annex-iii", "high-risk-product-embedded" ], "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "applicability": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" }, { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ] }, "source_ref": "eu_ai_act", "reviewed_on": "2026-06-26", "provision": "Art-11", "mapping_fit": "adjacent", "enforcement_gating": { "date_basis": "EU AI Act 2024/1689 as amended by proposed Digital Omnibus (provisional agreement May 2026, Council adoption pending)", "legal_status": "enacted-with-pending-amendments", "last_verified_on": "2026-06-26" } } ], "validation_objective": "All apeiris:// cross-domain evidence URIs referenced across this domain's 54 controls must resolve against the namespace-registry.json resolver_map at build time with zero unresolved URIs (or each unresolved URI documented as a named gap finding with a compensating control reference), a cross-domain dependency map must be produced as a signed release manifest artifact on each build, and a quarterly cross-domain sync review record must exist with sign-off from both model-domain and security-domain owners for the trailing 12 months.", "evidence_required": [ "audit:cross-domain check output from the most recent build listing each resolved URI, any unresolved URIs, and the named gap finding reference for each unresolved entry", "Cross-domain dependency map artifact (source_control → target_domain → target_control) produced by the build system and archived in CR-02 with artifact_hash matching the release commit", "Last 4 quarterly cross-domain sync review records with model-domain owner and security-domain owner sign-off, date, and scope of evidence references reviewed in each session", "Gap3 open finding documentation entry in the AI risk register naming CR-08 as the compensating control and including a roadmap milestone for federation protocol implementation", "Namespace-registry.json version pin record in CI configuration showing the file is referenced by commit hash, not branch name" ], "machine_tests": [ "Inject a deliberate unregistered apeiris:// URI (e.g., apeiris://nonexistent-domain/controls/XX-99) into a test control fixture and run audit:cross-domain check → assert the check exits non-zero and outputs an unresolved_uri_report containing the injected reference", "Run audit:cross-domain check against the full 54-control matrix on the current release commit → assert zero URIs with status=unresolved that are not present in the named gap findings list in the release manifest", "Query the release manifest for cross_domain_dependency_map artifact → assert it is present, artifact_hash is non-null, and generated_at timestamp matches the release commit timestamp", "Query CR-02 for quarterly_sync_review records with type=cross_domain and created_at within trailing 13 months → assert count >= 4 and each record has both model_domain_owner_signature and security_domain_owner_signature present" ], "human_review": [ "Review the cross-domain dependency map for completeness: confirm it enumerates all controls that reference apeiris:// URIs and that no cross-domain reference was added outside the audit:cross-domain build check workflow", "Assess the gap3 open finding documentation: confirm the compensating measure description (CR-08 quarterly sync reviews) accurately reflects current practice and includes a concrete roadmap target date for cross-domain federation protocol implementation", "Verify that the security-domain owner signatures on the quarterly sync reviews are from the authorized security domain owner — not a proxy — and that each sync examined mutual evidence references for staleness in both directions (model→security and security→model)" ], "blocking_effect": "advisory", "normative_status": "voluntary-standard", "anti_patterns": [ "Adding cross_domain.references[] entries to controls without first verifying the target URI is registered in namespace-registry.json resolver_map, creating dangling apeiris:// references that only surface at audit time", "Running the audit:cross-domain check only at major version releases rather than on every build commit, allowing cross-domain reference drift to accumulate silently between releases", "Pinning namespace-registry.json by branch name rather than commit hash in CI, allowing silent resolver_map changes to alter URI resolution results without triggering a pipeline failure", "Conducting cross-domain sync reviews with only model-domain team members present and treating the session as complete without security-domain owner verification of mutual evidence references", "Categorizing gap3 as a permanently acceptable open finding without a concrete roadmap milestone date for federation protocol implementation, normalizing an unresolved assurance gap" ], "update_status": "current", "layer_code": "CR" }, { "id": "EV-11", "layer": "EV", "layer_code": "EV", "plane": "both", "canonical_id": "apeiris://model/controls/EV-11", "name": "Backdoor and Trojan Detection Scanning", "plain": "Every third-party, pre-trained, or fine-tuned model is scanned for embedded backdoors and trigger patterns before it is registered or deployed. A valid signature proves the artifact is unaltered — not that it is free of a hidden trigger.", "threat": { "tags": [ "model-backdoor", "trojan-model", "supply-chain-integrity", "MR-INT" ], "desc": "A legitimately signed base or third-party model can carry an embedded backdoor or trojan trigger that provenance and signature checks cannot detect (NIST AI 100-2 NISTAML.021 Clean-label Backdoor / NISTAML.023 Backdoor Poisoning; ETSI GR SAI 005 §5.3). Signing proves integrity, not cleanliness." }, "standard": [ "NIST AI 100-2e2025 — Backdoor Poisoning (NISTAML.021/.023)", "ETSI GR SAI 005 §5.3 — Mitigating backdoor attacks", "OWASP ML Security Top 10 — ML10:2023 Model Poisoning" ], "sources": [ { "id": "nist_ai_100_2", "title": "NIST AI 100-2e2025 — Adversarial ML Taxonomy", "authority": "National Institute of Standards and Technology", "source_type": "industry-framework", "normative_force": "informative-reference", "version": "100-2e2025", "published_on": "2025-01-01", "retrieved_on": "2026-07-08", "canonical_url": "https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf", "relationship": "supporting_guidance", "note": "Backdoor poisoning taxonomy (NISTAML.021/.023) grounds the threat this control detects." }, { "id": "etsi_gr_sai_005", "title": "ETSI GR SAI 005 — Mitigation Strategy Report", "authority": "ETSI", "source_type": "industry-framework", "normative_force": "voluntary-standard", "version": "V1.1.1", "published_on": "2025-01-01", "retrieved_on": "2026-07-08", "canonical_url": "https://www.etsi.org/deliver/etsi_gr/SAI/001_099/005/01.01.01_60/gr_SAI005v010101p.pdf", "relationship": "supporting_guidance", "note": "§5.3 backdoor-detection mitigations (trigger detection, model restoration) inform the scan methods." } ], "implementation": { "pattern": "Automated backdoor/trojan scanning of every incoming model artifact (base, third-party, fine-tune) at registration, using trigger-reconstruction and neuron-activation analysis, with a flagged verdict blocking promotion pending security review.", "steps": [ "Integrate a backdoor scanner (trigger reconstruction, activation clustering, spectral-signature analysis) into the model-registration pipeline.", "Scan every third-party and fine-tuned model before it is added to the registry; record scanner name/version, method, and clean/flagged verdict.", "Block registration/deployment of any unscanned model and any flagged model that has not been remediated and re-scanned.", "Route flagged detections to a security reviewer for adjudication before any override." ] }, "validation": { "design_check": [ "Model-registration pipeline invokes a backdoor/trojan scanner on every third-party and fine-tuned artifact before registry entry. [ref:nist_ai_100_2]", "Scan report schema captures scanner name/version, method, and clean/flagged verdict, signed and linked to the model content hash. [ref:etsi_gr_sai_005]" ], "runtime_check": [ "Deployment gate rejects any model without a linked clean backdoor_scan_report." ] }, "lenses": { "engineering": "Wire a backdoor/trojan scanner into the model-registration CI; fail registration on missing or flagged scans.", "evaluation": "Own the scan methodology and thresholds; validate scanner efficacy against known-trojan test models.", "grc": "Evidence that every registered model carries a signed clean-scan report; report flagged-model overrides.", "mlops": "Gate the registry and deployment pipeline on scan status; keep scan reports in the evidence store.", "red_team": "Attempt to introduce a triggered model that passes signature checks and confirm the scanner catches it." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Extends LI-03 (third-party model signature/provenance verification) — signing proves the artifact is unaltered; this proves it is clean.", "frameworks": [ { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.021", "fit": "direct", "rationale": "NIST AI 100-2 Clean-label Backdoor is the threat this control detects.", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against" }, { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.023", "fit": "direct", "rationale": "NIST AI 100-2 Backdoor Poisoning is the threat this control detects.", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against" }, { "framework": "etsi_gr_sai_005", "requirement_id": "5.3", "fit": "supporting", "rationale": "ETSI SAI 005 §5.3 backdoor-detection mitigations inform the scan methods.", "normative_force": "voluntary-standard", "source_version": "V1.1.1", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ml_top10", "requirement_id": "ML10:2023", "fit": "partial", "rationale": "OWASP ML10 Model Poisoning overlaps embedded-trigger model compromise.", "normative_force": "industry-framework", "source_version": "2023", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against" }, { "framework": "owasp_ai_exchange", "requirement_id": "poisonrobustmodel", "fit": "supporting", "rationale": "Scanning third-party and fine-tuned models for embedded backdoors and triggers before deployment defends against the supply-chain model-poisoning the poison-robust control targets.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "capability_risk": { "capability_level": "elevated", "access_mode": "internal", "autonomy": "none", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "medium" }, "validation_objective": "Prove that every third-party, pre-trained, or fine-tuned model is scanned for embedded backdoors and trigger patterns (trigger reconstruction / neuron-activation analysis) before registration or deployment, and that a flagged detection blocks promotion pending security review.", "evidence_required": [ "signed backdoor_scan_report per model artifact: scanner name/version, method (trigger-reconstruction / activation-clustering / spectral-signature), model content hash, and clean/flagged verdict", "model_registry entry linking each registered model to its scan report and blocking any unscanned artifact" ], "machine_tests": [ "Check the model registry for any registered or deployed model lacking a linked backdoor_scan_report -> assert registration is blocked.", "Check scan verdict; if flagged and not remediated+re-scanned -> assert the deployment pipeline blocks promotion." ], "human_review": [ "Review flagged-model triage decisions to confirm a security reviewer adjudicated each detection before any override or acceptance." ], "blocking_effect": "blocks-deployment", "normative_status": "best-practice", "anti_patterns": [ "Treating a valid signature or provenance attestation as evidence the model is backdoor-free — signing proves integrity, not cleanliness.", "Scanning only in-house fine-tunes while trusting the base model unscanned." ], "update_status": "current" }, { "id": "EV-12", "layer": "EV", "layer_code": "EV", "plane": "both", "canonical_id": "apeiris://model/controls/EV-12", "name": "Model Inversion and Reconstruction Resistance", "plain": "The model is tested for its resistance to inversion and reconstruction attacks — attempts to recover training records or sensitive attributes by querying the model — and a mitigation is applied when leakage exceeds the accepted threshold.", "threat": { "tags": [ "model-inversion", "training-data-reconstruction", "privacy-leakage", "MR-PRIV" ], "desc": "An attacker with query access can reconstruct sensitive training records or infer attributes from a trained model (NIST AI 100-2 NISTAML.032 Reconstruction; OWASP ML03 Model Inversion; ETSI GR SAI 005 §6.4). Membership inference is addressed in Privacy DP-06; reconstruction/inversion of records is distinct and otherwise unaddressed." }, "standard": [ "NIST AI 100-2e2025 — Reconstruction (NISTAML.032)", "OWASP ML Security Top 10 — ML03:2023 Model Inversion Attack", "ETSI GR SAI 005 §6.4 — Mitigating data extraction" ], "sources": [ { "id": "nist_ai_100_2", "title": "NIST AI 100-2e2025 — Adversarial ML Taxonomy", "authority": "National Institute of Standards and Technology", "source_type": "industry-framework", "normative_force": "informative-reference", "version": "100-2e2025", "published_on": "2025-01-01", "retrieved_on": "2026-07-08", "canonical_url": "https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf", "relationship": "supporting_guidance", "note": "Reconstruction (NISTAML.032) grounds the attack this control resists." }, { "id": "etsi_gr_sai_005", "title": "ETSI GR SAI 005 — Mitigation Strategy Report", "authority": "ETSI", "source_type": "industry-framework", "normative_force": "voluntary-standard", "version": "V1.1.1", "published_on": "2025-01-01", "retrieved_on": "2026-07-08", "canonical_url": "https://www.etsi.org/deliver/etsi_gr/SAI/001_099/005/01.01.01_60/gr_SAI005v010101p.pdf", "relationship": "supporting_guidance", "note": "§6.4 data-extraction mitigations (embed data privacy, DP-SGD, output obfuscation) inform the mitigation." } ], "implementation": { "pattern": "Privacy-attack red-teaming (inversion/reconstruction) against the model before deployment, with a leakage threshold and a differential-privacy or output-perturbation mitigation applied when exceeded.", "steps": [ "Run inversion/reconstruction attack simulations against the model using representative query access.", "Measure reconstruction success against a documented leakage threshold.", "Apply a mitigation (DP training / output perturbation / confidence obfuscation) when the threshold is exceeded and re-test.", "Record the test, threshold, and mitigation in the model evidence archive; coordinate with Privacy DP-06 (membership inference)." ] }, "validation": { "design_check": [ "A documented inversion/reconstruction test methodology and leakage threshold exist and are applied before deployment. [ref:nist_ai_100_2]", "When the threshold is exceeded, a DP or output-perturbation mitigation is applied and the model re-tested. [ref:etsi_gr_sai_005]" ], "runtime_check": [ "Deployment gate requires a passed (or mitigated) inversion/reconstruction test result." ] }, "lenses": { "engineering": "Build the inversion/reconstruction test harness and integrate the pass/mitigate gate into deployment.", "evaluation": "Own the attack methodology, leakage threshold, and mitigation-efficacy re-test.", "grc": "Evidence that privacy-attack resistance was tested and mitigated; coordinate with Privacy DP-06.", "mlops": "Gate deployment on the test result; archive results and mitigation config.", "red_team": "Mount inversion/reconstruction attacks and attempt to recover training records above threshold." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Completes the model privacy-attack set: membership inference + differential privacy live in Privacy DP-06; this adds inversion/reconstruction resistance.", "frameworks": [ { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.032", "fit": "direct", "rationale": "NIST AI 100-2 Reconstruction is the attack this control resists.", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against" }, { "framework": "owasp_ml_top10", "requirement_id": "ML03:2023", "fit": "direct", "rationale": "OWASP ML03 Model Inversion Attack is the named threat.", "normative_force": "industry-framework", "source_version": "2023", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against" }, { "framework": "etsi_gr_sai_005", "requirement_id": "6.4", "fit": "supporting", "rationale": "ETSI SAI 005 §6.4 data-extraction mitigations inform the mitigation.", "normative_force": "voluntary-standard", "source_version": "V1.1.1", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_aisvs", "requirement_id": "C11.2.5", "fit": "adjacent", "rationale": "AISVS C11.2.5 membership-inference attack simulation (accuracy ~ random).", "normative_force": "industry-framework", "source_version": "1.0", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to", "correction": "ap07-fit-audit 2026-07-08 (direct->adjacent)" }, { "framework": "owasp_ai_exchange", "requirement_id": "modelobfuscation", "fit": "supporting", "rationale": "Testing and mitigating inversion/reconstruction leakage directly serves the model-obfuscation control, which AI Exchange scopes to hindering inversion.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "obfuscatetrainingdata", "fit": "supporting", "rationale": "Applying differential privacy or output perturbation to prevent recovery of training records is the privacy-protecting obfuscate-training-data control.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "capability_risk": { "capability_level": "elevated", "access_mode": "internal", "autonomy": "none", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "medium" }, "validation_objective": "Prove that the model is tested for inversion/reconstruction attack resistance against a documented leakage threshold before deployment, and that a differential-privacy or output-perturbation mitigation is applied and re-tested when the threshold is exceeded.", "evidence_required": [ "signed inversion_reconstruction_test_report with methodology, query budget, leakage metric vs threshold, and pass/mitigated verdict", "mitigation configuration record (DP parameters / output-perturbation settings) when a mitigation was applied, with the re-test result" ], "machine_tests": [ "Check the deployment manifest for a model lacking an inversion/reconstruction test result -> assert the deployment gate holds the model for privacy/security review before promotion.", "If the leakage metric exceeds the threshold and no mitigation+re-test is recorded -> assert the gate routes the model to review rather than auto-promoting." ], "human_review": [ "Review the leakage threshold and mitigation-acceptance decision to confirm a privacy/security reviewer signed off on any residual risk." ], "blocking_effect": "requires-review", "normative_status": "best-practice", "anti_patterns": [ "Assuming a signed, well-governed model cannot leak training records — a fully compliant model still leaks under query without a resistance test.", "Treating membership-inference coverage (DP-06) as covering reconstruction/inversion — they are distinct attack classes." ], "update_status": "current" }, { "id": "EV-13", "layer": "EV", "layer_code": "EV", "plane": "both", "canonical_id": "apeiris://model/controls/EV-13", "name": "Training-Data Memorization and Regurgitation Testing", "plain": "The model is tested for verbatim memorization and regurgitation of sensitive training data — and output filtering or mitigation is applied when the model reproduces memorized records above the accepted threshold.", "threat": { "tags": [ "training-data-memorization", "regurgitation", "data-extraction", "MR-PRIV" ], "desc": "Large models memorize and can regurgitate sensitive training records under crafted prompts (NIST AI 100-2 NISTAML.037 Training Data Attacks / NISTAML.038 Data Extraction). Signing and evaluation for accuracy do not test for memorization leakage." }, "standard": [ "NIST AI 100-2e2025 — Training Data Attacks / Data Extraction (NISTAML.037/.038)" ], "sources": [ { "id": "nist_ai_100_2", "title": "NIST AI 100-2e2025 — Adversarial ML Taxonomy", "authority": "National Institute of Standards and Technology", "source_type": "industry-framework", "normative_force": "informative-reference", "version": "100-2e2025", "published_on": "2025-01-01", "retrieved_on": "2026-07-08", "canonical_url": "https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf", "relationship": "supporting_guidance", "note": "Training-data extraction/memorization (NISTAML.037/.038) grounds this test." } ], "implementation": { "pattern": "Memorization/regurgitation red-teaming before deployment with a leakage threshold and output-filtering or DP mitigation when exceeded.", "steps": [ "Run extraction prompts (training-data probes, canary strings) against the model.", "Measure verbatim regurgitation against a documented leakage threshold.", "Apply output filtering / DP mitigation when the threshold is exceeded and re-test.", "Archive the test and mitigation in the model evidence store." ] }, "validation": { "design_check": [ "A memorization/regurgitation test methodology and leakage threshold exist and are applied before deployment. [ref:nist_ai_100_2]", "When exceeded, an output-filter or DP mitigation is applied and re-tested." ], "runtime_check": [ "The deployment gate requires a passed (or mitigated) memorization test result." ] }, "lenses": { "engineering": "Build the extraction/canary test harness and integrate the pass/mitigate gate.", "evaluation": "Own the memorization methodology, canaries, and leakage threshold.", "grc": "Evidence that memorization was tested and mitigated; coordinate with Privacy DP-06.", "mlops": "Gate deployment on the result; archive config.", "red_team": "Craft extraction prompts to recover memorized training records above threshold." }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Extends EV-12 (inversion/reconstruction) to verbatim memorization/regurgitation of training records.", "frameworks": [ { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.037", "fit": "direct", "rationale": "NIST AI 100-2 Training Data Attacks — the memorization-leakage class this control tests.", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against" }, { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.038", "fit": "direct", "rationale": "NIST AI 100-2 Data Extraction — verbatim regurgitation of memorized data.", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against" }, { "framework": "owasp_ai_exchange", "requirement_id": "obfuscatetrainingdata", "fit": "supporting", "rationale": "Applying DP mitigation when the model regurgitates memorized training records implements obfuscate-training-data to protect training-data privacy.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "sensitiveoutputhandling", "fit": "supporting", "rationale": "Output filtering triggered when the model reproduces sensitive training data is the handle-sensitive-output-to-prevent-leakage control.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0020", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Prove that the model is tested for verbatim memorization and regurgitation of sensitive…\" enacts ATLAS mitigation AML.M0020 Generative AI Guardrails; OpenCRE crosswalks this control’s OWASP AI Exchange concept (sensitiveoutputhandling) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "capability_risk": { "capability_level": "elevated", "access_mode": "internal", "autonomy": "none", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "medium" }, "validation_objective": "Prove that the model is tested for verbatim memorization and regurgitation of sensitive training data against a documented leakage threshold, and that output filtering or a DP mitigation is applied and re-tested when the threshold is exceeded.", "evidence_required": [ "memorization_test_report with methodology (canaries/extraction prompts), leakage metric vs threshold, and pass/mitigated verdict", "mitigation record (output filter / DP settings) when applied, with the re-test result" ], "machine_tests": [ "Check the deployment manifest for a model lacking a memorization test result -> assert the gate holds the model for review.", "If regurgitation exceeds the threshold and no mitigation+re-test is recorded -> assert the gate routes the model to review before promotion." ], "human_review": [ "Review the leakage threshold and any mitigation-acceptance decision for residual-risk sign-off." ], "blocking_effect": "requires-review", "normative_status": "best-practice", "anti_patterns": [ "Assuming accuracy/fairness evals cover memorization — they do not probe verbatim regurgitation.", "Testing only with generic prompts, never with targeted extraction/canary probes." ], "update_status": "current" } ] } }