---
title: "AI inventories and impact assessments | Optimize All Academy"
description: "The inventory is the foundation Every governance framework starts with knowing what you have. The EU AI Act's obligations depend on classification…"
url: https://optimizeall.com/learn/ai-governance-eu-ai-act/ai-inventory-and-impact-assessments
updated: 2026-10-05
---

AI Governance & Regulation: EU AI Act, NIST AI RMF and ISO/IEC 42001 · Operating AI governance in a company · lesson 13 of 17 · 16 min

# AI inventories and impact assessments

## The inventory is the foundation

Every governance framework starts with knowing what you have. The EU AI Act's obligations depend on classification; ISO/IEC 42001 requires you to identify AI systems in scope; NIST's Map function needs a use-case description. Without an inventory, none of these work.

## What to record for each AI system or use case

| Field | Why |
|---|---|
| ID, name, description | Unambiguous reference |
| Business owner and technical owner | Accountability |
| Vendor, product, model and version | Due diligence and change tracking |
| Purpose and intended use (and prohibited uses) | Classification depends on purpose |
| Users and affected people | Impact and transparency duties |
| Data inputs (personal? special category? client confidential?) | Privacy and security |
| Outputs and decisions (advice, content, decision about a person?) | Risk level |
| Degree of autonomy and human oversight | Oversight design |
| Jurisdictions of users and affected people | Which laws apply |
| EU AI Act role and tier; Article 50 duties | Legal obligations |
| Risk rating (likelihood x impact) and key risks | Prioritization |
| Controls in place | Evidence |
| Status (proposed, pilot, production, retired) and review date | Lifecycle |

## Finding shadow AI

- Survey staff with a short, non-punitive form: "Which AI tools or features do you use for work?"
- Check expense reports and card statements for AI subscriptions.
- Review SSO and OAuth app grants, browser extension lists and network logs where available.
- Ask vendors of existing software which AI features are on by default.

## Risk rating that is quick and consistent

Use a simple scale and write down the reasoning.

| Impact | Description |
|---|---|
| 1 Low | Internal, easily corrected, no personal data |
| 2 Moderate | Client-facing content or limited personal data; errors are visible but recoverable |
| 3 High | Decisions or advice affecting individuals, significant personal data, public-facing at scale |
| 4 Severe | Legal effects on people, special category data, safety, or high-risk AI Act uses |

Likelihood 1 to 4 based on autonomy, volume and maturity of controls. Risk = impact x likelihood. Any score of 9 or more, or any impact of 4, needs an impact assessment and AI lead approval.

## Impact assessments: which one when?

| Assessment | Trigger | Focus |
|---|---|---|
| AI system impact assessment (ISO/IEC 42001, guided by 42005) | Your own threshold, for example risk score 9+ | Impacts on individuals, groups and society across the lifecycle |
| Data protection impact assessment (GDPR Art. 35, UK GDPR, similar laws) | Processing likely to result in high risk to individuals, including innovative technology and systematic evaluation | Privacy risks and mitigations |
| Fundamental rights impact assessment (AI Act Art. 27) | Certain deployers of high-risk systems (public bodies, public services, credit scoring, life/health insurance) | Fundamental rights risks, affected groups, oversight, complaints |
| Algorithmic/bias audit | Certain local laws (e.g. NYC LL 144 for hiring tools) or your policy | Disparate impact across groups |

Combine where possible: one template with a core section and add-on modules avoids duplicate work.

## A combined impact assessment template (outline)

1. **Description**: purpose, context, users, affected people, data, outputs, autonomy.
2. **Necessity and proportionality**: why AI, alternatives considered, data minimization.
3. **Stakeholders**: who could be affected, including vulnerable groups; how you consulted them.
4. **Risks**: accuracy and confabulation, bias and discrimination, privacy, security (including prompt injection), transparency, over-reliance, IP, reputational and environmental.
5. **Mitigations and controls**: technical, procedural, human oversight, disclosure.
6. **Residual risk and decision**: approve, approve with conditions, reject; who decided.
7. **Monitoring and review**: metrics, triggers for reassessment (model change, new market, incident).
8. **Add-on modules**: GDPR DPIA items; AI Act FRIA items where applicable.

## Worked example: a Jeddah real-estate agency's lead-scoring model

The agency plans AI that scores inbound leads for sales priority using form data and website behavior.

