Gaps Identified

Agencies must design, develop, acquire, and use AI in a manner consistent with the Constitution and all applicable laws and policies, including those addressing privacy, civil rights, and civil liberties. Documentation must demonstrate how AI applications are evaluated against these legal and values-based requirements.

The document references EO 13960 in Section 1 and includes General Counsel and Chief Privacy Officer on the AI Governance Board, plus commits to fairness evaluation in §5.3 ('Acme is committed to the fair and equitable use of AI'). However, it does not explicitly require that AI design, development, acquisition, and use be evaluated against the Constitution, applicable laws, and civil rights/civil liberties/privacy standards, nor does the Pre-Deployment Review template (§5.1) enumerate a legal/constitutional/civil liberties compliance check as a required component. The disparate impact commitment in §5.3 is aspirational ('will evaluate...take corrective action where appropriate') without defined methodology, thresholds, or documentation requirements.

Amend the AI Impact Assessment template and Pre-Deployment Review checklist to require explicit, documented evaluation against constitutional protections, applicable federal law, privacy law, and civil rights/civil liberties standards, with sign-off by General Counsel and the Chief Privacy Officer. Define the disparate impact testing methodology, metrics, and retention requirements in §5.3 rather than relying on a commitment statement.

Agencies must only pursue AI use cases where the benefits significantly outweigh the risks and where risks can be assessed and managed. A documented risk-benefit analysis must exist for each AI application prior to design, development, acquisition, or deployment.

Section 5.1 requires a Pre-Deployment Review including an AI Impact Assessment that identifies 'intended purpose, expected benefits, populations affected, data quality, and anticipated failure modes,' plus a 'documented risk acceptance decision signed by the system owner and countersigned by the CAIO.' However, the policy does not explicitly require a comparative benefit-risk analysis demonstrating that benefits 'significantly outweigh' risks, nor does it require this analysis prior to design, development, or acquisition — the review is gated only at pre-production deployment.

Amend Section 5.1 to explicitly require a documented benefit-risk comparison concluding that benefits significantly outweigh residual risks, and extend the assessment trigger to the design, development, and acquisition phases (not only pre-deployment), with a decision criterion for rejecting use cases where risks cannot be adequately assessed or managed.

Agencies must ensure that AI applications are used only for the use cases they were trained for, and that such use is accurate, reliable, and effective. Evidence of validation testing aligned to intended use cases must be maintained.

The document addresses validation testing through §5.1, which requires 'a testing report conducted under conditions that mirror the intended production environment, using a validation dataset that is independent of the training dataset' and an AI Impact Assessment identifying 'intended purpose.' Ongoing monitoring in §5.2 also captures 'drift from expected behavior.' However, the policy does not explicitly require that AI systems be used only for the use cases they were trained for, nor does it specifically require evidence that validation testing is aligned to the intended use case. Accuracy, reliability, and effectiveness are not named as explicit validation criteria.

Add explicit language restricting AI use to trained-for use cases, define accuracy/reliability/effectiveness as required validation criteria with measurable thresholds tied to intended use, and require retention of validation evidence demonstrating alignment with the documented intended use case.

Agencies must ensure the safety, security, and resiliency of AI applications, including resilience against systematic vulnerabilities, adversarial manipulation, and malicious exploitation. Security controls and adversarial testing procedures must be documented.

The document addresses security incidents generically in Section 9 ('security compromises affecting AI systems') and references testing in Section 5.1 (pre-deployment testing report) and monitoring in Section 5.2. However, there is no explicit discussion of adversarial resilience, adversarial testing procedures (e.g., red-teaming, adversarial robustness evaluation), protection against malicious exploitation, or documented security controls specific to AI systems such as model poisoning, evasion attacks, or prompt injection defenses.

Add explicit provisions requiring documented adversarial testing procedures (e.g., red-team exercises, robustness testing against adversarial inputs), security controls specific to AI threat vectors (model theft, data poisoning, evasion, prompt injection), and resilience validation as part of pre-deployment and ongoing assessment for AI systems.

Agencies must clearly define, document, and assign human roles and responsibilities across the AI lifecycle (design, development, acquisition, use). Relevant inputs, outputs, and decisions of AI applications must be well documented and traceable to the extent practicable.

The document defines some roles clearly (CAIO in §3.1, Governance Board in §3.2, system owners and technical custodians referenced in §4) and establishes documentation/traceability for inventory records, Pre-Deployment Reviews (retained 'life of system plus seven years' per §5.1), and monitoring outputs. However, §3.3 explicitly states that Component AI Lead role definitions are 'under development and are expected to be finalized in the next policy revision,' leaving a gap in lifecycle role assignments at the business-unit level. The policy also does not explicitly require documentation and traceability of AI inputs, outputs, and decisions as a standalone control — it addresses monitoring and risk records but not traceability of individual AI decisions/outputs to the extent practicable.

Finalize Component AI Lead role definitions with documented responsibilities across design, development, acquisition, and use phases, and add an explicit control requiring that inputs, outputs, and decisions of AI applications be logged and traceable (e.g., decision logging, model version tracking, audit trails) to the extent practicable.

Agencies must regularly test AI applications against the Principles and maintain mechanisms to supersede, disengage, or deactivate AI applications demonstrating performance or outcomes inconsistent with intended use. Monitoring cadence and decommissioning procedures must be documented.

Section 5.2 establishes monitoring cadence by classification (continuous for High-Impact, quarterly for Limited-Impact, annual for Administrative) and states that detected degradation 'triggers a documented response, up to and including temporary suspension of the system,' which partially addresses the disengage/deactivate mechanism. However, the document does not describe testing AI applications against the EO 13960 Principles specifically, nor does it document formal decommissioning or deactivation procedures (criteria, authority, sequencing, data handling, notification) required by §3(g).

Add explicit procedures for testing AI systems against the nine EO 13960 Principles on a defined cadence, and document formal decommissioning/deactivation procedures including trigger criteria, decision authority, technical disengagement steps, stakeholder notification, and data/record disposition.

Agencies must be transparent in disclosing relevant information about their use of AI to Congress, the public, and other appropriate stakeholders, consistent with applicable law and protection of sensitive information. Disclosure mechanisms and boundaries must be defined.

The document addresses public transparency through Section 4 (redacted public AI Use Case Inventory published quarterly) and Section 8 (annual AI Transparency Statement, point-of-interaction notices). However, it does not define disclosure mechanisms or boundaries for Congress or 'other appropriate stakeholders,' nor does it articulate the criteria distinguishing disclosable information from protected sensitive/classified information beyond a general reference to 'protection of sensitive and classified information.'

Add explicit disclosure procedures and channels for Congressional reporting and interagency/stakeholder inquiries, and define the specific boundaries (e.g., classification tiers, FOIA exemptions, CUI categories) that govern what is withheld versus disclosed, including who makes those determinations.

Agencies must implement and enforce appropriate safeguards for AI use and must monitor, audit, and document compliance with those safeguards. Agencies must also provide appropriate training to all personnel responsible for the design, development, acquisition, and use of AI.

The document addresses safeguards (Section 5 Risk Management, Section 6 Human Oversight), monitoring (Section 5.2 with defined frequencies by classification), and training (Section 10, requiring initial and recurring training for personnel involved in design, development, acquisition, and operational oversight, with LMS tracking). However, while monitoring and documentation are addressed, the policy does not specify an internal audit function or independent compliance audit process for the safeguards themselves. Section 9 covers incident response and Section 5 covers pre-deployment review, but there is no explicit commitment to periodic auditing of compliance with the safeguards as required by §3(i).

