AI system impact assessments
Overview
Section titled “Overview”ISO/IEC 42001 asks for a process to assess the impact of each AI system (A.5.2), a record of each assessment (A.5.3), and an assessment of the impact on individuals and groups (A.5.4) and on society (A.5.5). The EU AI Act asks deployers to use AI systems as intended and monitor them (Art. 26), and some to assess the impact on fundamental rights (Art. 27).
A blank questionnaire asks people to remember what an AI system does. In Shield360 an assessment starts pre-filled with what was observed about the system over a period you choose, each fact with its source and a link to the page it came from. People judge; nobody types numbers in.
Govern → Impact assessments lists every AI system that needs an assessment and every asset that has one. Each assessment moves from draft to in review to approved, with a date by which it must be reviewed again. A new version of an asset’s assessment replaces the approved one when it is approved, and every version is kept.
Prerequisites
Section titled “Prerequisites”- To read assessments, you need the View the compliance overview permission (
compliance.read). Owners, administrators, the Compliance officer, Analyst and Viewer roles, and Auditors have it. - To start, write, submit and approve assessments, you need the Manage AI impact assessments permission (
compliance.impact.manage). Owners, administrators and the Compliance officer role have it. Auditors never do. - The facts come from the AI inventory and the pages it links to. Team counts need a directory (identity) connector, such as Microsoft Entra ID, Okta or Google Workspace; without one, people are counted but not by team.
Which systems need one
Section titled “Which systems need one”An asset is in scope when it is in use (seen in the inventory’s lookback), neither rejected nor retired, and either:
- an AI application or an agent your organisation runs, including coding agents that send traces and agents registered in the gateway, or
- an AI tool rated high risk in the inventory, or
- an AI tool or model whose risk tier is high, or
- an AI Model that stands alone (no parent AI System in its profile) with a direct consumer impact or a material financial impact.
An AI system or model registered by hand counts as in use while its profile says it is in production.
Other models, vendors and API keys are parts of a system and are assessed with it. You can still assess any other asset from its inventory page; it just does not count towards the controls below.
Start an assessment
Section titled “Start an assessment”Select Start assessment on the asset’s row in Govern → Impact assessments, or on the asset’s page in the AI inventory.
The new draft shows what Shield360 observed over the last 30 days. To use 7 or 90 days, choose the period and select Read the facts again.
Fill in the sections below, then select Save.
Submit for review is available once every judgement is recorded. The assessment is locked while it is in review; Return to draft unlocks it.
Someone else who may manage assessments sets the next review date and selects Approve. The author and the person who submitted it cannot approve it.
A later version starts from the previous version’s judgements with fresh facts. Only one version per asset can be in draft or in review at a time.
What is pre-filled
Section titled “What is pre-filled”| Fact | What it says | From |
|---|---|---|
| Who uses it and how much | How many people and machines used it, counted by team, and its requests, responses and tool calls | AI inventory, directory |
| Sensitive data sent to it | Sensitive-data events, how many were blocked or masked and how many were sent anyway after a warning, and the kinds of data | Data protection |
| Prompt-injection detections | Detections, and how many were blocked or could not be enforced | Prompt injection |
| Models and vendors behind it | The models and vendors the inventory relates to it, with their approval status | AI inventory |
| Agent tool access | For a gateway agent: its grants and tools, unused grants and tools, broad grants, and whether it was idle | Agent access |
| Evaluation results | For an application or agent sending traces: evaluations of its spans and how many were flagged | Evaluations |
| Linked risks and findings | Risks in the register that name the asset, and findings on those risks | Risk register |
| Approval and decision | The asset’s status, risk rating, whether it has an owner, and its last review and decision | AI inventory |
Each fact links to the page it came from. A source that could not be read is shown as unavailable, never as zero, and the rest are still filled in.
The facts can be read again while the assessment is a draft. Approving it freezes them: the approved version keeps what the approver saw.
What a person judges
Section titled “What a person judges”| Section | What you record |
|---|---|
| Intended purpose and context | What the system is for and how it is used. Up to 2,000 characters each. |
| Affected individuals and groups | Customers, employees, job applicants, children, vulnerable people, the general public or business partners, with notes. |
| Potential harms | For each harm that could arise, its likelihood and severity from 1 to 5, and the residual risk (low, medium or high) once mitigations are in place. |
| Mitigations | Guard settings (sensitive-data protection, prompt-injection detection, approved model list, agent guard, coding-agent policy, AI tools policy), ISO/IEC 42001 controls, sequence policies, and notes. |
| Residual risk | Low, medium or high overall, with notes. |
| Human oversight | A person approves each output, monitors and can step in, decides when it is used, or none. |
| Societal impact | None, limited, moderate or significant, with notes. |
| Decision | Proceed, proceed with conditions, or do not proceed, with the conditions or reasons. |
| Fundamental rights impact assessment (EU AI Act Art. 27) | The fundamental rights the use may affect, the period and frequency of use (27(1)(b)), the measures if the risks materialise with internal governance and complaint mechanisms (27(1)(f)), and when and how the market surveillance authority was notified (27(3)). |
Fundamental rights impact assessment
Section titled “Fundamental rights impact assessment”A deployer that is a public body or provides public services, or that uses a high-risk system for creditworthiness or life and health insurance pricing (Annex III 5(b), (c)), must assess the system’s impact on fundamental rights before first use (EU AI Act Art. 27). An impact assessment is that assessment when, besides its approval, it records every Art. 27(1) element: the context of use (a), the period and frequency of use (b), the affected groups (c), the harms and the rights they touch (d), human oversight (e) and the governance and complaint measures (f), plus the notification to the authority (27(3)). The EU AI Act page lists which systems need one and what each still lacks.
The harms are a short taxonomy written for Shield360:
| Harm | Covers |
|---|---|
| Privacy | Personal data exposed, kept too long, or used for something people did not expect |
| Discrimination and fairness | Some people or groups treated worse than others by what it decides or produces |
| Physical or psychological safety | Advice or actions that could hurt someone’s health, wellbeing or physical safety |
| Security | Misuse of the system, its tools or its data, or a way into other systems |
| Misinformation | Wrong or misleading output that people rely on or pass on |
| Intellectual property | Others’ protected work reproduced, or the organisation’s own leaked |
| Environmental | Energy and resources used out of proportion to the benefit |
| Labour and employment | Jobs, workload, monitoring or working conditions changed without people’s say |
What approving changes
Section titled “What approving changes”Approving a version:
- Supersedes the version approved before it, which is kept as it was.
- Records the residual risk as the asset’s risk rating in the AI inventory, with a rationale naming the version, and counts as the asset’s review.
- Opens risks, if you leave the option ticked, in the risk register: one for each harm whose residual risk is high, with the harm’s likelihood and severity, linked to the asset. The assessment lists the risks it opened.
If the inventory or the register cannot be updated, the approval still stands and the page says what to check.
Reviews and the overdue alert
Section titled “Reviews and the overdue alert”An approved assessment is current until its next review date. Once that day has ended, the daily control history job raises one impact_assessment.overdue alert for it. The alert names the asset’s type, the version and the date, never the asset’s name or any text. Start a new version to reassess the system.
Controls
Section titled “Controls”The check AI systems have a current approved impact assessment backs ISO/IEC 42001 A.5.2, A.5.3, A.5.4 and A.5.5 on Controls. It is:
- Met when every in-scope system has an approved assessment whose next review date has not passed.
- A gap when one has none, or its review is overdue. The reason says how many of each.
- Not applicable when no system is in scope.
It reads what is recorded now, so the daily history counts it as a presence check: an overdue review is a gap on every day it stays overdue.
Export
Section titled “Export”Select PDF or HTML on an assessment to download it: the facts, every judgement, and its history. Both are drawn the same way as the evidence package report. Each download is recorded in the audit log.
The evidence package includes impact-assessments.json and impact-assessments.csv with every version live during its period, and a section of report.html and report.pdf with today’s coverage.
Auditors
Section titled “Auditors”An Auditor can read the list, each assessment with its facts and history, and download it. They cannot start, change, submit or approve one.
Personal data
Section titled “Personal data”The facts never name anyone. The purpose, context and every note are free text, though, and can name a person:
- A person export includes every assessment whose text names the person as a whole word.
- Erasure clears that text, including a harm’s notes, and keeps the assessment, its choices, its facts and its steps.
- An organisation export includes every version as
impact_assessments, and every step asimpact_assessment_events.
The audit log records the step, the statuses, the asset, the version and the names of the fields changed, never the text.
Every request acts on the environment you have selected. A database config named in the request is ignored.
| Method | Path | Parameters |
|---|---|---|
GET | /api/governance/impact-assessments | Optional asset (an inventory asset key). One row per asset, with its current approved version, the version being worked on and the counts. |
POST | /api/governance/impact-assessments | JSON body: assetKey, and optionally periodDays (7, 30 or 90). Starts a pre-filled version. |
GET | /api/governance/impact-assessments/<id> | The version with its facts, judgements, steps and the asset’s other versions. |
PATCH | /api/governance/impact-assessments/<id> | JSON body: action and what it records: update (any sections), refresh_facts (periodDays), submit, return, approve (nextReviewDate as yyyy-mm-dd, and createRisks). |
GET | /api/governance/impact-assessments/<id>/export | format: pdf (default) or html. |
Malformed JSON, an id that is not an assessment id, a choice not on its list, a harm rated outside 1 to 5 or rated twice, a mitigation naming an unknown control, text over its limit, or a next review date not after today or more than three years away returns 400. Approving your own assessment returns 403. An assessment in another environment returns 404. A step the assessment cannot take from its status, a second version while one is open, or an assessment someone else changed meanwhile returns 409.
curl -X PATCH -H "Cookie: <session>" -H "Content-Type: application/json" \ -d '{"action":"approve","nextReviewDate":"2027-10-01","createRisks":true}' \ "https://<your-shield360>/api/governance/impact-assessments/<id>"