EU AI Act Article 15: the multimodal AI security checklist before 2 August 2026

1. Who needs to comply: is your system "high-risk"?

The EU AI Act uses a layered risk classification. At the top sits the "unacceptable risk" category (banned outright: social scoring, most real-time biometric surveillance). Below that: "high-risk AI systems" defined in Articles 6-7 and Annex III. These are where Article 15 applies. Below that: general-purpose AI systems (GPAI) with their own compliance track. Below that: limited and minimal risk, voluntary compliance only.

Annex III lists the high-risk categories that matter for AI startups:

• Biometric categorisation — systems that classify people based on biometric data into categories (gender, ethnicity, political views, religious beliefs, emotional state). Not just identification; categorisation is high-risk.
• Emotion recognition — systems that infer emotional states from facial expressions, voice, or physiological signals in workplace or educational settings.
• Critical infrastructure management — AI managing water, energy, transport, internet, financial systems.
• Education and vocational training — AI that determines access to or assesses students in educational institutions; automated grading systems.
• Employment screening and HR — AI used to screen CVs, rank candidates, monitor workers, assess performance, make or influence promotion or dismissal decisions.
• Access to essential services — credit scoring, insurance risk assessment, benefit entitlement decisions.
• Law enforcement — AI used to assess the risk of an individual committing a crime or as evidence in criminal proceedings.
• Migration and border management — visa assessment, risk profiling at borders.
• Administration of justice — AI that interprets law, assists adjudication, or makes decisions in judicial proceedings.

One important clarification for startups building on foundation models: GPT-4, Claude, Gemini, and Llama are General-Purpose AI (GPAI) models. Their providers comply under Articles 51-55, which cover model-level transparency, training data documentation, and system-card disclosures. That compliance path does not cover your application. When you deploy a high-risk AI system built on top of a GPAI model, the Article 15 obligations fall on you as the system provider, not on OpenAI or Anthropic. The two compliance tracks are independent.

If your system is not in Annex III, Article 15 does not bind you directly. But if you are selling to EU enterprises, their procurement and legal teams will ask about Article 15 compliance regardless of your formal classification — the questions arrive before the enforcement does.

2. What Article 15 actually requires for cybersecurity

Article 15 has three layers that compound on each other.

Article 15(1) — baseline resilience. High-risk AI systems must be resilient against errors, faults, inconsistencies, and unexpected situations during operation. This is the general robustness obligation; it is modality-agnostic and applies to every input channel.

Article 15(4) — continuous monitoring. The system must incorporate technical solutions that allow continuous monitoring of its operation — specifically its level of accuracy, reliability, and cybersecurity. The monitoring obligation means you need a live signal, not just a pre-deployment test. A per-request scan log with anomaly alerting is the standard implementation of this requirement.

Article 15(5) — AI-specific cybersecurity threats. This is the provision that names the threat classes directly. Technical solutions must address attacks attempting to:

• Manipulate the training dataset (data poisoning) — covered in OWASP LLM03:2025 training data poisoning
• Exploit weaknesses in pre-trained models used as components (supply chain)
• Use adversarial examples or model evasion targeting the AI component
• Poison the model after deployment (model poisoning)
• Extract confidential training data through inference queries

The provision at the centre of the multimodal checklist is the third bullet: adversarial examples or model evasion. That is the legislative description of what FigStep is. It is what AgentTypo is. It is what WhisperInject is. The provision does not say "adversarial text inputs" because it is modality-agnostic by design — the drafters wrote it to cover the AI-specific threat class, not a specific encoding. A conformity assessor reviewing your Article 15(5) evidence for a vision-capable system that has no image-side inspection is looking at an open gap against the named threat class.

3. The multimodal gap that most Article 15 readiness programmes miss

The gap is not exotic or subtle. It is a direct consequence of the way prompt-injection defences evolved: text PI scanners solved the text problem, then ships went to production, then multimodal inputs were added, and the text scanners stayed in place because the assumption was that the threat model was still text-shaped. It is not.

For image inputs, the structural problem is the OCR ceiling. A text PI scanner running on the OCR output of an image is inspecting a derived artefact: the text that a character-recognition engine decided the image contained. FigStep-class adversarial images are specifically designed to produce a clean OCR transcript while delivering a readable instruction to the vision encoder in pixel space. The attack works precisely because OCR is optimised for well-formed text at typical reading sizes and uses character-recognition heuristics that differ from what a neural vision encoder reads from pixel values at the same location. Scanning the OCR output is evidence that the OCR artefact was inspected — it is not evidence that the image bytes the model consumed were inspected. An Article 15(5) conformity assessor asking "what validates your image inputs against adversarial manipulation?" gets a categorically different answer from "we scan the OCR output" versus "we scan the image bytes before the model call."

