A vendor assurance pack is not evidence that an AI service is safe in your environment.
Boards and executives need proof that the provider’s controls match the organisation’s data, decision, integration and resilience risks—and a way to detect when those conditions change.
The 30-second take
Third-party AI can accelerate delivery, but it also hides dependencies on external models, data, hosting, subprocessors and update practices.
A certification or policy statement may be useful background; it does not demonstrate that the control works for your use case.
Classify vendors by impact, define evidence before procurement, test the highest-risk claims independently and monitor material changes throughout the relationship.
The organisation remains accountable for the outcome.
Australian cyber guidance treats assurance as recurring
The Australian Signals Directorate’s Australian Cyber Security Centre published updated procurement and outsourcing guidance on 9 June 2026. It says managed service providers should undergo regular security assessments, with later assessments focused on new services and material security-related changes.
That is a useful model for AI vendors because their services rarely stand still. Providers change models, hosting arrangements, features, data flows and subprocessors. An assurance review completed at onboarding can become stale while the contract remains unchanged.
In October 2025, the ACSC also highlighted AI and machine-learning supply-chain risks for organisations developing or procuring AI systems. The practical implication is that the dependency map must include the components behind the named vendor, not just the company on the invoice.
OAIC puts due diligence on the customer organisation
The OAIC’s guidance on commercially available AI products states that organisations choosing an AI product must conduct due diligence and identify potential privacy risks.
That means mapping which personal information enters the service, where it is processed, whether it is retained or used for model training, who can access it, which subprocessors are involved and how individuals’ rights will be supported. A vendor’s generic privacy statement does not answer those questions for a specific implementation.
Privacy evidence should also connect to technical configuration. Contract terms may promise restricted use while a default account setting permits broader retention. The organisation needs evidence that the agreed control is configured, operating and monitored.
Build an evidence hierarchy
Start with claims, then ask what would prove them. A statement that data is encrypted should lead to architecture, key-management and configuration evidence. A promise of isolation should lead to tenant-boundary testing. A commitment to notify incidents should lead to timeframes, escalation contacts and exercised response procedures.
Independent reports and certifications can reduce duplicated work, but only within their scope and period. Record which services, locations, control objectives and exceptions they cover. Anything outside that boundary still needs evidence.
For high-impact uses, test more than the security layer. Require model-performance evidence relevant to the affected population, known limitations, human-oversight design, change controls, fallback arrangements and the ability to investigate an adverse outcome.
Our AI Signal BoxTM provides organisations a mechanism to register, track and evaluate vendors for their AI usage and controls, and start the evidence gathering activities.
Make change notification a control
Contracts should define material changes: a new foundation model, hosting region, subprocessor, training-data practice, autonomous capability, safety control or end-of-life decision. The provider should notify the organisation early enough to reassess before exposure changes.
Internally, one owner must receive the notice, assess its significance and decide whether use continues. A mailbox is not an owner. Evidence expiry, overdue actions and unresolved exceptions should be visible alongside operational incidents and service performance.
Questions for your third-party AI controls
- Can we identify every material model, data, hosting and subprocessor dependency behind the vendor service?
- Does each important vendor claim have evidence that is current, scoped and relevant to our configuration?
- Which privacy, security and model-governance controls have we independently tested rather than accepted?
- Do contracts define material AI changes, notification timeframes, audit rights and exit support?
- Who decides whether the service continues when evidence expires, an exception remains open or the vendor changes a component?
Turn promises into proof
Third-party AI risk management is not about distrusting vendors. It is about converting promises into evidence the organisation can rely on and challenge. Visit the Innovation of Risk Reading Room to test your vendor-assurance controls and take a readiness snapshot.