The EU AI Act's high-risk-systems provisions came into enforcement in 2026. Vendors of AI systems used in cybersecurity are squarely in scope, and the documentation obligations have teeth. Article 15 on accuracy, robustness, and cybersecurity requires measurable claims backed by documented methodology. Article 12 on logging requires traceability sufficient to investigate incidents. Annex IV requires technical documentation that a reasonable assessor can verify. Griffin AI's architecture produces this documentation as a byproduct of normal operation. Mythos-class general-purpose AI-for-security tools that leaned on black-box model access are scrambling to retrofit it.
What the Act actually requires of AI security vendors
Four concrete obligations:
- Risk management system (Article 9). Documented risk identification and mitigation across the lifecycle.
- Data governance (Article 10). Training data provenance, quality controls, representativeness documentation.
- Technical documentation (Article 11 + Annex IV). Architecture, training methodology, evaluation approach, expected limitations.
- Logging and traceability (Article 12). Automatic recording of operation to support investigation.
- Accuracy, robustness, cybersecurity (Article 15). Measurable performance claims, robustness testing, security controls.
Each obligation can be met. Each requires structural capability that cannot be added after the fact cheaply.
Where Griffin AI's architecture meets the bar
Three direct mappings:
Documented methodology from the eval harness. The five-family eval program (exploit hypothesis, remediation correctness, advisory summarisation, cross-finding correlation, adversarial resistance) is the documentation Article 15 asks for. Methodology, datasets, scoring, and confidence intervals are published. Assessors can reproduce.
Logging built into the engine. Every finding, every Griffin reasoning step, every tool invocation, every policy evaluation is logged with timestamp, input hash, output, and decision rationale. Article 12 traceability is a query, not a retrofit.
Training provenance inherited from the frontier model. Griffin AI uses Anthropic's Claude models; Anthropic publishes model cards and training-data documentation to the extent the frontier industry does. Griffin adds the layer-above documentation — prompt scaffolding, eval harness, grounding architecture — that completes the provenance chain.
Where Mythos-class tools struggle
Three common gaps:
Evaluation methodology gap. Pure-LLM tools often have marketing-grade performance claims without underlying methodology. Satisfying Article 15's measurable-claim obligation requires retrofitting an eval program, which takes months.
Logging gap. Tools built around LLM calls often log at the API-call level without decision rationale. Article 12 traceability requires more than "we called the model and got this output" — it requires reconstruction of why decisions were made.
Data governance gap. Tools that fine-tune on proprietary datasets need to document those datasets per Article 10. Tools that don't fine-tune inherit the provenance of the underlying model; Anthropic, OpenAI, and Google each publish to their own standards.
A concrete compliance audit
A hypothetical EU customer preparing for first-year EU AI Act compliance asks the vendor for:
- Annex IV technical documentation for the deployed system.
- Most recent accuracy benchmarks with methodology.
- Six months of decision logs for a sample of findings in their environment.
- Risk management documentation for the lifecycle.
- Data governance documentation for training and fine-tuning.
Griffin AI produces all five as packaged artifacts from the platform. Mythos-class vendors vary — some produce three or four reasonably well, struggle with the other two.
A procurement question that sorts the field
Ask any AI-for-security vendor: "Show me an EU AI Act Annex IV document for the deployed system as of today."
Vendors that can produce it have done the work. Vendors that cannot are six months behind on regulatory posture.
What customers should evaluate
Three concrete checks:
- Annex IV technical documentation — is it available, and does it reflect the actually-deployed system?
- Eval methodology with published numbers — does the vendor publish and can the customer reproduce?
- Decision logs for a sample of findings — are they detailed enough for investigation?
The answers separate vendors whose compliance posture is production-ready from vendors whose compliance posture is slideware.
How Safeguard Helps
Safeguard's platform produces EU AI Act-aligned documentation as part of normal operation. Annex IV technical documentation, eval methodology with confidence intervals, full decision logging, risk management artifacts, and data governance documentation are all available as exports. Griffin AI's eval harness is the same mechanism that powers Article 15 compliance. For EU customers or vendors selling into the EU, this alignment reduces first-year compliance work from a multi-month project to a packaged deliverable.