For audio inputs, the structural problem is the STT ceiling. A text PI scanner running on the speech-to-text transcript is inspecting what the STT decided the audio meant. WhisperInject-class attacks hide payloads in frequency bands the STT is structurally incentivised to discard — ultrasonic carriers, sub-300 Hz modulation, inter-word silence steganography — because STT is a speech-to-text compression system, not a security inspection. The transcript-side scanner is useful for catching jailbreaks that are literally spoken aloud; it does not cover the attack class that lives in the bytes. We built the audio-side argument in detail in building a prompt-injection scanner for voice agents.

For RAG-augmented systems with multimodal corpora: the ingestion-time problem compounds with the inference-time problem. An adversarial image embedded inside a PDF in your knowledge base enters the retrieval corpus, passes text-only document ingestion validators, and delivers its payload to the vision encoder on every subsequent retrieval as trusted retrieved context — stealthy and persistent in a way that a per-request inference-time attack is not. OWASP LLM03:2025 covers this in the RAG corpus poisoning angle; it also maps directly to Article 15(5)'s data poisoning bullet, which means you need pre-ingestion multimodal scanning as well as inference-time scanning if your system uses multimodal RAG.

4. The eight-item pre-August checklist

These are ordered by dependency, not by difficulty. Items 1-2 are paperwork; items 3-7 are controls; item 8 is evidence-generation. All eight are needed before a conformity assessment that reviews Article 15.

1. Confirm whether your system falls under any Annex III category. Document the determination in writing — even if the answer is "no, here is why." The documentation of the determination is itself part of the Annex IV technical documentation requirement. If you are in an ambiguous category (e.g., an HR-adjacent tool that does not make final hiring decisions), document the reasoning for the classification you chose.
2. Enumerate every input modality in your technical documentation. Text fields, image uploads, audio/voice inputs, video streams, file ingestion endpoints that may carry images or audio. List every one. Annex IV Section 1(a) requires a general description of the AI system including its intended purpose; Section 2 requires a detailed description of elements and the development process including training data and inputs. A modality not in the documentation is a gap a conformity assessor will ask about.
3. Map each modality to a validation mechanism. For each modality in your list: what inspection mechanism exists? Text PI scanner covers text. What covers image bytes? What covers audio waveforms? Where the answer is "nothing yet," that is the Article 15(5) remediation list.
4. Verify your text PI scanner produces per-request evidence logs. A risk score returned in an API response is not durable evidence. An immutable append-only log entry with request_id, timestamp, modality, scan_id, risk_score, threshold, and action (allow/quarantine/block) is. Check that your current scanner writes this log, that the log is retained for long enough to cover a post-incident review window, and that it is queryable by request_id. This is also the ISO 27001:2022 A.8.28 input validation evidence and the SOC 2 CC6.6 logical access control evidence — the same log satisfies all three without duplicate instrumentation.
5. Add image-side scanning for every endpoint that accepts image inputs. Place the scan between receipt of the image bytes and any downstream processing (OCR, thumbnail generation, model call). Scan the bytes before the OCR runs, not after. The scan record is your Article 15(5) evidence for image inputs: scan_id, image_hash, risk_score, flagged_region (if any), action. Glyphward's /v1/scan returns this record for every scan. If you scan before OCR and before the model call, the log covers the artefact the model consumed.
6. Add audio-side scanning for every voice input path. Same placement logic: scan the waveform before the STT runs. The scan record is your Article 15(5) evidence for audio inputs: scan_id, waveform_hash, risk_score, flagged_window (timestamp range), action. For audio-LLMs that consume the waveform directly without STT (Gemini Audio, GPT-4o Audio), the waveform-side scanner is the only inspection point you have — there is no transcript stage to fall back on.
7. Configure anomaly alerting on high-risk scan events. Article 15(4) requires continuous monitoring. A scan event with risk_score above threshold is an anomaly signal. Route it to a SIEM or an on-call channel with enough metadata to investigate: request_id, modality, payload_hash, risk_score, flagged_region. The alert record is part of your Article 15(4) monitoring evidence trail. The threshold you set should be documented in your technical documentation — "we alert at risk_score ≥ 70 across all modalities" is a reviewable control statement.
8. Run a tabletop exercise against OWASP LLM Top 10 2025 multimodal vectors. OWASP LLM01:2025 (prompt injection) has documented multimodal attack families: FigStep-class image injection, WhisperInject-class audio injection, indirect injection via retrieved image content. A tabletop exercise that walks through each attack class against your endpoints, with notes on what control was in place and whether it triggered, gives you a pre-conformity-assessment evidence record. It also surfaces anything the checklist items above missed. Document it; a one-page written summary of the exercise scope and findings counts.

5. What audit evidence looks like in practice

EU AI Act conformity assessment for most high-risk categories is internal self-assessment — the provider prepares the Annex IV technical documentation and signs the EU declaration of conformity. A notified body is only required for a narrow set of categories (primarily biometric identification systems and specific law enforcement applications). For the employment, education, and financial-services categories most AI startups encounter, you are doing the assessment yourself.

What a reviewer working through your Annex IV documentation will look for on Article 15(5):

