Shadow AI and the EU AI Act: Why You Cannot Comply With an Estate You Cannot See

Shadow AI appeared in 43% of the security incidents analysed in IBM's Cost of a Data Breach Report 2026, published 29 July 2026. IBM's wording is that the figure "more than doubled to 43% this year from 20% last year". The average shadow AI breach cost USD 5.39 million, against a global average of USD 4.99 million and up from USD 4.63 million. And for the first time IBM measured regulatory outcomes: 21% of shadow AI incidents ended in a fine, with data loss or compromise in 49% of cases and reputational damage in 35%, up from 23%.

Across the same dataset, controls moved backwards year over year: IT approval required before deploying an AI tool, 45% down to 38%; AI governance technology, 39% to 33%; adoption of an AI governance framework, 39% to 33%; employee training on AI risks, 36% to 30%; regular audits for unsanctioned AI, 34% to 29%. Meanwhile 68% of breached organisations had no AI governance to manage AI or detect shadow AI, up from 63%, and only 32% had policies to manage AI and prevent shadow AI.

Exposure roughly doubled while the controls that address it were de-prioritised. The likeliest explanation is scheduling, not negligence. Regulation (EU) 2026/1744, the Digital Omnibus on AI, published in the Official Journal on 24 July 2026 and in force from 27 July 2026, deferred Chapter III Sections 1 to 3 to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I. Teams read that as runway. It is runway for classification and documentation, not for discovery. Every obligation live today already presumes you know what AI you run.

Shadow AI is shrinking, and that is not good news

The Netskope Cloud and Threat Report 2026, published 6 January 2026 on a data window from October 2024 to October 2025, found personal or unmanaged AI app use fell from 78% to 47% of generative AI users, while organisation-managed account use rose from 25% to 62%. Anyone selling undifferentiated shadow AI growth is not reading the data. But three things moved underneath that headline.

The overlap group grew, from 4% to 9% of users - people switching between personal and enterprise accounts for the same class of work. They have a sanctioned tool, they know the policy, and they still route certain tasks through an account you cannot log. A user with only a personal account is a provisioning failure. A user with both is a control-design failure.

The surface exploded. Netskope's tracked generative AI app catalogue grew fivefold, from 317 to over 1,600 apps, while the average organisation uses only eight. In the worst-controlled 1% of organisations, counts went from 47 to 89. An allow-list built for a 317-app market is not fit for a 1,600-app one, and the distance between that average of eight and the tail of 89 tells you the average is useless as a governance metric.

And growth is increasingly embedded rather than standalone. The Zscaler ThreatLabz 2026 AI Security Report, announced 27 January 2026 on 989.3 billion AI and ML transactions across roughly 9,000 organisations, is blunt: "Despite 200% AI usage growth in key sectors, many organizations still lack a basic inventory of AI models and embedded AI features, elevating AI governance to a board-level priority."

Zscaler also reports enterprises blocked 39% of all AI and ML access attempts in 2025, and their conclusion matters more than the number: blocking does not reduce use. Users shift to unsanctioned alternatives, personal accounts, or AI features embedded in already-approved SaaS platforms, where oversight is weaker than in the tool you blocked. A block-list converts a logged risk into an unlogged one.

Why you cannot survey your way to an AI inventory

Most AI inventory programmes begin with a questionnaire to business unit leads. That method has a measurable ceiling. The KPMG and University of Melbourne global study on trust, attitudes and use of AI, released April 2025 across more than 48,000 people in 47 countries, found 57% of employees hide their AI use and pass AI-generated work off as their own. Only 40% said their workplace had a generative AI policy, and almost half admitted using AI in ways that contravene company policy, including uploading sensitive company information to free public tools.

If a majority of staff conceal their usage, a self-declaration instrument cannot produce a valid AI inventory. It produces a census of the compliant: biased toward systems that were already going to be registered, blind to the ones that generate incidents. The undercount is not noise; it correlates with risk. Declaration is one layer of discovery, not the method.

What is actually live today

Start here, because most vendor content will not: the EU AI Act contains no article requiring you to "maintain an AI inventory". The obligation is implied rather than stated - and unavoidable, because none of the duties below can be discharged by an organisation that does not know what it runs. Dates follow the Commission's implementation timeline.

Obligation	Status, September 2026	Why it presumes an inventory
Article 4, AI literacy	In force since 2 February 2025, enforceable from 2 August 2026 by national market surveillance authorities	Covers all AI systems, not only high-risk. You cannot target measures at user groups you have not identified
Article 49, EU database registration	Live since 2 August 2026	Needs per-system role, classification and status, including systems self-assessed as not high-risk
Articles 72 and 73, post-market monitoring and incident reporting	Live since 2 August 2026	Clocks run in days. System-to-owner-to-authority mapping must pre-exist the incident
Article 26, deployer obligations	2 December 2027 (Annex III) / 2 August 2028 (Annex I)	Oversight, log retention, worker information and DPIA linkage are per-system duties
Article 27, fundamental rights impact assessment	2 December 2027 / 2 August 2028	Its six mandatory elements are effectively a field schema