- Impact 2 (it affects which prospects get a fast callback, not access to housing or credit), likelihood 3 (fully automated routing). Score 6: no mandatory assessment under their policy, but because it profiles individuals using personal data, KSA PDPL duties apply and they run a light DPIA anyway.
- Risk found: the model might deprioritize leads from certain neighborhoods, a proxy for socioeconomic status. Mitigation: remove postcode as a feature; monthly check of callback rates by region; all leads get a response within 24 hours regardless of score.

## Hands-on: inventory as code

```yaml
- id: AI-007
  name: "Lead scoring"
  owners: {business: "Head of Sales", technical: "CRM admin"}
  vendor: {product: "CRM predictive scoring add-on", model: "vendor-proprietary", version: "2026.08"}
  purpose: "Prioritize inbound leads for callback order"
  prohibited_uses: ["pricing", "deciding eligibility for viewings or rentals"]
  data_inputs: ["form fields", "site behavior"]
  personal_data: true
  special_category: false
  jurisdictions: ["KSA", "UAE"]
  eu_ai_act: {in_scope: false, reason: "No EU users or outputs"}
  autonomy: "automated routing; humans can override"
  risk: {impact: 2, likelihood: 3, score: 6}
  assessments: ["DPIA-light 2026-09"]
  controls: ["postcode removed", "24h response floor", "monthly regional fairness check"]
  status: production
  review_date: 2027-03-01
```

Keeping the inventory in YAML or a spreadsheet with fixed columns lets you filter, report and diff changes over time.

## Pitfalls

- Inventorying tools but not **use cases**. One chat assistant may power five use cases with different risks.
- Doing a big assessment once and never revisiting when the model, data or market changes.
- Assessments written after launch to justify a decision already made.

## Video lecture: AI inventories and impact assessments

Lecture coming soon · 13 chapters · about 8 minutes. Read the full transcript below.

1. Inventory and impact
2. Why inventory first
3. What to record
4. Analogy: a hospital equipment register
5. Finding shadow AI
6. Quick risk rating
7. Which assessment?
8. Worked example: Jeddah lead scoring
9. Three traps
10. Example 2: six-person Dubai travel agency
11. Keep it alive
12. Watch me do it: full inventory entry
13. Recap and next step

## Lecture transcript

### Inventory and impact

You can't govern what you can't see. Every framework in this course, the EU AI Act, NIST and ISO forty-two thousand and one, starts from the same place: knowing which AI systems you have, what they do, and who they affect. In this lesson you'll build a proper AI inventory, find the shadow AI you didn't know about, rate risk quickly and consistently, and choose the right impact assessment for each use case.

### Why inventory first

Why start with an inventory rather than a policy or a risk framework? Because every other control depends on it. You can't classify under the AI Act, answer a client questionnaire, respond to a vendor incident, or scope an ISO management system without knowing what AI you use and where. Teams that skip the inventory end up writing policies for tools they don't know about, and discover their real exposure only when something goes wrong.

### What to record

An inventory entry needs more than a tool name. Record an ID and description, a business owner and a technical owner, the vendor, product, model and version, and the purpose, including uses you forbid. Record who uses it and who's affected, what data goes in, especially personal or special category data, and what comes out: content, advice, or a decision about a person. Add the degree of autonomy and human oversight, the jurisdictions involved, the AI Act role and tier, a risk rating, the controls in place, status, and a review date.

### Analogy: a hospital equipment register

An analogy: an AI inventory is like a hospital's register of medical equipment. Every device has an ID, a location, a responsible department, a service date and a risk class. Before a new device is used on patients, someone checks it's safe for that purpose. If a device is recalled, the hospital knows exactly where every unit is. Your AI inventory gives you the same power: when a vendor has an incident, or a law changes, you can find every affected use within minutes.

### Finding shadow AI

Now the hard part: finding shadow AI. Run a short, non-punitive survey asking which AI tools and features people use for work. Check expense reports and card statements for AI subscriptions. Review single sign-on and app grants, browser extensions and network logs if you have them. And ask the vendors of software you already use which AI features are switched on by default. The goal is visibility, not punishment. If people fear blame, they'll hide tools.

### Quick risk rating

Rate risk with a simple, repeatable scale. Impact from one to four: one is internal and easily fixed; two is client-facing or limited personal data; three affects individuals or uses significant personal data at scale; four has legal effects on people, uses special category data, touches safety, or is a high-risk AI Act use. Likelihood from one to four, based on autonomy, volume and how mature your controls are. Multiply them. Set a rule, for example any score of nine or more, or any impact of four, needs an impact assessment and approval.

### Which assessment?

