EU AI Act
Cybersecurity Assessment
Signed cybersecurity testing evidence for high-risk AI systems under the EU AI Act (Regulation EU 2024/1689). Eight-phase methodology aligned to Article 9(8) pre-registered metrics, Article 12 logging, Article 15(4) robustness, and the five Article 15(5) cybersecurity threat categories. We produce evidence that supports your internal Annex IV technical documentation — we do not issue compliance or market placement determinations.
Strict Scope. Signed Evidence.
Article 9(8) requires pre-defined metrics. Article 15(5) names five cybersecurity threat categories. Article 12 mandates automatic logging. We test against each, sign the evidence, and stay in our lane on legal determinations.
Who Needs to Comply
The EU AI Act applies to providers, deployers, importers, and distributors — anywhere AI affects EU residents, regardless of where your company is based.
AI Providers & Developers
Any company developing or commercializing an AI system deployed in the EU. You bear full responsibility for conformity assessment, technical documentation, and CE marking. Independent cybersecurity testing evidence supports your Annex IV technical documentation — it does not, on its own, replace your provider's internal compliance assessment.
Enterprises Deploying AI
Organizations using third-party AI tools — for HR, credit decisioning, fraud detection, or customer service — are deployers with their own obligations. You must ensure human oversight, monitor performance, and conduct Fundamental Rights Impact Assessments.
US Companies with EU Customers
Non-EU companies are fully in scope if their AI systems affect EU residents. If you sell AI-powered products or services into the EU — even from Charlotte — you must comply or appoint an EU authorized representative.
GPAI / Foundation Model Providers
General-purpose AI model providers (LLMs, multimodal models) face a separate compliance track. Systemic risk GPAI providers must conduct explicit adversarial red-teaming before and after model release — mandated in Article 55. GPAI red-teaming is a separate service track and is not part of this engagement; contact us for scoping. This page covers Annex III high-risk systems.
Financial Services & Insurance
Credit scoring, fraud detection, insurance risk assessment, and loan underwriting AI are high-risk by default under Annex III. The regulation requires full technical documentation, bias and fairness testing (handled by your counsel and bias-testing specialists), and adversarial robustness testing (our scope).
HR & Recruitment Platforms
Any AI used for candidate screening, CV ranking, psychometric evaluation, or employment decision support is high-risk under Annex III. The regulation requires bias testing across protected characteristics (handled by your counsel and bias-testing specialists) and adversarial robustness testing (our scope).
AI Risk Classification Framework
The EU AI Act places every AI system into one of four risk tiers. Your tier determines your compliance obligations and whether you need security testing.
Prohibited — Banned Now
These systems are completely prohibited since February 2025. No compliance path exists.
- Real-time facial recognition in public spaces
- Social scoring by governments
- Subliminal behavior manipulation
- Predictive policing by profile alone
- Emotion recognition at work/school
Full Compliance Required
Most enterprise AI falls here. Full technical requirements including Article 15 cybersecurity testing apply from August 2026.
- HR/recruitment AI systems
- Credit & insurance scoring
- Law enforcement & border control
- Critical infrastructure management
- Educational assessment systems
Transparency Obligations
Must disclose AI nature to users. Deepfakes must be labeled. Chatbots must identify as AI. Lower compliance burden but obligations still apply.
- Customer service chatbots
- AI-generated synthetic content
- Deepfake video/audio systems
- Recommendation engines (some)
Voluntary Standards
Encouraged but not required to follow voluntary codes of conduct. Most consumer AI falls here with no mandatory compliance requirements.
- AI spam filters
- Basic recommendation algorithms
- AI-powered games
- Inventory management AI
What We Assess
Our cybersecurity assessment covers the testable cybersecurity requirements of the EU AI Act — Article 9(8) pre-registered testing, Article 12 automatic logging, Article 15(4) robustness, and the five Article 15(5) cybersecurity threat categories. Bias, fairness, FRIAs, conformity assessments, and legal interpretations are explicitly out of scope and belong with your qualified counsel.
Phase 2 — Data Poisoning Assessment
Article 15(5)Article 15(5) explicitly names "attempts to manipulate the training dataset." We map ingestion pathways, rate access controls on each, and apply a proprietary injection methodology to verify whether the pipeline's integrity controls perform as expected.
- Training data ingestion pipeline mapping
- Access control rating on each ingestion pathway
- Proprietary injection methodology to verify pipeline integrity
- If you are a pure API wrapper without an owned training pipeline, this phase is scoped to zero hours under the engagement (with a signed justification documenting why) and your fee adjusts accordingly. The assessment focuses on the phases where you actually own the attack surface.
Phase 3 — Model Poisoning / Supply Chain
Article 15(5)Article 15(5) names "pre-trained components used in training." SHA-256 hash verification on imported model weights against authoritative reference hashes, plus a version-pinning audit across the ML dependency graph.
- SHA-256 hash verification on imported model weights
- Comparison against authoritative reference hashes from major model and dependency repositories
- Version pinning audit across ML dependencies
- Pre-trained component inventory and source URL verification
- If your system uses only third-party API calls with no imported model files, this phase is scoped to zero hours (with a signed justification documenting why) and your fee adjusts accordingly.
Phase 4 — Adversarial Examples + OOD
Article 15(5)Article 15(5) names "inputs designed to cause the AI model to make a mistake." Adversarial perturbation campaigns against representative production inputs, with toolchain calibrated to data type. Results are measured against the pre-registered adversarial accuracy threshold.
- Adversarial perturbation campaigns against representative production inputs, with toolchain calibrated to data type (text, vision, tabular)
- Out-of-distribution boundary testing to assess model robustness against unexpected inputs
- Results compared to the pre-registered adversarial accuracy threshold
- Prompt injection (direct and indirect) is not in scope under this engagement; quote separately as a Change Order or see LLM/AI Penetration Testing
Phase 5 — Confidentiality / Membership Inference
Article 15(5)Article 15(5) names confidentiality attacks. We run black-box membership inference attack campaigns against a customer-provided split of in-training and out-of-training records (sample size confirmed at scoping with written split confirmation).
- Black-box membership inference attack campaigns
- Customer-provided in-training / out-of-training record split (sample size confirmed at scoping)
- Training data extraction probes for LLM-based systems
- Advantage score measured against pre-registered threshold
- Model inversion testing is not in scope under this engagement
Phase 6 — Model Flaws & Robustness
Article 15(4)Article 15(4) requires high-risk AI systems to be resilient against errors, faults, and inconsistencies. OOD failure modes from Phase 4 are classified by type, and decision-boundary stability analysis quantifies how much input perturbation is required to flip a prediction.
- OOD failure mode classification
- Decision boundary stability analysis
- Feedback loop adversarial detection (continuously learning systems)
- Edge-case and malformed-input behavior assessment
Phase 7 — Article 12 Logging Verification
Article 12Article 12 mandates automatic logging as a prerequisite under the regulation — not a recommendation. We submit a structured set of mixed inference requests and verify server-side logs against the required fields. Findings are entered into the Finding Register with prioritized remediation guidance; determinations about market placement remain with you and your qualified legal counsel.
- Verification of all required EU AI Act Article 12 logging fields against a structured completeness matrix
- Log immutability and retention period verified
- Absence of any required field is a finding
- Absence of logging entirely is a Critical finding requiring prioritized remediation
Pre-Registered Thresholds
Article 9(8) requires testing against pre-defined metrics. Pass/fail thresholds are documented and countersigned at kickoff — before any testing begins. Thresholds cannot be moved after results are seen. That's the point.
We maintain default thresholds for each Article 15(5) cybersecurity threat category, with elevated thresholds for sensitive verticals — biometric identification, law enforcement, medical, health, and financial systems. Specific threshold values are calibrated to your system's domain and risk tier and confirmed during the scoping call. The pre-registered thresholds for your engagement are recorded in the Metric Pre-Registration Document signed at kickoff.
Our Assessment Process
An eight-phase methodology that produces signed cybersecurity testing evidence aligned to EU AI Act Article 15 and Annex IV documentation requirements. Each phase is tied to a specific article and produces a signed test-log entry. The high-level customer-facing flow is summarized below; the six article-specific testing phases are detailed in the "What We Assess" section above.
Classify
Inventory your AI systems and map each to the correct Annex III risk category. Identify provider vs. deployer obligations. Identify which conformity assessment pathway applies under Article 43 (provider's responsibility — informational only).
Gap Analysis
Evaluate current technical controls against the testable cybersecurity requirements in Articles 9(8), 12, 15(4), and 15(5). Identify security testing gaps, missing logging fields, and untested attack surfaces.
Technical Testing
Execute Phases 2-7 sequentially against the dedicated staging environment: data poisoning, model poisoning, adversarial examples and OOD, confidentiality / membership inference, model robustness, and Article 12 logging verification. Each phase produces a signed test-log entry tied to the pre-registered threshold.
Evidence Package
Compile test results, findings, and remediation evidence into the Annex IV-aligned cybersecurity documentation support package — designed to drop into your broader internal Annex IV technical documentation effort, not to replace it.
Report & Roadmap
Deliver the Annex IV-aligned cybersecurity documentation support package, the technical testing report, and a prioritized remediation roadmap sequenced to address identified security testing gaps before your applicable deadline.
What You'll Receive
Every engagement produces a signed Annex IV-aligned cybersecurity documentation support package — designed to support your internal Annex IV technical documentation effort and to be useful to your engineering and legal teams.
Article 15 Technical Testing Report
A full adversarial security assessment report documenting every attack technique executed, vulnerabilities discovered, exploitability ratings, and prioritized remediation guidance. Written to align directly with Article 15 language so the customer's compliance and legal teams can drop the technical evidence into their broader Annex IV technical documentation.
Annex IV-Aligned Cybersecurity Documentation Support Package
A signed, dated documentation package structured to support Annex IV §2(g) and §2(h) requirements. Includes: (1) security assessment summary, (2) testing records and assessment log, (3) findings register with risk ratings, (4) description of identified cybersecurity weaknesses and observed failure modes, (5) remediation recommendations and prioritization guidance, and (6) supporting cybersecurity assessment evidence aligned to scope. Supports — does not replace — your internal Annex IV technical documentation effort.
Signed Metric Pre-Registration Document
Signed by Voke Cyber and countersigned by the customer at kickoff, before any Phase 2-7 testing begins. Records the thresholds agreed for the engagement. Shared with the customer as a record outside the support package; we make no representation that this document satisfies Article 9(8) or any other regulatory obligation. Whether and how the customer uses this record in their internal Annex IV process is the customer's decision, made with their counsel.
Article-Mapped Finding Register
Every finding cited to its specific EU AI Act article (15(5), 15(4), or 12), with CVSS score, exploitability rating, and remediation guidance written for the engineer who has to implement the fix. Risk-tiered per Article 9(5) so the customer's prioritization roadmap drops in cleanly.
Direct Engineer Access
Every EU AI Act engagement includes direct access to the engineers who performed the testing — not a project manager. Ask technical questions, get clarification on findings, and work through remediation decisions without intermediaries for the duration of the engagement.
The Cost of Non-Compliance
EU AI Act fines exceed GDPR at the highest tier. The business case for compliance investment is straightforward.
Prohibited AI Violations
Using banned AI systems (social scoring, real-time facial recognition in public spaces, subliminal manipulation). This tier exceeds GDPR's 4% maximum. Enforcement began February 2025.
High-Risk System Violations
Failing to meet conformity assessment, technical documentation, or Article 15 cybersecurity requirements for high-risk AI systems. The primary compliance risk for most enterprises after August 2026.
Incorrect Information Supplied
Providing false, incomplete, or misleading information to national market surveillance authorities or the EU AI Office. Beyond fines, enforcement also includes market withdrawal, product recall, and suspension of EU market access.
EU AI Act Cybersecurity Assessment — FAQ
Answers to the questions we hear most from AI providers, enterprise deployers, and US companies preparing for the August 2 2026 deadline. Includes scope-clarifying answers about what we do and don't do.
Does the EU AI Act require cybersecurity testing?
Yes. Article 15(5) explicitly requires that high-risk AI systems be resilient against attempts by unauthorised third parties to alter their use, outputs, or performance by exploiting system vulnerabilities, and Recital 77 names the specific attack categories — data poisoning, model poisoning, adversarial examples, confidentiality attacks, and model flaws. Article 9(8) further requires testing be performed against pre-defined metrics before market placement. This is a technical security testing mandate written directly into EU law.
What exactly does Article 15 of the EU AI Act require?
Article 15 covers accuracy, robustness, and cybersecurity for high-risk AI systems. Article 15(1) sets the design-level mandate for an appropriate level of accuracy, robustness, and cybersecurity throughout the lifecycle. Article 15(4) requires resilience against errors, faults, and inconsistencies. Article 15(5) — the operative cybersecurity clause — requires resilience against unauthorised third parties exploiting system vulnerabilities, with Recital 77 naming the specific attack categories: data poisoning, model poisoning, adversarial examples, confidentiality attacks, and model flaws.
When is the EU AI Act deadline for high-risk AI systems?
August 2, 2026 is the primary compliance deadline for Annex III high-risk AI systems. Legacy systems already on the market without substantial modification have until August 2, 2027. AI embedded in regulated products such as medical devices may qualify for a further extension to December 31, 2030. Prohibited AI practices have been enforced since February 2, 2025.
Do US companies need to comply with the EU AI Act?
Yes. The EU AI Act applies to any company whose AI affects EU residents — regardless of where the company is based. If you sell AI-powered products to EU customers, or operate AI that processes data about EU individuals, you are in scope. Non-EU providers must appoint an EU authorized representative before placing high-risk AI on the EU market.
What AI systems are high-risk under EU AI Act Annex III?
Eight sectors: biometrics (remote identification, emotion recognition), critical infrastructure, education and training (admissions, assessment, exam monitoring), employment (recruitment, CV screening, performance evaluation), essential services (credit scoring, insurance risk, benefit eligibility), law enforcement (profiling, risk assessment, forensics), migration and border control, and administration of justice. AI embedded in safety-critical regulated products is also high-risk.
What is an EU AI Act conformity assessment?
The process by which providers demonstrate compliance before market placement. Most high-risk AI uses self-assessment: compile an Annex IV technical documentation package covering risk management, data governance, design, testing evidence, and human oversight — then issue an EU Declaration of Conformity, register in the EU AI database, and affix CE marking. Notified body third-party assessment is required only for biometric identification systems and AI in safety-critical regulated products.
What are the penalties for EU AI Act non-compliance?
Fines are the greater of a fixed amount or a percentage of global annual turnover: up to €35M or 7% of global turnover for prohibited AI violations (exceeding GDPR's 4%); up to €15M or 3% for high-risk system violations including Article 15 failures; up to €7.5M or 1% for supplying incorrect information. Additional enforcement includes market withdrawal, deployment suspension, product recall, and public naming.
Does the EU AI Act explicitly require red-teaming for GPAI?
Yes — Article 55 explicitly mandates adversarial testing in a red-teaming format for systemic risk GPAI providers (models trained with more than 10²⁵ FLOPs, or designated by the EU AI Office). This applies before model release and on an ongoing post-deployment basis. It is one of the few places in the regulation where "red-teaming" is named directly rather than implied through technical requirements.
Scope Clarification
The boundary between what we do and what your qualified counsel does. We're explicit about it.
Can you tell us if we're compliant with the EU AI Act?
No. We produce signed cybersecurity testing evidence aligned to specific articles and Annex IV requirements. Compliance determinations are made by your qualified legal counsel based on the totality of your risk management, data governance, transparency, oversight, and conformity-assessment work — only some of which is testable security evidence.
Will this satisfy our notified body or regulator?
We make no representation about regulator or notified body acceptance. The evidence is produced to professional cybersecurity testing standards and is structured to align with Annex IV §2(g) and §2(h). Whether any given regulator or notified body accepts it as sufficient is a determination only those parties can make.
Can you do our FRIA, Annex IV package, or conformity assessment?
No. The Fundamental Rights Impact Assessment (Article 27), the full Annex IV technical documentation, and the conformity assessment procedure (Article 43) are the customer's responsibility with qualified counsel. We produce cybersecurity testing evidence that supports your broader Annex IV documentation effort — we don't replace it.
Can you screen for prohibited practices under Article 5?
No. Article 5 (banned AI practices like social scoring, exploitative manipulation, real-time biometric ID in public) requires legal interpretation, not cybersecurity testing. Engage qualified counsel for Article 5 screening.
Can you test for bias or fairness?
No. Bias and fairness testing under Article 10(2)(f) is a separate methodology with different tooling, statistical requirements, and legal sensitivities. It's outside the scope of this engagement and we don't pretend otherwise.
Can you do model inversion testing?
No. Model inversion is a different attack class from membership inference and is not in scope under this engagement. Phase 5 covers black-box membership inference attack campaigns and, for LLM systems, training data extraction probes — both of which are confidentiality-attack categories named in Recital 77, but neither is the same as a model inversion campaign.
Can you do prompt injection testing on our LLM?
Not under this engagement. Phase 4 adversarial testing uses adversarial perturbation campaigns calibrated to data type, which are not the same as direct or indirect prompt injection probes. We can quote prompt injection separately as a Change Order or refer you to our LLM/AI Penetration Testing service line, which covers OWASP LLM Top 10 categories explicitly.
What about retesting after we remediate findings?
Available as a separately quoted Change Order with a defined retest window. The Change Order reuses the Signed Test Log format so the retest evidence drops directly into the same Annex IV technical file. Most clients elect it after Critical or High findings, because remediation evidence on a system with unverified Critical findings is technically incomplete.
What if our system has multiple endpoints?
Same-model additional endpoints can be added under the base SOW with a Change Order. Different-model endpoints require a separate engagement — different model means different testing, different metrics, and different signed evidence.
Want the deep dive?
We wrote a plain-English breakdown of exactly what Article 15 requires, who's in scope (including non-EU companies), and a six-week preparation sprint for orgs starting late.
Read: EU AI Act Article 15 — What Adversarial Testing Actually MeansRelated Services
Explore other security assessments that complement this service.
LLM/AI Penetration Testing
LLM and AI penetration testing aligned with the OWASP LLM Top 10 2025 — prompt injection, data poisoning, system prompt leakage, and more.
Learn moreWeb Application Security
Comprehensive OWASP WSTG-aligned testing of authentication, authorization, business logic, and input validation vulnerabilities.
Learn moreCloud Security Assessment
Configuration review of AWS, Azure, and GCP environments — including the AI/ML services where your models live.
Learn moreBegin Your EU AI Act Readiness Assessment
Independent cybersecurity testing for high-risk AI systems, ahead of August 2, 2026. Schedule a 30-minute scoping call or request the methodology overview — we'll confirm whether your AI system is in scope and produce a customized assessment proposal within 24 hours.
Request a Scoping Proposal Book a 30-Min Scoping Call