Article 4 is live, and its text changed

Article 4 was rewritten in full by the Digital Omnibus. The current text provides that providers and deployers "shall take measures to support the development of AI literacy of their staff" and adds that "this obligation does not require providers or deployers to guarantee any specific level of AI literacy of any individual". That converts an obligation of result into an obligation of means.

Flag this internally: a lot of 2025-era content still quotes the superseded wording about ensuring "to their best extent, a sufficient level of AI literacy" as though it were current law. The change means a lower bar on outcomes and a higher bar on evidence: you are assessed on the design and delivery of your measures, which means showing which staff groups use which systems and what they were given. Article 4 covers all AI systems, not only high-risk, which makes it the only inventory-forcing duty that is live and enforceable today.

The Article 49(2) trap

Article 49 has been live since 2 August 2026 and is untouched by the Chapter III deferrals. Providers register Annex III high-risk systems in the EU database. The provision people miss is Article 49(2): a provider who concludes under the Article 6(3) derogation that an Annex III system is not high-risk must still register it. The negative determination is itself registrable. This catches far more organisations than expected, because the Article 6(3) route is taken precisely by teams who believe they have exited the regime. They have exited the conformity obligations, not registration. Article 49(3) separately requires public-authority deployers to register themselves and their use. Your AI register therefore needs a field not only for the classification but for the reasoning, date and author, because the derogation claim is what you will be asked to defend.

The two-day clock

Article 73, also live since 2 August 2026, sets the serious incident clocks: 15 days generally, 10 days on the death of a person, 2 days for widespread infringements and Article 3(49)(b) incidents.

A two-day clock is unmeetable if you cannot identify, within hours, which system was involved, who owns it, which provider to notify and which market surveillance authority is competent. That mapping is the register. Everything else in a register is documentation; this is operational capability, and it is the argument for the board that has been told the AI Act is a 2027 problem.

What Articles 26 and 27 demand of the same dataset

Article 26 does not bite until 2027 or 2028, but its content tells you which fields to capture now. Deployers must assign human oversight to competent, trained and authorised natural persons (26(2)); monitor operation, suspend use and notify (26(5)); keep the automatically generated logs, to the extent they are under their control, for at least six months (26(6)); inform workers' representatives and affected workers before putting a high-risk system into use at the workplace (26(7)); verify EU database registration and not use an unregistered system, for public-authority deployers (26(8)); and use the Article 13 information to feed the GDPR Article 35 DPIA (26(9)).

Article 27 requires a fundamental rights impact assessment from bodies governed by public law, private entities providing public services, and deployers of Annex III points 5(b) and 5(c) - creditworthiness and credit scoring, and risk assessment and pricing in life and health insurance. Its six mandatory elements: the deployer's processes using the system; the period and frequency of intended use; the categories of persons and groups affected; the specific risks of harm; how human oversight is implemented; and mitigation measures, including internal governance and complaint arrangements. Results go to the market surveillance authority on an AI Office template, whose publication is not yet confirmed. Read those six elements as fields rather than prose and you have a minimum schema.

A regulator is already counting

The Dutch data protection authority, Autoriteit Persoonsgegevens, published its sixth Rapportage AI & Algoritmes Nederland on 5 March 2026, calling for mandatory algorithm and AI registration by government organisations. The reported figures, and they are reported rather than audited: roughly 1,000 algorithms registered since 2023, over half of municipalities non-compliant, only 5% having undergone a FRIA. The AP names organisations' inadequate understanding of their own existing algorithms as one of the largest current algorithmic risks in the country. Registration completeness is already a supervisable metric in at least one Member State, ahead of the Chapter III dates.

Where the frameworks actually put this

Two corrections, because most vendor material gets both backwards.

NIST AI RMF. The inventory duty sits in GOVERN, not MAP. The controlling subcategory is GOVERN 1.6: "Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities." NIST defines an AI system inventory as "an organized database of artifacts relating to an AI system or model", which may include system documentation, incident response plans, data dictionaries, links to implementation software or source code, and contacts for relevant AI actors. MAP is where you characterise context and risk per system; GOVERN 1.6 is where the duty to hold an inventory, and to resource it, lives. File it under MAP and you will treat it as a per-project artefact rather than a funded enterprise capability (NIST AI RMF Playbook).

ISO/IEC 42001:2023. The standard has 38 Annex A controls across 9 objectives, and none is named "AI system inventory". The closest fit, and what auditors work from, is A.4.2 "Resource documentation", requiring documented resources - data, tooling, system and computing, and human - for each AI system, with sibling controls A.4.3 to A.4.6. So do not write that ISO 42001 requires an AI inventory; write that A.4.2 requires documented resources per AI system, which in practice is implemented as one. NIST publishes an official crosswalk.

