AI-SPM for EU AI Act compliance

Most teams we talk to are not unsure whether the EU AI Act applies to them. They are unsure what it actually asks them to do. The text is written for a regulator, not an engineer, and the gap between Article 15 saying a high-risk system must achieve an appropriate level of cybersecurity and robustness and a concrete task on a Jira board is wide.

Here is the translation we use. Article 9 wants a risk-management system that runs continuously, not a one-time assessment. Article 15 wants demonstrated resilience against the attacks that are specific to AI - the document spells out data poisoning, model evasion, and adversarial examples by name. Article 12 wants records that the system kept logs of what it did. Article 72 wants post-market monitoring, which in plain terms means you keep testing after launch, not just before it. For an LLM application, all four of those point at the same missing artefact: a recurring, documented record of adversarial testing against the live system, mapped to the articles, that you can hand to an auditor without a week of manual translation.

The deadline does not move, and a generic security programme does not produce that artefact. Pen-test reports are dated and prose. Cloud-posture scans do not test model behaviour. Something has to test the AI, on a schedule, and write the evidence in the auditor's language.

That artefact is exactly what an AI-SPM programme produces, and it is worth being concrete about how the pieces line up with the articles rather than waving at compliance.

Scheduled adversarial scans against your live endpoints are the Article 9 risk-management loop and the Article 72 post-market monitoring obligation - the same mechanism satisfies both because both ask for the same thing, a recurring process rather than a snapshot. The probe families covering prompt injection, data poisoning, and model evasion are the direct response to the threats Article 15 names. Every finding is tagged at the article level when it is created, so the evidence is already in the auditor's structure - no analyst sitting down to map a finding list onto a control list the week before the audit. The append-only audit log and configurable retention answer the Article 12 record-keeping requirement, and the PDF and JSON exports are formatted for the Annex IV technical documentation file.

We will be straight about scope: this is the security and robustness slice of the Act, plus the risk-management and record-keeping machinery around it. It does not write your conformity assessment or your fundamental-rights impact assessment for you. What it does is make sure that when those documents reference your testing and monitoring, there is real, dated, control-mapped evidence behind the reference instead of a promise.

A single prompt-injection finding against an internal copilot lands in your evidence file already tagged to Article 15(4) cybersecurity, Article 9(2)(a) risk management, and Article 12(1) record-keeping - three obligations, one row, no manual translation. That is the shape of evidence the August 2026 deadline asks for.