Why does coverage matter for governance?
A customer-facing assistant receives what customers send: many languages, mixed languages in one message, images, documents and voice. If a control detects a policy breach in English but not in another language, the policy is enforced for some customers and not others. If tests run only on text, evidence covers only part of the risk. Attackers know this and switch language or modality to get past a filter.
What do the six platforms state?
- Alice: the platform page lists coverage in 100+ languages, multimodal support and model-agnostic protection; the home page states 120+ languages. WonderFence lists Multimodal & Multilingual as a feature. These are vendor claims.
- SPLX: the Professional plan lists multimodal voice and image testing. A language count is not stated.
- Credo AI, Holistic AI, Pillar Security and Lasso: language and modality coverage is not described on the pages we read.
On our coverage criterion, Alice leads with 9. It carries 10 of 100 weight points by default; the readiness score doubles it if you tell it your customer-facing AI works in more than one language or modality.
How should you write coverage into policy?
- List the languages and modalities each system accepts, in the register entry.
- State in each policy that it applies to all of them.
- Require test sets in each language and modality before launch.
- Require evidence by language: blocked responses and test results broken down by language.
- Retest when you add a language or modality.
How do you check a vendor's claim?
Ask for test results in your top languages, including at least one with less training data available. Send mixed-language messages and images with embedded text during the proof of concept. Check that the control's decisions and logs record the language detected.
Record the results by language in the proof of concept report, so the vendor's claim and your measurement sit side by side.
What can go wrong without coverage?
- A request refused in one language is answered in another.
- Harmful text inside an image passes a text-only filter.
- A spoken request to a voice assistant is not logged the same way as typed text.
- Test evidence covers only the main language, so a report overstates what was tested.
How does coverage show up in the frameworks?
None of the frameworks on this site sets a language requirement as such. They ask for risk management, testing and monitoring that fit the system's intended use. If a system's intended users write in several languages or send images, testing and controls that cover only one language or modality leave part of that use unassessed. Record the languages and modalities in scope in the register, and make reports state them.
Coverage is also one of the least documented criteria in this lineup: four of the six platforms do not describe language or modality coverage on the pages we read. When vendors add it to their pages, we will update the scores.
Who should own coverage?
Product teams know which languages and modalities users send; security and trust and safety teams know which attacks use them. Put both in the policy review, and make the register entry for each customer-facing system list its languages and modalities, so that test plans and reports start from the same list.