Add an explicit internal audit or compliance audit provision specifying frequency, scope, independence, and reporting lines for auditing adherence to AI safeguards (distinct from operational monitoring and incident response), and define minimum training curriculum content and baseline competency requirements for personnel in scope.

Agencies must use voluntary consensus standards developed with industry participation, where available, unless inconsistent with applicable law or impracticable. Documentation should identify which standards are applied to AI development, acquisition, and use.

The document references alignment with the NIST AI Risk Management Framework (AI RMF 1.0) in Section 1 ('It aligns with guidance under... the NIST AI Risk Management Framework (AI RMF 1.0)'), which is a relevant voluntary consensus-style standard. However, the policy does not identify any other voluntary consensus standards (e.g., ISO/IEC 42001, ISO/IEC 23894, IEEE 7000-series) applied to AI development, acquisition, or use, nor does it describe a process for identifying and adopting such standards or documenting when they are used or deemed impracticable.

Amend the policy to explicitly enumerate the voluntary consensus standards applied across AI development, acquisition, and use phases, establish a process for evaluating and adopting new standards with industry participation, and require documentation of rationale when such standards are not used (e.g., impracticability or inconsistency with law).

Each agency must prepare an inventory of its non-classified and non-sensitive AI use cases, including current and planned uses, within 180 days of CIO Council guidance and annually thereafter. The inventory must follow the criteria, format, and mechanisms specified by the CIO Council.

Section 4 establishes an AI Use Case Inventory maintained by the CAIO's office with detailed per-system fields, and commits to quarterly publication of a redacted public version. However, the document does not explicitly commit to annual submission following CIO Council-specified criteria, format, or mechanisms, nor does it reference the 180-day initial inventory timeline or alignment with the federal CIO Council inventory format required by EO 13960 §5(b).

Add explicit language committing to prepare and submit the inventory in the criteria, format, and mechanism specified by the CIO Council (or applicable successor OMB guidance), and specify the annual submission cadence and responsible party for federal reporting.

Within 120 days of completing their inventories, agencies must make their AI use case inventories available to the public, to the extent practicable and in accordance with laws protecting privacy, law enforcement sensitive, national security, and other protected information.

Section 4 states that 'A redacted public version of the AI Use Case Inventory is published to acme-federal.com/transparency on a quarterly basis, consistent with federal transparency expectations and in accordance with the protection of sensitive and classified information.' This addresses public release and protection of sensitive information, but the document does not commit to the 120-day timeline following inventory completion specified in EO 13960 §5(e), nor does it explicitly reference the protected categories (privacy, law enforcement sensitive, national security) individually.

Add explicit commitment to publish the inventory within 120 days of completion as required by EO 13960 §5(e), and enumerate the specific categories of protected information (privacy, law enforcement sensitive, national security) that may be withheld or redacted.

Agencies are expected to participate in interagency bodies advancing implementation of the Principles and consistent use of AI. Participation in the interagency bodies and forums recommended by the CIO Council must be documented as appropriate to the agency's authorities and missions.

Section 3.1 states the CAIO is authorized to 'Represent Acme in federal interagency AI coordination activities as required,' which acknowledges participation in interagency bodies. However, the document does not identify specific CIO Council-recommended forums, commit to documenting such participation, or establish a process for tracking and reporting on interagency engagement.

Add explicit language identifying the interagency bodies Acme participates in (or commits to participating in), and establish a documented record-keeping process for tracking attendance, contributions, and outcomes of such participation as recommended by the CIO Council.

Within 30 days of the order, each agency must specify the responsible official(s) who will coordinate implementation of the Principles with the Agency Data Governance Body and other relevant officials, and who will collaborate with interagency coordination bodies. These designations must be formally documented.

The document designates Samira Delacroix as Chief AI Officer effective February 1, 2026, with a signed charter held by the Office of the CTO, and grants authority to 'Represent Acme in federal interagency AI coordination activities as required.' However, EO 13960 §8(c) specifically requires designation of official(s) who coordinate implementation with the Agency Data Governance Body — a concept applicable to federal agencies, not contractors. The document does not explicitly address coordination with an Agency Data Governance Body, nor does it document the 30-day timeline requirement, and Acme is a federal contractor rather than an agency subject to §8(c).

Clarify whether EO 13960 §8(c) applies to Acme as a contractor versus an agency; if applicable by contract flow-down, explicitly document the responsible official's coordination duties with client agency Data Governance Bodies and interagency coordination bodies, and record formal designation dates to evidence timeliness.

Agency governance must apply the Principles to both existing and new AI uses, standalone and embedded AI, AI developed by third parties on behalf of the agency, relevant training data inputs and decision-support outputs, and procurement of AI applications. Procurement and vendor management controls must reflect these obligations.

The document's scope statement in Section 1 covers 'development, procurement, deployment, and ongoing use' and applies to 'AI systems provided by external vendors but deployed in Acme environments,' and the inventory in Section 4 captures vendor and contract data. However, Section 7 (Procurement) is a single paragraph stating only that procurement 'must be coordinated with the Director of Procurement and reviewed by the CAIO's office' — it contains no contractual flow-down clauses, no vendor due diligence or assurance requirements, no handling of embedded AI, and no explicit treatment of third-party training data inputs or decision-support outputs as required by §9(c).

Expand Section 7 to specify procurement controls implementing the EO Principles for vendor-supplied AI: required contract clauses (testing, documentation, monitoring rights, incident notification), pre-award vendor risk assessments, explicit coverage of embedded/component AI and third-party training data and decision-support outputs, and ongoing vendor performance reviews tied to the governance framework.

Agencies must design, develop, acquire, and use AI in a manner consistent with the Constitution and all applicable laws and policies, including those addressing privacy, civil rights, and civil liberties. The governance framework must explicitly embed these legal and rights-based constraints into AI lifecycle processes.

The document references alignment with OMB memoranda, EO 13960, and the NIST AI RMF, and includes isolated rights-adjacent provisions (Section 5.3 on disparate impact, Section 6 on human oversight, Section 8 involving the Chief Privacy Officer, and General Counsel participation on the Governance Board). However, it does not explicitly commit to designing, developing, acquiring, and using AI consistent with the Constitution and applicable laws and policies addressing privacy, civil rights, and civil liberties, nor does it embed these legal and rights-based constraints as mandatory criteria within the AI lifecycle processes (e.g., the Pre-Deployment Review in Section 5.1 lists no civil rights, civil liberties, or constitutional compliance checkpoint). Section 5.3's commitment to fairness is aspirational ('is committed to') without specific controls, thresholds, or enforcement mechanisms.

Add an explicit policy statement requiring AI design, development, acquisition, and use to comply with the Constitution and laws governing privacy, civil rights, and civil liberties, and embed mandatory civil rights/civil liberties/privacy review checkpoints (with defined criteria and sign-off) into the Pre-Deployment Review, procurement, and ongoing monitoring processes.

Agencies must pursue AI only where the benefits significantly outweigh the risks and where risks can be assessed and managed. Documented processes for identifying, assessing, and managing AI-related risks must be in place prior to deployment.

The document establishes a Pre-Deployment Review in §5.1 that requires an AI Impact Assessment identifying 'intended purpose, expected benefits, populations affected, data quality, and anticipated failure modes,' along with independent review and a documented risk acceptance decision signed by the system owner and countersigned by the CAIO. However, the policy does not articulate the specific standard required by §3(b) — that AI be pursued only where benefits 'significantly outweigh' the risks, nor does it require a comparative risk-benefit determination or a finding that risks are assessable and manageable as a precondition to deployment. The Impact Assessment captures benefits and risks separately but does not mandate a documented weighing of one against the other.

