{ "dataset": { "meta": { "title": "AI Model & System Assurance Control Matrix", "subtitle": "modelverifier.ai — Apeiris Model Assurance Verifier", "domain": "model", "namespace": "apeiris://model", "site": "https://modelverifier.ai", "corpus_url": "https://modelverifier.ai/integration/model-controls-full.json", "version": "1.0.0", "schema_version": "1.0.0", "generated_at": "2026-06-27T19:44:43.151Z", "generated_by": "build-integration.mjs", "source_schema": "https://schema.apeiris.ai/model-assurance/v1/model-controls.schema.json", "license": "CC BY-NC 4.0", "license_url": "https://creativecommons.org/licenses/by-nc/4.0/", "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.", "release_manifest_url": "https://modelverifier.ai/integration/release-manifest.json", "cors": "enabled", "control_count": 54, "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" ], "layer_count": 6, "profile_count": 11, "framework_count": 10, "frameworks": [ "nist_rmf", "nist_ai_600_1", "iso_42001", "eu_ai_act", "sr262", "aisvs", "llm10", "aicm", "mitre", "owasp_aitg" ], "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" ], "planes": [ "control", "data", "both", "lifecycle" ], "has_warnings": false, "warning_count": 0, "content_hash": "sha256:489d5917de9d4bd9734c0f378ce599f61fa4f57e6a7795d0b8153831422e743a" }, "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 ML 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": "Accountability and transparency policies" }, { "id": "iso_42001", "section": "A.6.1", "title": "AI system lifecycle management" }, { "id": "sr262", "section": "S-1.1", "title": "Model inventory and identification" }, { "id": "aisvs", "section": "C1.1", "title": "AI governance — model identification" } ], "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", "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 }, { "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", "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" }, { "id": "sr262_2026", "title": "SR 26-2: Supervisory Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "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" }, { "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", "version": "1.0", "published_on": "2026-06-24", "retrieved_on": "2026-06-26", "canonical_url": "https://github.com/OWASP/www-project-ai-security-verification-standard", "license": "CC BY-SA 4.0", "status": "current", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "url": "https://github.com/OWASP/AISVS" } ], "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 requires that accountability and transparency policies for AI systems be established and maintained. Unique model identity and content-addressed hashing is a foundational mechanism for the traceability those policies depend on. LI-01 directly supports artifact-level traceability but does not cover role assignment, policy documentation, or the full accountability lifecycle that GOVERN-1.2 addresses.", "uncovered_portion": "GOVERN-1.2 addresses the full accountability policy lifecycle including roles, responsibilities, and escalation paths; LI-01 covers only the artifact identity and integrity mechanism.", "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" }, { "framework": "iso_42001", "requirement_id": "A.6.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001:2023 A.6.1 requires that AI systems be managed across their lifecycle with appropriate documentation and traceability. LI-01's content-addressed unique identity directly enables the artifact-level traceability and reproducibility that A.6.1 requires for lifecycle management.", "source_locator": { "section": "Annex A", "clause": "A.6.1" }, "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" }, { "framework": "sr262", "requirement_id": "S-1.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "SR 26-2 S-1.1 requires supervised institutions to maintain a model inventory that uniquely identifies each model, its version, and key attributes. LI-01 provides the technical mechanism — unique ID and content hash — that makes such an inventory auditable and tamper-evident. SR 26-2 is supervisory guidance, not binding law; this mapping reflects alignment with the guidance expectation.", "source_locator": { "section": "S-1", "clause": "S-1.1" }, "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" }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "direct", "direction": "bidirectional", "rationale": "OWASP AISVS C1.1 requires that organizations maintain an AI governance inventory with model identification. LI-01's unique ID and content hash requirement directly satisfies the identification component of C1.1 and makes the inventory auditable.", "source_locator": { "section": "C1", "clause": "C1.1" }, "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" }, { "framework": "mitre", "requirement_id": "AML.T0044", "fit": "partial", "direction": "control-supports-requirement", "rationale": "MITRE ATLAS AML.T0044 (Full ML 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": "5.6.0", "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" }, { "framework": "owasp_aitg", "requirement_id": "AITG-GV-01", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "AITG-GV-01 governance verification confirms that a unique model identifier registry is established and maintained; LI-01 is the implementation control that produces the artifact AITG-GV-01 checks, making this a supporting rather than direct test relationship.", "source_locator": { "section": "Governance Testing", "test_id": "AITG-GV-01" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "cross_domain": { "references": [ { "uri": "apeiris://security/controls/AS-08", "relationship": "related", "name": "Harden and assure the security control plane as tier-zero infrastructure", "note": "AS-08 hardens the security control plane (model registry, artifact stores, brokers) as tier-zero infrastructure, access-controlled and tamper-evident, which LI-01 depends on for model-identity tamper-evidence." } ], "evidence_artifacts": [ { "artifact_type": "model:registry-entry", "producer_verifier": "apeiris://model-assurance", "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" }, { "id": "LI-02", "cross_domain": { "references": [ { "relationship": "related", "uri": "apeiris://security/controls/AS-06", "name": "Verify model-weights and training-data provenance before load", "note": "AS-06 verifies model-weights and training-data provenance before load on the security side; it relies on this provenance chain." } ], "evidence_artifacts": [] }, "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 — Backdoor ML 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-1.5", "title": "Organizational risk tolerance and supply chain context" }, { "id": "iso_42001", "section": "A.6.2", "title": "AI system design and development records" }, { "id": "aisvs", "section": "C1.2", "title": "AI governance — lineage and provenance" }, { "id": "aicm", "section": "MG-01", "title": "Model governance — model 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", "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 }, { "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", "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" }, { "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", "version": "1.0", "published_on": "2026-06-24", "retrieved_on": "2026-06-26", "canonical_url": "https://github.com/OWASP/www-project-ai-security-verification-standard", "license": "CC BY-SA 4.0", "status": "current", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "url": "https://github.com/OWASP/AISVS" }, { "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": "informative", "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" } ], "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-1.5", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MAP-1.5 addresses AI risk identification including supply chain context. Provenance chain documentation directly supports MAP-1.5 by enabling identification of inherited risks from base models and third-party components. LI-02 does not cover the full MAP-1.5 risk identification scope beyond provenance.", "uncovered_portion": "MAP-1.5 addresses the full risk identification scope including intended use context and organizational risk tolerance; LI-02 covers only artifact lineage traceability.", "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" }, { "framework": "iso_42001", "requirement_id": "A.6.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001:2023 A.6.2 requires documentation of AI system design and development decisions. Provenance chain records directly satisfy A.6.2 by providing structured documentation of how each artifact was derived from its predecessors.", "source_locator": { "section": "Annex A", "clause": "A.6.2" }, "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" }, { "framework": "aisvs", "requirement_id": "C1.2", "fit": "direct", "direction": "bidirectional", "rationale": "OWASP AISVS C1.2 requires that model provenance and lineage be documented as part of AI governance. LI-02 directly implements C1.2 by requiring a structured, machine-readable provenance graph covering base models, fine-tuning steps, merges, and adapters.", "source_locator": { "section": "C1", "clause": "C1.2" }, "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" }, { "framework": "mitre", "requirement_id": "AML.T0018", "fit": "partial", "direction": "control-supports-requirement", "rationale": "MITRE ATLAS AML.T0018 (Backdoor ML 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": "5.6.0", "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" }, { "framework": "owasp_aitg", "requirement_id": "AITG-GV-02", "fit": "direct", "direction": "control-supports-requirement", "rationale": "LI-02 records a structured provenance graph covering base models, fine-tuning steps, merge contributors, and adapter lineage, directly supporting AITG-GV-02 Governance Testing which requires that the full ancestral lineage of a model artifact be documented and auditable.", "source_locator": { "section": "Governance Testing", "test_id": "AITG-GV-02" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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" }, { "id": "LI-03", "cross_domain": { "references": [ { "relationship": "mirrored-by", "uri": "apeiris://security/controls/PT-03", "name": "Verify skill/tool manifest integrity and sign the supply chain", "note": "PT-03 mirrors this on the security side: verify skill/tool manifest integrity and sign the supply chain." } ], "evidence_artifacts": [] }, "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 — Backdoor ML 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": "MAP-1.6", "title": "AI supply chain and third-party risk" }, { "id": "iso_42001", "section": "A.6.1", "title": "AI system lifecycle management" }, { "id": "aisvs", "section": "C1.3", "title": "AI governance — supply chain verification" } ], "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": "informative", "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 }, { "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", "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" }, { "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", "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" }, { "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": "informative", "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" } ], "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" }, { "framework": "nist_rmf", "requirement_id": "MAP-1.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MAP-1.6 addresses organizational policies for AI supply chain risk. LI-03 provides the technical mechanism for artifact-level supply chain integrity that MAP-1.6's policy framework depends on. LI-03 does not cover vendor management policies or contractual supply chain terms.", "uncovered_portion": "MAP-1.6 addresses vendor selection, contractual terms, and supply chain risk policies beyond artifact-level verification.", "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" }, { "framework": "iso_42001", "requirement_id": "A.6.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001:2023 A.6.1 requires that AI system components be managed across the lifecycle with appropriate controls. Supply chain integrity verification of third-party model artifacts supports A.6.1 by ensuring that external components entering the AI system are authenticated and documented. LI-03 does not cover the full A.6.1 lifecycle management scope.", "uncovered_portion": "A.6.1 covers the full AI system component lifecycle; LI-03 addresses only the artifact acquisition and verification phase.", "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" }, { "framework": "mitre", "requirement_id": "AML.T0018", "fit": "partial", "direction": "control-supports-requirement", "rationale": "MITRE ATLAS AML.T0018 (Backdoor ML 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": "5.6.0", "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" }, { "framework": "owasp_aitg", "requirement_id": "AITG-GV-01", "fit": "partial", "direction": "control-supports-requirement", "rationale": "LI-03 verifies third-party model artifacts against publisher-signed checksums and generates a model SBOM (mSBOM), supporting the AITG-GV-01 Governance Testing requirement that artifact identity and version integrity be confirmed before deployment. However, the mSBOM and chain-of-custody procedures extend into supply-chain documentation that AITG-GV-01 does not fully prescribe.", "source_locator": { "section": "Governance Testing", "test_id": "AITG-GV-01" }, "uncovered_portion": "AITG-GV-01 addresses identity and versioning of the model artifact itself; third-party supply-chain verification procedures including mSBOM generation and publisher-signed checksum workflows exceed what the test prescribes.", "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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" }, { "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-1.1", "title": "Policies and procedures for AI risk documentation" }, { "id": "iso_42001", "section": "A.6.2", "title": "AI system design and development records" }, { "id": "sr262", "section": "S-2.1", "title": "Model development documentation requirements" }, { "id": "aisvs", "section": "C1.4", "title": "AI governance — model 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": "informative", "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 }, { "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" }, { "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", "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" }, { "id": "sr262_2026", "title": "SR 26-2: Supervisory Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "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" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 — AI Management System", "source_type": "voluntary-standard", "retrieved_on": "2026-06-26", "normative_force": "voluntary", "version": "unknown", "status": "current", "authority": "ISO/IEC JTC 1/SC 42", "license": "proprietary-paid" } ], "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-1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-1.1 requires organizational policies for AI risk documentation and accountability to be established. A mandatory, schema-validated model card is a key mechanism implementing GOVERN-1.1's documentation requirement. GOVERN-1.1 also encompasses policy governance structures that LI-04 does not address.", "uncovered_portion": "GOVERN-1.1 includes policy governance structures, leadership accountability, and organizational AI risk culture beyond model-level documentation.", "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" }, { "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" }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "SR 26-2 S-2.1 requires that model development be documented including model purpose, assumptions, limitations, and performance characteristics. The Mitchell et al. model card structure directly implements S-2.1 documentation requirements with schema-enforced completeness. SR 26-2 is supervisory guidance, not binding law.", "source_locator": { "section": "S-2", "clause": "S-2.1" }, "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" }, { "framework": "iso_42001", "requirement_id": "A.6.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001:2023 A.6.2 requires documented records of AI system design and development decisions. A complete, versioned model card linked to the artifact hash satisfies A.6.2 by providing a structured, retrievable development record.", "source_locator": { "section": "Annex A", "clause": "A.6.2" }, "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", "uncovered_portion": "A.6.2 additionally addresses documentation governance, document control procedures, version approval workflows, and distribution controls beyond model card content requirements." }, { "framework": "mitre", "requirement_id": "AML.T0044", "fit": "adjacent", "direction": "tangential", "rationale": "MITRE ATLAS AML.T0044 (Full ML 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": "5.6.0", "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" }, { "framework": "owasp_aitg", "requirement_id": "AITG-GV-02", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "AITG-GV-02 reviews whether structured model documentation exists and is complete; LI-04 implements the model card that AITG-GV-02 checks, making this a supporting relationship — AITG verifies the artifact, LI-04 produces it.", "source_locator": { "section": "Governance Testing", "test_id": "AITG-GV-02" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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" }, { "id": "LI-05", "cross_domain": { "references": [ { "relationship": "related", "uri": "apeiris://security/controls/AS-06", "name": "Verify model-weights and training-data provenance before load", "note": "AS-06 verifies training-data provenance before load on the security side; it relies on this lineage pointer." } ], "evidence_artifacts": [] }, "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": "sr262", "section": "S-1.2", "title": "Model inventory — training data documentation" }, { "id": "nist_rmf", "section": "MAP-2.1", "title": "Scientific and established AI principles inform context" }, { "id": "iso_42001", "section": "A.6.2", "title": "AI system design and development records" }, { "id": "aisvs", "section": "C2.1", "title": "Training data — data lineage and provenance" } ], "sources": [ { "id": "sr262_2026", "title": "SR 26-2: Supervisory Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "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", "flagship": true }, { "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", "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" }, { "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", "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" }, { "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", "version": "1.0", "published_on": "2026-06-24", "retrieved_on": "2026-06-26", "canonical_url": "https://github.com/OWASP/www-project-ai-security-verification-standard", "license": "CC BY-SA 4.0", "status": "current", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "url": "https://github.com/OWASP/AISVS" } ], "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": "sr262", "requirement_id": "S-1.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "SR 26-2 S-1.2 requires model inventory documentation to include information about model inputs, including training data. LI-05's training-data pointer requirement directly satisfies S-1.2 by establishing a machine-resolvable link from every model registry entry to the authoritative training dataset record. SR 26-2 is supervisory guidance, not binding law.", "source_locator": { "section": "S-1", "clause": "S-1.2" }, "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence" }, { "framework": "nist_rmf", "requirement_id": "MAP-2.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MAP-2.1 addresses scientific and established AI principles for understanding AI system context, including data inputs. The training-data pointer supports MAP-2.1 by ensuring model context documentation includes a traceable reference to training data provenance. LI-05 does not cover the full MAP-2.1 contextual framing scope.", "uncovered_portion": "MAP-2.1 addresses broader contextual understanding of AI system inputs including deployment context and data representativeness; LI-05 covers only the registry linkage mechanism.", "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" }, { "framework": "iso_42001", "requirement_id": "A.6.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001:2023 A.6.2 requires documentation of AI system design and development, which includes training data inputs. LI-05's linkage between model registry and dataset record supports A.6.2 by providing a retrievable reference to training data documentation.", "uncovered_portion": "A.6.2 covers the full development record; LI-05 addresses only the data-linkage component.", "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" }, { "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": "5.6.0", "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" }, { "framework": "owasp_aitg", "requirement_id": "AITG-DG-01", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "LI-05 creates a structured pointer from the model registry entry to the authoritative TG-layer dataset record, directly satisfying the AITG-DG-01 Data Governance Testing requirement that the provenance and lineage of training data used by a model be documented and traceable from the model artifact to its data sources.", "source_locator": { "section": "Data Governance Testing", "test_id": "AITG-DG-01" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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" }, { "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 ML 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.2", "title": "AI risk treatment and version control" }, { "id": "iso_42001", "section": "A.8.1", "title": "AI system operation — change management" }, { "id": "eu_ai_act", "section": "Art-12", "title": "Record-keeping for high-risk AI systems" }, { "id": "sr262", "section": "S-5.1", "title": "Ongoing monitoring — version and change tracking" }, { "id": "aisvs", "section": "C6.2", "title": "Model deployment — version control and 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", "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 }, { "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", "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" }, { "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" }, { "id": "sr262_2026", "title": "SR 26-2: Supervisory Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "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" } ], "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.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MANAGE-2.2 requires that AI risks be treated through mechanisms including change management and rollback capabilities. LI-06 directly implements the artifact versioning, rollback, and emergency disable controls that MANAGE-2.2 requires for production AI risk treatment.", "source_locator": { "section": "MANAGE-2", "clause": "MANAGE-2.2" }, "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" }, { "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" }, { "framework": "iso_42001", "requirement_id": "A.8.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001:2023 A.8.1 requires that AI system operations be managed with appropriate change management controls. LI-06's append-only versioning, deployment logging, tested rollback, and emergency disable collectively implement A.8.1's change management requirements for AI system operations.", "source_locator": { "section": "Annex A", "clause": "A.8.1" }, "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" }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 S-5.1 requires ongoing monitoring to detect unauthorized or unexpected model changes and to ensure model behavior remains consistent with approved documentation. The version drift monitoring metrics in LI-06's monitoring_schema directly support S-5.1's change detection requirement. SR 26-2 is supervisory guidance, not binding law.", "uncovered_portion": "S-5.1 also covers outcomes analysis and behavioral drift monitoring beyond artifact-hash monitoring; those are addressed in BH-03 and CR-01.", "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "initial", "assurance_result": "not-assessed", "evidence_status": "no-evidence" }, { "framework": "mitre", "requirement_id": "AML.T0044", "fit": "partial", "direction": "control-supports-requirement", "rationale": "MITRE ATLAS AML.T0044 (Full ML 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": "5.6.0", "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" }, { "framework": "owasp_aitg", "requirement_id": "AITG-RT-06", "fit": "direct", "direction": "control-supports-requirement", "rationale": "LI-06 requires that every material change to a deployed model or system configuration pass a formal authorization gate before reaching production, directly supporting AITG-RT-06 Runtime Testing which validates that change authorization controls prevent unauthorized model updates from entering the production serving environment.", "source_locator": { "section": "Runtime Testing", "test_id": "AITG-RT-06" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "cross_domain": { "references": [ { "uri": "apeiris://security/controls/AS-08", "relationship": "related", "name": "Harden and assure the security control plane as tier-zero infrastructure", "note": "AS-08 hardens the control plane as tier-zero infrastructure with access-controlled, tamper-evident change control over model-registry writes, which LI-06 immutability semantics depend on." } ], "evidence_artifacts": [ { "artifact_type": "model:deployment-log", "producer_verifier": "apeiris://model-assurance", "consumer_verifiers": [ "apeiris://security" ], "retention": "P7Y" }, { "artifact_type": "model:rollback-test-record", "producer_verifier": "apeiris://model-assurance", "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" } } ] }, { "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": "GOVERN-1.5", "title": "Organizational risk tolerance for AI systems" }, { "id": "iso_42001", "section": "A.6.1", "title": "AI system lifecycle management — intended use documentation" }, { "id": "aisvs", "section": "C3.1", "title": "Model design — capability and limitation declaration" } ], "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 }, { "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", "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" }, { "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", "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" }, { "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", "version": "1.0", "published_on": "2026-06-24", "retrieved_on": "2026-06-26", "canonical_url": "https://github.com/OWASP/www-project-ai-security-verification-standard", "license": "CC BY-SA 4.0", "status": "current", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "url": "https://github.com/OWASP/AISVS" } ], "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" }, { "framework": "nist_rmf", "requirement_id": "GOVERN-1.5", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-1.5 requires that organizational risk tolerance for AI systems be documented and applied to AI deployment decisions. A formal capability-limitation declaration enables deployers to compare their risk tolerance against the model's declared limitations and out-of-scope uses. LI-07 provides the information basis for GOVERN-1.5 decisions; it does not itself establish the risk tolerance policy.", "uncovered_portion": "GOVERN-1.5 addresses the establishment of risk tolerance policies and governance structures; LI-07 provides the model-level information that informs those policies.", "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" }, { "framework": "iso_42001", "requirement_id": "A.6.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001:2023 A.6.1 requires documentation of intended use and scope for AI systems across the lifecycle. LI-07's intended_uses and out_of_scope_uses dimensions directly implement the scope documentation requirement in A.6.1.", "uncovered_portion": "A.6.1 covers the full lifecycle management scope including monitoring and end-of-life; LI-07 covers only the capability and limitation declaration at the design and release phase.", "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" }, { "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" } ], "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" } } ] }, { "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.6", "title": "Policies for AI-related legal and IP obligations" }, { "id": "iso_42001", "section": "A.5.2", "title": "AI system impact — legal and regulatory considerations" }, { "id": "aisvs", "section": "C1.3", "title": "AI governance — license and IP governance" }, { "id": "aicm", "section": "GOV-02", "title": "Governance — legal compliance and IP management" } ], "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", "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 }, { "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", "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" }, { "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", "version": "1.0", "published_on": "2026-06-24", "retrieved_on": "2026-06-26", "canonical_url": "https://github.com/OWASP/www-project-ai-security-verification-standard", "license": "CC BY-SA 4.0", "status": "current", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "url": "https://github.com/OWASP/AISVS" }, { "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", "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" } ], "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.6", "fit": "direct", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN-1.6 requires policies addressing legal, compliance, and IP obligations related to AI systems. LI-08's license chain tracking and automated compatibility analysis directly operationalize GOVERN-1.6 for the IP obligation dimension.", "source_locator": { "section": "GOVERN-1", "clause": "GOVERN-1.6" }, "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" }, { "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" }, { "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" }, { "framework": "aicm", "requirement_id": "MDS-03", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CSA AICM GOV-02 addresses AI governance requirements for legal compliance and IP management. LI-08's license chain record and compatibility analysis directly implement GOV-02's IP management requirement for AI systems.", "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": { "section": "GOV — Governance", "clause": "GOV-02" }, "provisional": true }, { "framework": "owasp_aitg", "requirement_id": "AITG-GV-04", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "AITG-GV-04 reviews AI governance committee structure and oversight accountability; LI-08 establishes the governance body whose existence AITG-GV-04 verifies, making this a supporting relationship.", "source_locator": { "section": "Governance Testing", "test_id": "AITG-GV-04" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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" }, { "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": "sr262", "section": "S-3.2", "title": "Re-validation requirements for material model changes" }, { "id": "nist_rmf", "section": "MANAGE-4.1", "title": "AI risk treatment for significant changes" }, { "id": "iso_42001", "section": "A.8.2", "title": "AI system operation — change management and impact assessment" }, { "id": "eu_ai_act", "section": "Art-9", "title": "Risk management system — lifecycle risk assessment" }, { "id": "aisvs", "section": "C7.3", "title": "Model operations — change management and material change determination" } ], "sources": [ { "id": "sr262_2026", "title": "SR 26-2: Supervisory Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "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", "flagship": true }, { "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" }, { "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", "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" }, { "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", "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" } ], "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": "Board of Governors of the Federal Reserve System", "instrument": "SR 26-2", "provision": "S-3.2", "jurisdiction": [ "us" ], "sector": [ "banking", "financial-services" ], "actor_roles": [ "operator", "developer" ], "subject_types": [ "model" ], "normative_force": "supervisory-guidance", "legal_status": "enacted", "effective_from": "2026-04-01", "applicability": { "all": [ { "field": "assurance_target.regulated_entity", "op": "eq-true", "value": true }, { "field": "assurance_target.jurisdiction", "op": "contains", "value": "us" } ] }, "mapping_fit": "direct", "source_ref": "sr262", "reviewed_on": "2026-06-26", "notes": "SR 26-2 S-3.2 requires that material changes to models trigger re-validation by an independent team. SR 26-2 defines 'material change' broadly; LI-09 operationalizes this definition with a seven-category taxonomy. SR 26-2 is supervisory guidance, not binding law — noncompliance alone does not trigger supervisory action, but patterns of unsafe practice do. Heightened expectations apply to institutions with $30B+ in assets." }, { "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": "sr262", "requirement_id": "S-3.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "SR 26-2 S-3.2 requires that material model changes trigger a re-validation process. LI-09's material-change taxonomy and authorization gate directly operationalize S-3.2 by defining what constitutes a material change across all seven change categories and requiring a classification decision before deployment. SR 26-2 is supervisory guidance, not binding law.", "source_locator": { "section": "S-3", "clause": "S-3.2" }, "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence" }, { "framework": "nist_rmf", "requirement_id": "MANAGE-4.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MANAGE-4.1 requires risk treatment responses to significant changes in AI system behavior or deployment context. LI-09's material-change determination gate is the mechanism that identifies which changes constitute 'significant changes' requiring MANAGE-4.1 risk treatment responses.", "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" }, { "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" }, { "framework": "iso_42001", "requirement_id": "A.8.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001:2023 A.8.2 requires that changes to AI systems be managed through an appropriate change management process with impact assessment. LI-09's material-change taxonomy, classification gate, and authorization workflow directly implement A.8.2's change management and impact assessment requirements for AI systems.", "source_locator": { "section": "Annex A", "clause": "A.8.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" }, { "framework": "owasp_aitg", "requirement_id": "AITG-IR-03", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "LI-09 establishes system-level composite identity covering the model artifact, system prompt, RAG corpus, and tool integrations, and defines a change-authorization process for any material alteration — directly implementing the AITG-IR-03 Incident Response Testing requirement that the system configuration at the time of any incident be uniquely identifiable and reconstructable for post-incident analysis.", "source_locator": { "section": "Incident Response Testing", "test_id": "AITG-IR-03" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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" }, { "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": "MANAGE-4.2", "title": "Decommissioning of AI systems" }, { "id": "iso_42001", "section": "A.8.1", "title": "AI system operation — lifecycle end-of-life management" }, { "id": "sr262", "section": "S-4.1", "title": "Governance — model lifecycle including retirement" }, { "id": "aisvs", "section": "C6.3", "title": "Model deployment — decommissioning and archival" } ], "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", "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 }, { "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", "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" }, { "id": "sr262_2026", "title": "SR 26-2: Supervisory Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "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" }, { "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" } ], "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": "MANAGE-4.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MANAGE-4.2 specifically addresses AI system decommissioning as a risk management activity. LI-10 directly implements MANAGE-4.2 by requiring authorized retirement, dependent-system impact assessment, evidence archiving, and registry status management as the operational decommissioning procedure.", "source_locator": { "section": "MANAGE-4", "clause": "MANAGE-4.2" }, "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" }, { "framework": "iso_42001", "requirement_id": "A.8.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 42001:2023 A.8.1 addresses AI system operation lifecycle management including end-of-life procedures. LI-10's retirement workflow and evidence archiving implement the end-of-life dimension of A.8.1. A.8.1 covers the full operational lifecycle; LI-10 addresses only the retirement and archiving phase.", "uncovered_portion": "A.8.1 covers ongoing operational management including monitoring and incident response beyond the retirement phase addressed by LI-10.", "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" }, { "framework": "sr262", "requirement_id": "S-4.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 S-4.1 requires that model governance cover the full model lifecycle including retirement decisions and documentation. LI-10's retirement authorization workflow and dependent-system impact assessment align with S-4.1's governance scope for model lifecycle management. SR 26-2 is supervisory guidance, not binding law.", "uncovered_portion": "S-4.1 addresses model governance broadly including development and validation oversight; LI-10 covers only the retirement phase.", "source_version": "SR 26-2", "reviewed_on": "2026-06-26", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "guidance", "control_readiness": "approved", "implementation_maturity": "none", "assurance_result": "not-assessed", "evidence_status": "no-evidence" }, { "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" }, { "framework": "owasp_aitg", "requirement_id": "AITG-RT-08", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "LI-10 governs model retirement at the registry level — requiring authorized retirement decisions, evidence archiving, and dependency impact assessment before decommissioning — addressing the same supply-chain governance domain as AITG-RT-08 Runtime Testing but focused on the lifecycle endpoint (retirement) rather than active upstream component change monitoring.", "source_locator": { "section": "Runtime Testing", "test_id": "AITG-RT-08" }, "uncovered_portion": "AITG-RT-08 requires active monitoring for changes to AI providers and upstream supply-chain components in the production runtime; LI-10 addresses model retirement governance and evidence archiving at end-of-life, which is a distinct lifecycle concern in the same supply-chain domain.", "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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" } } ] }, { "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 §8.4", "EU AI Act Art. 10(2)", "NIST AI RMF MAP 2.2", "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "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 }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" } ], "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.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Data quality gates directly implement NIST AI RMF data and risk mapping practices", "uncovered_portion": "NIST also addresses impact assessment of data quality failures on downstream stakeholders", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "iso_42001", "requirement_id": "8.4", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Schema validation and provenance checks implement ISO 42001 §8.4 data quality requirements", "reviewed_on": "2026-06-26", "source_version": "2023", "source_locator": { "section": "ISO/IEC 42001:2023", "clause": "8.4" } }, { "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" }, { "framework": "sr262", "requirement_id": "S-5.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "SR 26-2 requires documented data quality standards in model development", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "source_locator": { "section": "SR 26-2 — Model Risk Management", "clause": "S-5.2" } }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Training data quality validation aligns with AISVS data security requirements", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "section": "OWASP AISVS v1.0", "clause": "C5.1" } }, { "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" }, { "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 }, { "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": "5.6.0" }, { "framework": "owasp_aitg", "requirement_id": "AITG-DG-01", "fit": "direct", "direction": "control-supports-requirement", "rationale": "TG-01 gates training pipeline execution behind automated schema validation, completeness checks, and signed provenance verification, directly implementing the AITG-DG-01 Data Governance Testing requirement that training data quality and provenance be verified and attested before any model training run proceeds.", "source_locator": { "section": "Data Governance Testing", "test_id": "AITG-DG-01" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" } }, { "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 §8.4", "NIST AI RMF MAP 5.1, GOVERN 5.1", "SR 26-2 §IV.B" ], "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 }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "id": "sr262_2026", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26" } ], "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": "MAP-5.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Subgroup analysis operationalizes NIST AI RMF bias identification and fairness mapping practices", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "section": "NIST AI RMF 1.0", "clause": "MAP-5.1" } }, { "framework": "iso_42001", "requirement_id": "8.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Representativeness assessment is an ISO 42001 data quality requirement", "reviewed_on": "2026-06-26", "source_version": "2023", "source_locator": { "section": "ISO/IEC 42001:2023", "clause": "8.4" }, "uncovered_portion": "ISO 42001 §8.4 addresses the full data management lifecycle including acquisition, labeling, storage, access controls, and retirement — this control covers one aspect of that requirement." }, { "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" } }, { "framework": "sr262", "requirement_id": "S-1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 requires identification and documentation of data limitations including representativeness", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "source_locator": { "section": "SR 26-2 — Model Risk Management", "clause": "S-1.1" }, "uncovered_portion": "SR 26-2 S-1.1 additionally requires model inventory governance, ownership assignment, business unit mapping, and periodic inventory reconciliation beyond unique model identification." }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Bias assessment supports AISVS data security and quality requirements", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "section": "OWASP AISVS v1.0", "clause": "C5.1" }, "uncovered_portion": "AISVS C5.1 covers the full data security and privacy lifecycle including storage encryption, access controls, data subject rights, and retention — this control addresses one aspect." }, { "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." }, { "framework": "aicm", "requirement_id": "DSP-20", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Subgroup analysis is a core AICM fairness control", "reviewed_on": "2026-06-26", "source_version": "1.1", "source_locator": { "section": "CSA AI Controls Matrix v1.1", "clause": "GOV-04" }, "mapping_confidence": "medium", "provisional": true }, { "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": "5.6.0" }, { "framework": "owasp_aitg", "requirement_id": "AITG-DG-01", "fit": "partial", "direction": "control-supports-requirement", "rationale": "TG-02 conducts subgroup and intersectional fairness analysis on training data to assess population representativeness, partially aligning with AITG-DG-01 Data Governance Testing which addresses data quality and provenance validation. Bias and representativeness assessment goes beyond provenance chain verification into fairness measurement that the test does not fully cover.", "source_locator": { "section": "Data Governance Testing", "test_id": "AITG-DG-01" }, "uncovered_portion": "AITG-DG-01 addresses data quality and provenance validation; bias and representativeness assessment of training data subgroups extends beyond the quality-gate and provenance-chain checks defined in the test.", "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" } }, { "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 §8.4", "SR 26-2 §IV.B" ], "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 }, { "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" }, { "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" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "id": "sr262_2026", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26" } ], "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-2.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DRR implements NIST AI RMF legal and regulatory context mapping for training data", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "section": "NIST AI RMF 1.0", "clause": "GOVERN-2.2" } }, { "framework": "iso_42001", "requirement_id": "8.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Legal authority documentation is required by ISO 42001 for data used in AI systems", "reviewed_on": "2026-06-26", "source_version": "2023", "source_locator": { "section": "ISO/IEC 42001:2023", "clause": "8.4" }, "uncovered_portion": "ISO 42001 §8.4 addresses the full data management lifecycle including acquisition, labeling, storage, access controls, and retirement — this control covers one aspect of that requirement." }, { "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." }, { "framework": "sr262", "requirement_id": "S-5.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 data sourcing documentation requirements are met by DRR entries for regulated institution models", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "source_locator": { "section": "SR 26-2 — Model Risk Management", "clause": "S-5.2" }, "uncovered_portion": "SR 26-2 S-5.2 addresses the full data governance program including data quality policies, data stewardship roles, access controls, and retention schedules — this control covers one aspect." }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Data rights documentation is an AISVS data security requirement", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "section": "OWASP AISVS v1.0", "clause": "C5.1" }, "uncovered_portion": "AISVS C5.1 covers the full data security and privacy lifecycle including storage encryption, access controls, data subject rights, and retention — this control addresses one aspect." }, { "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." }, { "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 }, { "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": "5.6.0" }, { "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." }, { "framework": "owasp_aitg", "requirement_id": "AITG-DG-02", "fit": "direct", "direction": "control-supports-requirement", "rationale": "TG-03 establishes a Data Rights Registry documenting the specific legal basis, jurisdiction treatment, and permitted-use scope for every training dataset, directly implementing AITG-DG-02 Data Governance Testing which requires that lawful authority and data rights documentation be established and verified for all data used in model training.", "source_locator": { "section": "Data Governance Testing", "test_id": "AITG-DG-02" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" } }, { "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 MAP 3.5", "ISO/IEC 42001:2023 §8.4", "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": "informative", "version": "5.6.0", "published_on": "2026-05-04", "retrieved_on": "2026-06-26" }, { "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", "version": "2025", "published_on": "2024-11-17", "retrieved_on": "2026-06-26" }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "flagship": true } ], "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": { "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.", "risk_level": "critical", "relevant_profiles": [ "frontier-capability", "continuously-learning", "eu-high-risk" ], "capability_level": "elevated" }, "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": "MAP-3.5", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Cryptographic integrity controls directly implement NIST AI RMF data integrity requirements", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "section": "NIST AI RMF 1.0", "clause": "MAP-3.5" } }, { "framework": "iso_42001", "requirement_id": "8.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Chain-of-custody and integrity verification are ISO 42001 data governance requirements", "reviewed_on": "2026-06-26", "source_version": "2023", "source_locator": { "section": "ISO/IEC 42001:2023", "clause": "8.4" }, "uncovered_portion": "ISO 42001 §8.4 addresses the full data management lifecycle including acquisition, labeling, storage, access controls, and retirement — this control covers one aspect of that requirement." }, { "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." }, { "framework": "sr262", "requirement_id": "S-5.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Data integrity documentation is required by SR 26-2 for model development controls", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "source_locator": { "section": "SR 26-2 — Model Risk Management", "clause": "S-5.2" }, "uncovered_portion": "SR 26-2 S-5.2 addresses the full data governance program including data quality policies, data stewardship roles, access controls, and retention schedules — this control covers one aspect." }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Hash verification and chain-of-custody implement AISVS data integrity requirements", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "section": "OWASP AISVS v1.0", "clause": "C5.1" }, "uncovered_portion": "AISVS C5.1 covers the full data security and privacy lifecycle including storage encryption, access controls, data subject rights, and retention — this control addresses one aspect." }, { "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" }, { "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 }, { "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": "5.6.0" }, { "framework": "owasp_aitg", "requirement_id": "AITG-ME-04", "fit": "partial", "direction": "control-supports-requirement", "rationale": "TG-04 implements cryptographic hash-pinning, chain-of-custody logging, and adversarial content screening to prevent data poisoning during training, partially aligning with AITG-ME-04 Model Evaluation Testing which covers adversarial robustness. The training-time poisoning prevention focus addresses the upstream threat origin rather than the post-deployment adversarial probe methodology the test defines.", "source_locator": { "section": "Model Evaluation Testing", "test_id": "AITG-ME-04" }, "uncovered_portion": "AITG-ME-04 covers adversarial robustness testing on the deployed model; data poisoning prevention at training time addresses the upstream threat source rather than the adversarial probe suite the test defines for production models.", "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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" }, { "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 §8.4, §8.5", "NIST AI RMF MAP 2.2, EVAL 4.1", "SR 26-2 §IV.C Model Validation" ], "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "id": "sr262_2026", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26", "flagship": true } ], "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.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Data separation and contamination prevention implement NIST AI RMF evaluation integrity requirements", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "section": "NIST AI RMF 1.0", "clause": "MAP-2.2" } }, { "framework": "iso_42001", "requirement_id": "8.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Split separation and contamination detection are ISO 42001 data management and evaluation requirements", "reviewed_on": "2026-06-26", "source_version": "2023", "source_locator": { "section": "ISO/IEC 42001:2023", "clause": "8.4" }, "uncovered_portion": "ISO 42001 §8.4 addresses the full data management lifecycle including acquisition, labeling, storage, access controls, and retirement — this control covers one aspect of that requirement." }, { "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" } }, { "framework": "sr262", "requirement_id": "S-2.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "SR 26-2 requires independent validation with data separation from development", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "source_locator": { "section": "SR 26-2 — Model Risk Management", "clause": "S-2.2" } }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Data split integrity is an AISVS data quality and security requirement", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "section": "OWASP AISVS v1.0", "clause": "C5.1" }, "uncovered_portion": "AISVS C5.1 covers the full data security and privacy lifecycle including storage encryption, access controls, data subject rights, and retention — this control addresses one aspect." }, { "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" } }, { "framework": "aicm", "requirement_id": "DSP-24", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Train/eval separation is a core AICM evaluation control", "reviewed_on": "2026-06-26", "source_version": "1.1", "source_locator": { "section": "CSA AI Controls Matrix v1.1", "clause": "EVA-01" }, "mapping_confidence": "medium", "provisional": true }, { "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": "5.6.0" }, { "framework": "owasp_aitg", "requirement_id": "AITG-DG-03", "fit": "direct", "direction": "control-supports-requirement", "rationale": "TG-05 enforces strict separation between training, evaluation, and test splits and implements contamination detection including exact-match deduplication, near-duplicate semantic detection, and retrieval leakage checks — directly implementing AITG-DG-03 Data Governance Testing which requires that training and evaluation data partitions be segregated and contamination-free to ensure valid performance measurement.", "source_locator": { "section": "Data Governance Testing", "test_id": "AITG-DG-03" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "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" } } ] }, { "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 §8.4", "NIST AI RMF GOVERN 5.1" ], "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 }, { "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" }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" } ], "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": "GOVERN-5.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Data minimization and privacy by design implement NIST AI RMF privacy and fairness governance requirements", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "section": "NIST AI RMF 1.0", "clause": "GOVERN-5.1" } }, { "framework": "iso_42001", "requirement_id": "8.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Data minimization is an ISO 42001 data quality and governance requirement", "reviewed_on": "2026-06-26", "source_version": "2023", "source_locator": { "section": "ISO/IEC 42001:2023", "clause": "8.4" }, "uncovered_portion": "ISO 42001 §8.4 addresses the full data management lifecycle including acquisition, labeling, storage, access controls, and retirement — this control covers one aspect of that requirement." }, { "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." }, { "framework": "sr262", "requirement_id": "S-5.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Data governance documentation required by SR 26-2 includes PII handling policies", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "source_locator": { "section": "SR 26-2 — Model Risk Management", "clause": "S-5.2" }, "uncovered_portion": "SR 26-2 S-5.2 addresses the full data governance program including data quality policies, data stewardship roles, access controls, and retention schedules — this control covers one aspect." }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "PII minimization and access controls implement AISVS data security requirements", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "section": "OWASP AISVS v1.0", "clause": "C5.1" }, "uncovered_portion": "AISVS C5.1 covers the full data security and privacy lifecycle including storage encryption, access controls, data subject rights, and retention — this control addresses one aspect." }, { "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." }, { "framework": "aicm", "requirement_id": "DSP-08", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Data minimization and necessity controls are core AICM privacy controls", "reviewed_on": "2026-06-26", "source_version": "1.1", "source_locator": { "section": "CSA AI Controls Matrix v1.1", "clause": "PRV-01" }, "mapping_confidence": "medium", "provisional": true }, { "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", "uncovered_portion": "Runtime exfiltration controls addressed in BH layer", "reviewed_on": "2026-06-26", "source_version": "5.6.0" }, { "framework": "owasp_aitg", "requirement_id": "AITG-DG-04", "fit": "direct", "direction": "control-supports-requirement", "rationale": "TG-06 establishes data retention, deletion, and lifecycle governance policies for training datasets including right-to-erasure operationalization and pipeline quarantine workflows, directly supporting AITG-DG-04 Data Governance Testing which requires that training data lifecycle controls — including retention limits and deletion procedures — be documented and operationally enforced.", "source_locator": { "section": "Data Governance Testing", "test_id": "AITG-DG-04" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" } }, { "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 §8.4", "NIST AI RMF GOVERN 6.2", "MITRE ATLAS v5.6.0 AML.T0018", "EU AI Act Art. 10(2)(c)", "SR 26-2 §V Third-Party Model Risk" ], "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": "informative", "version": "5.6.0", "published_on": "2026-05-04", "retrieved_on": "2026-06-26" }, { "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", "version": "2025", "published_on": "2024-11-17", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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 }, { "id": "sr262_2026", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26" } ], "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.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "TPDR implements NIST AI RMF third-party and supply chain risk management requirements", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "section": "NIST AI RMF 1.0", "clause": "GOVERN-6.2" } }, { "framework": "iso_42001", "requirement_id": "8.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Third-party dataset governance is an ISO 42001 data management requirement", "reviewed_on": "2026-06-26", "source_version": "2023", "source_locator": { "section": "ISO/IEC 42001:2023", "clause": "8.4" }, "uncovered_portion": "ISO 42001 §8.4 addresses the full data management lifecycle including acquisition, labeling, storage, access controls, and retirement — this control covers one aspect of that requirement." }, { "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." }, { "framework": "sr262", "requirement_id": "S-3.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Third-party dataset due diligence implements SR 26-2 third-party risk management requirements", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "source_locator": { "section": "SR 26-2 — Model Risk Management", "clause": "S-3.1" } }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Third-party dataset integrity controls implement AISVS supply chain security requirements", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "section": "OWASP AISVS v1.0", "clause": "C5.1" }, "uncovered_portion": "AISVS C5.1 covers the full data security and privacy lifecycle including storage encryption, access controls, data subject rights, and retention — this control addresses one aspect." }, { "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." }, { "framework": "aicm", "requirement_id": "STA-09", "fit": "direct", "direction": "control-supports-requirement", "rationale": "TPDR is the primary AICM third-party data supply chain control", "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 }, { "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": "5.6.0" }, { "framework": "owasp_aitg", "requirement_id": "AITG-DG-01", "fit": "partial", "direction": "control-supports-requirement", "rationale": "TG-07 performs supply-chain integrity verification for third-party training datasets including vendor checksum validation and contractual due-diligence, partially aligning with AITG-DG-01 Data Governance Testing which defines data quality and provenance checks. The third-party vendor verification and contractual scope extend beyond the dataset-level provenance validation in the test.", "source_locator": { "section": "Data Governance Testing", "test_id": "AITG-DG-01" }, "uncovered_portion": "AITG-DG-01 defines data quality and provenance checks for training datasets; third-party data supply chain verification including vendor checksum and contractual due-diligence procedures go beyond the dataset-level provenance validation in the test.", "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "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" } } ] }, { "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 §8.4", "SR 26-2 §IV record-keeping" ], "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 }, { "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" }, { "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" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "id": "sr262_2026", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26" } ], "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-2.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Lifecycle policy implements NIST AI RMF data management and documentation retention requirements", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "section": "NIST AI RMF 1.0", "clause": "GOVERN-2.2" }, "uncovered_portion": "GOVERN-2.2 additionally addresses organizational data governance policies, roles, accountability structures, and data stewardship practices beyond the scope of this control." }, { "framework": "iso_42001", "requirement_id": "8.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Dataset lifecycle management is an ISO 42001 data governance requirement", "reviewed_on": "2026-06-26", "source_version": "2023", "source_locator": { "section": "ISO/IEC 42001:2023", "clause": "8.4" }, "uncovered_portion": "ISO 42001 §8.4 addresses the full data management lifecycle including acquisition, labeling, storage, access controls, and retirement — this control covers one aspect of that requirement." }, { "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." }, { "framework": "sr262", "requirement_id": "S-4.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "SR 26-2 record-keeping requirements define minimum retention for regulated institution model artifacts", "reviewed_on": "2026-06-26", "source_version": "SR 26-2", "source_locator": { "section": "SR 26-2 — Model Risk Management", "clause": "S-4.2" } }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Data lifecycle controls support AISVS data security and governance requirements", "reviewed_on": "2026-06-26", "source_version": "1.0", "source_locator": { "section": "OWASP AISVS v1.0", "clause": "C5.1" }, "uncovered_portion": "AISVS C5.1 covers the full data security and privacy lifecycle including storage encryption, access controls, data subject rights, and retention — this control addresses one aspect." }, { "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." }, { "framework": "aicm", "requirement_id": "DSP-03", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Lifecycle policy is a core AICM data 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 }, { "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", "reviewed_on": "2026-06-26", "source_version": "5.6.0", "source_locator": { "section": "MITRE ATLAS v5.6.0", "clause": "AML.T0024" } }, { "framework": "owasp_aitg", "requirement_id": "AITG-DG-05", "fit": "direct", "direction": "control-supports-requirement", "rationale": "TG-08 implements controls over feedback-loop data used for RLHF and continual learning — including feedback integrity verification, preference data quality gates, and reward signal validation — directly implementing AITG-DG-05 Data Governance Testing which requires that feedback and reinforcement learning data used in model updates be governed with the same rigor as initial training data.", "source_locator": { "section": "Data Governance Testing", "test_id": "AITG-DG-05" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" } }, { "id": "EV-01", "cross_domain": { "references": [ { "relationship": "related", "uri": "apeiris://security/controls/AS-03", "name": "Gate releases on continuous adversarial validation", "note": "AS-03 gates releases on continuous adversarial validation on the security side." } ], "evidence_artifacts": [] }, "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.1", "NIST AI RMF MANAGE 2.2", "ISO/IEC 42001:2023 §9.1", "EU AI Act Art. 9", "SR 26-2 §III.B" ], "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "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 }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26" } ], "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": "GOVERN-1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "GOVERN 1.1 requires organizational policies for AI deployment decisions; MANAGE 2.2 covers evaluation procedures before deployment.", "uncovered_portion": "NIST AI RMF does not specify technical gate enforcement mechanisms or cryptographic signing of evaluation records.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 §9.1 requires planned evaluation procedures and documented results before AI system deployment.", "uncovered_portion": "ISO 42001 does not mandate cryptographic signing or tamper-evident storage of evaluation records.", "reviewed_on": "2026-06-26", "source_version": "2023" }, { "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" }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 §III.B requires validation before deployment and maintenance of validation documentation; the evaluation gate operationalizes this requirement.", "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" }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AISVS V1 covers governance requirements aligned with deployment gate concepts.", "uncovered_portion": "AISVS v1.0 does not mandate signed evaluation manifests or tamper-evident storage.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "llm10", "requirement_id": "LLM10:2025", "fit": "adjacent", "direction": "out-of-scope", "rationale": "OWASP LLM Top 10 2025 addresses runtime threat categories, not deployment gate processes.", "reviewed_on": "2026-06-26", "source_version": "2025" }, { "framework": "aicm", "requirement_id": "GRC-01", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AI Control Matrix general governance controls align with the requirement for documented deployment 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 }, { "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": "5.6.0" }, { "framework": "owasp_aitg", "requirement_id": "AITG-ME-01", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EV-01 establishes the baseline performance evaluation framework including benchmark selection, metric definition, and disaggregated accuracy assessment, directly implementing AITG-ME-01 Model Evaluation Testing which requires that a model's core performance characteristics be systematically measured and documented before deployment.", "source_locator": { "section": "Model Evaluation Testing", "test_id": "AITG-ME-01" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" } }, { "id": "EV-02", "cross_domain": { "references": [ { "relationship": "related", "uri": "apeiris://security/controls/AS-05", "name": "Study frontier offensive capability before public release", "note": "AS-05 studies frontier offensive capability before public release on the security side." } ], "evidence_artifacts": [] }, "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.1", "NIST AI RMF MEASURE 2.5", "ISO/IEC 42001:2023 §9.1", "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "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", "version": "2025", "published_on": "2025-05-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 }, { "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", "version": "2025", "published_on": "2024-11-17", "retrieved_on": "2026-06-26" } ], "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.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "MEASURE 2.1 requires AI risk measurement approaches; MEASURE 2.5 requires evaluation of AI system performance against intended purpose.", "uncovered_portion": "NIST AI RMF does not specify dimension isolation requirements or threshold pre-specification.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 §9.1 requires systematic evaluation of AI system performance against defined criteria.", "uncovered_portion": "ISO 42001 does not specify generative-AI-specific evaluation dimensions.", "reviewed_on": "2026-06-26", "source_version": "2023" }, { "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" }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 requires validation to assess conceptual soundness and outcome analysis; structured dimension evaluation operationalizes this.", "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" }, { "framework": "aisvs", "requirement_id": "C7.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AISVS V2 covers model evaluation requirements; V4 covers application-layer safety testing.", "uncovered_portion": "AISVS does not mandate pre-specified thresholds or dimension isolation.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "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" }, { "framework": "aicm", "requirement_id": "A&A-02", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AICM EV-1 aligns with structured model evaluation before deployment.", "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 }, { "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": "5.6.0" }, { "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." }, { "framework": "owasp_aitg", "requirement_id": "AITG-ME-02", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EV-02 conducts capability boundary testing to determine what the model can and cannot reliably do under realistic conditions, directly implementing AITG-ME-02 Model Evaluation Testing which requires that a model's functional capability envelope be formally characterized and documented to prevent deployment in contexts exceeding validated capability.", "source_locator": { "section": "Model Evaluation Testing", "test_id": "AITG-ME-02" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "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" } } ] }, { "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/ASL-4 thresholds", "OpenAI Preparedness Framework v2 — capability evaluation tracks", "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": "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", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2.0", "published_on": "2025-01-01", "retrieved_on": "2026-06-26" }, { "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", "version": "3.1", "published_on": "2026-04-17", "retrieved_on": "2026-06-26" }, { "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 } ], "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 levels, OpenAI Preparedness v2 tracks, 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": { "domains": [ "CBRN", "cyberweapons", "autonomous-AI-RD", "mass-influence" ], "threshold_frameworks": [ "Anthropic RSP v3.3 ASL levels", "OpenAI Preparedness v2 tracks", "Google DeepMind FSF v3.1 TCLs" ], "re_evaluation_trigger": "Any significant capability update, new elicitation methodology, or threshold framework revision.", "capability_level": "frontier" }, "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": "GOVERN-6.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN 6.1 addresses systemic risk policies; MANAGE 4.1 covers risk response. Neither addresses dangerous capability threshold assessment specifically.", "uncovered_portion": "NIST AI RMF 1.0 predates frontier dangerous capability assessment methodology; it does not provide threshold definitions.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "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" }, { "framework": "eu_ai_act", "requirement_id": "Art-51", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Art. 51 defines systemic risk classification for GPAI models; Art. 55 requires adversarial testing and incident reporting for systemic risk models.", "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" }, { "framework": "sr262", "requirement_id": "S-1.1", "fit": "adjacent", "direction": "out-of-scope", "rationale": "SR 26-2 model risk management guidance does not address frontier AI dangerous capability assessment.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2" }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "adjacent", "direction": "out-of-scope", "rationale": "AISVS v1.0 does not address dangerous capability threshold assessment for frontier models.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "llm10", "requirement_id": "LLM10:2025", "fit": "adjacent", "direction": "out-of-scope", "rationale": "OWASP LLM Top 10 2025 addresses application-layer risks, not frontier model dangerous capability assessment.", "reviewed_on": "2026-06-26", "source_version": "2025" }, { "framework": "aicm", "requirement_id": "A&A-02", "fit": "adjacent", "direction": "out-of-scope", "rationale": "AI Control Matrix does not currently include frontier dangerous capability assessment controls.", "reviewed_on": "2026-06-26", "source_version": "1.1", "mapping_confidence": "medium", "provisional": true }, { "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": "5.6.0" }, { "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." }, { "framework": "owasp_aitg", "requirement_id": "AITG-ME-03", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EV-03 performs safety and alignment evaluation including harmful output testing, instruction-following compliance, and value alignment probes, directly implementing AITG-ME-03 Model Evaluation Testing which requires that safety-relevant behaviors and alignment properties be explicitly tested and attested before a model is approved for deployment.", "source_locator": { "section": "Model Evaluation Testing", "test_id": "AITG-ME-03" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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 applies to general-purpose AI models (GPAI) with systemic risk — requires providers to perform adversarial testing and report serious incidents.", "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" } } ] }, { "id": "EV-04", "cross_domain": { "references": [ { "relationship": "related", "uri": "apeiris://security/controls/AS-01", "name": "Adversarially red-team and evaluate the agent before launch", "note": "AS-01 adversarially red-teams and evaluates the agent before launch on the security side." } ], "evidence_artifacts": [] }, "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.6", "ISO/IEC 42001:2023 §9.1", "OWASP AISVS v1.0 V5 — 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": "informative", "version": "5.6.0", "published_on": "2026-05-04" }, { "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", "version": "2025", "published_on": "2024-11-17", "retrieved_on": "2026-06-26" }, { "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", "version": "1.0", "published_on": "2026-06-26", "retrieved_on": "2026-06-26" }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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 } ], "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.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE 2.6 requires testing for adversarial conditions and misuse scenarios.", "uncovered_portion": "NIST AI RMF does not specify red-team team composition independence requirements.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 §9.1 covers evaluation procedures; adversarial testing extends this to adversarial scenarios.", "uncovered_portion": "ISO 42001 does not mandate adversarial red-teaming or specify threat model requirements.", "reviewed_on": "2026-06-26", "source_version": "2023" }, { "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" }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 model validation principles support independent adversarial testing as part of validation.", "uncovered_portion": "SR 26-2 does not address LLM-specific adversarial testing methodology.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2" }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AISVS V5 covers adversarial robustness verification requirements aligned with structured red-team exercises.", "uncovered_portion": "AISVS does not specify red-team team independence requirements or report signing.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "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" }, { "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 }, { "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 ML 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": "5.6.0" }, { "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." }, { "framework": "owasp_aitg", "requirement_id": "AITG-ME-04", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EV-04 conducts adversarial robustness evaluation including red-team attacks, jailbreak probing, prompt injection resistance testing, and backdoor detection, directly implementing AITG-ME-04 Model Evaluation Testing which requires that a model's resilience to adversarial inputs and manipulation attempts be systematically assessed before release.", "source_locator": { "section": "Model Evaluation Testing", "test_id": "AITG-ME-04" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "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" } } ] }, { "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.5", "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 }, { "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", "version": "2025", "published_on": "2025-05-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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "1.0", "published_on": "2024-07-26" } ], "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.5", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF MEASURE 2.5 requires identification and measurement of AI bias and fairness dimensions.", "uncovered_portion": "NIST AI RMF does not mandate pre-specification of fairness thresholds or legal review for protected characteristic decisions.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "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" }, { "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" }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 outcome analysis requirements for financial models align with fairness evaluation for credit and lending applications.", "uncovered_portion": "SR 26-2 predates comprehensive fairness evaluation methodology for AI systems.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2" }, { "framework": "aisvs", "requirement_id": "C7.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AISVS V6 covers fairness and non-discrimination verification requirements.", "uncovered_portion": "AISVS does not mandate legal review for protected characteristic decisions.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "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" }, { "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 }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "direction": "out-of-scope", "rationale": "MITRE ATLAS v5.6.0 does not address fairness and bias evaluation methodology.", "reviewed_on": "2026-06-26", "source_version": "5.6.0" }, { "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." }, { "framework": "owasp_aitg", "requirement_id": "AITG-ME-05", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EV-05 performs fairness and bias evaluation by measuring disaggregated error rates across protected attribute subgroups and intersectional populations, directly implementing AITG-ME-05 Model Evaluation Testing which requires that differential performance across demographic groups be measured and documented as a prerequisite for deployment in contexts affecting people.", "source_locator": { "section": "Model Evaluation Testing", "test_id": "AITG-ME-05" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "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" } } ] }, { "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 — Evaluation methodology documentation", "ISO/IEC 42001:2023 §9.1", "NIST AI 600-1 — Generative AI Profile §2.5 (benchmark integrity)" ], "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "flagship": true }, { "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", "version": "1.0", "published_on": "2024-07-26" }, { "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", "version": "1.0", "published_on": "2026-06-26", "retrieved_on": "2026-06-26" } ], "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 requires documented AI risk measurement approaches sufficient to assess reliability; reproducible design is a prerequisite.", "uncovered_portion": "NIST AI RMF does not specify contamination screening or artifact signing requirements.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 §9.1 requires evaluation to be documented with sufficient detail to demonstrate planned results were achieved.", "uncovered_portion": "ISO 42001 does not mandate contamination screening or independent reproduction testing.", "reviewed_on": "2026-06-26", "source_version": "2023" }, { "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" }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 requires validation to be sufficiently documented to allow independent review; reproducibility documentation supports this.", "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" }, { "framework": "aisvs", "requirement_id": "C7.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AISVS V2 includes evaluation integrity requirements aligned with reproducible design.", "uncovered_portion": "AISVS does not mandate independent reproduction testing or contamination screening methodology.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "llm10", "requirement_id": "LLM10:2025", "fit": "adjacent", "direction": "out-of-scope", "rationale": "OWASP LLM Top 10 2025 does not address evaluation reproducibility or benchmark contamination.", "reviewed_on": "2026-06-26", "source_version": "2025" }, { "framework": "aicm", "requirement_id": "MDS-05", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AICM evaluation integrity controls align with reproducible design requirements.", "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 }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "direction": "out-of-scope", "rationale": "MITRE ATLAS v5.6.0 does not address evaluation reproducibility or benchmark integrity.", "reviewed_on": "2026-06-26", "source_version": "5.6.0" }, { "framework": "owasp_aitg", "requirement_id": "AITG-ME-06", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EV-06 evaluates calibration and uncertainty quantification — verifying that the model's confidence scores are statistically reliable and that it can communicate uncertainty appropriately — directly implementing AITG-ME-06 Model Evaluation Testing which requires that a model's uncertainty estimation capabilities be assessed and validated before deployment in decision-support contexts.", "source_locator": { "section": "Model Evaluation Testing", "test_id": "AITG-ME-06" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "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" } } ] }, { "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 — Change management and re-evaluation", "ISO/IEC 42001:2023 §10.1 — Nonconformity and corrective action", "EU AI Act Art. 9(4) — Iterative risk management", "SR 26-2 §III.C — 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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "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 }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26" }, { "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", "version": "2025", "published_on": "2024-11-17", "retrieved_on": "2026-06-26" } ], "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 requires re-evaluation when AI systems undergo changes that may affect risk.", "uncovered_portion": "NIST AI RMF does not specify zero-tolerance thresholds for safety regression or monitoring schema structure.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "iso_42001", "requirement_id": "10.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 §10.1 requires identification and correction of nonconformities; regression findings are a structured nonconformity detection mechanism.", "uncovered_portion": "ISO 42001 does not specify regression suite structure or safety regression zero-tolerance policy.", "reviewed_on": "2026-06-26", "source_version": "2023" }, { "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" }, { "framework": "sr262", "requirement_id": "S-4.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 §III.C requires ongoing monitoring of model performance; regression testing before each update is the pre-deployment component of this requirement.", "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" }, { "framework": "aisvs", "requirement_id": "C7.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AISVS V2 and V3 cover model evaluation and operational validation requirements aligned with regression testing.", "uncovered_portion": "AISVS does not specify zero-tolerance safety regression policy or monitoring schema structure.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "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" }, { "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 }, { "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": "5.6.0" }, { "framework": "owasp_aitg", "requirement_id": "AITG-ME-07", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EV-07 assesses the model's privacy risk properties including susceptibility to membership inference attacks, training data extraction, and personally identifiable information leakage, directly implementing AITG-ME-07 Model Evaluation Testing which requires that privacy-relevant attack surfaces in the model be evaluated and documented before deployment.", "source_locator": { "section": "Model Evaluation Testing", "test_id": "AITG-ME-07" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "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" } } ] }, { "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 §III.B — Independent model validation 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 1.7 — Separation of roles" ], "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: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26" }, { "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 }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" } ], "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-1.7", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN 1.7 requires separation of roles for AI risk management; independent validation operationalizes this for the evaluation function.", "uncovered_portion": "NIST AI RMF does not specify the organizational structure required for effective independence.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "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" }, { "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" }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 §III.B is the primary source for this control: it requires organizational independence, technical competence, and authority to provide effective challenge.", "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" }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AISVS V1 governance requirements align with separation of development and validation functions.", "uncovered_portion": "AISVS does not specify organizational independence requirements equivalent to SR 26-2 effective challenge.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "llm10", "requirement_id": "LLM10:2025", "fit": "adjacent", "direction": "out-of-scope", "rationale": "OWASP LLM Top 10 2025 does not address validation independence or organizational separation of duties.", "reviewed_on": "2026-06-26", "source_version": "2025" }, { "framework": "aicm", "requirement_id": "MDS-03", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AICM separation of duties controls align with independent validation requirements.", "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 }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "direction": "out-of-scope", "rationale": "MITRE ATLAS v5.6.0 does not address organizational separation of duties for model validation.", "reviewed_on": "2026-06-26", "source_version": "5.6.0" }, { "framework": "owasp_aitg", "requirement_id": "AITG-ME-08", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EV-08 evaluates the model's behavior under distribution shift and out-of-distribution inputs — testing reliability when inputs differ from the training distribution — directly implementing AITG-ME-08 Model Evaluation Testing which requires that model robustness under input distribution shift be characterized before deployment in production environments with diverse real-world inputs.", "source_locator": { "section": "Model Evaluation Testing", "test_id": "AITG-ME-08" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" } }, { "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 §II — Model risk tiering", "ISO/IEC 42001:2023 §6.1 — Risk assessment", "ISO/IEC 42005:2025 — AI system impact assessment", "NIST AI RMF GOVERN 1.2 — Risk tolerance and classification" ], "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 }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "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", "version": "2025", "published_on": "2025-05-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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" } ], "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 (AI Asset Inventory) 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": "GOVERN-1.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN 1.2 requires organizations to establish and communicate AI risk tolerance; risk classification operationalizes this for model systems.", "uncovered_portion": "NIST AI RMF does not provide a classification schema aligned with EU AI Act or SR 26-2 tier definitions.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "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" }, { "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" }, { "framework": "sr262", "requirement_id": "S-1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 §II requires financial institutions to implement model risk tiering; this control produces and maintains the required tier assignment and documentation.", "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" }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AISVS V1 governance requirements include risk classification as a prerequisite for defining applicable verification requirements.", "uncovered_portion": "AISVS does not specify a multi-framework classification schema.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "llm10", "requirement_id": "LLM10:2025", "fit": "adjacent", "direction": "out-of-scope", "rationale": "OWASP LLM Top 10 2025 does not address risk classification or regulatory categorization.", "reviewed_on": "2026-06-26", "source_version": "2025" }, { "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 }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "direction": "out-of-scope", "rationale": "MITRE ATLAS v5.6.0 does not address risk classification or regulatory categorization.", "reviewed_on": "2026-06-26", "source_version": "5.6.0" }, { "framework": "owasp_aitg", "requirement_id": "AITG-ME-09", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EV-09 performs use-case-specific impact assessment evaluating the model's suitability, risk profile, and potential harms in the specific deployment context, directly implementing AITG-ME-09 Model Evaluation Testing which requires that evaluation scope be tailored to the intended deployment use case and that context-specific risk factors be explicitly assessed.", "source_locator": { "section": "Model Evaluation Testing", "test_id": "AITG-ME-09" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" } }, { "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 §III.B — Model validation documentation", "ISO/IEC 42001:2023 §7.5 — Documented information", "NIST AI RMF GOVERN 1.6 — Accountability and traceability" ], "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 }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" } ], "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": "GOVERN-1.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN 1.6 requires accountability and traceability for AI risk management decisions; content-addressed, signed evaluation records operationalize this.", "uncovered_portion": "NIST AI RMF does not specify tamper-evident log requirements or provenance chain traversal tooling.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "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" }, { "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" }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 §III.B requires validation documentation to be sufficient for independent review and regulatory examination; content-addressed, signed records satisfy this requirement.", "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" }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AISVS V1 and V2 include documentation and traceability requirements aligned with evaluation result provenance.", "uncovered_portion": "AISVS does not specify content-addressing, tamper-evident logs, or provenance chain traversal tooling.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "llm10", "requirement_id": "LLM10:2025", "fit": "adjacent", "direction": "out-of-scope", "rationale": "OWASP LLM Top 10 2025 does not address evaluation result provenance or tamper-evident record-keeping.", "reviewed_on": "2026-06-26", "source_version": "2025" }, { "framework": "aicm", "requirement_id": "A&A-04", "fit": "partial", "direction": "control-supports-requirement", "rationale": "AICM evaluation records controls align with content-addressed, signed evaluation result provenance requirements.", "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 }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "direction": "out-of-scope", "rationale": "MITRE ATLAS v5.6.0 does not address evaluation result provenance or record-keeping integrity.", "reviewed_on": "2026-06-26", "source_version": "5.6.0" }, { "framework": "owasp_aitg", "requirement_id": "AITG-IR-05", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EV-10 ensures that all evaluation evidence — including benchmark results, red-team findings, and evaluation attestations — is integrity-protected and retained as a tamper-evident record, partially aligning with AITG-IR-05 Incident Response Testing which validates audit trail and evidence integrity. The pre-release evidence integrity focus is prospective assurance rather than the retrospective audit-trail preservation the test defines.", "source_locator": { "section": "Incident Response Testing", "test_id": "AITG-IR-05" }, "uncovered_portion": "AITG-IR-05 focuses on audit trail and evidence integrity verification for post-incident investigation; evaluation evidence integrity as a gate-keeping mechanism before model release addresses the prospective assurance chain rather than the retrospective audit-trail preservation that IR-05 defines.", "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "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" } } ] }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "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 }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC / FDIC", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26" } ], "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-1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN function requires documented roles and responsibilities for AI risk management.", "uncovered_portion": "Does not address organizational culture or incentive alignment.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "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" }, { "framework": "eu_ai_act", "requirement_id": "Art-16", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Art-16 requires high-risk AI providers to establish quality management with defined responsibilities.", "uncovered_portion": "Conformity assessment obligations covered in OA-05.", "reviewed_on": "2026-06-26", "source_version": "2024/1689" }, { "framework": "sr262", "requirement_id": "S-1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 requires model owners to be documented and accountable for model outcomes.", "uncovered_portion": "Validation independence requirements covered in EV layer.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2" }, { "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-GV-03", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "AITG-GV-03 verifies that AI system accountability is assigned and documented; OA-01 implements the accountable ownership assignment that AITG-GV-03 checks — AITG verifies the governance artifact, OA-01 produces it.", "source_locator": { "section": "Governance Testing", "test_id": "AITG-GV-03" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "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-16", "mapping_fit": "partial", "notes": "Art-16 lists obligations of providers of high-risk AI systems, including establishing quality management systems and maintaining technical documentation.", "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" } } ] }, { "id": "OA-02", "cross_domain": { "references": [ { "relationship": "related", "uri": "apeiris://security/controls/GV-01", "name": "Require a human hard-stop for irreversible actions", "note": "GV-01 requires a human hard-stop for irreversible actions on the security side." } ], "evidence_artifacts": [] }, "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 }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" } ], "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": { "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" ], "capability_level": "none" }, "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" }, { "framework": "nist_rmf", "requirement_id": "GOVERN-1.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN function covers accountability; MEASURE covers monitoring of oversight effectiveness.", "uncovered_portion": "None significant.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "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" }, { "framework": "sr262", "requirement_id": "S-1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 requires human review of model outputs in credit and risk decision contexts.", "uncovered_portion": "None significant.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2" }, { "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-GV-03", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "OA-02 establishes a structured human oversight adequacy assessment using five documented factors — oversight frequency, reviewer competence, decision reversibility, impact scope, and technical override capability — providing the governance evidence foundation that supports AITG-GV-03 Governance Testing by enabling testers to verify that meaningful human oversight exists and that oversight levels are appropriate to the model's capability tier and deployment risk profile.", "source_locator": { "section": "Governance Testing", "test_id": "AITG-GV-03" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "assurance_target": { "oversight_design": "five-factor-verified", "override_mechanism": "technically-effective", "reviewer_competence": "documented-and-certified" }, "canonical_id": "apeiris://model/controls/OA-02" }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "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 }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC / FDIC", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26" } ], "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-1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN function requires organizational accountability structures for AI risk.", "uncovered_portion": "None significant.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "iso_42001", "requirement_id": "5.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 requires top management to establish AI governance structures with defined roles and authorities.", "uncovered_portion": "None significant.", "reviewed_on": "2026-06-26", "source_version": "2023" }, { "framework": "sr262", "requirement_id": "S-1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 requires senior management governance structure for model risk management.", "uncovered_portion": "SR 26-2 validation independence requirements addressed in EV layer.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2" }, { "framework": "eu_ai_act", "requirement_id": "Art-9", "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" }, { "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-GV-05", "fit": "direct", "direction": "control-supports-requirement", "rationale": "OA-03 establishes the governance decision-making structure for AI systems including approval authorities, policy ownership, and cross-functional governance bodies, directly implementing AITG-GV-05 Governance Testing which requires that AI governance decision authority be formally established and that the governance structure be verifiable through documented policies and roles.", "source_locator": { "section": "Governance Testing", "test_id": "AITG-GV-05" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "canonical_id": "apeiris://model/controls/OA-03", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "low", "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" } } ] }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "flagship": true } ], "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": { "references": [ { "relationship": "related", "uri": "apeiris://security/controls/GV-05", "name": "Run an AI management system and tier agents by their autonomy", "note": "GV-05 runs an AI management system and tiers agents by their autonomy on the security side." } ], "evidence_artifacts": [], "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" }, "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.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF requires risk tier classification and calibrated management responses.", "uncovered_portion": "Technical enforcement controls addressed in Security Verifier domain.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "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" }, { "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-GV-07", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "AITG-GV-07 reviews autonomy and agency control governance documentation; OA-04 implements the autonomy tier classification that AITG-GV-07 checks, making this a supporting relationship.", "source_locator": { "section": "Governance Testing", "test_id": "AITG-GV-07" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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": "low", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" } }, { "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 for high-risk systems carries fines up to EUR 30 million or 6% of global annual turnover. 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 }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC / FDIC", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" } ], "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-9", "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" }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 requires model validation documentation to be reviewed by model risk function before deployment.", "uncovered_portion": "Ongoing monitoring and annual validation requirements addressed in CR layer.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2" }, { "framework": "iso_42001", "requirement_id": "8.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 requires legal and regulatory requirements to be identified and addressed in the AI management system.", "uncovered_portion": "None significant.", "reviewed_on": "2026-06-26", "source_version": "2023" }, { "framework": "nist_rmf", "requirement_id": "GOVERN-1.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF GOVERN function requires understanding of legal and regulatory context for AI deployment.", "uncovered_portion": "None significant.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "aicm", "requirement_id": "GRC-03", "fit": "direct", "direction": "control-supports-requirement", "rationale": "OA-05 requires compliance counsel to review and sign off on all regulated-use AI model deployments before production promotion, documenting applicable regulations, compliance posture, and residual legal risks — functions that directly implement CL-01's requirement for regulatory applicability review and legal sign-off before AI deployment. For EU high-risk AI systems, the control additionally requires a completed conformity assessment and EU Declaration of Conformity, satisfying the formal pre-market authorization element of CL-01 for the most regulated AI contexts.", "source_locator": { "section": "Compliance and Legal Obligations" }, "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-GV-04", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OA-05 defines and enforces a deployed model use policy specifying permitted and prohibited use patterns, user obligations, and deployment constraints, partially aligning with AITG-GV-04 Governance Testing which defines use-case risk classification and policy requirements. The deployed use policy is a downstream governance artifact that extends beyond the risk classification and tier assignment that the test validates.", "source_locator": { "section": "Governance Testing", "test_id": "AITG-GV-04" }, "uncovered_portion": "AITG-GV-04 defines use-case risk classification and policy requirements; a deployed model use policy that specifies permitted and prohibited use patterns is a downstream governance artifact that goes beyond the classification and risk-tier assignment the test validates.", "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "canonical_id": "apeiris://model/controls/OA-05", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "low", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" } }, { "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", "version": "2025", "published_on": "2024-11-17", "retrieved_on": "2026-06-26" }, { "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": "informative", "version": "5.6.0", "published_on": "2026-05-04" }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC / FDIC", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26", "flagship": true } ], "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": "LLM10:2025", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OWASP LLM03:2025 Supply Chain addresses third-party model risk through dependency management and vendor governance.", "uncovered_portion": "Technical supply chain artifact verification addressed in TG layer.", "reviewed_on": "2026-06-26", "source_version": "2025" }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "partial", "direction": "control-mitigates-risk", "rationale": "AML.T0018 Supply Chain Compromise is mitigated by vendor due diligence, version pinning, and behavioral monitoring.", "uncovered_portion": "Technical artifact integrity checks addressed in TG layer.", "reviewed_on": "2026-06-26", "source_version": "5.6.0" }, { "framework": "sr262", "requirement_id": "S-4.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 requires vendor model oversight including validation documentation requirements.", "uncovered_portion": "None significant.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2" }, { "framework": "nist_rmf", "requirement_id": "GOVERN-1.5", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF addresses third-party risk as part of AI supply chain risk management.", "uncovered_portion": "None significant.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "iso_42001", "requirement_id": "8.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OA-06 implements operational planning and control for third-party AI model procurement — requiring risk-based due diligence before first use, contract terms covering model change notification and audit rights, annual vendor risk review, and substitutability planning — directly supporting ISO 42001 Clause 8.1's requirement that operational processes including the use of externally-provided AI components be planned, implemented, controlled, and reviewed. Annex B's AI system supply chain considerations are additionally addressed because OA-06's vendor governance framework governs the intake, monitoring, and exit of third-party AI components throughout their operational lifecycle.", "uncovered_portion": "Clause 8.1 addresses operational planning and control across all AI system lifecycle phases and components; OA-06 covers only the third-party vendor and model risk oversight dimension and does not address operational controls for internally-developed AI systems covered by other OA layer controls and the BH layer.", "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" }, { "framework": "aicm", "requirement_id": "STA-09", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OA-06 applies systematic vendor governance to all third-party AI models and components — requiring risk-based due diligence before first use, contract terms mandating model change notification and audit rights, annual vendor risk reviews, and a documented substitution plan for critical vendors. This directly implements SUP-02's third-party AI model and vendor risk management program requirement by covering the full vendor lifecycle from intake due diligence through ongoing performance monitoring and exit planning.", "source_locator": { "section": "Supply Chain and Third-Party" }, "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": "STA-09 additionally requires BOM documentation for cloud infrastructure, software dependencies, and third-party service components beyond AI model and dataset provenance." }, { "framework": "owasp_aitg", "requirement_id": "AITG-IR-01", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OA-06 assigns authority for incident response decisions — designating who can declare an AI incident, authorize emergency interventions, and approve remediation actions — partially aligning with AITG-IR-01 Incident Response Testing which covers incident detection, investigation, and corrective action procedures. Authority assignment is a governance precondition that the test does not directly assess.", "source_locator": { "section": "Incident Response Testing", "test_id": "AITG-IR-01" }, "uncovered_portion": "AITG-IR-01 covers incident detection, investigation, and corrective action procedures; authority assignment for incident response decisions is a governance precondition that the test does not directly assess.", "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "canonical_id": "apeiris://model/controls/OA-06", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "low", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" } }, { "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 within 15 days)." ], "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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 }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" } ], "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 market surveillance authority within 15 days." }, { "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 RESPOND function requires defined incident response roles and decision authorities.", "uncovered_portion": "Technical incident response procedures addressed in CR layer.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "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 15-day window.", "uncovered_portion": "Post-incident corrective action requirements addressed in CR layer.", "reviewed_on": "2026-06-26", "source_version": "2024/1689" }, { "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" }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 requires escalation procedures for model risk incidents to senior management.", "uncovered_portion": "None significant.", "reviewed_on": "2026-06-26", "source_version": "SR 26-2" }, { "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-GV-05", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OA-07 defines escalation paths and cross-functional authority resolution mechanisms for AI governance decisions that span multiple teams or organizational boundaries, partially aligning with AITG-GV-05 Governance Testing which validates the existence and structure of AI governance decision authority. Escalation path definitions and cross-functional resolution mechanisms extend into organizational process territory beyond what the governance structure test checks.", "source_locator": { "section": "Governance Testing", "test_id": "AITG-GV-05" }, "uncovered_portion": "AITG-GV-05 validates the existence and structure of AI governance decision authority; escalation path definitions and cross-functional authority resolution mechanisms extend into organizational process territory beyond what the governance structure test checks.", "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "canonical_id": "apeiris://model/controls/OA-07", "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "bounded", "external_reach": "internal", "irreversibility": "low", "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" } } ] }, { "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 }, { "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" }, { "id": "owasp_aisvs_v1", "authority": "OWASP", "title": "OWASP AI Security Verification Standard v1.0", "source_type": "certification-standard", "url": "https://github.com/OWASP/AISVS", "license": "CC BY-SA 4.0", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "unverified": true, "status": "current", "retrieved_on": "2026-06-26", "normative_force": "voluntary", "version": "1.0" }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2025", "published_on": "2024-11-17", "retrieved_on": "2026-06-26" } ], "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": { "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" ], "capability_level": "none" }, "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" }, { "framework": "nist_rmf", "requirement_id": "GOVERN-1.7", "fit": "partial", "direction": "control-supports-requirement", "rationale": "NIST AI RMF addresses transparency and explainability as core trustworthy AI characteristics.", "uncovered_portion": "None significant.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "OWASP AISVS transparency and explainability verification standards address explanation mechanism accuracy validation.", "uncovered_portion": "None significant.", "reviewed_on": "2026-06-26", "source_version": "1.0" }, { "framework": "iso_42001", "requirement_id": "8.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO 42001 requires AI systems to be transparent to affected stakeholders.", "uncovered_portion": "None significant.", "reviewed_on": "2026-06-26", "source_version": "2023" }, { "framework": "llm10", "requirement_id": "LLM10:2025", "fit": "partial", "direction": "control-mitigates-risk", "rationale": "OWASP LLM09:2025 Misinformation is mitigated by AI provenance notice and explanation accuracy requirements.", "uncovered_portion": "Factual accuracy of model outputs is a separate concern addressed in EV layer.", "reviewed_on": "2026-06-26", "source_version": "2025" }, { "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 TE-01's requirements 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 TE-01 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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-GV-06", "fit": "direct", "direction": "control-supports-requirement", "rationale": "OA-08 implements audit logging and accountability trail requirements for all AI-driven decisions and human interventions, ensuring that a complete, tamper-evident record of model actions and oversight events is maintained — directly implementing AITG-GV-06 Governance Testing which requires that accountability audit trails for AI decisions be maintained and verifiable.", "source_locator": { "section": "Governance Testing", "test_id": "AITG-GV-06" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" } ], "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" }, { "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": "GOVERN 1.7, MANAGE 2.4" }, { "id": "iso_42001", "ref": "Clause 9.1" }, { "id": "eu_ai_act", "ref": "Art. 9(7), Art. 72" }, { "id": "aisvs", "ref": "V8.1" } ], "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "flagship": true }, { "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": "informative", "published_on": "2026-05-04", "retrieved_on": "2026-06-26" }, { "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", "version": "1.0", "published_on": "2026-06-26", "retrieved_on": "2026-06-26" } ], "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": "low", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-01 continuously samples model output distributions and applies statistical process control — computing PSI against a signed 30-day post-deployment baseline and firing tiered alerts when outputs shift beyond thresholds — directly operationalizing the production monitoring obligation of NIST AI RMF MEASURE 2.3. MANAGE 2.4 is additionally relevant because BH-01's alert routing SLAs (15 minutes for critical anomalies) define the response pathway when monitored outputs indicate elevated risk.", "uncovered_portion": "MEASURE 2.3 encompasses the full spectrum of operational AI monitoring including fairness metrics, input distribution, and societal impact dimensions; BH-01 addresses only statistical output distribution monitoring and does not cover input drift (BH-02), performance regression (BH-03), or behavioral boundary adherence (BH-04).", "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" }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-01 implements systematic monitoring and measurement of model output distributions using PSI metrics and control charts, with documented alert thresholds reviewed quarterly by the model owner — fulfilling the core obligations of ISO 42001 Clause 9.1 for monitoring, measurement, analysis, and evaluation of AI system performance. The versioned, signed baseline artifact provides the documented reference point that Clause 9.1 requires for evaluating whether AI system performance remains acceptable.", "uncovered_portion": "Clause 9.1 spans the full monitoring scope including evaluation of management system effectiveness and AI system performance across all risk dimensions; BH-01 addresses only statistical output distribution monitoring and does not cover the management system evaluation or other performance dimensions required by Clause 9.1's full scope.", "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" }, { "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-RT-01", "fit": "direct", "direction": "control-supports-requirement", "rationale": "BH-01 continuously monitors model output distributions using statistical process control — computing PSI against a signed 30-day post-deployment baseline and firing tiered alerts when output distributions shift beyond defined thresholds — directly implementing AITG-RT-01 Runtime Testing which requires that deployed model outputs be monitored in production to detect distributional anomalies and behavioral shifts as they occur.", "source_locator": { "section": "Runtime Testing", "test_id": "AITG-RT-01" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 §III.C requires 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 issues in production.", "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" } ], "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" } } ] }, { "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": "MANAGE 2.4, MANAGE 4.1" }, { "id": "iso_42001", "ref": "Clause 9.1, Clause 10.1" }, { "id": "eu_ai_act", "ref": "Art. 9(7), Art. 72" }, { "id": "sr262", "ref": "Section IV.C — 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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26", "flagship": true }, { "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": "informative", "published_on": "2026-05-04", "retrieved_on": "2026-06-26" } ], "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": "low", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-02 computes PSI and KS-test statistics on production input features against a versioned DriftReference artifact and fires profile-conditional alerts when distribution shift exceeds defined thresholds, directly addressing the input-monitoring dimension of NIST AI RMF MEASURE 2.3's production monitoring requirement. MANAGE 2.4 is additionally relevant because BH-02's alerts for PSI above 0.2 trigger model review workflows constituting a structured risk response to identified distributional changes.", "uncovered_portion": "MEASURE 2.3 spans the full AI system monitoring scope including output behavior, safety, and fairness monitoring; BH-02 covers only input feature and prediction distribution drift and does not address concept drift requiring labeled ground truth, which is addressed by the EV layer periodic re-validation in CR-03.", "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" }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-02 establishes systematic production monitoring of input and prediction distributions using PSI metrics with minimum sample size guards and profile-conditional thresholds, providing the measurement foundation that ISO 42001 Clause 9.1 requires for ongoing evaluation of AI system performance. The versioned DriftReference artifact and monthly drift summary reports reviewed by the model owner fulfill Clause 9.1's requirements for documented evidence of monitoring results and management review inputs.", "uncovered_portion": "Clause 9.1 and Annex B require a comprehensive monitoring and risk assessment view; BH-02 covers input and prediction distribution drift as one risk dimension and does not address the management system effectiveness evaluation or other performance dimensions encompassed by Clause 9.1's full scope.", "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" }, { "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." }, { "framework": "owasp_aitg", "requirement_id": "AITG-RT-02", "fit": "direct", "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 AITG-RT-02 Runtime Testing which requires that production input distributions be monitored to detect when inputs diverge materially from the training distribution.", "source_locator": { "section": "Runtime Testing", "test_id": "AITG-RT-02" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 §III.C requires ongoing monitoring to detect performance deterioration and distributional changes in model inputs; BH-02 directly implements this by computing PSI statistics against a versioned DriftReference artifact and routing alerts when thresholds are exceeded.", "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" } ], "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" } } ] }, { "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": "MANAGE 2.4, MANAGE 4.2" }, { "id": "iso_42001", "ref": "Clause 9.1" }, { "id": "eu_ai_act", "ref": "Art. 9(7), Art. 72" }, { "id": "sr262", "ref": "Section IV.C — Performance Benchmarking" } ], "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26" }, { "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 } ], "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": "low", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-03 compares live production performance metrics against a signed EvaluationBaseline artifact and fires tiered alerts when primary metrics regress beyond accepted tolerances — directly implementing the performance-against-baseline monitoring component of NIST AI RMF MEASURE 2.3. MANAGE 2.2 is additionally relevant because BH-03's sev1 escalation triggers the risk response pathway defined in the incident response runbook, operationalizing the MANAGE function's response to detected performance degradation.", "uncovered_portion": "MEASURE 2.3 encompasses the full monitoring scope including fairness, safety, and input distribution monitoring; BH-03 covers only performance metric regression monitoring anchored to the EV-layer baseline and does not address other monitoring dimensions covered by BH-01, BH-02, and BH-04.", "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" }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-03 implements documented performance thresholds expressed as percentage regression from a signed EvaluationBaseline, with tiered alert levels and routing SLAs that ensure performance monitoring evidence is systematically generated and acted upon — fulfilling the measurement, analysis, and evaluation obligations of ISO 42001 Clause 9.1. Clause 10.1 on nonconformity and corrective action is additionally implicated because crossing the critical threshold automatically initiates the corrective action workflow via CR-04 incident response.", "uncovered_portion": "Clause 9.1 spans the full performance monitoring and management system evaluation scope; BH-03 addresses only production metric regression against the release baseline and does not cover other monitoring dimensions or management system effectiveness evaluation.", "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" }, { "framework": "aicm", "requirement_id": "LOG-03", "fit": "direct", "direction": "control-supports-requirement", "rationale": "BH-03 anchors all production performance metrics to a signed EvaluationBaseline artifact established at each release, fires tiered alerts when primary metrics regress beyond accepted tolerances, and provides separate tracking for subgroup regression — directly implementing MON-03's performance monitoring and threshold alerting against deployment baseline requirement. The three-tier alert escalation (warning, critical, sev1) and automatic incident commander notification ensure that performance degradation signals reach decision-makers with enough time to intervene before user harm accumulates.", "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-RT-03", "fit": "direct", "direction": "control-supports-requirement", "rationale": "BH-03 anchors all production performance metrics against a signed EvaluationBaseline artifact established at release, firing tiered alerts when primary metrics regress beyond accepted tolerances and escalating to sev1 when thresholds indicating active user harm are crossed — directly implementing AITG-RT-03 Runtime Testing which requires that production model performance be continuously compared against a validated baseline to detect regression before degradation reaches users at scale.", "source_locator": { "section": "Runtime Testing", "test_id": "AITG-RT-03" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 §III.C requires banking organizations to monitor model performance on an ongoing basis and conduct periodic back-testing; BH-03's automated performance alerts provide the continuous monitoring layer that supports SR 26-2's ongoing performance tracking requirements.", "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" } ], "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" } } ] }, { "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": "MANAGE 1.3, MANAGE 4.1" }, { "id": "iso_42001", "ref": "Clause 6.1, Clause 9.1" }, { "id": "eu_ai_act", "ref": "Art. 9(1)(b), Art. 15" }, { "id": "aisvs", "ref": "V5.2" } ], "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "flagship": true }, { "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": "informative", "published_on": "2026-05-04", "retrieved_on": "2026-06-26" }, { "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", "version": "1.0", "published_on": "2026-06-26", "retrieved_on": "2026-06-26" } ], "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": { "references": [ { "relationship": "related", "uri": "apeiris://security/controls/AS-07", "name": "Verify a skill does what it declares (behavioral integrity)", "note": "AS-07 verifies a skill does what it declares (behavioral integrity) on the security side." } ], "evidence_artifacts": [], "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 V5.2 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": "low", "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." }, { "framework": "nist_rmf", "requirement_id": "MEASURE-2.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-04 operates a continuous BoundaryTestSuite against production inference endpoints, computing BoundaryAdherenceRate per category and trending results over 30 days — directly operationalizing the robustness and trustworthiness evaluation requirements of NIST AI RMF MEASURE 2.6 for the operational deployment phase. MANAGE 2.4 is additionally relevant because BH-04's critical alerts trigger cross-domain notification to securitycontrols.ai, linking measurement to risk response.", "uncovered_portion": "MEASURE 2.6 encompasses robustness evaluation across the full AI lifecycle including pre-deployment testing; BH-04 covers only the production-time adherence measurement component and explicitly excludes enforcement, which is delegated to securitycontrols.ai, and pre-release adversarial evaluation covered by EV-06 and EV-07.", "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" }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-04 implements scheduled behavioral boundary testing in production using a versioned BoundaryTestSuite with defined BoundaryAdherenceRate thresholds reviewed quarterly — providing systematic measurement evidence for ISO 42001 Clause 9.1's monitoring and measurement obligations. Clause 6.1 on addressing risks and opportunities is additionally relevant because behavioral boundary testing directly operationalizes the risk treatment selected during the risk assessment phase to maintain intended-use constraints in production.", "uncovered_portion": "Clauses 9.1 and 6.1 address performance monitoring and risk management across the full AI system scope; BH-04 covers only behavioral boundary adherence measurement and does not address other monitoring dimensions, fairness metrics, or management system effectiveness evaluation.", "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" }, { "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-RT-04", "fit": "direct", "direction": "control-supports-requirement", "rationale": "BH-04 runs a continuous BoundaryTestSuite against production inference endpoints, computing BoundaryAdherenceRate per boundary category and firing critical alerts when adherence drops below 90% — directly implementing AITG-RT-04 Runtime Testing which requires that behavioral boundary constraints be tested and verified in the production environment to ensure model policies remain intact after deployment.", "source_locator": { "section": "Runtime Testing", "test_id": "AITG-RT-04" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" } ], "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" } } ] }, { "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, Clause 9.1" }, { "id": "eu_ai_act", "ref": "Art. 12, Art. 26(5), Annex III" }, { "id": "sr262", "ref": "Section IV.D — Documentation and Records" }, { "id": "aicm", "ref": "AICM-LOG-01" } ], "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26" }, { "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 }, { "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": "informative", "published_on": "2026-05-04", "retrieved_on": "2026-06-26" } ], "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": "low", "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": "BH-05 creates a tamper-evident DecisionLog for every model inference — capturing caller identity, masked inputs, sampled outputs, latency, and decision outcomes — providing the accountability record foundation that NIST AI RMF GOVERN 1.2 requires for demonstrating that AI systems operate within established policies. MANAGE 4.1 is additionally relevant because DecisionLogs are the primary source of evidence for incident attribution, root-cause analysis, and corrective action verification.", "uncovered_portion": "GOVERN 1.2 addresses the full accountability and transparency policy lifecycle including governance structures, stakeholder communication, and external transparency obligations; BH-05 covers only inference-level audit trail creation and does not address governance policy documentation, accountability structures, or external reporting obligations.", "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" }, { "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" }, { "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-RT-05", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "BH-05 creates a tamper-evident, structured audit trail of every model inference — capturing caller identity, masked inputs, sampled outputs, latency, and decision outcomes — supporting AITG-RT-05 Runtime Testing by providing the telemetry foundation that enables detection, attribution, and documentation of runtime behavioral anomalies and safety violations as they occur.", "source_locator": { "section": "Runtime Testing", "test_id": "AITG-RT-05" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" } }, { "framework": "sr262", "requirement_id": "S-4.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 §IV.D requires banking organizations to maintain model documentation and records sufficient to support ongoing monitoring, audit, and supervisory examination; BH-05's structured decision audit trail — with content-addressed log entries, WORM storage, and a read-only retrieval API — supports these record-keeping requirements.", "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" } ] }, { "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": "MANAGE 1.3, MANAGE 2.2" }, { "id": "iso_42001", "ref": "Clause 6.1" }, { "id": "eu_ai_act", "ref": "Art. 9(1)(b), Art. 15" }, { "id": "aisvs", "ref": "V5.1, V5.3" }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "flagship": true }, { "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", "published_on": "2024-11-17", "retrieved_on": "2026-06-26" }, { "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": "informative", "published_on": "2026-05-04", "retrieved_on": "2026-06-26" }, { "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", "version": "1.0", "published_on": "2026-06-26", "retrieved_on": "2026-06-26" } ], "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": { "references": [ { "relationship": "related", "uri": "apeiris://security/controls/RT-02", "name": "Detect direct and indirect prompt injection at every input and output", "note": "RT-02 detects direct and indirect prompt injection at every input and output on the security side." } ], "evidence_artifacts": [], "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 V5.1 and V5.3 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": "low", "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.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-06 operates a continuous InjectionProbeLibrary against production endpoints, computing InjectionResistanceScore per attack category and trending results over 30 days — directly operationalizing the security robustness measurement requirements of NIST AI RMF MEASURE 2.6 for the production deployment phase. MANAGE 2.4 is additionally relevant because critical InjectionResistanceScore drops trigger cross-domain notification to securitycontrols.ai, linking measurement to risk response.", "uncovered_portion": "MEASURE 2.6 spans robustness evaluation across the full AI lifecycle; BH-06 covers only production injection resistance measurement and does not address detection or blocking of actual attacks delegated to securitycontrols.ai, or pre-release adversarial evaluation covered by EV-06 and EV-07.", "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" }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-06 implements scheduled adversarial probe runs against the production model with defined InjectionResistanceScore thresholds, monthly governance board reports, and documented cross-domain alert routing — providing systematic measurement evidence for ISO 42001 Clause 9.1's monitoring and measurement obligations for security-relevant AI risks. Annex B identifies adversarial robustness as a core AI system risk requiring operational monitoring; BH-06 satisfies this obligation for the injection-resistance dimension through continuous production testing.", "uncovered_portion": "Clause 9.1 and Annex B address AI system performance monitoring and risk management across multiple dimensions; BH-06 covers only production injection resistance measurement and does not address other robustness dimensions, fairness monitoring, or management system effectiveness evaluation.", "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" }, { "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-ME-04", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-06 deploys runtime prompt injection detection and filtering as an operational defense layer — screening user inputs for injection attempts that seek to override system instructions — partially aligning with AITG-ME-04 Model Evaluation Testing which covers adversarial robustness including injection resistance as part of pre-release evaluation. Runtime operational defense goes beyond the evaluation-time probe suite the test defines.", "source_locator": { "section": "Model Evaluation Testing", "test_id": "AITG-ME-04" }, "uncovered_portion": "AITG-ME-04 covers adversarial robustness evaluation including injection resistance as part of pre-release red-teaming; runtime prompt injection detection and filtering as an operational defense mechanism goes beyond the evaluation-time probe suite the test defines.", "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" } ], "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" } } ] }, { "id": "BH-07", "cross_domain": { "references": [ { "relationship": "related", "uri": "apeiris://security/controls/EC-05", "name": "Cap spend and resource use, stop denial-of-wallet", "note": "EC-05 caps spend and resource use to stop denial-of-wallet on the security side." } ], "evidence_artifacts": [] }, "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, GOVERN 1.7" }, { "id": "iso_42001", "ref": "Clause 9.1" }, { "id": "aisvs", "ref": "V8.2" }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "flagship": true }, { "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", "published_on": "2024-11-17", "retrieved_on": "2026-06-26" }, { "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": "informative", "published_on": "2026-05-04", "retrieved_on": "2026-06-26" }, { "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", "version": "1.0", "published_on": "2026-06-26", "retrieved_on": "2026-06-26" } ], "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 V8.2 resource control 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": "low", "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": "BH-07 implements real-time cost and resource anomaly monitoring using Z-score and EWMA anomaly detection against rolling per-caller baselines, with configurable budget guardrails and tiered alerts for cost spikes — directly operationalizing NIST AI RMF MANAGE 2.4's requirement for risk response controls that prevent resource-related operational harms. GOVERN 1.7 is additionally relevant because per-caller budget caps and monthly cost reports fulfill the resource allocation accountability obligations of the GOVERN function for AI system operations.", "uncovered_portion": "MANAGE 2.4 addresses risk treatment and response for the full AI risk taxonomy; BH-07 covers only resource consumption and cost anomaly detection and does not address other risk response actions such as behavioral containment, safety policy enforcement, or incident response covered by CR-04.", "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" }, { "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" }, { "framework": "aicm", "requirement_id": "LOG-16", "fit": "direct", "direction": "control-supports-requirement", "rationale": "BH-07 deploys a cost and resource telemetry pipeline that aggregates compute spend, token consumption, and API call volume per caller using Z-score and EWMA anomaly detection against rolling baselines, firing tiered cost-spike alerts and enforcing configurable per-caller budget guardrails — directly implementing MON-05's resource utilization and cost anomaly monitoring requirement for AI systems. The control's correlation of cost spikes with AML.T0024 bulk inference patterns and routing of correlated events to securitycontrols.ai adds a security-aware dimension that extends MON-05's financial monitoring function into adversarial resource abuse detection.", "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 }, { "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" } ], "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" } } ] }, { "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.3, MANAGE 3.1" }, { "id": "iso_42001", "ref": "Clause 8.1, Clause 8.4" }, { "id": "eu_ai_act", "ref": "Art. 9, Art. 15" }, { "id": "sr262", "ref": "Section IV.B — Model Deployment Controls" } ], "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26", "flagship": true } ], "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": "low", "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.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-08 requires signed authorization artifacts, pre-defined canary exit criteria, and automated rollback triggers before any production traffic is routed to a new model version — directly implementing the deployment authorization and governance requirements of NIST AI RMF MANAGE 1.3. MANAGE 3.1 is additionally relevant because BH-08's four-stage deployment pipeline with documented rollback arms constitutes a structured risk response framework for managing deployment-phase risks.", "uncovered_portion": "MANAGE 1.3 and MANAGE 3.1 address deployment risk governance and response across the full risk management scope; BH-08 covers only deployment authorization and staged rollout governance and does not address post-deployment ongoing risk management covered by BH-01 through BH-07 and the CR layer.", "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" }, { "framework": "iso_42001", "requirement_id": "8.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-08 implements operational planning and control for model deployment transitions by requiring signed authorization artifacts, enforcing pre-defined canary exit criteria, and automating rollback triggers — directly satisfying ISO 42001 Clause 8.1's requirement that operational processes be planned, implemented, controlled, and reviewed. Clause 8.4 on the AI system lifecycle is additionally relevant because BH-08's four-stage deployment pipeline constitutes the deployment phase lifecycle control required by the AI system lifecycle management obligations.", "uncovered_portion": "Clauses 8.1 and 8.4 address operational control and AI system lifecycle management across all phases; BH-08 covers only the deployment transition phase governance and does not address ongoing operational controls for the serving phase covered by BH-01 through BH-07, or the decommissioning phase covered by CR-07.", "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" }, { "framework": "aicm", "requirement_id": "DSP-08", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-08 requires signed authorization artifacts from both the model owner and evaluation team lead before any new model version receives live production traffic, implements a four-stage pipeline with pre-defined health gates and automated rollback triggers, and archives all transition records in a DeploymentGovernanceLog — directly implementing DP-01's AI model deployment gates, canary release governance, and rollback controls requirement. The shadow scoring comparison requirement, which demands less than 5% output divergence on safety-critical categories before canary authorization, provides the pre-traffic quantitative gate that DP-01 requires.", "source_locator": { "section": "Deployment and Change Management" }, "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-08 additionally covers privacy engineering practices for application interfaces, access controls on personal data, and privacy-by-default configuration across the full data lifecycle." }, { "framework": "owasp_aitg", "requirement_id": "AITG-RT-08", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "BH-08 enforces formal authorization gates and signed deployment artifacts before production traffic is routed to any new model version, ensuring that supply-chain changes and upstream model updates are assessed through shadow scoring and staged canary rollout before full exposure — supporting AITG-RT-08 Runtime Testing by governing the deployment pipeline through which changes to AI providers and supply-chain components are introduced into the production environment.", "source_locator": { "section": "Runtime Testing", "test_id": "AITG-RT-08" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" } ], "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" } } ] }, { "id": "BH-09", "cross_domain": { "references": [ { "relationship": "related", "uri": "apeiris://security/controls/GV-07", "name": "Protect humans from being deceived by an agent", "note": "GV-07 protects humans from being deceived by an agent on the security side." } ], "evidence_artifacts": [] }, "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": "Clause 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", "version": "2.1", "published_on": "2024-11-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", "version": "1.0" }, { "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 }, { "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", "published_on": "2024-11-17", "retrieved_on": "2026-06-26" }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" } ], "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", "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": { "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.", "capability_level": "none" }, "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." }, { "framework": "nist_rmf", "requirement_id": "GOVERN-1.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-09 embeds C2PA-compliant provenance assertions in AI-generated content and maintains a GenerationTraceabilityRegistry linking every output to the generating model version — providing the technical accountability and traceability infrastructure that NIST AI RMF GOVERN 1.2 requires for transparency about AI system outputs. GOVERN 6.1 is additionally relevant because BH-09's mandatory disclosure labels and provenance verification endpoint operationalize the transparency communication requirements for generative AI deployments under the GOVERN function.", "uncovered_portion": "GOVERN 1.2 and GOVERN 6.1 address accountability and transparency policy across the full AI lifecycle; BH-09 applies exclusively to the generative-ai profile and addresses only the technical provenance embedding and disclosure label components, not broader accountability structures or stakeholder transparency obligations.", "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" }, { "framework": "iso_42001", "requirement_id": "8.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-09 documents AI-generated content at the point of creation through C2PA manifest embedding, maintains a GenerationTraceabilityRegistry, and applies mandatory EU AI Act Art. 50 disclosure labels — fulfilling ISO 42001 Clause 8.2's AI system documentation requirements for generative AI outputs. Annex A.6 on system transparency further requires that AI systems provide mechanisms for identifying AI-generated content; BH-09 directly implements this through cryptographic provenance assertions and disclosure labels.", "uncovered_portion": "Clause 8.2 and Annex A.6 address AI system documentation and transparency as system-level properties; BH-09 covers only the content provenance and disclosure dimensions for the generative-ai profile and does not address broader system documentation obligations such as model card maintenance covered by LI-04 or system-level transparency disclosures.", "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" }, { "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." }, { "framework": "owasp_aitg", "requirement_id": "AITG-RT-07", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "BH-09 implements C2PA-compliant provenance assertion embedding, mandatory disclosure labels, and a GenerationTraceabilityRegistry for AI-generated content — addressing the transparency and traceability requirements for synthetic outputs in the same runtime domain as AITG-RT-07 Runtime Testing, which requires that system prompt and runtime configuration integrity be maintained and verifiable in the production deployment.", "uncovered_portion": "AITG-RT-07 addresses system prompt and runtime configuration integrity — protecting the model's operational instructions and configuration state from unauthorized modification; BH-09 addresses content provenance and disclosure for AI-generated outputs, which is a distinct concern in the same runtime domain.", "source_locator": { "section": "Runtime Testing", "test_id": "AITG-RT-07" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" } } ] }, { "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 2.2, MANAGE 4.1" }, { "id": "iso_42001", "ref": "Clause 8.1, Clause 10.1" }, { "id": "eu_ai_act", "ref": "Art. 9(1)(c), Art. 12" }, { "id": "sr262", "ref": "Section IV.C — Ongoing Monitoring" }, { "id": "aisvs", "ref": "V7.2" } ], "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26" }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26" }, { "id": "sr262_2026", "authority": "Federal Reserve / OCC", "title": "SR 26-2: Supervisory 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": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26", "flagship": true }, { "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": "informative", "published_on": "2026-05-04", "retrieved_on": "2026-06-26" }, { "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", "published_on": "2024-11-17", "retrieved_on": "2026-06-26" }, { "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", "version": "1.0", "published_on": "2026-06-26", "retrieved_on": "2026-06-26" } ], "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": { "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.", "capability_level": "elevated" }, "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 V7.2 feedback 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-2.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-10 governs all post-deployment feedback loops — requiring signed authorization for online learning updates, monitoring inter-rater reliability via Cohen's Kappa, detecting feedback poisoning through PSI anomaly detection, and implementing self-reinforcing error circuit breakers — directly operationalizing NIST AI RMF MANAGE 2.2's requirement for controls that manage changing AI system behaviors over time. MANAGE 2.4 is additionally relevant because BH-10's circuit breakers and poisoning alerts constitute the risk response layer when feedback anomalies are detected.", "uncovered_portion": "MANAGE 2.2 and MANAGE 2.4 address risk management for changing system behaviors and response actions across the full AI risk taxonomy; BH-10 covers only feedback loop integrity and online learning governance for continuously-learning and generative-ai profiles, not other post-deployment behavioral management dimensions.", "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" }, { "framework": "iso_42001", "requirement_id": "8.6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-10 implements governance controls for all feedback data that influences model behavior after deployment — including inter-rater reliability monitoring, feedback poisoning detection with PSI threshold of 0.2, and a signed authorization gate for online learning updates — directly operationalizing ISO 42001 Clause 8.6's requirement for data governance controls throughout the AI system lifecycle. For continuously-learning deployments, Clause 8.6's obligations extend to production feedback data, which BH-10 governs through labeler quality controls, anomaly detection, and the FeedbackGovernanceLog.", "uncovered_portion": "Clause 8.6 addresses data governance across the full AI system lifecycle including training and evaluation data; BH-10 covers only post-deployment feedback data integrity and online learning governance, not training data governance covered by TG layer controls or evaluation data governance.", "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" }, { "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-DG-05", "fit": "partial", "direction": "control-supports-requirement", "rationale": "BH-10 implements runtime feedback collection integrity controls — ensuring that RLHF telemetry, preference signals, and reward data collected in production are authentic and unmanipulated before being fed back into model updates — partially aligning with AITG-DG-05 Data Governance Testing which addresses feedback-loop and RLHF data integrity at training time. The operational runtime scope extends beyond the training-phase governance the test defines.", "source_locator": { "section": "Data Governance Testing", "test_id": "AITG-DG-05" }, "uncovered_portion": "AITG-DG-05 addresses feedback-loop and RLHF data integrity at training time; runtime feedback collection integrity including RLHF telemetry pipelines and production reward signal monitoring extends the test's training-phase scope into the operational deployment phase.", "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "SR 26-2 §III.C ongoing monitoring requirements include ongoing assessment of model behavior; BH-10's feedback loop integrity controls provide adjacent assurance for continuously-learning models in banking contexts by preventing systematic degradation through corrupted feedback signals.", "uncovered_portion": "SR 26-2 applies to supervised banking organizations with $30B+ in assets. SR 26-2 does not specifically address continuously-learning AI systems or reinforcement learning from human feedback; this mapping 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" } ], "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" } } ] }, { "id": "CR-01", "cross_domain": { "references": [ { "relationship": "related", "uri": "apeiris://security/controls/RT-04", "name": "Detect anomalies and trigger pause, kill switch, or containment", "note": "RT-04 detects anomalies and triggers pause, kill switch, or containment on the security side." } ], "evidence_artifacts": [] }, "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": "MANAGE-2.4", "title": "Risk monitoring in AI systems" }, { "id": "iso_42001", "section": "A.9.2", "title": "Monitoring and measurement" }, { "id": "sr262", "section": "S-5.1", "title": "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", "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 }, { "id": "sr262_2026", "title": "SR 26-2: Supervisory Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "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" }, { "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" } ], "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 required by SR 26-2 S-5.1 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": "S-5.1", "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": "S-5.1", "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": { "description": "Monitoring gap compounds capability risk: the higher the system capability, the more damaging undetected degradation or deviation becomes.", "risk_level": "elevated", "relevant_profiles": [ "frontier-capability", "high-impact-decision", "continuously-learning" ], "capability_level": "none" }, "canonical_id": "apeiris://model/controls/CR-01", "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CR-01 aggregates all runtime risk signals — performance, drift, fairness, safety, and cost — into a unified risk dashboard with automated alerting thresholds calibrated at ±2σ from baseline, directly operationalizing NIST AI RMF MEASURE 2.3's production monitoring requirement for AI systems. MANAGE 2.4 is additionally relevant because CR-01's tiered alert structure (P1 for safety threshold breaches, P2 for performance drift) constitutes the risk response triggering mechanism that routes monitoring signals to the appropriate risk treatment pathway.", "uncovered_portion": "MEASURE 2.3 encompasses the full AI system monitoring scope including evaluation of management system effectiveness; CR-01 covers the aggregated runtime monitoring and alerting layer and does not address pre-deployment evaluation gates covered by the EV layer or the structured risk response actions covered by CR-04.", "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" }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CR-01 implements a comprehensive monitoring, measurement, analysis, and evaluation system covering five metric types — performance, drift, fairness, safety, and cost — with a composite risk score updated on each operational window and a read-only GRC access dashboard, directly fulfilling ISO 42001 Clause 9.1's requirement for systematic monitoring and evaluation of AI system performance. The quarterly synthetic anomaly injection test requirement and documented alert threshold rationale fulfill Clause 9.1's requirement for evidence of monitoring effectiveness and management review inputs.", "uncovered_portion": "Clause 9.1 spans management system effectiveness evaluation and AI system performance monitoring across all risk dimensions; CR-01 addresses operational runtime signal aggregation and does not cover the management system evaluation or other lifecycle monitoring dimensions that Clause 9.1's full scope encompasses.", "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" }, { "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." }, { "framework": "owasp_aitg", "requirement_id": "AITG-IR-02", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CR-01 aggregates all runtime risk signals — performance, drift, fairness, safety, cost, and incident flags — into a unified risk dashboard with documented thresholds and automated P1/P2 alerting, providing the continuous risk assessment infrastructure that directly implements AITG-IR-02 Incident Response Testing's requirement for structured AI system risk evaluation on a defined schedule with formally documented and auditable assessment processes.", "source_locator": { "section": "Incident Response Testing", "test_id": "AITG-IR-02" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 §III.C requires ongoing model monitoring that aggregates performance signals and escalates material deterioration to appropriate stakeholders; CR-01's P1/P2/P3 tiered alert structure directly implements this requirement by routing critical threshold breaches to model owners and risk management.", "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" } ] }, { "id": "CR-02", "cross_domain": { "references": [ { "relationship": "mirrored-by", "uri": "apeiris://security/controls/GV-02", "name": "Keep an immutable, tamper-evident audit trail of what the agent did", "note": "GV-02 mirrors this on the security side: an immutable, tamper-evident audit trail of agent actions." } ], "evidence_artifacts": [] }, "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. Regulators under EU AI Act Art. 12, SR 26-2 S-5.2, and ISO 42001 A.9.3 all require retention of documentation 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-5.2", "title": "AI documentation and recordkeeping" }, { "id": "iso_42001", "section": "A.9.3", "title": "Documented information and records" }, { "id": "sr262", "section": "S-5.2", "title": "Model documentation and record retention" }, { "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 }, { "id": "sr262_2026", "title": "SR 26-2: Supervisory Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "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" }, { "id": "sigstore_rekor", "title": "Sigstore Rekor — Immutable Transparency Log", "authority": "Sigstore Project (OpenSSF)", "source_type": "product-documentation", "normative_force": "informative", "version": "1.3.0", "published_on": "2024-01-15", "retrieved_on": "2026-06-26", "canonical_url": "https://docs.sigstore.dev/rekor/overview/", "license": "apache-2.0", "status": "current" } ], "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 S-5.2. 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": { "description": "Frontier-capability systems require deeper evidence chains including dangerous capability evaluation manifests; evidence archive must support structured findings sub-arrays.", "risk_level": "elevated", "relevant_profiles": [ "frontier-capability", "eu-high-risk", "us-regulated-banking" ], "capability_level": "none" }, "canonical_id": "apeiris://model/controls/CR-02", "frameworks": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-6.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CR-02 implements an immutable, content-addressed evidence archive anchored to the Sigstore Rekor transparency log with S3 Object Lock COMPLIANCE mode storage and a read-only retrieval API accessible to auditors — directly operationalizing NIST AI RMF GOVERN 6.2's requirement for records management and accountability documentation that supports oversight of AI systems throughout their lifecycle. MANAGE 2.4 is additionally relevant because the CR-02 archive is the primary source of artifacts for post-incident investigation and corrective action verification.", "uncovered_portion": "GOVERN 6.2 addresses accountability and transparency information requirements across the full AI system scope including real-time accountability disclosures; CR-02 covers only the records retention and evidence archival dimension and does not address real-time transparency reporting or stakeholder communication obligations.", "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" }, { "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" }, { "framework": "aicm", "requirement_id": "SEF-07", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CR-02 maintains an immutable, content-addressed archive anchored to the Sigstore Rekor transparency log with S3 Object Lock COMPLIANCE mode storage — covering all evaluation manifests, monitoring snapshots, incident records, and regulatory submissions with retention schedules of 3 years (default) and 10 years (regulated banking) — directly implementing GOV-07's model evidence archival, audit trail, and records management requirement. The evidence retrieval API with auditor read-only access and annual retrieval testing fulfill GOV-07's expectation that archived evidence is verifiably accessible and tamper-evident throughout the retention period.", "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-IR-01", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "CR-02 maintains an immutable, content-addressed evidence archive with Sigstore Rekor transparency-log anchoring — providing the evidentiary foundation that supports AITG-IR-01 Incident Response Testing by ensuring that all artifacts required for incident detection, investigation, and response are retained in a tamper-evident store accessible to auditors, and that incident detection capability is demonstrably operational through retrieval of archived monitoring snapshots.", "source_locator": { "section": "Incident Response Testing", "test_id": "AITG-IR-01" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" }, { "framework": "sr262", "requirement_id": "S-4.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 §IV.D requires banking organizations to maintain comprehensive model documentation and records that support ongoing monitoring, audit, and supervisory examination; CR-02's immutable evidence archive with read-only audit API provides the records infrastructure required for examiner access to model validation and performance documentation.", "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" } ] }, { "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 S-4.3 requires periodic validation; EU AI Act Art. 43 requires conformity re-assessment when substantial modifications occur." }, "standard": [ { "id": "nist_rmf", "section": "MANAGE-3.1", "title": "Responses to identified AI risks" }, { "id": "sr262", "section": "S-4.3", "title": "Periodic model validation" }, { "id": "eu_ai_act", "section": "Art-43", "title": "Conformity assessment" }, { "id": "iso_42001", "section": "A.6.2", "title": "AI system lifecycle — verification and validation" } ], "sources": [ { "id": "sr262_2026", "title": "SR 26-2: Supervisory Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "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" }, { "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 }, { "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", "version": "1.0", "published_on": "2023-01-26", "status": "current", "authority": "NIST", "license": "public-domain" } ], "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 is a compliance obligation under SR 26-2 S-4.3. 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": "low", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CR-03 runs full benchmark, bias, and safety evaluation suites on a defined schedule — quarterly for Tier-1 models, semi-annually for Tier-2, annually for Tier-3 — with delta reports comparing current performance against the release baseline, directly operationalizing NIST AI RMF MEASURE 2.2's requirement for periodic measurement of AI system performance to verify that systems continue to meet their stated objectives post-deployment. MANAGE 3.1 is additionally relevant because CR-03's threshold breach triggers automatically initiate CR-04 incident response and, for EU high-risk systems, the conformity re-assessment process.", "uncovered_portion": "MEASURE 2.2 encompasses the full measurement scope for verifying AI systems meet their objectives including real-time performance monitoring; CR-03 addresses only the scheduled re-validation evaluation dimension and does not cover continuous runtime monitoring covered by BH-01 through BH-07 or the incident response framework covered by CR-04.", "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" }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CR-03 implements a scheduled AI system evaluation program with risk-tier-conditional cadences and produces signed delta reports comparing re-validation results against the pre-deployment baseline, reviewed by the model owner before archiving in CR-02 — directly fulfilling ISO 42001 Clause 9.1's requirement for monitoring, measurement, analysis, and evaluation of AI system performance on a defined schedule. The re-validation pipeline is required to be identical to the pre-deployment evaluation pipeline, satisfying Clause 9.1's comparability requirement for performance measurement.", "uncovered_portion": "Clause 9.1 spans the full monitoring scope including management system effectiveness evaluation and all AI system performance dimensions; CR-03 covers only the scheduled re-validation cadence and does not address continuous runtime monitoring or management system effectiveness evaluation encompassed by Clause 9.1's full scope.", "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" }, { "framework": "aicm", "requirement_id": "A&A-02", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CR-03 runs the full benchmark, bias, and safety evaluation suite on a defined schedule — quarterly for Tier-1 models, semi-annually for Tier-2, annually for Tier-3 — with delta reports comparing current performance against the pre-deployment baseline and archived in CR-02, directly implementing EVA-06's scheduled post-deployment model re-validation and periodic evaluation requirement. The trigger mechanism for unscheduled re-validation on CR-01 P1 alerts, PSI exceeding 0.25, or provider-announced model updates ensures that re-validation occurs whenever material risk signals emerge rather than only on the calendar schedule.", "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-IR-03", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CR-03 executes the full benchmark, bias, and safety evaluation suite on a defined schedule and produces signed delta reports comparing current AI system state against the release baseline — directly implementing AITG-IR-03 Incident Response Testing's requirement that the AI system state be reconstructable and comparable to historical reference states to support post-incident forensic analysis and root-cause determination.", "source_locator": { "section": "Incident Response Testing", "test_id": "AITG-IR-03" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" }, { "framework": "sr262", "requirement_id": "S-3.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 §III.C.2 requires periodic re-validation triggered by material changes, performance deterioration, or the passage of time; CR-03's material-change detection triggers and scheduled re-evaluation cadence directly operationalize this SR 26-2 requirement for banking models.", "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" } ], "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" } } ] }, { "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": "RESPOND-1.1", "title": "Incident response for AI systems" }, { "id": "sr262", "section": "S-6", "title": "Model risk incident escalation" }, { "id": "eu_ai_act", "section": "Art-73", "title": "Reporting of serious incidents" }, { "id": "iso_42001", "section": "A.10.1", "title": "Incident management — 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 }, { "id": "sr262_2026", "title": "SR 26-2: Supervisory Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "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" }, { "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": "informative", "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" }, { "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", "version": "1.0", "published_on": "2023-01-26", "status": "current", "authority": "NIST", "license": "public-domain" } ], "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 15 days [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 <15-day timeline for serious incidents [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": "low", "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": "CR-04 defines and maintains an AI-specific Incident Response Plan with four severity levels, AI-specific containment playbooks covering model rollback, output-filter enforcement, traffic shaping, and full model shutdown, plus regulatory notification triggers and quarterly MITRE ATLAS tabletop exercises — directly operationalizing NIST AI RMF MANAGE 4.1's requirement for risk treatment plans that include incident response and corrective action capabilities for AI systems. RESPOND 1.1 is additionally relevant because CR-04's AIRP and playbooks constitute the organizational AI incident response capability required under the RESPOND function.", "uncovered_portion": "MANAGE 4.1 addresses risk treatment planning across the full AI risk taxonomy including preventive and continuous controls; CR-04 covers only the incident response and corrective action dimension and does not address preventive risk treatment or the ongoing risk monitoring covered by CR-01 and BH layer controls.", "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" }, { "framework": "iso_42001", "requirement_id": "10.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CR-04 establishes a documented AI Incident Response Plan with defined severity classification criteria, model-specific containment playbooks, and a 5-day post-incident review requirement for P1/P2 events — directly fulfilling ISO 42001 Clause 10.1's requirement for documented processes for identifying and responding to nonconformities and implementing corrective actions. Quarterly tabletop exercises using MITRE ATLAS adversarial scenarios fulfill Clause 10.1's requirement for verifying the effectiveness of corrective action processes through regular testing.", "uncovered_portion": "Clause 10.1 addresses nonconformity and corrective action across the full AI management system scope including systemic improvement; CR-04 covers only the incident response and immediate corrective action dimension and does not address continual improvement of the management system or preventive action processes encompassed by Clause 10.1's full scope.", "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" }, { "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-IR-04", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CR-04 defines, tests, and requires exercise of AI-specific incident response procedures — including model rollback to prior versions via LI-06, output-filter enforcement, traffic shaping, and full model shutdown with fallback — and mandates quarterly tabletop exercises with signed results archives, directly implementing AITG-IR-04 Incident Response Testing's requirement that rollback and recovery procedures for AI systems be formally defined and validated through regular exercise.", "source_locator": { "section": "Incident Response Testing", "test_id": "AITG-IR-04" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "SR 26-2 §III.C requires escalation procedures for material model performance issues; CR-04's incident management framework provides adjacent coverage of the escalation and remediation requirements in the SR 26-2 ongoing monitoring section.", "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" } ], "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" } } ] }, { "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 S-6.1 requires board-level model risk reporting. 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": "S-6.1", "title": "Board and senior management reporting" }, { "id": "nist_rmf", "section": "GOVERN-4.1", "title": "Accountability and regulatory obligations" } ], "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 }, { "id": "sr262_2026", "title": "SR 26-2: Supervisory Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "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" } ], "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 <15-day notification [ref:eu_ai_act_2024]", "US banking: map SR 26-2 S-6.1 board reporting cadence (quarterly minimum, immediate for material events) to CR-04 escalation [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 15-day countdown [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": "low", "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-1.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CR-05 maintains a regulatory notification matrix mapping trigger events to jurisdictions, notification timelines, and designated liaison contacts, with automated countdown timer creation integrated into the CR-04 P1 incident escalation path — directly addressing NIST AI RMF GOVERN 1.4's requirement that organizations identify and meet their legal and regulatory accountability obligations for AI systems. GOVERN 4.1 is additionally relevant because CR-05's legal-counsel-reviewed notification matrix and countdown mechanism operationalize the organizational policies for satisfying external regulatory accountability requirements.", "uncovered_portion": "GOVERN 1.4 and GOVERN 4.1 address the full accountability and regulatory obligation scope for AI systems including internal governance structures; CR-05 covers only the statutory regulatory notification and reporting dimension and does not address internal governance accountability obligations or the broader transparency requirements encompassed by GOVERN 1.4's full scope.", "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" }, { "framework": "iso_42001", "requirement_id": "5.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CR-05 implements organization-wide accountability for regulatory notification obligations by integrating statutory reporting requirements into the incident response workflow and designating a regulatory liaison role responsible for timely submission — partially fulfilling ISO 42001 Clause 5.2's requirement that AI policy includes commitments to meeting applicable requirements and that leadership ensures these commitments are operationalized. The legal-counsel-reviewed notification matrix and annual review requirement fulfill Clause 5.2's management commitment and documented policy obligations.", "uncovered_portion": "Clause 5.2 addresses the full leadership commitment scope including AI policy definition, resource commitment, and strategic direction for the AI management system; CR-05 covers only the regulatory notification dimension of leadership accountability and does not address broader AI policy commitments, resource direction, or strategic AI management system leadership obligations.", "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" }, { "framework": "aicm", "requirement_id": "CCC-01", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CR-05 maintains a regulatory notification matrix mapping trigger events across jurisdictions to notification timelines, designated liaison contacts, and pre-approved templates — integrating automated countdown timer creation into the CR-04 P1 incident escalation path and archiving all notification submissions with delivery confirmations in CR-02 — directly implementing CL-02's regulatory notification obligations and statutory AI incident reporting requirement. Legal-counsel annual review of the notification matrix ensures that statutory reporting obligations remain current as the regulatory landscape evolves.", "source_locator": { "section": "Compliance and Legal Obligations" }, "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-IR-05", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "CR-05 establishes statutory reporting obligations and regulatory notification procedures for AI incidents — maintaining a pre-approved notification matrix, countdown timers, and a notification archive in CR-02 — addressing the regulatory accountability dimension in the same incident response domain as AITG-IR-05 Incident Response Testing, which requires that audit trail integrity be maintained and verifiable for AI system accountability purposes.", "uncovered_portion": "AITG-IR-05 requires that audit trail integrity be maintained and verifiable for AI system accountability; CR-05 addresses the regulatory notification and statutory disclosure dimension of incident accountability, which is a related but distinct concern — the audit trail integrity requirements of AITG-IR-05 are addressed by CR-02's immutable evidence archive and Sigstore transparency anchoring.", "source_locator": { "section": "Incident Response Testing", "test_id": "AITG-IR-05" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 §III.C requires ongoing monitoring including outcomes analysis to compare model predictions against realized results; CR-05's systematic outcomes analysis and back-testing framework directly implements this SR 26-2 requirement for banking models.", "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" } ] }, { "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.9.4", "title": "Feedback and improvement" }, { "id": "nist_rmf", "section": "MANAGE-4.1", "title": "Risk treatment and ongoing review" } ], "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" }, { "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", "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 } ], "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": "low", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "low" }, "frameworks": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CR-06 establishes three proactive surveillance channels — user-facing harm reporting, coordinated vulnerability disclosure, and quarterly literature monitoring — that extend AI system monitoring beyond passive runtime metrics to capture harm data that internal instrumentation alone cannot detect, directly supporting NIST AI RMF MEASURE 2.3's production monitoring obligation. MANAGE 4.1 is additionally relevant because CR-06's monthly surveillance report feeds the risk treatment process, triggering CR-04 incident response when surveillance signals meet P1/P2 severity criteria.", "uncovered_portion": "MEASURE 2.3 encompasses the full AI system monitoring scope including runtime statistical monitoring and performance regression detection; CR-06 covers only the proactive surveillance channels for externally-reported harms and third-party research findings, not the runtime instrumentation dimension covered by CR-01 and the BH layer.", "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" }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CR-06 implements a structured post-market surveillance program with three proactive input channels — user harm reporting, CVD submissions, and literature monitoring — aggregated into a monthly report reviewed by the AI risk function, fulfilling ISO 42001 Clause 9.1's requirement for monitoring and evaluation that captures AI system performance signals from the operating environment beyond internal instrumentation. Annex B's risk monitoring obligations for deployed AI systems are additionally addressed because CR-06 captures external risk signals and escalates qualifying findings to the incident response process.", "uncovered_portion": "Clause 9.1 spans systematic monitoring including internal performance measurement and management system effectiveness evaluation; CR-06 covers only the external surveillance and feedback channel dimension of production monitoring and does not address internal runtime metric monitoring covered by CR-01 or re-validation covered by CR-03.", "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" }, { "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-IR-02", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "CR-06 establishes proactive post-market surveillance channels — user harm reporting, coordinated vulnerability disclosure, and literature monitoring — that aggregate external harm and vulnerability signals into a monthly risk report reviewed by the AI risk function, supporting AITG-IR-02 Incident Response Testing by providing externally-sourced evidence that informs risk assessment and ensures the evaluation process captures harm signals that passive internal monitoring cannot detect.", "source_locator": { "section": "Incident Response Testing", "test_id": "AITG-IR-02" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" } }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "SR 26-2 §III.C escalation procedures include notifying senior management and relevant risk functions; CR-06's regulatory notification procedures provide adjacent coverage of the formal escalation requirements in SR 26-2, though they are oriented toward regulatory authorities rather than internal escalation.", "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" } ] }, { "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 ML Model Access via forgotten endpoints) and regulatory liability. EU AI Act Art. 13 and ISO 42001 A.6.3 require that end-of-life AI systems are decommissioned in a documented manner. SR 26-2 S-5.3 requires that model documentation be retained for the statutory period after retirement." }, "standard": [ { "id": "iso_42001", "section": "A.6.3", "title": "AI system lifecycle — decommissioning" }, { "id": "sr262", "section": "S-5.3", "title": "Record retention post-retirement" }, { "id": "eu_ai_act", "section": "Art-13", "title": "Transparency and provision of information to users" }, { "id": "nist_rmf", "section": "MANAGE-4.2", "title": "Decommissioning and disposal" } ], "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 }, { "id": "sr262_2026", "title": "SR 26-2: Supervisory Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "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" }, { "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", "version": "1.0", "published_on": "2023-01-26", "status": "current", "authority": "NIST", "license": "public-domain" } ], "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. Final retirement record is a regulatory document under SR 26-2 S-5.3. 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": "low", "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": "MANAGE-2.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CR-07 implements a formal model retirement process with a signed retirement decision record, traffic drain verification, IAM credential revocation, complete infrastructure decommissioning, evidence archive completeness verification, GDPR Art. 17 evaluation, and a final retirement record — directly operationalizing NIST AI RMF MANAGE 2.4's requirement for risk treatment actions that include decommissioning and end-of-life disposal of AI systems. MANAGE 4.2 is additionally relevant because CR-07's GDPR Art. 17 evaluation constitutes the post-retirement risk treatment for any remaining data subject rights obligations linked to the retired model.", "uncovered_portion": "MANAGE 2.4 and MANAGE 4.2 address risk treatment and disposal across the full AI risk taxonomy including active runtime risk responses; CR-07 covers only the end-of-life retirement and decommissioning dimension and does not address ongoing risk treatment for active deployments covered by BH layer controls and CR-04.", "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" }, { "framework": "iso_42001", "requirement_id": "8.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CR-07 implements operational planning and control for the AI system decommissioning phase — requiring a signed retirement decision record, minimum 30-day notice period, evidence archive completeness verification, and a final retirement record — directly satisfying ISO 42001 Clause 8.1's requirement that all AI system lifecycle phases be planned, implemented, controlled, and reviewed. Clause A.6.3 on AI system lifecycle decommissioning is additionally fulfilled because CR-07's retirement checklist ensures decommissioning is conducted in a documented and auditable manner with appropriate stakeholder notification.", "uncovered_portion": "Clause 8.1 addresses operational planning and control across all AI system lifecycle phases including development, deployment, and operation; CR-07 covers only the decommissioning and end-of-life phase and does not address operational controls for the active deployment phase covered by BH layer controls.", "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" }, { "framework": "aicm", "requirement_id": "TVM-04", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CR-07 executes a formal model retirement checklist encompassing retirement decision approval, minimum 30-day user notice, traffic drain verification, IAM credential revocation, complete infrastructure decommissioning, evidence archive completeness verification, GDPR Art. 17 right-to-erasure evaluation, and a final retirement record — directly implementing GOV-08's AI model retirement, lifecycle closure, and evidence archival obligations requirement. Marking the model as retired in the model registry and archiving all assurance evidence before infrastructure destruction ensures that regulatory obligations do not outlast the model's serving infrastructure.", "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-IR-06", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CR-07 executes a formal model retirement process that notifies affected users and stakeholders with at minimum 30 days' advance notice, provides migration path documentation, produces a final retirement record, and ensures all evidence is archived before infrastructure decommission — directly implementing AITG-IR-06 Incident Response Testing's requirement that communication procedures for AI system changes and decommissioning be formally defined and that appropriate stakeholders are notified in a timely manner.", "source_locator": { "section": "Incident Response Testing", "test_id": "AITG-IR-06" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" }, { "framework": "sr262", "requirement_id": "S-4.1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "SR 26-2 §IV.A requires model governance to cover the full model lifecycle including retirement; CR-07's decommissioning checklist — covering traffic drain, evidence archival, dependent-system notification, and 7-year post-retirement evidence retention — directly supports the lifecycle governance requirement.", "uncovered_portion": "SR 26-2 applies to supervised banking organizations with $30B+ in assets. SR 26-2 §IV.A is general governance rather than a detailed decommissioning procedure; the specific decommissioning process is organizationally defined.", "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" } ], "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" } } ] }, { "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-6.1", "title": "Policies and procedures for AI risk management across organizational boundaries" }, { "id": "iso_42001", "section": "A.4.2", "title": "AI risk management — organizational context" } ], "sources": [ { "id": "apeiris_thesis", "title": "Apeiris Namespace Registry and Multi-Domain Architecture Thesis", "authority": "Apeiris", "source_type": "apeiris-thesis", "normative_force": "informative", "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", "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 } ], "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": "related", "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": [] }, "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": "low", "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-2.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CR-08 resolves all apeiris:// cross-domain evidence references against the namespace-registry.json resolver_map at build time, maintains a cross-domain dependency map updated on each release, and coordinates quarterly sync reviews between model-domain and security-domain owners — directly addressing NIST AI RMF GOVERN 2.2's requirement for organizational practices that establish accountability and coordination for AI risk management across functional and organizational boundaries. GOVERN 6.1 is additionally relevant because CR-08 implements the inter-domain policies and procedures needed to ensure that no cross-domain assurance gap creates an uncompensated blind spot.", "uncovered_portion": "GOVERN 2.2 and GOVERN 6.1 address organizational accountability and inter-organizational AI risk governance across the full governance scope; CR-08 covers only the cross-domain evidence reference resolution and coordination dimension and does not address single-domain governance accountability covered by OA layer controls.", "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" }, { "framework": "iso_42001", "requirement_id": "8.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CR-08 implements governance for cross-domain evidence references through the audit:cross-domain build check, namespace-registry.json resolver validation, and quarterly cross-domain sync reviews — supporting ISO 42001 Clause 8.3's requirement for processes that govern AI system design activities including coordination across organizational and domain boundaries. Annex A.4.2 on organizational context for AI risk management is additionally addressed because CR-08 explicitly compensates the gap3 cross-domain federation finding through structured inter-domain accountability and documented open findings.", "uncovered_portion": "Clause 8.3 addresses AI system design and development process governance across the full system scope; CR-08 covers only the cross-domain assurance coordination dimension and does not address intra-domain design and development governance covered by other controls.", "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" }, { "framework": "aicm", "requirement_id": "A&A-04", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "CR-08 resolves all apeiris:// cross-domain evidence references against the namespace-registry.json resolver_map at build time, maintains a cross-domain dependency map updated on each release, and coordinates quarterly sync reviews between model-domain and security-domain owners — providing the technical evidence synchronization and reference resolution mechanism that supports GOV-09's cross-domain AI assurance coordination and evidence synchronization requirement. GOV-09's broader organizational governance coordination scope extends beyond the technical inter-domain evidence linkage that this control directly implements.", "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 }, { "framework": "owasp_aitg", "requirement_id": "AITG-IR-05", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "CR-08 resolves cross-domain apeiris:// evidence references, maintains a cross-domain dependency map, and coordinates inter-domain assurance reviews — addressing multi-domain audit trail integrity in the same evidence accountability domain as AITG-IR-05 Incident Response Testing, which requires that audit trail integrity be maintained and verifiable for AI system accountability purposes.", "uncovered_portion": "AITG-IR-05 addresses audit trail integrity for a single AI system's evidence chain; CR-08 addresses cross-domain evidence reference resolution and inter-domain assurance coordination across multiple Apeiris domain boundaries, which is a distinct concern in the same evidence accountability domain that AITG-IR-05 does not prescribe solutions for.", "source_locator": { "section": "Incident Response Testing", "test_id": "AITG-IR-05" }, "source_version": "1.0", "mapping_confidence": "medium", "reviewed_on": "2026-06-26" }, { "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" }, { "framework": "sr262", "requirement_id": "S-4.2", "fit": "adjacent", "direction": "control-supports-requirement", "rationale": "SR 26-2 §IV.D requires comprehensive records that support supervisory examination; CR-08's cross-domain compliance evidence collection provides adjacent coverage of the records management requirement by assembling evidence from multiple control domains.", "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" } ], "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" } } ] } ], "references": [ { "id": "anthropic_rsp_v3_3", "title": "Responsible Scaling Policy v3.3", "authority": "Anthropic", "source_type": "vendor-framework", "normative_force": "voluntary", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": null, "license": "proprietary", "supersedes": [ "RSP v3.2", "RSP v3.1", "RSP v3.0" ], "status": "current", "flagship": false, "cited_by": [ "EV-03" ] }, { "id": "apeiris_thesis", "title": "Apeiris Namespace Registry and Multi-Domain Architecture Thesis", "authority": "Apeiris", "source_type": "apeiris-thesis", "normative_force": "informative", "version": "1.0", "published_on": "2026-06-26", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": "apeiris://model/core/namespace-registry", "license": "proprietary", "supersedes": null, "status": "current", "flagship": false, "cited_by": [ "CR-08" ] }, { "id": "c2pa_spec_v2", "title": "C2PA Technical Specification v2.x", "authority": "Coalition for Content Provenance and Authenticity (C2PA)", "source_type": "voluntary-standard", "normative_force": "voluntary", "version": "2.1", "published_on": "2024-11-01", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": null, "license": "CC BY 4.0", "supersedes": null, "status": "current", "flagship": false, "cited_by": [ "BH-09" ] }, { "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", "normative_force": "binding-law", "version": "2023", "published_on": "2023-01-01", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": null, "license": "public", "supersedes": null, "status": "current", "flagship": false, "cited_by": [ "TG-03", "TG-08" ] }, { "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", "version": "1.1", "published_on": "2024-06-01", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": "https://cloudsecurityalliance.org/research/topics/ai-controls-matrix", "license": "CC BY-SA 4.0", "supersedes": null, "status": "current", "flagship": false, "cited_by": [ "LI-08" ] }, { "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", "artifact_hash": null, "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689", "license": "EU-public-sector-information", "supersedes": null, "status": "current", "flagship": false, "cited_by": [ "LI-04", "LI-06", "LI-07", "LI-09", "LI-10", "EV-01", "EV-02", "EV-03", "EV-04", "EV-05", "EV-07", "EV-08", "EV-09", "EV-10", "OA-01", "OA-02", "OA-03", "OA-05", "OA-07", "OA-08", "BH-03", "BH-05", "BH-09", "CR-01", "CR-02", "CR-03", "CR-04", "CR-05", "CR-06", "CR-07" ] }, { "id": "eu_ai_act_annex_iv", "title": "EU AI Act — Annex IV: Technical Documentation", "authority": "European Parliament and Council", "source_type": "regulation", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": null, "license": "public", "supersedes": null, "status": "current", "flagship": false, "cited_by": [ "TG-08" ] }, { "id": "eu_ai_act_art10", "title": "EU AI Act — Article 10: Data and Data Governance", "authority": "European Parliament and Council", "source_type": "regulation", "normative_force": "binding-law", "version": "2024", "published_on": "2024-08-01", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": null, "license": "public", "supersedes": null, "status": "current", "flagship": true, "cited_by": [ "TG-01", "TG-02", "TG-03", "TG-06", "TG-07" ] }, { "id": "gdm_fsf_v3_1", "title": "Frontier Safety Framework v3.1", "authority": "Google DeepMind", "source_type": "vendor-framework", "normative_force": "voluntary", "version": "3.1", "published_on": "2026-04-17", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": null, "license": "proprietary", "supersedes": [ "FSF v3.0" ], "status": "current", "flagship": false, "cited_by": [ "EV-03" ] }, { "id": "gdpr", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council", "source_type": "regulation", "normative_force": "binding-law", "version": "2016/679", "published_on": "2018-05-25", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": null, "license": "public", "supersedes": null, "status": "current", "flagship": true, "cited_by": [ "TG-03", "TG-06", "TG-08", "OA-08" ] }, { "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", "version": "2023", "published_on": "2023-12-18", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary-paid", "supersedes": null, "status": "current", "flagship": false, "cited_by": [ "LI-01", "LI-02", "LI-03", "LI-04", "LI-05", "LI-06", "LI-07", "LI-08", "LI-09", "LI-10", "TG-01", "TG-02", "TG-03", "TG-04", "TG-05", "TG-06", "TG-07", "TG-08", "EV-01", "EV-02", "EV-05", "EV-06", "EV-07", "EV-08", "EV-09", "EV-10", "OA-01", "OA-02", "OA-03", "OA-04", "OA-05", "OA-07", "BH-01", "BH-02", "BH-03", "BH-04", "BH-05", "BH-08", "BH-10" ] }, { "id": "iso_42005_2025", "title": "ISO/IEC 42005:2025 — Artificial Intelligence — AI system impact assessment", "authority": "ISO/IEC", "source_type": "certification-standard", "normative_force": "voluntary", "version": "2025", "published_on": "2025-05-01", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": null, "license": "commercial", "supersedes": null, "status": "current", "flagship": false, "cited_by": [ "EV-02", "EV-05", "EV-09" ] }, { "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": "informative", "version": "2019", "published_on": "2019-01-01", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": "https://arxiv.org/abs/1810.03993", "license": "CC BY 4.0", "supersedes": null, "status": "current", "flagship": true, "cited_by": [ "LI-04" ] }, { "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": "informative", "version": "5.6.0", "published_on": "2026-05-04", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": "https://atlas.mitre.org", "license": "Apache-2.0", "supersedes": null, "status": "current", "flagship": false, "cited_by": [ "LI-02", "LI-03", "TG-04", "TG-07", "EV-04", "OA-06", "BH-01", "BH-02", "BH-04", "BH-05", "BH-06", "BH-07", "BH-10", "CR-04" ] }, { "id": "nist_ai_100_4", "title": "NIST AI 100-4: Reducing Risks Posed by Synthetic Content", "authority": "NIST", "source_type": "supervisory-guidance", "normative_force": "voluntary", "version": "1.0", "published_on": null, "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": null, "license": "public_domain", "supersedes": null, "status": "current", "flagship": false, "cited_by": [ "BH-09" ] }, { "id": "nist_ai_600_1", "title": "NIST AI 600-1: Artificial Intelligence — Generative AI Profile", "authority": "NIST", "source_type": "voluntary-standard", "normative_force": "voluntary", "version": "1.0", "published_on": "2024-07-26", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": null, "license": "public-domain", "supersedes": null, "status": "current", "flagship": false, "cited_by": [ "EV-05", "EV-06" ] }, { "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", "version": "1.0", "published_on": "2023-01-26", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": "https://doi.org/10.6028/NIST.AI.100-1", "license": "public-domain", "supersedes": null, "status": "current", "flagship": true, "cited_by": [ "LI-01", "LI-02", "LI-03", "LI-04", "LI-05", "LI-06", "LI-07", "LI-08", "LI-09", "LI-10", "TG-01", "TG-02", "TG-04", "TG-05", "TG-06", "TG-07", "EV-01", "EV-02", "EV-04", "EV-05", "EV-06", "EV-07", "EV-08", "EV-09", "EV-10", "OA-01", "OA-02", "OA-03", "OA-04", "OA-06", "OA-07", "OA-08", "BH-01", "BH-02", "BH-03", "BH-04", "BH-05", "BH-06", "BH-07", "BH-08", "BH-09", "BH-10", "CR-01", "CR-03", "CR-04", "CR-06", "CR-07", "CR-08" ] }, { "id": "openai_preparedness_v2", "title": "OpenAI Preparedness Framework v2", "authority": "OpenAI", "source_type": "vendor-framework", "normative_force": "voluntary", "version": "2.0", "published_on": "2025-01-01", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": null, "license": "proprietary", "supersedes": [ "Preparedness Framework v1" ], "status": "current", "flagship": false, "cited_by": [ "EV-03" ] }, { "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", "version": "1.0", "published_on": "2026-06-24", "retrieved_on": "2026-06-26", "artifact_hash": "git:f2bade20a5255a2f023e770784bd7b3cf1ebb599", "canonical_url": "https://github.com/OWASP/www-project-ai-security-verification-standard", "license": "CC BY-SA 4.0", "supersedes": null, "status": "current", "flagship": false, "cited_by": [ "LI-01", "LI-02", "LI-05", "LI-07", "LI-08", "EV-04", "EV-06", "OA-08", "BH-01", "BH-04", "BH-06", "BH-07", "BH-10" ] }, { "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": "informative", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-26", "artifact_hash": null, "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, "cited_by": [ "LI-03", "TG-04", "TG-07", "EV-02", "EV-04", "EV-07", "OA-06", "OA-08", "BH-06", "BH-07", "BH-09", "BH-10" ] }, { "id": "sigstore_rekor", "title": "Sigstore Rekor — Immutable Transparency Log", "authority": "Sigstore Project (OpenSSF)", "source_type": "product-documentation", "normative_force": "informative", "version": "1.3.0", "published_on": "2024-01-15", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": "https://docs.sigstore.dev/rekor/overview/", "license": "apache-2.0", "supersedes": null, "status": "current", "flagship": false, "cited_by": [ "CR-02" ] }, { "id": "sr262_2026", "title": "SR 26-2: Supervisory Guidance on Model Risk Management", "authority": "Board of Governors of the Federal Reserve System", "source_type": "supervisory-guidance", "normative_force": "guidance", "version": "SR 26-2", "published_on": "2026-04-01", "retrieved_on": "2026-06-26", "artifact_hash": null, "canonical_url": "https://www.federalreserve.gov/supervisionreg/srletters/sr2602.htm", "license": "us-government-public-domain", "supersedes": "SR 11-7, SR 21-8", "status": "current", "flagship": false, "cited_by": [ "LI-01", "LI-04", "LI-05", "LI-06", "LI-09", "LI-10", "TG-02", "TG-03", "TG-05", "TG-07", "TG-08", "EV-01", "EV-07", "EV-08", "EV-09", "EV-10", "OA-01", "OA-03", "OA-05", "OA-06", "BH-02", "BH-03", "BH-05", "BH-08", "BH-10", "CR-01", "CR-02", "CR-03", "CR-04", "CR-05", "CR-07" ] } ], "layers": [ { "code": "LI", "name": "AI Asset, Lineage and Applicability", "plane": "control", "ordinal": 1, "description": "Controls governing unique model identity, provenance chains, supply-chain integrity, structured documentation, training data lineage, version management, risk classification, license obligations, system-level composition, and applicability determination.", "control_count": 10, "baseline_control_count": 3, "baseline_controls": [ "LI-01", "LI-04", "LI-06" ], "controls": [ "LI-01", "LI-02", "LI-03", "LI-04", "LI-05", "LI-06", "LI-07", "LI-08", "LI-09", "LI-10" ] }, { "code": "TG", "name": "Training and Data Governance", "plane": "data", "ordinal": 2, "description": "Controls governing dataset quality, documentation, provenance, data poisoning prevention, training/evaluation separation and contamination prevention, sensitive-data handling, and continuously-learning feedback-loop integrity.", "control_count": 8, "baseline_control_count": 2, "baseline_controls": [ "TG-01", "TG-05" ], "controls": [ "TG-01", "TG-02", "TG-03", "TG-04", "TG-05", "TG-06", "TG-07", "TG-08" ] }, { "code": "EV", "name": "Evaluation, Independent Validation and Release", "plane": "both", "ordinal": 3, "description": "Controls governing pre-release evaluation, fitness and safety assessment, dangerous capability assessment, adversarial red-team testing, fairness evaluation, reproducible evaluation design, regression testing, independent validation, impact and applicability classification, and evaluation evidence integrity.", "control_count": 10, "baseline_control_count": 4, "baseline_controls": [ "EV-01", "EV-06", "EV-07", "EV-09" ], "controls": [ "EV-01", "EV-02", "EV-03", "EV-04", "EV-05", "EV-06", "EV-07", "EV-08", "EV-09", "EV-10" ] }, { "code": "OA", "name": "Governance, Accountability and Use-Case Oversight", "plane": "control", "ordinal": 4, "description": "Controls governing named accountable ownership, human oversight adequacy, AI governance committee structure, autonomy and agency controls, model-use policy, incident decision authority, escalation paths, and notice and contestability mechanisms for affected parties.", "control_count": 8, "baseline_control_count": 2, "baseline_controls": [ "OA-01", "OA-07" ], "controls": [ "OA-01", "OA-02", "OA-03", "OA-04", "OA-05", "OA-06", "OA-07", "OA-08" ] }, { "code": "BH", "name": "Deployment and Runtime Assurance", "plane": "data", "ordinal": 5, "description": "Controls governing deployment authorization, input distribution monitoring, production performance monitoring, behavioral boundary enforcement, audit logging, immutable rollback capability, rate and cost controls, feedback-loop integrity, synthetic content provenance, and provider change monitoring.", "control_count": 10, "baseline_control_count": 2, "baseline_controls": [ "BH-03", "BH-05" ], "controls": [ "BH-01", "BH-02", "BH-03", "BH-04", "BH-05", "BH-06", "BH-07", "BH-08", "BH-09", "BH-10" ] }, { "code": "CR", "name": "Continuous Risk, Incident and Evidence Assurance", "plane": "lifecycle", "ordinal": 6, "description": "Controls governing periodic and event-driven re-evaluation, incident investigation and corrective action, material-change determination, outcomes and disparate-impact analysis, long-term evidence integrity, continuous risk monitoring, model decommissioning, and cross-domain compliance evidence.", "control_count": 8, "baseline_control_count": 2, "baseline_controls": [ "CR-01", "CR-02" ], "controls": [ "CR-01", "CR-02", "CR-03", "CR-04", "CR-05", "CR-06", "CR-07", "CR-08" ] } ], "planes": [ { "id": "control", "name": "Control Plane", "description": "Governs identity, documentation, governance policies, accountability assignments, and assurance state. These controls define what the system is and who is responsible for it.", "layers": [ "LI", "OA" ], "control_count": 18, "controls": [ "LI-01", "LI-02", "LI-03", "LI-04", "LI-05", "LI-06", "LI-07", "LI-08", "LI-09", "LI-10", "OA-01", "OA-02", "OA-03", "OA-04", "OA-05", "OA-06", "OA-07", "OA-08" ] }, { "id": "data", "name": "Data Plane", "description": "Governs what flows into and out of the model — training data, runtime inputs, inference outputs, and behavioral signals. Controls prevent data poisoning, monitor drift, enforce logging, and protect runtime integrity.", "layers": [ "TG", "BH" ], "control_count": 18, "controls": [ "TG-01", "TG-02", "TG-03", "TG-04", "TG-05", "TG-06", "TG-07", "TG-08", "BH-01", "BH-02", "BH-03", "BH-04", "BH-05", "BH-06", "BH-07", "BH-08", "BH-09", "BH-10" ] }, { "id": "both", "name": "Control and Data Plane", "description": "Controls that span both the control plane (governance of evaluation decisions, release authorization) and the data plane (measurement of model behavior, evaluation datasets). EV controls gate release and produce evidence consumed by both planes.", "layers": [ "EV" ], "control_count": 10, "controls": [ "EV-01", "EV-02", "EV-03", "EV-04", "EV-05", "EV-06", "EV-07", "EV-08", "EV-09", "EV-10" ] }, { "id": "lifecycle", "name": "Lifecycle Plane", "description": "Governs the ongoing assurance lifecycle: periodic re-evaluation, incident response, corrective action, evidence validity, and decommissioning. These controls are event-driven rather than deployment-point controls.", "layers": [ "CR" ], "control_count": 8, "controls": [ "CR-01", "CR-02", "CR-03", "CR-04", "CR-05", "CR-06", "CR-07", "CR-08" ] } ], "gaps": [ { "control_id": "LI-01", "control_name": "Unique Model Identity and Content-Addressed Version Hash", "layer": "LI", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.2", "fit": "partial", "uncovered_portion": "GOVERN-1.2 addresses the full accountability policy lifecycle including roles, responsibilities, and escalation paths; LI-01 covers only the artifact identity and integrity mechanism." }, { "framework": "mitre", "requirement_id": "AML.T0044", "fit": "partial", "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." } ] }, { "control_id": "LI-02", "control_name": "Model Provenance Chain — Base Model, Fine-Tune, Merge, and Adapter Lineage", "layer": "LI", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MAP-1.5", "fit": "partial", "uncovered_portion": "MAP-1.5 addresses the full risk identification scope including intended use context and organizational risk tolerance; LI-02 covers only artifact lineage traceability." }, { "framework": "mitre", "requirement_id": "AML.T0018", "fit": "partial", "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." } ] }, { "control_id": "LI-03", "control_name": "Supply Chain Integrity — Third-Party Model Verification and Cryptographic...", "layer": "LI", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MAP-1.6", "fit": "partial", "uncovered_portion": "MAP-1.6 addresses vendor selection, contractual terms, and supply chain risk policies beyond artifact-level verification." }, { "framework": "iso_42001", "requirement_id": "A.6.1", "fit": "partial", "uncovered_portion": "A.6.1 covers the full AI system component lifecycle; LI-03 addresses only the artifact acquisition and verification phase." }, { "framework": "mitre", "requirement_id": "AML.T0018", "fit": "partial", "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." }, { "framework": "owasp_aitg", "requirement_id": "AITG-GV-01", "fit": "partial", "uncovered_portion": "AITG-GV-01 addresses identity and versioning of the model artifact itself; third-party supply-chain verification procedures including mSBOM generation and publisher-signed checksum workflows exceed what the test prescribes." } ] }, { "control_id": "LI-04", "control_name": "Structured Model Documentation — Complete Model Card with All Required Sections", "layer": "LI", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.1", "fit": "partial", "uncovered_portion": "GOVERN-1.1 includes policy governance structures, leadership accountability, and organizational AI risk culture beyond model-level documentation." }, { "framework": "iso_42001", "requirement_id": "A.6.2", "fit": "partial", "uncovered_portion": "A.6.2 additionally addresses documentation governance, document control procedures, version approval workflows, and distribution controls beyond model card content requirements." }, { "framework": "mitre", "requirement_id": "AML.T0044", "fit": "adjacent", "uncovered_portion": null, "note": "MITRE ATLAS AML.T0044 (Full ML Model Access) is tangentially related to model documentation in that documented model characteristics reduce information asymmetry that adversaries exploit when probing " } ] }, { "control_id": "LI-05", "control_name": "Training Data Lineage Pointer — Link from Model Registry to TG-Layer Dataset...", "layer": "LI", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MAP-2.1", "fit": "partial", "uncovered_portion": "MAP-2.1 addresses broader contextual understanding of AI system inputs including deployment context and data representativeness; LI-05 covers only the registry linkage mechanism." }, { "framework": "iso_42001", "requirement_id": "A.6.2", "fit": "partial", "uncovered_portion": "A.6.2 covers the full development record; LI-05 addresses only the data-linkage component." }, { "framework": "mitre", "requirement_id": "AML.T0020", "fit": "adjacent", "uncovered_portion": null, "note": "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 contamin" } ] }, { "control_id": "LI-06", "control_name": "Immutable Version Control with Tested Rollback and Emergency Disable", "layer": "LI", "gaps": [ { "framework": "eu_ai_act", "requirement_id": "Art-12", "fit": "partial", "uncovered_portion": "Art-12 specifies logging content requirements (inputs, outputs, period) beyond version transition records; inference-level logging is addressed in BH-05." }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "partial", "uncovered_portion": "S-5.1 also covers outcomes analysis and behavioral drift monitoring beyond artifact-hash monitoring; those are addressed in BH-03 and CR-01." }, { "framework": "mitre", "requirement_id": "AML.T0044", "fit": "partial", "uncovered_portion": "AML.T0044 full mitigation requires access control to the model registry and serving infrastructure — cross-domain security responsibility." } ] }, { "control_id": "LI-07", "control_name": "Capability and Limitation Declaration — Intended Use, Constraints,...", "layer": "LI", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.5", "fit": "partial", "uncovered_portion": "GOVERN-1.5 addresses the establishment of risk tolerance policies and governance structures; LI-07 provides the model-level information that informs those policies." }, { "framework": "iso_42001", "requirement_id": "A.6.1", "fit": "partial", "uncovered_portion": "A.6.1 covers the full lifecycle management scope including monitoring and end-of-life; LI-07 covers only the capability and limitation declaration at the design and release phase." }, { "framework": "llm10", "requirement_id": "LLM09:2025", "fit": "partial", "uncovered_portion": "LLM09:2025 encompasses active misinformation detection, grounding controls, and evaluation of factual accuracy beyond the transparency declaration that LI-07 provides." } ] }, { "control_id": "LI-08", "control_name": "License and IP Governance — Dataset License Tracking, Derivative Work...", "layer": "LI", "gaps": [ { "framework": "llm10", "requirement_id": "LLM03:2025", "fit": "adjacent", "uncovered_portion": null, "note": "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 LL" } ] }, { "control_id": "LI-09", "control_name": "Material-Change Determination and Authorization Gate", "layer": "LI", "gaps": [ { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "partial", "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." } ] }, { "control_id": "LI-10", "control_name": "Model Retirement and Archive Policy — End-of-Life Procedure, Evidence...", "layer": "LI", "gaps": [ { "framework": "iso_42001", "requirement_id": "A.8.1", "fit": "partial", "uncovered_portion": "A.8.1 covers ongoing operational management including monitoring and incident response beyond the retirement phase addressed by LI-10." }, { "framework": "sr262", "requirement_id": "S-4.1", "fit": "partial", "uncovered_portion": "S-4.1 addresses model governance broadly including development and validation oversight; LI-10 covers only the retirement phase." }, { "framework": "eu_ai_act", "requirement_id": "Art-12", "fit": "partial", "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." }, { "framework": "owasp_aitg", "requirement_id": "AITG-RT-08", "fit": "adjacent", "uncovered_portion": "AITG-RT-08 requires active monitoring for changes to AI providers and upstream supply-chain components in the production runtime; LI-10 addresses model retirement governance and evidence archiving at end-of-life, which is a distinct lifecycle concern in the same supply-chain domain.", "note": "LI-10 governs model retirement at the registry level — requiring authorized retirement decisions, evidence archiving, and dependency impact assessment before decommissioning — addressing the same supp" } ] }, { "control_id": "TG-01", "control_name": "Training Data Quality Gates", "layer": "TG", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MAP-2.2", "fit": "partial", "uncovered_portion": "NIST also addresses impact assessment of data quality failures on downstream stakeholders" }, { "framework": "eu_ai_act", "requirement_id": "Art-10", "fit": "partial", "uncovered_portion": "Art. 10(3) examination for biases is covered by TG-02" }, { "framework": "llm10", "requirement_id": "LLM04:2025", "fit": "partial", "uncovered_portion": "Active adversarial poisoning detection is addressed in TG-04" }, { "framework": "mitre", "requirement_id": "AML.T0020", "fit": "partial", "uncovered_portion": "Cryptographic integrity of individual shards is covered in TG-04" } ] }, { "control_id": "TG-02", "control_name": "Bias and Representativeness Assessment", "layer": "TG", "gaps": [ { "framework": "iso_42001", "requirement_id": "8.4", "fit": "partial", "uncovered_portion": "ISO 42001 §8.4 addresses the full data management lifecycle including acquisition, labeling, storage, access controls, and retirement — this control covers one aspect of that requirement." }, { "framework": "sr262", "requirement_id": "S-1.1", "fit": "partial", "uncovered_portion": "SR 26-2 S-1.1 additionally requires model inventory governance, ownership assignment, business unit mapping, and periodic inventory reconciliation beyond unique model identification." }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "partial", "uncovered_portion": "AISVS C5.1 covers the full data security and privacy lifecycle including storage encryption, access controls, data subject rights, and retention — this control addresses one aspect." }, { "framework": "llm10", "requirement_id": "LLM04:2025", "fit": "partial", "uncovered_portion": "LLM04:2025 Data and Model Poisoning additionally covers fine-tuning data poisoning, reward model manipulation, and inference-time retrieval corpus poisoning." }, { "framework": "mitre", "requirement_id": "AML.T0020", "fit": "partial", "uncovered_portion": "Active poisoning detection is TG-04" }, { "framework": "owasp_aitg", "requirement_id": "AITG-DG-01", "fit": "partial", "uncovered_portion": "AITG-DG-01 addresses data quality and provenance validation; bias and representativeness assessment of training data subgroups extends beyond the quality-gate and provenance-chain checks defined in the test." } ] }, { "control_id": "TG-03", "control_name": "Data Rights, Lawful Authority and Permitted Use", "layer": "TG", "gaps": [ { "framework": "iso_42001", "requirement_id": "8.4", "fit": "partial", "uncovered_portion": "ISO 42001 §8.4 addresses the full data management lifecycle including acquisition, labeling, storage, access controls, and retirement — this control covers one aspect of that requirement." }, { "framework": "eu_ai_act", "requirement_id": "Art-10", "fit": "partial", "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." }, { "framework": "sr262", "requirement_id": "S-5.2", "fit": "partial", "uncovered_portion": "SR 26-2 S-5.2 addresses the full data governance program including data quality policies, data stewardship roles, access controls, and retention schedules — this control covers one aspect." }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "partial", "uncovered_portion": "AISVS C5.1 covers the full data security and privacy lifecycle including storage encryption, access controls, data subject rights, and retention — this control addresses one aspect." }, { "framework": "llm10", "requirement_id": "LLM03:2025", "fit": "partial", "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." }, { "framework": "mitre", "requirement_id": "AML.T0018", "fit": "partial", "uncovered_portion": "Active supply chain integrity checks are in TG-04 and TG-07" }, { "framework": "nist_ai_600_1", "requirement_id": "DATA-PRIVACY", "fit": "partial", "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." } ] }, { "control_id": "TG-04", "control_name": "Data Poisoning Prevention", "layer": "TG", "gaps": [ { "framework": "iso_42001", "requirement_id": "8.4", "fit": "partial", "uncovered_portion": "ISO 42001 §8.4 addresses the full data management lifecycle including acquisition, labeling, storage, access controls, and retirement — this control covers one aspect of that requirement." }, { "framework": "eu_ai_act", "requirement_id": "Art-10", "fit": "partial", "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." }, { "framework": "sr262", "requirement_id": "S-5.2", "fit": "partial", "uncovered_portion": "SR 26-2 S-5.2 addresses the full data governance program including data quality policies, data stewardship roles, access controls, and retention schedules — this control covers one aspect." }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "partial", "uncovered_portion": "AISVS C5.1 covers the full data security and privacy lifecycle including storage encryption, access controls, data subject rights, and retention — this control addresses one aspect." }, { "framework": "llm10", "requirement_id": "LLM04:2025", "fit": "partial", "uncovered_portion": "Model weight poisoning addressed in BH-03" }, { "framework": "mitre", "requirement_id": "AML.T0020", "fit": "partial", "uncovered_portion": "Inference API exfiltration (AML.T0024) is addressed in BH layer" }, { "framework": "owasp_aitg", "requirement_id": "AITG-ME-04", "fit": "partial", "uncovered_portion": "AITG-ME-04 covers adversarial robustness testing on the deployed model; data poisoning prevention at training time addresses the upstream threat source rather than the adversarial probe suite the test defines for production models." } ] }, { "control_id": "TG-05", "control_name": "Train/Evaluation/Test Separation and Contamination Prevention", "layer": "TG", "gaps": [ { "framework": "iso_42001", "requirement_id": "8.4", "fit": "partial", "uncovered_portion": "ISO 42001 §8.4 addresses the full data management lifecycle including acquisition, labeling, storage, access controls, and retirement — this control covers one aspect of that requirement." }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "partial", "uncovered_portion": "AISVS C5.1 covers the full data security and privacy lifecycle including storage encryption, access controls, data subject rights, and retention — this control addresses one aspect." }, { "framework": "mitre", "requirement_id": "AML.T0020", "fit": "partial", "uncovered_portion": "Active poisoning attack detection is TG-04" } ] }, { "control_id": "TG-06", "control_name": "Sensitive-Data Necessity, Minimization and Controlled Use", "layer": "TG", "gaps": [ { "framework": "iso_42001", "requirement_id": "8.4", "fit": "partial", "uncovered_portion": "ISO 42001 §8.4 addresses the full data management lifecycle including acquisition, labeling, storage, access controls, and retirement — this control covers one aspect of that requirement." }, { "framework": "eu_ai_act", "requirement_id": "Art-10", "fit": "partial", "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." }, { "framework": "sr262", "requirement_id": "S-5.2", "fit": "partial", "uncovered_portion": "SR 26-2 S-5.2 addresses the full data governance program including data quality policies, data stewardship roles, access controls, and retention schedules — this control covers one aspect." }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "partial", "uncovered_portion": "AISVS C5.1 covers the full data security and privacy lifecycle including storage encryption, access controls, data subject rights, and retention — this control addresses one aspect." }, { "framework": "llm10", "requirement_id": "LLM04:2025", "fit": "partial", "uncovered_portion": "LLM04:2025 Data and Model Poisoning additionally covers fine-tuning data poisoning, reward model manipulation, and inference-time retrieval corpus poisoning." }, { "framework": "mitre", "requirement_id": "AML.T0024", "fit": "partial", "uncovered_portion": "Runtime exfiltration controls addressed in BH layer" } ] }, { "control_id": "TG-07", "control_name": "Third-Party Dataset Governance", "layer": "TG", "gaps": [ { "framework": "iso_42001", "requirement_id": "8.4", "fit": "partial", "uncovered_portion": "ISO 42001 §8.4 addresses the full data management lifecycle including acquisition, labeling, storage, access controls, and retirement — this control covers one aspect of that requirement." }, { "framework": "eu_ai_act", "requirement_id": "Art-10", "fit": "partial", "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." }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "partial", "uncovered_portion": "AISVS C5.1 covers the full data security and privacy lifecycle including storage encryption, access controls, data subject rights, and retention — this control addresses one aspect." }, { "framework": "llm10", "requirement_id": "LLM03:2025", "fit": "partial", "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." }, { "framework": "mitre", "requirement_id": "AML.T0018", "fit": "partial", "uncovered_portion": "Model supply chain compromise (foundation models) is addressed in LI layer" }, { "framework": "owasp_aitg", "requirement_id": "AITG-DG-01", "fit": "partial", "uncovered_portion": "AITG-DG-01 defines data quality and provenance checks for training datasets; third-party data supply chain verification including vendor checksum and contractual due-diligence procedures go beyond the dataset-level provenance validation in the test." } ] }, { "control_id": "TG-08", "control_name": "Dataset Retention, Deletion and Lifecycle", "layer": "TG", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-2.2", "fit": "partial", "uncovered_portion": "GOVERN-2.2 additionally addresses organizational data governance policies, roles, accountability structures, and data stewardship practices beyond the scope of this control." }, { "framework": "iso_42001", "requirement_id": "8.4", "fit": "partial", "uncovered_portion": "ISO 42001 §8.4 addresses the full data management lifecycle including acquisition, labeling, storage, access controls, and retirement — this control covers one aspect of that requirement." }, { "framework": "eu_ai_act", "requirement_id": "Art-10", "fit": "partial", "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." }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "partial", "uncovered_portion": "AISVS C5.1 covers the full data security and privacy lifecycle including storage encryption, access controls, data subject rights, and retention — this control addresses one aspect." }, { "framework": "llm10", "requirement_id": "LLM04:2025", "fit": "partial", "uncovered_portion": "LLM04:2025 Data and Model Poisoning additionally covers fine-tuning data poisoning, reward model manipulation, and inference-time retrieval corpus poisoning." } ] }, { "control_id": "EV-01", "control_name": "Pre-Deployment Evaluation Gate", "layer": "EV", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.1", "fit": "partial", "uncovered_portion": "NIST AI RMF does not specify technical gate enforcement mechanisms or cryptographic signing of evaluation records." }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "uncovered_portion": "ISO 42001 does not mandate cryptographic signing or tamper-evident storage of evaluation records." }, { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "partial", "uncovered_portion": "EU AI Act does not specify pipeline-level technical enforcement or signing requirements." }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "partial", "uncovered_portion": "SR 26-2 applies to $30B+ asset institutions; sub-threshold entities have no binding equivalent." }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "partial", "uncovered_portion": "AISVS v1.0 does not mandate signed evaluation manifests or tamper-evident storage." }, { "framework": "llm10", "requirement_id": "LLM10:2025", "fit": "adjacent", "uncovered_portion": null, "note": "OWASP LLM Top 10 2025 addresses runtime threat categories, not deployment gate processes." }, { "framework": "aicm", "requirement_id": "GRC-01", "fit": "partial", "uncovered_portion": "AICM does not specify technical gate enforcement or signing requirements." }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "uncovered_portion": null, "note": "MITRE ATLAS v5.6.0 addresses adversarial ML attack tactics, not deployment gate governance processes." } ] }, { "control_id": "EV-02", "control_name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "layer": "EV", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.1", "fit": "partial", "uncovered_portion": "NIST AI RMF does not specify dimension isolation requirements or threshold pre-specification." }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "uncovered_portion": "ISO 42001 does not specify generative-AI-specific evaluation dimensions." }, { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "partial", "uncovered_portion": "EU AI Act does not prescribe specific evaluation datasets or dimension isolation methodology." }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "partial", "uncovered_portion": "SR 26-2 predates generative AI and does not address refusal/alignment evaluation." }, { "framework": "aisvs", "requirement_id": "C7.1", "fit": "partial", "uncovered_portion": "AISVS does not mandate pre-specified thresholds or dimension isolation." }, { "framework": "llm10", "requirement_id": "LLM09:2025", "fit": "partial", "uncovered_portion": "LLM Top 10 does not address structured pre-deployment evaluation protocol design." }, { "framework": "aicm", "requirement_id": "A&A-02", "fit": "partial", "uncovered_portion": "AICM does not specify dimension isolation or pre-specified threshold requirements." }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "uncovered_portion": null, "note": "MITRE ATLAS v5.6.0 addresses adversarial ML attack tactics; pre-deployment fitness/safety evaluation is not an adversarial threat category." } ] }, { "control_id": "EV-03", "control_name": "Dangerous Capability Threshold Assessment", "layer": "EV", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-6.1", "fit": "partial", "uncovered_portion": "NIST AI RMF 1.0 predates frontier dangerous capability assessment methodology; it does not provide threshold definitions." }, { "framework": "iso_42001", "requirement_id": "6.1", "fit": "partial", "uncovered_portion": "ISO 42001 does not define dangerous capability domains or threshold frameworks." }, { "framework": "eu_ai_act", "requirement_id": "Art-51", "fit": "partial", "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." }, { "framework": "sr262", "requirement_id": "S-1.1", "fit": "adjacent", "uncovered_portion": null, "note": "SR 26-2 model risk management guidance does not address frontier AI dangerous capability assessment." }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "adjacent", "uncovered_portion": null, "note": "AISVS v1.0 does not address dangerous capability threshold assessment for frontier models." }, { "framework": "llm10", "requirement_id": "LLM10:2025", "fit": "adjacent", "uncovered_portion": null, "note": "OWASP LLM Top 10 2025 addresses application-layer risks, not frontier model dangerous capability assessment." }, { "framework": "aicm", "requirement_id": "A&A-02", "fit": "adjacent", "uncovered_portion": null, "note": "AI Control Matrix does not currently include frontier dangerous capability assessment controls." }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "uncovered_portion": "N/A — no false mapping applied.", "note": "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 assuranc" } ] }, { "control_id": "EV-04", "control_name": "Adversarial Red-Team Testing", "layer": "EV", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.6", "fit": "partial", "uncovered_portion": "NIST AI RMF does not specify red-team team composition independence requirements." }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "uncovered_portion": "ISO 42001 does not mandate adversarial red-teaming or specify threat model requirements." }, { "framework": "eu_ai_act", "requirement_id": "Art-55", "fit": "partial", "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." }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "partial", "uncovered_portion": "SR 26-2 does not address LLM-specific adversarial testing methodology." }, { "framework": "aisvs", "requirement_id": "C5.1", "fit": "partial", "uncovered_portion": "AISVS does not specify red-team team independence requirements or report signing." }, { "framework": "llm10", "requirement_id": "LLM01:2025", "fit": "partial", "uncovered_portion": "LLM Top 10 2025 describes threat categories but does not specify red-team methodology or independence requirements." }, { "framework": "aicm", "requirement_id": "TVM-07", "fit": "partial", "uncovered_portion": "AICM does not specify threat model documentation or deployment gate integration." }, { "framework": "mitre", "requirement_id": "AML.T0051", "fit": "partial", "uncovered_portion": "MITRE ATLAS describes attack techniques; it does not specify evaluation methodology for pre-deployment red-teaming." }, { "framework": "nist_ai_600_1", "requirement_id": "INFO-SECURITY", "fit": "partial", "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." } ] }, { "control_id": "EV-05", "control_name": "Fairness and Bias Evaluation", "layer": "EV", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.5", "fit": "partial", "uncovered_portion": "NIST AI RMF does not mandate pre-specification of fairness thresholds or legal review for protected characteristic decisions." }, { "framework": "iso_42001", "requirement_id": "6.1.2", "fit": "partial", "uncovered_portion": "ISO 42001 does not prescribe fairness metric selection methodology." }, { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "partial", "uncovered_portion": "EU AI Act does not specify which fairness metrics satisfy Art. 9(7); metric selection remains implementation-defined." }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "partial", "uncovered_portion": "SR 26-2 predates comprehensive fairness evaluation methodology for AI systems." }, { "framework": "aisvs", "requirement_id": "C7.1", "fit": "partial", "uncovered_portion": "AISVS does not mandate legal review for protected characteristic decisions." }, { "framework": "llm10", "requirement_id": "LLM09:2025", "fit": "partial", "uncovered_portion": "LLM Top 10 2025 does not address structured fairness evaluation methodology." }, { "framework": "aicm", "requirement_id": "GRC-11", "fit": "partial", "uncovered_portion": "AICM does not specify pre-specification of thresholds or metric trade-off documentation requirements." }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "uncovered_portion": null, "note": "MITRE ATLAS v5.6.0 does not address fairness and bias evaluation methodology." }, { "framework": "nist_ai_600_1", "requirement_id": "HUMAN-AI-CONFIG", "fit": "partial", "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." } ] }, { "control_id": "EV-06", "control_name": "Reproducible Evaluation Design", "layer": "EV", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.1", "fit": "partial", "uncovered_portion": "NIST AI RMF does not specify contamination screening or artifact signing requirements." }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "uncovered_portion": "ISO 42001 does not mandate contamination screening or independent reproduction testing." }, { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "partial", "uncovered_portion": "EU AI Act does not specify benchmark contamination screening or reproduction testing." }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "partial", "uncovered_portion": "SR 26-2 does not address benchmark contamination or AI-specific reproducibility requirements." }, { "framework": "aisvs", "requirement_id": "C7.1", "fit": "partial", "uncovered_portion": "AISVS does not mandate independent reproduction testing or contamination screening methodology." }, { "framework": "llm10", "requirement_id": "LLM10:2025", "fit": "adjacent", "uncovered_portion": null, "note": "OWASP LLM Top 10 2025 does not address evaluation reproducibility or benchmark contamination." }, { "framework": "aicm", "requirement_id": "MDS-05", "fit": "partial", "uncovered_portion": "AICM does not specify contamination screening or artifact signing." }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "uncovered_portion": null, "note": "MITRE ATLAS v5.6.0 does not address evaluation reproducibility or benchmark integrity." } ] }, { "control_id": "EV-07", "control_name": "Regression Testing on Updates", "layer": "EV", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MANAGE-2.4", "fit": "partial", "uncovered_portion": "NIST AI RMF does not specify zero-tolerance thresholds for safety regression or monitoring schema structure." }, { "framework": "iso_42001", "requirement_id": "10.1", "fit": "partial", "uncovered_portion": "ISO 42001 does not specify regression suite structure or safety regression zero-tolerance policy." }, { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "partial", "uncovered_portion": "EU AI Act does not specify regression suite design or monitoring schema." }, { "framework": "sr262", "requirement_id": "S-4.1", "fit": "partial", "uncovered_portion": "SR 26-2 does not address generative-AI-specific regression categories (alignment drift, refusal rate delta)." }, { "framework": "aisvs", "requirement_id": "C7.1", "fit": "partial", "uncovered_portion": "AISVS does not specify zero-tolerance safety regression policy or monitoring schema structure." }, { "framework": "llm10", "requirement_id": "LLM04:2025", "fit": "partial", "uncovered_portion": "LLM Top 10 2025 does not address regression testing methodology or update-triggered evaluation." }, { "framework": "aicm", "requirement_id": "CCC-02", "fit": "partial", "uncovered_portion": "AICM does not specify monitoring schema structure or safety regression zero-tolerance policy." }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "uncovered_portion": null, "note": "MITRE ATLAS v5.6.0 addresses adversarial attack techniques; regression testing on model updates is not an adversarial threat category." } ] }, { "control_id": "EV-08", "control_name": "Independent Validation", "layer": "EV", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.7", "fit": "partial", "uncovered_portion": "NIST AI RMF does not specify the organizational structure required for effective independence." }, { "framework": "iso_42001", "requirement_id": "9.2", "fit": "partial", "uncovered_portion": "ISO 42001 internal audit requirements are process-level; model-level validation independence requires additional policy." }, { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "partial", "uncovered_portion": "EU AI Act does not explicitly mandate model-level validation independence equivalent to SR 26-2 effective challenge." }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "partial", "uncovered_portion": "SR 26-2 applies to $30B+ asset institutions; sub-threshold entities have no binding equivalent though the principle is best practice." }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "partial", "uncovered_portion": "AISVS does not specify organizational independence requirements equivalent to SR 26-2 effective challenge." }, { "framework": "llm10", "requirement_id": "LLM10:2025", "fit": "adjacent", "uncovered_portion": null, "note": "OWASP LLM Top 10 2025 does not address validation independence or organizational separation of duties." }, { "framework": "aicm", "requirement_id": "MDS-03", "fit": "partial", "uncovered_portion": "AICM does not specify the organizational depth of independence required for effective challenge." }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "uncovered_portion": null, "note": "MITRE ATLAS v5.6.0 does not address organizational separation of duties for model validation." } ] }, { "control_id": "EV-09", "control_name": "Risk and Applicability Classification", "layer": "EV", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.2", "fit": "partial", "uncovered_portion": "NIST AI RMF does not provide a classification schema aligned with EU AI Act or SR 26-2 tier definitions." }, { "framework": "iso_42001", "requirement_id": "6.1", "fit": "partial", "uncovered_portion": "ISO 42001 does not specify a multi-framework classification schema (EU AI Act + SR 26-2 + capability tier)." }, { "framework": "eu_ai_act", "requirement_id": "Art-6", "fit": "partial", "uncovered_portion": "EU AI Act does not specify how to integrate EU classification with non-EU frameworks (SR 26-2, capability tiers)." }, { "framework": "sr262", "requirement_id": "S-1.1", "fit": "partial", "uncovered_portion": "SR 26-2 tiering criteria predate generative AI capability categories and do not address GPAI systemic risk classification." }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "partial", "uncovered_portion": "AISVS does not specify a multi-framework classification schema." }, { "framework": "llm10", "requirement_id": "LLM10:2025", "fit": "adjacent", "uncovered_portion": null, "note": "OWASP LLM Top 10 2025 does not address risk classification or regulatory categorization." }, { "framework": "aicm", "requirement_id": "GRC-10", "fit": "partial", "uncovered_portion": "AICM does not specify EU AI Act Article 6 / Annex III classification methodology." }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "uncovered_portion": null, "note": "MITRE ATLAS v5.6.0 does not address risk classification or regulatory categorization." } ] }, { "control_id": "EV-10", "control_name": "Evaluation Result Provenance", "layer": "EV", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.6", "fit": "partial", "uncovered_portion": "NIST AI RMF does not specify tamper-evident log requirements or provenance chain traversal tooling." }, { "framework": "iso_42001", "requirement_id": "7.5", "fit": "partial", "uncovered_portion": "ISO 42001 does not specify content-addressing or tamper-evident log requirements." }, { "framework": "eu_ai_act", "requirement_id": "Art-12", "fit": "partial", "uncovered_portion": "EU AI Act does not specify tamper-evident log technology requirements." }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "partial", "uncovered_portion": "SR 26-2 does not specify tamper-evident storage or content-addressing for validation records." }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "partial", "uncovered_portion": "AISVS does not specify content-addressing, tamper-evident logs, or provenance chain traversal tooling." }, { "framework": "llm10", "requirement_id": "LLM10:2025", "fit": "adjacent", "uncovered_portion": null, "note": "OWASP LLM Top 10 2025 does not address evaluation result provenance or tamper-evident record-keeping." }, { "framework": "aicm", "requirement_id": "A&A-04", "fit": "partial", "uncovered_portion": "AICM does not specify tamper-evident log technology or provenance chain traversal tooling." }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "adjacent", "uncovered_portion": null, "note": "MITRE ATLAS v5.6.0 does not address evaluation result provenance or record-keeping integrity." }, { "framework": "owasp_aitg", "requirement_id": "AITG-IR-05", "fit": "partial", "uncovered_portion": "AITG-IR-05 focuses on audit trail and evidence integrity verification for post-incident investigation; evaluation evidence integrity as a gate-keeping mechanism before model release addresses the prospective assurance chain rather than the retrospective audit-trail preservation that IR-05 defines." } ] }, { "control_id": "OA-01", "control_name": "Model Ownership Assignment", "layer": "OA", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.1", "fit": "partial", "uncovered_portion": "Does not address organizational culture or incentive alignment." }, { "framework": "iso_42001", "requirement_id": "5.3", "fit": "partial", "uncovered_portion": "Competence requirements covered separately in OA-03." }, { "framework": "eu_ai_act", "requirement_id": "Art-16", "fit": "partial", "uncovered_portion": "Conformity assessment obligations covered in OA-05." }, { "framework": "sr262", "requirement_id": "S-1.1", "fit": "partial", "uncovered_portion": "Validation independence requirements covered in EV layer." } ] }, { "control_id": "OA-02", "control_name": "Meaningful Human Oversight for High-Stakes Decisions", "layer": "OA", "gaps": [ { "framework": "eu_ai_act", "requirement_id": "Art-14", "fit": "partial", "uncovered_portion": "Art-14(4) self-monitoring provisions require additional instrumentation addressed in CR layer." }, { "framework": "nist_rmf", "requirement_id": "GOVERN-1.3", "fit": "partial", "uncovered_portion": "None significant." }, { "framework": "iso_42001", "requirement_id": "6.1.2", "fit": "partial", "uncovered_portion": "None significant for this control." }, { "framework": "sr262", "requirement_id": "S-1.1", "fit": "partial", "uncovered_portion": "None significant." } ] }, { "control_id": "OA-03", "control_name": "AI Model Governance Committee", "layer": "OA", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.1", "fit": "partial", "uncovered_portion": "None significant." }, { "framework": "iso_42001", "requirement_id": "5.1", "fit": "partial", "uncovered_portion": "None significant." }, { "framework": "sr262", "requirement_id": "S-1.1", "fit": "partial", "uncovered_portion": "SR 26-2 validation independence requirements addressed in EV layer." }, { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "partial", "uncovered_portion": "Technical documentation requirements addressed in LI layer." } ] }, { "control_id": "OA-04", "control_name": "Delegated Autonomy Tier Governance", "layer": "OA", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.2", "fit": "partial", "uncovered_portion": "Technical enforcement controls addressed in Security Verifier domain." }, { "framework": "iso_42001", "requirement_id": "6.1.2", "fit": "partial", "uncovered_portion": "None significant for the governance aspect of tier management." } ] }, { "control_id": "OA-05", "control_name": "Regulatory and Legal Review Sign-Off", "layer": "OA", "gaps": [ { "framework": "eu_ai_act", "requirement_id": "Art-9", "fit": "partial", "uncovered_portion": "Post-market monitoring obligations addressed in CR layer." }, { "framework": "sr262", "requirement_id": "S-2.1", "fit": "partial", "uncovered_portion": "Ongoing monitoring and annual validation requirements addressed in CR layer." }, { "framework": "iso_42001", "requirement_id": "8.1", "fit": "partial", "uncovered_portion": "None significant." }, { "framework": "nist_rmf", "requirement_id": "GOVERN-1.3", "fit": "partial", "uncovered_portion": "None significant." }, { "framework": "owasp_aitg", "requirement_id": "AITG-GV-04", "fit": "partial", "uncovered_portion": "AITG-GV-04 defines use-case risk classification and policy requirements; a deployed model use policy that specifies permitted and prohibited use patterns is a downstream governance artifact that goes beyond the classification and risk-tier assignment the test validates." } ] }, { "control_id": "OA-06", "control_name": "Third-Party Model and Vendor Risk Oversight", "layer": "OA", "gaps": [ { "framework": "llm10", "requirement_id": "LLM10:2025", "fit": "partial", "uncovered_portion": "Technical supply chain artifact verification addressed in TG layer." }, { "framework": "mitre", "requirement_id": "AML.T0043", "fit": "partial", "uncovered_portion": "Technical artifact integrity checks addressed in TG layer." }, { "framework": "sr262", "requirement_id": "S-4.1", "fit": "partial", "uncovered_portion": "None significant." }, { "framework": "nist_rmf", "requirement_id": "GOVERN-1.5", "fit": "partial", "uncovered_portion": "None significant." }, { "framework": "iso_42001", "requirement_id": "8.1", "fit": "partial", "uncovered_portion": "Clause 8.1 addresses operational planning and control across all AI system lifecycle phases and components; OA-06 covers only the third-party vendor and model risk oversight dimension and does not address operational controls for internally-developed AI systems covered by other OA layer controls and the BH layer." }, { "framework": "aicm", "requirement_id": "STA-09", "fit": "partial", "uncovered_portion": "STA-09 additionally requires BOM documentation for cloud infrastructure, software dependencies, and third-party service components beyond AI model and dataset provenance." }, { "framework": "owasp_aitg", "requirement_id": "AITG-IR-01", "fit": "partial", "uncovered_portion": "AITG-IR-01 covers incident detection, investigation, and corrective action procedures; authority assignment for incident response decisions is a governance precondition that the test does not directly assess." } ] }, { "control_id": "OA-07", "control_name": "Incident Escalation Authority Chain", "layer": "OA", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MANAGE-2.4", "fit": "partial", "uncovered_portion": "Technical incident response procedures addressed in CR layer." }, { "framework": "eu_ai_act", "requirement_id": "Art-73", "fit": "partial", "uncovered_portion": "Post-incident corrective action requirements addressed in CR layer." }, { "framework": "iso_42001", "requirement_id": "10.2", "fit": "partial", "uncovered_portion": "None significant." }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "partial", "uncovered_portion": "None significant." }, { "framework": "owasp_aitg", "requirement_id": "AITG-GV-05", "fit": "partial", "uncovered_portion": "AITG-GV-05 validates the existence and structure of AI governance decision authority; escalation path definitions and cross-functional authority resolution mechanisms extend into organizational process territory beyond what the governance structure test checks." } ] }, { "control_id": "OA-08", "control_name": "Notice, Explanation Support, Human Review and Contestability", "layer": "OA", "gaps": [ { "framework": "eu_ai_act", "requirement_id": "Art-13", "fit": "partial", "uncovered_portion": "Art-13 technical documentation requirements (instructions for use) are addressed in LI layer." }, { "framework": "nist_rmf", "requirement_id": "GOVERN-1.7", "fit": "partial", "uncovered_portion": "None significant." }, { "framework": "aisvs", "requirement_id": "C1.1", "fit": "partial", "uncovered_portion": "None significant." }, { "framework": "iso_42001", "requirement_id": "8.4", "fit": "partial", "uncovered_portion": "None significant." }, { "framework": "llm10", "requirement_id": "LLM10:2025", "fit": "partial", "uncovered_portion": "Factual accuracy of model outputs is a separate concern addressed in EV layer." } ] }, { "control_id": "BH-01", "control_name": "Output Anomaly Detection", "layer": "BH", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.3", "fit": "partial", "uncovered_portion": "MEASURE 2.3 encompasses the full spectrum of operational AI monitoring including fairness metrics, input distribution, and societal impact dimensions; BH-01 addresses only statistical output distribution monitoring and does not cover input drift (BH-02), performance regression (BH-03), or behavioral boundary adherence (BH-04)." }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "uncovered_portion": "Clause 9.1 spans the full monitoring scope including evaluation of management system effectiveness and AI system performance across all risk dimensions; BH-01 addresses only statistical output distribution monitoring and does not cover the management system evaluation or other performance dimensions required by Clause 9.1's full scope." }, { "framework": "eu_ai_act", "requirement_id": "Art-15", "fit": "partial", "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." }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "partial", "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." } ] }, { "control_id": "BH-02", "control_name": "Concept and Data Drift Detection", "layer": "BH", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.3", "fit": "partial", "uncovered_portion": "MEASURE 2.3 spans the full AI system monitoring scope including output behavior, safety, and fairness monitoring; BH-02 covers only input feature and prediction distribution drift and does not address concept drift requiring labeled ground truth, which is addressed by the EV layer periodic re-validation in CR-03." }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "uncovered_portion": "Clause 9.1 and Annex B require a comprehensive monitoring and risk assessment view; BH-02 covers input and prediction distribution drift as one risk dimension and does not address the management system effectiveness evaluation or other performance dimensions encompassed by Clause 9.1's full scope." }, { "framework": "aicm", "requirement_id": "MDS-10", "fit": "partial", "uncovered_portion": "MDS-10 additionally requires ongoing security event correlation, adversarial input monitoring, and model artifact integrity checks beyond the scope of this control." }, { "framework": "eu_ai_act", "requirement_id": "Art-72", "fit": "partial", "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." }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "partial", "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." } ] }, { "control_id": "BH-03", "control_name": "Production Performance Degradation Alerting", "layer": "BH", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.3", "fit": "partial", "uncovered_portion": "MEASURE 2.3 encompasses the full monitoring scope including fairness, safety, and input distribution monitoring; BH-03 covers only performance metric regression monitoring anchored to the EV-layer baseline and does not address other monitoring dimensions covered by BH-01, BH-02, and BH-04." }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "uncovered_portion": "Clause 9.1 spans the full performance monitoring and management system evaluation scope; BH-03 addresses only production metric regression against the release baseline and does not cover other monitoring dimensions or management system effectiveness evaluation." }, { "framework": "eu_ai_act", "requirement_id": "Art-72", "fit": "partial", "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." }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "partial", "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." } ] }, { "control_id": "BH-04", "control_name": "Behavioral Boundary Performance Testing", "layer": "BH", "gaps": [ { "framework": "nist_ai_600_1", "requirement_id": "INFO-SECURITY", "fit": "partial", "uncovered_portion": "EV-04 (red-team evaluation) handles the pre-deployment adversarial testing component; BH-04 handles runtime detection only." }, { "framework": "nist_rmf", "requirement_id": "MEASURE-2.6", "fit": "partial", "uncovered_portion": "MEASURE 2.6 encompasses robustness evaluation across the full AI lifecycle including pre-deployment testing; BH-04 covers only the production-time adherence measurement component and explicitly excludes enforcement, which is delegated to securitycontrols.ai, and pre-release adversarial evaluation covered by EV-06 and EV-07." }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "uncovered_portion": "Clauses 9.1 and 6.1 address performance monitoring and risk management across the full AI system scope; BH-04 covers only behavioral boundary adherence measurement and does not address other monitoring dimensions, fairness metrics, or management system effectiveness evaluation." }, { "framework": "aicm", "requirement_id": "TVM-13", "fit": "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." }, { "framework": "eu_ai_act", "requirement_id": "Art-15", "fit": "partial", "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." } ] }, { "control_id": "BH-05", "control_name": "Usage Telemetry and Decision Logging", "layer": "BH", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.2", "fit": "partial", "uncovered_portion": "GOVERN 1.2 addresses the full accountability and transparency policy lifecycle including governance structures, stakeholder communication, and external transparency obligations; BH-05 covers only inference-level audit trail creation and does not address governance policy documentation, accountability structures, or external reporting obligations." }, { "framework": "iso_42001", "requirement_id": "7.5", "fit": "partial", "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." }, { "framework": "sr262", "requirement_id": "S-4.2", "fit": "partial", "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." } ] }, { "control_id": "BH-06", "control_name": "Injection-Resistance Evaluation in Production", "layer": "BH", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.6", "fit": "partial", "uncovered_portion": "MEASURE 2.6 spans robustness evaluation across the full AI lifecycle; BH-06 covers only production injection resistance measurement and does not address detection or blocking of actual attacks delegated to securitycontrols.ai, or pre-release adversarial evaluation covered by EV-06 and EV-07." }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "uncovered_portion": "Clause 9.1 and Annex B address AI system performance monitoring and risk management across multiple dimensions; BH-06 covers only production injection resistance measurement and does not address other robustness dimensions, fairness monitoring, or management system effectiveness evaluation." }, { "framework": "owasp_aitg", "requirement_id": "AITG-ME-04", "fit": "partial", "uncovered_portion": "AITG-ME-04 covers adversarial robustness evaluation including injection resistance as part of pre-release red-teaming; runtime prompt injection detection and filtering as an operational defense mechanism goes beyond the evaluation-time probe suite the test defines." }, { "framework": "eu_ai_act", "requirement_id": "Art-55", "fit": "partial", "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." } ] }, { "control_id": "BH-07", "control_name": "Resource and Cost Anomaly Monitoring", "layer": "BH", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MANAGE-2.4", "fit": "partial", "uncovered_portion": "MANAGE 2.4 addresses risk treatment and response for the full AI risk taxonomy; BH-07 covers only resource consumption and cost anomaly detection and does not address other risk response actions such as behavioral containment, safety policy enforcement, or incident response covered by CR-04." }, { "framework": "iso_42001", "requirement_id": "7.1", "fit": "partial", "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." }, { "framework": "eu_ai_act", "requirement_id": "Art-55", "fit": "adjacent", "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.", "note": "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 fo" } ] }, { "control_id": "BH-08", "control_name": "Shadow and Canary Deployment Governance", "layer": "BH", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MANAGE-1.3", "fit": "partial", "uncovered_portion": "MANAGE 1.3 and MANAGE 3.1 address deployment risk governance and response across the full risk management scope; BH-08 covers only deployment authorization and staged rollout governance and does not address post-deployment ongoing risk management covered by BH-01 through BH-07 and the CR layer." }, { "framework": "iso_42001", "requirement_id": "8.1", "fit": "partial", "uncovered_portion": "Clauses 8.1 and 8.4 address operational control and AI system lifecycle management across all phases; BH-08 covers only the deployment transition phase governance and does not address ongoing operational controls for the serving phase covered by BH-01 through BH-07, or the decommissioning phase covered by CR-07." }, { "framework": "aicm", "requirement_id": "DSP-08", "fit": "partial", "uncovered_portion": "DSP-08 additionally covers privacy engineering practices for application interfaces, access controls on personal data, and privacy-by-default configuration across the full data lifecycle." }, { "framework": "eu_ai_act", "requirement_id": "Art-15", "fit": "adjacent", "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.", "note": "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 exp" } ] }, { "control_id": "BH-09", "control_name": "Synthetic-Content Provenance, Disclosure and Traceability", "layer": "BH", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.2", "fit": "partial", "uncovered_portion": "GOVERN 1.2 and GOVERN 6.1 address accountability and transparency policy across the full AI lifecycle; BH-09 applies exclusively to the generative-ai profile and addresses only the technical provenance embedding and disclosure label components, not broader accountability structures or stakeholder transparency obligations." }, { "framework": "iso_42001", "requirement_id": "8.2", "fit": "partial", "uncovered_portion": "Clause 8.2 and Annex A.6 address AI system documentation and transparency as system-level properties; BH-09 covers only the content provenance and disclosure dimensions for the generative-ai profile and does not address broader system documentation obligations such as model card maintenance covered by LI-04 or system-level transparency disclosures." }, { "framework": "aicm", "requirement_id": "DSP-20", "fit": "partial", "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." }, { "framework": "owasp_aitg", "requirement_id": "AITG-RT-07", "fit": "adjacent", "uncovered_portion": "AITG-RT-07 addresses system prompt and runtime configuration integrity — protecting the model's operational instructions and configuration state from unauthorized modification; BH-09 addresses content provenance and disclosure for AI-generated outputs, which is a distinct concern in the same runtime domain.", "note": "BH-09 implements C2PA-compliant provenance assertion embedding, mandatory disclosure labels, and a GenerationTraceabilityRegistry for AI-generated content — addressing the transparency and traceabilit" } ] }, { "control_id": "BH-10", "control_name": "Feedback Loop Integrity and Online Learning Governance", "layer": "BH", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MANAGE-2.2", "fit": "partial", "uncovered_portion": "MANAGE 2.2 and MANAGE 2.4 address risk management for changing system behaviors and response actions across the full AI risk taxonomy; BH-10 covers only feedback loop integrity and online learning governance for continuously-learning and generative-ai profiles, not other post-deployment behavioral management dimensions." }, { "framework": "iso_42001", "requirement_id": "8.6", "fit": "partial", "uncovered_portion": "Clause 8.6 addresses data governance across the full AI system lifecycle including training and evaluation data; BH-10 covers only post-deployment feedback data integrity and online learning governance, not training data governance covered by TG layer controls or evaluation data governance." }, { "framework": "owasp_aitg", "requirement_id": "AITG-DG-05", "fit": "partial", "uncovered_portion": "AITG-DG-05 addresses feedback-loop and RLHF data integrity at training time; runtime feedback collection integrity including RLHF telemetry pipelines and production reward signal monitoring extends the test's training-phase scope into the operational deployment phase." }, { "framework": "eu_ai_act", "requirement_id": "Art-72", "fit": "adjacent", "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.", "note": "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 — p" }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "adjacent", "uncovered_portion": "SR 26-2 applies to supervised banking organizations with $30B+ in assets. SR 26-2 does not specifically address continuously-learning AI systems or reinforcement learning from human feedback; this mapping is an interpretive analog.", "note": "SR 26-2 §III.C ongoing monitoring requirements include ongoing assessment of model behavior; BH-10's feedback loop integrity controls provide adjacent assurance for continuously-learning models in ban" } ] }, { "control_id": "CR-01", "control_name": "Continuous Production Monitoring and Risk Aggregation", "layer": "CR", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.3", "fit": "partial", "uncovered_portion": "MEASURE 2.3 encompasses the full AI system monitoring scope including evaluation of management system effectiveness; CR-01 covers the aggregated runtime monitoring and alerting layer and does not address pre-deployment evaluation gates covered by the EV layer or the structured risk response actions covered by CR-04." }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "uncovered_portion": "Clause 9.1 spans management system effectiveness evaluation and AI system performance monitoring across all risk dimensions; CR-01 addresses operational runtime signal aggregation and does not cover the management system evaluation or other lifecycle monitoring dimensions that Clause 9.1's full scope encompasses." }, { "framework": "aicm", "requirement_id": "MDS-10", "fit": "partial", "uncovered_portion": "MDS-10 additionally requires ongoing security event correlation, adversarial input monitoring, and model artifact integrity checks beyond the scope of this control." }, { "framework": "eu_ai_act", "requirement_id": "Art-72", "fit": "partial", "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." }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "partial", "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." } ] }, { "control_id": "CR-02", "control_name": "Model Evidence Archive and Audit Trail", "layer": "CR", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-6.2", "fit": "partial", "uncovered_portion": "GOVERN 6.2 addresses accountability and transparency information requirements across the full AI system scope including real-time accountability disclosures; CR-02 covers only the records retention and evidence archival dimension and does not address real-time transparency reporting or stakeholder communication obligations." }, { "framework": "iso_42001", "requirement_id": "7.5", "fit": "partial", "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." }, { "framework": "eu_ai_act", "requirement_id": "Art-11", "fit": "partial", "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." }, { "framework": "sr262", "requirement_id": "S-4.2", "fit": "partial", "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." } ] }, { "control_id": "CR-03", "control_name": "Scheduled Model Re-validation", "layer": "CR", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.2", "fit": "partial", "uncovered_portion": "MEASURE 2.2 encompasses the full measurement scope for verifying AI systems meet their objectives including real-time performance monitoring; CR-03 addresses only the scheduled re-validation evaluation dimension and does not cover continuous runtime monitoring covered by BH-01 through BH-07 or the incident response framework covered by CR-04." }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "uncovered_portion": "Clause 9.1 spans the full monitoring scope including management system effectiveness evaluation and all AI system performance dimensions; CR-03 covers only the scheduled re-validation cadence and does not address continuous runtime monitoring or management system effectiveness evaluation encompassed by Clause 9.1's full scope." }, { "framework": "eu_ai_act", "requirement_id": "Art-72", "fit": "partial", "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." }, { "framework": "sr262", "requirement_id": "S-3.2", "fit": "partial", "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." } ] }, { "control_id": "CR-04", "control_name": "AI Incident Response Management", "layer": "CR", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MANAGE-4.1", "fit": "partial", "uncovered_portion": "MANAGE 4.1 addresses risk treatment planning across the full AI risk taxonomy including preventive and continuous controls; CR-04 covers only the incident response and corrective action dimension and does not address preventive risk treatment or the ongoing risk monitoring covered by CR-01 and BH layer controls." }, { "framework": "iso_42001", "requirement_id": "10.1", "fit": "partial", "uncovered_portion": "Clause 10.1 addresses nonconformity and corrective action across the full AI management system scope including systemic improvement; CR-04 covers only the incident response and immediate corrective action dimension and does not address continual improvement of the management system or preventive action processes encompassed by Clause 10.1's full scope." }, { "framework": "eu_ai_act", "requirement_id": "Art-73", "fit": "partial", "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." }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "adjacent", "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.", "note": "SR 26-2 §III.C requires escalation procedures for material model performance issues; CR-04's incident management framework provides adjacent coverage of the escalation and remediation requirements in " } ] }, { "control_id": "CR-05", "control_name": "Regulatory Notification and Statutory Reporting", "layer": "CR", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-1.4", "fit": "partial", "uncovered_portion": "GOVERN 1.4 and GOVERN 4.1 address the full accountability and regulatory obligation scope for AI systems including internal governance structures; CR-05 covers only the statutory regulatory notification and reporting dimension and does not address internal governance accountability obligations or the broader transparency requirements encompassed by GOVERN 1.4's full scope." }, { "framework": "iso_42001", "requirement_id": "5.2", "fit": "partial", "uncovered_portion": "Clause 5.2 addresses the full leadership commitment scope including AI policy definition, resource commitment, and strategic direction for the AI management system; CR-05 covers only the regulatory notification dimension of leadership accountability and does not address broader AI policy commitments, resource direction, or strategic AI management system leadership obligations." }, { "framework": "owasp_aitg", "requirement_id": "AITG-IR-05", "fit": "adjacent", "uncovered_portion": "AITG-IR-05 requires that audit trail integrity be maintained and verifiable for AI system accountability; CR-05 addresses the regulatory notification and statutory disclosure dimension of incident accountability, which is a related but distinct concern — the audit trail integrity requirements of AITG-IR-05 are addressed by CR-02's immutable evidence archive and Sigstore transparency anchoring.", "note": "CR-05 establishes statutory reporting obligations and regulatory notification procedures for AI incidents — maintaining a pre-approved notification matrix, countdown timers, and a notification archive" }, { "framework": "eu_ai_act", "requirement_id": "Art-72", "fit": "partial", "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." }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "partial", "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." } ] }, { "control_id": "CR-06", "control_name": "Post-Market Surveillance", "layer": "CR", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MEASURE-2.3", "fit": "partial", "uncovered_portion": "MEASURE 2.3 encompasses the full AI system monitoring scope including runtime statistical monitoring and performance regression detection; CR-06 covers only the proactive surveillance channels for externally-reported harms and third-party research findings, not the runtime instrumentation dimension covered by CR-01 and the BH layer." }, { "framework": "iso_42001", "requirement_id": "9.1", "fit": "partial", "uncovered_portion": "Clause 9.1 spans systematic monitoring including internal performance measurement and management system effectiveness evaluation; CR-06 covers only the external surveillance and feedback channel dimension of production monitoring and does not address internal runtime metric monitoring covered by CR-01 or re-validation covered by CR-03." }, { "framework": "sr262", "requirement_id": "S-5.1", "fit": "adjacent", "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).", "note": "SR 26-2 §III.C escalation procedures include notifying senior management and relevant risk functions; CR-06's regulatory notification procedures provide adjacent coverage of the formal escalation requ" } ] }, { "control_id": "CR-07", "control_name": "Model Retirement and Evidence Archival", "layer": "CR", "gaps": [ { "framework": "nist_rmf", "requirement_id": "MANAGE-2.4", "fit": "partial", "uncovered_portion": "MANAGE 2.4 and MANAGE 4.2 address risk treatment and disposal across the full AI risk taxonomy including active runtime risk responses; CR-07 covers only the end-of-life retirement and decommissioning dimension and does not address ongoing risk treatment for active deployments covered by BH layer controls and CR-04." }, { "framework": "iso_42001", "requirement_id": "8.1", "fit": "partial", "uncovered_portion": "Clause 8.1 addresses operational planning and control across all AI system lifecycle phases including development, deployment, and operation; CR-07 covers only the decommissioning and end-of-life phase and does not address operational controls for the active deployment phase covered by BH layer controls." }, { "framework": "eu_ai_act", "requirement_id": "Art-16", "fit": "adjacent", "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.", "note": "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 struct" }, { "framework": "sr262", "requirement_id": "S-4.1", "fit": "partial", "uncovered_portion": "SR 26-2 applies to supervised banking organizations with $30B+ in assets. SR 26-2 §IV.A is general governance rather than a detailed decommissioning procedure; the specific decommissioning process is organizationally defined." } ] }, { "control_id": "CR-08", "control_name": "Cross-Domain Assurance Coordination", "layer": "CR", "gaps": [ { "framework": "nist_rmf", "requirement_id": "GOVERN-2.2", "fit": "partial", "uncovered_portion": "GOVERN 2.2 and GOVERN 6.1 address organizational accountability and inter-organizational AI risk governance across the full governance scope; CR-08 covers only the cross-domain evidence reference resolution and coordination dimension and does not address single-domain governance accountability covered by OA layer controls." }, { "framework": "iso_42001", "requirement_id": "8.3", "fit": "partial", "uncovered_portion": "Clause 8.3 addresses AI system design and development process governance across the full system scope; CR-08 covers only the cross-domain assurance coordination dimension and does not address intra-domain design and development governance covered by other controls." }, { "framework": "owasp_aitg", "requirement_id": "AITG-IR-05", "fit": "adjacent", "uncovered_portion": "AITG-IR-05 addresses audit trail integrity for a single AI system's evidence chain; CR-08 addresses cross-domain evidence reference resolution and inter-domain assurance coordination across multiple Apeiris domain boundaries, which is a distinct concern in the same evidence accountability domain that AITG-IR-05 does not prescribe solutions for.", "note": "CR-08 resolves cross-domain apeiris:// evidence references, maintains a cross-domain dependency map, and coordinates inter-domain assurance reviews — addressing multi-domain audit trail integrity in t" }, { "framework": "eu_ai_act", "requirement_id": "Art-11", "fit": "adjacent", "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.", "note": "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 correla" }, { "framework": "sr262", "requirement_id": "S-4.2", "fit": "adjacent", "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.", "note": "SR 26-2 §IV.D requires comprehensive records that support supervisory examination; CR-08's cross-domain compliance evidence collection provides adjacent coverage of the records management requirement " } ] } ], "profiles": [ { "profile_id": "general-predictive-ml", "name": "General Predictive ML", "description": "Traditional supervised, unsupervised, or semi-supervised ML models used in analytical or decision-support contexts. Includes classification, regression, clustering, time-series forecasting, and tabular models. Excludes models with elevated capability levels, generative outputs, or continuously-learning regimes (which trigger additional profiles). This profile establishes the minimum viable control set for conventional enterprise ML deployments — the baseline for all other profiles.", "version": "1.0.0", "trigger_conditions": { "any": [ { "field": "assurance_target.model_paradigm", "op": "in", "value": [ "supervised", "unsupervised", "semi-supervised", "time-series", "tabular" ] } ], "none": [ { "field": "capability_risk.capability_level", "op": "in", "value": [ "elevated", "frontier" ] }, { "field": "assurance_target.model_paradigm", "op": "eq", "value": "generative" } ] }, "heightened_trigger": null, "enforcement_gating": null, "required_controls": [ "LI-01", "LI-04", "TG-01", "EV-01", "OA-01", "CR-01" ], "recommended_controls": [ "LI-06", "TG-05", "EV-06", "EV-07", "EV-09", "OA-07", "BH-03", "BH-05", "CR-02" ], "not_applicable_controls": [ "EV-03", "EV-04" ], "not_applicable_rationale": "Dangerous capability assessment (EV-03) and adversarial red-team testing (EV-04) are not required for low-capability conventional ML models with no elevated capability domains. Including them would burden standard enterprise deployments with disproportionate effort.", "required_control_count": 6, "recommended_control_count": 9, "profile_specific_notes": null, "eu_ai_act_mapping": null }, { "profile_id": "generative-ai", "name": "Generative AI", "description": "Models that generate novel outputs including text, code, images, audio, video, or structured content. Includes large language models (LLMs), diffusion models, multimodal generators, code generation models, and any model where the primary output modality is generative. Generative AI introduces unique risks: hallucination, misinformation amplification, synthetic content provenance, prompt manipulation, and supply-chain exposure through pretrained foundation models. This profile activates a materially larger required control set reflecting those risks.", "version": "1.0.0", "trigger_conditions": { "any": [ { "field": "assurance_target.model_paradigm", "op": "eq", "value": "generative" }, { "field": "assurance_target.output_modalities", "op": "contains-any", "value": [ "text", "image", "audio", "video", "code" ] } ] }, "heightened_trigger": null, "enforcement_gating": null, "required_controls": [ "LI-01", "LI-04", "LI-06", "TG-01", "TG-05", "EV-01", "EV-02", "EV-06", "EV-07", "OA-01", "BH-03", "BH-05", "BH-09" ], "recommended_controls": [ "LI-06", "TG-04", "EV-04", "EV-09", "OA-02", "OA-07", "BH-04", "CR-01", "CR-02" ], "not_applicable_controls": [], "not_applicable_rationale": null, "required_control_count": 13, "recommended_control_count": 9, "profile_specific_notes": { "EV-02": "Safety and fitness evaluation must include hallucination rate, factual accuracy on held-out benchmarks, policy-adherence testing, and refusal-behavior evaluation. 'Helpful, harmless, honest' framing is insufficient without quantified metrics.", "BH-09": "Synthetic content provenance and disclosure controls are required for all externally visible generative outputs. Reference C2PA and NIST AI 100-4 guidance on technical approaches but note neither mandates a specific watermarking mechanism.", "TG-05": "Benchmark contamination, semantic duplicates, temporal leakage, retrieval leakage, and evaluation overfitting must be explicitly addressed — not just train/test split." }, "eu_ai_act_mapping": null }, { "profile_id": "multimodal", "name": "Multimodal AI System", "description": "AI systems that process non-text inputs (images, audio, video, documents) or generate outputs across multiple modalities. Includes vision-language models (VLMs), audio-language models, video understanding systems, document AI, and any model where non-text modalities create a meaningful attack surface or data governance obligation. The generative-ai profile addresses output generation risks; this profile addresses the distinct risks that arise from non-text input processing: cross-modal jailbreaks (image or audio inputs bypassing text-layer safety filters), indirect prompt injection via OCR'd document content, visual PII and biometric data in training corpora, audio deepfake generation, and cross-modal hallucination (false descriptions of visual content). Multimodal evaluation must test adversarial inputs across all active modalities, not only text.", "version": "1.0.0", "trigger_conditions": { "any": [ { "field": "assurance_target.model_paradigm", "op": "eq", "value": "multimodal" }, { "field": "assurance_target.input_modalities", "op": "contains-any", "value": [ "image", "audio", "video", "document" ] }, { "field": "assurance_target.output_modalities", "op": "contains-any", "value": [ "image", "audio", "video" ] } ] }, "heightened_trigger": null, "enforcement_gating": null, "required_controls": [ "LI-01", "LI-04", "TG-01", "TG-06", "EV-01", "EV-02", "EV-04", "OA-01", "BH-04", "BH-09" ], "recommended_controls": [ "LI-06", "TG-03", "TG-05", "EV-06", "EV-07", "EV-09", "OA-07", "BH-05", "CR-01", "CR-02" ], "not_applicable_controls": [], "not_applicable_rationale": null, "required_control_count": 10, "recommended_control_count": 10, "profile_specific_notes": { "cross_modal_attack_surface": "The primary risk this profile addresses is cross-modal policy bypass: adversarial content embedded in images, audio, or documents that causes the model to behave in ways that text-only safety evaluation would not predict or detect. EV-04 (adversarial red-team testing) must include modality-specific attack vectors — not only text jailbreaks.", "EV-02": "Safety and fitness evaluation must be conducted across all active input modalities. A text-safe model is not necessarily image-safe or audio-safe. Evaluation must include cross-modal adversarial inputs: adversarial images designed to produce harmful text outputs, document-embedded injection attacks (OCR-based), and audio-based manipulation if audio input is active.", "EV-04": "Red-team testing must include domain experts in relevant modalities. Cross-modal jailbreaks require different attack expertise than text-only jailbreaks. Test cases must cover: images with embedded text instructions, typographic attacks, adversarial optical patterns, indirect prompt injection via OCR'd documents, audio-based adversarial inputs, and steganographic content.", "TG-06": "Non-text training data carries distinct sensitive data risks: visual content may contain biometric data (faces, fingerprints), location information (GPS EXIF data), PII in document images, or sensitive visual scenes. Audio data may contain voice biometrics and PII. The sensitive data necessity and minimization analysis (TG-06) must address all modalities present in training data.", "BH-04": "Behavioral boundary enforcement must cover all output modalities, not only text. For image-generating systems: policy enforcement on generated visual content (nudity, violence, biometrics, IP-infringing styles). For audio-generating systems: deepfake voice policy enforcement, voice consent requirements. Cross-modal output policies are owned here; Security domain owns API-level enforcement.", "BH-09": "Synthetic content provenance and disclosure requirements under BH-09 are especially critical for multimodal systems that generate images, audio, or video. C2PA (Coalition for Content Provenance and Authenticity) is the leading technical standard; NIST AI 100-4 covers synthetic content risk. Provenance metadata must travel with generated non-text content.", "LI-04": "Technical documentation must enumerate all active modalities: input modalities accepted, output modalities generated, any modality-specific limitations (e.g., language support varies by modality), and modality-specific evaluation results. Modality-specific risk profile must be documented.", "document_ai_note": "Document AI (PDF/image parsing for question answering or extraction) is a distinct multimodal pattern with specific indirect prompt injection risks — malicious content in documents can hijack the model's behavior when processed by an LLM backend. TG-05 must address document corpus contamination; EV-04 must test document-embedded injection." }, "eu_ai_act_mapping": null }, { "profile_id": "hosted-api", "name": "Hosted API / Third-Party Model", "description": "Deployments where the model is accessed via an external API rather than operated directly — including commercial LLM APIs, foundation model providers, and third-party ML service vendors. Also applies to internal model-as-a-service deployments serving multiple internal consumers. Key risks: supply-chain exposure, undisclosed provider-side model updates, provider availability dependency, rate limits and unbounded consumption, and loss of reproducibility when provider changes model behavior without notice.", "version": "1.0.0", "trigger_conditions": { "any": [ { "field": "capability_risk.access_mode", "op": "eq", "value": "api" }, { "field": "assurance_target.provider_type", "op": "in", "value": [ "third-party", "open-weight" ] } ] }, "heightened_trigger": null, "enforcement_gating": null, "required_controls": [ "LI-01", "LI-04", "LI-06", "BH-03", "BH-05", "BH-10", "CR-01", "OA-01" ], "recommended_controls": [ "TG-05", "EV-01", "EV-07", "EV-09", "OA-07", "CR-02", "CR-04" ], "not_applicable_controls": [], "not_applicable_rationale": null, "required_control_count": 8, "recommended_control_count": 7, "profile_specific_notes": { "LI-06": "For hosted APIs, rollback means maintaining the ability to switch to a prior provider version, an alternative provider, or a degraded fallback mode. The deployer must negotiate version pinning or change notification SLAs with the provider.", "BH-10": "Provider change monitoring is essential — model behavior at the same API endpoint may change without version bump. Establish behavioral regression tests that run against the provider API on a scheduled basis.", "EV-01": "Pre-release evaluation must still occur even if the model weights are not accessible. Behavioral evaluation using the API is sufficient — but document the evaluation scope limitation explicitly.", "retraining_caveat": "For third-party APIs, retraining is not an available response action. Fallback actions must be provider-agnostic: switch provider, activate fallback model, restrict use, or increase human review." }, "eu_ai_act_mapping": null }, { "profile_id": "continuously-learning", "name": "Continuously Learning System", "description": "Models that update their parameters or decision behavior from production data, human feedback, or reinforcement signals during deployment. Includes online learning systems, models with RLHF pipelines, continual learning systems, and adaptive fine-tuning pipelines. The defining risk is that production data becomes training data — meaning data poisoning, feedback manipulation, reward hacking, and self-reinforcing errors are live threats, not pre-deployment threats. Standard one-time pre-release evaluation is insufficient for continuously-learning systems.", "version": "1.0.0", "trigger_conditions": { "any": [ { "field": "assurance_target.training_regime", "op": "contains-any", "value": [ "online-learning", "rlhf", "continual-learning", "adaptive-fine-tuning" ] } ] }, "heightened_trigger": null, "enforcement_gating": null, "required_controls": [ "TG-01", "TG-04", "TG-05", "EV-01", "EV-06", "EV-07", "CR-01", "CR-02", "CR-03", "BH-05", "BH-08" ], "recommended_controls": [ "LI-06", "BH-03", "OA-07", "CR-04", "TG-06" ], "not_applicable_controls": [], "not_applicable_rationale": null, "required_control_count": 11, "recommended_control_count": 5, "profile_specific_notes": { "EV-01": "Pre-release evaluation gates must apply not only to initial release but to every material behavioral update triggered by the learning pipeline. Define what constitutes a 'material change' that requires re-evaluation.", "TG-04": "Feedback poisoning, reward model manipulation, labeler quality degradation, and self-reinforcing error amplification are active production threats — not just pre-training concerns. TG-04 controls must extend to the production feedback pipeline.", "BH-08": "Feedback loop integrity controls — monitoring for feedback poisoning, labeler drift, reward hacking, and self-reinforcing error patterns — are required for all continuously-learning systems.", "CR-03": "Material change determination is especially critical: when does a learning update constitute a material behavioral change requiring formal re-evaluation? This threshold must be documented and operationalized." }, "eu_ai_act_mapping": null }, { "profile_id": "high-impact-decision", "name": "High-Impact Automated Decision", "description": "Model deployments that influence or make consequential decisions affecting individuals' access to services, opportunities, or rights. Includes credit decisioning, employment screening, healthcare triage or diagnosis, benefits eligibility, housing applications, educational admissions, insurance underwriting, judicial risk assessment, and similar high-stakes domains. The distinguishing factor is that model errors impose significant, often irreversible harm on affected individuals. Human oversight must be meaningful — not nominal — and affected parties must have access to notice, explanation, and contestability mechanisms.", "version": "1.0.0", "trigger_conditions": { "any": [ { "field": "capability_risk.affected_party_impact", "op": "in", "value": [ "high", "critical" ] }, { "field": "assurance_target.decision_domain", "op": "contains-any", "value": [ "credit", "hiring", "healthcare", "benefits", "education", "law-enforcement", "housing", "insurance", "judicial", "immigration", "government-services" ] }, { "field": "capability_risk.irreversibility", "op": "eq", "value": "irreversible" } ] }, "heightened_trigger": null, "enforcement_gating": null, "required_controls": [ "LI-01", "LI-04", "LI-06", "EV-01", "EV-05", "EV-06", "EV-09", "OA-01", "OA-02", "OA-07", "OA-08", "CR-01", "CR-02" ], "recommended_controls": [ "TG-01", "TG-03", "TG-06", "EV-07", "BH-03", "BH-05", "CR-04" ], "not_applicable_controls": [], "not_applicable_rationale": null, "required_control_count": 13, "recommended_control_count": 7, "profile_specific_notes": { "OA-02": "Human oversight adequacy evaluation must assess whether the human reviewer has time, information, authority, competence, and a genuine ability to override — not merely whether a human is nominally present in the process.", "EV-05": "Fairness evaluation must document: which populations, which protected attributes (where legally permitted), which fairness metric(s) selected and why, what legal basis exists for using protected attributes in testing, what thresholds are acceptable, and what trade-offs between fairness metrics were deliberately chosen.", "OA-08": "Notice, explanation support, human review, and contestability must be implemented as operational capabilities, not policy commitments. Affected parties must have a genuine, accessible path to challenge decisions.", "TG-06": "Protected attribute handling: while DT controls generally require minimization of sensitive data, fairness evaluation in high-impact contexts may require controlled access to protected attributes. TG-06 must address this tension explicitly — controlled use for auditing and bias testing, with strict access governance.", "capability_risk_note": "affected_party_impact: 'critical' indicates potential for irreversible serious harm to individuals (e.g., denial of life-saving treatment, wrongful incarceration). These deployments require the most rigorous evaluation, oversight, and contestability controls." }, "eu_ai_act_mapping": null }, { "profile_id": "us-regulated-banking", "name": "US Regulated Banking / Financial Institution", "description": "Model deployments at US supervised financial institutions subject to SR 26-2 (Federal Reserve) and OCC Bulletin 2026-13 (interagency). SR 26-2 supersedes SR 11-7 and SR 21-8. Applies to all supervised institutions with heightened expectations for those with $30B+ in consolidated assets. Both SR 26-2 and OCC 2026-13 are supervisory guidance, not binding law — noncompliance alone does not trigger supervisory action, but patterns of unsafe practice do. Controls in this profile align to SR 26-2's model risk management framework: independent validation, ongoing monitoring, governance, and outcomes analysis. Note: SR 26-2 explicitly excludes generative AI and agentic AI systems from scope; those deployments should reference the relevant GenAI or frontier-capability profiles instead.", "version": "1.0.0", "trigger_conditions": { "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "us" }, { "field": "assurance_target.regulated_entity", "op": "eq-true" } ], "any": [ { "field": "assurance_target.industry", "op": "contains-any", "value": [ "banking" ] } ] }, "heightened_trigger": { "description": "Controls marked as 'heightened' apply at elevated stringency when the institution has $30B+ in assets (SR 26-2 heightened expectations).", "condition": { "field": "assurance_target.asset_threshold_usd", "op": "gte", "value": 30000000000 } }, "enforcement_gating": null, "required_controls": [ "LI-01", "LI-04", "LI-05", "TG-01", "EV-01", "EV-06", "EV-08", "EV-09", "OA-01", "OA-03", "CR-01", "CR-02" ], "recommended_controls": [ "LI-06", "BH-03", "BH-05", "EV-07", "OA-07", "CR-03", "CR-05" ], "not_applicable_controls": [], "not_applicable_rationale": null, "required_control_count": 12, "recommended_control_count": 7, "profile_specific_notes": { "EV-08": "Independent validation is a cornerstone of SR 26-2. The validator must be organizationally independent from the model development team. For AI/ML models, independent validation must address conceptual soundness of the model approach, data inputs and processing, outputs and their use, and monitoring design.", "OA-03": "AI governance committee with model risk oversight is an SR 26-2 expectation for material models, particularly at larger institutions.", "LI-05": "Model inventory and tiering documentation (materiality classification) is required by SR 26-2. Models must be classified by materiality to determine validation depth and ongoing monitoring requirements.", "legal_status_reminder": "All SR 26-2 and OCC 2026-13 mappings must carry legal_status: 'guidance'. These are supervisory guidance documents — not binding law. Represent this accurately in all obligations and mapping records.", "scope_exclusions": "SR 26-2 does not apply to insurance companies, investment managers, or general financial services firms. It explicitly excludes generative AI and agentic AI systems. For broader financial-services AI governance, treat SR 26-2 as a non-binding model risk management analog only.", "sr262_genai_exclusion": "OCC Bulletin 2026-13 and SR 26-2 are not within scope for generative AI or agentic AI deployments. For those systems, reference the generative-ai or frontier-capability profiles." }, "eu_ai_act_mapping": null }, { "profile_id": "eu-high-risk", "name": "EU AI Act High-Risk System (Annex III)", "description": "Model deployments classified as high-risk AI systems under EU AI Act Annex III, or systems embedded in regulated products that become high-risk under Annex I. Annex III covers: biometric identification and categorization, management of critical infrastructure, education and vocational training, employment and HR decisions, access to essential services (credit, insurance, social benefits), law enforcement, immigration and asylum, administration of justice and democratic processes. EU AI Act high-risk requirements for standalone Annex III systems become enforceable Dec 2, 2027; product-embedded systems Aug 2, 2028. Controls in this profile align to the mandatory technical requirements (Art-9 through Art-17).", "version": "1.0.0", "trigger_conditions": { "any": [ { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "high-risk-annex-iii", "high-risk-product-embedded" ] } ], "all": [ { "field": "assurance_target.jurisdiction", "op": "contains", "value": "eu" } ] }, "heightened_trigger": null, "enforcement_gating": { "description": "This profile's obligations are legally enforceable only after the applicable effective date. During the transitional period, controls should be treated as best-practice requirements preparatory to enforcement.", "standalone_effective": "2027-12-02", "product_embedded_effective": "2028-08-02" }, "required_controls": [ "LI-01", "LI-04", "LI-06", "LI-07", "TG-01", "TG-03", "TG-06", "EV-01", "EV-05", "EV-06", "EV-09", "OA-01", "OA-02", "OA-07", "OA-08", "BH-05", "CR-01", "CR-02" ], "recommended_controls": [ "TG-05", "EV-07", "BH-03", "BH-04", "CR-04" ], "not_applicable_controls": [], "not_applicable_rationale": null, "required_control_count": 18, "recommended_control_count": 5, "profile_specific_notes": { "classification_prerequisite": "The eu_ai_act_classification in assurance_target must be formally determined before this profile is activated. Classification depends on intended purpose, deployment context, actor role, and product category — it is not an intrinsic model property.", "actor_role_scoping": "Many Art-9 through Art-17 requirements apply to providers (organizations that develop or place AI systems on the market) differently from deployers. The obligation object actor_roles field must reflect this distinction.", "gpai_note": "GPAI model obligations (Art-51+) are a separate regime applying to providers of general-purpose AI models. If the deployment also involves a GPAI model, the gpai-systemic-risk profile conditions may additionally apply." }, "eu_ai_act_mapping": { "LI-04": "Art-11 (Technical documentation), Annex-IV", "LI-06": "Art-12 (Record-keeping and logging)", "TG-01": "Art-10 (Data governance)", "TG-03": "Art-10(5) (Data with special categories)", "TG-06": "Art-10(5) (Sensitive data necessary for bias correction)", "EV-01": "Art-9 (Risk management system)", "EV-05": "Art-10(2)(f) (Bias examination and correction)", "EV-09": "Art-9(2)(a) (Risk identification and analysis)", "OA-02": "Art-14 (Human oversight)", "OA-08": "Art-13 (Transparency and information provision)", "BH-05": "Art-12 (Logging obligations)" } }, { "profile_id": "gpai-provider", "name": "GPAI Model Provider (EU AI Act Ch. V)", "description": "Providers of general-purpose AI models (GPAI models) as defined in EU AI Act Art. 3(63) and regulated under Title III, Chapter V (Art. 51–55). A GPAI model is trained on broad data at scale, exhibits general-purpose capabilities, and can perform a wide range of distinct tasks — typically including foundation models and large language models. Chapter V obligations apply to organizations that develop and place GPAI models on the EU market (providers), not downstream deployers. Key obligations: technical documentation per Annex XI, copyright compliance policy, training data summary publication, and availability of documentation to downstream providers. GPAI-specific obligations became applicable 2 August 2025 — earlier than standalone Annex III high-risk enforcement. A limited open-source exception applies under Art. 53(2).", "version": "1.0.0", "trigger_conditions": { "any": [ { "field": "assurance_target.eu_ai_act_classification", "op": "in", "value": [ "gpai-general", "gpai-systemic-risk" ] }, { "field": "assurance_target.is_gpai_model", "op": "eq-true" } ], "all": [ { "field": "assurance_target.actor_role", "op": "contains", "value": "provider" } ] }, "heightened_trigger": null, "enforcement_gating": { "description": "GPAI model provider obligations under EU AI Act Title III, Chapter V became applicable 2025-08-02 (12 months after entry into force on 2024-08-01) — earlier than standalone Annex III high-risk system enforcement (2027-12-02). The open-source exception under Art. 53(2) reduces documentation obligations for models released under qualifying free and open-source licenses, unless the model presents systemic risk.", "gpai_general_effective": "2025-08-02", "gpai_systemic_risk_effective": "2025-08-02", "open_source_exception": "Art-53(2)" }, "required_controls": [ "LI-01", "LI-04", "TG-01", "TG-03", "OA-01", "OA-03" ], "recommended_controls": [ "LI-02", "LI-03", "LI-05", "TG-05", "EV-01", "OA-07", "CR-01", "CR-02" ], "not_applicable_controls": [], "not_applicable_rationale": null, "required_control_count": 6, "recommended_control_count": 8, "profile_specific_notes": { "actor_scope": "This profile applies to providers of GPAI models — organizations that develop GPAI models and place them on the EU market or put them into service. Downstream providers who deploy a GPAI model within their own AI system (without modifying its core parameters) are not GPAI model providers under Ch. V and instead may trigger the eu-high-risk profile if their system qualifies under Annex III.", "gpai_definition": "A GPAI model (Art. 3(63)) is an AI model trained on large amounts of data using self-supervision at scale, displaying significant generality and capable of performing a wide range of distinct tasks. The classification is based on the model's characteristics and training methodology, not the deployer's specific intended use.", "TG-03": "Art. 53(1)(b) requires a copyright compliance policy specifically covering the text and data mining exception under Art. 4(3) of Directive (EU) 2019/790. Art. 53(1)(c) requires public disclosure of a sufficiently detailed summary of training data content including sources and data types. These obligations apply regardless of whether the model is open-source.", "LI-04": "Technical documentation for GPAI models must be prepared in accordance with Annex XI, covering: model description, training methodology, evaluation results, downstream use guidance, and information for integrating providers. For models with systemic risk, Annex XII applies additionally — see gpai-systemic-risk profile.", "open_source_exception": "Under Art. 53(2), GPAI model providers releasing models under free and open-source licenses need only comply with Art. 53(1)(b) (copyright policy) and Art. 53(1)(c) (training summary) unless the model presents systemic risk. The Annex XI documentation and downstream-provider information obligations are reduced for qualifying open-source releases.", "gpai_vs_high_risk": "GPAI model obligations (Ch. V–VI) and high-risk AI system obligations (Ch. III, Annex III) are distinct regulatory regimes with different subject scopes and actor roles. A GPAI model integrated into a high-risk AI system may trigger obligations under both regimes for different actors: the GPAI provider under Ch. V and the high-risk system provider under Ch. III.", "effective_date_note": "GPAI-specific Title III obligations became applicable 2025-08-02 — one year after EU AI Act entry into force on 2024-08-01 — ahead of standalone Annex III high-risk enforcement (2027-12-02) and product-embedded enforcement (2028-08-02)." }, "eu_ai_act_mapping": { "LI-01": "Art-51 (Classification and notification of GPAI models with systemic risk; identity registration)", "LI-04": "Art-53(1)(a) (Technical documentation per Annex XI), Art-53(1)(d) (Documentation made available to downstream providers)", "TG-01": "Art-53(1)(a) (Training data governance and documentation as part of Annex XI)", "TG-03": "Art-53(1)(b) (Union copyright compliance policy, text and data mining exception under Directive 2019/790 Art-4(3)), Art-53(1)(c) (Sufficiently detailed summary of training data content)", "OA-01": "Art-52 (Provider accountability for GPAI model obligations)", "OA-03": "Art-56 (Governance and cooperation with the AI Office)" } }, { "profile_id": "gpai-systemic-risk", "name": "GPAI Model with Systemic Risk (EU AI Act Ch. V, Section 3, Art. 55)", "description": "Providers of general-purpose AI models classified as presenting systemic risk under EU AI Act Art. 51 — models with aggregate training compute exceeding 10^25 floating-point operations (FLOPs, per Annex XIII), or models designated by the European Commission following qualitative evaluation (Art. 51(2)). Systemic risk GPAI models are subject to Chapter V, Section 3, Art. 55 obligations in addition to all Chapter V, Section 2 obligations applicable to GPAI providers. Art. 55 requires: model evaluation using standardized protocols and adversarial testing; systemic risk assessment and mitigation including cybersecurity risk; serious incident tracking, documentation, and reporting to the AI Office without undue delay; and adequate cybersecurity protection for the model and its infrastructure. This profile is additive to gpai-provider — both profiles are simultaneously active for systemic risk GPAI model providers.", "version": "1.0.0", "trigger_conditions": { "any": [ { "field": "assurance_target.eu_ai_act_classification", "op": "eq", "value": "gpai-systemic-risk" }, { "field": "capability_risk.training_compute_flops", "op": "gte", "value": 1e+25, "value_note": "10^25 FLOPs — EU AI Act Annex XIII threshold" }, { "field": "assurance_target.gpai_systemic_risk_designated", "op": "eq-true" } ], "all": [ { "field": "assurance_target.actor_role", "op": "contains", "value": "provider" } ] }, "heightened_trigger": null, "enforcement_gating": { "description": "Chapter VI (systemic risk) obligations became applicable 2025-08-02, concurrent with Chapter V. The 10^25 FLOPs threshold is codified in Annex XIII. The AI Office may designate additional models as presenting systemic risk based on qualitative assessment under Art. 51(2), even below the compute threshold. Providers must self-notify the AI Office when they determine their model meets the systemic risk threshold.", "effective": "2025-08-02", "threshold_reference": "Annex XIII (10^25 FLOPs training compute) or AI Office designation under Art-51(2)" }, "required_controls": [ "LI-01", "LI-04", "TG-01", "TG-03", "EV-01", "EV-03", "EV-04", "EV-09", "OA-01", "OA-03", "OA-07", "BH-05", "CR-01", "CR-02" ], "recommended_controls": [ "LI-02", "LI-03", "LI-05", "LI-06", "TG-05", "EV-06", "EV-07", "BH-03", "BH-04", "CR-03", "CR-06" ], "not_applicable_controls": [], "not_applicable_rationale": null, "required_control_count": 14, "recommended_control_count": 11, "profile_specific_notes": { "additive_to_gpai_provider": "This profile is additive to gpai-provider — both profiles are simultaneously active for systemic risk GPAI model providers. The required_controls here include the full set needed for Ch. V, Section 3, Art. 55 compliance; the union of both profiles' required_controls represents the total obligation set.", "EV-03": "Art. 55(1)(a) requires GPAI model providers with systemic risk to perform model evaluations in accordance with standardized protocols and tools reflecting the state of the art. EV-03 (Dangerous Capability Assessment) is the primary control: the evaluation must address systemic risk domains including but not limited to cyber offense, biological design assistance, persuasion at scale, and autonomous AI R&D. The AI Office may prescribe specific evaluation protocols and may designate third parties for independent evaluation under Art. 78.", "EV-04": "Art. 55(1)(a) explicitly requires adversarial testing of systemic risk GPAI models to identify and mitigate systemic risks before release. Red-team exercises (EV-04) must be structured to probe for systemic risk scenarios, not only conventional harmful outputs. Adversarial testing must be repeated upon material modifications to the model.", "CR-02": "Art. 55(1)(c) requires tracking, documenting, and reporting serious incidents without undue delay to the AI Office and national competent authorities. A 'serious incident' in the GPAI context includes incidents that actually or potentially affect safety, health, or fundamental rights at scale, or that constitute an infringement of Union law protecting fundamental rights.", "cybersecurity_boundary": "Art. 55(1)(d) requires adequate cybersecurity protection for the GPAI model and its physical infrastructure. BH-04 (Behavioral Boundary Enforcement) covers the behavioral evidence dimension. The Security domain (securitycontrols.ai) owns infrastructure, access control, and vulnerability response enforcement.", "systemic_risk_scope": "Systemic risk concerns under Art. 55 include: amplification of disinformation at scale; autonomous cyberattacks against critical infrastructure; enabling mass-casualty-weapon development; cascading failures across dependent AI systems; large-scale manipulation of public opinion or democratic processes. Systemic risk is about macro-level harm potential, not individual incident harm.", "ai_office_cooperation": "The AI Office (established under the EU AI Act to oversee GPAI models) may: issue guidance on evaluation protocols; request model access for independent testing; impose corrective actions and fines; designate additional models as systemic risk even below the compute threshold; and publish lists of GPAI models with systemic risk." }, "eu_ai_act_mapping": { "LI-01": "Art-51 (Classification and notification of GPAI models with systemic risk to the AI Office)", "LI-04": "Art-53(1)(a) (Technical documentation per Annex XI), Annex-XII (Additional documentation requirements for systemic risk models)", "TG-03": "Art-53(1)(b) (Copyright compliance policy), Art-53(1)(c) (Training data summary)", "EV-01": "Art-55(1)(a) (Model evaluation before release and upon material modification)", "EV-03": "Art-55(1)(a) (Systemic risk evaluation in accordance with standardized protocols and state-of-the-art tools)", "EV-04": "Art-55(1)(a) (Adversarial testing to identify and mitigate systemic risks; AI Office may prescribe evaluation protocols)", "EV-09": "Art-55(1)(b) (Systemic risk identification, analysis and mitigation planning)", "OA-01": "Art-52 (Provider accountability), Art-55(1) (Obligations attributable to systemic risk GPAI model provider)", "OA-03": "Art-55(1) (Internal governance for systemic risk models), Art-56 (Cooperation with AI Office including model access for evaluation)", "OA-07": "Art-55(1)(c) (Escalation authority for serious incident reporting to AI Office and national competent authorities)", "BH-05": "Art-55(1)(c) (Tracking and documenting serious incidents affecting or potentially affecting safety, health, fundamental rights)", "CR-01": "Art-55(1)(b) (Ongoing assessment and mitigation of systemic risks; continuous monitoring)", "CR-02": "Art-55(1)(c) (Incident investigation, corrective action, and reporting without undue delay to AI Office)" } }, { "profile_id": "frontier-capability", "name": "Frontier Capability Model", "description": "Model deployments at or near the state of the art in capability, where the model has demonstrated or potentially has capability thresholds that could enable serious harm at scale — including dangerous capabilities in cyber, biological, chemical, nuclear-radiological, persuasion/manipulation, or autonomous AI R&D domains. Corresponds to Anthropic RSP ASL-3+ levels, Google DeepMind FSF equivalent, or other frontier safety frameworks. This profile requires the full 15-control baseline plus the most demanding evaluation, governance, and assurance controls in the matrix. No control is categorically excluded for frontier models.", "version": "1.0.0", "trigger_conditions": { "any": [ { "field": "capability_risk.capability_level", "op": "eq", "value": "frontier" }, { "field": "capability_risk.capability_domains", "op": "contains-any", "value": [ "cyber", "bio", "chemical", "nuclear-radiological", "autonomous-ai-rd", "self-proliferation" ] } ] }, "heightened_trigger": null, "enforcement_gating": null, "required_controls": [ "LI-01", "LI-04", "LI-06", "LI-08", "TG-01", "TG-04", "TG-05", "TG-07", "EV-01", "EV-03", "EV-04", "EV-06", "EV-07", "EV-09", "OA-01", "OA-03", "OA-04", "OA-07", "BH-03", "BH-04", "BH-05", "CR-01", "CR-02", "CR-03" ], "recommended_controls": [ "LI-02", "LI-03", "LI-05", "LI-07", "LI-09", "LI-10", "TG-02", "TG-03", "TG-06", "TG-08", "EV-02", "EV-05", "EV-08", "EV-10", "OA-02", "OA-05", "OA-06", "OA-08", "BH-01", "BH-02", "BH-06", "BH-07", "BH-08", "BH-09", "BH-10", "CR-04", "CR-05", "CR-06", "CR-07", "CR-08" ], "not_applicable_controls": [], "not_applicable_rationale": null, "required_control_count": 24, "recommended_control_count": 30, "profile_specific_notes": { "EV-03": "Dangerous capability assessment (EV-03) is required — not optional — for frontier models. The assessment must cover all relevant capability domains including cyber offense, biological design, chemical synthesis, persuasion at scale, autonomous AI R&D, and self-proliferation. No ATLAS technique ID directly maps to capability-threshold crossing — document this as a frontier assurance gap in MITRE mappings.", "EV-04": "Adversarial red-team testing (EV-04) must include structured elicitation attempts for all dangerous capability domains identified in EV-03. Red team must be independent and include domain experts (biosecurity, cybersecurity, nuclear safety as applicable).", "capability_level_derivation": "capability_level: 'frontier' triggers this profile. The other capability_risk fields (capability_domains, autonomy, external_reach, irreversibility) provide specificity for determining which controls are most critical within the profile.", "frontier_framework_references": [ "Anthropic Responsible Scaling Policy v3.3 (effective 2026-05-26)", "Google DeepMind Frontier Safety Framework v3.1 (published 2026-04-17)", "OpenAI Preparedness Framework v2 and Frontier Governance Framework (May 2026)" ], "no_control_exclusions": "Unlike the general-predictive-ml profile which excludes EV-03 and EV-04, the frontier-capability profile has no excluded controls. All 54 controls should be assessed; recommended_controls lists those not elevated to required beyond the baseline.", "material_change_gate": "For frontier models, any model update, fine-tuning, prompt change, capability addition, or tool integration must be evaluated through the material change determination process (CR-03) before deployment. The default posture is to treat all changes as material and require re-evaluation unless EV-03 demonstrates the update does not cross additional capability thresholds." }, "eu_ai_act_mapping": null } ], "patterns": [ { "control_id": "LI-01", "layer": "LI", "name": "Unique Model Identity and Content-Addressed Version Hash", "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.", "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." ], "implementers": [ "ML Engineering", "MLOps", "Platform Engineering" ], "thesis_type": "preventive" }, { "control_id": "LI-02", "layer": "LI", "name": "Model Provenance Chain — Base Model, Fine-Tune, Merge, and Adapter Lineage", "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.", "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." ], "implementers": [ "ML Engineering", "MLOps", "Model Governance" ], "thesis_type": "preventive" }, { "control_id": "LI-03", "layer": "LI", "name": "Supply Chain Integrity — Third-Party Model Verification and Cryptographic...", "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.", "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." ], "implementers": [ "ML Engineering", "Platform Engineering", "Security Engineering" ], "thesis_type": "preventive" }, { "control_id": "LI-04", "layer": "LI", "name": "Structured Model Documentation — Complete Model Card with All Required Sections", "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.", "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." ], "implementers": [ "ML Engineering", "Model Governance", "Compliance" ], "thesis_type": "directive" }, { "control_id": "LI-05", "layer": "LI", "name": "Training Data Lineage Pointer — Link from Model Registry to TG-Layer Dataset...", "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.", "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." ], "implementers": [ "ML Engineering", "Data Engineering", "MLOps" ], "thesis_type": "directive" }, { "control_id": "LI-06", "layer": "LI", "name": "Immutable Version Control with Tested Rollback and Emergency Disable", "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.", "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." ], "implementers": [ "MLOps", "Platform Engineering", "ML Engineering" ], "thesis_type": "corrective" }, { "control_id": "LI-07", "layer": "LI", "name": "Capability and Limitation Declaration — Intended Use, Constraints,...", "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.", "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." ], "implementers": [ "ML Engineering", "Model Governance", "Legal/Compliance" ], "thesis_type": "directive" }, { "control_id": "LI-08", "layer": "LI", "name": "License and IP Governance — Dataset License Tracking, Derivative Work...", "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.", "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." ], "implementers": [ "ML Engineering", "Legal/Compliance", "Model Governance" ], "thesis_type": "preventive" }, { "control_id": "LI-09", "layer": "LI", "name": "Material-Change Determination and Authorization Gate", "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.", "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." ], "implementers": [ "MLOps", "Model Governance", "ML Engineering", "Legal/Compliance" ], "thesis_type": "directive" }, { "control_id": "LI-10", "layer": "LI", "name": "Model Retirement and Archive Policy — End-of-Life Procedure, Evidence...", "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.", "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." ], "implementers": [ "MLOps", "Model Governance", "Platform Engineering", "Legal/Compliance" ], "thesis_type": "corrective" }, { "control_id": "TG-01", "layer": "TG", "name": "Training Data Quality Gates", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "TG-02", "layer": "TG", "name": "Bias and Representativeness Assessment", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "TG-03", "layer": "TG", "name": "Data Rights, Lawful Authority and Permitted Use", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "TG-04", "layer": "TG", "name": "Data Poisoning Prevention", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "TG-05", "layer": "TG", "name": "Train/Evaluation/Test Separation and Contamination Prevention", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "TG-06", "layer": "TG", "name": "Sensitive-Data Necessity, Minimization and Controlled Use", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "TG-07", "layer": "TG", "name": "Third-Party Dataset Governance", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "TG-08", "layer": "TG", "name": "Dataset Retention, Deletion and Lifecycle", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "EV-01", "layer": "EV", "name": "Pre-Deployment Evaluation Gate", "pattern": "Gate-based deployment pipeline with signed evaluation manifests as mandatory, blocking preconditions for production promotion.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "EV-02", "layer": "EV", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "EV-03", "layer": "EV", "name": "Dangerous Capability Threshold Assessment", "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.", "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." ], "implementers": [], "thesis_type": "detective" }, { "control_id": "EV-04", "layer": "EV", "name": "Adversarial Red-Team Testing", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "EV-05", "layer": "EV", "name": "Fairness and Bias Evaluation", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "EV-06", "layer": "EV", "name": "Reproducible Evaluation Design", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "EV-07", "layer": "EV", "name": "Regression Testing on Updates", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "EV-08", "layer": "EV", "name": "Independent Validation", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "EV-09", "layer": "EV", "name": "Risk and Applicability Classification", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "EV-10", "layer": "EV", "name": "Evaluation Result Provenance", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "OA-01", "layer": "OA", "name": "Model Ownership Assignment", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "OA-02", "layer": "OA", "name": "Meaningful Human Oversight for High-Stakes Decisions", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "OA-03", "layer": "OA", "name": "AI Model Governance Committee", "pattern": "Charter-first governance: approve a formal committee charter at executive level before operationalizing any AI governance processes.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "OA-04", "layer": "OA", "name": "Delegated Autonomy Tier Governance", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "OA-05", "layer": "OA", "name": "Regulatory and Legal Review Sign-Off", "pattern": "Deployment gate with legal sign-off: regulatory review is embedded in the model deployment checklist as a required step, not an optional advisory.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "OA-06", "layer": "OA", "name": "Third-Party Model and Vendor Risk Oversight", "pattern": "Vendor risk lifecycle: pre-contract due diligence → contract terms → version pinning → ongoing monitoring → periodic re-assessment → exit planning.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "OA-07", "layer": "OA", "name": "Incident Escalation Authority Chain", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "OA-08", "layer": "OA", "name": "Notice, Explanation Support, Human Review and Contestability", "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.", "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." ], "implementers": [], "thesis_type": "directive" }, { "control_id": "BH-01", "layer": "BH", "name": "Output Anomaly Detection", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "BH-02", "layer": "BH", "name": "Concept and Data Drift Detection", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "BH-03", "layer": "BH", "name": "Production Performance Degradation Alerting", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "BH-04", "layer": "BH", "name": "Behavioral Boundary Performance Testing", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "BH-05", "layer": "BH", "name": "Usage Telemetry and Decision Logging", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "BH-06", "layer": "BH", "name": "Injection-Resistance Evaluation in Production", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "BH-07", "layer": "BH", "name": "Resource and Cost Anomaly Monitoring", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "BH-08", "layer": "BH", "name": "Shadow and Canary Deployment Governance", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "BH-09", "layer": "BH", "name": "Synthetic-Content Provenance, Disclosure and Traceability", "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.", "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." ], "implementers": [], "thesis_type": "directive" }, { "control_id": "BH-10", "layer": "BH", "name": "Feedback Loop Integrity and Online Learning Governance", "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.", "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." ], "implementers": [], "thesis_type": null }, { "control_id": "CR-01", "layer": "CR", "name": "Continuous Production Monitoring and Risk Aggregation", "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).", "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" ], "implementers": [], "thesis_type": "detective" }, { "control_id": "CR-02", "layer": "CR", "name": "Model Evidence Archive and Audit Trail", "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.", "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" ], "implementers": [], "thesis_type": "corrective" }, { "control_id": "CR-03", "layer": "CR", "name": "Scheduled Model Re-validation", "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.", "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" ], "implementers": [], "thesis_type": "corrective" }, { "control_id": "CR-04", "layer": "CR", "name": "AI Incident Response Management", "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.", "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" ], "implementers": [], "thesis_type": "corrective" }, { "control_id": "CR-05", "layer": "CR", "name": "Regulatory Notification and Statutory Reporting", "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.", "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)" ], "implementers": [], "thesis_type": "directive" }, { "control_id": "CR-06", "layer": "CR", "name": "Post-Market Surveillance", "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.", "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" ], "implementers": [], "thesis_type": "detective" }, { "control_id": "CR-07", "layer": "CR", "name": "Model Retirement and Evidence Archival", "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.", "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" ], "implementers": [], "thesis_type": "corrective" }, { "control_id": "CR-08", "layer": "CR", "name": "Cross-Domain Assurance Coordination", "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.", "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" ], "implementers": [], "thesis_type": "compensating" } ], "threat_scenarios": [ { "tag": "MR-DEV", "control_count": 15, "controls": [ "TG-01", "TG-02", "TG-03", "TG-04", "TG-05", "TG-06", "TG-07", "TG-08", "OA-01", "OA-03", "OA-04", "OA-05", "OA-06", "BH-08", "BH-10" ], "desc_samples": [ { "control_id": "TG-01", "excerpt": "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." }, { "control_id": "TG-02", "excerpt": "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." }, { "control_id": "TG-03", "excerpt": "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 be" } ] }, { "tag": "EU-AIA-AnnexIII", "control_count": 15, "controls": [ "TG-02", "TG-03", "TG-06", "TG-08", "EV-03", "EV-05", "EV-09", "OA-01", "OA-02", "OA-03", "OA-05", "OA-07", "OA-08", "BH-05", "BH-09" ], "desc_samples": [ { "control_id": "TG-02", "excerpt": "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." }, { "control_id": "TG-03", "excerpt": "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 be" }, { "control_id": "TG-06", "excerpt": "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 carefu" } ] }, { "tag": "MR-PERFORMANCE", "control_count": 15, "controls": [ "TG-05", "EV-01", "EV-02", "EV-05", "EV-06", "EV-07", "EV-10", "OA-02", "OA-08", "BH-02", "BH-03", "BH-04", "BH-06", "BH-08", "BH-09" ], "desc_samples": [ { "control_id": "TG-05", "excerpt": "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 w" }, { "control_id": "EV-01", "excerpt": "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." }, { "control_id": "EV-02", "excerpt": "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." } ] }, { "tag": "MR-VAL", "control_count": 12, "controls": [ "TG-02", "TG-05", "EV-01", "EV-02", "EV-03", "EV-04", "EV-05", "EV-06", "EV-07", "EV-08", "EV-09", "EV-10" ], "desc_samples": [ { "control_id": "TG-02", "excerpt": "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." }, { "control_id": "TG-05", "excerpt": "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 w" }, { "control_id": "EV-01", "excerpt": "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." } ] }, { "tag": "MR-MONITORING", "control_count": 9, "controls": [ "OA-02", "OA-04", "OA-07", "BH-01", "BH-02", "BH-03", "BH-05", "BH-07", "BH-10" ], "desc_samples": [ { "control_id": "OA-02", "excerpt": "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 sub" }, { "control_id": "OA-04", "excerpt": "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." }, { "control_id": "OA-07", "excerpt": "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 ha" } ] }, { "tag": "LLM04:2025", "control_count": 8, "controls": [ "TG-01", "TG-04", "TG-06", "TG-07", "EV-04", "EV-07", "BH-01", "BH-10" ], "desc_samples": [ { "control_id": "TG-01", "excerpt": "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." }, { "control_id": "TG-04", "excerpt": "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.T0" }, { "control_id": "TG-06", "excerpt": "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 carefu" } ] }, { "tag": "governance-gap", "control_count": 7, "controls": [ "LI-02", "LI-04", "LI-05", "LI-07", "LI-08", "LI-09", "LI-10" ], "desc_samples": [ { "control_id": "LI-02", "excerpt": "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 — Backdoor ML Model) can propagate its behavior into downstream derived mo" }, { "control_id": "LI-04", "excerpt": "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 m" }, { "control_id": "LI-05", "excerpt": "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, consen" } ] }, { "tag": "supply-chain-compromise", "control_count": 6, "controls": [ "LI-01", "LI-02", "LI-03", "LI-05", "LI-06", "LI-08" ], "desc_samples": [ { "control_id": "LI-01", "excerpt": "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 ML Model Access) can substitute a backdoored or degraded model while preserving the model label. Absent content-add" }, { "control_id": "LI-02", "excerpt": "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 — Backdoor ML Model) can propagate its behavior into downstream derived mo" }, { "control_id": "LI-03", "excerpt": "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 — Backdoor ML Model). An attacker who compromises a model hub or CDN can substitute a backdoored or trojaned a" } ] }, { "tag": "undisclosed-model-change", "control_count": 5, "controls": [ "LI-01", "LI-02", "LI-03", "LI-06", "LI-09" ], "desc_samples": [ { "control_id": "LI-01", "excerpt": "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 ML Model Access) can substitute a backdoored or degraded model while preserving the model label. Absent content-add" }, { "control_id": "LI-02", "excerpt": "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 — Backdoor ML Model) can propagate its behavior into downstream derived mo" }, { "control_id": "LI-03", "excerpt": "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 — Backdoor ML Model). An attacker who compromises a model hub or CDN can substitute a backdoored or trojaned a" } ] }, { "tag": "unauthorized-deployment", "control_count": 4, "controls": [ "LI-01", "LI-03", "LI-06", "LI-09" ], "desc_samples": [ { "control_id": "LI-01", "excerpt": "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 ML Model Access) can substitute a backdoored or degraded model while preserving the model label. Absent content-add" }, { "control_id": "LI-03", "excerpt": "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 — Backdoor ML Model). An attacker who compromises a model hub or CDN can substitute a backdoored or trojaned a" }, { "control_id": "LI-06", "excerpt": "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 ML Model Access) and through accidental CI/CD pipeline errors. Without immutable" } ] }, { "tag": "accountability-gap", "control_count": 4, "controls": [ "LI-04", "LI-05", "LI-07", "LI-10" ], "desc_samples": [ { "control_id": "LI-04", "excerpt": "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 m" }, { "control_id": "LI-05", "excerpt": "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, consen" }, { "control_id": "LI-07", "excerpt": "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," } ] }, { "tag": "AML.T0020", "control_count": 4, "controls": [ "TG-01", "TG-04", "BH-02", "BH-10" ], "desc_samples": [ { "control_id": "TG-01", "excerpt": "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." }, { "control_id": "TG-04", "excerpt": "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.T0" }, { "control_id": "BH-02", "excerpt": "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)." } ] }, { "tag": "AML.T0018", "control_count": 3, "controls": [ "TG-04", "TG-07", "OA-06" ], "desc_samples": [ { "control_id": "TG-04", "excerpt": "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.T0" }, { "control_id": "TG-07", "excerpt": "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." }, { "control_id": "OA-06", "excerpt": "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" } ] }, { "tag": "LLM09:2025", "control_count": 3, "controls": [ "EV-02", "OA-08", "BH-09" ], "desc_samples": [ { "control_id": "EV-02", "excerpt": "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." }, { "control_id": "OA-08", "excerpt": "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 out" }, { "control_id": "BH-09", "excerpt": "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" } ] }, { "tag": "AML.T0051", "control_count": 3, "controls": [ "EV-04", "BH-04", "BH-06" ], "desc_samples": [ { "control_id": "EV-04", "excerpt": "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" }, { "control_id": "BH-04", "excerpt": "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 bound" }, { "control_id": "BH-06", "excerpt": "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 resist" } ] }, { "tag": "LLM01:2025", "control_count": 3, "controls": [ "EV-04", "BH-04", "BH-06" ], "desc_samples": [ { "control_id": "EV-04", "excerpt": "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" }, { "control_id": "BH-04", "excerpt": "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 bound" }, { "control_id": "BH-06", "excerpt": "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 resist" } ] }, { "tag": "AML.T0024", "control_count": 3, "controls": [ "BH-01", "BH-05", "BH-07" ], "desc_samples": [ { "control_id": "BH-01", "excerpt": "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." }, { "control_id": "BH-05", "excerpt": "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." }, { "control_id": "BH-07", "excerpt": "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-volum" } ] }, { "tag": "regulatory-noncompliance", "control_count": 2, "controls": [ "LI-04", "LI-08" ], "desc_samples": [ { "control_id": "LI-04", "excerpt": "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 m" }, { "control_id": "LI-08", "excerpt": "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 constraint" } ] }, { "tag": "silent-model-degradation", "control_count": 2, "controls": [ "CR-01", "CR-03" ], "desc_samples": [ { "control_id": "CR-01", "excerpt": "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 aggr" }, { "control_id": "CR-03", "excerpt": "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, the" } ] }, { "tag": "regulatory-notification-failure", "control_count": 2, "controls": [ "CR-04", "CR-05" ], "desc_samples": [ { "control_id": "CR-04", "excerpt": "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 " }, { "control_id": "CR-05", "excerpt": "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 S-6.1 requires board-level model risk reporting. Notificati" } ] }, { "tag": "missing-rollback", "control_count": 1, "controls": [ "LI-06" ], "desc_samples": [ { "control_id": "LI-06", "excerpt": "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 ML Model Access) and through accidental CI/CD pipeline errors. Without immutable" } ] }, { "tag": "harmful-output", "control_count": 1, "controls": [ "LI-07" ], "desc_samples": [ { "control_id": "LI-07", "excerpt": "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," } ] }, { "tag": "stale-evidence", "control_count": 1, "controls": [ "LI-10" ], "desc_samples": [ { "control_id": "LI-10", "excerpt": "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 report" } ] }, { "tag": "LLM03:2025", "control_count": 1, "controls": [ "OA-06" ], "desc_samples": [ { "control_id": "OA-06", "excerpt": "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" } ] }, { "tag": "LLM10:2025", "control_count": 1, "controls": [ "BH-07" ], "desc_samples": [ { "control_id": "BH-07", "excerpt": "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-volum" } ] }, { "tag": "undetected-drift", "control_count": 1, "controls": [ "CR-01" ], "desc_samples": [ { "control_id": "CR-01", "excerpt": "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 aggr" } ] }, { "tag": "compliance-gap", "control_count": 1, "controls": [ "CR-01" ], "desc_samples": [ { "control_id": "CR-01", "excerpt": "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 aggr" } ] }, { "tag": "late-incident-detection", "control_count": 1, "controls": [ "CR-01" ], "desc_samples": [ { "control_id": "CR-01", "excerpt": "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 aggr" } ] }, { "tag": "evidence-tampering", "control_count": 1, "controls": [ "CR-02" ], "desc_samples": [ { "control_id": "CR-02", "excerpt": "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. Regulators under EU AI Act Art. 12, SR 26-2 S-5.2, and ISO 42" } ] }, { "tag": "audit-failure", "control_count": 1, "controls": [ "CR-02" ], "desc_samples": [ { "control_id": "CR-02", "excerpt": "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. Regulators under EU AI Act Art. 12, SR 26-2 S-5.2, and ISO 42" } ] }, { "tag": "regulatory-non-compliance", "control_count": 1, "controls": [ "CR-02" ], "desc_samples": [ { "control_id": "CR-02", "excerpt": "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. Regulators under EU AI Act Art. 12, SR 26-2 S-5.2, and ISO 42" } ] }, { "tag": "incident-attribution-loss", "control_count": 1, "controls": [ "CR-02" ], "desc_samples": [ { "control_id": "CR-02", "excerpt": "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. Regulators under EU AI Act Art. 12, SR 26-2 S-5.2, and ISO 42" } ] }, { "tag": "distribution-shift", "control_count": 1, "controls": [ "CR-03" ], "desc_samples": [ { "control_id": "CR-03", "excerpt": "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, the" } ] }, { "tag": "world-knowledge-staleness", "control_count": 1, "controls": [ "CR-03" ], "desc_samples": [ { "control_id": "CR-03", "excerpt": "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, the" } ] }, { "tag": "infrastructure-induced-regression", "control_count": 1, "controls": [ "CR-03" ], "desc_samples": [ { "control_id": "CR-03", "excerpt": "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, the" } ] }, { "tag": "uncontained-model-harm", "control_count": 1, "controls": [ "CR-04" ], "desc_samples": [ { "control_id": "CR-04", "excerpt": "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 " } ] }, { "tag": "slow-incident-escalation", "control_count": 1, "controls": [ "CR-04" ], "desc_samples": [ { "control_id": "CR-04", "excerpt": "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 " } ] }, { "tag": "adversarial-attack-response-gap", "control_count": 1, "controls": [ "CR-04" ], "desc_samples": [ { "control_id": "CR-04", "excerpt": "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 " } ] }, { "tag": "statutory-deadline-miss", "control_count": 1, "controls": [ "CR-05" ], "desc_samples": [ { "control_id": "CR-05", "excerpt": "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 S-6.1 requires board-level model risk reporting. Notificati" } ] }, { "tag": "enforcement-action-risk", "control_count": 1, "controls": [ "CR-05" ], "desc_samples": [ { "control_id": "CR-05", "excerpt": "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 S-6.1 requires board-level model risk reporting. Notificati" } ] }, { "tag": "cross-jurisdiction-compliance-gap", "control_count": 1, "controls": [ "CR-05" ], "desc_samples": [ { "control_id": "CR-05", "excerpt": "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 S-6.1 requires board-level model risk reporting. Notificati" } ] }, { "tag": "unknown-harm-accumulation", "control_count": 1, "controls": [ "CR-06" ], "desc_samples": [ { "control_id": "CR-06", "excerpt": "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 explicit" } ] }, { "tag": "vulnerability-disclosure-gap", "control_count": 1, "controls": [ "CR-06" ], "desc_samples": [ { "control_id": "CR-06", "excerpt": "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 explicit" } ] }, { "tag": "user-harm-under-reporting", "control_count": 1, "controls": [ "CR-06" ], "desc_samples": [ { "control_id": "CR-06", "excerpt": "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 explicit" } ] }, { "tag": "third-party-research-blind-spot", "control_count": 1, "controls": [ "CR-06" ], "desc_samples": [ { "control_id": "CR-06", "excerpt": "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 explicit" } ] }, { "tag": "orphaned-model-exposure", "control_count": 1, "controls": [ "CR-07" ], "desc_samples": [ { "control_id": "CR-07", "excerpt": "Retired models that leave orphaned inference endpoints, stale credentials, or incomplete evidence handoff create persistent attack surface (AML.T0044 — Full ML Model Access via forgotten endpoints) and regulatory liability. EU AI Act Art. 13 and ISO 42001 A.6.3 require that end-of-life AI systems ar" } ] }, { "tag": "evidence-loss-at-retirement", "control_count": 1, "controls": [ "CR-07" ], "desc_samples": [ { "control_id": "CR-07", "excerpt": "Retired models that leave orphaned inference endpoints, stale credentials, or incomplete evidence handoff create persistent attack surface (AML.T0044 — Full ML Model Access via forgotten endpoints) and regulatory liability. EU AI Act Art. 13 and ISO 42001 A.6.3 require that end-of-life AI systems ar" } ] }, { "tag": "data-retention-violation", "control_count": 1, "controls": [ "CR-07" ], "desc_samples": [ { "control_id": "CR-07", "excerpt": "Retired models that leave orphaned inference endpoints, stale credentials, or incomplete evidence handoff create persistent attack surface (AML.T0044 — Full ML Model Access via forgotten endpoints) and regulatory liability. EU AI Act Art. 13 and ISO 42001 A.6.3 require that end-of-life AI systems ar" } ] }, { "tag": "ghost-endpoint-attack-surface", "control_count": 1, "controls": [ "CR-07" ], "desc_samples": [ { "control_id": "CR-07", "excerpt": "Retired models that leave orphaned inference endpoints, stale credentials, or incomplete evidence handoff create persistent attack surface (AML.T0044 — Full ML Model Access via forgotten endpoints) and regulatory liability. EU AI Act Art. 13 and ISO 42001 A.6.3 require that end-of-life AI systems ar" } ] }, { "tag": "cross-domain-assurance-gap", "control_count": 1, "controls": [ "CR-08" ], "desc_samples": [ { "control_id": "CR-08", "excerpt": "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 b" } ] }, { "tag": "unresolved-uri-reference", "control_count": 1, "controls": [ "CR-08" ], "desc_samples": [ { "control_id": "CR-08", "excerpt": "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 b" } ] }, { "tag": "siloed-compliance-view", "control_count": 1, "controls": [ "CR-08" ], "desc_samples": [ { "control_id": "CR-08", "excerpt": "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 b" } ] }, { "tag": "inter-domain-control-overlap", "control_count": 1, "controls": [ "CR-08" ], "desc_samples": [ { "control_id": "CR-08", "excerpt": "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 b" } ] } ], "framework_coverage": [ { "framework": "nist_rmf", "display_name": "NIST AI RMF 1.0", "authority": "NIST", "total_mappings": 54, "fit_distribution": { "direct": 10, "partial": 44, "adjacent": 0, "supporting": 0, "none": 0 }, "by_layer": { "LI": 10, "TG": 8, "EV": 10, "OA": 8, "BH": 10, "CR": 8 }, "by_confidence": { "verified": 0, "high": 24, "medium": 4, "low": 0, "speculative": 0 }, "controls_mapped": [ "LI-01", "LI-02", "LI-03", "LI-04", "LI-05", "LI-06", "LI-07", "LI-08", "LI-09", "LI-10", "TG-01", "TG-02", "TG-03", "TG-04", "TG-05", "TG-06", "TG-07", "TG-08", "EV-01", "EV-02", "EV-03", "EV-04", "EV-05", "EV-06", "EV-07", "EV-08", "EV-09", "EV-10", "OA-01", "OA-02", "OA-03", "OA-04", "OA-05", "OA-06", "OA-07", "OA-08", "BH-01", "BH-02", "BH-03", "BH-04", "BH-05", "BH-06", "BH-07", "BH-08", "BH-09", "BH-10", "CR-01", "CR-02", "CR-03", "CR-04", "CR-05", "CR-06", "CR-07", "CR-08" ], "controls_mapped_count": 54, "coverage_pct": 100 }, { "framework": "nist_ai_600_1", "display_name": "NIST AI 600-1 GenAI Profile", "authority": "NIST", "total_mappings": 7, "fit_distribution": { "direct": 3, "partial": 4, "adjacent": 0, "supporting": 0, "none": 0 }, "by_layer": { "LI": 0, "TG": 1, "EV": 4, "OA": 0, "BH": 2, "CR": 0 }, "by_confidence": { "verified": 0, "high": 0, "medium": 7, "low": 0, "speculative": 0 }, "controls_mapped": [ "TG-03", "EV-02", "EV-03", "EV-04", "EV-05", "BH-04", "BH-09" ], "controls_mapped_count": 7, "coverage_pct": 13 }, { "framework": "iso_42001", "display_name": "ISO/IEC 42001:2023", "authority": "ISO/IEC JTC 1/SC 42", "total_mappings": 54, "fit_distribution": { "direct": 6, "partial": 48, "adjacent": 0, "supporting": 0, "none": 0 }, "by_layer": { "LI": 10, "TG": 8, "EV": 10, "OA": 8, "BH": 10, "CR": 8 }, "by_confidence": { "verified": 0, "high": 27, "medium": 2, "low": 0, "speculative": 0 }, "controls_mapped": [ "LI-01", "LI-02", "LI-03", "LI-04", "LI-05", "LI-06", "LI-07", "LI-08", "LI-09", "LI-10", "TG-01", "TG-02", "TG-03", "TG-04", "TG-05", "TG-06", "TG-07", "TG-08", "EV-01", "EV-02", "EV-03", "EV-04", "EV-05", "EV-06", "EV-07", "EV-08", "EV-09", "EV-10", "OA-01", "OA-02", "OA-03", "OA-04", "OA-05", "OA-06", "OA-07", "OA-08", "BH-01", "BH-02", "BH-03", "BH-04", "BH-05", "BH-06", "BH-07", "BH-08", "BH-09", "BH-10", "CR-01", "CR-02", "CR-03", "CR-04", "CR-05", "CR-06", "CR-07", "CR-08" ], "controls_mapped_count": 54, "coverage_pct": 100 }, { "framework": "eu_ai_act", "display_name": "EU AI Act (Regulation 2024/1689)", "authority": "European Parliament and Council", "total_mappings": 47, "fit_distribution": { "direct": 7, "partial": 35, "adjacent": 5, "supporting": 0, "none": 0 }, "by_layer": { "LI": 5, "TG": 8, "EV": 10, "OA": 6, "BH": 10, "CR": 8 }, "by_confidence": { "verified": 0, "high": 21, "medium": 2, "low": 0, "speculative": 0 }, "controls_mapped": [ "LI-04", "LI-06", "LI-07", "LI-09", "LI-10", "TG-01", "TG-02", "TG-03", "TG-04", "TG-05", "TG-06", "TG-07", "TG-08", "EV-01", "EV-02", "EV-03", "EV-04", "EV-05", "EV-06", "EV-07", "EV-08", "EV-09", "EV-10", "OA-01", "OA-02", "OA-03", "OA-05", "OA-07", "OA-08", "BH-01", "BH-02", "BH-03", "BH-04", "BH-05", "BH-06", "BH-07", "BH-08", "BH-09", "BH-10", "CR-01", "CR-02", "CR-03", "CR-04", "CR-05", "CR-06", "CR-07", "CR-08" ], "controls_mapped_count": 47, "coverage_pct": 87 }, { "framework": "sr262", "display_name": "SR 26-2 — Model Risk Management", "authority": "Federal Reserve Board", "total_mappings": 43, "fit_distribution": { "direct": 8, "partial": 30, "adjacent": 5, "supporting": 0, "none": 0 }, "by_layer": { "LI": 6, "TG": 8, "EV": 10, "OA": 6, "BH": 5, "CR": 8 }, "by_confidence": { "verified": 0, "high": 5, "medium": 14, "low": 0, "speculative": 0 }, "controls_mapped": [ "LI-01", "LI-04", "LI-05", "LI-06", "LI-09", "LI-10", "TG-01", "TG-02", "TG-03", "TG-04", "TG-05", "TG-06", "TG-07", "TG-08", "EV-01", "EV-02", "EV-03", "EV-04", "EV-05", "EV-06", "EV-07", "EV-08", "EV-09", "EV-10", "OA-01", "OA-02", "OA-03", "OA-05", "OA-06", "OA-07", "BH-01", "BH-02", "BH-03", "BH-05", "BH-10", "CR-01", "CR-02", "CR-03", "CR-04", "CR-05", "CR-06", "CR-07", "CR-08" ], "controls_mapped_count": 43, "coverage_pct": 80 }, { "framework": "aisvs", "display_name": "OWASP AI Security Verification Standard v1.0", "authority": "OWASP", "total_mappings": 21, "fit_distribution": { "direct": 3, "partial": 17, "adjacent": 1, "supporting": 0, "none": 0 }, "by_layer": { "LI": 2, "TG": 8, "EV": 10, "OA": 1, "BH": 0, "CR": 0 }, "by_confidence": { "verified": 0, "high": 2, "medium": 0, "low": 0, "speculative": 0 }, "controls_mapped": [ "LI-01", "LI-02", "TG-01", "TG-02", "TG-03", "TG-04", "TG-05", "TG-06", "TG-07", "TG-08", "EV-01", "EV-02", "EV-03", "EV-04", "EV-05", "EV-06", "EV-07", "EV-08", "EV-09", "EV-10", "OA-08" ], "controls_mapped_count": 21, "coverage_pct": 39 }, { "framework": "llm10", "display_name": "OWASP LLM Top 10 2025", "authority": "OWASP", "total_mappings": 23, "fit_distribution": { "direct": 2, "partial": 14, "adjacent": 7, "supporting": 0, "none": 0 }, "by_layer": { "LI": 3, "TG": 8, "EV": 10, "OA": 2, "BH": 0, "CR": 0 }, "by_confidence": { "verified": 0, "high": 1, "medium": 1, "low": 1, "speculative": 0 }, "controls_mapped": [ "LI-03", "LI-07", "LI-08", "TG-01", "TG-02", "TG-03", "TG-04", "TG-05", "TG-06", "TG-07", "TG-08", "EV-01", "EV-02", "EV-03", "EV-04", "EV-05", "EV-06", "EV-07", "EV-08", "EV-09", "EV-10", "OA-06", "OA-08" ], "controls_mapped_count": 23, "coverage_pct": 43 }, { "framework": "aicm", "display_name": "CSA AI Controls Matrix v1.1", "authority": "Cloud Security Alliance", "total_mappings": 45, "fit_distribution": { "direct": 26, "partial": 15, "adjacent": 1, "supporting": 3, "none": 0 }, "by_layer": { "LI": 1, "TG": 8, "EV": 10, "OA": 8, "BH": 10, "CR": 8 }, "by_confidence": { "verified": 0, "high": 0, "medium": 45, "low": 0, "speculative": 0 }, "controls_mapped": [ "LI-08", "TG-01", "TG-02", "TG-03", "TG-04", "TG-05", "TG-06", "TG-07", "TG-08", "EV-01", "EV-02", "EV-03", "EV-04", "EV-05", "EV-06", "EV-07", "EV-08", "EV-09", "EV-10", "OA-01", "OA-02", "OA-03", "OA-04", "OA-05", "OA-06", "OA-07", "OA-08", "BH-01", "BH-02", "BH-03", "BH-04", "BH-05", "BH-06", "BH-07", "BH-08", "BH-09", "BH-10", "CR-01", "CR-02", "CR-03", "CR-04", "CR-05", "CR-06", "CR-07", "CR-08" ], "controls_mapped_count": 45, "coverage_pct": 83 }, { "framework": "mitre", "display_name": "MITRE ATLAS v5.6.0", "authority": "MITRE Corporation", "total_mappings": 25, "fit_distribution": { "direct": 1, "partial": 13, "adjacent": 11, "supporting": 0, "none": 0 }, "by_layer": { "LI": 6, "TG": 8, "EV": 10, "OA": 1, "BH": 0, "CR": 0 }, "by_confidence": { "verified": 0, "high": 0, "medium": 4, "low": 2, "speculative": 0 }, "controls_mapped": [ "LI-01", "LI-02", "LI-03", "LI-04", "LI-05", "LI-06", "TG-01", "TG-02", "TG-03", "TG-04", "TG-05", "TG-06", "TG-07", "TG-08", "EV-01", "EV-02", "EV-03", "EV-04", "EV-05", "EV-06", "EV-07", "EV-08", "EV-09", "EV-10", "OA-06" ], "controls_mapped_count": 25, "coverage_pct": 46 }, { "framework": "owasp_aitg", "display_name": "OWASP AI Testing Guide v1", "authority": "OWASP", "total_mappings": 52, "fit_distribution": { "direct": 26, "partial": 10, "adjacent": 4, "supporting": 12, "none": 0 }, "by_layer": { "LI": 9, "TG": 8, "EV": 10, "OA": 8, "BH": 9, "CR": 8 }, "by_confidence": { "verified": 0, "high": 0, "medium": 52, "low": 0, "speculative": 0 }, "controls_mapped": [ "LI-01", "LI-02", "LI-03", "LI-04", "LI-05", "LI-06", "LI-08", "LI-09", "LI-10", "TG-01", "TG-02", "TG-03", "TG-04", "TG-05", "TG-06", "TG-07", "TG-08", "EV-01", "EV-02", "EV-03", "EV-04", "EV-05", "EV-06", "EV-07", "EV-08", "EV-09", "EV-10", "OA-01", "OA-02", "OA-03", "OA-04", "OA-05", "OA-06", "OA-07", "OA-08", "BH-01", "BH-02", "BH-03", "BH-04", "BH-05", "BH-06", "BH-08", "BH-09", "BH-10", "CR-01", "CR-02", "CR-03", "CR-04", "CR-05", "CR-06", "CR-07", "CR-08" ], "controls_mapped_count": 52, "coverage_pct": 96 } ], "regulatory_coverage": [ { "framework_key": "eu_ai_act", "instrument": "Regulation (EU) 2024/1689", "authority": "European Union — European Parliament and Council", "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2027-12-02", "jurisdiction": [ "eu" ], "sector": [ "cross-sector" ], "controls": [ "LI-04", "LI-06", "LI-07", "LI-09", "LI-10", "TG-01", "TG-02", "TG-03", "TG-04", "TG-05", "TG-06", "TG-07", "TG-08", "EV-01", "EV-02", "EV-03", "EV-04", "EV-05", "EV-06", "EV-07", "EV-08", "EV-09", "EV-10", "OA-01", "OA-02", "OA-03", "OA-05", "OA-07", "OA-08", "BH-01", "BH-02", "BH-03", "BH-04", "BH-05", "BH-06", "BH-07", "BH-08", "BH-09", "BH-10", "CR-01", "CR-02", "CR-03", "CR-04", "CR-05", "CR-06", "CR-07", "CR-08" ], "provision_count": 69, "control_count": 47 }, { "framework_key": "sr262", "instrument": "SR 26-2", "authority": "Board of Governors of the Federal Reserve System", "normative_force": "supervisory-guidance", "legal_status": "enacted", "effective_from": "2026-04-01", "jurisdiction": [ "us" ], "sector": [ "banking", "financial-services" ], "controls": [ "LI-09", "EV-08", "EV-09", "BH-05", "CR-01" ], "provision_count": 5, "control_count": 5 }, { "framework_key": null, "instrument": "Regulation (EU) 2016/679", "authority": "European Union", "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2018-05-25", "jurisdiction": [ "eu" ], "sector": [], "controls": [ "TG-03", "TG-06", "TG-08", "OA-08", "BH-05" ], "provision_count": 9, "control_count": 5 }, { "framework_key": null, "instrument": "California Consumer Privacy Act (CCPA/CPRA)", "authority": "California Privacy Protection Agency", "normative_force": "binding-law", "legal_status": "enacted", "effective_from": "2023-01-01", "jurisdiction": [ "us-california" ], "sector": [], "controls": [ "TG-03", "TG-08" ], "provision_count": 2, "control_count": 2 }, { "framework_key": null, "instrument": "Fair Credit Reporting Act (FCRA)", "authority": "US Congress / CFPB", "normative_force": "binding-law", "legal_status": "enacted", "effective_from": null, "jurisdiction": [ "us" ], "sector": [], "controls": [ "OA-08" ], "provision_count": 1, "control_count": 1 }, { "framework_key": null, "instrument": "NIST AI 100-4", "authority": "NIST", "normative_force": "best-practice", "legal_status": "enacted", "effective_from": null, "jurisdiction": [ "us" ], "sector": [], "controls": [ "BH-09" ], "provision_count": 1, "control_count": 1 }, { "framework_key": null, "instrument": "C2PA Specification", "authority": "Coalition for Content Provenance and Authenticity", "normative_force": "voluntary", "legal_status": "enacted", "effective_from": null, "jurisdiction": [ "global" ], "sector": [], "controls": [ "BH-09" ], "provision_count": 1, "control_count": 1 } ], "capability_coverage": [ { "capability_level": "universal", "control_count": 37, "controls": [ "TG-01", "TG-02", "TG-03", "TG-05", "TG-06", "TG-08", "EV-01", "EV-02", "EV-05", "EV-06", "EV-07", "EV-08", "EV-09", "EV-10", "OA-01", "OA-02", "OA-03", "OA-04", "OA-05", "OA-06", "OA-07", "OA-08", "BH-01", "BH-02", "BH-03", "BH-04", "BH-05", "BH-07", "BH-08", "BH-09", "CR-01", "CR-02", "CR-03", "CR-04", "CR-05", "CR-06", "CR-08" ], "by_layer": { "LI": 0, "TG": 6, "EV": 8, "OA": 8, "BH": 8, "CR": 7 } }, { "capability_level": "low", "control_count": 10, "controls": [ "LI-01", "LI-02", "LI-03", "LI-04", "LI-05", "LI-06", "LI-07", "LI-08", "LI-09", "LI-10" ], "by_layer": { "LI": 10, "TG": 0, "EV": 0, "OA": 0, "BH": 0, "CR": 0 } }, { "capability_level": "elevated", "control_count": 4, "controls": [ "TG-04", "EV-04", "BH-06", "BH-10" ], "by_layer": { "LI": 0, "TG": 1, "EV": 1, "OA": 0, "BH": 2, "CR": 0 } }, { "capability_level": "frontier", "control_count": 3, "controls": [ "TG-07", "EV-03", "CR-07" ], "by_layer": { "LI": 0, "TG": 1, "EV": 1, "OA": 0, "BH": 0, "CR": 1 } } ], "capability_coverage_by_domain": {}, "lifecycle": [ { "stage": 1, "layer": "LI", "name": "AI Asset, Lineage and Applicability", "plane": "control", "control_count": 10, "thesis_types": [ "preventive", "directive", "corrective" ], "required_for_baseline": [ "LI-01", "LI-04", "LI-06" ] }, { "stage": 2, "layer": "TG", "name": "Training and Data Governance", "plane": "data", "control_count": 8, "thesis_types": [], "required_for_baseline": [ "TG-01", "TG-05" ] }, { "stage": 3, "layer": "EV", "name": "Evaluation, Independent Validation and Release", "plane": "both", "control_count": 10, "thesis_types": [ "detective" ], "required_for_baseline": [ "EV-01", "EV-06", "EV-07", "EV-09" ] }, { "stage": 4, "layer": "OA", "name": "Governance, Accountability and Use-Case Oversight", "plane": "control", "control_count": 8, "thesis_types": [ "directive" ], "required_for_baseline": [ "OA-01", "OA-07" ] }, { "stage": 5, "layer": "BH", "name": "Deployment and Runtime Assurance", "plane": "data", "control_count": 10, "thesis_types": [ "directive" ], "required_for_baseline": [ "BH-03", "BH-05" ] }, { "stage": 6, "layer": "CR", "name": "Continuous Risk, Incident and Evidence Assurance", "plane": "lifecycle", "control_count": 8, "thesis_types": [ "detective", "corrective", "directive", "compensating" ], "required_for_baseline": [ "CR-01", "CR-02" ] } ] } }