Shadow AI: Building an AI System Inventory
How to find the AI systems in your organisation and record them in one register: five steps, a register template and the duties in Articles 4, 26 and 49.
The EU AI Act has no article that requires an AI system inventory, but several duties are hard to meet without one.
Providers and deployers must take measures to support AI literacy among their staff, since 2 February 2025 (Article 4). Deployers of high-risk systems must take appropriate measures to use them in accordance with the instructions for use. This applies from 2 December 2027 (Annex III) or 2 August 2028 (Annex I). Breaches of Article 26 reach EUR 15 million or 3% of worldwide annual turnover, whichever is higher (Article 99(4)). Next step: list every AI system in use.
Three of the duties presuppose that you know your AI systems
AI literacy (Article 4)
Providers and deployers of AI systems take measures to support the AI literacy of their staff and of others who operate and use AI systems for them, taking context into account. The duty does not require a guaranteed level for any individual.
Deployer duties (Article 26)
Deployers of high-risk AI systems take appropriate technical and organisational measures to use them in accordance with the instructions for use, assign human oversight to people with the necessary competence, training and authority, and monitor how the system operates (Article 26(1), (2) and (5)).
Registration (Article 49)
Providers register Annex III high-risk systems, and systems they judge not high-risk under Article 6(3), in the EU database before placing them on the market or putting them into service. Systems for law enforcement and migration (Annex III points 1, 6 and 7) go into a non-public section, and critical infrastructure systems (point 2) are registered at national level. Deployers that are public authorities, Union institutions, bodies, offices or agencies, or persons acting on their behalf, register their use (Article 49(3)).
Article 2 limits the scope. For AI systems classified high-risk under Article 6(1) that relate to Annex I Section B products, only Article 6(1), Article 60a and Articles 102 to 112 apply, so Article 4 does not. The Act also excludes systems used exclusively for military, defence or national security purposes, research systems and purely private non-professional use (Article 2(2), (3), (6), (8) and (10)).
What counts as an AI system, and what does not
The Act defines an AI system as a machine-based system designed to operate with varying levels of autonomy that infers from its input how to generate outputs such as predictions, content, recommendations or decisions (Article 3(1)). Systems based only on rules defined by natural persons are not covered (recital 12).
AI services called by API
Your code calls an AI model through an API. An AI system is in use even if a vendor runs the model. Record it, and note who is the provider and who is the deployer.
Embedded pre-trained models
A model file from a public model hub runs inside your application, for example for classification or content moderation. Record the model and where it comes from.
SaaS tools with AI features
Writing assistants, CRM scoring and code assistants are examples. Using such a tool for a purpose listed in Annex III, such as screening applicants, can make you the deployer of a high-risk system, unless the Article 6(3) exception applies.
Scoring, recommendation and filtering features
These are AI systems only if they infer outputs from input data. A fixed set of rules written by people is not an AI system. Check which one you have.
Five steps build the inventory
Scan your code
Start with discovery in code: search all repositories for AI-related imports, API calls, model files and configuration.
- Search for ML framework imports (for example tensorflow, torch, sklearn, transformers)
- Identify AI API calls (for example openai, anthropic, google.ai, azure.cognitiveservices)
- Find model files (for example .pb, .pt, .onnx, .h5, .pkl, .safetensors)
- Find AI configuration files such as model configs and prompt templates
- Look for embedding and vector database usage (for example pinecone, weaviate, chromadb)
Ask your teams
Code scanning finds AI that appears in code and misses planned, experimental or SaaS-based AI. Ask every team about the rest.
- Send a short questionnaire to engineering, product and business teams
- Ask about AI features in the SaaS tools in use
- Identify experimental or proof-of-concept AI projects
- Document AI tools used for internal processes such as HR screening, customer support and analytics
- Map vendor relationships that involve AI or ML services
Classify each system
For each system, check in this order which rules apply, and write down the reasoning.
- Check the banned practices of Article 5
- Check the Annex I route and the 8 Annex III areas (Article 6)
- Check the Article 6(3) exception where it applies
- Check whether a general-purpose AI model is involved (Article 3(63))
- Check the transparency duties of Article 50
- Document the reasoning for each system
Keep one register
Create one register for all AI systems. It is the basis for the duties in Articles 4, 26 and 49 and for requests from authorities.
- Assign a unique identifier to each AI system
- Record the provider, the deployer and the person responsible
- Record the classification and the reasoning
- Track the open duties for each system
- Link the technical documentation (Annex IV) where it applies
- Keep version history and records of changes
Keep it current
An inventory is only useful if it stays current. Capture new AI systems and changes that may alter the classification.
- Add an AI inventory check to code review and pull requests
- Require registration of an AI system before it goes to production
- Scan for new AI dependencies in CI/CD
- Review the inventory with stakeholders every quarter
- Define who decides when a new system may be high-risk
- Train development teams to identify and report AI systems
One possible register: ten fields (our suggestion)
| Field | Description | Example |
|---|---|---|
| System ID | Unique identifier | AI-SYS-001 |
| System name | Name used internally | CV screening assistant |
| Provider | Who developed the system | Vendor name or internal team |
| Your role | Provider, deployer or both | Deployer |
| Classification | Result of your classification, with reasoning | High-risk, Annex III point 4(a) |
| Intended purpose | What the system is used for | Ranks job applications |
| Deployment status | Current lifecycle stage | In production |
| Data processed | Types of data handled | CVs and application forms |
| Responsible person | Internal owner of the duties | Head of HR |
| Open duties | What is still to do | Request the instructions for use |
Common questions about the AI inventory
Is an AI system inventory legally required under the EU AI Act?
No article requires an inventory as a document. Several duties presuppose that you know your AI systems: AI literacy for providers and deployers (Article 4), deployer duties for high-risk systems (Article 26) and registration in the EU database (Article 49). A provider who judges that an Annex III system is not high-risk must document that judgement and register the system (Article 6(4) and Article 49(2)).
How do I handle AI systems already in production?
Start with systems that may be banned (Article 5) or high-risk (Article 6). Record each system, classify it and note its provider. The Act has limits: it excludes military, research and purely private use (Article 2(3), (6), (8) and (10)), and some bans apply only later (Article 113(a)). A high-risk system placed on the market or put into service before the application date is covered only if its design changes significantly afterwards. In any case, providers and deployers of high-risk systems intended to be used by public authorities must take the necessary steps to comply by a later date (Article 111(2))
Should I include employee-facing AI tools in my inventory?
Yes. Article 4 covers AI systems that your staff operate and use, whether or not they are high-risk. Annex III point 4 lists employment uses, such as recruitment and selection, decisions on terms of work, task allocation and monitoring of performance and behaviour.
Read next: classification and documentation
Is My AI System High-Risk? A Decision Tree
Walks through the questions that decide whether an AI system is banned, high-risk or neither.
Annex III Deep Dive: All 8 High-Risk Categories
Lists the 8 areas whose AI systems are high-risk, with examples from the Annex wording.
Annex IV Technical Documentation: The Nine Points
Shows the nine points of documentation that a high-risk system needs.
Scanara prepares evidence from your repositories
Scanara reads your connected GitHub repositories and runs rule-based scans for standard AI and machine-learning patterns. It can miss non-standard code. Separately, it generates draft documentation from templates and your assessment answers as evidence for your compliance work. You make the classification decisions.