Which assessment when? An AI system impact assessment, as expected by ISO forty-two thousand and one and guided by forty-two thousand and five, looks at impacts on people and society across the lifecycle. A data protection impact assessment is required under GDPR and similar laws when processing is likely to be high-risk to individuals. A fundamental rights impact assessment under the AI Act applies to certain deployers of high-risk systems. And some local laws require bias audits, like New York City's rule for hiring tools. The smart move is one combined template with add-on modules.

### Worked example: Jeddah lead scoring

Here's a real estate agency in Jeddah planning AI that scores inbound leads for callback priority. Impact two, because it changes who gets a fast callback, not who gets housing or credit. Likelihood three, because routing is automated. Score six, below their threshold. But it profiles people using personal data, so Saudi data protection law applies, and they run a light assessment anyway. They find the model might deprioritize certain neighborhoods, a proxy for income. So they remove postcode, guarantee every lead a response within twenty-four hours, and check callback rates by region each month.

### Three traps

Three traps to avoid. First, inventorying tools instead of use cases. One chat assistant might power five use cases with very different risks. Second, doing an assessment once and never revisiting it when the model, data or market changes. Set reassessment triggers. Third, writing the assessment after launch to justify a decision already made. The assessment should be able to change the design, or it's theatre.

### Example 2: six-person Dubai travel agency

A simpler example. A six-person travel agency in Dubai runs its first inventory. They find four uses: a chat assistant for itinerary drafts, an AI feature in their email tool that writes subject lines, a WhatsApp chatbot answering visa questions, and a transcription tool for client calls. Scores: the drafts and subject lines are ones and twos. The visa chatbot scores higher, because wrong answers could cost clients a trip, so it gets a light assessment, a rule to link to official sources, and a human check on unusual cases.

### Keep it alive

A final practical tip: keep the inventory where people already work, in a shared spreadsheet or your project tool, with fixed columns and a named owner, and make adding an entry part of every new tool request. An inventory that lives in a forgotten document decays within months. One that's part of the approval workflow stays current automatically, because nobody gets a new AI tool approved without creating its entry.

### Watch me do it: full inventory entry

Watch me do it. I convert the register into the full inventory format for one use case: lead scoring. ID: AI zero zero seven. Owners: head of sales for business, CRM admin for technical. Vendor: the CRM's predictive scoring add-on, version from the release notes. Purpose: prioritize inbound leads for callback order. Prohibited uses: pricing, and deciding who gets viewings. Data in: form fields and website behavior, personal data yes, special category no. Jurisdictions: Saudi Arabia and the UAE, so EU AI Act not in scope, reasoning attached. Autonomy: automated routing, humans can override. Now the risk score: impact two, because it affects callback speed, not access to housing or credit. Likelihood three, because routing is automated at volume. Score six, below our threshold of nine. But it profiles people with personal data, so I open the combined assessment template and fill the light version: necessity, stakeholders, risks, and I spot postcode as a proxy for income. Mitigation: remove postcode, guarantee a response within twenty-four hours, check callback rates by region monthly. Review date: March.

### Recap and next step

Recap. Your inventory is the foundation of everything else. Record owners, purpose, data, outputs, autonomy, jurisdictions, tier, risk and controls. Hunt for shadow AI without blame. Rate risk simply and set a threshold for deeper assessment. Use one combined template for AI, data protection and fundamental rights assessments. Your next step: convert your tool list into the YAML inventory format in the lesson text, one entry per use case, and rate each one.

## Key takeaways

- An AI inventory records owners, vendor/model/version, purpose, data, outputs, autonomy, jurisdictions, AI Act tier, risk and controls per use case.
- Find shadow AI through non-punitive surveys, expenses, SSO grants, extensions and vendor feature checks.
- A simple impact x likelihood score with a threshold decides when a deeper assessment and approval are required.
- Combine AI impact assessment, DPIA, FRIA and bias audit needs in one template with add-on modules, and reassess on change.

## Try it

Convert your tool list into YAML inventory entries, one per use case. Rate impact and likelihood, and mark any entry that crosses your assessment threshold.

- [Previous: Writing an AI policy people actually follow](https://optimizeall.com/learn/ai-governance-eu-ai-act/writing-an-ai-policy)
- [Next: Model and vendor due diligence](https://optimizeall.com/learn/ai-governance-eu-ai-act/model-and-vendor-due-diligence)
- [All lessons of AI Governance & Regulation: EU AI Act, NIST AI RMF and ISO/IEC 42001](https://optimizeall.com/learn/ai-governance-eu-ai-act)