International AI incident notification between competing powers isn't just diplomatic theater. It's an operational necessity when your model supply chain, threat intelligence, and incident response plans assume adversaries will keep quiet about what they're seeing.
They won't. And when they do share, you need a framework that turns political signals into technical action.
This template provides a starting structure for bilateral AI incident notification agreements between organizations or governments operating in contested technical spaces. Transparency reduces misunderstanding faster than secrecy prevents exploitation.
Purpose of the Template
You're negotiating an information-sharing arrangement with a counterpart you don't fully trust. Maybe it's a competitor in the same regulatory jurisdiction. Maybe it's a foreign government agency with overlapping AI safety mandates. The goal: establish a mechanism where both sides notify each other about AI incidents that cross a severity threshold before they become crises.
This isn't about sharing proprietary methods or model weights. It's about flagging when something breaks containment in ways that affect shared infrastructure, public safety, or international stability.
The US-China AI Dialogue discussions that Treasury Secretary Scott Bessent described in May 2025 follow this pattern. Representatives from both countries meet to discuss technology, align on common threats, and establish notification protocols for AI incidents threatening national security. As Bessent put it, moving from opacity to transparency between the number one and two AI powers is vital.
Your version might operate at an enterprise scale, but the structural challenges remain identical.
Prerequisites
Before you customize this template, ensure you have:
Defined incident taxonomy. You can't notify about "serious AI incidents" without agreement on what constitutes serious. Map your incidents to MITRE ATLAS tactics or NIST AI RMF risk categories. Your counterpart needs to use the same grid.
Designated notification channels. Who calls whom? This template assumes you've established secure communication paths and verified contact lists. Test them before you need them.
Internal escalation authority. Your notification triggers need to align with your internal incident response plan. If your security team can't notify an external party without three VP approvals, your notification timeline is fiction.
Legal review of information-sharing constraints. Export controls, competition law, and data protection regulations all limit what you can share. Know your boundaries before you draft notification language.
The Template
BILATERAL AI INCIDENT NOTIFICATION FRAMEWORK
1. SCOPE AND PURPOSE
This framework establishes procedures for [PARTY A] and [PARTY B] to notify
each other of AI system incidents that meet severity thresholds defined in
Section 3, with the goal of reducing shared risk and preventing cascading
failures across interconnected systems.
2. NOTIFICATION TRIGGERS
Either party SHALL notify the other within [24/48/72] hours of confirming
an incident that meets ANY of these criteria:
a) Compromise of AI Supply Chain Components
- Unauthorized access to training data repositories used by both parties
- Poisoning attacks on shared foundation models or open-source components
- Backdoor insertion in model artifacts distributed through common channels
b) Capability Surprise Events
- Emergent behaviors in deployed systems that bypass documented safeguards
- Successful adversarial attacks demonstrating novel exploit techniques
- Model-generated outputs that violate safety commitments at scale
c) Cross-Border Impact Incidents
- AI system failures affecting critical infrastructure in multiple jurisdictions
- Autonomous agent behavior creating legal or safety liability across borders
- Data breaches involving training sets with international provenance
d) Coordinated Exploitation Campaigns
- Evidence of systematic probing across multiple organizations' AI systems
- Threat actor activity targeting AI governance or validation processes
- Information operations using AI-generated content at coordinated scale
3. NOTIFICATION CONTENT
Initial notifications SHALL include:
- Incident classification per agreed taxonomy (reference: [MITRE ATLAS /
NIST AI RMF / custom framework])
- Affected system types (do not disclose proprietary architecture details)
- Observed impact scope and severity
- Known or suspected threat actor characteristics (if applicable)
- Recommended defensive measures for similar systems
- Contact information for follow-up technical exchange
Initial notifications SHALL NOT include:
- Model weights, training code, or proprietary algorithms
- Customer or user data subject to data protection regulation
- Information subject to export control restrictions
- Details that would compromise ongoing investigations
4. RESPONSE OBLIGATIONS
The receiving party SHALL:
- Acknowledge receipt within [6/12/24] hours
- Assess applicability to own systems within [48/72] hours
- Share reciprocal threat intelligence if incident affects both parties
- Maintain confidentiality per Section 6
The receiving party MAY:
- Request follow-up technical details through designated channels
- Propose joint investigation or [Responsible Disclosure](/glossary/responsible-disclosure)
- Decline to act if incident falls outside defined scope
5. ESCALATION AND REVIEW
Parties SHALL meet [quarterly/semi-annually] to:
- Review notification effectiveness and response timeliness
- Update incident taxonomy based on emerging threats
- Adjust severity thresholds as AI capabilities evolve
- Discuss common threats and align on safety objectives
Either party may request emergency consultation outside regular schedule
when incident severity warrants immediate coordination.
6. CONFIDENTIALITY AND USE RESTRICTIONS
Information shared under this framework:
- SHALL be used only for defensive and safety purposes
- SHALL NOT be used for competitive advantage or product development
- SHALL be protected at [CLASSIFICATION LEVEL] or equivalent
- MAY be shared with designated third parties only with prior written consent
7. TERMINATION
Either party may terminate this framework with [30/60/90] days written notice.
Confidentiality obligations survive termination for [2/3/5] years.
Customization Guidance
Adjust notification timelines based on your operational reality. If you're a frontier lab with 24/7 security operations, 24-hour notification is achievable. If you're a government agency with weekend gaps, 72 hours might be the honest answer. Don't commit to timelines you can't meet.
Tailor the trigger criteria to your shared risk surface. The template focuses on supply chain, capability surprise, cross-border impact, and coordinated campaigns because those are the categories where bilateral notification adds value. If you're two enterprises in the same vertical, you might care more about adversarial attacks on similar model architectures. If you're two governments, you might prioritize autonomous weapons or critical infrastructure.
Define your incident taxonomy explicitly. The template references MITRE ATLAS and NIST AI RMF, but you need to pick one and map your internal severity levels to it. Without this mapping, "serious incident" means different things to each party and you'll under-notify or over-notify.
Specify your confidentiality tier. "Protected at classification level X" works for government-to-government. For enterprise-to-enterprise, you might reference your standard NDA terms or create a new confidentiality schedule. Be specific about what the receiving party can and cannot do with the information.
Build in regular review cycles. AI capabilities evolve faster than most legal agreements. Your notification triggers in 2025 won't match the threat landscape in 2026. Schedule review meetings and give both parties authority to propose updates without renegotiating the entire framework.
Validation Steps
Before you sign this framework, validate it against real scenarios:
Run a tabletop exercise. Pick three incidents from your last 12 months. Would they have triggered notification under this framework? If not, are your thresholds too high? If yes, would the other party have found the notification useful?
Test your notification channels. Send a test message through your designated secure communication path. Measure response time. If it takes 18 hours to acknowledge a test message, your 24-hour notification commitment is already broken.
Map internal escalation paths. Who has authority to trigger a notification? Walk through your incident response plan and identify the decision point where external notification gets evaluated. If that decision point comes after your notification deadline, restructure your escalation chain.
Review against export control and competition law. Have your legal team confirm that the information you're committing to share doesn't violate trade restrictions or create antitrust exposure. This matters especially for agreements involving Chinese counterparts, where US export controls on AI technology continue to evolve.
Confirm reciprocity expectations. Does the other party have equivalent capability to detect and report incidents? If they can't notify you because they lack the monitoring infrastructure, the framework becomes one-way information flow. That might be acceptable, but you should know it going in.
The US-China discussions Bessent described face this challenge at scale. Establishing common goals and threat definitions between countries with different political systems and technological priorities is harder than drafting notification language. Your bilateral agreement will hit similar friction wherever your counterpart's incentives diverge from yours.
The template can't solve trust deficits. But it can convert political willingness into operational process. When both parties decide that transparency reduces risk more than opacity protects advantage, you need something to sign. This gives you the structure to start.
