The EU AI Act has been law since August 2024. The grace periods are expiring. For operators of high-risk AI systems — those used in hiring, credit scoring, biometric identification, critical infrastructure, law enforcement, and a growing list of regulated domains — the compliance clock is no longer theoretical.

What does enforceable compliance actually require? We have mapped the Act's high-risk system obligations against ARMS and AISC to give practitioners a concrete starting point.

The Four Obligations That Matter Most

Risk management system (Article 9). Operators must establish, implement, document, and maintain a risk management system throughout the AI system lifecycle. ARMS was designed precisely for this — its measurement methodology covers identification, likelihood, impact, and control effectiveness across the full system lifecycle.

Technical documentation (Article 11). A documented description of the system, its intended purpose, training data, performance metrics, and known limitations must be maintained and available to authorities on request. AISC's evidence pack templates cover the majority of this requirement as a byproduct of normal control implementation.

Transparency and logging (Article 12). High-risk systems must be designed to allow automatic logging of events throughout operation. This maps directly to AISC Control Domain 6 (Monitoring & Observability), which specifies logging requirements for AI system decisions, inputs, and anomalies.

Human oversight (Article 14). Operators must implement measures enabling human oversight — the ability to understand, monitor, and intervene in AI system operation. AISC Control Domain 7 covers human-in-the-loop requirements and override mechanism specifications.

What Is Not Covered by Existing Frameworks

The AI Act introduces conformity assessment obligations that go beyond what most security frameworks address. Registration in the EU database, CE marking for certain system categories, and post-market monitoring plans are regulatory requirements with no direct equivalent in ARMS or AISC. Organizations will need legal counsel alongside technical controls.

The Practical Next Step

Start with an AI system inventory mapped against the high-risk classification criteria in Annex III of the Act. For each system that qualifies, run an ARMS assessment to establish your baseline risk posture, then gap-analyze against the AISC controls relevant to your system type. The documentation produced by that process will cover roughly 60-70% of what Article 11 requires.

The AI Act is not going away and the enforcement mechanisms are real. Getting structured now is significantly cheaper than getting audited unprepared.

Retrieval-Augmented Generation was supposed to solve the hallucination problem. Feed the model verified documents, ground its outputs in facts — clean, simple, controllable. What the architecture diagrams failed to show is that every retrieved chunk is also a potential attack vector.

Over the past quarter, AISAIC has tracked fourteen publicly disclosed incidents involving prompt injection through RAG pipelines. The pattern is consistent: an attacker plants adversarial instructions inside a document or web page that the retrieval system indexes. When a user queries the system, the malicious content is retrieved alongside legitimate context and passed directly to the LLM — which dutifully executes the embedded instructions.

Three Attack Patterns We're Seeing

Indirect injection via poisoned documents. Attackers upload or publish documents containing hidden instructions formatted to blend with legitimate content. Vector similarity search retrieves them as relevant, and the LLM processes them without distinction.

Cross-user context leakage. In multi-tenant RAG deployments with inadequate namespace isolation, retrieved context from one user's data can surface in another user's response — with or without adversarial intent.

Exfiltration via retrieval manipulation. Crafted queries designed to retrieve sensitive documents, combined with output formatting instructions embedded in poisoned chunks, have been used to extract confidential data from enterprise knowledge bases.

What AISC Says About This

AISC Control Domain 4 (Input & Output Integrity) addresses precisely this threat surface. Specifically, controls 4.3 through 4.7 cover retrieved context validation, output filtering, and cross-session isolation requirements. Organizations running RAG systems without these controls implemented should treat the gap as high severity.

What You Can Do Now

Implement content provenance tracking so every retrieved chunk carries metadata about its source and ingestion timestamp. Apply output schema validation before surfacing LLM responses to users. Enforce strict namespace isolation in multi-tenant deployments. And critically — red team your retrieval pipeline, not just your prompts.

The good news: these attacks are detectable and mitigable with the right controls in place. The bad news: most RAG deployments were built without threat modeling the retrieval layer at all.