TL;DR: Spain’s AESIA guidance turns EU AI Act compliance into an evidence problem: high-risk AI providers must show continuous risk control, logging, robustness, and human oversight, and AccuKnox frames runtime prompt firewalls plus red teaming as the mechanism that produces that proof. For practitioners, the shift is from policy statements to enforceable controls with audit trails.
Editorial analysis by NHI Mgmt Group, based on content published by AccuKnox: “Spain’s AI Act Asks for Evidence, Not Intentions. How to Prove Runtime Evidence for AESIA”.
By the numbers:
- AESIA published 16 practical guides in December 2025, including 13 on technical requirements and a per-obligation checklist for providers and deployers of high-risk AI systems.
- The EU AI Act requires high-risk providers, under Articles 8 to 17, to run a lifecycle risk-management system, automatically log events, and design for accuracy, robustness, and cybersecurity.
- Annex III high-risk obligations apply 24 months after entry into force, while prohibited-practice rules applied at six months.
Key questions
Q: How should security teams prove that a high-risk AI system is actually controlled at runtime?
A: They should produce evidence from the live control path, not rely on policy documents.
Q: Why do static AI policies fall short for EU AI Act compliance?
A: Static policies describe intent, but they do not prove that risks are controlled continuously.
Q: What are the signs that an AI governance control is not producing usable evidence?
A: The main warning signs are manual log reconstruction, missing refusal records, unclear escalation paths, and a gap between what the policy says and what the system actually allowed.
Practitioner guidance
- Implement inline runtime enforcement Place a policy enforcement layer between users, applications, and the model so prompts, responses, and blocks are controlled at execution time.
- Build an auditable decision trail Log every prompt, response, refusal, and block in a format that can support regulatory review and internal assurance.
- Tie red teaming to change control Repeat adversarial testing whenever prompts, models, or deployment context change so the test evidence stays current.
Bottom line: Spain’s AESIA guidance makes high-risk AI compliance a runtime evidence problem, because supervisors will expect proof that controls operated continuously.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Runtime evidence is becoming the new compliance boundary for AI governance. The EU AI Act and AESIA guidance both push high-risk AI programmes away from static documentation and toward continuously enforced controls. That changes the governance burden from proving intent to proving operation. For practitioners, the control is only real if it creates evidence as it acts.
A few things that frame the scale:
- DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Which matters more for regulated AI: red teaming or runtime enforcement?
A: They serve different purposes, but runtime enforcement is what carries the day in production because it prevents unsafe behaviour and creates the audit trail. Red teaming is still essential because it reveals how the system fails, but those findings only matter if they are translated into enforced controls and repeatable evidence.
👉 Read our full editorial: Runtime evidence for Spain’s AI Act: what AESIA guidance changes