# AI Vendor Safety Commitment Register and Review Template Tracking the voluntary safety commitments that shaped a procurement decision, and reacting when they change. A commitment register, a monitoring configuration, a materiality threshold definition, and a re-assessment template. **Who this is for:** The vendor risk owner who bought partly on the strength of a vendor's safety pledges and needs to know if they hold. Source playbook: https://aigovernance.com/playbook/voluntary-ai-commitment-monitoring --- ## Vendor safety commitment register _The specific commitments that mattered at procurement, and whether each is currently verified._ ### Template | Vendor | Commitment | Source | Material to our decision? | Last verified | Current status | |---|---|---|---|---|---| | | | | Yes / No | YYYY-MM-DD | Verified / Weakened / Withdrawn / Unclear | ### Worked example | Vendor | Commitment | Source | Material? | Last verified | Current status | |---|---|---|---|---|---| | VendorLM | Pre-deployment third-party red-teaming of frontier models | Vendor safety policy v3 | Yes | 2026-08-15 | Verified | | VendorLM | Publish model cards with safety eval results | Vendor blog | Yes | 2026-08-15 | Weakened (last two releases: summary only) | | FraudCo | SOC 2 Type II maintained annually | Trust centre | Yes | 2026-06-15 | Verified | | FraudCo | Signatory to a national AI safety framework | Government registry | No | 2026-06-15 | Verified | ### Acceptance criteria - Commitments are specific and checkable, not "takes safety seriously". - Each is marked material or not, so monitoring effort goes where it counts. - Every material commitment has a verification date within the review cycle. --- ## Monitoring configuration _The feeds and cadence that would tell you a commitment changed, per vendor._ ### Template | Vendor | Feeds monitored | Alert type | Review frequency | Owner | |---|---|---|---|---| | | safety blog RSS; gov commitment registry; leadership changes; benchmark result pages | email / digest | monthly / quarterly | | ### Worked example | Vendor | Feeds monitored | Alert type | Review frequency | Owner | |---|---|---|---|---| | VendorLM | safety policy page (change-watch); model release notes; AI safety index | change-watch email | monthly | Vendor Risk | | FraudCo | trust centre; SOC 2 bridge letters; funding news | quarterly digest | quarterly | Vendor Risk | ### Acceptance criteria - Each material vendor has at least one automated feed, not only an annual manual check. - The review frequency matches the vendor's risk tier. - An owner is named per vendor and alerts route to them. --- ## Materiality threshold definition _The line between a commitment change you note and one that forces a formal re-assessment._ ### Template > Agree with Legal and the system owner. Apply consistently. **A commitment change triggers a formal vendor re-assessment when any of these are true:** - The commitment was material to the original procurement decision, and it has been weakened or withdrawn - A safety practice we relied on (pre-deployment testing, red-teaming, disclosure) is reduced in scope or frequency - The vendor exits a framework or registry we cited in our own compliance position - Key safety leadership departs and the commitment's ownership is unclear for more than 60 days - A benchmark or index we track shows a material regression in the vendor's safety posture **Below the threshold:** log the change in the register, note it at the next scheduled review, no immediate action. ### Worked example **Applied to VendorLM's model-card change:** - Material to procurement: yes (we cited their published safety evals in our own risk assessment). - Change: disclosure reduced from full eval results to a summary. - Threshold met: yes, clause 2 (a disclosure practice we relied on was reduced in scope). - Action: formal re-assessment opened 2026-08-20. ### Acceptance criteria - The triggers are specific enough that two reviewers would agree whether one fired. - The definition is agreed with Legal and applied the same way across vendors. - Sub-threshold changes are still logged, not discarded. --- ## Commitment-change re-assessment template _The record produced when a threshold is crossed, feeding the renewal decision._ ### Template > One to two pages. Links to the contract renewal decision. - **Vendor and commitment affected:** - **What changed, with a source and date:** - **Which of our uses relied on this commitment:** - **Impact on our risk position:** what protection or assurance we have lost - **Options:** accept with monitoring / seek contractual replacement / add compensating controls / reduce reliance / exit - **Recommendation and rationale:** - **Contract implications:** clauses to add at renewal, or grounds to renegotiate - **Decision, decision owner, and date:** - **Follow-up actions with owners and dates:** ### Worked example - **Vendor / commitment:** VendorLM, published model-card safety eval results - **What changed:** last two releases shipped with summary-only safety sections (blog, 2026-08-12) - **Our reliance:** we cited their eval disclosures in the fraud-scoring risk assessment and in a customer trust doc - **Impact:** we can no longer independently sanity-check their safety evals; our own documentation now overstates the assurance - **Options considered:** accept with monitoring; require eval detail under NDA; add our own pre-production testing - **Recommendation:** require eval detail under NDA at renewal, and add a lightweight internal eval now - **Contract implications:** add a disclosure clause (eval methodology + results under NDA) to the renewal - **Decision:** approved by Head of Vendor Risk, 2026-08-27 - **Follow-up:** internal eval stood up (MLOps, 2026-09-20); renewal redline drafted (Legal, 2026-10-01); trust doc corrected (Comms, 2026-09-05) ### Acceptance criteria - The re-assessment states concretely what assurance was lost, not just that a change occurred. - It lists real options and a recommendation, not only a description. - The outcome connects to the contract renewal decision and has follow-up actions with owners. --- ## Governance controls this kit produces evidence for - **PRC-006**: The register and its verification dates are the vendor safety commitment verification record. - **PRC-007**: The monitoring configuration is the vendor governance-change monitoring setup. - **PRC-012**: Tracking a safety index or benchmark per vendor implements safety-index and benchmark monitoring. - **PRC-008**: The re-assessment template handles vendor disclosure changes that warrant re-assessment. - **PRC-002**: The "contract implications" section drives commitment-notification and disclosure clauses into renewals.