# AI Shared Responsibility: CoSAI SRF Full Content > Authoritative full-content file for aisharedresponsibility.com. Optimized for LLM and agent retrieval. > One accountable party per activity. "Shared" is a valid matrix value but every control resolves to a single named persona. > > Link index: https://aisharedresponsibility.com/llms.txt > Machine-readable JSON: https://aisharedresponsibility.com/data/index.json > Homepage: https://aisharedresponsibility.com/ --- ## Part 1: Core Framework Reference: https://aisharedresponsibility.com/framework/ The CoSAI AI Shared Responsibility Framework (SRF) v1.0 defines accountability across AI deployments using five enterprise architecture layers, eight named personas, and four operating models. Source: CoSAI AI Shared Responsibility Framework Draft V0.7, OASIS Open / Coalition for Secure AI Workstream 2. ### 1.1 The Five Layers Reference: https://aisharedresponsibility.com/framework/ #### L1: AI Business & Usage Governance, strategy, and compliance at the executive and business-unit level. This layer owns regulatory obligations, acceptable-use policy, and incident governance. Cascades security and governance requirements down to all supporting layers. Components: Capabilities & Business Strategy, Processes & Governance, Business Units & Accountability Primary personas at this layer: AI System Users, AI System Governance Operating model responsibility assignments: - AI-SaaS: Shared - AI-PaaS: Customer-owned - Agent-PaaS: Customer-owned - IaaS: Customer-owned #### L2: AI Information Data ownership, quality, and privacy. Accountable for training data provenance, master data management, privacy controls, and data classification decisions that constrain what AI systems can access at runtime. Components: Master Data Management, Privacy Controls & Policies, AI Training Data Primary personas at this layer: Data Provider Operating model responsibility assignments: - AI-SaaS: Shared - AI-PaaS: Shared - Agent-PaaS: Shared - IaaS: Customer-owned #### L3: AI Application Development, integration, and testing of AI-powered applications. Responsible for guardrails, input validation, output filtering, prompt engineering, RAG pipelines, and agent orchestration logic. Components: Agents & Orchestration Models, APIs & Fine-tuned Models, Application Platforms Primary personas at this layer: Application Developer, Agentic Platform & Framework Providers Operating model responsibility assignments: - AI-SaaS: Shared - AI-PaaS: Shared - Agent-PaaS: Shared - IaaS: Customer-owned #### L4: AI Platform Infrastructure, APIs, and runtime services for hosting, training, and serving AI models. Covers compute, LLM gateways, model routers, guardrail infrastructure, and platform-level IAM. Provides the operating environment that L3 applications run on. Components: Guardrails & Safety Systems, Compute Infrastructure, LLM Routers & Gateways Primary personas at this layer: AI Platform Provider, AI Model Serving Operating model responsibility assignments: - AI-SaaS: Shared - AI-PaaS: Shared - Agent-PaaS: Shared - IaaS: Customer-owned #### L5: AI Model Provider Foundation models, model governance, and supply-chain provenance. Accountable for model architecture security, model cards, vulnerability disclosure, and governance of model distribution. Responsibility assignment depends on licensing and deployment approach. Components: Model Distribution, Model Governance, Foundation Models Primary personas at this layer: Model Provider Operating model responsibility assignments: - AI-SaaS: N/A - AI-PaaS: Model evaluation - Agent-PaaS: Shared - IaaS: Customer-owned ### 1.2 The Eight Personas Reference: https://aisharedresponsibility.com/personas/ Each persona maps to one or more SRF layers. Controls assign accountability to exactly one persona. #### Agentic Platform & Framework Providers ID: `agentic-platform-provider` | Layers: L3, L4 | ISO/IEC 22989:2022 §5.19.5 - AI Partner (tool and framework provider) Provides development environments, software frameworks, and orchestration runtimes for agentic AI. Responsible for framework security, sandboxing, secure state management across multi-turn workflows, and defining cognitive architecture. Responsibilities: - Ensuring framework security and sandboxing - Implementing safety controls around tool execution - Managing state in multi-turn workflows securely - Integrating APIs securely - Defining cognitive architecture for AI systems #### Application Developer ID: `application-developer` | Layers: L3 | ISO/IEC 22989:2022 §5.19.2 - AI Provider; also acts as AI Customer (§5.19.4) with respect to upstream model and platform providers Integrates AI models into applications, products, or services via APIs or embedded models. May perform light customization such as prompt engineering or RAG. Accountable for application-level security controls, input validation, output filtering, and user access management. Responsibilities: - Implementing application-level security controls - Implementing safety controls around tool execution - Ensuring input validation and output filtering - Managing user access control mechanisms #### Data Provider ID: `data-provider` | Layers: L2 | ISO/IEC 22989:2022 §5.19.5 - AI Partner (data provider) Supplies training data, evaluation datasets, or inference data to model providers or application developers. Includes data aggregators, data marketplaces, and dataset licensors. Responsibilities: - Conducting data quality assurance - Tracking data provenance and compliance - Implementing privacy protections in data handling - Managing data classification #### AI System Users ID: `ai-system-users` | Layers: L1 | ISO/IEC 22989:2022 §5.19.4 - AI Customer (end user sub-role) Uses AI-powered applications or services without developing or deploying the AI components. Relies on application developers and providers for security controls. Responsibilities: - Adhering to appropriate use policies - Reporting issues or anomalies detected during use - Following usage guidelines to minimize data exposure Note: Defined for completeness; no controls in the current finance schema assign accountability to this persona. End-user obligations in finance deployments are governed by the institution's acceptable-use policy, which falls under ai-system-governance. #### AI System Governance ID: `ai-system-governance` | Layers: L1 | ISO/IEC 22989:2022 §5.19.4 - AI Customer; §5.19.7 - Relevant Authority where regulatory obligations apply Defines security control objectives, measures implementations, and enforces compliance across the AI system lifecycle. Includes AI risk officers, compliance teams, and governance boards. Responsibilities: - Establishing security and governance rules including acceptable risk levels - Evaluating security measure effectiveness across the AI lifecycle - Ensuring compliance with standards, laws, and company policies - Managing a risk register with assigned owners and remediation timelines - Overseeing incident response plans and post-incident analysis #### Model Provider ID: `model-provider` | Layers: L5 | ISO/IEC 22989:2022 §5.19.3 - AI Producer Develops, trains, evaluates, and tunes AI/ML models including foundation models, specialized models, and domain-adapted models. Accountable for model architecture security, safety validation, and model card publication. Responsibilities: - Secure and responsible model architecture design and training - Model security, safety, and performance validation - Publishing model cards with provenance, benchmarks, and intended use - Maintaining model version and vulnerability disclosures #### AI Model Serving ID: `ai-model-serving` | Layers: L4 | ISO/IEC 22989:2022 §5.19.5 - AI Partner (platform and runtime services provider) Provisions, manages, and secures the runtime environment that serves AI and ML model predictions at scale. Distinct from Model Provider (training/registry) and AI Platform Provider (physical infrastructure). Focused on secure orchestration and delivery of the model serving layer. Responsibilities: - Managing secure API endpoints, enforcing access policies, and input validation - Executing models in isolated or confidential computing environments - Ensuring model and dataset integrity at load-time and during runtime - Monitoring and validating outputs to prevent unintended disclosures - Conducting adversarial simulations to test model serving robustness Note: Defined for completeness; no controls in the current finance schema assign accountability to this persona. L4 controls currently assign to ai-platform-provider or agentic-platform-provider. Review at v1.0 to confirm whether model-serving responsibilities warrant a separate accountability line in L4 controls. #### AI Platform Provider ID: `ai-platform-provider` | Layers: L4 | ISO/IEC 22989:2022 §5.19.5 - AI Partner (infrastructure provider); also acts as AI Provider (§5.19.2) where the platform serves application developers Provides infrastructure, compute resources, APIs, and platform services for AI model hosting, training, or inference. Includes cloud providers (AWS, Azure, GCP), MLOps platforms, and model API services. Responsibilities: - Securing infrastructure and maintaining high availability - Maintaining platform-level compliance certifications (SOC 2, ISO 27001, FedRAMP) - Providing robust IAM primitives for upstream tenants - Providing configurable data residency, encryption, and region-locking capabilities - Guaranteeing uptime, incident notification, and SLAs bounding the platform's contribution to incident response ### 1.3 Operating Models Reference: https://aisharedresponsibility.com/operating-models/ The four operating models determine how accountability shifts between customer and provider across the five layers. #### AI-Enabled SaaS (AI-SaaS) Provider supplies a managed AI application. Customer retains business governance and supplies context data; provider assumes technical responsibility for the application, platform, and model. #### AI Platform as a Service (AI-PaaS) Customer builds and operates the application layer on a provider-managed AI platform. Customer owns business governance and the application; provider manages the platform and foundational model. #### Agentic Platform as a Service (Agent-PaaS) Customer owns agent definitions and business logic on a provider-managed orchestration runtime. Responsibility at L3 and L5 is shared as both parties control distinct parts of the agentic stack. #### Infrastructure as a Service (IaaS) Maximum customer responsibility. Customer builds and operates the application, platform, and model layers. Provider is accountable only for the physical and virtual infrastructure underpinning L4. #### Responsibility Matrix Notation: Customer / Provider. Values: customer-owned, shared, provider-managed, model-evaluation, N/A. | Layer | AI-SaaS (customer/provider) | AI-PaaS (customer/provider) | Agent-PaaS (customer/provider) | IaaS (customer/provider) | |-------|---------------------------|---------------------------|-------------------------------|-------------------------| | L1 | shared / provider-managed | customer-owned / N/A | customer-owned / N/A | customer-owned / N/A | | L2 | shared / provider-managed | shared / shared | shared / shared | customer-owned / N/A | | L3 | N/A / provider-managed | customer-owned / shared | shared / provider-managed | customer-owned / N/A | | L4 | N/A / provider-managed | N/A / provider-managed | N/A / provider-managed | customer-owned / shared | | L5 | N/A / provider-managed | model-evaluation / provider-managed | shared / shared | customer-owned / N/A | --- ## Part 1.4: Framework Comparison Reference: https://aisharedresponsibility.com/compare/ The CoSAI SRF fills the accountability gap left by adjacent frameworks: - NIST AI RMF: Risk categories and organizational functions but no layer-level accountability assignment or persona model. - ISO 42001: Management system requirements without specifying which layer or role is accountable for each control. - EU AI Act: Regulatory obligations for high-risk AI but no internal shared-responsibility model for multi-party deployments. - CSA AICM: Controls catalog aligned to cloud; does not resolve AI-specific persona accountability. - MITRE ATLAS: Adversarial threat taxonomy; no accountability or governance model. The SRF is complementary to all five: it provides the accountability layer that resolves which party in a multi-party AI supply chain owns each control. --- ## Part 2: Industry Vertical Control Schemas Reference: https://aisharedresponsibility.com/industries/ Each vertical is an independently proposed extension to CoSAI SRF v1.0. Not part of the official CoSAI release. All controls map to SRF layers L1-L5 and assign accountability to a single named persona. --- ### Financial Services Reference: https://aisharedresponsibility.com/finance/ Controls page: https://aisharedresponsibility.com/finance/controls/ Machine-readable: https://aisharedresponsibility.com/data/finance-controls.json Finance-sector control schema for the CoSAI AI Shared Responsibility Framework. Maps SRF layers and accountable personas to the MRM lifecycle (SR 26-2 principles), with threshold tuples and OCSF evidence pointers per control. Total controls: 40 #### L1: AI Business & Usage (9 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L1-DEV-001: AI Risk Appetite Statement with Named Accountable Executive Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Processes & Governance Mrm Stage: development Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS The institution must publish a board-approved AI risk appetite statement that names a specific senior executive accountable for AI risk. The statement must define risk tolerance thresholds for each operating model (AI-SaaS, AI-PaaS, Agent-PaaS, IaaS) and be reviewed on the cadence defined in SRF-L1-MON-002. Evidence: Binary: board-approved AI risk appetite statement exists, names an accountable executive, and covers all operating models in use. Threshold: risk_appetite_statement_approved == true Breach action: escalate-to-board-risk-committee ##### SRF-L1-DEV-002: AI Model Inventory and Tier Classification Policy Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Business Units & Accountability Mrm Stage: development Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS The institution must maintain a complete inventory of AI models in use, with each model assigned a materiality tier (e.g., Tier 1: high materiality, Tier 2: moderate, Tier 3: low) per SR 26-2's risk-based approach. Tier assignment criteria must be documented and approved by the accountable executive named in SRF-L1-DEV-001. Evidence: Binary: tier classification methodology documented, approved, and applied to all models entering production. Threshold: tier_classification_policy_approved == true Breach action: block-model-production-promotion Regulatory mappings: - eu_ai_act: Art. 9 (risk management system): TBD confirm article applicability ##### SRF-L1-DEV-003: Acceptable Use Policy with Named Business-Unit Accountable Individual Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Capabilities & Business Strategy Mrm Stage: development Operating models: AI-SaaS, AI-PaaS, Agent-PaaS Each business unit deploying AI systems must designate a named individual (not a team, role title, or org-unit) as the accountable signatory for the acceptable use policy covering that unit's AI systems. The AUP must specify permitted use cases, prohibited outputs, user categories, and escalation paths, and must address each operating model in scope. A business-unit-level signature without a named individual does not satisfy SR 26-2's governance accountability expectations and will be a finding under examiner review. The named individual must be recorded in the model inventory alongside the models they are accountable for, and updated when the individual changes (see SRF-L1-MON-003). Evidence: Percentage of business units with AI systems in production that have a current AUP acknowledgment signed by a named individual (not a team or role), linked to that individual's identity record in the HR or IAM system. Threshold: business_unit_named_aup_signatory_coverage >= tier-defined Breach action: suspend-ai-system-access-for-non-compliant-business-unit; notify-mrm-head ##### SRF-L1-DEV-004: Agent Business Process Authorization Policy Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Processes & Governance Mrm Stage: development Operating models: Agent-PaaS Before any Agent-PaaS system is deployed to act autonomously on the institution's behalf, executing transactions, communicating with clients, initiating workflows, or making decisions that produce regulatory or financial consequences; the institution must produce a written agent authorization policy for each business process the agent is permitted to act within. The policy must specify: the bounded scope of agent authority (which actions are permitted, which require human approval), the named human business owner accountable for agent actions within that process, the escalation path when an agent action falls outside its authorized scope, and the conditions under which the agent must halt and refer to a human. SR 26-2 puts agentic AI out of scope but existing MRM principles require human accountability for model outputs. When an agent acts, the accountable human must be named at L1 before deployment, not identified after an incident. This control applies to Agent-PaaS only; AI-SaaS and AI-PaaS systems that do not act autonomously are out of scope. Evidence: Binary: for every Agent-PaaS deployment in production, a written agent authorization policy exists naming an accountable business owner and defining the bounded scope of agent authority for each business process the agent acts within. Threshold: agent_process_authorization_policy_exists == true Breach action: block-agent-production-deployment; notify-cro-and-legal ##### SRF-L1-VAL-001: Independent Review of AI Risk Appetite by Second Line Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Processes & Governance Mrm Stage: independent-validation Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS The second line of defense (model risk management or independent risk function) must perform an annual independent review of the AI risk appetite statement (SRF-L1-DEV-001) and tier classification policy (SRF-L1-DEV-002). The review must assess whether thresholds remain appropriate given changes to the model portfolio, operating models, and regulatory guidance. Evidence: Binary: second-line independent review of AI risk appetite completed within the past 12 months, with findings documented and remediation tracked. Threshold: independent_review_completed == true Breach action: escalate-to-cro-and-audit-committee ##### SRF-L1-MON-001: Model Tier Classification Coverage Rate Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Business Units & Accountability Mrm Stage: ongoing-monitoring Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS Ongoing monitoring of the percentage of AI models in production that have an assigned materiality tier per the policy in SRF-L1-DEV-002. Any model that has been in production longer than the onboarding window without a tier assignment constitutes a breach. Evidence: Percentage of AI models in production inventory that have a current, approved tier assignment. Threshold: model_tier_classification_coverage_rate >= tier-defined Breach action: flag-unclassified-models-for-immediate-tier-assignment; notify-mrm-head ##### SRF-L1-MON-002: AI Governance Committee Review Cadence Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Processes & Governance Mrm Stage: ongoing-monitoring Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS The AI governance committee (or equivalent body) must hold documented reviews of the AI model portfolio at the cadence required by the institution's tier policy. Tier-1 models require quarterly review; Tier-2 and Tier-3 review cadence is institution-defined per SR 26-2's materiality principle. This control monitors that reviews occur as scheduled. Evidence: Percentage of scheduled governance reviews that were completed within the required window, across all model tiers. Threshold: governance_review_cadence_adherence >= tier-defined Breach action: alert-mrm-head; document-missed-review; reschedule-within-15d ##### SRF-L1-MON-003: Governance Role Identity Lifecycle Monitoring Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Business Units & Accountability Mrm Stage: ongoing-monitoring Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS When any named individual in an AI governance accountability role changes, including the accountable executive (SRF-L1-DEV-001), business-unit AUP signatories (SRF-L1-DEV-003), agent business process owners (SRF-L1-DEV-004), and the MRM function head; the vacancy or transition must be resolved within the SLA defined per role tier. A stale name on a governance document is an accountability gap and a regulatory finding. This control monitors open vacancies against SLA and flags overdue reassignments. SLA tiers: Tier-1 roles (accountable executive, MRM head) must be reassigned within 30 days of vacancy; Tier-2 roles (business-unit signatories, agent process owners) within 60 days. Institutions may tighten but not loosen these defaults. Evidence: Number of days any named governance accountability role has been vacant or held by a departed/transferred employee without a confirmed successor. Breach when vacancy exceeds the SLA tier for that role. Threshold: governance_role_vacancy_age <= tier-defined (Tier-1: 30d, Tier-2: 60d) Breach action: alert-cro-and-audit-committee; flag-affected-models-as-governance-gap-pending-reassignment ##### SRF-L1-ECH-001: Board-Level Effective Challenge of AI Risk Profile Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Processes & Governance Mrm Stage: effective-challenge Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS The board risk committee (or equivalent) must conduct annual effective challenge of the institution's AI risk profile, including review of the risk appetite statement, tier distribution, open findings from independent validation, and any material incidents from the prior period. Challenge must be documented with evidence of substantive board-level inquiry, not passive acceptance. Evidence: Binary: board risk committee review of AI risk profile completed in the past 12 months with documented substantive challenge (questions, findings, or required management actions recorded in board minutes). Threshold: board_effective_challenge_documented == true Breach action: escalate-to-audit-committee; flag-in-regulatory-exam-preparation #### L2: AI Information (8 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L2-DEV-001: Training and RAG Data Provenance Documentation Layer: L2 (AI Information) | Persona: `data-provider` | Component: AI Training Data Mrm Stage: development Operating models: AI-PaaS, Agent-PaaS, IaaS Before a model enters validation, the data provider must produce a provenance record for every training dataset and RAG corpus used, covering: source, licensing terms, collection date, preprocessing steps applied, known biases documented, and the data owner accountable for ongoing quality. The record must be stored in the model inventory and linked to the model card. For third-party data sources, the provenance record must additionally name an internal data steward accountable for the vendor relationship and for validating that the source meets the institution's data quality and classification standards. The SRF's single-accountable-party principle applies regardless of whether the data provider is internal or external; accountability does not transfer to the vendor. Evidence: Binary: complete provenance record exists for all training and RAG datasets linked to the model, with no missing required fields. Threshold: provenance_record_completeness == true Breach action: block-model-from-entering-validation ##### SRF-L2-DEV-002: Data Classification for AI-Accessible Data Stores Layer: L2 (AI Information) | Persona: `data-provider` | Component: Privacy Controls & Policies Mrm Stage: development Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS All data stores accessible by AI systems at runtime (RAG corpora, grounding databases, tool-accessible APIs) must have a current data classification label (e.g., public, internal, confidential, restricted) before the system enters production. Classification must be performed by or reviewed by the accountable data owner, not the application developer. Evidence: Percentage of data stores accessible by AI systems in production that carry a current, approved data classification label. Threshold: ai_accessible_store_classification_coverage >= tier-defined Breach action: block-production-promotion; notify-data-owner ##### SRF-L2-DEV-003: Training Data Quality Baseline and PSI Reference Distribution Layer: L2 (AI Information) | Persona: `data-provider` | Component: Master Data Management Mrm Stage: development Operating models: AI-PaaS, Agent-PaaS, IaaS For each model using institution-provided training data, the data provider must establish a reference distribution at the time of initial training. This reference distribution anchors Population Stability Index (PSI) calculations during ongoing monitoring (SRF-L2-MON-001). The baseline must cover all features used by the model and be stored alongside the model artifacts. Evidence: Binary: reference distribution artifact exists in model registry for all monitored features, linked to model version. Threshold: psi_reference_distribution_stored == true Breach action: block-model-from-entering-validation ##### SRF-L2-VAL-001: Independent Validation of Training Data Quality and Representativeness Layer: L2 (AI Information) | Persona: `data-provider` | Component: AI Training Data Mrm Stage: independent-validation Operating models: AI-PaaS, Agent-PaaS, IaaS The independent validation function must assess training data quality before a model is approved for production. Assessment must cover: representativeness of training data relative to the production population, absence of prohibited data (per SRF-L2-DEV-002 classification), bias indicators across protected classes relevant to the use case, and completeness of the provenance record (SRF-L2-DEV-001). Findings must be documented with disposition (accepted, conditionally accepted, or rejected). Evidence: Binary: independent validation report for training data quality exists, covers all required assessment areas, and records a formal disposition. Threshold: data_validation_completed_with_disposition == true Breach action: block-production-approval ##### SRF-L2-MON-001: Training and RAG Data Drift Monitoring (PSI) Layer: L2 (AI Information) | Persona: `data-provider` | Component: AI Training Data Mrm Stage: ongoing-monitoring Operating models: AI-PaaS, Agent-PaaS, IaaS For models using institution-provided training data or runtime RAG corpora, the data provider must monitor Population Stability Index (PSI) against the reference distribution established in SRF-L2-DEV-003. PSI breach thresholds follow MRM convention: PSI >= 0.1 triggers investigation; PSI >= 0.25 triggers re-validation. Tier-1 models require continuous or daily monitoring; lower tiers follow institution-defined cadence per SR 26-2's materiality principle. Evidence: Population Stability Index calculated between current input distribution and reference distribution. Conventional MRM thresholds: < 0.1 stable, 0.1 to 0.25 minor shift (investigate), >= 0.25 major shift (re-validate). Institutions set tier-specific alert levels. Threshold: psi_score < tier-defined Breach action: alert-data-provider; escalate-to-mrm-if-psi-ge-0.25; initiate-re-validation ##### SRF-L2-MON-002: Data Classification Coverage Rate for AI-Accessible Stores Layer: L2 (AI Information) | Persona: `data-provider` | Component: Privacy Controls & Policies Mrm Stage: ongoing-monitoring Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS Ongoing monitoring of the percentage of data stores accessible by AI systems in production that carry a current data classification. New data stores connected to AI systems after initial production approval must be classified before use. This control catches classification drift as AI systems are extended to new data sources over time. Upward reclassification of an existing store (sensitivity level increasing) is treated as a breach event requiring re-evaluation of platform-level compute controls at L4, not only a coverage metric update. Evidence: Percentage of data stores accessed by AI systems in the monitoring window that appear in the classification register with a current label. Threshold: ai_accessible_store_classification_coverage_rate >= tier-defined Breach action: alert-data-owner; quarantine-unclassified-store-from-ai-access-pending-classification ##### SRF-L2-MON-003: Agent Runtime Memory Store Integrity Monitoring Layer: L2 (AI Information) | Persona: `data-provider` | Component: Master Data Management Mrm Stage: ongoing-monitoring Operating models: Agent-PaaS For Agent-PaaS deployments, the data provider (in coordination with the agentic platform provider at L3/L4) must monitor agent runtime memory stores: episodic memory, working memory, and any mutable knowledge store the agent reads from or writes to, for unauthorized or anomalous write operations. This control targets memory poisoning: the injection of malicious or incorrect content into an agent's memory during a session, which can corrupt subsequent reasoning across that session or persist across sessions if memory is durable. Monitoring must cover: write-access events by actor (agent identity, tool, or external input), write rate relative to session baseline, and content that deviates significantly from the memory store's established distribution. Accountability for the integrity of the data in the store sits at L2 (data-provider); the implementing telemetry sits at L3/L4 (agentic-platform-provider). Evidence: Rate of write operations to agent memory stores that deviate from the session baseline (unexpected actor, write volume spike, or content distribution shift). A zero-tolerance threshold applies to writes by actors outside the authorized write-access list. Threshold: memory_anomalous_write_rate == 0 unauthorized-actor writes Breach action: terminate-agent-session; quarantine-memory-store; alert-data-provider-and-agentic-platform-provider; initiate-forensic-review ##### SRF-L2-ECH-001: Effective Challenge of Data Quality Standards and Drift Thresholds Layer: L2 (AI Information) | Persona: `data-provider` | Component: Master Data Management Mrm Stage: effective-challenge Operating models: AI-PaaS, Agent-PaaS, IaaS The independent validation or second-line risk function must annually challenge whether the PSI thresholds (SRF-L2-MON-001) and classification coverage targets (SRF-L2-MON-002) remain appropriate. Challenge must assess: whether conventional PSI thresholds are calibrated to the institution's specific model population, whether new data modalities (e.g., multimodal inputs, agent tool outputs) require additional drift metrics, and whether any Tier-1 model has exceeded its drift threshold without triggering a re-validation. Evidence: Binary: annual second-line challenge of L2 monitoring thresholds completed, with findings documented and any required threshold adjustments tracked to closure. Threshold: data_standards_challenge_documented == true Breach action: escalate-to-cro; flag-in-annual-mrm-report #### L3: AI Application (8 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L3-DEV-001: Input Validation and Prompt Injection Defense Design Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application Platforms Mrm Stage: development Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS Before a model-backed application enters validation, the application developer must document and implement input validation controls covering: maximum input length enforcement, character set and encoding validation, detection of prompt injection patterns (instruction override attempts, role-switch instructions, jailbreak patterns), and sanitization of user-supplied content before it reaches the model context. For RAG pipelines, retrieved content must be treated as untrusted input and passed through the same validation chain as user input. Defense-in-depth is required: a single detection layer is not sufficient. Design must be documented and reviewable by the independent validation function. Evidence: Binary: input validation design document exists, covers all required layers, and has been reviewed by a party independent of the developer who wrote it. Threshold: input_validation_design_documented == true Breach action: block-model-from-entering-validation Regulatory mappings: - owasp_llm: LLM01: Prompt Injection ##### SRF-L3-DEV-002: Output Filtering and Content Safety Design Layer: L3 (AI Application) | Persona: `application-developer` | Component: APIs & Fine-tuned Models Mrm Stage: development Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS The application developer must implement output filtering controls before model outputs reach end users or downstream systems. Required layers: a content safety classifier or rules engine that blocks prohibited output categories (defined by the institution's acceptable use policy at SRF-L1-DEV-003), a PII detection and redaction layer for outputs destined for external parties or low-clearance users, and structured output validation for applications that parse model outputs into downstream decisions or workflows. For fine-tuned models, the developer must document whether fine-tuning altered the base model's built-in safety behaviors and what compensating controls are in place. Output filters must be applied after every model call, including intermediate steps in agentic chains. Evidence: Binary: output filtering design covers all required layers, documents fine-tuning safety impact where applicable, and has been reviewed independently. Threshold: output_filter_design_documented == true Breach action: block-model-from-entering-validation Regulatory mappings: - owasp_llm: LLM02: Insecure Output Handling; LLM06: Sensitive Information Disclosure ##### SRF-L3-DEV-003: Tool-Execution Authorization Design for Agentic Systems Layer: L3 (AI Application) | Persona: `agentic-platform-provider` | Component: Agents & Orchestration Models Mrm Stage: development Operating models: Agent-PaaS For Agent-PaaS deployments, the agentic platform and framework provider must design and document a tool-execution authorization scheme that enforces least-privilege access for each tool the agent can invoke. Required design elements: an explicit allow-list of tools per agent role (no implicit allow-all), per-tool authorization checks that verify the agent's current session context and user delegation before execution, a confirmation gate for irreversible or high-consequence tool calls (as defined in the agent authorization policy at SRF-L1-DEV-004), and an audit trail linking each tool execution to the agent session, the human user or system that initiated the session, and the business process the agent is authorized to act within. Tool authorization must be re-checked at each step in a multi-step orchestration chain, not only at session start. Evidence: Binary: tool-execution authorization design document exists covering all required elements, and has been reviewed by a party independent of the framework developer. Threshold: tool_authorization_design_documented == true Breach action: block-agent-from-entering-validation Regulatory mappings: - owasp_llm: LLM07: Insecure Plugin Design; LLM08: Excessive Agency ##### SRF-L3-VAL-001: Independent Validation of Application-Level Security Controls Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application Platforms Mrm Stage: independent-validation Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS Before production approval, the independent validation function must conduct adversarial testing of the application's security controls. Required scope: prompt injection attempts across at least the OWASP LLM Top 10 attack categories relevant to the architecture, output filter bypass attempts (including indirect injection via RAG retrieval), tool-execution authorization bypass for Agent-PaaS deployments, and chain-of-thought leakage tests for multi-step orchestrations. Testing must be performed by a team with no development accountability for the controls being tested. Findings must be documented with severity ratings, and any Critical or High findings must be remediated before production approval. Tier-1 models require external red-team involvement or independent security firm engagement. Evidence: Binary: independent adversarial test report exists covering required scope, with all Critical and High findings dispositioned (remediated or accepted with documented rationale) before production approval. Threshold: adversarial_validation_completed == true Breach action: block-production-approval-until-critical-and-high-findings-remediated Regulatory mappings: - owasp_llm: LLM01 through LLM10: full top 10 scope for adversarial testing ##### SRF-L3-MON-001: Prompt Injection Detection Rate Monitoring Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application Platforms Mrm Stage: ongoing-monitoring Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS The application developer must monitor the rate of detected prompt injection attempts against the application in production. Detection rate is the proportion of inputs flagged by the injection detection layer (SRF-L3-DEV-001) relative to total inputs. A sustained elevation in detection rate is a signal of active attack or a shift in the user population that warrants investigation. A sudden drop in detection rate when attack volume is expected to be constant may indicate detector degradation. Both conditions are breach events. Tier-1 models require continuous monitoring; lower tiers follow the institution-defined cadence. Evidence: Rate of inputs flagged as prompt injection attempts per unit time. Breach conditions: (1) rate exceeds the upper control limit defined at baseline (active attack signal); (2) rate drops below the lower control limit when traffic volume is stable (detector degradation signal). Threshold: prompt_injection_detection_rate within-control-limits tier-defined (upper and lower control limits set at baseline) Breach action: alert-application-developer; escalate-to-security-team-if-upper-limit-exceeded; escalate-to-mrm-if-lower-limit-breached Regulatory mappings: - owasp_llm: LLM01: Prompt Injection ##### SRF-L3-MON-002: Output Filter Block-Rate Monitoring Layer: L3 (AI Application) | Persona: `application-developer` | Component: APIs & Fine-tuned Models Mrm Stage: ongoing-monitoring Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS The application developer must monitor the rate at which the output filter (SRF-L3-DEV-002) blocks or redacts model outputs in production. An elevated block rate signals model behavior drift, a shift in user inputs driving prohibited outputs, or a fine-tuning regression. A declining block rate over time may indicate filter degradation or evasion. Both are breach conditions. The block rate must be broken down by filter category (content safety, PII redaction, structured output validation) so that category-level anomalies are visible independently. Evidence: Rate of model outputs blocked or redacted per filter category per unit time. Breach when any category's block rate falls outside its established control limits. Threshold: output_filter_block_rate_by_category within-control-limits tier-defined per filter category Breach action: alert-application-developer; investigate-category-causing-breach; escalate-to-mrm-if-unresolved-within-sla Regulatory mappings: - owasp_llm: LLM02: Insecure Output Handling; LLM06: Sensitive Information Disclosure ##### SRF-L3-MON-003: Tool-Execution Authorization Failure Rate Monitoring Layer: L3 (AI Application) | Persona: `agentic-platform-provider` | Component: Agents & Orchestration Models Mrm Stage: ongoing-monitoring Operating models: Agent-PaaS For Agent-PaaS deployments, the agentic platform provider must monitor the rate of tool-execution authorization failures: attempts by an agent to invoke a tool it is not authorized to call, or invocations that fail the per-call authorization check (SRF-L3-DEV-003). A rising authorization failure rate signals prompt injection driving out-of-scope tool calls, agent scope creep, or a misconfigured allow-list. Any attempt to invoke a tool outside the agent's allow-list is a Severity-1 event regardless of whether it succeeded. Authorization failures must be correlated with the originating session and user to support forensic review. Evidence: Count of tool invocation attempts that fail authorization checks per session and per time window. Zero tolerance for out-of-allow-list invocation attempts; tier-defined thresholds for per-call authorization check failures. Threshold: tool_authorization_failure_rate == 0 out-of-allow-list attempts; tier-defined for per-call failures Breach action: terminate-agent-session-on-out-of-allow-list-attempt; alert-agentic-platform-provider; escalate-to-security-team; notify-l1-agent-business-process-owner Regulatory mappings: - owasp_llm: LLM07: Insecure Plugin Design; LLM08: Excessive Agency ##### SRF-L3-ECH-001: Effective Challenge of Application Security Control Thresholds Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application Platforms Mrm Stage: effective-challenge Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS The independent validation or second-line risk function must annually challenge whether the application-level security control thresholds established in SRF-L3-MON-001, SRF-L3-MON-002, and SRF-L3-MON-003 remain appropriate. Challenge must assess: whether control limits reflect the current threat environment (updated OWASP LLM Top 10 categories, new injection techniques observed in the prior period), whether any Tier-1 application has operated outside its control limits without triggering a documented response, whether fine-tuning or model version changes since last validation have altered the output filter's effectiveness, and whether the agentic tool allow-lists remain appropriately scoped given changes to business processes since initial deployment. Evidence: Binary: annual second-line challenge of L3 monitoring thresholds completed, covering all required assessment areas, with findings and any threshold adjustments tracked to closure. Threshold: application_security_challenge_documented == true Breach action: escalate-to-cro; flag-in-annual-mrm-report #### L4: AI Platform (8 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L4-DEV-001: Platform-Level Guardrail Design and Configuration Baseline Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Guardrails & Safety Systems Mrm Stage: development Operating models: AI-SaaS, AI-PaaS, Agent-PaaS The AI platform provider must design, configure, and document platform-level guardrails before any model is served in production. Platform guardrails operate below the application layer (SRF-L3-DEV-001/002) and provide a defense-in-depth layer that persists even when application controls are misconfigured or bypassed. Required elements: input guardrails that intercept and evaluate requests before they reach the model, output guardrails that evaluate model responses before returning them to the caller, a configuration baseline that specifies which guardrail policies are active per model tier, and a change-control process requiring re-validation when guardrail configuration changes. Guardrail configuration must be immutable to application-layer callers; applications may request guardrail policies but cannot disable them. Evidence: Binary: guardrail configuration baseline document exists per model tier, has been reviewed independently, and is stored in version control with change-control enforcement. Threshold: guardrail_configuration_baseline_approved == true Breach action: block-model-from-entering-validation ##### SRF-L4-DEV-002: LLM Gateway Authentication and Authorization Design Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: LLM Routers & Gateways Mrm Stage: development Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS The AI platform provider must design and document authentication and authorization controls for all LLM gateway and router endpoints before production deployment. Required elements: mutual authentication for all model API calls (service-to-service mTLS or equivalent), per-caller authorization that enforces model access entitlements (a caller authorized for Tier-3 models cannot invoke Tier-1 endpoints), rate limiting and quota enforcement per caller identity to prevent abuse, and audit logging of all gateway requests with caller identity, model invoked, and token usage. For Agent-PaaS, the gateway must distinguish agent-identity calls from human-identity calls and apply appropriate authorization policies to each. Gateway credentials must be rotated on a schedule defined by the institution's secrets management policy. Evidence: Binary: gateway authentication and authorization design document covers all required elements and has been reviewed independently. Credential rotation schedule is documented and enforced. Threshold: gateway_authn_authz_design_documented == true Breach action: block-model-from-entering-validation ##### SRF-L4-DEV-003: Confidential Compute Configuration for Tier-1 Models Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Compute Infrastructure Mrm Stage: development Operating models: AI-PaaS, Agent-PaaS, IaaS Tier-1 AI models processing confidential or restricted data (as classified per SRF-L2-DEV-002) must be configured to run in confidential compute environments (e.g., AMD SEV-SNP, Intel TDX, or equivalent trusted execution environment) that provide hardware-enforced memory encryption and isolation. The platform provider must document the confidential compute configuration, generate a cryptographic attestation report at deployment, and store the attestation alongside the model artifact in the model registry. Attestation must be re-generated after any infrastructure change that could affect the trusted execution environment. This control applies to Tier-1 models only; lower tiers follow institution-defined policy. Evidence: Binary: cryptographic attestation report exists in model registry for Tier-1 model deployments, linked to the model version and infrastructure configuration hash. Threshold: confidential_compute_attestation_stored == true Breach action: block-tier-1-model-deployment-until-attestation-generated ##### SRF-L4-VAL-001: Independent Validation of Platform Security Controls Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Guardrails & Safety Systems Mrm Stage: independent-validation Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS Before a model is approved for production, the independent validation function must assess the effectiveness of the platform's guardrail configuration and gateway security controls. Required scope: guardrail bypass testing (attempts to reach the model with inputs that should be blocked, from the application layer), gateway authentication and authorization boundary testing (confirming callers cannot access model tiers above their entitlement), confidential compute attestation verification for Tier-1 models, and review of the guardrail change-control record since the last validation. Validation findings must include a tested bypass rate: the proportion of attempted guardrail bypasses that succeeded during testing. Any bypass success rate above zero for Critical guardrail categories is a blocking finding. Evidence: Binary: independent validation report exists covering all required scope. Tested bypass rate for Critical guardrail categories is zero. All High findings are dispositioned before production approval. Threshold: platform_validation_completed_bypass_rate_zero == true Breach action: block-production-approval-until-critical-bypass-findings-remediated ##### SRF-L4-MON-001: Guardrail Bypass Rate Monitoring Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Guardrails & Safety Systems Mrm Stage: ongoing-monitoring Operating models: AI-SaaS, AI-PaaS, Agent-PaaS The AI platform provider must monitor the rate at which requests or responses bypass platform-level guardrails in production. A bypass occurs when an input that should have been intercepted reaches the model, or when a model output that should have been blocked is returned to the caller. Bypass rate is the proportion of guardrail evaluation events that result in a bypass verdict relative to total evaluations. Bypass events must be classified by guardrail category and severity. Zero-tolerance applies to Critical category bypasses (e.g., guardrails covering regulated content, PII in outputs, or financial advice prohibitions). Tier-defined thresholds apply to lower-severity categories. Bypass rate monitoring operates at the platform layer independently of application-layer output filter monitoring (SRF-L3-MON-002); both layers must report. Where model serving is operated by a distinct ai-model-serving vendor, that vendor is accountable for reporting guardrail evaluation events to the ai-platform-provider; the ai-platform-provider retains accountability for the aggregate bypass rate. Evidence: Rate of guardrail bypass events per category per monitoring window. Zero tolerance for Critical category bypasses; tier-defined thresholds for lower-severity categories. Threshold: guardrail_bypass_rate_by_category <= tier-defined (0 for Critical; tier-defined for lower severity) Breach action: alert-ai-platform-provider; escalate-to-l1-governance-on-critical-bypass; initiate-guardrail-configuration-review ##### SRF-L4-MON-002: Gateway Authentication Failure Rate Monitoring Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: LLM Routers & Gateways Mrm Stage: ongoing-monitoring Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS The AI platform provider must monitor the rate of authentication and authorization failures at all LLM gateway and router endpoints. Authentication failures (invalid credentials, expired tokens, missing credentials) and authorization failures (valid caller attempting to access an unauthorized model tier or endpoint) must be tracked separately. A sustained elevation in authentication failures may indicate credential stuffing, rotation failures, or misconfigured callers. A spike in authorization failures may indicate an application attempting to escalate model access beyond its entitlement, or an agent attempting to invoke a higher-tier model than its authorization permits. All authorization failures for Tier-1 model endpoints are Severity-1 events regardless of rate. Where ai-model-serving operates the inference endpoint directly, it is accountable for authentication failures at that endpoint; the ai-platform-provider is accountable for authorization failures at the routing and gateway layer. Evidence: Rate of authentication and authorization failures per gateway endpoint per monitoring window, tracked separately by failure type. Tier-1 authorization failures: zero tolerance. All others: tier-defined control limits. Threshold: gateway_authn_failure_rate within-control-limits tier-defined (Tier-1 authz failures: 0; all others: tier-defined) Breach action: alert-ai-platform-provider; escalate-to-security-team-on-tier-1-authz-failure; investigate-credential-rotation-status-on-authn-spike ##### SRF-L4-MON-003: Confidential Compute Attestation Validity Monitoring Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Compute Infrastructure Mrm Stage: ongoing-monitoring Operating models: AI-PaaS, Agent-PaaS, IaaS For Tier-1 models deployed in confidential compute environments (SRF-L4-DEV-003), the AI platform provider must continuously monitor that the cryptographic attestation for each running instance remains valid. Attestation validity may lapse due to infrastructure patching, node migration, hypervisor updates, or certificate expiry. A Tier-1 model running without a valid attestation has lost its confidentiality guarantee and must be treated as an unprotected workload until attestation is re-established. Attestation status must be checked at model load, on a scheduled polling interval, and on any infrastructure event that could affect the trusted execution environment. Where ai-model-serving operates the compute instances directly, it is jointly accountable with ai-platform-provider for attestation validity; the ai-platform-provider retains accountability for reporting to L1 governance on breach. Evidence: Binary per Tier-1 model instance: current cryptographic attestation is valid, has not expired, and matches the expected configuration hash for that deployment. Threshold: confidential_compute_attestation_valid == true per Tier-1 instance Breach action: suspend-tier-1-model-serving-on-attestation-lapse; alert-ai-platform-provider; notify-l1-governance; restore-only-after-valid-attestation-confirmed ##### SRF-L4-ECH-001: Effective Challenge of Platform Security Controls and Thresholds Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Guardrails & Safety Systems Mrm Stage: effective-challenge Operating models: AI-SaaS, AI-PaaS, Agent-PaaS, IaaS The independent validation or second-line risk function must annually challenge whether the platform-level security controls and monitoring thresholds remain appropriate. Challenge must assess: whether the guardrail configuration baseline reflects the current model portfolio and threat environment, whether any guardrail bypass events in the prior period were dispositioned correctly and within SLA, whether gateway credential rotation has been executed on schedule, whether any Tier-1 model ran without valid confidential compute attestation during the prior period, and whether new operating models or model serving architectures introduced since last validation require additional platform controls not currently in scope. Evidence: Binary: annual second-line challenge of L4 controls completed, covering all required assessment areas, with findings and any required control updates tracked to closure. Threshold: platform_security_challenge_documented == true Breach action: escalate-to-cro; flag-in-annual-mrm-report #### L5: AI Model Provider (7 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L5-DEV-001: Model Card Completeness and Security Disclosure Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Governance Mrm Stage: development Operating models: AI-PaaS, Agent-PaaS, IaaS Before a foundation model is made available to institution consumers (via API, download, or marketplace), the model provider must publish a model card that meets the minimum completeness standard for financial services deployment. Required fields: intended use cases and explicitly out-of-scope use cases, known failure modes and documented evaluation results on safety benchmarks, training data description at the level of detail needed for MRM provenance review (SRF-L2-DEV-001 alignment), known limitations relevant to regulated use cases (credit, insurance, financial advice), security evaluation summary covering at minimum prompt injection resistance, jailbreak resistance, and data exfiltration risk, and the vulnerability disclosure process and contact (SRF-L5-MON-002 alignment). Model cards must be versioned and updated with each model release. Evidence: Binary: model card exists, covers all required fields, is versioned, and is publicly accessible at the time the model is offered to institution consumers. Threshold: model_card_completeness == true Breach action: block-model-from-institution-deployment-until-model-card-complete ##### SRF-L5-DEV-002: Model Artifact Signing and Supply-Chain Provenance Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Distribution Mrm Stage: development Operating models: AI-PaaS, Agent-PaaS, IaaS The model provider must cryptographically sign all model artifacts (weights, tokenizer, configuration files) before distribution. The signing key must be managed under the provider's documented key management policy, with the public key published in a verifiable trust store. The model provider must also publish a Software Bill of Materials (SBOM) or equivalent supply-chain provenance record for each model release, covering training framework versions, key dependencies, and any third-party components incorporated into the model architecture. This provenance record enables the ai-platform-provider to verify model integrity at load (SRF-L5-MON-001) and supports the institution's third-party risk management obligations under SR 26-2's inherited vendor management principles. Evidence: Binary: all model artifacts for the release are cryptographically signed with a key in the published trust store, and an SBOM or equivalent provenance record is published alongside the model. Threshold: model_artifact_signed_and_sbom_published == true Breach action: block-model-from-institution-deployment-until-signed-artifacts-available ##### SRF-L5-DEV-003: Pre-Release Security Evaluation Baseline Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Foundation Models Mrm Stage: development Operating models: AI-PaaS, Agent-PaaS, IaaS Before a foundation model is made available to institution consumers, the model provider must conduct and publish a security evaluation covering the model's behavior on categories of risk relevant to financial services deployment. Required evaluation categories: prompt injection resistance (resistance to direct and indirect injection attacks), jailbreak resistance across documented bypass techniques, tendency to produce ungrounded financial claims (hallucination in financial contexts), data exfiltration risk (tendency to reproduce training data verbatim), and behavior on agentic tool-use scenarios including tool-call refusal when out of scope. Evaluation methodology and benchmark datasets used must be disclosed. Results must be quantitative where possible and updated with each major model version. Evidence: Binary: security evaluation report covering all required categories is published with the model release, with quantitative results and disclosed methodology. Threshold: security_evaluation_published == true Breach action: block-model-from-institution-deployment-until-evaluation-published Regulatory mappings: - owasp_llm: LLM01: Prompt Injection; LLM06: Sensitive Information Disclosure; LLM09: Overreliance ##### SRF-L5-VAL-001: Independent Evaluation of Model Security Properties Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Foundation Models Mrm Stage: independent-validation Operating models: AI-PaaS, Agent-PaaS, IaaS Before institution deployment of a Tier-1 or Tier-2 model, the institution's independent validation function (or a commissioned third party) must conduct its own security evaluation of the foundation model, independent of the model provider's published evaluation (SRF-L5-DEV-003). This is required because the provider's evaluation is self-reported and may not cover the institution's specific deployment context, use case constraints, or threat model. The independent evaluation must cover: reproduction of key benchmark results from the provider's evaluation to validate claims, institution-specific red-teaming for the intended use case, and assessment of whether the model's known failure modes are adequately addressed by the application and platform controls (SRF-L3, SRF-L4). Findings must be incorporated into the model's validation report and linked to the model card. Evidence: Binary: independent evaluation completed by a party with no development accountability for the model, covering required scope, with findings documented and incorporated into the validation report. Threshold: independent_model_evaluation_completed == true Breach action: block-tier-1-and-tier-2-model-production-approval ##### SRF-L5-MON-001: Model Signature Verification at Load Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Distribution Mrm Stage: ongoing-monitoring Operating models: AI-PaaS, Agent-PaaS, IaaS Every time a foundation model artifact is loaded into an inference environment, the ai-platform-provider must verify the cryptographic signature against the model provider's published trust store (SRF-L5-DEV-002). A load event that cannot be verified must be rejected; the model must not serve requests from an unsigned or unverifiable artifact. Signature verification must be logged with the model version, artifact hash, and verification result. This control detects supply-chain tampering: an attacker substituting a malicious model artifact for a legitimate one. Accountability for the signing infrastructure sits with the model-provider (L5); accountability for executing verification at load sits with the ai-platform-provider (L4). Both controls are required; neither substitutes for the other. Evidence: Percentage of model load events where signature verification succeeds. Any verification failure for a currently deployed model version is a Severity-1 event. Threshold: model_signature_verification_success_rate == 1.0 (100% verification success) Breach action: reject-model-load; alert-ai-platform-provider-and-model-provider; initiate-supply-chain-incident-response; suspend-affected-model-version ##### SRF-L5-MON-002: Vulnerability Disclosure SLA Adherence Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Governance Mrm Stage: ongoing-monitoring Operating models: AI-PaaS, Agent-PaaS, IaaS The model provider must operate a public vulnerability disclosure program for foundation models used by financial institutions, with documented SLAs for acknowledgment and remediation. The institution must monitor the provider's disclosure feed and track open vulnerabilities against the SLA. Required SLA tiers: Critical vulnerabilities (active exploitation or CVSS >= 9.0 equivalent for AI risk): acknowledgment within 24 hours, remediation or documented mitigation within 7 days; High vulnerabilities: acknowledgment within 72 hours, remediation within 30 days. Institutions using a model with an open Critical vulnerability beyond SLA must treat the model as impaired and escalate to L1 governance. This control monitors both provider SLA adherence and the institution's response to disclosed vulnerabilities. Evidence: Binary per open vulnerability: provider has acknowledged and provided remediation or mitigation within the SLA window for the vulnerability's severity tier. Threshold: vulnerability_disclosure_sla_adherence == true per open vulnerability within SLA window Breach action: escalate-critical-sla-breach-to-l1-governance; initiate-model-impairment-review; engage-provider-via-vendor-management-process ##### SRF-L5-ECH-001: Effective Challenge of Model Governance Standards Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Governance Mrm Stage: effective-challenge Operating models: AI-PaaS, Agent-PaaS, IaaS The institution's independent validation or second-line risk function must annually challenge whether the model governance requirements placed on foundation model providers remain appropriate and are being met. Challenge must assess: whether model cards for deployed models remain current and complete relative to the standard in SRF-L5-DEV-001, whether any model provider has missed vulnerability disclosure SLAs in the prior period and whether the institution's response was adequate, whether the model provider's published security evaluation methodology remains credible relative to the current threat environment, whether new model versions deployed in the prior year received independent evaluation per SRF-L5-VAL-001, and whether model signing and SBOM practices have been maintained across all model versions in use. Findings must be reported to the MRM head and factored into the institution's third-party model risk ratings. Evidence: Binary: annual challenge of L5 model governance standards completed, covering all required assessment areas, with findings reported to MRM head and factored into third-party model risk ratings. Threshold: model_governance_challenge_documented == true Breach action: escalate-to-cro; flag-in-annual-mrm-report; review-institution-model-provider-relationships --- ### Healthcare Reference: https://aisharedresponsibility.com/healthcare/ Controls page: https://aisharedresponsibility.com/healthcare/controls/ Machine-readable: https://aisharedresponsibility.com/data/healthcare-controls.json Healthcare-sector control schema for the CoSAI AI Shared Responsibility Framework. Maps SRF layers and accountable clinical personas to the FDA AI/ML SaMD lifecycle (design & development, verification & validation, post-market surveillance, human oversight & review), with safety thresholds and HL7 FHIR AuditEvent evidence pointers per control. Total controls: 40 #### L1: AI Business & Usage (9 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L1-DEV-001: Clinical AI Risk Classification Policy Layer: L1 (AI Business & Usage) | Persona: `clinical-ai-governance` | Component: Governance & Processes Clinical Stage: design-development Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise The organization must publish a board- or executive-approved policy assigning FDA SaMD risk tiers (Class I, II, or III) and EU AI Act risk levels (limited, high) to all AI-enabled clinical systems. The policy must name a specific senior executive accountable for clinical AI risk and require tier re-classification upon any significant algorithm change. Evidence: Binary: board- or executive-approved AI risk classification policy exists, names an accountable executive, and covers all AI-enabled clinical systems in production. Threshold: risk_classification_policy_approved == true Breach action: block-new-ai-system-clinical-deployment Regulatory mappings: - fda_tplc: Section 3.1: Intended Use and Device Description - fda_pccp: Principle 1: Focused scope with verifiable modifications - onc_hti1: N/A - hipaa: N/A - eu_ai_act: Art. 9: Risk management system - iec_62304: §4.3: Software safety classification - iso_14971: §4: Risk analysis ##### SRF-L1-DEV-002: Clinical AI System Inventory and Registry Layer: L1 (AI Business & Usage) | Persona: `clinical-ai-governance` | Component: Governance & Processes Clinical Stage: design-development Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise The organization must maintain a complete registry of all AI-enabled clinical systems, including SaMD tier, intended use statement, FDA clearance or approval status, accountable clinician, and deployment date. New systems must be registered before clinical use. Evidence: Binary: all AI-enabled clinical systems have a registry entry with required fields before first clinical use. Threshold: ai_system_registry_completeness == true Breach action: block-clinical-deployment Regulatory mappings: - fda_tplc: Section 3.2: Device Description and Specifications - fda_pccp: N/A - onc_hti1: §170.315(b)(11): Decision support interventions - hipaa: N/A - eu_ai_act: Art. 51: Registration of high-risk AI systems - iec_62304: §5.1: Software development planning - iso_14971: N/A ##### SRF-L1-DEV-003: Clinical AI Ethics Committee and Oversight Charter Layer: L1 (AI Business & Usage) | Persona: `clinical-ai-governance` | Component: Governance & Processes Clinical Stage: design-development Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise The organization must establish a clinical AI governance body (ethics committee, AI review board, or equivalent) with a named chairperson and clear CMO or CMIO accountability. The charter must define scope, meeting cadence, escalation criteria, and authority to suspend AI-enabled clinical systems. Evidence: Binary: clinical AI governance body exists with approved charter, named chairperson, and documented CMO/CMIO accountability. Threshold: ai_governance_body_chartered == true Breach action: escalate-to-board Regulatory mappings: - fda_tplc: Section 4.1: Organizational governance - fda_pccp: Principle 3: Evidence-based with appropriate oversight - onc_hti1: N/A - hipaa: N/A - eu_ai_act: Art. 9: Risk management; Art. 14: Human oversight - iec_62304: §4.1: Quality management - iso_14971: §3: General requirements ##### SRF-L1-HOR-001: Clinical AI Governance Review Cadence Layer: L1 (AI Business & Usage) | Persona: `clinical-ai-governance` | Component: Governance & Processes Clinical Stage: human-oversight-review Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise The clinical AI governance body must convene on the approved cadence (minimum quarterly for high-risk SaMD, annually for low-risk) and produce documented reviews of system performance, adverse events, and algorithm change requests. Missed reviews constitute a control failure. Evidence: Binary per review period: governance review meeting occurred, quorum met, and minutes archived within the approved cadence. Threshold: governance_review_completed_on_cadence == true Breach action: escalate-to-cmo Regulatory mappings: - fda_tplc: Section 4.1: Lifecycle management governance - fda_pccp: Principle 5: Lifecycle-oriented oversight - onc_hti1: N/A - hipaa: N/A - eu_ai_act: Art. 9(6): Risk management review - iec_62304: §4.1: Quality system review - iso_14971: §3.4: Risk management review ##### SRF-L1-HOR-002: Acceptable Use Policy for Clinical AI Layer: L1 (AI Business & Usage) | Persona: `clinical-ai-governance` | Component: Governance & Processes Clinical Stage: human-oversight-review Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise The organization must publish and enforce an acceptable use policy (AUP) covering all clinical AI systems in use. The AUP must address: permitted use cases, prohibited uses, required training for clinical staff, and consequences of misuse. Policy currency must be verified annually. Evidence: Binary: AUP published, covers all deployed AI systems, and clinical staff acknowledgment rate meets threshold. Threshold: aup_current_and_enforced == true Breach action: suspend-ai-clinical-access Regulatory mappings: - fda_tplc: Section 2.4: User interface and intended use - fda_pccp: N/A - onc_hti1: §170.315(b)(11)(vi): Transparency disclosures - hipaa: 45 CFR §164.308(a)(5): Security awareness training - eu_ai_act: Art. 13: Transparency; Art. 4: AI literacy - iec_62304: N/A - iso_14971: N/A ##### SRF-L1-HOR-003: Clinician Override Documentation Policy Layer: L1 (AI Business & Usage) | Persona: `clinical-ai-governance` | Component: Governance & Processes Clinical Stage: human-oversight-review Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise The organization must maintain a policy requiring clinicians to document when they override an AI recommendation, including the clinical rationale. Override events must be captured in the EHR audit log and reviewed as part of the governance cadence defined in SRF-L1-HOR-001. Evidence: Binary: override documentation policy exists, is enforced in EHR workflow, and override events are captured in AuditEvent. Threshold: override_documentation_policy_enforced == true Breach action: escalate-to-cmo-and-governance-body Regulatory mappings: - fda_tplc: Section 4.3: Post-market performance feedback - fda_pccp: Principle 2: Risk-based with patient safety focus - onc_hti1: §170.315(b)(11): DSI transparency including override tracking - hipaa: N/A - eu_ai_act: Art. 14(4): Human oversight measures - iec_62304: N/A - iso_14971: N/A ##### SRF-L1-PMS-001: FDA Regulatory Filing Currency Layer: L1 (AI Business & Usage) | Persona: `clinical-ai-governance` | Component: Governance & Processes Clinical Stage: post-market-surveillance Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise All SaMD in clinical production must have current FDA marketing authorization (510(k), De Novo, or PMA as applicable) or be classified as non-device clinical decision support (CDS) under the 21st Century Cures Act with documented rationale. Filing status must be tracked in the system registry and reviewed at each governance cycle. Evidence: Binary: all production SaMD have current FDA marketing authorization or documented CDS non-device determination. Threshold: regulatory_filing_current == true Breach action: escalate-to-legal-and-suspend-system Regulatory mappings: - fda_tplc: Section 3: Marketing authorization and lifecycle - fda_pccp: N/A - onc_hti1: N/A - hipaa: N/A - eu_ai_act: Art. 43: Conformity assessment - iec_62304: §4.3: Regulatory compliance - iso_14971: N/A ##### SRF-L1-PMS-002: Medical Device Adverse Event Reporting Readiness Layer: L1 (AI Business & Usage) | Persona: `clinical-ai-governance` | Component: Governance & Processes Clinical Stage: post-market-surveillance Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise The organization must maintain a documented process for detecting, evaluating, and reporting AI-related adverse events to FDA per 21 CFR Part 803 (Medical Device Reporting). The process must be tested annually with a tabletop exercise, and all AI-related adverse events must be logged in FHIR AdverseEvent. Evidence: Binary: MDR reporting process documented, tested annually, and all AI-related adverse events captured in FHIR AdverseEvent. Threshold: mdr_reporting_process_tested == true Breach action: escalate-to-quality-and-compliance Regulatory mappings: - fda_tplc: Section 4.4: Adverse event reporting - fda_pccp: N/A - onc_hti1: N/A - hipaa: N/A - eu_ai_act: Art. 73: Reporting of serious incidents - iec_62304: §6.2: Problem resolution process - iso_14971: §10: Post-production information ##### SRF-L1-PMS-003: PCCP Algorithm Change Governance Layer: L1 (AI Business & Usage) | Persona: `clinical-ai-governance` | Component: Governance & Processes Clinical Stage: post-market-surveillance Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise For AI systems with an FDA-approved Predetermined Change Control Plan, the organization must operate a change governance process that ensures all algorithm updates fall within the approved PCCP modification scope. Changes outside PCCP scope require a new FDA submission before deployment. Evidence: Binary: PCCP-aligned change review occurs before each algorithm update; unauthorized out-of-scope updates are blocked. Threshold: pccp_change_governance_active == true Breach action: rollback-and-escalate-to-regulatory Regulatory mappings: - fda_tplc: Section 4: Total lifecycle change management - fda_pccp: All five principles - onc_hti1: N/A - hipaa: N/A - eu_ai_act: Art. 43: Conformity of substantially modified systems - iec_62304: §6: Software maintenance - iso_14971: §10: Post-production feedback #### L2: AI Information (8 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L2-DEV-001: Training Data Provenance and Consent Documentation Layer: L2 (AI Information) | Persona: `clinical-data-steward` | Component: Data & Training Clinical Stage: design-development Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise All training datasets must have documented provenance including source institution(s), collection period, IRB approval or waiver, HIPAA authorization or de-identification certification per 45 CFR §164.514, and applicable data use agreements. Provenance must be archived and linkable to the deployed model version. Evidence: Binary: all training datasets have complete provenance records including source, IRB/HIPAA authorization, and de-identification certification, linked to the model version in production. Threshold: training_data_provenance_documented == true Breach action: block-model-clinical-deployment Regulatory mappings: - fda_tplc: Section 2.2: Data management for AI/ML SaMD - fda_pccp: Principle 3: Evidence-based - onc_hti1: §170.315(b)(11)(iii): Training data description - hipaa: 45 CFR §164.514: De-identification standards - eu_ai_act: Art. 10: Data and data governance - iec_62304: N/A - iso_14971: §4.2: Risk analysis data ##### SRF-L2-DEV-002: Demographic Representation Assessment Layer: L2 (AI Information) | Persona: `clinical-data-steward` | Component: Data & Training Clinical Stage: design-development Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise Training data for clinical AI systems must meet minimum representation thresholds for demographic groups (age, sex, race/ethnicity, geographic region) proportionate to the intended patient population. Assessment results must be disclosed per ONC HTI-1 transparency requirements. Evidence: Minimum representation fraction for each protected demographic group in training data, relative to the intended deployment population. Threshold: demographic_representation_rate >= {min_representation_fraction} Breach action: block-model-clinical-deployment Regulatory mappings: - fda_tplc: Section 2.3: Bias, fairness, and representation - fda_pccp: N/A - onc_hti1: §170.315(b)(11)(ii): Inclusivity and bias description - hipaa: N/A - eu_ai_act: Art. 10(2)(f): Appropriate data governance including bias examination - iec_62304: N/A - iso_14971: §4.3: Intended use analysis ##### SRF-L2-DEV-003: PHI Isolation in Non-Production Environments Layer: L2 (AI Information) | Persona: `clinical-data-steward` | Component: Data & Training Clinical Stage: design-development Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise Protected Health Information must not appear in development, test, or staging environments unless those environments meet full HIPAA Security Rule requirements. Automated PHI scanning must run on all non-production data stores, and any detection is an immediate zero-tolerance breach. Evidence: Zero tolerance: PHI detected in any non-HIPAA-compliant non-production environment. Threshold: phi_detected_in_nonprod_rate == 0 Breach action: immediate-environment-lockdown-and-incident-response Regulatory mappings: - fda_tplc: N/A - fda_pccp: N/A - onc_hti1: N/A - hipaa: 45 CFR §164.312(a)(1): Access control; §164.308(a)(3): Workforce access - eu_ai_act: Art. 10(5): Special categories data in testing - iec_62304: §5.7: Software testing (data handling) - iso_14971: N/A ##### SRF-L2-VV-001: External Validation Dataset Independence Layer: L2 (AI Information) | Persona: `clinical-data-steward` | Component: Data & Training Clinical Stage: verification-validation Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise Clinical AI validation must use a cohort that is geographically and demographically distinct from the training dataset, collected from a different institution or time period. The independence of the validation cohort must be documented in the validation report and archived with the regulatory submission package. Evidence: Binary: validation cohort documented as geographically and demographically distinct from training data, from at least one external institution. Threshold: validation_cohort_independence_documented == true Breach action: block-clinical-deployment Regulatory mappings: - fda_tplc: Section 3.4: Performance testing and validation - fda_pccp: Principle 4: Transparent with regulator - onc_hti1: §170.315(b)(11)(iv): External validation process - hipaa: N/A - eu_ai_act: Art. 10(3): Testing data relevance and appropriateness - iec_62304: §5.7: System and software testing - iso_14971: §7: Risk evaluation ##### SRF-L2-VV-002: Subgroup Performance Equivalence Layer: L2 (AI Information) | Persona: `clinical-data-steward` | Component: Data & Training Clinical Stage: verification-validation Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise Model performance (primary metric) must not degrade beyond the configured threshold across protected demographic subgroups (age, sex, race/ethnicity). Subgroup analysis must be included in the validation report and disclosed per ONC HTI-1 transparency requirements. Evidence: Maximum allowable performance degradation (e.g., AUC drop, sensitivity drop) for any protected subgroup relative to overall model performance. Threshold: subgroup_performance_gap_rate <= {max_subgroup_performance_gap} Breach action: block-clinical-deployment-and-remediate-bias Regulatory mappings: - fda_tplc: Section 3.4: Subgroup analysis - fda_pccp: N/A - onc_hti1: §170.315(b)(11)(ii): Bias description and fairness - hipaa: N/A - eu_ai_act: Art. 10(2)(f): Bias examination; Art. 15: Accuracy across groups - iec_62304: N/A - iso_14971: §5: Risk estimation ##### SRF-L2-PMS-001: Input Distribution Drift Monitoring Layer: L2 (AI Information) | Persona: `clinical-data-steward` | Component: Data & Training Clinical Stage: post-market-surveillance Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise Production clinical AI systems must monitor for significant shifts in the distribution of input data relative to the training distribution. Population Stability Index (PSI) or equivalent metric must be computed continuously and trigger re-validation when the threshold is exceeded. Evidence: Population Stability Index score for primary input features. PSI > 0.25 signals significant distribution shift requiring re-validation. Threshold: psi_score <= {max_psi_score} Breach action: trigger-revalidation-and-notify-governance Regulatory mappings: - fda_tplc: Section 4.3: Real-world performance monitoring - fda_pccp: Principle 5: Lifecycle-oriented; monitoring plan required - onc_hti1: §170.315(b)(11)(v): Ongoing maintenance - hipaa: N/A - eu_ai_act: Art. 72: Post-market monitoring obligations - iec_62304: §6.2: Problem and modification process - iso_14971: §10: Post-production activities ##### SRF-L2-PMS-002: Real-World Data Quality Scoring Layer: L2 (AI Information) | Persona: `clinical-data-steward` | Component: Data & Training Clinical Stage: post-market-surveillance Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise Production inference inputs must be scored for data quality (completeness, value range validity, temporal consistency) on every inference cycle. Inferences on inputs below the data quality threshold must be flagged to the clinician before the AI recommendation is surfaced. Evidence: Fraction of required input features present and within valid range for each inference request. Threshold: data_completeness_rate >= {min_data_completeness_rate} Breach action: flag-recommendation-to-clinician-with-data-quality-warning Regulatory mappings: - fda_tplc: Section 4.2: Real-world data quality - fda_pccp: N/A - onc_hti1: N/A - hipaa: N/A - eu_ai_act: Art. 10(3): Testing data relevance in production - iec_62304: §6.2: Software problem resolution - iso_14971: §10.2: Information from post-production phase ##### SRF-L2-PMS-003: Agent Context Store Integrity Layer: L2 (AI Information) | Persona: `clinical-data-steward` | Component: Data & Training Clinical Stage: post-market-surveillance Operating models: Agent-Clinical For agentic clinical AI systems that maintain session memory or patient context stores (e.g., FHIR-backed context), the integrity of context data must be verified at each use. Context stores must be audited for unauthorized modification, and audit records must reference the source FHIR Provenance. Evidence: Binary per session: context store integrity hash check passes before each agent inference use. Threshold: context_store_integrity_verified == true Breach action: invalidate-session-and-alert-clinical-staff Regulatory mappings: - fda_tplc: Section 4.2: Data integrity in production - fda_pccp: N/A - onc_hti1: N/A - hipaa: 45 CFR §164.312(c)(1): Integrity controls - eu_ai_act: Art. 9: Risk management for agentic AI - iec_62304: §5.7: Data integrity verification - iso_14971: N/A #### L3: AI Application (8 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L3-DEV-001: Human-in-the-Loop Gate for High-Stakes Outputs Layer: L3 (AI Application) | Persona: `clinical-application-developer` | Component: Application & Agent Clinical Stage: design-development Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise Clinical AI outputs classified as high-risk (diagnosis, treatment selection, medication dosing, procedure recommendation) must be surfaced as advisory only and require explicit clinician confirmation before any downstream action is taken. The confirmation step must be logged in the EHR AuditEvent. Evidence: Binary: high-risk AI recommendations require and record explicit clinician confirmation before any clinical action. Threshold: hitl_gate_enforced == true Breach action: block-autonomous-action-and-alert-developer Regulatory mappings: - fda_tplc: Section 2.4: Human-machine interface design - fda_pccp: N/A - onc_hti1: §170.315(b)(11): DSI transparency and clinician review - hipaa: N/A - eu_ai_act: Art. 14: Human oversight; Art. 14(4)(e): Intervention capability - iec_62304: §5.2: Software requirements (user interface safety) - iso_14971: §6: Risk control (human oversight as control) ##### SRF-L3-DEV-002: AI Explanation Coverage for Clinical Decisions Layer: L3 (AI Application) | Persona: `clinical-application-developer` | Component: Application & Agent Clinical Stage: design-development Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical Clinical AI systems must provide a human-interpretable rationale with each recommendation, meeting ONC HTI-1 transparency requirements for certified health IT. Explanation coverage rate (fraction of inferences with an explanation surfaced to the clinician) must meet the configured threshold. Evidence: Fraction of clinical AI inferences for which a human-interpretable rationale is surfaced to the clinician at the point of care. Threshold: explanation_coverage_rate >= {min_explanation_coverage_rate} Breach action: alert-product-team-and-notify-governance Regulatory mappings: - fda_tplc: Section 2.4: Transparency of AI outputs - fda_pccp: Principle 4: Transparent - onc_hti1: §170.315(b)(11)(vi)(A): DSI transparency; rationale disclosure - hipaa: N/A - eu_ai_act: Art. 13: Transparency and provision of information - iec_62304: §5.2: Software requirements (output transparency) - iso_14971: N/A ##### SRF-L3-DEV-003: Adversarial Robustness Testing Before Clinical Deployment Layer: L3 (AI Application) | Persona: `clinical-application-developer` | Component: Application & Agent Clinical Stage: design-development Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical Clinical AI systems must undergo adversarial input testing (red-team exercises) before first deployment to identify failure modes under atypical or manipulated inputs. For LLM-based clinical tools, testing must include prompt injection, jailbreak attempts, and clinical misinformation scenarios. Results must be documented and critical findings remediated before deployment. Evidence: Binary: adversarial/red-team testing completed and critical findings remediated before first clinical deployment. Threshold: adversarial_testing_completed == true Breach action: block-clinical-deployment Regulatory mappings: - fda_tplc: Section 3.3: Algorithmic testing including corner cases - fda_pccp: Principle 2: Risk-based - onc_hti1: N/A - hipaa: N/A - eu_ai_act: Art. 9(5)(b): Testing of high-risk AI systems - iec_62304: §5.7: Software testing - iso_14971: §6.4: Risk control verification ##### SRF-L3-VV-001: Clinical Workflow Usability Validation Layer: L3 (AI Application) | Persona: `clinical-application-developer` | Component: Application & Agent Clinical Stage: verification-validation Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise Clinical AI applications must undergo usability testing with representative clinical end users (clinicians, nurses, pharmacists as applicable) before deployment, following FDA Human Factors guidance and IEC 62366. Usability issues rated as safety-critical must be resolved before deployment. Evidence: Binary: usability study with representative clinical users completed; safety-critical issues resolved before deployment. Threshold: usability_study_completed == true Breach action: block-clinical-deployment Regulatory mappings: - fda_tplc: Section 2.4: Human-machine interface; Human Factors guidance - fda_pccp: N/A - onc_hti1: N/A - hipaa: N/A - eu_ai_act: Art. 14(4): Measures for human oversight - iec_62304: §5.7: System testing - iso_14971: §5.6: Usability risk analysis (per IEC 62366) ##### SRF-L3-VV-002: Prompt Injection and Input Manipulation Defense Layer: L3 (AI Application) | Persona: `clinical-application-developer` | Component: Application & Agent Clinical Stage: verification-validation Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical LLM-based clinical AI tools must implement and validate defenses against prompt injection, jailbreak, and adversarial input manipulation before clinical deployment. Defense mechanisms must be verified through structured testing and must be validated as part of the V&V package. Evidence: Binary: prompt injection and input manipulation defenses validated through structured testing before clinical deployment of any LLM-based clinical tool. Threshold: injection_defense_validated == true Breach action: block-clinical-deployment Regulatory mappings: - fda_tplc: Section 3.3: Generative AI-specific testing - fda_pccp: N/A - onc_hti1: N/A - hipaa: 45 CFR §164.308(a)(1): Security risk analysis - eu_ai_act: Art. 9(5)(b): Testing including cybersecurity - iec_62304: §5.7: Software testing (security) - iso_14971: §6.4: Risk control verification ##### SRF-L3-PMS-001: Clinician Override Rate Monitoring Layer: L3 (AI Application) | Persona: `clinical-application-developer` | Component: Application & Agent Clinical Stage: post-market-surveillance Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise The rate at which clinicians override or dismiss AI recommendations must be monitored continuously. Override rates exceeding the threshold signal poor model calibration or alert fatigue and must trigger a governance review. Override rate data must be stratified by recommendation type, care setting, and clinician role. Evidence: Fraction of AI recommendations dismissed or overridden by clinicians within a rolling 30-day window. High override rates indicate poor model fit or alert fatigue. Threshold: clinician_override_rate <= {max_clinician_override_rate} Breach action: trigger-governance-review-and-consider-model-revalidation Regulatory mappings: - fda_tplc: Section 4.3: Real-world performance monitoring - fda_pccp: Principle 5: Lifecycle monitoring - onc_hti1: §170.315(b)(11)(v): Ongoing maintenance assessment - hipaa: N/A - eu_ai_act: Art. 72: Post-market monitoring - iec_62304: §6.2: Problem and modification process - iso_14971: §10.2: Post-production information ##### SRF-L3-PMS-002: Safety-Critical Output Filter Bypass Rate Layer: L3 (AI Application) | Persona: `clinical-application-developer` | Component: Application & Agent Clinical Stage: post-market-surveillance Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical Clinical AI systems with safety-critical output filters (e.g., filters blocking lethal drug dose recommendations, filters enforcing contraindication checks) must maintain a zero-tolerance bypass rate. Any filter bypass must be treated as a patient safety incident. Evidence: Zero tolerance: any safety-critical output filter bypass constitutes an immediate patient safety incident. Threshold: output_filter_bypass_rate == 0 Breach action: immediate-patient-safety-escalation-and-system-suspend Regulatory mappings: - fda_tplc: Section 4.3: Safety monitoring - fda_pccp: N/A - onc_hti1: N/A - hipaa: N/A - eu_ai_act: Art. 9: Risk management system; Art. 15: Accuracy and robustness - iec_62304: §6.2: Problem resolution - iso_14971: §9: Residual risk evaluation ##### SRF-L3-PMS-003: Agentic Task Boundary Enforcement Layer: L3 (AI Application) | Persona: `clinical-application-developer` | Component: Application & Agent Clinical Stage: post-market-surveillance Operating models: Agent-Clinical Agentic clinical AI systems must be limited to authorized FHIR endpoint scopes defined at deployment. Scope creep, accessing FHIR resources or patient data outside the authorized SMART on FHIR scope, must be detected and blocked in real time. Evidence: Zero tolerance: agentic AI accessing FHIR resources outside authorized SMART on FHIR scopes. Threshold: unauthorized_scope_access_rate == 0 Breach action: terminate-agent-session-and-revoke-token Regulatory mappings: - fda_tplc: Section 2.4: Intended use boundary enforcement - fda_pccp: N/A - onc_hti1: N/A - hipaa: 45 CFR §164.312(a)(1): Minimum necessary access - eu_ai_act: Art. 9: Risk management for autonomous AI - iec_62304: N/A - iso_14971: §6: Risk control (scope limitation) #### L4: AI Platform (8 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L4-DEV-001: SMART on FHIR Authentication and Scoped Authorization Layer: L4 (AI Platform) | Persona: `health-platform-provider` | Component: Platform & Infrastructure Clinical Stage: design-development Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical All clinical AI integrations with EHR systems must use OAuth 2.0 with SMART on FHIR scopes. Service accounts must not hold over-privileged resource-level access. Scope grants must be reviewed at each governance cycle and reduced to minimum necessary per HIPAA minimum necessary standard. Evidence: Binary: all clinical AI integrations authenticate via OAuth2/SMART on FHIR; no over-privileged service accounts in production. Threshold: smart_fhir_auth_enforced == true Breach action: revoke-access-and-alert-security Regulatory mappings: - fda_tplc: N/A - fda_pccp: N/A - onc_hti1: §170.315(g)(10): Standardized API (SMART on FHIR) - hipaa: 45 CFR §164.312(d): Person authentication; §164.312(a)(1): Access control - eu_ai_act: Art. 9: Risk management (access security) - iec_62304: §5.2: Software requirements (authentication) - iso_14971: N/A ##### SRF-L4-DEV-002: FHIR AuditEvent Logging Completeness Layer: L4 (AI Platform) | Persona: `health-platform-provider` | Component: Platform & Infrastructure Clinical Stage: design-development Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise All AI-assisted clinical decisions, recommendation events, override events, and PHI access events must generate FHIR AuditEvent records. Audit log completeness rate (fraction of qualifying events with a corresponding AuditEvent) must meet the configured threshold, per 21 CFR Part 11 and HIPAA audit controls. Evidence: Fraction of qualifying clinical AI events (inferences, overrides, PHI access) with a corresponding FHIR AuditEvent record. Threshold: audit_log_completeness_rate >= {min_audit_completeness_rate} Breach action: alert-platform-team-and-escalate-to-compliance Regulatory mappings: - fda_tplc: N/A - fda_pccp: N/A - onc_hti1: §170.315(d)(2): Auditing actions on health information - hipaa: 45 CFR §164.312(b): Audit controls - eu_ai_act: Art. 12: Record-keeping - iec_62304: N/A - iso_14971: N/A ##### SRF-L4-DEV-003: PHI Encryption at Rest and in Transit Layer: L4 (AI Platform) | Persona: `health-platform-provider` | Component: Platform & Infrastructure Clinical Stage: design-development Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise All PHI processed by clinical AI systems must be encrypted at rest (minimum AES-256) and in transit (minimum TLS 1.2). Encryption configuration must be verified at deployment and monitored continuously. Any unencrypted PHI transmission is a zero-tolerance HIPAA Security Rule violation. Evidence: Binary: all PHI encrypted at rest (AES-256) and in transit (TLS 1.2+); any unencrypted PHI transmission is zero-tolerance. Threshold: phi_encryption_enforced == true Breach action: immediate-breach-response-and-hipaa-incident-declaration Regulatory mappings: - fda_tplc: N/A - fda_pccp: N/A - onc_hti1: N/A - hipaa: 45 CFR §164.312(a)(2)(iv): Encryption; §164.312(e)(2)(ii): Encryption in transit - eu_ai_act: Art. 9: Risk management (data security) - iec_62304: §5.2: Software requirements (data security) - iso_14971: N/A ##### SRF-L4-VV-001: Platform Security Assessment Before Clinical Deployment Layer: L4 (AI Platform) | Persona: `health-platform-provider` | Component: Platform & Infrastructure Clinical Stage: verification-validation Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise Clinical AI platforms must undergo a penetration test and vulnerability scan before clinical deployment. Critical and high-severity findings must be remediated before go-live. Results must be archived with the regulatory submission package and reviewed at each governance cycle. Evidence: Binary: penetration test and vulnerability scan completed before clinical deployment; critical and high findings remediated. Threshold: platform_pentest_completed == true Breach action: block-clinical-deployment Regulatory mappings: - fda_tplc: Section 3.2: Cybersecurity considerations - fda_pccp: N/A - onc_hti1: N/A - hipaa: 45 CFR §164.308(a)(8): Evaluation standard - eu_ai_act: Art. 9(5)(b): Testing including cybersecurity - iec_62304: §5.7: Software testing (security) - iso_14971: §6.4: Risk control verification ##### SRF-L4-VV-002: Clinical Guardrail Configuration Baseline Verification Layer: L4 (AI Platform) | Persona: `health-platform-provider` | Component: Platform & Infrastructure Clinical Stage: verification-validation Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise All clinical safety guardrails (contraindication checks, dosing limits, clinical alert thresholds, content safety filters) must be verified as active and correctly configured at platform deployment. Verification must be automated and produce a signed baseline record. Evidence: Binary: all clinical safety guardrails verified active at deployment; signed baseline record produced. Threshold: guardrail_configuration_verified == true Breach action: block-clinical-activation Regulatory mappings: - fda_tplc: Section 3.2: Safety controls verification - fda_pccp: Principle 1: Focused and verifiable - onc_hti1: N/A - hipaa: N/A - eu_ai_act: Art. 9: Risk management controls active - iec_62304: §5.7: System testing (guardrail verification) - iso_14971: §6.4: Risk control verification ##### SRF-L4-PMS-001: Unauthorized Access Attempt Monitoring Layer: L4 (AI Platform) | Persona: `health-platform-provider` | Component: Platform & Infrastructure Clinical Stage: post-market-surveillance Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise Unauthorized access attempts to clinical AI systems or PHI held by the platform must be detected and alerted in real time. Any confirmed unauthorized access is a zero-tolerance HIPAA Security Incident requiring documented breach assessment per 45 CFR §164.308(a)(6). Evidence: Zero tolerance: any confirmed unauthorized access to clinical AI systems or PHI requires immediate breach assessment. Threshold: confirmed_unauthorized_access_rate == 0 Breach action: immediate-security-incident-response-and-hipaa-breach-assessment Regulatory mappings: - fda_tplc: Section 4: Post-market cybersecurity monitoring - fda_pccp: N/A - onc_hti1: N/A - hipaa: 45 CFR §164.308(a)(6)(ii): Response and reporting - eu_ai_act: Art. 72: Post-market monitoring including security - iec_62304: N/A - iso_14971: §10.2: Post-production information ##### SRF-L4-PMS-002: Clinical AI Platform Availability SLA Layer: L4 (AI Platform) | Persona: `health-platform-provider` | Component: Platform & Infrastructure Clinical Stage: post-market-surveillance Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical Clinical AI platforms integrated into clinical workflows must meet an availability SLA calibrated to the clinical dependency risk tier. Systems supporting emergency or critical-care decisions require a higher SLA than administrative AI tools. Downtime must be logged and root cause documented. Evidence: Fraction of scheduled uptime during which the clinical AI platform is available, measured over a rolling 30-day period. Threshold: platform_availability_rate >= {min_platform_availability_rate} Breach action: alert-operations-and-review-contingency-plan Regulatory mappings: - fda_tplc: Section 4: Post-market performance - fda_pccp: N/A - onc_hti1: N/A - hipaa: 45 CFR §164.312(a)(2)(ii): Emergency access; §164.310(a)(2)(i): Contingency plan - eu_ai_act: Art. 15: Accuracy, robustness, and cybersecurity - iec_62304: N/A - iso_14971: §6: Risk control (availability) ##### SRF-L4-PMS-003: Runtime Model Artifact Integrity Verification Layer: L4 (AI Platform) | Persona: `health-platform-provider` | Component: Platform & Infrastructure Clinical Stage: post-market-surveillance Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise The cryptographic hash of the deployed model artifact must be verified at each model load. A hash mismatch between the loaded artifact and the signed baseline must trigger an immediate alert, prevent the model from serving clinical inferences, and initiate incident response. Evidence: Binary per model load: cryptographic hash of loaded model artifact matches signed baseline. Threshold: model_artifact_integrity_verified == true Breach action: block-model-serve-and-initiate-incident-response Regulatory mappings: - fda_tplc: Section 4: Post-market integrity assurance - fda_pccp: Principle 1: Verifiable modification scope - onc_hti1: N/A - hipaa: 45 CFR §164.312(c)(1): Integrity - eu_ai_act: Art. 9: Risk management (integrity controls) - iec_62304: §6.3: Software modification process - iso_14971: N/A #### L5: AI Model Provider (7 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L5-DEV-001: Model Card and SaMD Definition Statement Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Clinical Stage: design-development Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise Every clinical AI model must have a model card documenting: intended use and patient population, contraindications, training data summary, performance characteristics (sensitivity, specificity, AUC by subgroup), known limitations, and update history. The model card must map to the IEC 62304 §5.2 software requirements specification and be included in the FDA marketing submission. Evidence: Binary: model card exists with all required fields, linked to the deployed model version, and available for regulatory inspection. Threshold: model_card_complete == true Breach action: block-clinical-deployment Regulatory mappings: - fda_tplc: Section 2.1: Device description and labeling - fda_pccp: Principle 4: Transparent documentation - onc_hti1: §170.315(b)(11)(i): DSI source attributes disclosure - hipaa: N/A - eu_ai_act: Art. 11: Technical documentation; Art. 13: Transparency - iec_62304: §5.2: Software requirements specification - iso_14971: §4.2: Intended use description ##### SRF-L5-DEV-002: Software of Unknown Provenance (SOUP) Documentation Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Clinical Stage: design-development Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise All third-party AI components used in clinical AI systems, including pre-trained foundation models, inference frameworks, and data preprocessing libraries, must be documented as Software of Unknown Provenance per IEC 62304 §8. SOUP documentation must include version, license, known vulnerabilities, and validation evidence. Evidence: Binary: all third-party AI components documented as SOUP with version, license, known vulnerabilities, and validation evidence. Threshold: soup_documentation_complete == true Breach action: block-clinical-deployment Regulatory mappings: - fda_tplc: Section 2.2: Algorithm description (component provenance) - fda_pccp: N/A - onc_hti1: N/A - hipaa: N/A - eu_ai_act: Art. 11: Technical documentation - iec_62304: §8: Software configuration management; SOUP documentation - iso_14971: §4.2: Hazard identification (from third-party components) ##### SRF-L5-DEV-003: Pre-Deployment Safety Evaluation (ISO 14971) Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Clinical Stage: design-development Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise A formal risk-benefit analysis must be completed for every clinical AI model before first deployment, following ISO 14971. The analysis must enumerate hazards, estimate probability and severity of harm, define risk controls, and document residual risk. The risk file must be approved by the clinical AI governance body and archived with the regulatory submission. Evidence: Binary: ISO 14971 risk file completed, approved by governance body, and residual risk accepted before clinical deployment. Threshold: iso14971_risk_file_approved == true Breach action: block-clinical-deployment Regulatory mappings: - fda_tplc: Section 3.1: Risk management documentation - fda_pccp: Principle 2: Risk-based - onc_hti1: N/A - hipaa: N/A - eu_ai_act: Art. 9: Risk management system - iec_62304: §4.3: Safety classification (informed by risk file) - iso_14971: §7: Risk evaluation; §8: Risk control; §9: Residual risk ##### SRF-L5-VV-001: Independent Clinical Validation Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Clinical Stage: verification-validation Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise Validation of clinical AI model performance must be performed by a party independent of the development team. For Class II and III SaMD, independent validation must be performed by a qualified external organization. The validation report must be archived and referenced in the FDA marketing submission. Evidence: Binary: independent validation performed by party separate from the development team; validation report archived. Threshold: independent_validation_completed == true Breach action: block-clinical-deployment Regulatory mappings: - fda_tplc: Section 3.4: Independent testing and validation - fda_pccp: Principle 4: Transparent with regulator - onc_hti1: §170.315(b)(11)(iv): External validation - hipaa: N/A - eu_ai_act: Art. 43: Conformity assessment by Notified Body - iec_62304: §5.7: System testing (independence requirement) - iso_14971: §7: Risk evaluation (independent review) ##### SRF-L5-VV-002: Model Artifact Signing and Supply-Chain Provenance Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Clinical Stage: verification-validation Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise All clinical AI model artifacts must be cryptographically signed before deployment. The signing key must be controlled by the model provider and verified by the health platform provider at load time. A supply-chain provenance record must link the signed artifact to the training data, code commit, and build pipeline. Evidence: Binary: all production model artifacts are cryptographically signed; supply-chain provenance record links artifact to training data and build pipeline. Threshold: model_artifact_signed == true Breach action: block-artifact-deployment Regulatory mappings: - fda_tplc: Section 3.2: Cybersecurity and supply chain - fda_pccp: Principle 1: Verifiable modification scope - onc_hti1: N/A - hipaa: N/A - eu_ai_act: Art. 9: Risk management; Art. 28: Transparency for providers - iec_62304: §5.5: Software unit implementation (artifact management) - iso_14971: N/A ##### SRF-L5-PMS-001: Post-Market Performance Monitoring Plan Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Clinical Stage: post-market-surveillance Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise Every clinical AI model must have a documented Post-Market Surveillance (PMS) plan aligned to FDA PCCP Guiding Principles. The plan must define: primary performance metrics, monitoring cadence, drift thresholds triggering re-validation, and conditions requiring a new FDA submission. The PMS plan must be submitted to FDA as part of the PCCP. Evidence: Binary: PMS plan documented, approved, and actively generating performance reports on the defined cadence. Threshold: pms_plan_active == true Breach action: alert-governance-body-and-notify-regulatory Regulatory mappings: - fda_tplc: Section 4: Post-market monitoring requirements - fda_pccp: Principle 5: Lifecycle-oriented monitoring plan - onc_hti1: §170.315(b)(11)(v): Ongoing maintenance assessment - hipaa: N/A - eu_ai_act: Art. 72: Post-market monitoring plan - iec_62304: §6.2: Problem and modification process - iso_14971: §10: Post-production activities ##### SRF-L5-PMS-002: Vulnerability Disclosure and Patch Response SLA Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Clinical Stage: post-market-surveillance Operating models: SaMD-Cloud, EHR-Embedded, Agent-Clinical, On-Premise Critical CVEs affecting clinical AI model components (inference frameworks, SOUP libraries) must be assessed and patched within the configured SLA. Patch deployment must be logged. The SLA aligns to FDA's 2023 Cybersecurity Final Guidance requirements for medical device software. Evidence: Maximum number of days to deploy a patch for a critical (CVSS >= 9.0) CVE affecting clinical AI model components. Threshold: cve_critical_patch_days <= {max_cve_critical_patch_days} Breach action: escalate-to-security-and-regulatory-and-consider-system-suspension Regulatory mappings: - fda_tplc: Section 4: Post-market cybersecurity obligations - fda_pccp: N/A - onc_hti1: N/A - hipaa: 45 CFR §164.308(a)(1)(ii)(B): Risk management - eu_ai_act: Art. 72: Post-market monitoring including cybersecurity - iec_62304: §6.2: Software problem resolution - iso_14971: §10.2: Post-production information (vulnerability feedback) --- ### Insurance Reference: https://aisharedresponsibility.com/insurance/ Controls page: https://aisharedresponsibility.com/insurance/controls/ Machine-readable: https://aisharedresponsibility.com/data/insurance-controls.json Insurance-sector control schema for the CoSAI AI Shared Responsibility Framework. Maps SRF layers and accountable personas to NAIC Model Bulletin AIS Program requirements, NAIC AI Systems Evaluation Tool dimensions, Colorado Regulation 10-1-1 (3 CCR 702-10), NYDFS Circular Letter No. 7, EU AI Act articles, and OWASP LLM Top 10. Total controls: 40 #### L1: AI Business & Usage (9 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L1-DEV-001: AIS Program Document Currency and Board Approval Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Vendor-Model The insurer must maintain a written AI Systems (AIS) Program approved by the board or a designated senior executive. The program must cover governance structure, risk management framework, internal controls, and third-party AI oversight. It must be reviewed and reapproved on the cadence defined in SRF-L1-MON-001 and be available to the regulator on request per CO Regulation 10-1-1. Evidence: Binary: a written AIS Program exists, carries board or executive approval dated within the prior review cycle, and covers all four required areas. Threshold: ais_program_board_approved == true Breach action: escalate-to-board; notify-chief-compliance-officer; block-new-ai-system-deployment Regulatory mappings: - owasp_llm: N/A ##### SRF-L1-DEV-002: AI System Inventory Coverage Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Vendor-Model The insurer must maintain a current inventory of all AI systems in use across all lines of business covered by the AIS Program. The inventory must record system name, vendor (if third-party), line of business, risk tier, accountable officer, and deployment date. Coverage is defined as the percentage of known production AI systems appearing in the inventory. Evidence: Percentage of known production AI systems appearing in the current inventory. Tier-configurable; recommended minimum 95%. Threshold: ai_system_inventory_coverage_pct >= TIER_AI_INVENTORY_COVERAGE_PCT Breach action: identify-unregistered-systems; suspend-unregistered-ai-deployments; report-to-chief-compliance-officer Regulatory mappings: - nydfs_cl7: N/A - owasp_llm: N/A ##### SRF-L1-DEV-003: Third-Party AI Vendor Register with Named Accountable Officer Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, Agent-Ops, Vendor-Model The insurer must maintain a register of all third-party AI vendors whose systems are used in underwriting, rating, claims, or consumer-facing workflows. Each vendor entry must name the insurer-side accountable officer responsible for oversight of that vendor relationship, consistent with the NAIC Model Bulletin's third-party oversight requirements. Evidence: Binary: a third-party AI vendor register exists, every vendor entry names an accountable officer, and the register was reviewed within the prior review cycle. Threshold: vendor_register_accountable_officer_coverage == true Breach action: identify-vendors-without-accountable-officer; freeze-new-vendor-onboarding; escalate-to-chief-risk-officer Regulatory mappings: - owasp_llm: N/A ##### SRF-L1-DEV-004: Adverse-Decision Appeal Process Documentation Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Vendor-Model The insurer must document and publish (internally and, where required, to consumers) a process by which consumers can appeal or seek human review of adverse decisions made with AI assistance, including coverage denials, premium increases, and claims denials. The process must name the accountable function, specify the review timeline, and comply with applicable state requirements. Evidence: Binary: documented appeal process exists, names the accountable function, specifies the review timeline, and has been reviewed by legal and compliance within the prior annual cycle. Threshold: adverse_decision_appeal_process_documented == true Breach action: escalate-to-chief-compliance-officer; halt-AI-assisted-adverse-decisions-pending-remediation Regulatory mappings: - owasp_llm: N/A ##### SRF-L1-DEV-005: Governance Framework Availability Readiness for CO Regulation 10-1-1 Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Vendor-Model Insurers writing private passenger auto or health benefit plans in Colorado must have their complete AI governance structure and risk management framework available to the Division of Insurance on request from July 1, 2026. This control verifies that the framework package (AIS Program, system inventory, risk assessments, audit logs) is assembled, current, and accessible within the required response window. Evidence: Zero-tolerance: the governance framework package is assembled and can be produced to the Colorado Division of Insurance within the regulatory response window. Failure means the insurer cannot demonstrate compliance on request. Threshold: co_framework_package_availability_ready == true Breach action: immediate-escalation-to-general-counsel; suspend-AI-use-in-CO-auto-and-health-lines-pending-remediation Regulatory mappings: - naic_model_bulletin: N/A - naic_eval_tool: N/A - nydfs_cl7: N/A - eu_ai_act: N/A - owasp_llm: N/A ##### SRF-L1-MON-001: AI Risk Appetite Statement Review Cadence Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Vendor-Model The insurer must maintain a board-approved AI risk appetite statement that names a specific senior executive accountable for AI risk. The statement must define risk tolerance thresholds by line of business and operating model and must be reviewed and reapproved on the cadence defined here. Significant changes in AI system scope or a material market conduct exam finding trigger an out-of-cycle review. Evidence: Binary: board-approved AI risk appetite statement reviewed and reapproved within the prior 12 months, and within 90 days of any material scope change. Threshold: risk_appetite_statement_reviewed == true Breach action: escalate-to-board-risk-committee; flag-in-annual-compliance-report Regulatory mappings: - eu_ai_act: N/A - owasp_llm: N/A ##### SRF-L1-MON-002: Senior Management Accountability Designation for AI Governance Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Vendor-Model The insurer must designate a named senior officer accountable for the AIS Program, with documented authority, responsibilities, and reporting line. The designation must be reviewed annually and updated within 30 days of any change in the responsible officer. Evidence: Binary: a named senior officer designation exists, is current (updated within 30 days of any change), and is included in the AIS Program. Threshold: senior_officer_designation_current == true Breach action: escalate-to-board; flag-for-regulatory-disclosure Regulatory mappings: - eu_ai_act: N/A - owasp_llm: N/A ##### SRF-L1-TPO-001: Third-Party AIS Program Alignment Review Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, Agent-Ops, Vendor-Model The insurer must annually review each third-party AI vendor's AIS Program (or equivalent governance documentation) to confirm it meets or exceeds the insurer's own standards. The review must be documented, findings tracked to resolution, and results factored into vendor risk ratings. Insurers remain accountable for vendor AI outcomes under the NAIC Model Bulletin. Evidence: Binary: annual governance review completed for each in-scope third-party AI vendor, findings documented, and results incorporated into vendor risk ratings. Threshold: vendor_ais_program_review_completed == true Breach action: escalate-to-chief-risk-officer; freeze-new-vendor-deployments; initiate-remediation-plan Regulatory mappings: - owasp_llm: N/A ##### SRF-L1-TPO-002: Market Conduct Exam Readiness Documentation Package Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Vendor-Model The insurer must maintain a documentation package structured for market conduct exam review, covering governance, risk management, internal controls, and third-party oversight dimensions as reflected in the NAIC AI Systems Evaluation Tool. The package must be current, indexed, and producible within the insurer's exam response SLA. Evidence: Binary: documentation package exists, covers all NAIC Evaluation Tool dimensions, is indexed, and was reviewed within the prior 6 months. Threshold: exam_readiness_package_current == true Breach action: escalate-to-general-counsel; convene-exam-readiness-task-force Regulatory mappings: - nydfs_cl7: N/A - eu_ai_act: N/A - owasp_llm: N/A #### L2: AI Information (8 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L2-DEV-001: ECDIS Source Documentation and Permissible-Purpose Verification Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Training Operating models: AI-SaaS, AI-PaaS, Vendor-Model Any external consumer data or information source (ECDIS) used in underwriting, rating, or claims decisions must be documented with its source, data type, intended use, and a written permissible-purpose determination. Proxy variable screening per SRF-L2-DEV-002 must be completed before deployment. This control is the data-layer counterpart to the adverse-action explanation obligation in SRF-L3-VAL-001. Evidence: Zero-tolerance: no ECDIS source may be used in production without a documented permissible-purpose determination and completed proxy screening. Threshold: ecdis_permissible_purpose_documented == true Breach action: suspend-ECDIS-source-from-production; escalate-to-chief-compliance-officer; initiate-permissible-purpose-review Regulatory mappings: - owasp_llm: N/A ##### SRF-L2-DEV-002: Protected-Class Proxy Variable Screening Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Training Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Vendor-Model Before any model or ECDIS source is deployed in underwriting, rating, or claims, the data-provider must complete a documented proxy variable screen to identify variables that may serve as proxies for race, color, national origin, religion, sex, marital status, or other protected characteristics. Identified proxy variables must be reviewed by the accountable officer and either removed or subject to a documented fairness mitigation plan. Evidence: Zero-tolerance: no model or ECDIS source may enter production without a completed and documented proxy variable screen, reviewed and signed off by the accountable officer. Threshold: proxy_variable_screen_completed == true Breach action: block-deployment; escalate-to-chief-compliance-officer; initiate-proxy-variable-remediation Regulatory mappings: - owasp_llm: N/A ##### SRF-L2-DEV-003: Training Data Representativeness by Line of Business Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Training Operating models: AI-PaaS, Vendor-Model Training datasets for models used in underwriting, rating, or claims must be assessed for demographic and geographic representativeness relative to the insurer's book of business and the applicable line of business. Representativeness gaps must be documented and addressed in the model validation plan. This control applies to internally trained models and to vendor model evaluations under SRF-L5-VAL-001. Evidence: Binary: representativeness assessment completed and documented before model deployment, with findings incorporated into the model validation plan. Threshold: training_data_representativeness_documented == true Breach action: block-deployment; document-representativeness-gap; initiate-data-remediation-or-scope-restriction Regulatory mappings: - owasp_llm: N/A ##### SRF-L2-VAL-001: External Data Source Permissible Use Audit Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Training Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Vendor-Model Before production deployment, all external data sources must undergo a permissible-use audit confirming that each source's terms of use, data license, and applicable regulatory permissions cover the intended insurance use case. The audit result must be retained in the model documentation package. Evidence: Binary: permissible-use audit completed for all external data sources in the deployment package before production go-live. Threshold: external_data_permissible_use_audited == true Breach action: block-deployment; escalate-to-legal; remove-unaudited-data-sources Regulatory mappings: - naic_eval_tool: N/A - owasp_llm: N/A ##### SRF-L2-MON-001: Input Drift Monitoring via Population Stability Index Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Training Operating models: AI-PaaS, Agent-Ops, Vendor-Model For each model in production use, the data-provider or model operator must monitor the distribution of input variables against the training baseline using the Population Stability Index (PSI) or an equivalent statistical measure. Drift beyond the tier-configurable threshold triggers model review. This control is the data-layer counterpart to the performance disclosure obligation in SRF-L5-MON-001. Evidence: Maximum PSI across monitored input variables in the current monitoring window. Tier-configurable; recommended threshold: PSI < 0.2 for stable, 0.2-0.25 for minor drift requiring review, > 0.25 for significant drift requiring model review. Threshold: input_psi_max < TIER_PSI_DRIFT_THRESHOLD Breach action: trigger-model-review; notify-model-owner; escalate-to-chief-actuary-if-drift-persists-two-cycles Regulatory mappings: - nydfs_cl7: N/A - owasp_llm: N/A ##### SRF-L2-MON-002: Consumer Data Minimization in Agent Context Stores Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Training Operating models: Agent-Ops Agentic AI systems used in claims, underwriting, or customer service must enforce data minimization in context stores and retrieval-augmented generation (RAG) pipelines. Consumer PII and sensitive insurance data retained in agent context must be scoped to the current session and purged within the configured retention window. Persistent cross-session consumer profiles must not be built without explicit authorization. Evidence: Zero-tolerance: no consumer PII or sensitive insurance data retained in agent context stores beyond the configured session retention window without explicit authorization. Threshold: agent_context_pii_retention_violation_count == 0 Breach action: purge-affected-context-stores; notify-data-privacy-officer; suspend-affected-agent-workflows-pending-investigation Regulatory mappings: - naic_model_bulletin: N/A - naic_eval_tool: N/A - nydfs_cl7: N/A ##### SRF-L2-MON-003: Algorithmic Model Input Completeness Monitoring Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Training Operating models: AI-PaaS, Vendor-Model For each model in production use, the rate of missing or null values in required input variables must be monitored against the training baseline. Sustained incompleteness above the tier-configurable threshold may indicate upstream data pipeline failure, ECDIS source degradation, or a distribution shift requiring model review. Evidence: Percentage of input records with one or more missing required variables. Tier-configurable; triggers model review when above threshold for two consecutive monitoring windows. Threshold: model_input_missing_rate_pct < TIER_INPUT_MISSING_RATE_THRESHOLD_PCT Breach action: investigate-data-pipeline; notify-model-owner; escalate-if-persists-two-cycles Regulatory mappings: - co_reg_10_1_1: N/A - nydfs_cl7: N/A - owasp_llm: N/A ##### SRF-L2-TPO-001: Vendor Data Lineage Documentation Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Training Operating models: AI-SaaS, Vendor-Model Third-party AI vendors providing models or ECDIS sources must supply documented data lineage covering training data sources, data collection methods, processing steps, and retention policies. The insurer must review and retain this documentation as part of vendor onboarding and annual review under SRF-L1-TPO-001. Evidence: Binary: data lineage documentation provided by vendor, reviewed by insurer, and retained in the vendor file. Required at onboarding and refreshed at each annual review. Threshold: vendor_data_lineage_documented == true Breach action: suspend-vendor-data-source; request-documentation; escalate-to-chief-risk-officer-if-not-remediated-within-30-days Regulatory mappings: - owasp_llm: N/A #### L3: AI Application (8 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L3-DEV-001: Prompt Injection Defense for Consumer-Facing AI Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Agent Operating models: AI-SaaS, Agent-Ops AI applications and agentic systems with consumer-facing interfaces in insurance workflows (chatbots, claims intake, policy service) must implement documented defenses against prompt injection attacks. Defenses must include input validation, output filtering, and system prompt isolation. Validation must be completed before production deployment and repeated after any significant update to the application. Evidence: Zero-tolerance: no consumer-facing AI application may enter production without documented prompt injection defense validation. Threshold: prompt_injection_defense_validated == 0 Breach action: block-deployment; require-security-remediation; re-validate-before-release Regulatory mappings: - naic_model_bulletin: N/A - naic_eval_tool: N/A - co_reg_10_1_1: N/A - nydfs_cl7: N/A ##### SRF-L3-DEV-002: Agentic Task Boundary Enforcement for Claims Automation Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Agent Operating models: Agent-Ops Agentic AI systems used in claims processing, settlement, or subrogation must enforce explicit task boundaries preventing the agent from taking actions outside the defined scope without human authorization. Boundary enforcement must be implemented as a technical control (not solely policy), tested before deployment, and monitored per SRF-L3-MON-002. Evidence: Zero-tolerance: no agentic claims or underwriting workflow may enter production without validated technical task boundary enforcement. Threshold: agent_boundary_enforcement_validated == 0 Breach action: block-deployment; require-technical-boundary-remediation; escalate-to-chief-claims-officer Regulatory mappings: - naic_eval_tool: N/A - co_reg_10_1_1: N/A - nydfs_cl7: N/A ##### SRF-L3-VAL-001: Adverse-Action Explanation Coverage with Reason Codes Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Agent Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Vendor-Model Every adverse decision made with material AI assistance (coverage denial, premium increase above threshold, claims denial) must be accompanied by a documented explanation in the form of reason codes or equivalent disclosure sufficient to meet applicable state requirements. Explanation coverage must reach 100% of in-scope adverse decisions before production deployment and be maintained in ongoing monitoring. Evidence: Zero-tolerance: 100% of AI-assisted adverse decisions in scope must carry a documented explanation or reason code before deployment and in ongoing production. Threshold: adverse_action_explanation_coverage_pct == 100 Breach action: suspend-AI-assisted-adverse-decisions; escalate-to-chief-compliance-officer; initiate-explanation-remediation Regulatory mappings: - owasp_llm: N/A ##### SRF-L3-VAL-002: Human Review Gate for Adverse Underwriting and Claims Decisions Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Agent Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Vendor-Model AI-assisted adverse decisions in underwriting and claims must route through a documented human review gate before being communicated to the consumer. The gate must be a technical control in the workflow, not solely a policy requirement. Review completion must be logged with the reviewer identity, timestamp, and outcome. Evidence: Zero-tolerance: no adverse underwriting or claims decision generated with AI assistance may bypass the human review gate. Threshold: adverse_decision_human_review_gate_bypass_count == 0 Breach action: void-bypassed-decision; notify-affected-consumer; escalate-to-chief-claims-officer; regulatory-disclosure-assessment Regulatory mappings: - owasp_llm: N/A ##### SRF-L3-VAL-003: Explainability Validation for Rate and Underwriting Models Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Agent Operating models: AI-PaaS, Vendor-Model Before deployment, rate and underwriting models must undergo explainability validation confirming that the model's decision logic can be explained to an examiner, a consumer, or a regulator at the level required by applicable state rules. Validation must use a documented methodology and produce an explainability evidence artifact retained in the model file. Evidence: Binary: explainability validation completed using a documented methodology, evidence artifact produced and retained in model file, before production deployment. Threshold: explainability_validation_completed == true Breach action: block-deployment; require-explainability-validation; escalate-to-chief-actuary Regulatory mappings: - co_reg_10_1_1: N/A - owasp_llm: N/A ##### SRF-L3-MON-001: Unfair-Discrimination Outcome Testing Cadence Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Agent Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Vendor-Model For each AI model or system used in underwriting, rating, or claims, the insurer must conduct outcome testing for unfair discrimination on a cadence scaled to consumer impact and line of business. Testing must assess adverse impact ratios across protected class proxies and document results. Findings above the tier-configurable threshold trigger a model review. Evidence: Maximum adverse impact ratio across monitored protected-class proxies in the current testing window. Tier-configurable by line of business and consumer impact level; recommended threshold follows the 4/5ths rule (0.8 minimum ratio) as a starting point. Threshold: adverse_impact_ratio_max >= TIER_ADVERSE_IMPACT_RATIO_MIN Breach action: initiate-model-review; notify-chief-compliance-officer; consider-model-suspension-pending-remediation; regulatory-disclosure-assessment Regulatory mappings: - owasp_llm: N/A ##### SRF-L3-MON-002: Consumer Complaint Monitoring for AI-Driven Decisions Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Agent Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Vendor-Model The insurer must monitor the volume and nature of consumer complaints related to AI-assisted underwriting, rating, and claims decisions. Complaints must be categorized by AI system, line of business, and decision type. Complaint rate trends above the tier-configurable threshold trigger a model review and must be reported to the accountable officer. Evidence: Consumer complaint rate related to AI-assisted decisions, expressed per 1,000 decisions. Tier-configurable by line of business. Threshold: ai_complaint_rate_per_1000_decisions < TIER_COMPLAINT_RATE_THRESHOLD Breach action: trigger-model-review; notify-accountable-officer; escalate-if-trend-continues-two-quarters Regulatory mappings: - co_reg_10_1_1: N/A - nydfs_cl7: N/A - owasp_llm: N/A ##### SRF-L3-TPO-001: Vendor Application Interface Security Testing Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Agent Operating models: AI-SaaS, Vendor-Model Third-party AI applications and API integrations used in insurance workflows must undergo documented security testing before integration into production systems. Testing must cover authentication, authorization, input validation, and output integrity. Test results must be retained and reviewed at each annual vendor assessment under SRF-L1-TPO-001. Evidence: Binary: security test completed for the vendor application interface, results documented, and critical or high findings resolved before production integration. Threshold: vendor_interface_security_test_completed == 0 Breach action: block-vendor-integration; require-remediation; re-test-before-release Regulatory mappings: - naic_eval_tool: N/A - nydfs_cl7: N/A #### L4: AI Platform (8 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L4-DEV-001: Model Gateway Authentication Configuration Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Operating models: AI-PaaS, Agent-Ops Every model API gateway used to serve AI models in insurance workflows must enforce mutual TLS or equivalent strong authentication. Unauthenticated or weakly authenticated access paths must not exist in production. Configuration must be validated before deployment and after any infrastructure change affecting authentication. Evidence: Zero-tolerance: no unauthenticated access path to model API gateways may exist in production. Threshold: unauthenticated_model_gateway_access_count == 0 Breach action: block-unauthenticated-access-immediately; page-platform-security-team; initiate-incident-response Regulatory mappings: - naic_model_bulletin: N/A - naic_eval_tool: N/A - co_reg_10_1_1: N/A - nydfs_cl7: N/A ##### SRF-L4-DEV-002: Guardrail Configuration Baseline Documentation Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Operating models: AI-SaaS, AI-PaaS, Agent-Ops AI platforms used in insurance workflows must maintain a documented baseline configuration for content and behavior guardrails. The baseline must specify enabled guardrail categories, thresholds, and the review process for any configuration change. Changes to guardrail configuration must be logged and approved by the accountable officer before taking effect in production. Evidence: Binary: documented guardrail baseline exists, is current, and all configuration changes in the prior period were logged and approved. Threshold: guardrail_baseline_documented_and_current == true Breach action: revert-unapproved-change; notify-platform-security-team; review-change-management-process Regulatory mappings: - naic_eval_tool: N/A - co_reg_10_1_1: N/A - nydfs_cl7: N/A - owasp_llm: N/A ##### SRF-L4-DEV-003: PII Encryption at Rest and in Transit Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Vendor-Model All consumer PII and sensitive insurance data processed or stored by AI platform infrastructure must be encrypted at rest using AES-256 or equivalent and in transit using TLS 1.2 or higher. Encryption configuration must be validated before deployment and included in the platform security assessment under SRF-L4-VAL-001. Evidence: Zero-tolerance: no consumer PII or sensitive insurance data stored or transmitted in unencrypted form in production AI platform infrastructure. Threshold: pii_unencrypted_at_rest_or_in_transit_count == 0 Breach action: isolate-affected-data-store; page-security-team; initiate-incident-response; regulatory-disclosure-assessment Regulatory mappings: - naic_model_bulletin: N/A - naic_eval_tool: N/A - nydfs_cl7: N/A - owasp_llm: N/A ##### SRF-L4-VAL-001: Platform Security Assessment Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Vendor-Model AI platform infrastructure used in insurance workflows must undergo a documented security assessment before production deployment and annually thereafter. The assessment must cover authentication, authorization, encryption, guardrail configuration, network segmentation, and third-party component vulnerability status. Critical and high findings must be remediated before production go-live. Evidence: Binary: security assessment completed, all critical and high findings remediated, and assessment report retained before production deployment. Threshold: platform_security_assessment_completed == 0 Breach action: block-deployment; remediate-open-findings; re-assess-before-release Regulatory mappings: - nydfs_cl7: N/A - owasp_llm: N/A ##### SRF-L4-MON-001: Vendor-Model Isolation and Egress Control Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Operating models: AI-PaaS, Agent-Ops, Vendor-Model Third-party model inference endpoints and AI SaaS platforms must be isolated from core insurance systems through network segmentation and egress controls. Consumer PII and policy data must not be transmitted to vendor endpoints beyond what is required for the specific inference task. Egress controls must be monitored continuously and violations treated as security incidents. Evidence: Zero-tolerance: no unauthorized transmission of consumer PII or policy data to vendor endpoints. Any egress control violation is treated as a security incident. Threshold: vendor_model_egress_violation_count == 0 Breach action: block-egress-immediately; isolate-affected-system; initiate-incident-response; notify-data-privacy-officer Regulatory mappings: - naic_eval_tool: N/A - nydfs_cl7: N/A ##### SRF-L4-MON-002: Audit Log Completeness for AI-Assisted Decisions Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Vendor-Model All AI-assisted decisions in underwriting, rating, and claims must generate complete, tamper-evident audit log entries capturing: decision type, AI system identifier, input data hash, output recommendation, human review outcome (if applicable), timestamp, and user identity. Log completeness must be monitored continuously and the completeness rate must remain above the tier-configurable threshold. Evidence: Percentage of AI-assisted decisions with complete, tamper-evident audit log entries. Tier-configurable; recommended minimum 99.5%. Threshold: audit_log_completeness_pct >= TIER_AUDIT_LOG_COMPLETENESS_PCT Breach action: investigate-logging-gap; notify-platform-team; escalate-to-chief-compliance-officer-if-gap-exceeds-24h Regulatory mappings: - owasp_llm: N/A ##### SRF-L4-MON-003: Runtime Anomaly Detection for AI Workloads Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Operating models: AI-PaaS, Agent-Ops AI platform infrastructure must monitor runtime behavior of AI workloads for anomalous patterns indicating model compromise, data exfiltration, or unexpected model behavior. Monitoring must cover inference request volume, latency, output distribution, and network activity. Anomaly findings above the tier-configurable sensitivity threshold must trigger an incident response workflow. Evidence: Mean time to detect runtime anomaly events. Tier-configurable; lower is better. Recommended: detect within 1 hour for high-severity anomalies. Threshold: runtime_anomaly_mean_time_to_detect_hours <= TIER_RUNTIME_ANOMALY_DETECT_HOURS Breach action: page-security-operations; initiate-incident-response; isolate-anomalous-workload-if-high-severity Regulatory mappings: - naic_model_bulletin: N/A - naic_eval_tool: N/A - co_reg_10_1_1: N/A - nydfs_cl7: N/A ##### SRF-L4-TPO-001: Third-Party Platform Access Review Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Operating models: AI-SaaS, Vendor-Model Third-party AI platforms and SaaS AI providers must undergo an annual access review confirming that access credentials, API keys, and data sharing agreements are current, scoped to current use cases, and consistent with the vendor register in SRF-L1-DEV-003. Access not used in the prior 90 days must be deprovisioned or explicitly reauthorized. Evidence: Count of third-party AI platform access credentials or API keys unused in the prior 90 days that have not been deprovisioned or reauthorized. Threshold: stale_vendor_access_count == 0 Breach action: deprovision-stale-access; notify-accountable-officer; update-vendor-register Regulatory mappings: - naic_eval_tool: N/A - nydfs_cl7: N/A - owasp_llm: N/A #### L5: AI Model Provider (7 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L5-DEV-001: Model Card with Intended Line-of-Business Statement Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Operating models: AI-PaaS, Vendor-Model Every AI model used in insurance underwriting, rating, or claims must have a current model card that includes: intended lines of business, training data summary, known performance limitations, bias evaluation results, recommended use and out-of-scope uses, and the vendor's accountability contact. Model cards must be updated within 30 days of any material model change. Evidence: Binary: current model card exists, covers all required fields, and was updated within 30 days of the last material model change. Threshold: model_card_current == true Breach action: suspend-model-from-new-deployments; require-model-card-update; notify-chief-actuary Regulatory mappings: - owasp_llm: N/A ##### SRF-L5-DEV-002: Model Artifact Signing and Supply-Chain Provenance Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Operating models: AI-PaaS, Vendor-Model Model artifacts deployed in insurance AI infrastructure must be cryptographically signed by the model provider, and the insurer must verify signatures before deployment. A software bill of materials (SBOM) or equivalent supply-chain provenance document must accompany each model artifact. Signature verification must be automated in the deployment pipeline. Evidence: Zero-tolerance: no model artifact may be deployed without a verified cryptographic signature from the model provider. Threshold: unsigned_model_artifact_deployment_count == 0 Breach action: block-deployment; alert-security-team; investigate-supply-chain-integrity Regulatory mappings: - naic_model_bulletin: N/A - naic_eval_tool: N/A - co_reg_10_1_1: N/A - nydfs_cl7: N/A ##### SRF-L5-VAL-001: Pre-Deployment Fairness Evaluation by Line of Business Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Operating models: AI-PaaS, Vendor-Model Before any model is deployed in underwriting, rating, or claims for a given line of business, the model provider or insurer must complete a documented fairness evaluation assessing the model's performance across protected class proxies for that specific line. The evaluation must follow a documented methodology, produce findings, and result in either a clearance determination or a documented remediation plan before deployment is authorized. Evidence: Zero-tolerance: no model may be deployed in a covered line of business without a completed, documented fairness evaluation for that line. Threshold: pre_deployment_fairness_eval_completed == true Breach action: block-deployment; require-fairness-evaluation; escalate-to-chief-actuary-and-chief-compliance-officer Regulatory mappings: - owasp_llm: N/A ##### SRF-L5-VAL-002: Independent Model Validation Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Operating models: AI-PaaS, Vendor-Model Models used in underwriting, rating, or claims must undergo independent validation (conducted by a function or party independent of model development) before production deployment. Validation must assess conceptual soundness, data quality, performance, and limitations. Findings must be reviewed by the accountable officer and addressed before deployment. This control supports the insurer's ability to demonstrate due diligence to examiners. Evidence: Binary: independent validation completed, findings documented and reviewed, open findings addressed or risk-accepted with documented rationale, before production deployment. Threshold: independent_model_validation_completed == true Breach action: block-deployment; require-independent-validation; escalate-to-chief-risk-officer Regulatory mappings: - owasp_llm: N/A ##### SRF-L5-MON-001: Post-Deployment Performance and Drift Disclosure SLA from Vendors Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Operating models: AI-PaaS, Vendor-Model Vendors providing AI models used in underwriting, rating, or claims must contractually commit to a performance monitoring and disclosure SLA covering: notification of material performance degradation within the configured window, PSI drift reports on a defined cadence, and advance notice of planned model updates. The insurer must enforce this SLA in vendor contracts and monitor compliance. Evidence: Count of SLA breaches: vendor failed to notify within the contractual disclosure window of material performance degradation or drift event. Tier-configurable disclosure window. Threshold: vendor_perf_disclosure_sla_breach_count == 0 Breach action: notify-vendor; escalate-to-vendor-accountable-officer; assess-model-suspension; factor-into-vendor-risk-rating Regulatory mappings: - nydfs_cl7: N/A - owasp_llm: N/A ##### SRF-L5-MON-002: CVE Vulnerability Disclosure SLA from Model Provider Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Operating models: AI-PaaS, Vendor-Model Model providers must contractually commit to notifying the insurer within the configured SLA window of any CVE or material security vulnerability in model infrastructure, training pipeline, or inference API that could affect the insurer's production deployment. The insurer must have a documented patch response procedure triggered by vendor notifications. Evidence: Count of vendor CVE or security vulnerability notifications not received within the contractual disclosure SLA window. Threshold: cve_disclosure_sla_breach_count == 0 Breach action: notify-vendor; escalate-to-security-team; assess-emergency-patch; factor-into-vendor-risk-rating Regulatory mappings: - naic_eval_tool: N/A - co_reg_10_1_1: N/A - nydfs_cl7: N/A - owasp_llm: N/A ##### SRF-L5-TPO-001: Vendor Model Due-Diligence Evidence Package (NAIC Third-Party Oversight) Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Operating models: AI-SaaS, Vendor-Model For each third-party AI model used in underwriting, rating, or claims, the insurer must assemble and retain a due-diligence evidence package covering: model card (SRF-L5-DEV-001), independent validation results (SRF-L5-VAL-002), fairness evaluation (SRF-L5-VAL-001), artifact signing (SRF-L5-DEV-002), and performance SLA (SRF-L5-MON-001). This package is the primary artifact for demonstrating third-party model oversight to examiners. Evidence: Binary: due-diligence evidence package assembled, all component artifacts present and current, and package reviewed by the accountable officer within the prior annual cycle. Threshold: vendor_model_due_diligence_package_complete == true Breach action: identify-missing-artifacts; engage-vendor; escalate-to-chief-risk-officer; assess-model-suspension-if-package-cannot-be-completed Regulatory mappings: - owasp_llm: N/A --- ### Public Sector Reference: https://aisharedresponsibility.com/public-sector/ Controls page: https://aisharedresponsibility.com/public-sector/controls/ Machine-readable: https://aisharedresponsibility.com/data/public-sector-controls.json Public-sector control schema for the CoSAI AI Shared Responsibility Framework. Scoped to U.S. federal civilian agencies (FCEB). Maps SRF layers and accountable personas to OMB M-25-21 minimum practices, OMB M-25-22 acquisition requirements, FedRAMP 20x Key Security Indicators, NIST AI RMF 1.0, NIST AI 600-1 (Generative AI Profile), NIST COSAiS overlays (draft), and OWASP LLM Top 10. Each control carries a responsibility_split value aligned to FedRAMP Customer Responsibility Matrix categories. Total controls: 40 #### L1: AI Business & Usage (9 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L1-ACQ-001: AI Use-Case Inventory Completeness and Public Posting Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Shared-Service The agency must maintain a current inventory of all AI use cases, confirm completeness against known system deployments, and publicly post the inventory per M-25-21 transparency requirements. Each entry must record the use case, operating component, point of contact, and whether the use case has been designated high-impact. Evidence: Percentage of known production AI use cases appearing in the current public inventory. Tier-configurable; recommended minimum 95% for agencies with high-impact designations. Threshold: ai_use_case_inventory_coverage_pct >= TIER_AI_INVENTORY_COVERAGE_PCT Breach action: identify-unregistered-use-cases; notify-CAIO; escalate-to-AI-governance-board Regulatory mappings: - m_25_22: N/A - fedramp_20x_ksi: N/A - nist_ai_rmf: GOVERN 1.1 (policies, processes, procedures, and practices across the organization); MAP 1.1 (context is established for the AI risk assessment) - owasp_llm: N/A ##### SRF-L1-ACQ-002: High-Impact AI Designation with Named Designating Official Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Shared-Service For each AI use case, the agency must document whether a high-impact designation has been made under M-25-21, name the official who made the designation, and record the rationale. Use cases pending designation must have an open action item with a target date. Designation status must be reviewed at least annually. Evidence: Binary: every AI use case in the inventory carries a documented designation decision, names the designating official, and was reviewed within the prior annual cycle. Threshold: high_impact_designation_documented == true Breach action: flag-undesignated-use-cases; halt-new-high-impact-deployments-pending-designation; notify-CAIO Regulatory mappings: - m_25_22: N/A - fedramp_20x_ksi: N/A - nist_ai_rmf: GOVERN 1.2 (organizational teams document AI risk and benefit); MAP 2.1 (scientific findings, known and foreseeable impacts are characterized) - owasp_llm: N/A ##### SRF-L1-ACQ-003: CAIO Appointment and AI Governance Board Charter Currency Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Shared-Service The agency must have a confirmed Chief AI Officer (CAIO) in place per M-25-21 and an active AI governance board with a current charter. The charter must define membership, decision rights, meeting cadence, and escalation paths for high-impact AI use cases. Evidence: Binary: a confirmed CAIO is in place, an AI governance board exists with a current charter reviewed within the prior annual cycle, and meeting minutes from the prior quarter are on file. Threshold: caio_and_governance_board_active == true Breach action: escalate-to-agency-head; notify-OMB-liaison; freeze-new-high-impact-AI-approvals Regulatory mappings: - m_25_22: N/A - fedramp_20x_ksi: N/A - nist_ai_rmf: GOVERN 1.1 (policies, processes, procedures documented and in effect); GOVERN 2.1 (roles and responsibilities for AI risk management are designated) - owasp_llm: N/A ##### SRF-L1-ACQ-004: M-25-21 Compliance Plan Currency Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Shared-Service The agency must maintain a published compliance plan addressing all seven M-25-21 minimum practices for high-impact AI. The plan must identify which use cases are in scope, assign responsible offices, and specify target dates for any practices not yet fully implemented. It must be updated whenever material changes occur or at least annually. Evidence: Binary: a compliance plan exists, addresses all seven minimum practices, assigns responsible offices, and was updated within the prior annual cycle. Threshold: compliance_plan_current == true Breach action: escalate-to-CAIO; notify-OMB-liaison; block-new-high-impact-AI-onboarding Regulatory mappings: - m_25_22: N/A - fedramp_20x_ksi: N/A - nist_ai_rmf: GOVERN 1.1; GOVERN 4.1 (AI risk management is integrated into broader enterprise risk management) - owasp_llm: N/A ##### SRF-L1-MON-005: Discontinuation and Waiver Process Readiness Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Shared-Service For high-impact AI use cases that cannot meet the minimum practices by the September 22, 2026 deadline, the agency must have a documented discontinuation or waiver process. The process must name the approving official, specify the criteria for waiver, and set a remediation timeline. Discontinued use cases must be removed from the public inventory. Evidence: Binary: a discontinuation and waiver process exists, names the approving official, and specifies criteria and remediation timelines. Threshold: discontinuation_process_documented == true Breach action: notify-CAIO; escalate-to-AI-governance-board; schedule-emergency-compliance-review Regulatory mappings: - m_25_22: N/A - fedramp_20x_ksi: N/A - nist_ai_rmf: GOVERN 1.4 (AI risk management frameworks are established for decommissioning); MANAGE 4.1 (post-deployment AI risks are monitored and tracked) - owasp_llm: N/A ##### SRF-L1-OVR-006: Public Feedback Channel for High-Impact AI Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Shared-Service For each high-impact AI use case that affects the public, the agency must operate a public feedback channel allowing affected individuals to report concerns, errors, or adverse outcomes. The channel must be listed in the public use-case inventory entry and reviewed by the responsible office on the cadence defined in the compliance plan. Evidence: Binary: a feedback channel exists for each public-facing high-impact use case, is listed in the inventory entry, and logs show review within the prior quarter. Threshold: public_feedback_channel_operational == true Breach action: re-establish-feedback-channel; notify-CAIO; update-public-inventory-entry Regulatory mappings: - m_25_22: N/A - fedramp_20x_ksi: N/A - nist_ai_rmf: MANAGE 4.2 (mechanisms are in place to collect and analyze feedback); GOVERN 6.1 (policies for engaging AI actors across life cycle) - owasp_llm: N/A ##### SRF-L1-ACQ-007: AI Acquisition Contract Compliance with M-25-22 Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, AI-PaaS, Shared-Service All AI service contracts entered or renewed after the M-25-22 effective date must include the required performance terms, data rights clauses (agency data not used to train vendor models without consent), vendor lock-in avoidance provisions, and transparency requirements. The contracting officer and CAIO office must jointly certify compliance for each contract. Evidence: Percentage of AI service contracts entered or renewed since M-25-22 that include all required clauses. Recommended minimum 100%. Threshold: m_25_22_contract_compliance_pct == 1.0 Breach action: notify-contracting-officer; escalate-to-CAIO; flag-for-contract-remediation Regulatory mappings: - m_25_21: N/A - fedramp_20x_ksi: N/A - nist_ai_rmf: GOVERN 5.1 (organizational risk policies include supply chain risk); GOVERN 5.2 (risk management frameworks include third-party AI providers) - owasp_llm: N/A ##### SRF-L1-ACQ-008: AI Staff Training and Assessment Coverage Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Shared-Service Staff operating or overseeing high-impact AI use cases must complete agency-approved AI literacy and risk training before deployment and on the annual cadence defined in the compliance plan, per M-25-21 human training and assessment requirements. Training completion rates must be tracked by use case and reported to the CAIO. Evidence: Percentage of staff operating or overseeing high-impact AI use cases who have completed current required training. Tier-configurable; recommended minimum 95%. Threshold: ai_staff_training_completion_pct >= TIER_STAFF_TRAINING_COMPLETION_PCT Breach action: identify-untrained-staff; suspend-oversight-role-pending-training; notify-CAIO Regulatory mappings: - m_25_22: N/A - fedramp_20x_ksi: N/A - nist_ai_rmf: GOVERN 3.1 (AI risk and benefit management is reflected in workforce and capacity planning); GOVERN 3.2 (AI risk awareness training is provided) - owasp_llm: N/A ##### SRF-L1-MON-009: AI Governance Board Review Cadence for High-Impact Use Cases Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Shared-Service The agency AI governance board must formally review all high-impact AI use cases at the cadence specified in the board charter. Each review must assess minimum-practice compliance status, open remediation items, and any material changes since the prior review. Minutes must be retained and available to OMB on request. Evidence: Binary: board meeting minutes confirm reviews of all high-impact use cases at the charter-specified cadence in the prior review period. Threshold: governance_board_review_on_cadence == true Breach action: convene-emergency-board-session; notify-CAIO; document-gap-in-compliance-plan Regulatory mappings: - m_25_22: N/A - fedramp_20x_ksi: N/A - nist_ai_rmf: GOVERN 2.2 (AI risk management accountability is maintained); MANAGE 4.1 (post-deployment AI risks are monitored) - owasp_llm: N/A #### L2: AI Information (8 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L2-ACQ-001: Authority-to-Use Verification for Training and RAG Data Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Input Control Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Shared-Service Before ingesting data into AI training pipelines or retrieval-augmented generation (RAG) stores, the agency must verify authority to use, including Privacy Act System of Records Notice (SORN) coverage for Privacy Act-protected records, copyright clearance for third-party content, and data rights confirmation for vendor-supplied datasets. Evidence: Binary: every data source ingested into training or RAG pipelines has a documented authority-to-use determination on file before ingestion. Threshold: training_rag_data_authority_verified == true Breach action: halt-ingestion; notify-data-governance-officer; escalate-to-privacy-officer Regulatory mappings: - nist_ai_rmf: MAP 2.2 (scientific rigor and data quality are characterized for intended context); MAP 3.5 (organizational risk tolerances are considered) - owasp_llm: LLM03: Training Data Poisoning ##### SRF-L2-ACQ-002: Agency Data Egress Block to Commercial Model Training Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Input Control Operating models: AI-SaaS, AI-PaaS Agency data must not be used to train commercial AI vendor models without explicit agency consent, per M-25-22 data rights requirements. The data-sharing configuration of each AI service must be audited at onboarding and after any vendor terms-of-service update to confirm no training data sharing is enabled. Evidence: Binary: data-sharing configuration for every AI service confirms training data sharing is disabled or contractually prohibited per M-25-22. Threshold: vendor_training_data_sharing_disabled == true Breach action: suspend-service; notify-CAIO; notify-data-protection-officer; escalate-to-legal Regulatory mappings: - m_25_21: N/A - nist_ai_rmf: GOVERN 5.2 (risk management includes third-party AI providers and data practices); MAP 5.1 (likelihood of impacts on individuals is assessed) - owasp_llm: LLM10: Unbounded Consumption ##### SRF-L2-ACQ-003: PII and CUI Classification Coverage for AI-Accessible Data Stores Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Input Control Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Shared-Service Data stores accessible by AI systems must have complete PII and Controlled Unclassified Information (CUI) classification coverage. Unclassified data stores must be labelled before AI systems are granted access. Classification coverage must be tracked as a percentage of data stores and reported to the ISSO. Evidence: Percentage of AI-accessible data stores with complete PII and CUI classification. Tier-configurable; recommended minimum 100% for high-impact use cases. Threshold: ai_accessible_data_store_classification_coverage_pct >= TIER_DATA_CLASSIFICATION_COVERAGE_PCT Breach action: suspend-AI-access-to-unclassified-stores; notify-ISSO; escalate-to-privacy-officer Regulatory mappings: - nist_ai_rmf: MAP 2.2 (data quality and sensitivity characterized); MAP 5.1 (impacts on individuals assessed) - owasp_llm: LLM06: Sensitive Information Disclosure ##### SRF-L2-MON-004: Input Distribution Shift Monitoring (PSI) Layer: L2 (AI Information) | Persona: `application-developer` | Component: Data and Input Control Operating models: AI-SaaS, AI-PaaS, Agent-Ops For high-impact AI use cases, the agency or application developer must monitor the distribution of AI system inputs against a baseline established at deployment. Population Stability Index (PSI) or an equivalent measure must be computed on a cadence appropriate to the use case risk level and alerts triggered when drift exceeds the configured threshold. Evidence: Population Stability Index on input features. Tier-configurable; common threshold is PSI < 0.2 (stable), 0.2-0.25 (moderate drift, investigate), > 0.25 (significant drift, re-validate). Threshold: input_psi < TIER_INPUT_PSI_THRESHOLD Breach action: alert-application-developer; trigger-re-validation; notify-ISSO; pause-high-impact-outputs-pending-review Regulatory mappings: - m_25_22: N/A - nist_ai_rmf: MANAGE 2.4 (AI risk treatments are tracked); MEASURE 2.5 (ongoing monitoring tracks fairness and performance) - owasp_llm: LLM09: Misinformation ##### SRF-L2-ACQ-005: AI Interaction Log Retention Compliance (NARA) Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Input Control Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Shared-Service AI interaction logs for high-impact use cases may be federal records subject to NARA retention schedules. The agency records officer must determine retention obligations for each use case and configure log retention accordingly. Logs used as evidence for M-25-21 minimum-practice compliance must be retained through the compliance reporting period. Evidence: Binary: NARA retention determination exists for each high-impact use case, log retention is configured accordingly, and the records officer has confirmed compliance within the prior annual cycle. Threshold: ai_interaction_log_retention_compliant == true Breach action: notify-records-officer; escalate-to-ISSO; halt-log-deletion-pending-determination Regulatory mappings: - m_25_22: N/A - nist_ai_rmf: GOVERN 1.3 (organizational policies include recordkeeping); MANAGE 4.1 (monitoring includes log completeness) - owasp_llm: N/A ##### SRF-L2-MON-006: AI Output Accuracy Monitoring Against Human Baseline Layer: L2 (AI Information) | Persona: `application-developer` | Component: Data and Input Control Operating models: AI-SaaS, AI-PaaS, Agent-Ops For high-impact AI use cases with measurable accuracy requirements, the agency must track output accuracy against a validated human-reviewer baseline established before deployment. Accuracy must be re-measured on the cadence defined in the compliance plan and reviewed at each governance board cycle. Evidence: Degradation in output accuracy versus the human-reviewer baseline. Tier-configurable; alert if accuracy drops more than configured percentage points. Threshold: ai_output_accuracy_delta_vs_baseline <= TIER_ACCURACY_DEGRADATION_THRESHOLD_PCT Breach action: alert-application-developer; trigger-re-validation; notify-ISSO; pause-high-stakes-outputs Regulatory mappings: - m_25_22: N/A - nist_ai_rmf: MEASURE 2.5 (ongoing monitoring tracks performance); MANAGE 2.4 (risk treatments tracked) - owasp_llm: LLM09: Misinformation ##### SRF-L2-MON-007: Bias and Disparate Impact Monitoring for Citizen-Facing Use Cases Layer: L2 (AI Information) | Persona: `application-developer` | Component: Data and Input Control Operating models: AI-SaaS, AI-PaaS, Agent-Ops For high-impact AI use cases affecting citizen eligibility, benefits, or enforcement decisions, the agency must track output rates across protected demographic groups and test for disparate impact. Disparate impact analysis must be performed before deployment and repeated on the cadence defined in the compliance plan. Evidence: Four-fifths (80%) rule: adverse outcome rate for a protected group must not fall below 0.8 times the rate for the most favored group. Tier-configurable. Threshold: disparate_impact_ratio >= TIER_DISPARATE_IMPACT_RATIO_THRESHOLD Breach action: suspend-adverse-decisions-for-affected-groups; notify-CAIO; escalate-to-civil-rights-officer; trigger-root-cause-analysis Regulatory mappings: - m_25_22: N/A - fedramp_20x_ksi: N/A - nist_ai_rmf: MEASURE 2.2 (AI system trustworthiness characteristics are evaluated for relevant population groups); MEASURE 2.5 (ongoing monitoring tracks fairness) - owasp_llm: N/A ##### SRF-L2-ACQ-008: FedRAMP Authorization Status Verification for AI Data Services Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Input Control Operating models: AI-SaaS, AI-PaaS, Shared-Service Any cloud data service feeding AI systems must hold a FedRAMP authorization at or above the required FIPS 199 impact level for the data it handles. The agency ISSO must verify authorization status at onboarding and re-verify quarterly against the current FedRAMP marketplace authorization list. Evidence: Binary: every AI data service in use holds a current FedRAMP authorization at or above the required impact level, confirmed against the current marketplace listing. Threshold: fedramp_authorization_current == true Breach action: suspend-service-pending-authorization-verification; notify-ISSO; escalate-to-Authorizing-Official Regulatory mappings: - m_25_21: N/A - nist_ai_rmf: GOVERN 5.1 (supply chain risk management); MAP 1.5 (organizational risk tolerances for AI supply chain are established) - owasp_llm: N/A #### L3: AI Application (8 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L3-VAL-001: Pre-Deployment Testing Coverage for High-Impact Use Cases Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Integration Operating models: AI-SaaS, AI-PaaS, Agent-Ops Before deploying or materially modifying a high-impact AI use case, the agency application developer must complete a pre-deployment test plan covering functional accuracy, safety boundaries, bias and fairness, and security. Test results must be reviewed and signed off by the CAIO office before go-live, per M-25-21 pre-deployment testing minimum practice. Evidence: Binary: a completed and CAIO-reviewed pre-deployment test report exists for the current version of every high-impact AI use case. Threshold: pre_deployment_test_plan_completed == true Breach action: block-deployment; notify-CAIO; escalate-to-AI-governance-board Regulatory mappings: - nist_ai_rmf: MEASURE 2.1 (approaches for evaluating AI system trustworthiness are established); MEASURE 2.6 (evaluations are completed and results documented) - owasp_llm: LLM09: Misinformation; LLM05: Improper Output Handling ##### SRF-L3-VAL-002: AI Impact Assessment Completion for High-Impact Use Cases Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Integration Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Shared-Service Before deploying a high-impact AI use case, the agency must complete an AI impact assessment documenting potential harms to individuals and communities, mitigation measures, and residual risks. The assessment must be reviewed by the AI governance board and retained as part of the ATO documentation package. Evidence: Binary: a completed and governance-board-reviewed AI impact assessment exists for the current version of every high-impact AI use case. Threshold: ai_impact_assessment_completed == true Breach action: block-deployment; notify-CAIO; escalate-to-AI-governance-board Regulatory mappings: - m_25_22: N/A - fedramp_20x_ksi: N/A - nist_ai_rmf: MAP 5.1 (likelihood of impacts on individuals is assessed); MAP 5.2 (practices for risk assessment are in use); MEASURE 2.6 (evaluations are completed and results documented) - owasp_llm: N/A ##### SRF-L3-VAL-003: Prompt Injection Detection for Citizen-Facing AI Systems Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Integration Operating models: AI-SaaS, AI-PaaS, Agent-Ops AI applications that process citizen-supplied text input must deploy prompt injection detection controls before production. Detection coverage must be tested as part of the pre-deployment security test plan and re-tested after material model or configuration changes. Evidence: Binary: prompt injection detection is deployed and tested for every citizen-facing AI application before production. Threshold: prompt_injection_detection_deployed == true Breach action: block-deployment; notify-ISSO; escalate-to-application-security-team Regulatory mappings: - m_25_22: N/A - nist_ai_rmf: MEASURE 2.1 (trustworthiness evaluation includes security); MEASURE 2.6 - owasp_llm: LLM01: Prompt Injection ##### SRF-L3-OVR-004: Human Oversight Gate for Adverse Citizen-Facing Decisions Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Integration Operating models: AI-SaaS, AI-PaaS, Agent-Ops AI systems that generate or inform adverse decisions affecting citizens (benefits denials, eligibility determinations, enforcement actions) must route those decisions through a human oversight gate before they are finalized. The gate must be documented in the impact assessment and tested in the pre-deployment plan. Evidence: Binary: a human oversight gate is implemented and confirmed operational for every adverse-decision workflow in high-impact AI use cases. Threshold: human_oversight_gate_operational == true Breach action: suspend-adverse-decision-outputs; notify-CAIO; escalate-to-AI-governance-board; notify-affected-citizens-of-delay Regulatory mappings: - m_25_22: N/A - fedramp_20x_ksi: N/A - nist_ai_rmf: MANAGE 3.2 (AI risks are tracked and overseen by designated individuals); GOVERN 6.2 (policies for human oversight are established) - owasp_llm: N/A ##### SRF-L3-OVR-005: Remedy and Appeal Mechanism Coverage Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Integration Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Shared-Service For each high-impact AI use case affecting citizens, the agency must document and publish a remedy and appeal mechanism that allows affected individuals to challenge an AI-informed decision and receive human review. The mechanism must specify the accountable office, review timeline, and available remedies. Evidence: Binary: a documented and published remedy and appeal mechanism exists for every citizen-facing high-impact AI use case. Threshold: remedy_appeal_mechanism_documented == true Breach action: suspend-adverse-decision-outputs; notify-CAIO; escalate-to-legal-and-compliance Regulatory mappings: - m_25_22: N/A - fedramp_20x_ksi: N/A - nist_ai_rmf: MANAGE 3.2; GOVERN 6.2 (policies for human oversight and remedy) - owasp_llm: N/A ##### SRF-L3-MON-006: Agentic Task Boundary Enforcement for Casework Automation Layer: L3 (AI Application) | Persona: `agentic-platform-provider` | Component: Application and Integration Operating models: Agent-Ops AI agents used in casework, benefits processing, or citizen service workflows must operate within defined task boundaries specifying permitted actions, data access scopes, and escalation triggers. Boundary violations must be logged and trigger automated suspension of the agent session pending human review. Evidence: Count of agent task boundary violations per session. Zero tolerance for high-impact casework agents. Threshold: agent_task_boundary_violations_per_session == 0 Breach action: suspend-agent-session; notify-ISSO; escalate-to-human-caseworker; log-to-audit-trail Regulatory mappings: - m_25_22: N/A - nist_ai_rmf: MANAGE 3.2; MEASURE 2.7 (AI system trustworthiness is evaluated for agentic contexts) - owasp_llm: LLM06: Sensitive Information Disclosure; LLM08: Excessive Agency ##### SRF-L3-VAL-007: Shared-Service AI Inheritance Chain Documentation Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Integration Operating models: Shared-Service For AI systems deployed through interagency shared services (such as GSA platforms), the consuming agency must document the complete inheritance chain: which controls are inherited from the shared-service ATO, which are shared, and which are the agency's sole responsibility. The inheritance chain must be reviewed and confirmed at each ATO renewal cycle. Evidence: Binary: a current inheritance chain document exists for every shared-service AI deployment, reviewed at each ATO renewal. Threshold: inheritance_chain_documented == true Breach action: flag-shared-service-deployment; notify-ISSO; escalate-to-Authorizing-Official Regulatory mappings: - m_25_22: N/A - nist_ai_rmf: GOVERN 5.1 (supply chain risk includes shared-service providers); GOVERN 5.2 - owasp_llm: N/A ##### SRF-L3-OVR-008: AI Output Explanation for Adverse Citizen Decisions Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Integration Operating models: AI-SaaS, AI-PaaS, Agent-Ops For adverse decisions informed by AI, the agency must provide an explanation to the affected citizen describing, in plain language, the factors that contributed to the decision. The explanation must not require the citizen to have technical knowledge and must accompany any notice of the adverse decision. Evidence: Binary: every adverse-decision notice issued by a high-impact AI use case includes a plain-language explanation of contributing factors. Threshold: adverse_decision_explanation_provided == true Breach action: suspend-notice-issuance; notify-CAIO; escalate-to-legal; remediate-notice-template Regulatory mappings: - fedramp_20x_ksi: N/A - nist_ai_rmf: MANAGE 3.2; GOVERN 6.2 - owasp_llm: N/A #### L4: AI Platform (8 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L4-ACQ-001: AI Service FedRAMP Authorization at Required Impact Level Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Operating models: AI-SaaS, AI-PaaS, Shared-Service Every AI service (model API, platform, or data processing service) used in a federal AI use case must hold a current FedRAMP authorization at or above the FIPS 199 impact level required for the data it processes. For high-impact AI use cases, Moderate or High authorization is required. The ISSO must verify and document authorization status before service onboarding. Evidence: Binary: every AI service in use for the given use case holds a current FedRAMP authorization at or above the required FIPS 199 level, confirmed in the FedRAMP marketplace. Threshold: ai_service_fedramp_authorization_level_met == true Breach action: suspend-service; notify-ISSO; escalate-to-Authorizing-Official; notify-CAIO Regulatory mappings: - m_25_21: N/A - nist_ai_rmf: GOVERN 5.1 (supply chain risk management); MAP 1.5 - owasp_llm: N/A ##### SRF-L4-ACQ-002: Guardrail Configuration Baseline and Change Control Layer: L4 (AI Platform) | Persona: `agentic-platform-provider` | Component: Platform and Infrastructure Operating models: AI-SaaS, AI-PaaS, Agent-Ops The agency agentic platform provider must establish and document a guardrail configuration baseline for each AI platform deployment. Changes to guardrail configurations must go through a formal change-control process, be logged, and require ISSO review before applying to production high-impact use cases. Evidence: Binary: a current guardrail configuration baseline exists, is under change control, and no unauthorized configuration changes have been detected in the prior review period. Threshold: guardrail_baseline_documented_and_change_controlled == true Breach action: revert-unauthorized-change; notify-ISSO; escalate-to-Authorizing-Official; trigger-incident-response Regulatory mappings: - m_25_22: N/A - nist_ai_rmf: MANAGE 1.3 (responses to AI risks are selected); MEASURE 2.6 - owasp_llm: LLM07: System Prompt Leakage; LLM08: Excessive Agency ##### SRF-L4-ACQ-003: Gateway Authentication and Authorization for AI API Access Layer: L4 (AI Platform) | Persona: `agentic-platform-provider` | Component: Platform and Infrastructure Operating models: AI-SaaS, AI-PaaS, Agent-Ops All agency access to AI model APIs and platform services must route through an agency-controlled API gateway enforcing authentication, authorization, and rate limiting. Direct-to-model access outside the gateway is prohibited for high-impact use cases. The gateway configuration must be documented in the system security plan. Evidence: Binary: all AI API access for high-impact use cases routes through an authenticated agency-controlled gateway; no unauthorized direct access paths detected. Threshold: ai_api_gateway_enforced == true Breach action: block-direct-access-path; notify-ISSO; escalate-to-incident-response; log-to-audit-trail Regulatory mappings: - m_25_21: N/A - m_25_22: N/A - nist_ai_rmf: GOVERN 5.1 (supply chain access controls); MAP 1.5 - owasp_llm: LLM04: Data and Model Poisoning; LLM02: Sensitive Information Disclosure ##### SRF-L4-MON-004: CUI Encryption and Access Monitoring for AI Workloads Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Shared-Service CUI processed or stored by AI workloads must be encrypted at rest and in transit per FIPS 140-3 requirements. Access to CUI-holding stores by AI processes must be logged and monitored for anomalous access patterns. The ISSO must review access logs on the cadence defined in the system security plan. Evidence: Binary: CUI encryption at rest and in transit is verified, and access logging is confirmed active with no gaps in the prior review period. Threshold: cui_encryption_and_access_logging_compliant == true Breach action: suspend-CUI-access-by-AI-processes; notify-ISSO; escalate-to-data-protection-officer; initiate-breach-assessment Regulatory mappings: - m_25_21: N/A - m_25_22: N/A - nist_ai_rmf: MEASURE 2.5 (ongoing monitoring tracks security controls); MAP 1.5 - owasp_llm: LLM06: Sensitive Information Disclosure ##### SRF-L4-MON-005: Audit Log Completeness Aligned to FedRAMP 20x KSI Evidence Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Shared-Service Audit logs for AI platform components must meet FedRAMP 20x Key Security Indicator evidence expectations: machine-readable, pulled from production environments, and covering authentication, authorization, configuration changes, and API activity. Log completeness must be assessed against the KSI evidence requirements at each ATO renewal and after any material platform change. Evidence: Percentage of required KSI log fields present and populated in production audit logs. Recommended minimum 100% for High-impact systems; tier-configurable for Moderate and Low. Threshold: audit_log_completeness_pct >= TIER_AUDIT_LOG_COMPLETENESS_PCT Breach action: alert-ISSO; identify-missing-log-fields; escalate-to-Authorizing-Official-if-High-system Regulatory mappings: - m_25_21: N/A - m_25_22: N/A - nist_ai_rmf: MEASURE 2.5 (ongoing monitoring includes audit capabilities); MANAGE 4.1 - owasp_llm: N/A ##### SRF-L4-MON-006: Model Serving Availability SLA for Mission-Critical Use Cases Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Operating models: AI-SaaS, AI-PaaS For high-impact AI use cases designated mission-critical, the agency must document and enforce an availability SLA for the model serving layer. The SLA must be reflected in the AI service contract per M-25-22 performance-based acquisition terms. Availability must be monitored continuously and reported at each governance board review. Evidence: Percentage uptime of the model serving layer over the measurement window. Tier-configurable; recommended minimum 99.5% for mission-critical High systems. Threshold: model_serving_availability_pct >= TIER_MODEL_AVAILABILITY_PCT Breach action: escalate-to-vendor; notify-CAIO; activate-continuity-plan; log-SLA-breach-for-contract-reporting Regulatory mappings: - nist_ai_rmf: MANAGE 2.4 (risk treatments are tracked); MEASURE 2.5 - owasp_llm: LLM10: Unbounded Consumption ##### SRF-L4-VAL-007: Security Control Inheritance Verification at ATO Boundary Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Operating models: AI-SaaS, AI-PaaS, Shared-Service Before authorizing a new AI service, the agency Authorizing Official and ISSO must verify that all security controls within the FedRAMP authorization boundary are properly inherited and that agency-responsible controls are implemented and documented. The Customer Responsibility Matrix must be completed for AI-specific controls, including M-25-21 obligations. Evidence: Binary: the Customer Responsibility Matrix is completed for all AI-specific controls before ATO is granted, and agency-responsible controls are implemented and documented. Threshold: ato_crm_completed_for_ai_controls == true Breach action: block-ATO-issuance; notify-Authorizing-Official; escalate-to-ISSO Regulatory mappings: - m_25_22: N/A - nist_ai_rmf: GOVERN 5.1 (supply chain risk); GOVERN 5.2 - owasp_llm: N/A ##### SRF-L4-MON-008: Continuous Vulnerability Scanning for AI Platform Components Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Operating models: AI-SaaS, AI-PaaS, Agent-Ops AI platform components (model serving infrastructure, gateway, RAG pipeline) must be included in the agency continuous vulnerability scanning program. Critical and high-severity findings must be remediated within the timelines defined in the system security plan and reported to the ISSO at each ATO continuous monitoring cycle. Evidence: Percentage of critical and high-severity vulnerabilities in AI platform components remediated within the SSP-defined timeline. Zero tolerance for overdue critical findings. Threshold: critical_high_vuln_remediation_within_sla_pct == 1.0 Breach action: escalate-to-ISSO; notify-Authorizing-Official; initiate-POA-and-M-if-remediation-delayed Regulatory mappings: - m_25_21: N/A - m_25_22: N/A - nist_ai_rmf: MANAGE 2.4 (risk treatments tracked); MEASURE 2.5 - owasp_llm: LLM09: Misinformation; LLM04: Data and Model Poisoning #### L5: AI Model Provider (7 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L5-ACQ-001: Model Documentation Completeness per M-25-22 Transparency Terms Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model and Supplier Operating models: AI-SaaS, AI-PaaS AI vendors must provide model documentation covering training data sources, known limitations, evaluation results, and applicable use-case constraints, per M-25-22 transparency requirements. The agency must verify documentation completeness at contract execution and before renewing or expanding use. Evidence: Binary: vendor-supplied model documentation addresses all M-25-22 required transparency fields and is on file before contract execution or renewal. Threshold: model_documentation_complete == true Breach action: escalate-to-contracting-officer; hold-contract-execution; notify-CAIO Regulatory mappings: - m_25_21: N/A - nist_ai_rmf: GOVERN 5.2 (third-party AI provider transparency); MAP 4.1 (risks of receiving AI from third parties are enumerated) - owasp_llm: N/A ##### SRF-L5-MON-002: Vendor Performance and Drift Disclosure SLA Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model and Supplier Operating models: AI-SaaS, AI-PaaS AI vendors must disclose material changes to model performance or behavior (drift, retraining events, capability changes) within the timeline specified in the contract, per M-25-22 transparency requirements. The agency must verify SLA compliance at each contract review period and escalate gaps to the contracting officer. Evidence: Binary: no outstanding overdue model performance or drift disclosures from the vendor per contract SLA terms. Threshold: vendor_drift_disclosure_within_sla == true Breach action: notify-contracting-officer; escalate-to-CAIO; trigger-re-validation; document-SLA-breach Regulatory mappings: - nist_ai_rmf: MANAGE 2.4 (risk treatments tracked); MAP 4.1 - owasp_llm: N/A ##### SRF-L5-ACQ-003: Model Artifact Signing and Provenance Verification Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model and Supplier Operating models: AI-PaaS, Agent-Ops AI model artifacts (model weights, containerized inference images, fine-tuned adapters) used in agency deployments must be cryptographically signed by the vendor and the signatures verified before deployment. Unsigned or unverifiable artifacts must not be deployed to production. Evidence: Binary: all model artifacts deployed to production carry valid vendor signatures verified before deployment; no unsigned artifact deployed. Threshold: model_artifact_signature_verified == true Breach action: block-deployment; notify-ISSO; escalate-to-supply-chain-risk-manager Regulatory mappings: - m_25_21: N/A - nist_ai_rmf: GOVERN 5.1 (supply chain risk management includes artifact integrity); MAP 4.1 - owasp_llm: LLM04: Data and Model Poisoning ##### SRF-L5-MON-004: Vendor Vulnerability Disclosure SLA Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model and Supplier Operating models: AI-SaaS, AI-PaaS AI vendors must disclose security vulnerabilities in their models or platforms within the timeline required by the contract and M-25-22 terms. The agency must track open disclosures and verify remediation or mitigation within SLA. Outstanding overdue disclosures must be escalated to the contracting officer and ISSO. Evidence: Binary: no outstanding overdue vendor vulnerability disclosures per contract SLA terms. Threshold: vendor_vuln_disclosure_within_sla == true Breach action: notify-contracting-officer; escalate-to-ISSO; initiate-interim-mitigation; document-SLA-breach Regulatory mappings: - m_25_21: N/A - nist_ai_rmf: MANAGE 2.4 (risk treatments tracked); GOVERN 5.2 - owasp_llm: LLM04: Data and Model Poisoning ##### SRF-L5-ACQ-005: Model Portability Evidence for Vendor Lock-In Avoidance Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model and Supplier Operating models: AI-SaaS, AI-PaaS Per M-25-22 vendor lock-in avoidance requirements, the agency must obtain evidence before contract execution that the AI service supports data export in standard formats and that the agency can migrate to an alternative provider without losing access to its data, fine-tuning assets, or interaction history. Evidence: Binary: portability evidence (data export documentation, migration path description) is on file before contract execution. Threshold: model_portability_evidence_on_file == true Breach action: escalate-to-contracting-officer; hold-contract-execution; notify-CAIO Regulatory mappings: - m_25_21: N/A - fedramp_20x_ksi: N/A - nist_ai_rmf: GOVERN 5.1 (supply chain risk includes lock-in); MAP 4.1 - owasp_llm: N/A ##### SRF-L5-MON-006: AI Model Version Change Notification and Re-Validation Trigger Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model and Supplier Operating models: AI-SaaS, AI-PaaS When a vendor updates or replaces an AI model version used in a high-impact use case, the agency must be notified in advance per the contract SLA, conduct a re-validation assessment, and confirm that the new model version meets all pre-deployment testing requirements before continuing production use. Evidence: Binary: every vendor model version change on a high-impact use case triggers a re-validation assessment that is completed before the new version enters production. Threshold: model_version_change_revalidation_completed == true Breach action: block-new-model-version-in-production; notify-CAIO; escalate-to-Authorizing-Official; initiate-expedited-re-validation Regulatory mappings: - nist_ai_rmf: MANAGE 2.4 (post-deployment risk tracking); MEASURE 2.6 - owasp_llm: N/A ##### SRF-L5-MON-007: Third-Party AI Supply Chain Risk Assessment Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model and Supplier Operating models: AI-SaaS, AI-PaaS, Shared-Service The agency must conduct a supply chain risk assessment for each AI vendor covering financial stability, national security considerations, sub-processor dependencies, and open-source component provenance. The assessment must be reviewed by the CAIO and Authorizing Official before contract execution and refreshed annually. Evidence: Binary: a completed supply chain risk assessment exists for every AI vendor, was reviewed by CAIO and Authorizing Official, and was refreshed within the prior annual cycle. Threshold: supply_chain_risk_assessment_current == true Breach action: escalate-to-contracting-officer; flag-for-CAIO-review; delay-contract-renewal-pending-assessment Regulatory mappings: - m_25_21: N/A - nist_ai_rmf: GOVERN 5.1 (supply chain risk management); MAP 4.1 (risks from third-party AI enumerated) - owasp_llm: N/A --- ### Defense / DoD Reference: https://aisharedresponsibility.com/defense/ Controls page: https://aisharedresponsibility.com/defense/controls/ Machine-readable: https://aisharedresponsibility.com/data/defense-controls.json Defense control schema for the CoSAI AI Shared Responsibility Framework. Scoped to DoD components and the defense industrial base (DIB). Maps SRF layers and accountable personas to DoD Responsible AI (RAI) principles, DoDI 5000.90 (AI acquisition), DoDI 5000.89 (TEVV), CMMC 2.0, NIST SP 800-171 Rev 3, NIST AI RMF 1.0, and the DISA Cloud Computing SRG. Controls are parameterized by impact level (IL4/IL5/IL6) and NSS tier (non-nss/nss/both). Total controls: 53 #### L1: AI Business & Usage (11 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L1-ACQ-001: AI Use Case Registry and CDAO Reporting Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded The DoD component must maintain a current registry of all AI systems in development or operation, record each system's operating model, impact level, NSS determination, accountable program manager, and TEVV status, and report to CDAO on the schedule established by the DoD AI Inventory directive. Unregistered systems must be identified and added within 30 days of discovery. Evidence: Percentage of known production AI systems appearing in the current CDAO-reported registry. Threshold: ai_registry_coverage_pct >= TIER_AI_REGISTRY_COVERAGE_PCT Breach action: identify-unregistered-systems; notify-program-manager; escalate-to-CDAO Regulatory mappings: - dod_rai_strategy: Governable principle; DoD RAI Strategy Implementation Pathway Section TBD - dodi_5000_89: N/A - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: GOVERN 1.1 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L1-ACQ-002: Responsible AI Officer Designation Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded Each DoD component deploying AI systems must designate a Responsible AI Officer (or equivalent role under CDAO guidance) responsible for RAI principle adherence, incident escalation, and annual compliance attestation. The designation must be documented, current, and communicated to CDAO. Evidence: Binary: a named RAI Officer (or equivalent) is designated, documented, and has been confirmed active within the prior annual cycle. Threshold: rai_officer_designation_current == true Breach action: flag-gap-to-CDAO; initiate-designation-within-30-days Regulatory mappings: - dod_rai_strategy: Governable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: GOVERN 1.2 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L1-ACQ-003: AI Governance Board with CDAO Oversight Link Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded The component must establish an AI Governance Board (or equivalent body) with a defined charter, meeting cadence, quorum requirements, and a documented reporting line to CDAO. The Board must review high-risk AI use cases before operational deployment and record decisions. Evidence: Binary: the Board has met at its chartered cadence in the prior period, quorum was achieved, and decisions were recorded. Threshold: governance_board_meeting_cadence_met == true Breach action: schedule-missed-meeting; notify-RAI-officer; document-gap Regulatory mappings: - dod_rai_strategy: Governable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: GOVERN 2.2 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L1-ACQ-004: DoD RAI Compliance Plan (Five-Principle Assessment) Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded Before deploying an AI system, the component must produce a written RAI compliance plan assessing the system against all five DoD RAI principles (Responsible, Equitable, Traceable, Reliable, Governable). The plan must name the accountable official for each principle, identify gaps, and set remediation timelines. Evidence: Binary: a RAI compliance plan exists for the system, covers all five principles, and was reviewed within the prior annual cycle. Threshold: rai_compliance_plan_complete == true Breach action: block-deployment; notify-RAI-officer; produce-plan-within-60-days Regulatory mappings: - dod_rai_strategy: All five RAI principles; Implementation Pathway Section TBD - dodi_5000_89: N/A - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: GOVERN 1.3 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L1-ACQ-005: AI Acquisition Requirements per DoDI 5000.90 Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS, Program-Embedded Contracting officers and program managers must document AI-specific acquisition requirements in the solicitation or contract in accordance with DoDI 5000.90. Requirements include transparency card delivery, TEVV access, data rights, and vendor incident notification obligations. Evidence: Binary: every AI contract or task order includes the required DoDI 5000.90 clauses as verified by the contracting officer. Threshold: ai_acq_requirements_documented == true Breach action: flag-contract-for-modification; notify-contracting-officer Regulatory mappings: - dod_rai_strategy: Responsible principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: GOVERN 1.6 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L1-ACQ-006: AI Supply Chain Risk Assessment Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded Before acquiring an AI system or foundation model, the program must conduct a supply chain risk assessment covering the provenance of training data, model weights, third-party components, and hosting infrastructure. The assessment must identify foreign-origin components and apply appropriate ITAR/EAR and supply chain risk management controls. Evidence: Binary: a supply chain risk assessment exists for every AI system in the registry, covers required provenance dimensions, and was completed before contract award. Threshold: supply_chain_risk_assessment_complete == true Breach action: block-contract-award; notify-PM; escalate-to-program-security-officer Regulatory mappings: - dod_rai_strategy: Reliable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.11.1 - nist_ai_rmf: MAP 5.1 - cc_srg: N/A - owasp_llm: LLM03 ##### SRF-L1-ACQ-007: Operator and Commander AI Training Program Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded The component must establish a training program covering AI capabilities, limitations, failure modes, and RAI principles for every operator and commander using or authorizing AI-assisted decisions. Training completion must be tracked and refreshed at least annually or upon significant model update. Evidence: Percentage of designated operators and commanders who have completed current AI training within the required refresh cycle. Threshold: ai_training_completion_pct >= TIER_TRAINING_COMPLETION_PCT Breach action: restrict-system-access-for-untrained-personnel; notify-supervisor Regulatory mappings: - dod_rai_strategy: Responsible and Equitable principles; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.2.1 - nist_ai_rmf: GOVERN 4.1 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L1-OPS-008: AI Incident Reporting to CDAO Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: ops Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded The component must report AI incidents (unexpected outputs, operator overrides of consequential decisions, system failures, and adversarial attacks) to CDAO within the required reporting window. An incident response procedure must be documented, tested annually, and linked to the system's ATO. Evidence: Percentage of AI incidents reported to CDAO within the required window from time of discovery. Threshold: incident_report_timeliness_pct >= TIER_INCIDENT_REPORT_TIMELINESS_PCT Breach action: escalate-to-RAI-officer; submit-late-report-with-explanation Regulatory mappings: - dod_rai_strategy: Governable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.6.1 - nist_ai_rmf: RESPOND 1.1 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L1-ACQ-009: NSS Boundary Classification Determination Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded Before deployment, the component must produce and retain a written NSS boundary determination memo signed by the authorizing official. The memo must cite 44 USC 3552(b)(6), document the factors considered, state whether the system is NSS or non-NSS, and specify the resulting security requirements (CNSSI 1253 baseline for NSS; NIST 800-53 for non-NSS). Evidence: Binary: a signed NSS boundary determination memo exists in the ATO package for every AI system in the registry. Threshold: nss_determination_memo_exists == true Breach action: block-ATO; notify-AO; produce-determination-memo Regulatory mappings: - dod_rai_strategy: Responsible principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: GOVERN 1.7 - owasp_llm: N/A ##### SRF-L1-TEVV-010: TEVV Plan Existence and Approval Before Operational Deployment Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: tevv Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded A Test, Evaluation, Verification and Validation (TEVV) plan per DoDI 5000.89 must be documented and approved by the authorizing official before the AI system reaches operational deployment. The plan must specify test objectives, acceptance criteria, responsible testers, and re-validation triggers. Evidence: Binary: an approved TEVV plan exists in the program record for every AI system at or beyond initial operational capability. Threshold: tevv_plan_approved_before_deployment == true Breach action: block-deployment; notify-PM; escalate-to-AO Regulatory mappings: - dod_rai_strategy: Reliable and Traceable principles; Implementation Pathway Section TBD - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: MEASURE 2.1 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L1-OVR-011: Human Oversight Escalation Chain Documented and Rehearsed Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: human-oversight-remedy Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded The DoD component must document and rehearse a human oversight escalation chain for every AI system used in decisions affecting personnel, operations, or lethal force. The chain must name the operator, supervising officer, program manager, and the CDAO reporting path. For NSS systems, the chain must include the Authorizing Official. The chain must be tested at least annually through a tabletop exercise or equivalent. Evidence: Binary: a documented escalation chain exists for every AI system in the registry that falls within scope, and a tabletop exercise or equivalent rehearsal is recorded in the prior annual period. Threshold: oversight_escalation_chain_rehearsed == true Breach action: Escalate to CDAO liaison and program manager. Conduct tabletop within 30 days. Update ATO package. Regulatory mappings: - dod_rai_strategy: Responsible principle; Governable principle - dodi_5000_89: N/A - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: GOVERN 5.1 - cc_srg: N/A - owasp_llm: N/A #### L2: AI Information (10 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L2-ACQ-001: CUI Classification and Marking on AI Inputs and Outputs Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Feedback Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded All data inputs to and outputs from the AI system that contain Controlled Unclassified Information must be classified and marked per 32 CFR Part 2002 and the CUI Registry before use or release. The component must verify that AI-generated outputs do not aggregate or synthesize CUI in ways that elevate the effective classification. Evidence: Percentage of AI data assets in scope confirmed as correctly marked per CUI Registry requirements. Threshold: cui_marking_compliance_pct >= TIER_CUI_MARKING_COMPLIANCE_PCT Breach action: quarantine-unclassified-assets; notify-ISSO; remediate-within-10-days Regulatory mappings: - dod_rai_strategy: Traceable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.1.3 - nist_ai_rmf: MAP 1.6 - owasp_llm: LLM06 ##### SRF-L2-OPS-002: IL-Level Data Boundary Enforcement and Tenant Isolation Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Feedback Lifecycle Stage: ops Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded The platform must enforce data boundaries such that IL4 data cannot flow to IL5 or IL6 environments, and IL5 non-NSS data cannot flow to IL5 NSS or IL6 partitions. For cloud deployments, tenant isolation must be verified against the DISA PA for the applicable IL. Any cross-boundary data flow must trigger an alert. Evidence: Number of unresolved cross-IL boundary data flow alerts in the monitoring period. Zero-tolerance: any unresolved alert is a breach. Threshold: cross_boundary_data_flow_alerts == TIER_CROSS_BOUNDARY_ALERTS Breach action: block-data-flow; alert-ISSO; open-security-incident Regulatory mappings: - dod_rai_strategy: Reliable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.1.3 - nist_ai_rmf: MEASURE 2.6 - owasp_llm: LLM06 ##### SRF-L2-ACQ-003: Training Data Authority-to-Use Documentation Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Feedback Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded The component must document the authority to use each training dataset, including data rights clauses, any restrictions on use for AI training, ITAR/EAR applicability, and PII/PHI presence. Documentation must be retained for the life of the system and updated when training data sources change. Evidence: Percentage of training datasets in use for which authority-to-use documentation is complete and current. Threshold: training_data_atu_documented_pct >= TIER_ATU_DOCUMENTED_PCT Breach action: suspend-use-of-undocumented-data; notify-data-steward; remediate-within-30-days Regulatory mappings: - dod_rai_strategy: Traceable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: MAP 1.6 - cc_srg: N/A - owasp_llm: LLM03 ##### SRF-L2-OPS-004: Data Egress Controls per Classification Level Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Feedback Lifecycle Stage: ops Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded The system must enforce data egress controls that prevent AI outputs containing CUI or classified information from leaving the authorized environment. For IL6 systems, egress must be blocked at the classified enclave boundary. For IL4/IL5, controls must match the DISA PA requirements and be validated during TEVV. Evidence: Number of unauthorized data egress events detected per monitoring period. Zero-tolerance. Threshold: unauthorized_egress_events == TIER_UNAUTHORIZED_EGRESS_EVENTS Breach action: block-egress; alert-ISSO; open-security-incident; notify-AO Regulatory mappings: - dod_rai_strategy: Responsible principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.1.3 - nist_ai_rmf: MANAGE 2.4 - owasp_llm: LLM06 ##### SRF-L2-OPS-005: Adversarial Input Detection (Prompt Injection and Data Poisoning) Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Feedback Lifecycle Stage: ops Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded The system must deploy detection controls for prompt injection attacks and data poisoning attempts. Detection must cover both the inference-time layer (malicious user inputs) and the training pipeline (poisoned data sources). Alerts must be generated and routed to the security operations center. Evidence: Percentage of AI inference endpoints covered by active prompt injection detection controls. Threshold: adversarial_detection_coverage_pct >= TIER_ADVERSARIAL_DETECTION_PCT Breach action: block-input; alert-SOC; escalate-to-cybersecurity-team Regulatory mappings: - dod_rai_strategy: Reliable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.14.1 - nist_ai_rmf: MEASURE 2.6 - owasp_llm: LLM01 ##### SRF-L2-OPS-006: Bias and Disparate Impact Monitoring on Consequential Decisions Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Feedback Lifecycle Stage: ops Operating models: AI-SaaS, AI-PaaS, Agent-Ops For AI systems that make or inform personnel, benefits, or enforcement decisions, the component must conduct periodic bias and disparate impact analyses disaggregated by protected characteristics as applicable. Results must be reviewed by the RAI Officer and remediated if disparate impact exceeds established thresholds. Evidence: Binary: a bias and disparate impact analysis has been completed within the prior review cycle for every in-scope consequential AI use case. Threshold: bias_analysis_current == TIER_BIAS_ANALYSIS_CURRENT Breach action: notify-RAI-officer; schedule-analysis; document-gap Regulatory mappings: - dod_rai_strategy: Equitable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: MEASURE 2.5 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L2-OPS-007: AI Decision Log Retention per NARA Requirements Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Feedback Lifecycle Stage: ops Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded The component must retain logs of AI system decisions, operator overrides, and model version identifiers in accordance with NARA records schedules applicable to the underlying decision type. Retention periods must be configured before system deployment and reviewed when NARA schedules are updated. Evidence: Binary: decision logs are retained for the required period as verified by the records manager and ISSO. Threshold: decision_log_retention_compliant == true Breach action: notify-records-manager; extend-retention-period; document-gap Regulatory mappings: - dod_rai_strategy: Traceable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.3.1 - nist_ai_rmf: GOVERN 1.5 - owasp_llm: N/A ##### SRF-L2-ACQ-008: Contractor Data Isolation from DoD Data Planes Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Feedback Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS, Program-Embedded Contractor-operated AI systems must be architected so that contractor infrastructure does not have persistent access to DoD data planes beyond the scope of the contract. Data isolation requirements must be specified in the contract, verified during TEVV, and audited annually. Evidence: Binary: contractor data isolation architecture has been verified in the most recent TEVV cycle or annual audit. Threshold: contractor_data_isolation_verified == true Breach action: notify-contracting-officer; restrict-contractor-access; open-security-incident Regulatory mappings: - dod_rai_strategy: Responsible principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.1.3 - nist_ai_rmf: MAP 5.2 - owasp_llm: N/A ##### SRF-L2-TEVV-009: Training and RAG Data Integrity Verification Before Deployment Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Input Lifecycle Stage: tevv Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded Before a model or RAG pipeline is promoted to any operational environment, the data provider must verify that all training and retrieval data sources have passed quality and provenance checks: authority-to-use documented, CUI markings validated at the required IL, and a data lineage record retained. For IL5 and IL6 systems, a formal data integrity sign-off by the Chief Data Officer or delegated data authority is required before the TEVV plan closes. Evidence: Binary: a data integrity verification record exists for every data source in scope, signed by the data authority, before the TEVV plan is closed and the system is promoted to IOC. Threshold: data_integrity_signoff_before_deployment == true Breach action: Block promotion to IOC. Data authority must complete sign-off. Log gap in TEVV report. Regulatory mappings: - dod_rai_strategy: Traceable principle; Reliable principle - nist_800_171: 3.11.1 - nist_ai_rmf: MAP 2.2 - owasp_llm: LLM03 ##### SRF-L2-OVR-010: AI Decision Log Human Review Cadence for High-Stakes Operations Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Input Lifecycle Stage: human-oversight-remedy Operating models: AI-PaaS, Agent-Ops, Program-Embedded For AI systems making or informing high-stakes decisions (personnel actions, logistics prioritization, target data triage), the data provider and system owner must conduct periodic human reviews of AI decision logs to detect anomalous patterns, data drift, or systematic bias. Review frequency scales with impact level: IL4 quarterly, IL5 monthly, IL6 continuous with a formal review no less than weekly. Findings must be reported to the CDAO liaison. Evidence: Percentage of required review periods in the window during which a completed human review of AI decision logs is on record. IL4: quarterly (4 reviews/year), IL5: monthly (12/year), IL6: weekly (52/year). Threshold: decision_log_review_cadence_met >= TIER_DECISION_LOG_REVIEW_COVERAGE_PCT Breach action: Notify CDAO liaison and program manager. Complete overdue reviews. Assess whether anomalous patterns were missed during the gap period. Regulatory mappings: - dod_rai_strategy: Equitable principle; Traceable principle - dodi_5000_89: N/A - nist_800_171: 3.3.1 - nist_ai_rmf: MEASURE 2.5 - owasp_llm: N/A #### L3: AI Application (11 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L3-TEVV-001: TEVV Plan Execution per DoDI 5000.89 Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Orchestration Lifecycle Stage: tevv Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded The TEVV plan must be executed before operational deployment, producing a TEVV report documenting test results, acceptance criteria outcomes, identified failure modes, and the disposition decision (approve, conditional, or reject). The TEVV report must be signed by the authorizing official and retained in the ATO package. Evidence: Binary: a signed TEVV report exists in the ATO package for every system at or beyond initial operational capability. Threshold: tevv_report_signed_before_deployment == true Breach action: block-deployment; notify-PM; escalate-to-AO Regulatory mappings: - dod_rai_strategy: Reliable and Traceable principles; Implementation Pathway Section TBD - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: MEASURE 2.1 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L3-TEVV-002: AI Impact Assessment Before Operational Deployment Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Orchestration Lifecycle Stage: tevv Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded The component must complete an AI impact assessment documenting the decision or operational context, potential failure modes, consequences of incorrect outputs, affected populations, and mitigation measures. The assessment must be reviewed and approved before initial operational capability. Evidence: Binary: an approved AI impact assessment exists in the program record for every system before initial operational capability. Threshold: impact_assessment_approved == true Breach action: block-deployment; notify-PM; schedule-assessment Regulatory mappings: - dod_rai_strategy: Responsible and Equitable principles; Implementation Pathway Section TBD - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: MAP 2.1 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L3-OVR-003: Human Oversight Gate for Use-of-Force-Adjacent Decisions Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Orchestration Lifecycle Stage: human-oversight-remedy Operating models: Program-Embedded, Agent-Ops AI systems that inform or recommend use-of-force-adjacent decisions must incorporate a mandatory human oversight gate that prevents autonomous action. The gate must require affirmative authorization from a qualified commander or operator before any decision is executed. DoD Directive 3000.09 compliance is required for autonomous and semi-autonomous weapon functions. Evidence: Number of logged instances where a use-of-force-adjacent decision was executed without affirmative human authorization. Zero-tolerance. Threshold: human_gate_bypass_events == TIER_HUMAN_GATE_BYPASS_EVENTS Breach action: halt-system; notify-commander; open-safety-incident; report-to-CDAO Regulatory mappings: - dod_rai_strategy: Governable and Responsible principles; Implementation Pathway Section TBD - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: MANAGE 1.3 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L3-OVR-004: Operator Interface Override Capability Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Orchestration Lifecycle Stage: human-oversight-remedy Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded Every AI-assisted operational system must provide qualified operators with a clearly labeled, immediately accessible mechanism to override or disable AI outputs without requiring technical knowledge. Override events must be logged with operator identity, timestamp, and reason code. Evidence: Binary: operator override capability has been verified during TEVV and confirmed operational in the most recent system check. Threshold: override_capability_verified == true Breach action: restrict-AI-assisted-operations; notify-PM; remediate-before-next-operational-use Regulatory mappings: - dod_rai_strategy: Governable principle; Implementation Pathway Section TBD - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: MANAGE 1.3 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L3-OVR-005: Remedy and Appeal Mechanism for Adverse Administrative Decisions Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Orchestration Lifecycle Stage: human-oversight-remedy Operating models: AI-SaaS, AI-PaaS, Agent-Ops For AI systems that inform personnel, benefits, or administrative decisions with adverse consequences, the component must provide a documented remedy and appeal mechanism. Affected individuals must be informed of the mechanism. Appeals must be reviewed by a human official with authority to override the AI-informed decision. Evidence: Binary: a remedy and appeal procedure is documented, published to affected populations, and has a named review official for every in-scope administrative AI system. Threshold: remedy_mechanism_documented == true Breach action: suspend-adverse-decisions; notify-RAI-officer; publish-procedure-within-30-days Regulatory mappings: - dod_rai_strategy: Equitable and Governable principles; Implementation Pathway Section TBD - dodi_5000_89: N/A - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: MANAGE 4.2 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L3-OPS-006: Agentic Task Boundary Enforcement Layer: L3 (AI Application) | Persona: `agentic-platform-provider` | Component: Application and Orchestration Lifecycle Stage: ops Operating models: Agent-Ops Agentic AI systems must operate within documented task boundaries that restrict the range of actions the agent can take autonomously. The boundary specification must be reviewed and approved before deployment. Any attempt to execute an action outside the boundary must be blocked and logged. Evidence: Number of out-of-boundary action attempts not blocked per monitoring period. Zero-tolerance. Threshold: boundary_violation_events == TIER_BOUNDARY_VIOLATION_EVENTS Breach action: suspend-agent; alert-SOC; notify-PM Regulatory mappings: - dod_rai_strategy: Governable principle; Implementation Pathway Section TBD - nist_800_171: 3.1.1 - nist_ai_rmf: MANAGE 1.3 - owasp_llm: LLM08 ##### SRF-L3-OPS-007: Prompt Injection Detection at Application Layer Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Orchestration Lifecycle Stage: ops Operating models: AI-SaaS, AI-PaaS, Agent-Ops The application layer must implement prompt injection detection to identify adversarial instructions embedded in user inputs or retrieved documents. Detection must operate before inputs reach the model and must generate security findings routed to the SOC. Evidence: Percentage of AI inference endpoints with active application-layer prompt injection detection. Threshold: prompt_injection_detection_coverage_pct >= TIER_PROMPT_INJECTION_DETECTION_PCT Breach action: block-input; alert-SOC; notify-ISSO Regulatory mappings: - dod_rai_strategy: Reliable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.14.2 - nist_ai_rmf: MEASURE 2.6 - owasp_llm: LLM01 ##### SRF-L3-ACQ-008: Shared Service Inheritance Chain Documentation Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Orchestration Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS Where an AI system inherits security controls from a DISA-managed shared service or interagency platform, the inheritance chain must be documented in the ATO package. Documentation must identify each inherited control, the providing service, the PA or ATO that covers it, and any residual component responsibility. Evidence: Binary: every inherited control in the ATO package identifies the providing service and the authorizing PA or ATO. Threshold: inheritance_chain_documented == true Breach action: flag-incomplete-ATO; notify-ISSO; remediate-before-ATO-approval Regulatory mappings: - dod_rai_strategy: Traceable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: GOVERN 1.6 - owasp_llm: N/A ##### SRF-L3-OPS-009: Plain-Language Output Explanation for Operators Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Orchestration Lifecycle Stage: ops Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded AI systems that present recommendations to operators must provide a plain-language explanation of the factors driving the output, stated at a level comprehensible to a qualified operator without technical AI knowledge. Explanations must be surfaced in the operator interface alongside the recommendation. Evidence: Percentage of AI recommendations presented to operators accompanied by a plain-language explanation as verified by TEVV usability testing. Threshold: explanation_availability_pct >= TIER_EXPLANATION_AVAILABILITY_PCT Breach action: notify-PM; remediate-interface-before-next-TEVV Regulatory mappings: - dod_rai_strategy: Traceable and Equitable principles; Implementation Pathway Section TBD - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: MANAGE 2.2 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L3-TEVV-010: Red Team and Adversarial Robustness Test Before Deployment Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Use Case Lifecycle Stage: tevv Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded For AI systems at IL5 NSS or IL6, a structured red team exercise testing adversarial inputs, prompt injection, and model manipulation must be completed before initial operational capability and before any major capability change. For IL4 and IL5 Non-NSS systems, a documented adversarial robustness assessment is required; a full red team exercise is recommended. Results must be retained in the TEVV package and reviewed by the program manager and ISSO. Evidence: Binary: an adversarial robustness assessment (or red team report for IL5 NSS / IL6) is on file in the TEVV package before the system reaches IOC and before each major capability change. No critical-severity findings may remain open at IOC. Threshold: adversarial_robustness_assessment_complete == true Breach action: Block IOC. Program manager and ISSO must remediate critical findings and re-run assessment. Document in TEVV report. Regulatory mappings: - dod_rai_strategy: Reliable principle; Traceable principle - nist_800_171: 3.11.2 - nist_ai_rmf: MEASURE 2.6 - owasp_llm: LLM01 ##### SRF-L3-TEVV-011: Bias and Equitable Treatment Assessment Before Deployment Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Use Case Lifecycle Stage: tevv Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded Before initial operational capability, the application developer must complete a bias and equitable treatment assessment for every AI system that affects personnel decisions, benefits, or civil liberties. The assessment must test for disparate impact across protected characteristics to the extent data availability allows, document residual bias risk, and be reviewed by the RAI Officer. For systems where population-level demographic data is unavailable, a proxy-metric approach must be documented with rationale. Evidence: Binary: a bias and equitable treatment assessment is on file in the program record, reviewed by the RAI Officer, and completed before the system reaches IOC. Residual bias risks must be documented with mitigations or acceptance rationale. Threshold: bias_assessment_complete_before_ioc == true Breach action: Block IOC until assessment is complete and reviewed by RAI Officer. Document gap in TEVV report. Regulatory mappings: - dod_rai_strategy: Equitable principle - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: MEASURE 2.2 - cc_srg: N/A - owasp_llm: N/A #### L4: AI Platform (12 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L4-ACQ-001: DISA Provisional Authorization at Required IL Before Deployment Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: AI Platform Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS The cloud service or AI platform must hold a current DISA Provisional Authorization (PA) at the impact level required for the data being processed before the component may use it for DoD data. The component must verify the PA is current and covers the services in use before deployment and at each annual review. Evidence: Binary: the platform holds a current DISA PA at or above the required IL as verified against the DISA PA list. Threshold: disa_pa_current == TIER_DISA_PA_CURRENT Breach action: block-deployment; notify-PM; identify-alternative-PA-platform Regulatory mappings: - dod_rai_strategy: Responsible principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: GOVERN 1.6 - owasp_llm: N/A ##### SRF-L4-ACQ-002: STIG Baseline Configuration Enforcement Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: AI Platform Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS, Program-Embedded The platform and all AI-hosting components must be configured to the applicable DISA Security Technical Implementation Guide (STIG) baseline. STIG compliance must be verified during TEVV and continuously monitored. Open STIG findings must be tracked with accepted risk or remediation plans signed by the AO. Evidence: Number of open Category I (high) STIG findings without accepted risk signed by the AO. Zero-tolerance. Threshold: stig_open_findings_cat1 == TIER_STIG_OPEN_CAT1_FINDINGS Breach action: notify-ISSO; remediate-or-accept-risk-within-30-days; report-to-AO Regulatory mappings: - dod_rai_strategy: Reliable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.4.1 - nist_ai_rmf: MANAGE 2.4 - owasp_llm: N/A ##### SRF-L4-ACQ-003: IL-Appropriate Cloud Region Enforcement Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: AI Platform Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS The platform must enforce that DoD data is processed only in cloud regions that meet the applicable IL requirements: commercial regions for IL4, government-only regions for IL5, and classified cloud only for IL6. Region enforcement must be verified during TEVV and monitored continuously. Evidence: Number of data processing events detected in a non-authorized region. Zero-tolerance. Threshold: out_of_region_processing_events == TIER_OUT_OF_REGION_EVENTS Breach action: block-processing; alert-ISSO; notify-AO; open-security-incident Regulatory mappings: - dod_rai_strategy: Responsible principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: MANAGE 2.4 - owasp_llm: N/A ##### SRF-L4-OPS-004: CUI and Classified Data Encryption to NSA-Approved Standards Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: AI Platform Lifecycle Stage: ops Operating models: AI-SaaS, AI-PaaS, Program-Embedded CUI data at IL4/IL5 must be encrypted at rest and in transit using FIPS 140-3 validated cryptography. IL6 classified data must be encrypted using NSA-approved cryptography (Suite B or Commercial National Security Algorithm Suite). Encryption key management must comply with CNSSI 1300 or equivalent. Evidence: Percentage of data stores and transport channels confirmed compliant with the required cryptographic standard. Threshold: encryption_compliance_pct >= TIER_ENCRYPTION_COMPLIANCE_PCT Breach action: quarantine-non-compliant-store; notify-ISSO; remediate-within-30-days Regulatory mappings: - dod_rai_strategy: Responsible principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.13.8 - nist_ai_rmf: MANAGE 2.4 - owasp_llm: N/A ##### SRF-L4-OPS-005: Audit Log Completeness per DISA Requirements Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: AI Platform Lifecycle Stage: ops Operating models: AI-SaaS, AI-PaaS, Program-Embedded The platform must generate and retain audit logs meeting DISA requirements for the applicable IL. Logs must cover authentication events, API calls, data access, configuration changes, and AI inference requests. Log completeness must be verified quarterly and after any platform update. Evidence: Percentage of required event types with confirmed log generation, as verified by the most recent completeness audit. Threshold: audit_log_completeness_pct >= TIER_AUDIT_LOG_COMPLETENESS_PCT Breach action: notify-ISSO; remediate-logging-gaps; notify-AO Regulatory mappings: - dod_rai_strategy: Traceable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.3.1 - nist_ai_rmf: GOVERN 1.5 - owasp_llm: N/A ##### SRF-L4-OPS-006: API Gateway Authentication and Authorization Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: AI Platform Lifecycle Stage: ops Operating models: AI-SaaS, AI-PaaS, Agent-Ops All AI platform APIs must require authentication using DoD PKI or equivalent credential and enforce attribute-based or role-based authorization before any AI inference or data access is permitted. Unauthenticated requests must be rejected and logged. Privileged API calls require multi-factor authentication. Evidence: Percentage of AI platform API requests that bypassed authentication controls. Zero-tolerance. Threshold: unauthenticated_api_request_pct == TIER_UNAUTH_API_REQUESTS Breach action: block-request; alert-SOC; notify-ISSO Regulatory mappings: - dod_rai_strategy: Responsible principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.5.3 - nist_ai_rmf: MANAGE 2.4 - owasp_llm: LLM09 ##### SRF-L4-ACQ-007: CMMC Level 2 Assessment for Contractor-Owned CUI Platforms Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: AI Platform Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS, Program-Embedded Defense contractors operating AI platforms that process CUI must obtain a third-party CMMC Level 2 assessment (C3PAO assessment) covering the 110 NIST SP 800-171 practices before processing DoD CUI. Assessment results must be submitted to SPRS and referenced in the contract. Evidence: Binary: the contractor holds a current C3PAO-assessed CMMC Level 2 certification with results in SPRS. Threshold: cmmc_l2_assessment_current == TIER_CMMC_L2_CURRENT Breach action: block-CUI-processing; notify-contracting-officer; initiate-assessment Regulatory mappings: - dod_rai_strategy: Responsible principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - cmmc_2_0: 32 CFR Part 170, Level 2 requirements - nist_800_171: 3.12.1 - nist_ai_rmf: GOVERN 1.6 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L4-ACQ-008: CMMC Level 3 Assessment for Higher-Value Contractor Platforms Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: AI Platform Lifecycle Stage: acquisition Operating models: AI-PaaS, Program-Embedded Defense contractors operating AI platforms for programs designated as requiring CMMC Level 3 must obtain a DIBCAC-led government assessment covering the NIST SP 800-172 enhanced practices. The assessment must be current and referenced in the contract before any higher-value program data is processed. Evidence: Binary: the contractor holds a current DIBCAC-assessed CMMC Level 3 certification for the designated program. Threshold: cmmc_l3_assessment_current == TIER_CMMC_L3_CURRENT Breach action: block-higher-value-program-data; notify-contracting-officer; initiate-assessment Regulatory mappings: - dod_rai_strategy: Responsible principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - cmmc_2_0: 32 CFR Part 170, Level 3 requirements - nist_800_171: 3.12.1 - nist_ai_rmf: GOVERN 1.6 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L4-OPS-009: Continuous Vulnerability Scanning via DISA ACAS Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: AI Platform Lifecycle Stage: ops Operating models: AI-SaaS, AI-PaaS, Program-Embedded AI platform hosts and containers must be continuously scanned using DISA-approved tools (Assured Compliance Assessment Solution, ACAS) and findings must be tracked and remediated per DISA remediation timelines. Scan coverage must include all AI inference and supporting infrastructure nodes. Evidence: Percentage of AI platform nodes covered by ACAS scans within the required scan cadence. Threshold: acas_scan_coverage_pct >= TIER_ACAS_COVERAGE_PCT Breach action: notify-ISSO; expand-scan-scope; report-gap-to-AO Regulatory mappings: - dod_rai_strategy: Reliable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.11.2 - nist_ai_rmf: MANAGE 2.4 - owasp_llm: N/A ##### SRF-L4-OPS-010: Mission-Critical AI Availability SLA Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: AI Platform Lifecycle Stage: ops Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded AI systems supporting mission-critical operations must have a documented availability SLA, a tested failover or degraded-mode procedure, and a recovery time objective (RTO) approved by the operational commander. Availability must be monitored continuously and reported against the SLA. Evidence: Percentage of monitoring periods in which the system met its approved availability SLA. Threshold: availability_sla_compliance_pct >= TIER_AVAILABILITY_SLA_PCT Breach action: notify-operational-commander; activate-degraded-mode; open-availability-incident Regulatory mappings: - dod_rai_strategy: Reliable principle; Implementation Pathway Section TBD - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: MEASURE 2.7 - owasp_llm: N/A ##### SRF-L4-TEVV-011: Platform Security Configuration Validated Against CC SRG Baseline Before ATO Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: AI Platform (Runtime and Infrastructure) Lifecycle Stage: tevv Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded Before an authority to operate is granted, the platform engineering team and ISSO must verify that the cloud platform configuration conforms to the applicable CC SRG baseline for the target impact level. This includes STIG compliance for OS and middleware, network segmentation validation, and audit logging configuration. For IL6 systems, validation must be performed on the classified network by cleared personnel and documented in the classified ATO package. Findings at CAT I must be remediated before ATO is granted. Evidence: Binary: a completed CC SRG baseline validation report is on file in the ATO package, no CAT I findings remain open, and the ISSO has signed off before the ATO is granted. Threshold: cc_srg_baseline_validation_complete == true Breach action: Block ATO. Remediate CAT I findings. ISSO re-validates and updates ATO package. Regulatory mappings: - dod_rai_strategy: Reliable principle - dodi_5000_89: N/A - nist_800_171: 3.4.1 - nist_ai_rmf: MANAGE 2.2 - owasp_llm: N/A ##### SRF-L4-OVR-012: Platform-Level Emergency Stop Capability Tested Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: AI Platform (Runtime and Infrastructure) Lifecycle Stage: human-oversight-remedy Operating models: AI-PaaS, Agent-Ops, Program-Embedded Every AI platform hosting systems that directly inform or execute operational decisions must implement a platform-level emergency stop capability: a mechanism that allows an authorized operator to halt all AI-driven decision outputs within a defined response time. The mechanism must be tested annually and after any major platform change. Test results must be retained in the program record. For IL6 and Program-Embedded operating models, the response time requirement is more stringent and must be documented in the program's operational requirements. Evidence: Binary: a documented emergency stop test result is on file, conducted within the prior annual period (or after most recent major platform change, whichever is more recent), confirming the stop mechanism operates within the required response time. Threshold: emergency_stop_test_current == true Breach action: Notify program manager and CDAO liaison. Conduct emergency stop test within 30 days. Document result in program record. Regulatory mappings: - dod_rai_strategy: Governable principle; Responsible principle - cmmc_2_0: N/A - nist_800_171: 3.1.1 - nist_ai_rmf: GOVERN 5.2 - owasp_llm: N/A #### L5: AI Model Provider (9 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L5-ACQ-001: Model Transparency Card per DoDI 5000.90 Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS, Program-Embedded The model provider must deliver a transparency card documenting the model's intended use, training data scope, known limitations, performance bounds, failure modes, and version identifier. The card must be delivered before contract award for AI systems subject to DoDI 5000.90 and updated when the model is significantly updated. Evidence: Binary: a transparency card has been delivered for every AI system subject to DoDI 5000.90 and is current for the deployed model version. Threshold: transparency_card_delivered == true Breach action: block-deployment; notify-contracting-officer; request-card-from-vendor Regulatory mappings: - dod_rai_strategy: Traceable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: GOVERN 1.6 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L5-OPS-002: Vendor Model Drift Disclosure SLA Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Lifecycle Stage: ops Operating models: AI-SaaS, AI-PaaS The vendor or model provider must contractually commit to disclosing any model updates or behavioral changes that may affect performance, accuracy, or safety within the defined disclosure window. The component must monitor for drift and trigger re-validation when a disclosure is received. Evidence: Percentage of model updates where the vendor provided timely disclosure within the contractual SLA window. Threshold: drift_disclosure_sla_compliance_pct >= TIER_DRIFT_DISCLOSURE_SLA_PCT Breach action: notify-contracting-officer; initiate-contract-remedy; trigger-re-validation Regulatory mappings: - dod_rai_strategy: Reliable principle; Implementation Pathway Section TBD - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: MEASURE 2.8 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L5-ACQ-003: Model Artifact Signing and Bill of AI Materials Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Lifecycle Stage: acquisition Operating models: AI-PaaS, Program-Embedded All AI model artifacts deployed on DoD platforms must be cryptographically signed by the provider. The component must maintain a Bill of AI Materials (BoAIM) listing model identifiers, version hashes, training data provenance, and third-party component dependencies for every model in production. Evidence: Binary: a current BoAIM exists for every production model, artifact signatures are verified, and the BoAIM was reviewed within the prior annual cycle. Threshold: boaim_current_and_signed == true Breach action: notify-PM; re-verify-signatures; update-BoAIM-within-30-days Regulatory mappings: - dod_rai_strategy: Traceable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.14.3 - nist_ai_rmf: MAP 5.1 - cc_srg: N/A - owasp_llm: LLM03 ##### SRF-L5-OPS-004: Vulnerability Disclosure SLA and Patch Cadence Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Lifecycle Stage: ops Operating models: AI-SaaS, AI-PaaS, Program-Embedded The model or platform provider must commit to a vulnerability disclosure SLA and patch release cadence in the contract. Critical vulnerabilities must be disclosed within 24 hours of discovery and patched or mitigated within the contractual window. The component must apply patches within its own remediation timeline after vendor release. Evidence: Percentage of critical model vulnerabilities patched or mitigated within the contractual window from vendor disclosure. Threshold: critical_vuln_patch_timeliness_pct >= TIER_CRITICAL_PATCH_TIMELINESS_PCT Breach action: notify-ISSO; apply-emergency-patch; report-to-AO Regulatory mappings: - dod_rai_strategy: Reliable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.14.1 - nist_ai_rmf: MANAGE 2.4 - owasp_llm: N/A ##### SRF-L5-ACQ-005: Model Portability to Avoid Vendor Lock-In Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS Contracts for AI systems must include data rights and model portability provisions that allow the component to transition to an alternative model without losing operational capability. Portability must be verified through a portability exercise or documented portability plan approved by the program manager. Evidence: Binary: a portability plan or portability exercise result is documented and approved in the program record. Threshold: portability_plan_approved == TIER_PORTABILITY_PLAN_APPROVED Breach action: notify-contracting-officer; add-portability-clause-at-next-modification Regulatory mappings: - dod_rai_strategy: Governable principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: GOVERN 1.6 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L5-OPS-006: Re-Validation Trigger on Model Version Change Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Lifecycle Stage: ops Operating models: AI-SaaS, AI-PaaS, Program-Embedded Any change to the deployed model version must trigger a re-validation cycle proportional to the scope of the change. The re-validation plan must be documented before the new version is deployed to operational environments. Major version changes require full TEVV; minor updates require at minimum a regression test against the prior TEVV acceptance criteria. Evidence: Binary: a re-validation record exists for every model version change, proportional to change scope, completed before production deployment. Threshold: revalidation_completed_before_deployment == true Breach action: block-deployment; notify-PM; complete-revalidation Regulatory mappings: - dod_rai_strategy: Reliable principle; Implementation Pathway Section TBD - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: MANAGE 3.1 - cc_srg: N/A - owasp_llm: N/A ##### SRF-L5-ACQ-007: Personnel Security Clearance for IL6 Model Infrastructure Access Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Lifecycle Stage: acquisition Operating models: Program-Embedded Personnel with administrative or maintenance access to AI model infrastructure in IL6 classified environments must hold the required personnel security clearance. The component must verify clearance levels before granting access and review access rosters quarterly. Access must be terminated immediately upon clearance lapse. Evidence: Number of IL6 model infrastructure access events by personnel without a verified active clearance. Zero-tolerance. Threshold: uncleared_il6_access_events == TIER_UNCLEARED_IL6_ACCESS Breach action: revoke-access; notify-security-officer; open-security-incident; report-to-AO Regulatory mappings: - dod_rai_strategy: Responsible principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.9.1 - nist_ai_rmf: GOVERN 1.6 - owasp_llm: N/A ##### SRF-L5-ACQ-008: Supply Chain Risk Assessment for AI Components and Foundation Model Providers Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Lifecycle Stage: acquisition Operating models: AI-SaaS, AI-PaaS, Program-Embedded Before selecting a foundation model or AI component provider, the component must assess supply chain risk covering country of origin of training data and model weights, ownership structure, export control status, and any foreign government relationships. Assessments must be updated when ownership or control of the provider changes. Evidence: Binary: a supply chain risk assessment for each model provider has been completed before contract award and updated within the prior annual cycle. Threshold: model_scrm_assessment_complete == true Breach action: block-contract-award; notify-PM; complete-assessment Regulatory mappings: - dod_rai_strategy: Responsible principle; Implementation Pathway Section TBD - dodi_5000_89: N/A - nist_800_171: 3.11.1 - nist_ai_rmf: MAP 5.1 - cc_srg: N/A - owasp_llm: LLM03 ##### SRF-L5-TEVV-009: Model Behavioral Baseline Documented Before Initial Deployment Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model Lifecycle Stage: tevv Operating models: AI-SaaS, AI-PaaS, Agent-Ops, Program-Embedded Before a model is promoted to any operational environment, the model provider or program team must document a behavioral baseline: key performance metrics on representative test sets, accuracy and reliability measurements at the target operating conditions, and known limitations and failure modes. The baseline must be retained in the TEVV package and the BoAIM. Subsequent model versions must be compared against this baseline to detect significant behavioral drift before re-deployment. Evidence: Binary: a model behavioral baseline document is on file in the TEVV package and referenced in the BoAIM before the model is promoted to any operational environment. Known limitations and failure modes are explicitly listed. Threshold: model_behavioral_baseline_documented == true Breach action: Block promotion to operational environment. Model provider or program team must complete baseline documentation and update BoAIM. Regulatory mappings: - dod_rai_strategy: Reliable principle; Traceable principle - cmmc_2_0: N/A - nist_800_171: N/A - nist_ai_rmf: MEASURE 1.1 - cc_srg: N/A - owasp_llm: N/A --- ### Manufacturing Reference: https://aisharedresponsibility.com/manufacturing/ Controls page: https://aisharedresponsibility.com/manufacturing/controls/ Machine-readable: https://aisharedresponsibility.com/data/manufacturing-controls.json Manufacturing control schema for the CoSAI AI Shared Responsibility Framework. Scoped to industrial manufacturers deploying AI in OT/ICS environments, embedding AI in products placed on the EU market, and operating IT-side AI for supply chain, quality, and production management. Controls are parameterized by OT applicability (ot-only, it-only, both) and EU AI Act risk class (high-risk, limited-risk, minimal-risk, N/A). Total controls: 45 #### L1: AI Business & Usage (10 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L1-DES-001: EU AI Act Risk Classification and Registry Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: design Ot Applicability: both Eu Ai Act Risk Class: high-risk Operating models: AI-SaaS, OT-Edge, Product-Embedded, AI-PaaS The manufacturer must classify every AI system in development or operation by EU AI Act risk tier (prohibited, high-risk, limited-risk, minimal-risk). High-risk systems must be registered in the EU AI database before being placed on the market or put into service. The registry must record the system's operating model, risk class, conformity assessment route, accountable manager, and market placement date. Unregistered high-risk systems identified post-deployment must be added within 30 days of discovery. Evidence: Every high-risk AI system is registered in the EU AI database before market placement or entry into service. EU AI Act Article 49 is a binary obligation; partial registration is not permitted and any unregistered in-scope system constitutes non-compliance. Threshold: all_high_risk_systems_registered == true Breach action: identify-unregistered-systems; halt-market-placement; notify-compliance-manager; initiate-registration Regulatory mappings: - eu_ai_act: Article 16 (provider obligations), Article 49 (registration), Annex III (high-risk categories) - eu_machinery_reg: N/A - iec_62443: N/A - iso_42001: Section TBD - nist_ai_rmf: GOVERN 1.1 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L1-DES-002: AI Governance Committee with OT and Safety Representation Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: design Ot Applicability: both Eu Ai Act Risk Class: high-risk Operating models: AI-SaaS, OT-Edge, Product-Embedded, AI-PaaS The manufacturer must establish an AI governance committee that includes at minimum the Plant AI Safety Officer (or functional safety engineer), OT Security lead, product compliance manager, and a senior operations representative. The committee must meet at least quarterly, review the AI system inventory, approve new high-risk AI deployments, and document decisions. Committee composition and meeting records must be retained for audit. Evidence: Governance committee with required membership exists and has met within the last 90 days with documented minutes. Threshold: governance_committee_active == true Breach action: convene-committee; appoint-missing-roles; document-composition Regulatory mappings: - eu_ai_act: Article 17 (quality management system), Article 26 (deployer obligations) - eu_machinery_reg: N/A - iec_62443: ISA-62443-2-1 Section TBD - iso_42001: Section TBD - nist_ai_rmf: GOVERN 1.2 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L1-DES-003: AI Use Case Inventory with Operating Model and Risk Tier Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: design Ot Applicability: both Eu Ai Act Risk Class: N/A Operating models: AI-SaaS, OT-Edge, Product-Embedded, AI-PaaS The manufacturer must maintain a current inventory of all AI use cases, recording for each: system name, operating model (AI-SaaS, OT-Edge, Product-Embedded, AI-PaaS), EU AI Act risk class, OT applicability, accountable owner, deployment status, and date last reviewed. The inventory must be updated within 14 days of any new AI system entering design, validation, or production. Evidence: Maximum number of days since any AI use case record was last reviewed. Threshold: inventory_staleness_days <= TIER_INVENTORY_STALENESS_DAYS Breach action: review-and-update-inventory; notify-governance-committee Regulatory mappings: - eu_ai_act: Article 17 (quality management system, inventory element) - eu_machinery_reg: N/A - iec_62443: ISA-62443-2-1 Section TBD - iso_42001: Section TBD - nist_ai_rmf: GOVERN 1.1 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L1-VAL-004: Conformity Assessment Program Management Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: validation Ot Applicability: both Eu Ai Act Risk Class: high-risk Operating models: Product-Embedded, OT-Edge For each high-risk AI system, the manufacturer must determine the required conformity assessment route (self-assessment per Article 43 or third-party notified body assessment) and track assessment status, scheduled completion date, and responsible manager. Systems requiring notified-body assessment must have an engaged notified body before market placement. A master conformity assessment register must be maintained and reviewed by the governance committee. Evidence: All high-risk systems in the inventory have an assigned conformity assessment route and status in the master register. Threshold: conformity_assessment_register_complete == true Breach action: assign-assessment-route; engage-notified-body-if-required; update-register Regulatory mappings: - eu_ai_act: Article 43 (conformity assessment procedures), Annex VII (third-party assessment) - eu_machinery_reg: Article TBD - iec_62443: N/A - iso_42001: Section TBD - nist_ai_rmf: GOVERN 1.4 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L1-OPS-005: Incident Reporting Plan to Market Surveillance Authority Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: ops Ot Applicability: both Eu Ai Act Risk Class: high-risk Operating models: Product-Embedded, OT-Edge, AI-SaaS The manufacturer must maintain a written incident reporting plan for serious incidents involving high-risk AI systems. The plan must define the trigger conditions, the responsible reporter, the market surveillance authority contact, and the 15-business-day reporting deadline per EU AI Act Article 73. The plan must be tested annually via a tabletop exercise, and test results must be documented. Evidence: Incident reporting plan exists, names the responsible reporter and MSA contact, and has been exercised via tabletop test within the last 12 months. Threshold: incident_plan_tested == true Breach action: draft-or-update-incident-plan; schedule-tabletop-exercise Regulatory mappings: - eu_ai_act: Article 73 (serious incident reporting), Article 72 (post-market monitoring) - eu_machinery_reg: N/A - iec_62443: N/A - iso_42001: Section TBD - nist_ai_rmf: GOVERN 5.1 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L1-DES-006: Third-Party AI System Procurement Policy Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: design Ot Applicability: both Eu Ai Act Risk Class: high-risk Operating models: AI-SaaS, OT-Edge, Product-Embedded, AI-PaaS The manufacturer must maintain a procurement policy for third-party AI systems that requires: EU declaration of conformity for high-risk systems, technical documentation per Article 11, supplier contractual obligations for post-market monitoring data sharing, and a supply chain AI risk assessment for OT-deployed components. The policy must apply to equipment OEMs, AI software vendors, and system integrators supplying AI-enabled systems. Evidence: A written AI procurement policy covering the required elements exists and has been communicated to procurement and legal. Threshold: procurement_policy_active == true Breach action: draft-or-update-procurement-policy; communicate-to-procurement Regulatory mappings: - eu_ai_act: Article 16 (provider obligations on deployers), Article 25 (obligations of distributors and deployers), Article 28 (third-party obligations) - eu_machinery_reg: N/A - iec_62443: ISA-62443-2-1 Section TBD - iso_42001: Section TBD - nist_ai_rmf: GOVERN 6.1 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L1-OPS-007: Post-Market Monitoring Plan per EU AI Act Article 72 Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: ops Ot Applicability: both Eu Ai Act Risk Class: high-risk Operating models: Product-Embedded, OT-Edge, AI-SaaS For each high-risk AI system placed on the market or put into service, the manufacturer must maintain a post-market monitoring plan. The plan must define monitoring frequency, performance metrics to track, data collection mechanism, the responsible team, and the escalation threshold for triggering a corrective action or market withdrawal. Plans must be updated when the system's risk profile changes. Evidence: A post-market monitoring plan exists for each high-risk AI system, names a responsible owner, and specifies collection frequency and escalation thresholds. Threshold: post_market_plan_active == true Breach action: create-post-market-plan; assign-owner; define-escalation-thresholds Regulatory mappings: - eu_ai_act: Article 72 (post-market monitoring system), Article 17 (quality management system) - eu_machinery_reg: N/A - iec_62443: N/A - iso_42001: Section TBD - nist_ai_rmf: MANAGE 4.1 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L1-DES-008: Fundamental Rights Impact Assessment (FRIA) Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: design Ot Applicability: both Eu Ai Act Risk Class: high-risk Operating models: AI-SaaS, Product-Embedded Public-body deployers and private deployers of high-risk AI systems covered by EU AI Act Article 27 must complete a Fundamental Rights Impact Assessment before putting the system into service. The FRIA must address: the rights at risk, the affected populations, the safeguards applied, and the monitoring plan. FRIA records must be retained and provided to market surveillance authorities on request. Evidence: FRIA completed and documented for each applicable high-risk AI system before service entry. Threshold: fria_completed == true Breach action: schedule-fria; assign-assessor; document-findings Regulatory mappings: - eu_ai_act: Article 27 (fundamental rights impact assessment for deployers) - eu_machinery_reg: N/A - iec_62443: N/A - iso_42001: Section TBD - nist_ai_rmf: MAP 5.1 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L1-CHG-009: AI Discontinuation and Decommission Procedure Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: change Ot Applicability: both Eu Ai Act Risk Class: N/A Operating models: AI-SaaS, OT-Edge, Product-Embedded, AI-PaaS The manufacturer must maintain a documented decommission procedure for AI systems covering: shutdown sequence for OT-edge AI (including safe state transitions and safety interlock preservation), data retention and deletion requirements, EU AI database de-registration for high-risk systems, and post-decommission evidence retention per regulatory requirements. The procedure must be tested for OT-edge systems before any production decommission. Evidence: Decommission procedure exists, covers OT safe-state requirements, and has been reviewed within 12 months. Threshold: decommission_procedure_documented == true Breach action: draft-decommission-procedure; review-with-ot-safety-team Regulatory mappings: - eu_ai_act: Article 49 (registration and de-registration) - eu_machinery_reg: N/A - iec_62443: ISA-62443-2-1 Section TBD - iso_42001: Section TBD - nist_ai_rmf: MANAGE 3.1 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L1-CHG-010: OT Change Management Policy for AI Systems Layer: L1 (AI Business & Usage) | Persona: `ai-system-governance` | Component: Governance and Processes Lifecycle Stage: change Ot Applicability: ot-only Eu Ai Act Risk Class: N/A Operating models: OT-Edge The manufacturer must maintain an OT-specific change management policy for AI systems that defines: version freeze windows aligned to production schedules, the trigger conditions for safety re-validation (model update, training data change, configuration change), the rollback procedure and rollback test requirement, and the change record format. The policy must distinguish between IT-side AI changes (standard change management cycle) and OT-edge AI changes (extended validation window, safety re-validation gate). Evidence: An OT AI change management policy exists, distinguishes OT from IT change cycles, defines safety re-validation triggers, and has been communicated to OT engineering and production. Threshold: ot_change_policy_active == true Breach action: draft-ot-change-policy; align-with-plant-safety-officer; communicate-to-ot-engineering Regulatory mappings: - eu_ai_act: Article 17 (quality management system, change control element) - eu_machinery_reg: Annex I item TBD - iec_62443: ISA-62443-2-1 Section TBD - iso_42001: Section TBD - nist_ai_rmf: MANAGE 2.2 - owasp_llm: N/A - mapping_status_note: IEC 61508 clause reference requires verification against IEC 61508-1 through IEC 61508-7. Do not cite specific clause numbers without primary text verification. #### L2: AI Information (8 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L2-DES-001: Sensor and Historian Data Provenance Documentation Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Input Lifecycle Stage: design Ot Applicability: ot-only Eu Ai Act Risk Class: high-risk Operating models: OT-Edge, AI-PaaS For every AI system using plant sensor or historian data as training or inference input, the data provider must document: the data source (sensor ID, historian tag, PLC address), authority-to-use (operational license or site ownership), data quality specification (sampling rate, expected range, known degradation conditions), and chain of custody for data used in model training. Documentation must be retained as part of the EU AI Act technical file for high-risk systems. Evidence: Provenance documentation exists for all training and inference data sources used by OT-edge AI systems. Threshold: data_provenance_documented == true Breach action: document-data-sources; assign-data-provider; include-in-technical-file Regulatory mappings: - eu_ai_act: Article 10 (data and data governance), Annex IV (technical documentation data section) - eu_machinery_reg: N/A - iec_62443: ISA-62443-2-1 Section TBD - iso_42001: Section TBD - nist_ai_rmf: MAP 3.1 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L2-DES-002: Training Data Authority-to-Use for Production Data Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Input Lifecycle Stage: design Ot Applicability: both Eu Ai Act Risk Class: high-risk Operating models: OT-Edge, AI-SaaS, AI-PaaS The data provider must establish and document the contractual or operational basis authorizing use of plant production data for training or fine-tuning AI models. Where production data was collected under operational agreements that do not explicitly authorize AI training use, the data provider must obtain explicit authorization before training commences. The authority-to-use record must reference the applicable agreement and be retained as part of the technical file. Evidence: Authority-to-use documented for all production data sources used in model training before training commences. Threshold: training_atu_documented == true Breach action: obtain-authorization; document-legal-basis; pause-training-until-authorized Regulatory mappings: - eu_ai_act: Article 10 (data governance, legal basis for data use) - eu_machinery_reg: N/A - iec_62443: N/A - iso_42001: Section TBD - nist_ai_rmf: MAP 3.2 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L2-OPS-003: OT/IT Data Boundary Enforcement Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Input Lifecycle Stage: ops Ot Applicability: ot-only Eu Ai Act Risk Class: N/A Operating models: OT-Edge, AI-PaaS No training or fine-tuning data may traverse from OT network zones to cloud or IT networks without traversing an approved conduit documented in the IEC 62443 zone-and-conduit model. Every such traversal must be logged with source zone, destination, data type, volume, and timestamp. The data provider must verify conduit approval before each extraction and retain traversal audit logs for the period specified in the site data retention policy. Evidence: Count of data traversals from OT zones to IT or cloud without an approved conduit record in the current period. Threshold: ot_data_boundary_violations == 0 Breach action: block-unapproved-traversal; alert-ot-security; initiate-conduit-review Regulatory mappings: - eu_ai_act: Article 10 (data governance) - eu_machinery_reg: N/A - iec_62443: ISA-62443-3-3 Section TBD - iso_42001: Section TBD - nist_ai_rmf: MAP 3.5 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L2-OPS-004: Input Data Drift Monitoring Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Input Lifecycle Stage: ops Ot Applicability: both Eu Ai Act Risk Class: high-risk Operating models: OT-Edge, AI-SaaS, AI-PaaS For AI systems with tier-configurable thresholds, the data provider must monitor input data distribution drift using a statistical measure (Population Stability Index or equivalent) on sensor or process variable inputs. The drift metric must be computed at least as frequently as the configured monitoring window and trigger an alert when the threshold is exceeded. Drift alerts must be investigated within the configured response window. Evidence: Population Stability Index (or equivalent) on primary model input features. Lower is better; alert threshold set by operating model and criticality. Threshold: input_psi_score <= TIER_INPUT_PSI_THRESHOLD Breach action: alert-data-provider; investigate-root-cause; consider-retraining-or-fallback Regulatory mappings: - eu_ai_act: Article 72 (post-market monitoring), Article 9 (risk management system) - eu_machinery_reg: N/A - iec_62443: ISA-62443-2-1 Section TBD - iso_42001: Section TBD - nist_ai_rmf: MEASURE 2.5 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L2-VAL-005: Training Data Bias Assessment for Consequential AI Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Input Lifecycle Stage: validation Ot Applicability: it-only Eu Ai Act Risk Class: high-risk Operating models: AI-SaaS, AI-PaaS For AI systems used in personnel, quality, or safety decisions, the data provider must conduct a training data bias assessment before model deployment. The assessment must evaluate representation across relevant subgroups (shift, plant, demographic where applicable), identify and document known gaps, and specify mitigations applied. Assessment results must be retained as part of the technical file for high-risk systems. Evidence: Training data bias assessment completed, documented, and reviewed before model deployment for consequential AI systems. Threshold: bias_assessment_completed == true Breach action: complete-bias-assessment; document-mitigations; update-technical-file Regulatory mappings: - eu_ai_act: Article 10 (data governance, bias examination), Annex IV (bias documentation) - eu_machinery_reg: N/A - iec_62443: N/A - iso_42001: Section TBD - nist_ai_rmf: MEASURE 2.11 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L2-OPS-006: Adversarial Input Detection for OT-Edge AI Layer: L2 (AI Information) | Persona: `ai-platform-provider` | Component: Data and Input Lifecycle Stage: ops Ot Applicability: ot-only Eu Ai Act Risk Class: high-risk Operating models: OT-Edge AI systems deployed in OT/ICS environments must include anomaly detection on process variable inputs to identify adversarial manipulation or sensor spoofing. The detection mechanism must be configured with thresholds appropriate to the process's normal operating envelope and must alert the OT security team and process operator on detection. Detection events must be logged and investigated. Evidence: Percentage of OT-edge AI systems with anomaly detection active on primary process variable inputs. Threshold: adversarial_input_alert_coverage >= TIER_OT_ANOMALY_DETECTION_COVERAGE_PCT Breach action: deploy-anomaly-detection; alert-ot-security; investigate-uncovered-systems Regulatory mappings: - eu_ai_act: Article 9 (risk management, security robustness) - eu_machinery_reg: Annex I item TBD (protection against third-party attacks) - iec_62443: ISA-62443-3-3 Section TBD - iso_42001: Section TBD - nist_ai_rmf: MEASURE 2.6 - owasp_llm: LLM07 (System Prompt Leakage, adapted to sensor input manipulation) - mapping_status_note: IEC 61508 clause reference requires verification against primary text. EU Machinery Regulation Annex I item number TBD. ##### SRF-L2-OPS-007: AI Decision Log Retention per EU AI Act Article 12 Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Input Lifecycle Stage: ops Ot Applicability: both Eu Ai Act Risk Class: high-risk Operating models: OT-Edge, AI-SaaS, Product-Embedded High-risk AI systems must emit automated logs covering the input data used, the output produced, the date and time, and the operator or automated system that acted on the output. Logs must be retained for a minimum of six months per EU AI Act Article 12. Logs must be stored in a tamper-evident format and be retrievable on request by the deployer, operator, or market surveillance authority. Evidence: Minimum retention period in days for AI decision logs. EU AI Act Article 12 minimum: 180 days. Threshold: ai_log_retention_days >= TIER_LOG_RETENTION_DAYS Breach action: extend-log-retention; verify-tamper-evidence; alert-compliance-team Regulatory mappings: - eu_ai_act: Article 12 (record-keeping), Article 26 (deployer logging obligations) - eu_machinery_reg: N/A - iec_62443: ISA-62443-2-1 Section TBD - iso_42001: Section TBD - nist_ai_rmf: MANAGE 4.2 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L2-OPS-008: Production Data Egress Audit for Cloud AI Services Layer: L2 (AI Information) | Persona: `data-provider` | Component: Data and Input Lifecycle Stage: ops Ot Applicability: it-only Eu Ai Act Risk Class: N/A Operating models: AI-SaaS, AI-PaaS For AI systems that send plant production data to cloud AI services, the data provider must verify that no plant data leaves the approved cloud boundary without an audit record. Monthly automated scans must compare actual data egress records against the approved data flow register. Any undocumented egress must be investigated, halted if possible, and reported to the OT security team and data protection officer within 24 hours. Evidence: Count of confirmed plant data egress events not covered by an approved data flow register entry in the current month. Threshold: undocumented_egress_events == 0 Breach action: investigate-egress; halt-if-feasible; notify-dpo-and-ot-security Regulatory mappings: - eu_ai_act: Article 10 (data governance) - eu_machinery_reg: N/A - iec_62443: N/A - iso_42001: Section TBD - nist_ai_rmf: MAP 3.5 - iec_61508: N/A - owasp_llm: N/A #### L3: AI Application (10 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L3-VAL-001: EU AI Act Technical Documentation Completeness Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Use Case Lifecycle Stage: validation Ot Applicability: both Eu Ai Act Risk Class: high-risk Operating models: Product-Embedded, OT-Edge Before placing a high-risk AI system on the market or putting it into service, the application developer must verify that technical documentation per Article 11 and Annex IV is complete. Required elements include: general description of the system, detailed design description, information on training methodology and data, testing and validation information, instructions for use, and relevant standards applied. The documentation must be retained for 10 years after the last unit is placed on the market. Evidence: All required Annex IV elements are present and current in the technical file before market placement. Threshold: technical_documentation_complete == true Breach action: complete-missing-elements; update-technical-file; delay-market-placement Regulatory mappings: - eu_ai_act: Article 11 (technical documentation), Annex IV (technical documentation content) - eu_machinery_reg: Article TBD (technical file requirements) - iec_62443: N/A - iso_42001: Section TBD - nist_ai_rmf: GOVERN 1.3 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L3-VAL-002: Pre-Deployment Testing for Safety-Critical AI Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Use Case Lifecycle Stage: validation Ot Applicability: ot-only Eu Ai Act Risk Class: high-risk Operating models: OT-Edge, Product-Embedded Before deploying an AI system in a safety-critical process context, the application developer must complete a documented test plan and test results covering: normal operating envelope, out-of-range input handling, degraded mode behavior, and failure mode effects. Test results must reference specific test cases and pass/fail outcomes. The test record must be included in the technical file. Evidence: Pre-deployment test plan and results documented for safety-critical AI systems before deployment. Threshold: safety_critical_test_completed == true Breach action: complete-test-plan; execute-tests; resolve-failures-before-deployment Regulatory mappings: - eu_ai_act: Article 9 (risk management, testing), Annex IV (testing and validation documentation) - eu_machinery_reg: Annex I item TBD - iec_62443: ISA-62443-2-1 Section TBD - iso_42001: Section TBD - nist_ai_rmf: MEASURE 2.2 - owasp_llm: N/A - mapping_status_note: IEC 61508 clause reference requires verification against IEC 61508-1 through IEC 61508-7. ##### SRF-L3-OPS-003: Human Oversight Gate for Safety-Critical AI Outputs Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Use Case Lifecycle Stage: ops Ot Applicability: ot-only Eu Ai Act Risk Class: high-risk Operating models: OT-Edge, Product-Embedded AI systems whose outputs could directly affect safety-critical process states must have a human-confirmed gate before the output is acted upon. The gate must require an affirmative operator acknowledgment rather than passive non-intervention. The system must log each gate event, including whether the operator confirmed or overrode the AI output. Zero-tolerance: no autonomous safety decision without a human-confirmed gate unless the system has a validated safety case demonstrating that automatic response is required to prevent imminent harm. Evidence: Count of safety-critical AI output events acted upon without a recorded human-confirmed gate acknowledgment. Threshold: safety_gate_bypass_count == 0 Breach action: alert-plant-safety-officer; investigate-bypass; verify-gate-implementation Regulatory mappings: - eu_ai_act: Article 14 (human oversight), Article 9 (risk management) - eu_machinery_reg: Annex I item TBD - iec_62443: ISA-62443-3-3 Section TBD - iso_42001: Section TBD - nist_ai_rmf: GOVERN 4.1 - owasp_llm: N/A - mapping_status_note: IEC 61508 clause reference requires verification against primary text. ##### SRF-L3-VAL-004: Safety Interlock Integration Verification Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Use Case Lifecycle Stage: validation Ot Applicability: ot-only Eu Ai Act Risk Class: high-risk Operating models: OT-Edge Before deploying an AI system that provides outputs to a safety-instrumented system (SIS) or interlock circuit, the application developer must verify that the AI output cannot override or suppress the SIS response. Verification must be documented via a test record demonstrating that a simulated AI failure mode does not prevent SIS activation. The verification record must be retained in the safety case. Evidence: Safety interlock integration verified by test before deployment; AI output cannot override or suppress SIS activation. Threshold: sis_integration_verified == true Breach action: halt-deployment; remediate-integration; retest-before-resuming Regulatory mappings: - eu_ai_act: Article 9 (risk management), Annex IV (safety testing documentation) - eu_machinery_reg: Annex I item 5 (safety components with self-evolving behaviour) - iec_62443: ISA-62443-3-3 Section TBD - iso_42001: N/A - nist_ai_rmf: MEASURE 2.2 - owasp_llm: N/A - mapping_status_note: IEC 61508 clause reference requires verification against IEC 61508-1 and IEC 61508-4. Do not cite specific clause numbers without verification. ##### SRF-L3-VAL-005: EU AI Act Conformity Assessment Completed Before Market Placement Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Use Case Lifecycle Stage: validation Ot Applicability: both Eu Ai Act Risk Class: high-risk Operating models: Product-Embedded, OT-Edge For each high-risk AI system, the application developer must verify that the applicable conformity assessment procedure (self-assessment per Annex VI or third-party per Annex VII) has been completed and documented before the system is placed on the market or put into service. The conformity assessment record must be retained as part of the technical file and referenced in the EU declaration of conformity. Evidence: Conformity assessment completed and declaration of conformity signed before market placement. Threshold: conformity_assessment_completed == true Breach action: complete-conformity-assessment; sign-declaration; update-technical-file Regulatory mappings: - eu_ai_act: Article 43 (conformity assessment procedures), Annex VI (internal control), Annex VII (third-party assessment), Article 47 (EU declaration of conformity) - eu_machinery_reg: Article TBD - iec_62443: N/A - iso_42001: Section TBD - nist_ai_rmf: GOVERN 1.4 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L3-VAL-006: FAT/SAT Test Coverage for AI-Enabled Machinery Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Use Case Lifecycle Stage: validation Ot Applicability: ot-only Eu Ai Act Risk Class: high-risk Operating models: OT-Edge, Product-Embedded Factory Acceptance Tests (FAT) and Site Acceptance Tests (SAT) for AI-enabled machinery must include test cases covering AI-specific failure modes: model output at edge-of-envelope inputs, graceful degradation on model failure, and correct override behavior. Test coverage for AI-specific cases must be documented separately in the FAT/SAT report and included in the technical file. Test completion is required before commissioning. Evidence: FAT and SAT reports include AI-specific test cases and are completed before commissioning. Threshold: fat_sat_ai_coverage_complete == true Breach action: extend-fat-sat-scope; retest-ai-failure-modes; delay-commissioning Regulatory mappings: - eu_ai_act: Annex IV (testing information), Article 9 (risk management testing) - eu_machinery_reg: Annex I item 5 (safety component validation) - iec_62443: ISA-62443-2-1 Section TBD - iso_42001: Section TBD - nist_ai_rmf: MEASURE 2.2 - owasp_llm: N/A - mapping_status_note: IEC 61508 clause reference requires verification against IEC 61508-1 through IEC 61508-7. ##### SRF-L3-VAL-007: Operator Override Interface Verification Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Use Case Lifecycle Stage: validation Ot Applicability: ot-only Eu Ai Act Risk Class: high-risk Operating models: OT-Edge, Product-Embedded Every AI-assisted decision interface deployed in OT or product contexts must include a tested, functional operator override capability that allows an authorized operator to reject the AI output and proceed with manual control. The override path must not require network connectivity to function. Override functionality must be tested and documented before deployment; test results must be retained in the technical file. Evidence: Operator override interface tested and documented before deployment. Override functions without network connectivity. Threshold: override_interface_tested == true Breach action: implement-override-capability; test-offline-function; document-results Regulatory mappings: - eu_ai_act: Article 14 (human oversight measures, override capability) - eu_machinery_reg: Annex I item TBD - iec_62443: ISA-62443-3-3 Section TBD - iso_42001: N/A - nist_ai_rmf: GOVERN 4.1 - owasp_llm: N/A - mapping_status_note: EU Machinery Regulation Annex I item number TBD pending review of Annex I provisions. ##### SRF-L3-OPS-008: Agentic Task Boundary Enforcement for Autonomous Systems Layer: L3 (AI Application) | Persona: `agentic-platform-provider` | Component: Application and Use Case Lifecycle Stage: ops Ot Applicability: ot-only Eu Ai Act Risk Class: high-risk Operating models: OT-Edge, AI-PaaS Autonomous AI agents deployed in manufacturing (robotic work cells, AI-driven production schedulers, autonomous quality inspection systems) must operate within a defined task boundary specifying: permitted actions, authority limits (what plant states the agent can command), and abort conditions. The boundary must be enforced at runtime, and any attempt to exceed authority must trigger an alert and operator intervention. Boundary definitions must be version-controlled. Evidence: Count of runtime events where an agent attempted to execute an action outside its defined task boundary. Threshold: authority_boundary_violation_count == 0 Breach action: halt-agent; alert-operator; review-boundary-definition Regulatory mappings: - eu_ai_act: Article 14 (human oversight), Article 9 (risk management) - eu_machinery_reg: Annex I item 5 - iec_62443: ISA-62443-3-3 Section TBD - iso_42001: Section TBD - nist_ai_rmf: GOVERN 4.2 - owasp_llm: LLM06 (Excessive Agency) - mapping_status_note: IEC 61508 clause reference requires verification against primary text. ##### SRF-L3-OPS-009: Prompt Injection and Adversarial Input Detection for AI Assistants Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Use Case Lifecycle Stage: ops Ot Applicability: it-only Eu Ai Act Risk Class: limited-risk Operating models: AI-SaaS, AI-PaaS AI assistants and LLM-backed tools deployed in manufacturing IT environments (AI-SaaS, AI-PaaS) must include input validation and prompt injection detection. Detection must cover direct injection in user inputs and indirect injection via retrieved documents or data feeds. Detection events must be logged, and confirmed injections must be investigated within the configured response window. Evidence: Prompt injection detection is active and logging on all AI-SaaS and AI-PaaS deployments. Threshold: prompt_injection_detection_active == true Breach action: enable-injection-detection; review-detection-configuration; alert-security-team Regulatory mappings: - eu_ai_act: Article 52 (transparency obligations for certain AI systems) - eu_machinery_reg: N/A - iec_62443: N/A - iso_42001: Section TBD - nist_ai_rmf: MEASURE 2.6 - iec_61508: N/A - owasp_llm: LLM01 (Prompt Injection) ##### SRF-L3-OPS-010: Explanation Availability for AI-Assisted Quality and Safety Decisions Layer: L3 (AI Application) | Persona: `application-developer` | Component: Application and Use Case Lifecycle Stage: ops Ot Applicability: both Eu Ai Act Risk Class: high-risk Operating models: OT-Edge, AI-SaaS, AI-PaaS AI systems used for quality inspection, defect classification, or safety-relevant process decisions must provide operators with an explanation or rationale on request. The explanation must be available in the operator interface without requiring external connectivity. Explanation format and depth must be calibrated to the operating model: OT-edge systems must provide a concise process-variable-level rationale; IT-side systems may provide more detailed feature attributions. Evidence: Explanation capability is available in the operator interface for AI-assisted quality and safety decisions, accessible without external connectivity. Threshold: explanation_capability_available == true Breach action: implement-explanation-interface; test-offline-access; update-technical-file Regulatory mappings: - eu_ai_act: Article 13 (transparency and provision of information to deployers), Article 14 (human oversight, explainability) - eu_machinery_reg: N/A - iec_62443: N/A - iso_42001: Section TBD - nist_ai_rmf: MEASURE 2.9 - iec_61508: N/A - owasp_llm: N/A #### L4: AI Platform (9 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L4-DES-001: OT Network Zone Segmentation per IEC 62443 Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Lifecycle Stage: design Ot Applicability: ot-only Eu Ai Act Risk Class: N/A Operating models: OT-Edge AI systems deployed within OT/ICS environments must be assigned to the correct security zone in the plant's IEC 62443 zone-and-conduit model. Zone assignment must be documented in the conduit design, and the conduit between the AI system zone and adjacent zones must be documented with its security level, communication protocol, and data flow direction. Zone placement must be reviewed and approved by the OT security team before deployment. Evidence: All OT-deployed AI systems have a documented zone assignment and conduit design reviewed by the OT security team. Threshold: ot_zone_assignment_documented == true Breach action: assign-zone; document-conduit; obtain-ot-security-sign-off Regulatory mappings: - eu_ai_act: Article 9 (risk management, security measures) - eu_machinery_reg: Annex I item TBD (protection against third-party attacks) - iec_62443: ISA-62443-3-2 Section TBD (zone and conduit design), ISA-62443-3-3 Section TBD - iso_42001: N/A - nist_ai_rmf: MAP 1.5 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L4-DES-002: OT-Edge AI Hardware Security Baseline Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Lifecycle Stage: design Ot Applicability: ot-only Eu Ai Act Risk Class: N/A Operating models: OT-Edge Edge hardware hosting AI models within OT zones must comply with a documented hardware security baseline covering: firmware signing, secure boot, removal of unnecessary network services, physical port restrictions, and hardened credentials. The baseline must be applied before deployment and verified via a configuration audit. Deviations from the baseline must be documented with a risk acceptance by the OT security lead. Evidence: Hardware security baseline applied and configuration audit completed for all OT-edge AI hardware before deployment. Threshold: ot_hw_baseline_applied == true Breach action: apply-baseline; audit-configuration; document-deviations-with-risk-acceptance Regulatory mappings: - eu_ai_act: Article 9 (risk management, cybersecurity measures) - eu_machinery_reg: Annex I item TBD - iec_62443: ISA-62443-4-2 Section TBD - iso_42001: N/A - nist_ai_rmf: MAP 1.5 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L4-OPS-003: Air-Gap or Approved-Conduit Enforcement for Safety-Critical OT AI Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Lifecycle Stage: ops Ot Applicability: ot-only Eu Ai Act Risk Class: high-risk Operating models: OT-Edge AI systems deployed in safety-critical OT zones must be isolated from external networks via an air gap or a documented approved conduit. Unapproved network connections from safety-critical OT zones to external networks, the corporate IT network, or the internet are prohibited. Connections detected outside the approved conduit must trigger an immediate alert to the OT security team and plant safety officer. Evidence: Count of network connections from safety-critical OT zones to external networks not traversing an approved conduit. Threshold: unapproved_ot_connection_count == 0 Breach action: block-connection; alert-ot-security-and-plant-safety-officer; investigate-source Regulatory mappings: - eu_ai_act: Article 9 (risk management, security measures for high-risk AI) - eu_machinery_reg: Annex I item TBD (protection against third-party attacks for the operational lifetime) - iec_62443: ISA-62443-3-3 Section TBD - iso_42001: N/A - nist_ai_rmf: MAP 1.5 - owasp_llm: N/A - mapping_status_note: IEC 61508 clause reference requires verification against primary text. EU Machinery Regulation Annex I item number TBD. ##### SRF-L4-CHG-004: Patch and Update Change Management for OT AI Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Lifecycle Stage: change Ot Applicability: ot-only Eu Ai Act Risk Class: N/A Operating models: OT-Edge Patches and software updates for AI systems in OT zones must follow the OT change management policy: each update requires a change record, a safety impact assessment, and version freeze coordination with production scheduling. Updates to AI systems that affect safety functions must include a safety re-validation gate before deployment. Rollback capability must be verified before any OT AI patch is applied. Evidence: Percentage of OT AI patch events with a completed change record, safety impact assessment, and confirmed rollback test. Threshold: ot_patch_change_record_completeness >= TIER_CHANGE_RECORD_COMPLETENESS_PCT Breach action: complete-change-record; conduct-safety-impact-assessment; verify-rollback Regulatory mappings: - eu_ai_act: Article 17 (quality management system, change control) - eu_machinery_reg: Annex I item TBD - iec_62443: ISA-62443-2-1 Section TBD - iso_42001: Section TBD - nist_ai_rmf: MANAGE 2.2 - owasp_llm: N/A - mapping_status_note: IEC 61508 clause reference requires verification against primary text. ##### SRF-L4-OPS-005: OT SIEM and Anomaly Detection Coverage Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Lifecycle Stage: ops Ot Applicability: ot-only Eu Ai Act Risk Class: N/A Operating models: OT-Edge OT zones hosting AI systems must be covered by a security information and event management (SIEM) platform or OT-native anomaly detection tool. Coverage must include the AI host device, the conduit interfaces, and the associated PLCs or SCADA components in the same security zone. Detection coverage must be validated quarterly and reported to the OT security lead. Evidence: Percentage of OT zones hosting AI systems covered by SIEM or OT anomaly detection. Threshold: ot_siem_coverage_pct >= TIER_OT_SIEM_COVERAGE_PCT Breach action: extend-siem-coverage; deploy-sensors; alert-ot-security Regulatory mappings: - eu_ai_act: Article 9 (risk management, monitoring measures) - eu_machinery_reg: N/A - iec_62443: ISA-62443-3-3 Section TBD - iso_42001: N/A - nist_ai_rmf: MEASURE 2.8 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L4-OPS-006: Remote Access Security for OT AI Maintenance Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Lifecycle Stage: ops Ot Applicability: ot-only Eu Ai Act Risk Class: N/A Operating models: OT-Edge Remote access sessions to OT AI systems for maintenance, diagnostics, or updates are prohibited unless authenticated using multi-factor authentication (MFA) and authorized via a formal change record or maintenance request. Zero unauthenticated remote sessions are permitted. All remote sessions must be logged with the operator identity, session duration, and actions performed. Session logs must be retained and reviewed monthly. Evidence: Count of remote access sessions to OT AI systems without MFA authentication. Threshold: unauthenticated_remote_session_count == 0 Breach action: terminate-session; alert-ot-security; review-access-controls Regulatory mappings: - eu_ai_act: Article 9 (risk management, access control measures) - eu_machinery_reg: Annex I item TBD - iec_62443: ISA-62443-3-3 Section TBD - iso_42001: N/A - nist_ai_rmf: MAP 1.5 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L4-OPS-007: Encrypted Communication for AI Data in Transit Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Lifecycle Stage: ops Ot Applicability: both Eu Ai Act Risk Class: N/A Operating models: AI-SaaS, OT-Edge, AI-PaaS AI data in transit between components must be encrypted using approved cryptographic protocols. For OT-edge deployments where latency constraints preclude standard TLS, the platform provider must document the alternative encryption or integrity protection mechanism and the associated risk acceptance approved by the OT security lead. IT-side AI communications must use TLS 1.2 or later. Evidence: Count of confirmed AI data flows in transit without approved encryption or documented risk-accepted alternative. Threshold: unencrypted_ai_data_in_transit_count <= TIER_UNENCRYPTED_FLOW_TOLERANCE Breach action: enable-encryption; document-alternative-if-ot-constrained; obtain-risk-acceptance Regulatory mappings: - eu_ai_act: Article 9 (risk management, security measures) - eu_machinery_reg: Annex I item TBD - iec_62443: ISA-62443-3-3 Section TBD - iso_42001: N/A - nist_ai_rmf: MAP 1.5 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L4-DES-008: AI Software Bill of Materials (SBOM/AIBOM) for OT AI Components Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Lifecycle Stage: design Ot Applicability: ot-only Eu Ai Act Risk Class: N/A Operating models: OT-Edge, Product-Embedded For AI systems deployed in OT zones, the platform provider must maintain an AI Bill of Materials (AIBOM) covering all software components, ML frameworks, model artifacts, and third-party libraries. The AIBOM must be updated with each change to the AI system and used as the basis for vulnerability management. Component suppliers must be identified for every third-party entry. The AIBOM must be retained as part of the technical file. Evidence: An AIBOM exists for every OT-deployed AI system and has been updated within 30 days of the last system change. Threshold: aibom_current == true Breach action: create-aibom; update-after-changes; include-in-technical-file Regulatory mappings: - eu_ai_act: Annex IV (technical documentation, component inventory element) - eu_machinery_reg: N/A - iec_62443: ISA-62443-2-1 Section TBD - iso_42001: Section TBD - nist_ai_rmf: MAP 5.2 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L4-OPS-009: Availability SLA for AI in Critical Production Processes Layer: L4 (AI Platform) | Persona: `ai-platform-provider` | Component: Platform and Infrastructure Lifecycle Stage: ops Ot Applicability: both Eu Ai Act Risk Class: N/A Operating models: OT-Edge, AI-SaaS For AI systems that are in the critical path of production (AI-driven quality gates, real-time process control, predictive maintenance with mandatory action) the platform provider must define and monitor an availability SLA. The SLA must specify the target availability percentage, the measurement window, and the degraded-mode behavior when availability falls below threshold. SLA breaches must trigger a defined escalation path. Evidence: Measured availability of critical-path AI systems as a percentage of total required uptime in the measurement window. Threshold: ai_availability_pct >= TIER_AI_AVAILABILITY_PCT Breach action: escalate-to-platform-provider; activate-degraded-mode-procedure; investigate-root-cause Regulatory mappings: - eu_ai_act: Article 9 (risk management, continuity measures) - eu_machinery_reg: N/A - iec_62443: N/A - iso_42001: Section TBD - nist_ai_rmf: MANAGE 4.1 - iec_61508: N/A - owasp_llm: N/A #### L5: AI Model Provider (8 controls) Framework layer reference: https://aisharedresponsibility.com/framework/ ##### SRF-L5-VAL-001: EU AI Act Technical File Completeness - Model Supplier Obligations Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model and Supplier Lifecycle Stage: validation Ot Applicability: both Eu Ai Act Risk Class: high-risk Operating models: Product-Embedded, OT-Edge The model provider (AI model vendor or equipment OEM supplying an AI-enabled system) must provide a complete technical file including: the EU declaration of conformity, technical documentation per Annex IV, information on training methodology and data, and the conformity assessment record. For high-risk systems, the declaration of conformity must be signed by an authorized representative. Deploying manufacturers must verify completeness of supplier documentation before market placement. Evidence: Model supplier technical file includes declaration of conformity, technical documentation, and conformity assessment record before deployment. Threshold: supplier_technical_file_complete == true Breach action: request-missing-documentation; delay-deployment; escalate-to-procurement Regulatory mappings: - eu_ai_act: Article 11 (technical documentation), Article 47 (EU declaration of conformity), Annex IV - eu_machinery_reg: Article TBD (technical file requirements) - iec_62443: N/A - iso_42001: Section TBD - nist_ai_rmf: GOVERN 1.3 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L5-OPS-002: Model Drift and Performance Degradation Monitoring Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model and Supplier Lifecycle Stage: ops Ot Applicability: both Eu Ai Act Risk Class: high-risk Operating models: OT-Edge, AI-SaaS, AI-PaaS The model provider must supply or specify a monitoring mechanism for model drift and performance degradation. For OT-edge AI, the monitoring interval must be calibrated to the process criticality and the acceptable lag between degradation onset and detection. Performance metrics must include at minimum the primary task metric (e.g., classification accuracy for quality inspection, MAE for predictive maintenance) and a statistical drift indicator. Degradation events must trigger an alert and investigation. Evidence: Model primary task metric relative to the validated baseline performance. Drift threshold set by operating model and process criticality. Threshold: model_performance_vs_baseline >= TIER_MODEL_PERFORMANCE_FLOOR Breach action: alert-model-provider; investigate-drift-cause; consider-retraining-or-fallback Regulatory mappings: - eu_ai_act: Article 72 (post-market monitoring), Article 9 (risk management, ongoing monitoring) - eu_machinery_reg: N/A - iec_62443: N/A - iso_42001: Section TBD - nist_ai_rmf: MEASURE 2.5 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L5-CHG-003: Model Version Change Management Trigger Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model and Supplier Lifecycle Stage: change Ot Applicability: both Eu Ai Act Risk Class: high-risk Operating models: OT-Edge, AI-SaaS, Product-Embedded, AI-PaaS Every model version change must generate a change record before deployment. For high-risk AI systems, model version changes must trigger a re-validation assessment to determine whether the change requires a new conformity assessment under EU AI Act Article 43. OT-edge deployments require an additional safety impact assessment and version freeze coordination. The model provider must document the change scope and re-validation determination in the change record. Evidence: Percentage of model version change events with a completed change record and re-validation determination before deployment. Threshold: model_change_record_completeness == true Breach action: create-change-record; conduct-revalidation-assessment; delay-deployment Regulatory mappings: - eu_ai_act: Article 43 (conformity assessment re-evaluation trigger), Article 17 (quality management, change control) - eu_machinery_reg: N/A - iec_62443: ISA-62443-2-1 Section TBD - iso_42001: Section TBD - nist_ai_rmf: MANAGE 2.2 - owasp_llm: N/A - mapping_status_note: IEC 61508 clause reference requires verification against primary text. ##### SRF-L5-OPS-004: Vulnerability Disclosure SLA for AI Model Supplier Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model and Supplier Lifecycle Stage: ops Ot Applicability: both Eu Ai Act Risk Class: N/A Operating models: OT-Edge, AI-SaaS, Product-Embedded, AI-PaaS The model provider must publish and honor a vulnerability disclosure SLA specifying: the channel for receiving vulnerability reports, the acknowledgment timeline, the assessment and severity classification timeline, and the patch availability timeline by severity level. For OT-edge AI, the SLA must account for the OT change management cycle; critical vulnerabilities must include a compensating control recommendation when immediate patching is infeasible. Evidence: Maximum days from confirmed critical vulnerability to patch availability for AI model components. Threshold: vuln_sla_days_critical <= TIER_VULN_SLA_DAYS_CRITICAL Breach action: escalate-to-vendor; implement-compensating-control; notify-ot-security Regulatory mappings: - eu_ai_act: Article 9 (risk management, security vulnerability management) - eu_machinery_reg: N/A - iec_62443: ISA-62443-2-1 Section TBD - iso_42001: Section TBD - nist_ai_rmf: MANAGE 3.1 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L5-DES-005: BoAIM and Model Artifact Signing Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model and Supplier Lifecycle Stage: design Ot Applicability: both Eu Ai Act Risk Class: N/A Operating models: OT-Edge, Product-Embedded The model provider must supply a Bill of AI Materials (BoAIM) for each AI model artifact, listing model architecture, training framework versions, base model or pre-trained weights sources, and fine-tuning dataset provenance. Model artifacts must be signed with a verifiable digital signature before distribution. The deploying manufacturer must verify artifact signatures before deployment to OT or product environments. Evidence: Model artifact signature verified before deployment. BoAIM present and current for every artifact deployed to OT or product environments. Threshold: model_artifact_signed == true Breach action: obtain-boaim; verify-signature; halt-deployment-if-verification-fails Regulatory mappings: - eu_ai_act: Annex IV (technical documentation, model description) - eu_machinery_reg: N/A - iec_62443: ISA-62443-2-1 Section TBD - iso_42001: Section TBD - nist_ai_rmf: MAP 5.2 - iec_61508: N/A - owasp_llm: LLM03 (Supply Chain Vulnerabilities) ##### SRF-L5-VAL-006: Functional Safety Validation for AI in Safety-Instrumented Systems Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model and Supplier Lifecycle Stage: validation Ot Applicability: ot-only Eu Ai Act Risk Class: high-risk Operating models: OT-Edge Where an AI system is integrated into or provides inputs to a safety-instrumented system (SIS), the model provider and deploying manufacturer must complete a safety validation appropriate to the Safety Integrity Level (SIL) of the SIS. Safety validation must follow IEC 61508 or a sector-equivalent standard. Safety case documents and SIL assessment records are classified documents: note document type and custodian role (functional safety engineer, plant safety officer); do not publish document URLs. Validation must be completed before commissioning. Evidence: SIL-appropriate functional safety validation completed and safety case documented before commissioning. Document custodian: functional safety engineer. Threshold: sil_validation_completed == true Breach action: engage-functional-safety-engineer; complete-sil-assessment; document-safety-case Regulatory mappings: - eu_ai_act: Article 9 (risk management, safety validation), Annex IV (safety testing documentation) - eu_machinery_reg: Annex I item 5 (safety components with self-evolving behaviour) - iec_62443: ISA-62443-3-3 Section TBD - iso_42001: N/A - nist_ai_rmf: MEASURE 2.2 - owasp_llm: N/A - mapping_status_note: All IEC 61508 clause references marked TBD. Citation must reference IEC 61508 part numbers (IEC 61508-1 through IEC 61508-7) only, not specific clause numbers, pending verification against primary text. ##### SRF-L5-DES-007: Model Portability and Lock-In Avoidance Documentation Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model and Supplier Lifecycle Stage: design Ot Applicability: both Eu Ai Act Risk Class: N/A Operating models: OT-Edge, AI-SaaS, AI-PaaS The model provider must document the model export capability, the supported export formats, and the migration path to an alternative platform. For OT-edge AI, the export documentation must specify whether the model can be re-deployed on alternative OT-compatible hardware without retraining. Model portability documentation must be provided before contract signature and updated when the provider's platform capabilities change. Evidence: Model portability documentation provided before contract signature, covering export formats and OT re-deployment capability. Threshold: portability_documentation_provided == true Breach action: request-portability-documentation; evaluate-lock-in-risk; escalate-to-procurement Regulatory mappings: - eu_ai_act: N/A - eu_machinery_reg: N/A - iec_62443: N/A - iso_42001: Section TBD - nist_ai_rmf: GOVERN 6.2 - iec_61508: N/A - owasp_llm: N/A ##### SRF-L5-DES-008: Model Supplier Due Diligence and Supply Chain Risk Assessment Layer: L5 (AI Model Provider) | Persona: `model-provider` | Component: Model and Supplier Lifecycle Stage: design Ot Applicability: both Eu Ai Act Risk Class: N/A Operating models: OT-Edge, Product-Embedded Before contracting a model supplier for an OT-edge or product-embedded AI system, the model provider evaluation must include: financial stability and support horizon, security disclosure history, jurisdictional risk (data residency, export control), EU AI Act compliance status for high-risk models, and OT environment compatibility. The due diligence record must be reviewed by procurement and the OT security lead and retained with the supplier record. Evidence: Supplier due diligence record completed, reviewed by procurement and OT security lead, and retained before contract signature. Threshold: supplier_due_diligence_completed == true Breach action: complete-due-diligence; obtain-ot-security-review; delay-contract-signature Regulatory mappings: - eu_ai_act: Article 28 (third-party provider obligations), Article 16 (provider due diligence) - eu_machinery_reg: N/A - iec_62443: ISA-62443-2-1 Section TBD - iso_42001: Section TBD - nist_ai_rmf: GOVERN 6.1 - iec_61508: N/A - owasp_llm: LLM03 (Supply Chain Vulnerabilities) --- ## Part 3: Regulations and Standards Reference: https://aisharedresponsibility.com/regulations/ AI regulations and standards mapped to SRF layers. For layer definitions see Part 1.1. - NIST AI Risk Management Framework url: https://www.nist.gov/itl/ai-risk-management-framework - EU Artificial Intelligence Act url: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689 - ISO/IEC 42001: AI Management Systems url: https://www.iso.org/standard/81230.html - ISO/IEC 22989: AI Concepts and Terminology url: https://www.iso.org/standard/74296.html - NIST AI 100-1: AI Risk Management url: https://doi.org/10.6028/NIST.AI.100-1 - COSAiS: SP 800-53 Control Overlays for Securing AI Systems url: https://csrc.nist.gov/projects/cosais - NIST Cybersecurity Framework 2.0 url: https://www.nist.gov/cyberframework - OWASP LLM Top 10 url: https://owasp.org/www-project-top-10-for-large-language-model-applications/ - CSA AI Controls Matrix url: https://cloudsecurityalliance.org/artifacts/ai-controls-matrix - MITRE ATLAS url: https://atlas.mitre.org/ - SR 26-2: Revised Guidance on Model Risk Management url: https://www.federalreserve.gov/supervisionreg/srletters/SR2602.pdf - FDA AI/ML-Based Software as a Medical Device url: https://www.fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-and-machine-learning-aiml-enabled-medical-devices - General Data Protection Regulation url: https://gdpr-info.eu/ --- ## Part 4: Tools and Resources Reference: https://aisharedresponsibility.com/tools/ Interactive tools for applying the SRF to real deployments. ### Regulation Discovery Wizard URL: https://aisharedresponsibility.com/tools/regulation-discovery/ 4-step wizard identifying applicable regulations by jurisdiction, risk tier, deployment context, and industry vertical. Outputs a layer-mapped regulatory profile with PDF export. References L1-L5 accountability assignments. ### Controls Assessment (AICM) URL: https://aisharedresponsibility.com/tools/controls-assessment/ Assess control implementation status against the SRF across all five layers (L1 AI Business & Usage through L5 AI Model Provider). ### Layer Matrix URL: https://aisharedresponsibility.com/tools/layer-matrix/ Visual matrix of accountability assignments across all five SRF layers and four operating models (AI-SaaS, AI-PaaS, Agent-PaaS, IaaS). ### Policy Pyramid URL: https://aisharedresponsibility.com/tools/policy-pyramid/ Governance policy hierarchy showing how L1 (AI Business & Usage) policy cascades down through L2-L5. ### Security Controls URL: https://aisharedresponsibility.com/tools/security-controls/ Security-specific control reference with SRF layer and persona mapping. ### SRF Stress Test URL: https://aisharedresponsibility.com/tools/srf-stress/ Accepts a plain-language AI deployment scenario and stress-tests it against SRF accountability rules. Identifies unassigned accountability gaps. ### System Instructions URL: https://aisharedresponsibility.com/tools/prompts/ Copy-ready prompts for grounding AI assistants in the SRF. Core instruction enforcing one accountable party per activity. Role variants: executive, auditor, developer, legal/procurement. Sector context parameters for all six verticals. --- ## Document metadata - Site: https://aisharedresponsibility.com/ - Framework: CoSAI AI Shared Responsibility Framework v1.0 - Source organization: OASIS Open / Coalition for Secure AI (CoSAI) Workstream 2 - Note: Industry vertical schemas are independently proposed extensions to CoSAI SRF v1.0 and are not part of the official CoSAI release. - Link index: https://aisharedresponsibility.com/llms.txt - Data index: https://aisharedresponsibility.com/data/index.json - Sitemap: https://aisharedresponsibility.com/sitemap.xml - Generated: 2026-06-13