Amend §5.1 to require an explicit, documented risk-benefit determination concluding that benefits significantly outweigh risks and that residual risks are assessable and manageable, and make that finding a mandatory precondition of the CAIO's risk acceptance signature prior to deployment.

Agencies must ensure AI applications are accurate, reliable, and effective, and are used only consistent with the use cases for which they were trained. Controls must verify operational alignment between training context and deployment context.

The document addresses accuracy and reliability through Pre-Deployment Review requirements, including 'a testing report conducted under conditions that mirror the intended production environment, using a validation dataset that is independent of the training dataset' (§5.1) and ongoing monitoring for 'drift from expected behavior' (§5.2). The CAIO also has authority to 'Require the immediate suspension of any AI system found to be operating outside its intended scope' (§3.1). However, the policy does not explicitly establish controls verifying operational alignment between training context and deployment context — there is no requirement to document the trained use cases, compare them to deployment context, or restrict use to validated use cases.

Add explicit controls requiring documentation of the use cases, data distributions, and operational contexts for which each AI system was trained, and require a pre-deployment and periodic verification that deployment context matches training context, with deviations triggering re-validation or suspension.

Agencies must ensure the safety, security, and resilience of AI applications, including resilience to systematic vulnerabilities, adversarial manipulation, and malicious exploitation. Technical and procedural safeguards against such threats must be documented and tested.

The document addresses some adjacent elements of safety and resilience — Section 5.1 requires pre-deployment testing in a production-mirroring environment, Section 5.2 mandates ongoing monitoring with anomaly alerting for High-Impact AI, and Section 9 references incident response for 'security compromises affecting AI systems.' However, the policy does not explicitly address resilience to systematic vulnerabilities, adversarial manipulation (e.g., adversarial examples, prompt injection, model evasion), or malicious exploitation (e.g., model theft, data poisoning). No adversarial testing, red-teaming, or security-specific AI safeguards are documented.

Add explicit technical and procedural safeguards against adversarial manipulation and malicious exploitation (e.g., adversarial robustness testing, red-team exercises, protections against data poisoning and model extraction), require documentation and periodic testing of those safeguards, and tie AI-specific security controls into the incident response program.

Agencies must clearly define, assign, and document human roles and responsibilities for the design, development, acquisition, and use of AI. The design, development, acquisition, use, inputs, and outputs of AI applications must be documented and traceable to the extent practicable.

The document defines several human roles (CAIO, AI Governance Board membership, system owner, technical custodian) and requires documentation of Pre-Deployment Reviews, risk acceptance decisions signed by the system owner and countersigned by the CAIO, and a 7-year retention of AI inventory records and review results. However, Section 3.3 explicitly states that Component AI Lead role definitions are 'under development and are expected to be finalized in the next policy revision,' leaving a material gap in assigned responsibilities. Additionally, while design, acquisition, and use are partially addressed, there is no explicit requirement to document and trace AI inputs and outputs (e.g., training data lineage, model inputs/outputs logs) as required by §3(f).

Finalize Component AI Lead role definitions and responsibilities, and add explicit requirements for documenting and maintaining traceability of AI inputs, outputs, training data lineage, and model decisions throughout the AI lifecycle.

Agencies must regularly test AI applications against the Principles and maintain mechanisms to supersede, disengage, or deactivate AI applications that demonstrate performance or outcomes inconsistent with intended use. Testing cadence and kill-switch procedures must be documented.

The document addresses ongoing monitoring with classification-based cadences ('High-Impact AI is monitored continuously with anomaly alerting; Limited-Impact AI is reviewed no less than quarterly; Administrative AI is reviewed annually') and mentions that detected issues can trigger 'temporary suspension of the system.' The CAIO also has authority to 'require the immediate suspension of any AI system found to be operating outside its intended scope.' However, the document does not describe regular testing against the EO 13960 Principles specifically, nor does it document formal kill-switch/deactivation procedures (who executes, how, technical mechanism, rollback, notification). Section 5.3 on fairness testing is aspirational rather than procedural.

Add a documented testing protocol that explicitly evaluates AI systems against the nine EO 13960 Principles on a defined cadence, and establish formal supersede/disengage/deactivate procedures specifying technical kill-switch mechanisms, designated authorities to invoke them, execution steps, and post-deactivation review requirements.

Agencies must be transparent in disclosing relevant information regarding their AI use to Congress, the public, and other appropriate stakeholders, to the extent practicable and consistent with applicable laws. Disclosure procedures must balance transparency with protection of privacy, law enforcement, and national security information.

Section 8 establishes transparency mechanisms including an annual AI Transparency Statement, a quarterly redacted public AI Use Case Inventory (Section 4: 'A redacted public version of the AI Use Case Inventory is published to acme-federal.com/transparency on a quarterly basis'), and point-of-interaction notices to individuals. However, the document does not specifically address disclosure to Congress or 'other appropriate stakeholders' as required, nor does it articulate a formal procedure balancing transparency against privacy, law enforcement, and national security information beyond a general reference to 'protection of sensitive and classified information.'

Add explicit procedures for disclosures to Congress and other stakeholders, and document a formal balancing framework (criteria, decision authority, and redaction standards) for weighing transparency against privacy, law enforcement, and national security exemptions.

Agencies must use voluntary consensus standards developed with industry participation, where available, unless inconsistent with applicable law or otherwise impracticable. The governance framework must document which standards are applied to AI systems.

The document references alignment with the NIST AI Risk Management Framework (AI RMF 1.0) in Section 1 ('It aligns with guidance under... the NIST AI Risk Management Framework (AI RMF 1.0)'), which is a voluntary consensus standard. However, it does not document any other voluntary consensus standards applied to AI systems (e.g., ISO/IEC 42001, IEEE standards, ISO/IEC 23894), nor does it describe a process for identifying, evaluating, or documenting applicable voluntary consensus standards per system, nor does it address the OMB Circular A-119 framework for standards selection.

Add a provision explicitly committing to use of voluntary consensus standards consistent with OMB Circular A-119, maintain a register of which specific standards (e.g., NIST AI RMF, ISO/IEC 42001, IEEE 7000-series) apply to each AI system in the inventory, and document any cases where such standards are impracticable or inconsistent with law.

Each agency must prepare an inventory of its non-classified and non-sensitive AI use cases, including current and planned uses, within 180 days of the CIO Council's guidance and annually thereafter. The inventory must follow the format and mechanisms specified by the CIO Council.

Section 4 establishes a comprehensive AI Use Case Inventory maintained by the CAIO's office with detailed per-system fields (name, vendor, classification, data sources, owner, risk assessment dates, contract info) and commits to quarterly publication of a redacted public version. However, the document does not reference the required 180-day initial preparation timeline, annual submission cadence to the federal government, or adherence to the format and mechanisms specified by the CIO Council as required under §5(b).

Add explicit language committing to preparing the inventory within 180 days of CIO Council guidance, updating it annually per federal cadence, and using the format/mechanisms specified by the CIO Council for federal reporting (not just internal and public transparency).

Agencies must make their AI use case inventories available to the public within 120 days of completion, to the extent practicable and consistent with applicable law. Public release processes must include appropriate redactions for privacy, law enforcement, and national security information.

Section 4 states that 'A redacted public version of the AI Use Case Inventory is published to acme-federal.com/transparency on a quarterly basis, consistent with federal transparency expectations and in accordance with the protection of sensitive and classified information.' This addresses public release with redactions in general terms, but the document does not specify the 120-day timeline from inventory completion, nor does it enumerate the specific redaction categories required (privacy, law enforcement, national security) or the process by which redaction determinations are made.

Amend Section 4 to commit to public release within 120 days of inventory completion, and define a formal redaction review process that explicitly addresses privacy, law enforcement, and national security categories with named approvers (e.g., CPO, General Counsel, security officer) for each category.