1. A description of each input modality and the cybersecurity control in place for each.
2. The evidence format for each control — what is logged per request, where it is stored, how long it is retained.
3. The threshold contract — at what risk score level does the system quarantine or block? Is that threshold documented?
4. A description of the monitoring mechanism — how are anomaly events detected and surfaced? (Article 15(4))
5. A description of incident response — what happens when a high-risk scan event is triggered?

The minimum viable evidence file per request is a row in an append-only log:

request_id | timestamp | endpoint | modality | payload_hash | scan_id | risk_score | threshold | action

That log, retained for the period the system is in production plus a reasonable post-incident review window (typical legal guidance: 3-5 years for high-risk AI system records, though the EU AI Act does not specify an exact retention period), is the primary Article 15(5) evidence artefact. Everything else in the checklist above is the machinery that produces this log.

One note on the ISO 27001 and SOC 2 intersection: if you are pursuing ISO/IEC 27001:2022 certification alongside EU AI Act compliance — common for European enterprise customers — the A.8.28 (Secure Coding, input validation) evidence record is satisfied by the same scan log. The same log satisfies SOC 2 CC6.6. Instrument once; it counts in three frameworks simultaneously.

6. What happens on and after 2 August 2026

The 2 August 2026 date is set in EU AI Act Article 111(2) — the transitional provision that gives providers of high-risk AI systems that were already placing products on the EU market a 36-month window from the Act's entry into force (1 August 2023) to come into compliance. The date is legislated; it will not be extended by a regulatory announcement. EU Member State Market Surveillance Authorities (MSAs) become competent to enforce Chapter 2 requirements including Article 15 from that date.

The penalty structure for non-compliance with Title III Chapter 2 requirements — which includes Article 15 — is in Article 99(4): up to €15 million or 3% of total worldwide annual turnover, whichever is higher. These are maximum figures; enforcement against smaller providers will likely prioritise documented non-conformities found during conformity assessments and post-incident reviews rather than unprompted audits of all providers on day one. But a provider that has no evidence of cybersecurity controls at all is in a categorically worse position than a provider that has documented controls with known gaps and a remediation timeline.

One practical note for startups raising EU investment or selling into EU enterprise accounts: EU-regulated buyers (banks, insurance, healthcare, utilities) will start requiring Article 15 compliance evidence in vendor procurement questionnaires on or before the deadline. The sales-friction version of non-compliance will arrive sooner than the enforcement version. The checklist above answers both.

7. Five questions to ask your team this week

If you have 63 days and need to prioritise, these five questions scope the work:

1. Have we confirmed in writing whether our system falls under any Annex III category? If the answer is "we think not but have not checked," that is the first task. The determination needs to be documented, not assumed.
2. Do we have a complete list of every input modality our production system accepts? Text, image, audio, video, file uploads — enumerate them. The list of modalities with no inspection mechanism is the Article 15(5) remediation backlog.
3. Does our current text PI scanner write a per-request log entry with the fields above? If you are using a managed scanner, check the dashboard for a downloadable audit log. If you are using an open-source library, check whether it has built-in logging or whether you need to add it.
4. If a conformity assessor asked "what inspects your image inputs for adversarial manipulation?" — what is our answer? "We scan the OCR output" is not the same answer as "we scan the image bytes before the model call and log a scan_id per request." The assessor knows the difference.
5. Has someone been assigned to own the Annex IV technical documentation? The documentation does not write itself, and it is a hard blocker for the EU declaration of conformity. Assign an owner, set a deadline before 2 August.

FAQ

Further reading

• EU AI Act Article 15 — multimodal prompt injection compliance — the detailed compliance reference covering Article 15(5) provisions, the full mapping from adversarial-inputs language to FigStep and WhisperInject attack classes, and the five-step inference-boundary architecture.
• ISO 27001:2022 AI security controls and prompt injection — A.8.28 input validation, A.8.7 malware detection, A.8.16 monitoring, and A.5.7 threat intelligence: how the same scan log satisfies all four controls across image and audio modalities.
• SOC 2 AI security controls and prompt injection — CC6.6 (logical access) and CC7.2 (anomaly monitoring) evidence requirements per modality; the five-step SOC 2 control architecture.
• OWASP LLM01:2025 — prompt injection (multimodal) — the attack taxonomy behind Article 15(5)'s adversarial-examples language, including FigStep-class and indirect injection via image context.
• OWASP LLM03:2025 — training data poisoning (multimodal) — the RAG corpus poisoning vector and fine-tuning poisoning vector; maps to Article 15(5)'s data-poisoning bullet for multimodal RAG systems.
• The multimodal prompt-injection threat model (2026) — the full threat model covering text, image, and audio attack families; the 5-step defender's playbook.
• Building a prompt-injection scanner for voice agents — the engineering argument for why waveform-side scanning is structurally necessary (not additive) when your STT pipeline discards the bands where audio PI lives.
• Glyphward pricing — free tier for evaluation; $29/mo Pro with per-request scan logs, webhook, and SDK; $99/mo Team with SSO and audit log export.