EXIN AI Security Professional common mistakes
EXIN AI Security Professional · Understand the traps and how to avoid them.
Treating the EU AI Act's risk tiers as a single linear scale and classifying a system by its sector or by the technology name (e.g. 'it's a chatbot, so limited risk') instead of by its intended purpose and the specific use described in Annex III.
Candidates study the four tiers as a list to memorise and then pattern-match on industry labels. The Act classifies by intended purpose and context of use, so two systems built on the same model can land in different tiers; sector intuition overrides the actual text under exam pressure.
What to do instead
For every scenario question, write down the intended purpose, the affected persons, and whether the use appears in an Annex III area before choosing a tier. Practise by taking one capability (e.g. emotion recognition) and mapping how the tier changes across workplace, education, medical and consumer contexts.
Confusing the AI Act's transparency obligations with its prohibited practices: answering that a chatbot must be banned or that a prohibited practice only needs disclosure, rather than separating Article 50-style disclosure duties from the outright prohibitions.
Both are 'rules you must follow' and both appear in the same chapter headings in summaries. Candidates remember the phrase 'transparency' and attach it to whichever obligation the question hints at, without checking whether the practice is banned outright or merely conditioned.
What to do instead
Build a two-column table: prohibited practices (closed list, no compliance path) versus transparency duties (disclosure, marking, notice). For each practice, state which column it belongs to and what the compliant behaviour looks like, then test yourself with questions that describe a borderline use such as real-time remote biometric identification.
Assigning every AI Act obligation to the provider and forgetting the deployer, importer and distributor roles, so questions about a bank using a third-party high-risk system are answered as if the bank had no duties.
Most study material is written from the vendor's perspective, and the provider is the most visible role. Candidates default to 'the provider does it' without checking who is placing the system into service or putting their name on it.
What to do instead
For each high-risk scenario, name the role of every party first, then list the duties that attach to that role (e.g. deployer duties on human oversight, monitoring, logging and informing affected persons). Rehearse the case where a deployer substantially modifies a system and becomes a provider.
Describing prompt injection, jailbreaks and data poisoning as the same class of attack, or proposing the same control for all three, instead of distinguishing manipulation of the input at inference time from corruption of training data or model weights.
All three are 'the model is made to behave badly', and vendor material often bundles them under one heading. Candidates match on the symptom (bad output) rather than the attack surface (input channel versus training pipeline versus model artefact).
What to do instead
Classify each attack by where it enters: inference input (prompt injection, jailbreak), training data (poisoning, backdoor), model supply chain (tampered weights), or output handling (insecure downstream use). Then attach controls to the entry point, and practise rewriting a scenario into 'which surface is touched' before answering.
Treating guardrails or a content filter as a complete mitigation for prompt injection, rather than as a defence-in-depth layer that does not remove the need for least-privilege tool access, output validation and separation of trusted and untrusted content.
Filters are the most visible control and are easy to name. Candidates stop at the first plausible control instead of asking what happens when the filter is bypassed and what the model can still do with its tools and data access.
What to do instead
For any injection question, answer in layers: input handling and provenance tagging, privilege limitation for tools and retrieval, output validation before action, monitoring and logging. State explicitly what each layer does not cover, and practise questions where the model has agency (sending email, calling APIs) so the blast radius matters.
Answering model-security questions with classical application-security answers only, such as 'patch the server and add a WAF', without addressing model extraction, membership inference, adversarial examples or unsafe model artefacts.
Candidates with a traditional security background transfer familiar controls. Those controls are necessary but do not touch threats that arise from the model's behaviour and its training data, so the answer looks competent and misses the AI-specific risk.
What to do instead
Keep a short list of AI-specific threat categories (extraction, inference and privacy leakage, evasion and adversarial input, poisoning and backdoors, supply-chain and model artefact risk) and force yourself to check each scenario against it. Where a classical control applies, say what it does and does not mitigate for the model itself.
Treating AI governance as documentation produced after deployment, so answers propose writing a policy or an impact assessment only at the end, rather than embedding risk management, data governance, testing and monitoring across the lifecycle.
Governance is often studied as a set of documents to name. Candidates list artefacts instead of describing the process that produces them and the feedback loop that keeps them current after the system changes.
What to do instead
Map each governance element to a lifecycle stage: risk classification and data governance before development, testing and evaluation before release, logging, monitoring and incident handling after release, review on change. Answer governance questions by naming the stage as well as the artefact, and include the trigger for reassessment.
Skipping the human-oversight requirement for high-risk systems, or describing oversight as a person who can read the logs, instead of effective oversight with authority, competence, information and the ability to intervene or stop the system.
Oversight sounds like a checkbox and candidates reduce it to 'a human reviews outputs'. That answer misses the conditions that make oversight meaningful and fails questions that probe automation bias or oversight by someone without the power to act.
What to do instead
Define oversight by its components: named responsible person, adequate competence and information, real authority to override or halt, and safeguards against rubber-stamping. Apply it to a concrete high-risk use such as recruitment screening and describe what the overseer sees, decides and can stop.
Assuming the EU AI Act applies only to companies established in the EU, or that general-purpose AI model obligations and high-risk system obligations are the same regime with the same actors.
Extraterritorial scope and the split between model-level and system-level obligations are structural details that get compressed in summaries. Candidates rely on the intuitive 'EU law applies in the EU' shortcut and on a single mental model of 'AI rules'.
What to do instead
Learn the scope triggers (placing on the market, putting into service, use in the Union, and output used in the Union) and keep two separate obligation maps: one for general-purpose AI models and one for high-risk AI systems, each with its actors. Test yourself with a non-EU vendor selling into the EU and with a model provider whose model is embedded in someone else's high-risk product.
Answering incident-response and monitoring questions for AI systems with a generic IT incident process, omitting AI-specific signals such as drift, data or behaviour change, model updates, prompt or retrieval changes, and the need to preserve inputs, outputs and model versions as evidence.
Incident response is taught once in a general security frame, and candidates reuse it unchanged. AI incidents often emerge from gradual degradation or a silent model change rather than a discrete breach, so the generic process has no detection hook for them.
What to do instead
Extend the incident process with AI-specific detection (performance and drift monitoring, output quality sampling, user reports of harmful behaviour), change management for models, prompts and data, and evidence capture covering model version, inputs, outputs and configuration. Practise a scenario where output quality degrades after a supplier updates the model and describe detection, containment and notification.