Agencies must participate in interagency bodies identified by the CIO Council for the purpose of advancing implementation of the Principles and consistent AI use. Participation decisions and activities should be documented as part of governance.

The document mentions that the CAIO has authority to 'Represent Acme in federal interagency AI coordination activities as required,' which acknowledges participation in interagency coordination. However, there is no reference to the CIO Council specifically, no identification of which interagency bodies Acme participates in, and no mechanism for documenting participation decisions and activities as part of governance.

The policy should explicitly identify the CIO Council-designated interagency bodies in which Acme participates, name responsible representatives, and establish a process for documenting participation decisions, meeting attendance, and outcomes within the governance record (e.g., Board minutes or a dedicated register).

Each agency must, within 30 days of the Order, designate responsible official(s) to coordinate implementation of the AI Principles with the Agency Data Governance Body and other relevant officials. These officials must also collaborate with identified interagency coordination bodies.

The document designates Samira Delacroix as Chief AI Officer effective February 1, 2026, with documented authority including to 'Represent Acme in federal interagency AI coordination activities as required.' However, §8(c) applies to federal agencies rather than contractors, and the document does not explicitly reference coordination with an Agency Data Governance Body nor name specific interagency coordination bodies. The 30-day designation timeline from the Order is also not addressed.

Clarify applicability (as a contractor, Acme is not directly subject to §8(c)) or, if claiming alignment, explicitly name the Agency Data Governance Body counterparts and interagency coordination bodies (e.g., AI CoP, CAIO Council) the CAIO coordinates with, and document the scope of that coordination.

The Principles and implementation guidance must apply to AI designed, developed, acquired, or used to advance agency missions, enhance decision making, or provide public benefits, including AI developed by third parties on behalf of the agency and AI procured by the agency. Governance processes must cover training data inputs and decision-support outputs for such systems.

The document's Section 1 explicitly extends scope to 'development, procurement, deployment, and ongoing use of AI systems' including 'AI systems provided by external vendors but deployed in Acme environments,' and the inventory (Section 4) captures vendor and contract information. However, Section 7 on Procurement is only two sentences and lacks substantive controls over third-party AI — there is no explicit requirement that governance processes cover training data inputs or decision-support outputs of procured/third-party systems, no contract clauses mandated for vendor transparency into training data, and no described mechanism for agency oversight of vendor-developed AI built on the agency's behalf.

Expand Section 7 to require specific contractual controls on Covered Vendors, including vendor disclosure of training data provenance and quality, access to model documentation, decision-output auditability, and explicit application of Pre-Deployment Review and Ongoing Monitoring (Sections 5.1–5.2) to third-party and procured AI with the same rigor as internally developed systems.

The organization must identify, understand, manage, and document all legal and regulatory requirements involving AI that apply to its systems and operations. This includes maintaining current awareness of applicable laws across jurisdictions where AI systems are developed or deployed.

The policy references alignment with several federal authorities (OMB M-24-10, M-25-21, M-25-22, EO 13960, NIST AI RMF 1.0) in Section 1 and allows interim updates 'in response to changes in applicable law' in Section 12. However, it does not establish a specific process to identify, track, or document the full universe of legal and regulatory requirements applicable to its AI systems, nor does it address multi-jurisdictional awareness. There is no named owner for legal/regulatory horizon scanning, no register of applicable laws, and no documented procedure for assessing new regulations against the AI portfolio.

Acme should establish a documented legal/regulatory register enumerating applicable AI-related laws and regulations across relevant jurisdictions, assign ownership (e.g., General Counsel in coordination with the CAIO) for ongoing monitoring of changes, and define a procedure for mapping each AI system in the inventory to its applicable legal obligations.

The organization must integrate the characteristics of trustworthy AI (valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed) into organizational policies, processes, procedures, and practices. These integrations must be documented and operationalized, not merely stated as aspirations.

The document addresses some trustworthy AI characteristics operationally — security (via CISO involvement and incident response §9), privacy (Chief Privacy Officer role, §8), accountability/transparency (CAIO authority §3.1, public inventory §4, Transparency Statement §8), and validity/reliability (Pre-Deployment testing §5.1, monitoring §5.2). However, it does not integrate all seven NIST trustworthy AI characteristics systematically. 'Safe' is not explicitly addressed as a policy characteristic; 'explainable and interpretable' is entirely absent; 'secure and resilient' is only partially covered (security yes, resilience not addressed); and 'fair with harmful bias managed' appears only as an aspirational statement in §5.3 ('Acme is committed to the fair and equitable use of AI... we will evaluate outputs for potential disparate impact and take corrective action where appropriate') without specific metrics, thresholds, testing methodology, or controls.

Amend the policy to explicitly enumerate all seven NIST trustworthy AI characteristics and map each to specific operational controls, procedures, and documentation requirements. In particular, add concrete fairness/bias testing methodology with metrics and thresholds (replacing the aspirational §5.3 language), add explainability/interpretability requirements (e.g., model documentation, explanation mechanisms for High-Impact AI), and add resilience requirements (e.g., adversarial testing, failover).

The organization must have documented processes and procedures to determine the required level of risk management activities based on its defined risk tolerance. Risk tolerance determinations must account for context, application, and use-case specificity.

The document establishes a tiered classification scheme (High-Impact, Limited-Impact, Administrative) in Section 4 and calibrates some monitoring activities to those tiers in Section 5.2 ('High-Impact AI is monitored continuously with anomaly alerting; Limited-Impact AI is reviewed no less than quarterly; Administrative AI is reviewed annually'). However, the document does not define an organizational risk tolerance, nor does it document the process or criteria by which risk tolerance is determined or how it accounts for context, application, and use-case specificity. The classification definitions in Section 2 are threshold definitions, not risk tolerance statements, and there is no documented procedure for calibrating risk management activities to a defined tolerance.

Acme should document an explicit risk tolerance statement (including acceptable/unacceptable risk thresholds), a procedure for determining risk tolerance on a context- and use-case-specific basis, and a mapping showing how the level of required risk management activities (assessment depth, review frequency, controls) is calibrated against that tolerance.

The organization must document roles, responsibilities, and lines of communication related to mapping, measuring, and managing AI risks. These must be clearly communicated to individuals and teams throughout the organization.

The document documents roles for the CAIO (Section 3.1) and AI Governance Board (Section 3.2) with specific authorities, reporting lines, and membership. However, Section 3.3 (Component AI Leads) explicitly states that 'Individual business units will work with the CAIO's office to identify points of contact as needed. Detailed role definitions are under development and are expected to be finalized in the next policy revision,' indicating incomplete role documentation at the business unit level. Additionally, while lines of communication to the CAIO and Audit Committee are described, there is no explicit documentation of how roles, responsibilities, and communication lines are communicated to individuals and teams throughout the organization.

Finalize the Component AI Lead role definitions with documented responsibilities for mapping, measuring, and managing AI risks at the business unit level, and add an explicit mechanism (e.g., onboarding, intranet publication, mandatory briefings) for communicating roles, responsibilities, and escalation/communication pathways to all relevant individuals and teams.

The organization must ensure personnel and partners receive AI risk management training sufficient to perform their duties and responsibilities consistent with related policies, procedures, and agreements. Training must be documented and ongoing.

Section 10 states that 'All employees involved in the design, development, acquisition, or operational oversight of AI systems receive initial and recurring training,' that content is 'updated at least annually,' and that records are retained in the LMS with completion tracked as a condition of continued assignment. Section 6 also requires operators of High-Impact AI to receive mandatory pre-deployment and annual recurring training. However, the policy does not address training for partners/third-party vendors (despite vendors being in scope per Section 1), does not specify training content sufficient to perform AI risk management duties (e.g., topics, role-based curricula, competency criteria), and does not define documentation standards beyond LMS completion tracking.

