EXIN VFB Functioneel Beheer en AI common mistakes
EXIN VFB Functioneel Beheer en AI · Understand the traps and how to avoid them.
Treating AI as a standalone IT project and answering that the IT department alone owns the AI solution, instead of placing functional management (functioneel beheer) as the bridge between business and IT that translates user needs into information-system requirements.
Candidates carry over a general 'IT does technology' reflex and forget that the exam frames functional management as the demand-side owner of the information provision, with AI as a new type of component inside that responsibility.
What to do instead
For every positioning question, explicitly name the three layers: business (process owner), functional management (requirements, alignment, acceptance), and technical management (infrastructure, model hosting). State that functional management stays accountable for whether the AI solution supports the business process, even when the model itself is delivered externally.
Describing functional management only as 'writing user stories and doing acceptance testing', without distinguishing it from information management and from technical/application management when a scenario asks who should decide on data governance or AI model changes.
The roles overlap in daily practice and candidates use everyday job titles rather than the exam's role definitions, so they assign responsibilities to the wrong party.
What to do instead
Memorise the distinction as a decision rule: information management sets the policy and strategy for information provision, functional management translates that into system requirements and business-process fit, technical management keeps it running. In scenario questions, ask 'who owns the policy', 'who owns the requirements', 'who owns the running system' and answer each separately.
Answering data-quality questions by only mentioning completeness and accuracy, and omitting the dimensions the scenario actually tests, such as timeliness, consistency, validity, uniqueness and traceability of the data used for or produced by an AI system.
Completeness and accuracy are the best-known dimensions, so under time pressure candidates list only those and miss the dimension the case is built around.
What to do instead
Keep a checklist of dimensions and run it against the case: completeness, accuracy, timeliness, consistency, validity, uniqueness, and provenance/traceability. Then link each to a control: validation rules at input, periodic quality monitoring, source registration, and a feedback loop for model output quality.
Treating the GDPR/AVG as the only legal requirement for an AI use case and ignoring the EU AI Act risk classification, transparency obligations, and the need for a data protection impact assessment when personal data or high-risk processing is involved.
Candidates default to the privacy regulation they know best and are not yet fluent in the AI-specific regulatory layer, so they give an incomplete compliance answer.
What to do instead
Structure every legal/compliance answer in three steps: (1) classify the AI use case under the AI Act (prohibited, high-risk, limited-risk, minimal-risk), (2) check GDPR grounds, purpose limitation and DPIA obligation, (3) name sector or internal rules. Mention human oversight and documentation as concrete obligations for high-risk cases.
Writing that 'the algorithm is biased' or 'the model is a black box' as a complete answer, without naming a concrete governance measure such as bias testing on representative data, model documentation, periodic revalidation, or an escalation path for disputed outcomes.
Candidates recognise the ethical problem but stop at describing it, because they have not practised converting an ethical risk into a control that functional management can actually specify.
What to do instead
Always pair each risk with an owner and a control: bias risk -> test data representativeness and periodic bias audit; opacity -> model card and explainability requirement in the contract; drift -> scheduled revalidation and a change procedure. Name functional management as the party that writes these into requirements and acceptance criteria.
Choosing an AI use case for a scenario by picking the most technically impressive option (for example a generative chatbot) rather than the option that fits the process problem, the available data, and the acceptable risk level.
Candidates associate AI with generative models and answer from enthusiasm rather than from a structured assessment of value, feasibility and risk.
What to do instead
Use a fixed triage: what is the process problem, is there sufficient representative data, what is the impact of an error, and is human review feasible. Then select the simplest technique that fits (rules, classification, prediction, generative) and justify why heavier options are rejected.
Skipping the change-management and adoption side of an AI implementation and answering only with the technical go-live, so questions about user acceptance, training, process redesign and post-implementation review are answered thinly.
The technical implementation dominates candidates' mental model of a project, and functional management's process and people responsibilities are underestimated.
What to do instead
For every implementation scenario, add a paragraph covering impact analysis on the process, user training and communication, adjusted work instructions, acceptance criteria including AI-specific ones (accuracy threshold, fallback to manual handling), and a post-go-live review moment.
Confusing incident management with problem management in AI contexts, for example logging a wrong model output only as an incident without asking whether the underlying model, data or prompt needs structural correction.
The ITIL vocabulary is familiar but candidates do not translate it to AI-specific failure patterns such as data drift, changed source data or prompt dependency.
What to do instead
State explicitly that an incident restores service (manual override, fallback procedure) while problem management investigates the root cause (data drift, model degradation, changed business rules) and feeds a change request. Mention that AI incidents need logging with input, output and model version for later analysis.
Giving generic answers about 'involving stakeholders' and 'communicating well' instead of naming concrete artefacts such as a requirements specification, data-quality plan, model card, DPIA, acceptance test report, or service-level agreement for model performance.
Candidates fall back on soft-skill language when they are unsure of the formal deliverable, and the exam rewards named artefacts and role owners.
What to do instead
Build a one-page list of artefacts per phase (intake, design, build, acceptance, operate) and practise attaching the right artefact to each scenario. When you catch yourself writing 'communicate', replace it with the document or meeting that carries the communication and who owns it.
Ignoring the supplier and contract dimension, answering that an externally purchased AI service is 'just a component' without addressing data processing agreements, performance guarantees, transparency about the model, exit and data-return arrangements, and dependency risk.
Candidates treat bought AI as a normal licence purchase and do not consider that model behaviour, training data and change frequency sit outside the organisation's control.
What to do instead
For any externally sourced AI, add contract requirements: processing agreement, purpose limitation, performance and accuracy commitments, notification of model changes, audit or documentation rights, data export on exit, and a fallback if the supplier discontinues the service. Assign functional management the task of translating these into the requirement specification.