OpenAI announced GPT-Red on 15 July 2026, an automated red-teaming model built to probe its own systems for weaknesses before wider release. The claim comes from OpenAI's own announcement; openai.com blocks most scraping tools, so treat the specifics as company-reported until independently confirmed. The pitch is a self-improving safety loop: one model attacks another in a repeating cycle, catching problems faster than a human red team working alone.
That's a reasonable engineering idea. It's also a vendor safety claim, and vendor safety claims are exactly what Australian businesses should learn to interrogate rather than accept at face value, whichever AI provider is making them. A press release is marketing copy. A due diligence file needs something sturdier.
This isn't only a big-end-of-town problem. A ten-person Sydney business handing customer records to an AI tool carries the same Privacy Act obligations as a national retailer, just without a compliance team to catch the gap. Vendor safety claims deserve the same scrutiny at that scale, not less.
The procurement questions worth asking any AI vendor
Most AU businesses evaluating an AI vendor, Claude included, aren't equipped to audit a model's internals, and they don't need to be. What they can do is ask sharper questions before signing. A business bound by the Privacy Act 1988, or an APRA-regulated entity running a vendor risk assessment under CPS 234, needs answers that hold up in a compliance file, not a headline.
Is safety testing independently verified, or only self-reported by the company that built the model?
Does the vendor publish a model or system card describing known limitations, not just capabilities?
What is the vendor's process for disclosing a discovered vulnerability, and how fast do fixes reach production?
Where is customer data actually processed, and does that match what the contract says?
Claude's answer to the first two questions is public record. Anthropic publishes system cards alongside major Claude releases and runs external safety testing as part of its Responsible Scaling Policy, documentation an AU compliance team can cite directly in a vendor register rather than take on faith. That's a different kind of claim to "our AI tests itself," and the difference is worth understanding before either version ends up in a board paper. It's also worth being precise about what Anthropic doesn't claim, because a credible vendor names its own gaps rather than letting a prospect find them later: no IRAP assessment of its own systems, no direct AU data residency outside cloud-partner regions like AWS or Google Cloud, and no public commitment that logs are automatically stripped of personal information before a human reviewer ever sees them. A vendor willing to say what it doesn't do yet is usually more trustworthy than one that only talks about what it does.
What a credible answer actually looks like
A publicly available system card or model card, not just a product page
A named external testing partner or a disclosed testing program, not purely in-house claims
A plain description of where data processing actually happens, matched against the contract
A track record of disclosing past issues, not just a policy promise
None of this makes automated red-teaming a bad idea. Catching a vulnerability with a model is faster than waiting on a manual review, and a manual red-teaming engagement for a mid-sized deployment can run past $40,000 in specialist consulting fees. The concern is narrower: a vendor grading its own homework isn't the same as a vendor whose homework gets checked by someone else, and a due diligence file should show which one you're dealing with.
The AU compliance angle most vendors skip past
Under the Privacy Act 1988, an AU business stays responsible for personal information it hands to a vendor, including an AI vendor processing customer data on its behalf. Australian Privacy Principle 8 specifically covers cross-border disclosure: before sending personal information to an overseas recipient, a business needs to take reasonable steps to ensure that recipient won't breach the Privacy Principles, which is exactly the "where is data actually processed" question from the checklist above, not a hypothetical one. The Notifiable Data Breaches scheme then requires notification as soon as practicable once a business becomes aware of an eligible breach, not on a fixed 72-hour clock like the EU's GDPR. That timing pressure makes a vendor's disclosure practices a genuine operational question, not a box-ticking one: a vendor that's slow to disclose its own incidents puts your notification clock at risk too. For APRA-regulated entities, CPS 234 already requires documented vendor security assessments before onboarding a new information asset provider, and an AI model counts as one. Treating a chatbot rollout as exempt from the scrutiny applied to a payments processor is usually where the gap starts.
Building this into a Claude rollout
In practice, this is a short document, not a full security audit. Before signing with any AI vendor: ask the four questions above in writing, request the system card or nearest equivalent, confirm where data is actually processed against the contract's wording rather than the sales deck, and file the answers somewhere your next audit or insurer can find them. Revisit it at renewal, because vendor practices change faster than contracts do, and a system card from eighteen months ago may already be out of date.
None of this is a reason to avoid AI vendors, Claude included. It's a reason to ask for paperwork instead of press releases before rolling one out across a Sydney, Melbourne, or Brisbane team. Automata AI helps Australian businesses build exactly this kind of vendor due diligence into a Claude rollout, from the first procurement conversation through to what actually goes in the compliance file. If that would save you a few hours next time a vendor announces a new safety feature, book a time to talk it through.