Extend training requirements to cover partners/Covered Vendors with contractual training obligations, define role-based curricula and competency requirements tied to AI risk management duties, and specify documentation standards (content, attendance, assessment outcomes) beyond simple completion tracking.

Executive leadership must take documented responsibility for decisions about risks associated with AI system development and deployment. Accountability structures must escalate material AI risk decisions to senior leadership.

The document establishes a CAIO (Samira Delacroix, CTO) reporting to the CEO with authority to approve/reject AI deployments, and an AI Governance Board whose minutes are provided quarterly to the Audit Committee of the Board of Directors. However, the policy does not explicitly articulate that executive leadership takes *documented responsibility* for AI risk decisions, nor does it define escalation thresholds for what constitutes a 'material' AI risk decision requiring senior leadership or board-level sign-off. Risk acceptance is signed by the system owner and countersigned by the CAIO, but there is no defined escalation path to the CEO or Board of Directors for material risks beyond informational reporting.

Add explicit language defining materiality thresholds that trigger escalation to the CEO and/or Board of Directors, and require documented sign-off (not just informational minutes) from senior executives for high-risk AI decisions. Clarify that executive leadership bears accountability for residual AI risk acceptance.

The organization must have practices in place to enable AI testing, identification of incidents, and information sharing about AI failures and adverse events. Incident reporting mechanisms must be operational and documented.

Section 9 establishes internal incident response: AI incidents are 'reported through Acme's existing IT incident response procedures with an additional notification to the CAIO within 24 hours of detection' and 'Post-incident reports are reviewed by the AI Governance Board.' Section 5.1 requires testing reports using independent validation datasets, and Section 5.2 requires monitoring with documented response to drift. However, the document does not address external information sharing about AI failures and adverse events (e.g., participation in AI incident databases, ISACs, peer organizations, or federal incident sharing channels), nor does it document channels for affected users or the public to report AI failures.

Add explicit provisions for external information sharing about AI failures (e.g., participation in AI incident repositories, interagency coordination, or vendor/peer disclosure) and establish a documented intake channel allowing end users, employees, and affected individuals to report suspected AI failures or adverse events.

The organization must have policies and procedures addressing AI risks associated with third-party software, data, and services, including risks of infringement of third-party intellectual property or other rights. Third-party risk assessments must be performed and documented.

Section 7 acknowledges that Acme procures AI from external vendors and requires procurement to be 'coordinated with the Director of Procurement and reviewed by the CAIO's office,' and Section 2 defines 'Covered Vendor.' However, the document contains no specific policies or procedures addressing third-party AI risks such as IP infringement, third-party data provenance, or supply chain security. No documented third-party risk assessment process, vendor due diligence criteria, or contractual control requirements are specified.

Add explicit policies covering third-party AI risk assessment methodology, IP infringement review (including training data provenance and license compliance), supply chain security controls, required contractual clauses, and documentation/retention requirements for vendor risk assessments prior to and during engagement.

The organization must have contingency processes to handle failures or incidents in third-party data or AI systems deemed high-risk. These processes must be documented, tested, and actionable.

The document addresses incident response generically in Section 9, stating that 'AI-related incidents — including unintended outputs, security compromises affecting AI systems, and significant operational failures — are reported through Acme's existing IT incident response procedures' with CAIO notification within 24 hours. However, it does not specifically address contingency processes for failures in third-party/vendor AI systems, despite Section 7 acknowledging that 'Acme procures many of its AI capabilities from external vendors.' There is no documentation of fallback procedures, tested contingency plans, or actionable response workflows specific to third-party AI or data failures for high-risk systems.

Add explicit contingency processes for third-party AI/data system failures, including documented fallback procedures (e.g., manual processing, alternate vendors, service degradation protocols), evidence of periodic testing/tabletop exercises of those contingencies, and clear activation criteria and roles specifically for vendor-provided high-impact AI systems.

The organization must document intended purposes, beneficial uses, context-specific laws, norms, expected user populations, and prospective deployment settings for each AI system. Documentation must include potential positive and negative impacts on individuals, communities, organizations, society, and the environment.

Section 5.1 requires an AI Impact Assessment that 'identifies intended purpose, expected benefits, populations affected, data quality, and anticipated failure modes,' and Section 4 captures 'Business purpose and functional description' in the inventory. However, the document does not require documentation of context-specific laws and norms, prospective deployment settings, or potential positive and negative impacts on communities, society, and the environment as required by Map 1.1.

Expand the AI Impact Assessment template to explicitly require documentation of applicable context-specific laws and norms, expected deployment settings, and a structured analysis of positive and negative impacts across individuals, communities, organizations, society, and the environment.

The organization must define, assess, and document processes for human oversight of AI systems in accordance with organizational governance policies. Human oversight configurations must be role-appropriate and verifiable.

Section 6 defines human oversight mechanisms for High-Impact AI, including fallback override, opt-out, appeals with independent human review, and mandatory operator training. However, the policy does not describe how these oversight processes are assessed for effectiveness or verified (e.g., audits, testing of override mechanisms, metrics), nor does it specify role-appropriate oversight configurations beyond the generic 'operator' role. Oversight for Limited-Impact and Administrative AI is not addressed.

Add explicit processes to periodically assess and verify human oversight effectiveness (e.g., testing override mechanisms, reviewer competency verification, audit logs of human interventions) and define role-specific oversight responsibilities tied to system classification.

The organization must identify and document the likelihood and magnitude of each identified impact (beneficial and harmful) based on expected use, prior incidents in similar contexts, public incident reports, and external feedback. Impact assessments must cover individuals, groups, communities, organizations, and society.

Section 5.1 requires an AI Impact Assessment identifying 'intended purpose, expected benefits, populations affected, data quality, and anticipated failure modes,' which partially addresses impact identification. However, the document does not require documenting the likelihood and magnitude of each impact, does not reference prior incidents in similar contexts, public incident reports, or external feedback as inputs, and does not explicitly require coverage of impacts to groups, communities, and society (beyond 'populations affected').

Expand the AI Impact Assessment template to explicitly require documented likelihood and magnitude ratings for each identified beneficial and harmful impact, drawing on prior incidents, public incident databases (e.g., AIID), and external stakeholder feedback, and require assessment across individuals, groups, communities, organizations, and society.

AI system performance or assurance criteria must be measured qualitatively or quantitatively and demonstrated for conditions similar to the expected deployment setting. Measurement methodologies, test sets, and results must be documented.

Section 5.1 requires 'A testing report conducted under conditions that mirror the intended production environment, using a validation dataset that is independent of the training dataset,' which addresses deployment-like testing conditions. However, the policy does not specify what performance or assurance criteria must be measured, what measurement methodologies are required, how test sets are constructed or documented beyond being 'independent,' or what specific results documentation is retained beyond a general retention period.

Expand Section 5.1 to specify the qualitative and quantitative performance metrics required (e.g., accuracy, robustness, fairness thresholds), the methodology for constructing representative deployment-like test sets, and explicit documentation requirements for methodology, test set composition, and results.

The AI system must be evaluated regularly for safety risks and demonstrated to be safe prior to deployment, with residual negative risk not exceeding defined risk tolerance. Safety metrics must cover reliability, robustness, real-time monitoring, response times, and safe failure behavior particularly when operating beyond knowledge limits.

