In short
- Every AI Act obligation is scoped by classification, and classification is scoped by inventory. An unlisted system is not low risk, it is unassessed.
- 4 detection sources exist in most organisations already: expense records, identity logs, network egress and code search. Each misses a different population.
- Expense data finds paid accounts and misses free tiers. Identity logs find single sign-on and miss personal accounts. Neither finds a model called from code with an embedded key.
- Article 4 literacy measures are calibrated to the context a system is used in, and Article 26 deployer duties attach per system, so an inventory gap is a compliance gap in 2 directions at once.
- ISO/IEC 42001 Annex A includes controls on the use of AI systems and third-party relationships, both of which an auditor samples against a list you provide.
Shadow AI is usually framed as a security story about data leaving the building. The more expensive version is quieter.
Every obligation in the AI Act is scoped by classification, and classification requires a list. A system nobody listed has not been classified as low risk. It has not been classified.
01Why does the inventory come first?
Because it is the input to every other answer.
Article 6 and Annex III decide whether a system is high risk. Article 26 sets deployer duties for high-risk systems. Article 4, as replaced by Regulation (EU) 2026/1744, requires measures supporting AI literacy, taking into account the context the systems are used in. Article 27 requires a fundamental rights assessment for specific deployers and uses.
Each of those is a per system question. An organisation that cannot enumerate its systems cannot answer any of them, and the honest description of its compliance position is unknown rather than compliant.
02Which four sources actually find things?
| Source | Finds | Misses |
|---|---|---|
| Expense and card records | Paid subscriptions and API spend | Free tiers, trials, personal cards |
| Identity and single sign-on logs | Sanctioned apps used at scale | Personal accounts, unfederated tools |
| Network egress to model endpoints | Server side and browser traffic | Traffic from unmanaged devices |
| Code search for SDKs and key patterns | Embedded integrations in your code | Vendor products that call models for you |
The fourth row is the one that changes the shape of the problem. A supplier whose product calls a model on your behalf puts an AI system into your process without appearing in any of your first three sources, which is why the vendor questionnaire is part of inventory work rather than separate from it.
03What should the list actually record?
Six fields, and no more, because the list has to survive.
| Field | Why it is needed | Who supplies it |
|---|---|---|
| System and owner | Every later question needs 1 addressee | Business unit |
| Model and how it is reached | Consumed, fine tuned or self hosted | Engineering |
| Decision it informs | Drives Annex III classification | Business unit |
| Personal data involved | Triggers GDPR and Article 27 questions | Privacy |
| Classification and date | The compliance answer itself | Assurance |
| Last reviewed | Stale entries are worse than none | Assurance |
Six fields is deliberately austere. Inventories fail from ambition: a thirty column register is accurate for one quarter and abandoned in the second.
04Which obligations does the gap actually break?
| Obligation | Provision | Applies from |
|---|---|---|
| Measures supporting AI literacy, calibrated to context of use | Article 4 | 2 Feb 2025 |
| Transparency where people interact or content is generated | Article 50 | 2 Aug 2026 |
| Deployer obligations for high-risk systems | Article 26 | 2 Dec 2027 |
| Fundamental rights impact assessment | Article 27 | 2 Dec 2027 |
The first two rows are already live and neither is scoped to high-risk systems, which is why an incomplete inventory is a present problem rather than a 2027 one. The deferral of the high-risk block moved the deadline and not the work, as the obligations that survived the delay set out.
05How do you keep it from going stale?
Attach it to something that already happens.
The inventories that survive are the ones wired into an existing gate, such as procurement approval, architecture review or the change process. The ones that die are maintained by an annual survey, because the survey captures a moment and the estate moves.
A useful discipline is to make the classification field mandatory rather than the description. Teams will describe a system happily and skip the question that has consequences, so the field that must be filled is the one saying whether anyone believes this is high risk, and who signed that.
06What about consumer chatbot use by staff?
Treat it as a literacy and policy question, not an inventory row.
Individual use of a public assistant is real exposure, mostly around confidential data, and it does not usefully sit in a system register. Article 4 is the better instrument: the duty reaches other persons dealing with the operation and use of AI systems on your behalf, and a short, specific rule about what may be pasted into a public tool is literacy work that produces evidence.
The inventory should track systems that make or inform decisions. The policy should track what people may type. Confusing the two produces a register with four hundred entries and no owners.
07Frequently asked questions
What is shadow AI?
AI systems and services used inside an organisation without being registered, reviewed or governed. It ranges from an individual using a consumer chatbot for work, to a team wiring a model API into a production service without telling anyone.
How do you find unsanctioned AI use?
Combine four sources you already have: expense and card records, single sign-on and identity logs, network egress to known model endpoints, and a code search for provider SDKs and API key patterns. Each source finds a population the others miss.
Is shadow AI a security problem or a compliance problem?
Both, and the compliance side is usually underestimated. A system nobody has classified cannot have been assessed for high-risk status, which means every downstream obligation that depends on that classification has silently not been performed.
What is a realistic first target?
Complete coverage of systems that touch personal data or customer facing decisions, rather than complete coverage of everything. A list of forty systems with owners beats a list of four hundred entries nobody maintains.
08References and method
- Regulation (EU) 2024/1689, Article 4 (AI literacy, as replaced by the Digital Omnibus) and Article 26 (deployer obligations), for the duties that are scoped by the systems in use and therefore depend on an inventory.
- Regulation (EU) 2024/1689, Article 6 and Annex III, for the classification step that every later obligation is scoped by.
- Regulation (EU) 2026/1744 of 8 July 2026, the Digital Omnibus on AI, published 24 July 2026 and in force from 27 July 2026, for the replacement of Article 4 and for the application dates of 2 December 2027 and 2 August 2028 in Article 113. Consolidated text of the AI Act as at 27 July 2026 consulted on 16 September 2026.
- ISO/IEC 42001:2023, Annex A, for the control areas covering use of AI systems and third-party relationships.
- The four detection sources and their coverage gaps are editorial, prepared by The Guardrail from ordinary asset discovery practice. They are not drawn from a published standard.