4.1 Use-case definition & impact/risk assessment

Framing the Problem and Intended Purpose

Governing AI development starts before any model is trained, with a disciplined definition of the use case. A governable use case states the intended purpose, the deployment context, the affected population, the decisions the system will influence, and the degree of automation. A vague ambition such as "use AI to improve hiring" cannot be governed; a specific statement such as "screen inbound applicants for a warehouse role and surface the top 20% by predicted first-year retention, with a recruiter making the final call" can be. The EU AI Act builds obligations around a provider's declared intended purpose, and the NIST AI Risk Management Framework's Map function similarly asks organizations to establish context before anything else. Getting the purpose statement right therefore determines both the technical requirements and the legal classification that follow.

Two questions belong at the front of every intake. First, is AI the appropriate tool at all? Many problems are better solved with deterministic rules, better process design, or no automation. AI earns its place when the task involves pattern recognition over data too large or complex for hand-written rules, and where some tolerance for probabilistic error exists. Second, is the use case one that law, policy, or ethics places off-limits? The EU AI Act prohibits certain practices outright — social scoring by public authorities, untargeted scraping of facial images to build recognition databases, emotion recognition in workplaces and schools, and manipulative subliminal techniques — so a go/no-go screen against prohibited uses must happen at definition time, not after investment.

Conducting an Algorithmic Impact Assessment

Once a use case survives the appropriateness screen, governance requires a structured algorithmic impact assessment (AIA), sometimes called an AI risk assessment. Canada's Directive on Automated Decision-Making pioneered the AIA as a mandatory questionnaire that produces an impact level (I–IV) driving proportionate controls. A robust AIA works through a repeatable sequence:

Stakeholder mapping must reach beyond direct users to bystanders and affected non-users — a facial-recognition system's subjects rarely consent, yet often bear the greatest harm. Harm identification should span individual harms (financial, physical, psychological, dignitary), group harms (discrimination against protected classes), and societal harms (erosion of trust, chilling effects on speech or assembly). Rights-impact analysis connects those harms to specific fundamental rights: non-discrimination, privacy and data protection, freedom of expression, due process, and human dignity. Severity, likelihood, and reversibility together let the team rate residual risk and prioritize mitigation.

Risk Classification and the Go/No-Go Decision

The AIA culminates in a risk classification that dictates the governance burden. The EU AI Act's tiered model — unacceptable (prohibited), high, limited, and minimal risk — is the reference framework AIGP candidates must know. High-risk uses (listed in Annex III, including employment, education, essential services, law enforcement, migration, and biometric identification) trigger the heaviest obligations: risk-management systems, data governance, technical documentation, logging, human oversight, and a conformity assessment before market placement. Limited-risk systems such as chatbots carry transparency duties only, and minimal-risk systems are largely unregulated.

Because AI risk assessment overlaps heavily with data protection, organizations should integrate the AIA with the Data Protection Impact Assessment (DPIA) required by GDPR Article 35 whenever processing is likely to result in high risk to individuals' rights and freedoms. The two assessments share inputs — data flows, affected populations, necessity and proportionality — and a combined assessment avoids duplicated effort while ensuring privacy and AI-specific harms are both covered. For EU high-risk systems, the AIA also feeds the conformity assessment, the pre-market process by which a provider demonstrates the system meets the Act's requirements, either through internal control (self-assessment) or, for certain biometric systems, a notified body. Deployers of high-risk systems that are public bodies additionally owe a Fundamental Rights Impact Assessment (FRIA) under Article 27.

The go/no-go decision is a documented governance gate, not a rubber stamp. Options are: proceed as designed, proceed with additional controls, redesign the use case (for example, reducing automation or narrowing scope), or abandon it. The decision, its rationale, and the accountable owner should be recorded so the organization can demonstrate due diligence and revisit the judgment as the system and its context evolve.

Two framing errors recur on the exam and in practice. The first is solutionism — reaching for AI because it is available rather than because it fits the problem — which the appropriateness screen exists to catch. The second is scope creep, where a narrowly justified system is quietly extended to new purposes the assessment never examined; because the EU AI Act ties obligations to intended purpose, a material change of purpose is effectively a new system that must be re-assessed. Candidates should also distinguish the provider (who develops or places the system on the market) from the deployer (who uses it), because the two roles carry different obligations: providers own the conformity assessment and technical documentation, while deployers own operational human oversight and, for public bodies, the fundamental-rights assessment. Finally, the impact assessment is proportionate and iterative — a low-impact internal tool warrants a light-touch review, while a high-impact system touching fundamental rights warrants a deep assessment revisited at each major change — so the AIA is a living record, not a one-time compliance artifact filed and forgotten.