The document addresses general monitoring and pre-deployment testing (Section 5.1 requires 'a testing report conducted under conditions that mirror the intended production environment' and Section 5.2 requires continuous monitoring with anomaly alerting for High-Impact AI), but it does not specifically address safety risk evaluation, defined risk tolerance thresholds, or safety metrics such as reliability, robustness, response times, or fail-safe behavior when operating beyond knowledge limits. The Pre-Deployment Review mentions 'anticipated failure modes' but does not require demonstration of safe failure behavior or define residual risk tolerance.

Add explicit safety evaluation requirements including defined quantitative risk tolerance thresholds, mandatory safety metrics (reliability, robustness, response time, safe-failure behavior), documented out-of-distribution/knowledge-limit handling procedures, and a requirement that systems be demonstrated safe prior to deployment with residual risk not exceeding tolerance.

Fairness and bias in the AI system must be evaluated, with results documented. Evaluation must address systemic, computational/statistical, and human-cognitive bias categories and consider differential impacts across affected groups.

Section 5.3 states that Acme 'will evaluate outputs for potential disparate impact and take corrective action where appropriate,' but this is an intent statement without specific methodology, metrics, or documentation requirements. The document does not address the three bias categories (systemic, computational/statistical, human-cognitive) required by Measure 2.11, nor does it specify how differential impacts across affected groups will be measured or documented.

Add explicit requirements for fairness evaluation covering all three NIST bias categories (systemic, computational/statistical, human-cognitive), specify quantitative fairness metrics, require documented analysis of differential impacts across protected/affected groups, and define retention and review requirements for bias evaluation artifacts.

The organization must establish feedback processes allowing end users and impacted communities to report problems and appeal AI system outcomes. These mechanisms must be integrated into AI system evaluation metrics and operational workflows.

The document addresses appeal mechanisms for High-Impact AI in Section 6, stating 'Appeals processes for AI-driven adverse decisions must provide meaningful human review by a person not involved in the original AI output' and references an 'opt-out mechanism for affected individuals.' However, there is no general user feedback process for end users or impacted communities to report problems, and no indication that feedback/appeals are integrated into AI system evaluation metrics or operational workflows as required by Measure 3.3. The mechanisms described are limited to High-Impact AI adverse decisions, not broader end-user feedback.

Establish an accessible feedback channel for end users and impacted communities (not limited to High-Impact AI adverse decisions), document how reports are triaged, and specify how feedback data is incorporated into evaluation metrics and monitoring workflows described in Section 5.2.

The organization must allocate risk resources to mapped and measured AI risks on a regular basis, with documented plans to respond to, recover from, and communicate about AI incidents or adverse events. Plans must include criteria for ceasing development or deployment when risks are unacceptable.

The document partially addresses Manage 1.1. Section 9 establishes incident response with 24-hour CAIO notification and Board review, and Section 5.2 references 'temporary suspension' upon degradation. Section 3.1 allocates $1.8M dedicated governance budget, partially satisfying resource allocation. However, the document lacks documented recovery plans, external/public communication plans for adverse AI events, and — critically — no defined criteria for ceasing development or deployment when risks are deemed unacceptable. Risk resource allocation to specific mapped/measured risks on a regular basis is also not documented.

Add explicit go/no-go criteria and thresholds triggering cessation of development or deployment, documented recovery procedures for AI incidents, a stakeholder communication plan (including affected individuals and regulators), and a recurring process for allocating risk resources against the mapped/measured risk register.

The organization must define roles for periodic review of content provenance and GAI incident monitoring, conduct after-action reviews of incident response and disclosures, and update response processes based on gaps identified. A document retention policy must preserve TEVV records and digital content transparency artifacts.

The document addresses some elements of Govern 1.5: ongoing monitoring is defined with frequencies by classification (§5.2), incidents are reviewed by the AI Governance Board post-incident (§9), and certain records are retained (Board minutes 7 years §3.2; Pre-Deployment Review records life+7 years §5.1). However, the document does not specifically address content provenance review roles, GAI-specific incident monitoring, after-action reviews of disclosures, updating response processes based on identified gaps, or retention of TEVV records and digital content transparency artifacts as distinct categories. GenAI-specific provenance and transparency artifacts are entirely absent.

Add explicit roles for periodic review of content provenance and GAI incident monitoring, require formal after-action reviews covering both incident response and public/user disclosures with documented process updates based on gaps, and extend the document retention policy to explicitly preserve TEVV records and digital content transparency artifacts (e.g., watermarking logs, provenance metadata, disclosure notices).

The organization must maintain an inventory of GAI systems that includes data provenance (source, signatures, versioning, watermarks), known issues from incident databases, human oversight roles, IP and sensitive-data considerations, and underlying foundation models and access modes. Inventory exemptions for embedded GAI must be explicitly defined.

Section 4 establishes an AI Use Case Inventory with fields including system name/version, vendor, business purpose, classification, data sources and sensitivity, system owner, and risk assessment dates. However, the inventory does not specifically address GAI-unique elements required by Govern 1.6: data provenance (source signatures, versioning, watermarks), known issues from incident databases (e.g., AVID, AIID), IP and sensitive-data considerations specific to GAI training data, underlying foundation models and access modes (API, fine-tuned, on-prem), or explicit exemptions for embedded GAI. The policy is AI-general and does not differentiate GAI systems.

Expand the inventory schema to include GAI-specific fields: foundation model identity and version, access mode (API/hosted/fine-tuned/self-hosted), training data provenance and watermark/signature status, linkage to known-issue trackers (AIID/AVID), IP and sensitive-data review status, and documented human oversight roles. Additionally, define explicit criteria for when embedded GAI components are exempted from inventory and document the rationale.

The organization must document roles, lines of communication, and procedures for reporting GAI incidents and performance to internal and downstream stakeholders via recognized incident resources. It must verify that incident responders have appropriate skills, involve national security professionals where relevant, and provide whistleblower protections for reports of legal violations or substantiated public safety risks.

The document addresses roles (CAIO, Governance Board) and includes an incident response clause (Section 9) requiring CAIO notification within 24 hours and Board review. However, it does not document lines of communication to downstream/external stakeholders via recognized incident resources (e.g., AI incident databases), does not verify incident responder skills/qualifications, makes no reference to involving national security professionals despite serving Defense and Intelligence Community lines, and contains no whistleblower protections for reporting legal violations or public safety risks. Section 3.3 on Component AI Leads explicitly defers role definitions to a future revision.

Add explicit whistleblower protection provisions (anti-retaliation, confidential reporting channels) for legal violations and public safety risks; specify responder qualifications/skills verification; document procedures for reporting GAI incidents to downstream stakeholders and recognized external incident-sharing resources; and require involvement of national security professionals for IC/Defense-facing AI incidents.

The organization must allocate resources for external outreach, feedback, and recourse processes for GAI systems and must disclose user interactions with GAI systems prior to interactive activities, particularly in higher-risk contexts.

The document addresses user disclosure in Section 8: 'Individuals interacting with Acme services that materially rely on AI are notified of that fact at the point of interaction where practicable,' but this is hedged by 'where practicable' and delegates form/placement to system owners without binding standards, particularly for higher-risk contexts. The document does not allocate resources for external outreach, external feedback mechanisms, or recourse processes for GAI systems — Section 6 provides internal appeals for High-Impact AI but no external feedback channel, and no GAI-specific provisions exist anywhere in the policy.

Add explicit GAI-specific provisions that (1) require pre-interaction disclosure of GAI use without 'where practicable' carve-outs in higher-risk contexts, (2) establish and resource external feedback channels (e.g., public reporting portal, bug bounty, red-team engagement) with named owners and budget, and (3) define a recourse process for external parties harmed by GAI outputs.

The organization must manage third-party GAI risks through well-defined contracts and SLAs specifying content ownership, usage rights, security, and provenance expectations; implement a use-case-based supplier risk assessment framework; maintain an inventory of approved third-party GAI providers; and update procurement due diligence to cover IP, data privacy, security, and embedded GAI technologies.

