Almost every security and IT operations product now claims to use AI. Some of those claims describe mature machine learning that has been in detection engines for years. Some describe a generative AI assistant added to the interface. Some describe features that are still on a roadmap. For a decision owner, the label says very little. What matters is whether a specific AI feature improves a specific outcome in your environment, what data it uses to do so, and what happens when it gets something wrong.
CYBORIUM helps Australian organisations evaluate AI-enabled security and IT tools through a structured vendor-neutral sourcing process. The selected provider pays CYBORIUM a capped fee. The client contracts directly with that provider, and CYBORIUM does not sell, deliver, operate or invoice the technology.
Separate the AI claim from the product
Ask each vendor to list its AI features individually and, for each one, answer four questions: what task it performs, whether it is generally available or in preview, whether it is included in the price or licensed separately, and whether it can be turned off. This removes marketing language from the evaluation and often shows that the features you care about are a small part of the offer.
Then decide how much each feature is worth to you. An assistant that summarises an alert saves analyst time. A model that decides to block a user acts on your environment and carries more risk. The two need different levels of testing and control.
Five areas to test in any AI security tool
1. Measured outcome
Ask for the metric the feature improves, such as detection rate for a defined technique, false positives per day or analyst minutes per case, and how the vendor measured it. Then plan to measure the same thing in your own trial. Customer case studies without a method are not evidence.
2. Data use
Find out what data the feature sends outside your environment, whether prompts and outputs are stored, where processing happens, and whether your data is used to train models that serve other customers. For personal information, the Australian Privacy Principles still apply, including APP 8 on disclosure outside Australia.
3. Error handling and human control
Ask what happens when the model is wrong. Check whether automated actions can require approval, whether decisions are logged with the reasons given, and whether analysts can correct outcomes. If the tool makes decisions that affect individuals, consider the Privacy Act transparency requirements for automated decisions due to start in December 2026.
4. Security of the AI feature itself
AI features add new attack surface, including prompt injection through data the assistant reads, and over-broad access granted to the assistant. Ask how the vendor tests for these and what permissions the feature holds in your environment.
5. Governance fit
If your organisation has adopted ISO/IEC 42001, the NIST AI Risk Management Framework or Australia’s Voluntary AI Safety Standard, check that the vendor can supply the information those frameworks expect, such as model documentation, testing records and a way to raise and track issues.
A comparable evaluation
Test AI features against the same data and tasks for each shortlisted product, with the feature on and off. Measure the difference. For an alert triage assistant, compare analyst time per case and accuracy of the summary. For an AI detection engine, compare true and false positives across a fixed set of scenarios. Score these results alongside written answers on data use, controls, security testing and cost.
Contract points to settle
The agreement should state how customer data is used by AI features, whether it trains shared models, where processing occurs, what logs are retained and how quickly the vendor must tell you about material changes to a model or its data use. Confirm that price and functionality are protected if a feature moves from included to separately licensed during the term.
CYBORIUM’s role in the decision
CYBORIUM can separate and document AI claims, design trials that measure outcomes, coordinate vendors, evaluate evidence and support negotiation of data and model terms. The organisation keeps the decision and contracts directly with the selected provider. For broader AI purchases, see the enterprise AI vendor selection criteria and AI procurement guardrails.
Updated 15 September 2026. This guide explains CYBORIUM’s procurement evaluation method. It does not provide legal or regulatory advice.
Standards and further reading
AI modernisation proposals move faster than the governance around them. Australia has published what good practice looks like, and it is short.
- Voluntary AI Safety Standard. Ten guardrails, each with procurement guidance describing what to establish with a supplier before signature rather than after.
- ISO/IEC 42001:2023. The AI management system standard. Certification is a genuine signal, but read the scope statement: it often excludes the product being sold.
- NIST AI Risk Management Framework. A way to turn a vendor claim about model behaviour into something testable.
Related from CYBORIUM
How do you test an AI security tool before you buy?
Ask for results on your own data, a list of what the tool cannot detect and how it handles its own mistakes. Claims about accuracy mean little without that.
What should an AI security tool vendor tell you about its own models?
What data trained them, how they are updated and what happens to your data. Put the answers in the contract.
Choosing a provider soon? We compare the market so you decide with evidence. Contact CYBORIUM or request a free market briefing.
Last updated:
