In late September 2026, OpenAI chief executive Sam Altman told the UN Security Council that the world needs shared AI safety standards: common ways to measure capability, assess risk, report incidents and share vulnerabilities between governments and infrastructure operators. He also warned about keeping powerful systems under human control and about power concentrating in too few hands.
Those are reasonable concerns raised at an appropriate forum, and this post takes no side on the geopolitics. The question for an Australian business is narrower and more practical. When you are about to trust a vendor with customer records and agentic workflows, what kind of safety communication actually helps you decide?
Does a call for AI safety standards tell you how safe a vendor is?
No. A call for industry standards describes what the speaker thinks every lab should do. It does not show what the speaker's own company already does, how it measures that, or what happened when something went wrong. For procurement, a buyer needs evidence about one vendor's practice that can be read, checked and written into a contract.
That is the useful contrast between the two labs. Altman's remarks were a policy statement about the industry. Anthropic's public safety case for Claude runs mostly through documents about its own behaviour: Constitutional AI, a published Responsible Scaling Policy, model cards for each release, safeguard updates disclosed as they ship, and two Claude safety incidents it published in full this year. We covered those incident reports in Claude's safety incident reports as a vendor trust signal.
Neither form of communication is wrong. Industry standards matter, and a lab arguing for them in public is a good thing. They just answer a different question from the one sitting on your risk register.
Two kinds of safety communication
It helps to sort what a vendor says about safety into two buckets before you read any of it closely.
Statements of principle.
Disclosures of practice.
Contract terms.
A strong vendor file has all three. A thin one leans on the first bucket. The test is simple: for each safety claim, ask whether you could point to a document that would show the vendor broke it.
| Signal | Example | Can you verify it? | Use in procurement |
|---|---|---|---|
| Public speech | UN Security Council remarks | No | Context only |
| Published scaling policy | Anthropic Responsible Scaling Policy | Partly, against later releases | Reference in security review |
| Model card | Per-release Claude model cards | Yes, per model version | Attach to risk assessment |
| Incident disclosure | Two published Claude incidents in 2026 | Yes, after the fact | Check vendor's response quality |
| Contract clause | Data retention and no-training terms | Yes, enforceable | Primary control |
What this means for an Australian risk assessment
Australian buyers already have a framework that rewards evidence over intent. The Voluntary AI Safety Standard asks organisations to document how they assess and monitor AI systems, and the Privacy Act reforms push the same direction for personal information. APRA-regulated entities face CPS 230 operational risk expectations for material service providers. None of those obligations can be met with a vendor's speech. All of them can draw on a vendor's published policies and model cards.
In practice, a mid-market firm in Sydney or Melbourne rolling out Claude to 80 staff might spend 15 to 25 hours on the vendor safety section of its risk assessment. At an illustrative blended rate of $180 an hour, that is $2,700 to $4,500 of internal time. Most of it goes on finding and reading documents. A vendor that publishes its practice in inspectable form makes that work faster and the conclusions firmer.
A short checklist for the security review
List every safety claim the vendor makes in its sales material and mark each as principle, practice or contract.
For each practice claim, save the source document and its date as at the review.
Ask how the vendor discloses incidents, and read at least one past disclosure.
Confirm which commitments appear in the contract, not just on the website.
Set a review date, because policies and model cards change with each release.
What not to conclude
This is not an argument that OpenAI's products are unsafe or that Anthropic's are perfect. Both labs publish technical material, and both have had problems. A speech at the UN says nothing negative about OpenAI's internal practice; it simply is not evidence either way. The point is to weigh each document by what it can prove.
It is also not a reason to skip your own testing. Published policies tell you how a vendor intends to behave. Your own pilot, logging and access controls tell you how the tool behaves in your environment. Our earlier comparison of Claude's safety model and OpenAI's governance framework and the note on independent safety audits cover where outside evaluation fits.
If you are building the vendor section of an AI risk assessment and want a second pair of eyes, our Claude rollout services include a procurement review, or you can book a call to talk it through.