Section 7 acknowledges AI procurement and requires coordination with the Director of Procurement and CAIO review, and Section 4 captures vendor name and contract number in the inventory. However, the document does not specify contractual/SLA clauses covering content ownership, usage rights, security, or provenance; does not describe a use-case-based supplier risk assessment framework; does not establish an inventory of approved third-party GAI providers distinct from the general AI inventory; and does not address updated procurement due diligence for IP, data privacy, security, or embedded GAI technologies.

Add explicit contract/SLA requirements for GAI vendors (content ownership, usage rights, security, provenance/watermarking), define a use-case-based supplier risk tiering methodology, establish and maintain an approved third-party GAI provider list, and formalize procurement due diligence standards covering IP, privacy, security, and embedded GAI components.

The organization must document the intended purpose, context of use, assumptions, limitations, and acceptable operational environment for each GAI system. Foreseeable illegal uses, misuse, abuse, and off-label uses that exceed organizational risk tolerances must be explicitly identified.

Section 5.1 requires an AI Impact Assessment that 'identifies intended purpose, expected benefits, populations affected, data quality, and anticipated failure modes,' which partially addresses intended purpose and limitations. However, the document does not explicitly require documentation of context of use, assumptions, acceptable operational environment, or — critically — identification of foreseeable illegal uses, misuse, abuse, or off-label uses exceeding risk tolerances. The policy also does not specifically address generative AI systems or their unique misuse vectors.

Amend the AI Impact Assessment template to explicitly require documentation of operational assumptions, acceptable deployment environments, and an enumerated list of foreseeable illegal uses, misuse, abuse, and off-label uses that exceed Acme's defined risk tolerances, with specific attention to GenAI-specific misuse patterns (e.g., prompt injection, CBRN uplift, CSAM generation, defamation).

The organization must understand and document the mission, internal and external stakeholder needs, dependencies, and legal, regulatory, and contractual requirements (including privacy and civil liberties obligations) that inform cybersecurity risk management decisions. Critical objectives, capabilities, and services that external stakeholders depend on, as well as those the organization depends on, must be identified and communicated.

The document identifies certain stakeholders (federal customers, business units such as Defense Services, Civil Services, Intelligence Community) and references some regulatory drivers (OMB M-24-10, M-25-21, M-25-22, EO 13960, NIST AI RMF). However, it does not document the organizational mission, internal/external stakeholder needs, dependencies (supply chain or operational), or critical objectives/capabilities/services that external stakeholders depend on. Privacy and civil liberties obligations are not explicitly inventoried, and there is no mapping of legal/regulatory/contractual requirements informing cybersecurity risk decisions.

Add an explicit organizational context section documenting Acme's mission, a register of internal and external stakeholders and their needs, a list of critical services/capabilities Acme provides and depends on, and a comprehensive mapping of legal, regulatory, contractual, privacy, and civil liberties obligations that drive cybersecurity risk management decisions.

The organization must establish, communicate, and enforce cybersecurity roles, responsibilities, and authorities, with leadership held accountable for cybersecurity risk and for fostering a risk-aware, ethical, and continually improving culture. Adequate resources must be allocated commensurate with the cybersecurity risk strategy, and cybersecurity must be integrated into human resources practices.

The document establishes clear AI governance roles (CAIO with documented charter, reporting line to CEO, $1.8M dedicated budget, AI Governance Board with defined membership and quarterly cadence, system owners, technical custodians) and integrates training into HR practices (Section 10: training tracked in LMS as 'a condition of continued assignment to AI-related roles'). However, the requirement is specifically about cybersecurity roles/responsibilities/authorities, not AI governance roles. The document does reference the CISO as a Board member but does not articulate cybersecurity-specific roles, authorities, leadership accountability for cybersecurity risk, or resource allocation commensurate with a cybersecurity risk strategy. Section 3.3 (Component AI Leads) explicitly defers detailed role definitions to a future revision, which is a gap even on the AI side.

Add explicit cybersecurity roles, responsibilities, and authorities (e.g., CISO accountability statement, delegation chains for cybersecurity decisions affecting AI systems), document leadership accountability for cybersecurity risk with resource allocation tied to the cybersecurity risk strategy, and finalize the Component AI Leads role definitions rather than deferring them.

The organization must establish, communicate, and enforce a cybersecurity policy based on organizational context, strategy, and priorities. The policy must be reviewed and updated periodically to reflect changes in requirements, threats, technology, and organizational mission.

The document is an AI governance policy, not a cybersecurity policy. While Section 12 establishes a formal review cycle ('reviewed and updated no less than annually... Next scheduled review is January 2027') and Section 1 grounds the policy in organizational context (federal contractor obligations, OMB memoranda, EO 13960, NIST AI RMF), it does not establish or reference an overarching cybersecurity policy. The CISO is named as a Governance Board member, but no cybersecurity policy establishment, communication, or enforcement process is documented, and the policy does not address cybersecurity threats, technology changes, or mission evolution as review triggers in a cybersecurity context.

Either incorporate by reference an existing enterprise cybersecurity policy (with its own scope, review cadence, and enforcement mechanisms) or expand this document to explicitly establish cybersecurity policy elements — including communication channels to the workforce, enforcement mechanisms tied to cybersecurity controls, and review triggers tied to threat landscape and technology changes, not just AI-specific law and guidance.

The organization must review the outcomes and performance of its cybersecurity risk management strategy to inform and adjust the strategy and direction. Reviews must confirm that the strategy covers organizational requirements and risks, and performance evaluations must identify adjustments needed.

The document establishes annual policy review (Section 12: 'This policy is reviewed and updated no less than annually') and quarterly Board meetings with minutes provided to the Audit Committee (Section 3.2), plus monthly monitoring summaries to the CAIO (Section 5.2). However, these provisions focus on policy review and operational monitoring, not on reviewing the outcomes and performance of the overall cybersecurity/AI risk management strategy to confirm it covers organizational requirements and risks, nor on performance evaluations that identify strategic adjustments.

Add an explicit governance process requiring periodic review of the risk management strategy's outcomes and performance against organizational requirements, with documented performance evaluation criteria and a mechanism for feeding findings back into strategy adjustment (e.g., annual strategy effectiveness review by the AI Governance Board with documented strategic course corrections).

The organization must establish a cybersecurity supply chain risk management (C-SCRM) program including strategy, objectives, policies, and processes agreed to by stakeholders, integrated with enterprise risk management. Suppliers must be identified and prioritized by criticality; cybersecurity requirements must be incorporated into contracts; due diligence must be performed before entering relationships; supplier risks must be assessed and monitored throughout the relationship; and plans must address activities after the conclusion of supplier relationships.

The document addresses AI vendor management at a high level through Section 7 (Procurement) stating 'Procurement of AI systems must be coordinated with the Director of Procurement and reviewed by the CAIO's office,' and Section 2 defines 'Covered Vendor.' The inventory (Section 4) captures vendor name and contract expiration. However, the document lacks a formal C-SCRM program with strategy and objectives, does not describe supplier criticality prioritization, does not specify cybersecurity contract clauses, does not document pre-engagement due diligence processes, does not describe ongoing supplier risk monitoring, and contains no provisions for activities at the conclusion of supplier relationships (offboarding, data return/destruction, access revocation).

Acme should develop an explicit C-SCRM program integrated with enterprise risk management, including supplier criticality tiering, mandatory cybersecurity contract clauses, documented pre-contract due diligence procedures, periodic supplier risk reassessment, and defined supplier offboarding/termination procedures addressing data handling and access revocation.