What goes in the register

The field set below is derived from the legal text - Annex VIII, Article 26, Article 27 - and from NIST GOVERN 1.6, not from a vendor data model.

Annex VIII Section A supplies the provider baseline: name, address and contacts; the submitting person; the authorised representative; trade name plus "any additional unambiguous reference allowing identification and traceability"; intended purpose, components and functions; data, inputs and operating logic; status; notified body certificate type, number and expiry; Member States of availability; the declaration of conformity; instructions for use. Section C adds, for public-sector deployers, deployer contacts, the URL of the provider's database entry and summaries of the FRIA and DPIA.

These operational fields sit on top of that base, each mapped to the provision forcing it.

Field	Forced by
Internal ID, trade name, unambiguous reference, version	Annex VIII Section A
Role per system: provider / deployer / importer / distributor	The whole Act. This single field drives everything else
Provider and authorised representative, contract or DPA reference	Annex VIII Section A; Article 26
Intended purpose, components and functions, data and inputs, operating logic	Annex VIII Section A
Risk classification, justification, date and author, including any Article 6(3) reasoning	Articles 6 and 49(2)
Status: on the market / in service / withdrawn / recalled	Annex VIII Section A
Deployment: Member States, business units, user groups, workplace use	Annex VIII Section A; Article 26(7)
Personal data yes/no, categories, DPIA reference	Article 26(9)
FRIA reference and summary of findings	Article 27; Annex VIII Section C
Logs: whether under your control, where retained, retention of six months minimum	Article 26(6)
Human oversight: named person, evidence of competence and authority	Article 26(2)
AI literacy: which user groups, which training, delivered when	Article 4
Incident routing: competent authority, provider contact, owner of the 2 / 10 / 15-day clocks	Article 73
EU database entry URL	Articles 49 and 71
Artefact links: technical documentation, instructions, declaration of conformity, post-market monitoring plan, model and system cards, repository	NIST GOVERN 1.6

On the role field: organisations routinely record themselves as deployer after fine-tuning or rebranding a system, either of which can make them a provider. Get it wrong and every other cell in that row is wrong too.

How to find what you have

Discovery has to be layered, because declaration systematically under-counts. Six sources:

1. Network, CASB and SSE telemetry. The long tail beyond your eight sanctioned tools.
2. SSO and OAuth grant review. Tools authorised against corporate identity without procurement. Review grants, not just apps.
3. Expense and corporate card data. Personal subscriptions reimbursed as expenses - the cheapest high-yield source most programmes skip.
4. SaaS vendor AI feature release notes. Embedded AI inside already-approved tools is the biggest blind spot, per Zscaler, and telemetry cannot separate it from ordinary use of the platform.
5. A procurement gate. Not to block, but so anything bought from today arrives with a role, an owner and a classification.
6. Code repository scanning. Model calls, keys and dependencies in systems your engineers built rather than bought - where you are the provider.

Alongside discovery you need an AI acceptable use policy that is enforceable rather than aspirational. Three properties matter: it names the sanctioned tools explicitly rather than describing categories; it names the data classes that may never be pasted into any model; and it gives people a fast path to request a new tool, with a published turnaround time.

That last property makes the first two work. Zscaler's 39% block rate coexists with continued growth in AI use, and Netskope's overlap group is the same phenomenon from the identity side. If the only answer is "no", or takes six weeks, you have not prevented the use. You have only stopped seeing it.

The first 90 days

Days 1 to 30, establish the baseline. Pull 90 days of network, CASB and SSE telemetry for AI destinations and reconcile it against your tool list. Export SSO and OAuth grants. Query expense data for AI vendor names. Stand up the register in whatever you already have, with role and incident-routing fields mandatory from day one - a spreadsheet with the right fields beats a platform with the wrong ones. Confirm which market surveillance authority is competent for you in each Member State.

Days 31 to 60, close the enforceable gaps. Articles 4 and 73 are live, so treat them as the deadline. Map user groups to systems, deliver targeted AI literacy measures, record what went to whom and when. Build the incident runbook against the 2, 10 and 15-day clocks and tabletop it. Review every Annex III system carrying an Article 6(3) derogation claim and confirm it is registered under Article 49(2). Publish the AI acceptable use policy with the fast-path route live, not promised.

Days 61 to 90, make it durable. Add the procurement gate. Start the repository scan for systems where you are the provider. Begin Article 26 and 27 field capture for systems likely to be in scope in December 2027, using the six FRIA elements as the schema. Set the recurring cadence - monthly telemetry reconciliation, quarterly OAuth review, continuous vendor release-note monitoring - and satisfy the second clause of GOVERN 1.6 with a real budget, because a mechanism that is not resourced to risk priorities does not meet it.

None of this depends on the deferred dates. The deferral bought time to classify and document. It bought none on knowing what you run, and the duties live right now all start from that assumption.