Should organisations prioritise compliance mapping or protective testing for multimodal AI first?

Which should come first for multimodal AI, compliance mapping or protective testing?

Protective testing should come first when the system can expose users, data or business processes to immediate harm. Compliance mapping still matters, but documentation alone does not stop prompt injection or leakage. The practical order is to validate behaviour, then generate evidence from controls that are already constraining production risk.

Why protective testing has to lead when the model touches live workflows

Multimodal AI changes the risk profile because the system can interpret text, images, audio or structured inputs and then act on them. That widens the attack surface for prompt injection, data leakage, unsafe tool use and incorrect action, especially when outputs flow into customer support, document handling or internal automation.

Protective testing asks the question compliance mapping cannot answer on its own: what happens when the system is fed hostile, ambiguous or policy-violating inputs? If the answer includes exposure of secrets, private content or operational action, testing is the faster way to discover whether guardrails actually hold under pressure.

Compliance mapping is still necessary, but it belongs in parallel or after the first round of behavioural validation. A mapped control set is only meaningful if the control can be observed in the product path, for example filtering inputs, constraining tool calls, logging sensitive actions or enforcing approval gates before a model can affect a real system.

What compliance mapping is good for, and where it is too weak by itself

Compliance mapping translates a system into obligations, control families and evidence requirements. That helps with governance, audit readiness and deciding which safeguards should exist. It is useful for answering whether the organisation has identified its control surface and whether the right owners are accountable for each risk.

Its limitation is timing. A mapped control can exist on paper while the system still leaks data or follows malicious instructions. For multimodal AI, the difference between "documented" and "effective" is often whether the control is tested against realistic prompts, images, files and workflow abuse before deployment, not whether the policy text is complete.

This is why evidence should be generated from working controls, not from assumptions. In practice, that means test cases, red-team findings and mitigation results should drive the compliance narrative, not the other way around. The Identity Security Regulatory Map is useful when the organisation needs to translate operational controls into regulatory or audit language, but it should reflect controls that are already real.

How to sequence the work so risk falls first and evidence follows

Start with the highest-consequence behaviours: data exposure, unauthorised disclosure, unsafe tool invocation, and any path from model output to business action. Those are the failure modes that determine whether the AI can safely remain in production while the control and compliance work continues.

Then map the controls that actually reduce those behaviours. For multimodal systems, that usually means input filtering, privilege restriction, human review for high-impact actions, audit logging and secrets handling. Once those are in place and tested, compliance mapping becomes a way to organise proof rather than a substitute for protection.

If the model is being prepared for external assurance or regulated deployment, the mapping layer should be attached to evidence from testing, not vice versa. That is where the Agentic AI Compliance Guide helps, because it shows how to connect AI governance requirements to audit evidence once the system is already being constrained.

Risk and Threat Considerations

Multimodal AI can fail in ways that are immediate and material: an image, document or prompt can trigger disclosure, a tool call can execute the wrong action, or a user can smuggle malicious instructions into content the system trusts. Those are operational and security risks, not just compliance gaps.

Failure mechanism: The system is documented as controlled, but protective boundaries have not been tested against real adversarial inputs, so hostile content reaches the model, the model follows it, and the output propagates into data access, external communication or business action.

Impact: Organisations may ship a system that is "mapped" for compliance yet still leaks sensitive material, violates policy, or causes harmful downstream actions before governance evidence can meaningfully reduce the loss.

Practitioner Guidance

What to prioritise: Validate the highest-harm pathways first, especially any prompt, image or document flow that can expose data or trigger a tool action. If a single failure can create real business impact, testing outranks documentation.

What to verify: Confirm that the same control you intend to cite in compliance actually blocks or contains the behaviour under test. If a safeguard is only visible in policy language, treat it as incomplete.

Practitioner takeaway: Use compliance mapping to formalise and evidence the control set, but use protective testing to prove the system is safe enough to trust. In multimodal AI, assurance should follow demonstrated restraint, not precede it.

Related resources from NHI Mgmt Group

• How do organisations decide whether to prioritise AI discovery, data governance, or broader compliance mapping first?
• Should organisations prioritise security analysis or functional testing for AI-generated code first?
• Should organisations prioritise model testing or access governance first for AI security?
• Should organisations prioritise discovery or access restriction first for shadow AI?