The organization must maintain inventories of hardware, software, services, systems, data (with metadata for designated data types), and services provided by suppliers. Network communications and data flows must be documented, assets must be prioritized based on classification, criticality, and mission impact, and systems, hardware, software, services, and data must be managed throughout their life cycles.

Section 4 establishes an AI Use Case Inventory with fields including system name/version/vendor, data sources and sensitivity classification, system owner, and contract details, which partially addresses asset inventory for AI systems. However, the document does not address inventories of hardware, software libraries, underlying services, or supplier-provided services beyond the AI use case level; there is no documentation of network communications or data flows; no asset prioritization based on criticality or mission impact; and no life cycle management controls for hardware, software, services, or data.

Expand the inventory to cover hardware, software components/libraries, services, data with required metadata, and supplier services; document network communications and data flows for AI systems; establish asset prioritization criteria based on classification, criticality, and mission impact; and define life cycle management processes from acquisition through decommissioning.

The organization must identify improvements to cybersecurity risk management processes, procedures, and activities from evaluations, security tests and exercises (including those coordinated with suppliers and third parties), and from execution of operational processes. Incident response plans and other cybersecurity plans that affect operations must be established, communicated, maintained, and improved.

The document establishes an incident response pathway (Section 9) requiring AI-related incidents to be reported through existing IT incident response procedures with CAIO notification within 24 hours, and post-incident reports reviewed by the AI Governance Board. Section 12 provides for annual policy review. However, the document does not describe a systematic process for identifying improvements from evaluations, security tests, exercises, or supplier/third-party coordinated exercises, nor does it describe how lessons learned from incidents or operational execution feed back into process improvement. There is no mention of tabletop exercises, red-team testing, or supplier-coordinated security exercises.

Add explicit provisions for (1) conducting and documenting security tests and exercises including those coordinated with Covered Vendors and third parties, (2) a lessons-learned process that captures improvements from incidents, evaluations, and operational execution and feeds them into updates to cybersecurity and incident response plans, and (3) communication and maintenance cadence for incident response and related cybersecurity plans.

The organization must provide cybersecurity awareness and training to personnel so they possess the knowledge and skills to perform general tasks with cybersecurity risks in mind. Individuals in specialized roles must receive additional awareness and training appropriate to their responsibilities.

Section 10 addresses training for 'employees involved in the design, development, acquisition, or operational oversight of AI systems' with initial and recurring training, and Section 6 requires mandatory and annual training for High-Impact AI operators. However, the policy addresses AI-specific training, not general cybersecurity awareness training for all personnel. There is no reference to cybersecurity awareness training for the general workforce, nor specialized cybersecurity training for specialized roles (e.g., CISO staff, developers, privileged users) as required by PR.AT.

Add explicit provisions requiring (1) baseline cybersecurity awareness training for all personnel and (2) role-based specialized cybersecurity training for individuals in security-sensitive or privileged roles, with frequency, content standards, and completion tracking.

The organization must monitor networks and network services, the physical environment, personnel activity and technology usage, external service provider activities, and computing hardware, software, and runtime environments to find anomalies, indicators of compromise, and potentially adverse events.

Section 5.2 addresses AI system monitoring with tiered frequency ('High-Impact AI is monitored continuously with anomaly alerting') and triggers responses to 'detected degradation in performance, change in input distribution, or drift from expected behavior.' However, the document does not address the broader DE.CM scope: monitoring of networks/network services, physical environment, personnel activity, external service provider activities, or computing hardware and runtime environments for indicators of compromise. Monitoring is narrowly scoped to AI model performance/drift, not adverse security events across the enumerated asset classes.

Expand the policy to explicitly require continuous monitoring of networks, physical environment, personnel and technology usage, third-party/vendor activity, and computing hardware/software/runtime environments for anomalies and indicators of compromise — or cross-reference an enterprise security monitoring program (SOC/SIEM, EDR, vendor activity logging, physical access monitoring) that provides these controls for AI systems.

The organization must analyze potentially adverse events to understand associated activities, correlate information from multiple sources, estimate impact and scope, and integrate cyber threat intelligence into analysis. Information on adverse events must be provided to authorized staff and tools, and incidents must be declared when adverse events meet defined incident criteria.

Section 9 (Incident Response) states that AI-related incidents including 'unintended outputs, security compromises affecting AI systems, and significant operational failures' are reported through existing IT incident response procedures with CAIO notification within 24 hours, and post-incident reports are reviewed by the AI Governance Board. However, the document does not address key DE.AE elements: correlating information from multiple sources, estimating impact and scope, integrating cyber threat intelligence into analysis, defined incident declaration criteria, or routing adverse event information to authorized staff and tools. The reference to 'existing IT incident response procedures' is not substantiated with any detail in this document.

Add explicit procedures for adverse event analysis covering multi-source correlation, impact/scope estimation, cyber threat intelligence integration, and defined incident declaration criteria specific to AI systems; or incorporate by reference a specific IR procedure document that demonstrably covers these elements.

The organization must execute its incident response plan in coordination with relevant third parties once an incident is declared. Incident reports must be triaged and validated; incidents must be categorized, prioritized, and escalated as needed; and defined criteria must govern the initiation of incident recovery.

Section 9 addresses AI incident response at a high level, stating incidents are 'reported through Acme's existing IT incident response procedures with an additional notification to the CAIO within 24 hours of detection' and 'Post-incident reports are reviewed by the AI Governance Board at its next scheduled meeting.' However, the document does not describe execution of the incident response plan in coordination with third parties (e.g., vendors of Covered AI systems), nor does it define triage/validation procedures, categorization and prioritization schemes, escalation paths, or defined criteria for initiating incident recovery.

Expand Section 9 to specify: (1) coordination protocols with Covered Vendors and other third parties during incident response, (2) a documented triage and validation process for AI incident reports, (3) categorization and prioritization criteria with escalation thresholds, and (4) explicit criteria governing when incident recovery is initiated.

The organization must conduct investigations to determine what occurred during an incident and its root cause. Actions performed during investigations must be recorded, and incident data and metadata must be collected with integrity and provenance preserved, and an incident's magnitude must be estimated and validated.

Section 9 (Incident Response) states that AI-related incidents are reported through existing IT incident response procedures with CAIO notification within 24 hours, and post-incident reports are reviewed by the AI Governance Board. However, the document does not specify any investigation process to determine root cause, does not require recording of investigative actions, does not address collection of incident data/metadata with integrity and provenance preserved, and does not require estimation or validation of incident magnitude. The reference to 'existing IT incident response procedures' is not detailed or cited.

The policy should explicitly require root cause analysis, documentation of investigative actions taken, chain-of-custody/provenance controls for incident artifacts and metadata, and a process to estimate and validate incident magnitude — or incorporate by reference a specific IT incident response procedure that demonstrably addresses each of these RS.AN elements.

The organization must coordinate response activities with internal and external stakeholders as required by laws, regulations, or policies, including notifying stakeholders of incidents and sharing information with designated parties. Incidents must be contained and eradicated to prevent expansion and mitigate effects.

Section 9 establishes that AI-related incidents are reported through existing IT incident response procedures with CAIO notification within 24 hours, and post-incident reports are reviewed by the AI Governance Board. However, the document does not specify coordination with external stakeholders (regulators, affected individuals, federal partners, CISA, etc.), does not describe notification obligations under laws or regulations, and provides no details on containment or eradication procedures to prevent incident expansion.

Augment Section 9 to specify external stakeholder coordination (including regulatory notification timelines, federal reporting obligations, and information-sharing with designated parties such as CISA or contracting officers), and add explicit containment and eradication procedures with defined roles and criteria for isolating, suspending, and remediating affected AI systems.