A model can pass a technical performance test and still create an unacceptable governance problem. A recruitment screening tool may disadvantage protected groups. A customer prioritisation model may lead staff to treat vulnerable people differently. A generative AI assistant may expose confidential information through prompts, retrieval sources or poorly controlled outputs.
To assess AI system impacts properly, organisations need more than a generic risk score or a supplier questionnaire. They need a repeatable assessment that identifies who may be affected, how harm could arise, which legal and control obligations apply, and who is accountable for closing the resulting actions. That is the difference between an AI inventory that describes technology and a governance record that can withstand regulatory, customer and board scrutiny.
Why AI impact assessment cannot be a one-off exercise
Impact assessment is the point at which an organisation translates an AI use case into its real operational, legal and human consequences. It should consider the system as deployed, not merely as presented in a vendor demonstration. The relevant context includes the intended purpose, users, affected individuals, decision workflow, datasets, jurisdictions, degree of automation and available human intervention.
This matters because the same model can have materially different consequences in different settings. A tool that summarises internal meeting notes has a different impact profile from a tool that recommends whether an employee should be investigated, promoted or dismissed. Likewise, an AI system supporting a clinician may be acceptable with qualified review and clear limitations, but unsuitable where users are likely to treat its output as decisive.
The EU AI Act makes this distinction operational. Risk classification depends on intended purpose and use, not simply on the type of model. High-risk systems require risk management, data governance, technical documentation, logging, human oversight and post-market monitoring. Article 27 also requires a fundamental rights impact assessment before deployment for specified deployers of high-risk AI systems, including public bodies and private entities providing public services, with additional cases defined by the Act.
ISO/IEC 42001 takes a wider management-system view. It expects organisations to determine and address AI-related risks, evaluate impacts, assign responsibilities and retain evidence that controls operate as intended. A credible assessment process should therefore serve both regulatory and assurance objectives rather than creating separate paperwork for each framework.
Start with the deployment context, not the model
The first failure in many AI assessments is starting with technical terminology. Teams debate whether a system uses machine learning, large language models or rules-based automation before recording the operational decision it influences. That approach produces incomplete classifications and vague controls.
Begin by documenting what the system does in the business process. Identify the provider, system owner, users, purpose, inputs, outputs, integration points and whether the system informs, recommends or makes a decision. Record whether people can challenge the output, override it, or understand the grounds on which it was produced.
The assessment should distinguish between intended use and foreseeable misuse. A generative AI tool approved for drafting internal content may still be used by staff to process personal data, generate customer communications or draft regulated advice. These uses may not be authorised, but they are foreseeable. Governance needs a clear restriction, technical guardrail or monitoring control rather than an assumption that policy alone will prevent them.
This context also determines whether supplier evidence is sufficient. A vendor’s model card, security certificate or standard data processing agreement can inform the review. It cannot establish that your organisation’s deployment has appropriate human oversight, adequate user training or a defensible route for affected people to raise concerns.
Assess impacts across people, rights and operations
A useful assessment separates potential impacts into clear categories, then considers how they connect. Privacy, discrimination, safety, security, consumer protection and employee rights often overlap. Treating them as isolated checklist items can hide the actual harm pathway.
For each use case, assess the likely effect on affected groups, including indirect users and people whose data is used to train, configure or validate the system. Consider whether impacts are more severe for children, employees, job applicants, customers in financial difficulty, people with disabilities or other vulnerable groups. A system can appear neutral at aggregate level while creating disproportionate errors or barriers for a smaller population.
The analysis should address four practical questions:
- What decision, recommendation or action is influenced by the AI system?
- Who could be affected, and what adverse outcome could they experience?
- What conditions make the harm more likely, such as poor data quality, automation bias or weak access controls?
- Which safeguards prevent, detect or reduce the impact, and who tests them?
This is not an exercise in predicting every theoretical risk. The objective is proportionate judgement supported by evidence. A low-impact internal productivity tool may justify a shorter review with standard controls. An AI system used in employment, credit, education, policing, healthcare or access to essential services requires deeper analysis, specialist input and a more formal approval route.
Connect impact findings to legal duties and controls
An impact assessment becomes useful when each finding leads to a defined governance response. Risk statements without control owners, deadlines or validation criteria simply become a record of unresolved concern.
For personal data processing, assess whether a data protection impact assessment is required under UK GDPR or EU GDPR, depending on the processing and relevant establishment. Where automated decision-making is involved, examine the safeguards needed for individuals, including meaningful information, human intervention and routes to contest a decision where applicable. Do not label an AI system as “human in the loop” unless the human reviewer has authority, competence, time and information to intervene meaningfully.
For EU AI Act classification, record the basis for determining whether the system is prohibited, high-risk, subject to transparency duties or outside the relevant regulated categories. Where a provider claims its system is not high-risk, retain the reasoning and assess whether your intended use changes that position. The deployer’s obligations do not disappear because a procurement document uses reassuring language.
Controls should be specific enough to test. For example, “mitigate bias” is not a control. A more defensible control may require pre-deployment performance testing against defined groups, documented acceptance thresholds, quarterly monitoring for outcome disparities, escalation where thresholds are exceeded, and a named owner responsible for remediation. The right frequency depends on the system’s impact, rate of change, data volatility and scale of use.
Build an evidence trail that survives audit
Compliance teams should be able to retrieve the assessment record without chasing emails, spreadsheets and departed project managers. Each AI system needs a central record containing the inventory entry, classification decision, impact assessment, approvals, supplier documents, risk treatment plan, control tests, monitoring results and review history.
Evidence should show not only that an assessment occurred, but that the organisation acted on it. If the review identified a risk of fabricated outputs, the record should show the chosen safeguards: user guidance, output validation, restricted use cases, audit sampling, incident reporting and a decision on acceptable residual risk. If a control was not implemented, record the rationale, accountable approver and review date.
Board reporting should not reproduce every assessment. It should show the risk posture: how many systems are unassessed, high-risk or overdue for review; which material issues remain open; whether owners are meeting control deadlines; and where senior decisions are required. This gives the board a decision-grade view rather than a catalogue of technical projects.
A system of record such as Endaxi AIG can make this operational by connecting inventory, EU AI Act classification, ISO/IEC 42001 controls, evidence and reporting in one workflow. The value is not another dashboard. It is a traceable line from AI use case to obligation, owner, control and proof.
Reassess when the system or its context changes
Approval is not permanent. AI systems change through model updates, new features, altered prompts, expanded user groups, revised training data, new integrations and changes to the business process around them. Any of these can alter the impact profile.
Set review triggers at the point of change management and procurement governance. Reassessment should be required when a system moves into a new jurisdiction, begins processing a new category of personal data, influences a consequential decision, experiences a material incident, or is repurposed beyond its approved use. Scheduled reviews still matter, particularly for high-impact systems, but event-driven reviews catch the changes annual cycles miss.
The practical test is straightforward: could this change affect people, rights, compliance duties or the effectiveness of existing controls? If the answer is yes, update the assessment before the changed deployment becomes business as usual.
Good AI governance is not achieved by producing the longest impact assessment. It is achieved when the organisation can show, clearly and promptly, what the system does, who may be affected, what it decided to control, and why those decisions remain appropriate.