Make AI Safety Notices Reach the Business

On 7 October, US Senator Maria Cantwell published a frontier-AI governance framework calling for prompt reporting of material safety and security incidents, alongside independent testing and risk disclosure. It is a policy proposal, not an enacted reporting duty. Its significance for buyers is the attention to continuing oversight after development, not a new compliance deadline. ¹

The EU position is different. The AI Act requires providers of general-purpose models with systemic risk to track, document and report serious incidents to the AI Office and, where appropriate, national authorities. General-purpose-model obligations began applying on 2 August 2025; models placed on the market before that date have a transition until 2 August 2027. Commission enforcement powers began on 2 August 2026. ²

Those duties do not make every enterprise AI buyer a systemic-risk model provider. Nor should a buyer treat a report to the AI Office as evidence that its own response team has been notified. The Commission’s explanatory guidelines are not themselves binding law; the underlying Act is. Assess the provider, model and market-entry date before asserting a current obligation. ²

Singapore’s Model AI Governance Framework for Generative AI includes incident management and reporting within a wider governance approach. It is a framework, not a universal statutory notification clock. Together, these sources show why a global procurement team needs a legal-status register rather than one undifferentiated list of AI rules. ³

Make notification part of the service discussion. Relevant triggers might include a newly discovered failure of an agreed safeguard, unauthorised actions affecting the service, or a restriction that changes which work the supplier considers safe. These are suggested contract topics, not a claim that every such event meets a legal definition of a serious incident.

Ask for the affected product and version, the known exposure window, the kinds of use that may be affected, immediate protective steps and a contact for follow-up. Require uncertainty to be stated. An early notice that clearly separates established facts from open questions can be more useful than a polished account delivered after your team has continued the exposed work.

Balance speed against false alarms. An unverified research finding need not trigger the same response as confirmed customer exposure. Agree severity levels and update expectations with legal, security and operating teams. Do not invent a single global deadline: the contract must support applicable duties without confusing them with the business’s preferred response time.

Many organisations buy AI through a software platform or integrator rather than directly from a model developer. Ask each intermediary how an upstream warning becomes a customer-specific notice. A supplier can receive important information without knowing which of your workflows depend on the affected component. Your inventory must supply that missing connection.

Name an operational recipient as well as a legal contact. The person receiving a notice needs an alternate, access to the dependency record and a route to someone authorised to pause the relevant work. Sending an email to an account owner who has left the business is not an operating control.

Use a tabletop exercise with a clearly labelled fictional notice. Trace it from the supplier contact to the affected service owner, check what can be stopped and identify the information needed to resume. Record delays and unresolved ownership. Do not test by creating a real external incident.

Research in arXiv’s 7 October release illustrates why reporting depends on detection. A new preprint on agent-trace auditing reduces audit effort on OpenAgentSafety but reports lower detection than auditing every action: 72.8% versus 81.5%. These are benchmark results, not enterprise incident rates. Neither configuration finds everything. A supplier’s lack of reported incidents is therefore not, by itself, proof of safety. ⁴

Existing data-protection duties also remain relevant. The UK ICO says a processor must notify its controller of a personal-data breach without undue delay; a controller must report a notifiable breach within 72 hours of awareness. These are scoped data-breach rules, not a deadline for every AI error. A supplier notice must help the responsible organisation assess its own obligations. ⁵

For operations across Latin America, Africa, the Middle East and Asia-Pacific, do not import the EU or UK rule as a regional default. Identify the applicable privacy, cyber and sector regimes locally. This brief has not established an exhaustive country-by-country legal map. The shared operating method can travel; the legal thresholds and recipients cannot simply be copied.

Practical delivery also matters across borders. A notice in an unread language, through an unreliable portal or outside the only staffed support window may not reach the decision-maker promptly. Check the actual customer support arrangements and institutional capacity rather than assume that a global supplier provides identical response coverage everywhere.

Choose one AI service whose failure would interrupt consequential work. Ask procurement to document its safety-notification terms, security to test the route and the process owner to identify the decision that follows. Keep regulatory reporting, customer communication and internal response as separate responsibilities connected by explicit hand-offs.

If the supplier cannot explain what customers would learn, record that as a dependency risk before expanding use. The answer may be tighter permissions, additional monitoring or a narrower deployment—not necessarily rejection. The board needs to know whether the business can act on new safety information, not merely whether someone promises to file a report.