The Readiness Gap: Most Organisations Don't Know What AI They're Running

The AI You Didn't Buy

The board of a European insurer approves an "AI programme" of six projects, each with a sponsor, a budget, and a risk review. A year later, an inventory exercise finds many times that number. The CRM vendor switched on AI lead-scoring in a routine update. The applicant-tracking system now ranks candidates. Claims handlers use a free chatbot to draft letters. A finance analyst built a forecasting model in a spreadsheet add-in.

None of these went through the AI programme, because none of them looked like an AI project.

The gap: Most AI no longer arrives as a project. It arrives as a feature, a subscription, or an employee's sign-up, and it bypasses the governance built for projects. Many times, this happens transparently for the final user, and without any clear “opt-out” option.

The evidence:

• 78% of people who use AI at work bring their own tools (Microsoft and LinkedIn, 2024 Work Trend Index).
• 69% of organisations suspect or have evidence that employees use prohibited public generative AI tools (Gartner).
• One in five breached organisations in a study on over 600 companies had a breach linked to shadow AI, adding up to an average cost of USD $670,000, and 63% of breached organisations had no AI governance policy (IBM Cost of a Data Breach Report 2025).

Two real cases:

• AI inside software you already use: In May 2024, Slack customers discovered that the company's privacy principles allowed customer data to be used to train its platform-wide machine-learning models by default, with opt-out only by emailing Slack. Slack clarified the scope and updated the wording after the backlash (TechCrunch).
• AI brought in by employees: In 2023, Samsung engineers pasted confidential source code into ChatGPT, and the company banned generative AI tools on its devices and networks (Bloomberg).

The classification Issue: As we have seen in Article 1, the Act's first decision is classification. You cannot classify what you cannot see.

Why the Timeline Is a Visibility Problem

The EU AI Act does not regulate "AI" in general. It regulates specific systems in specific uses, one by one, so every obligation attaches to something an organisation must first know it has. You cannot switch off a prohibited practice you do not know is running, such as an emotion-analysis feature quietly enabled in a call-centre platform. You cannot support AI literacy without knowing who uses which tools. You cannot disclose a chatbot, label a deepfake, or mark AI-generated output without knowing which systems talk to customers or produce content. The same holds for what is coming: High-risk classification starts from a list of systems and what each is used for. Read this way, the timeline below is less a list of legal deadlines than a schedule for how quickly an organisation must be able to see its AI. Three of those deadlines have already passed.

Several obligations are already in force: prohibitions and AI literacy (February 2025), rules for general-purpose AI models (August 2025), transparency duties (August 2026). Watermarking and new prohibitions follow on 2 December 2026. The Digital Omnibus postponed only the high-risk regime, to December 2027 and August 2028.

Four Readiness Tests

To assess the readiness of your organization, consider the following four tests. Each test is a question an executive can put to the organisation this quarter, with examples and what a good answer looks like.

Test 1: Can you see it? (inventory)

Can we list every AI system we build, buy, or use, including AI features inside software we already have?

A five-category model for the inventory. A list of tool names is not an inventory. Each entry needs a few attributes that tell you, at a glance, what the Act is likely to require. We suggest describing every AI system through five categories:

This categorization was inspired by the OECD Framework for the Classification of AI Systems, which describes AI systems along five dimensions (people and planet, economic context, data and input, AI model, task and output); NIST AI RMF GOVERN 1.6, which calls for an AI inventory with a named owner, resourced according to risk; the OWASP LLM AI Cybersecurity & Governance Checklist, whose asset-inventory section asks for owners, data sensitivity and AI components in the software bill of materials; and the OWASP AIBOM project, which extends the CycloneDX format to record in-house models, datasets and their provenance.

Example: The applicant-tracking system's new ranking feature reads as embedded · scores people · decisions about applicants · personal data · vendor can change it, no independent test. That profile flags it straight away for Test 2 as a likely high-risk use, with you as deployer and a vendor relationship that needs tightening.

The desired outcome: a living inventory with a named owner, fed by procurement, IT asset management and security's discovery tools (network and SaaS monitoring), and updated when vendors change features, not once a year.

The Executive takeaway: Ask who owns the inventory, how it learns about AI that arrives in updates, and when it was last reconciled.

Test 2: Can you risk assess it? (classification)

For each system, do we know whether it is prohibited, high-risk, subject to transparency duties, or minimal risk?

The asset inventory, adequately defined via the five categories we’ve established in Test 1, can be processed according to the requirements of the risk assessment definitions of the AI Act.

The desired outcome: a documented decision for each system, with an owner, the evidence behind it, and a trigger to re-check it when the system or its use changes.

The Executive takeaway: Ask how many systems have a recorded classification, and who signed each one off.

Test 3: Are you a provider or a deployer? (role definition)

For each system, are we the provider (we build it and put our name on it) or the deployer (we use it)?

The desired outcome: The role is recorded for each system and reflected in contracts, including who keeps the logs and who reports incidents.

The Executive takeaway: Most organisations are both provider and deployer, often without realising it, and a single change can move them from one to the other. We will unpack this in the next article in the series: Why the question "are we a provider or a deployer?" defines your real exposure.

Test 4: Have you met what already applies? (live obligations)

Have we met the obligations that are already in force, or will be by December?

What the Commission's guidelines add: A disclosure must be clear at the point of contact. Burying it in terms and conditions, relying on metadata alone, or using a vague name such as "assistant" is not enough. Deepfakes must be labelled whether or not the intention is to deceive, and the exception for AI-generated text needs genuine human review and editorial responsibility, not a quick check. There is no exemption for small companies.

The desired outcome: a checklist of current obligations, each with an owner and a status, reviewed by the executive team before 2 December 2026.

Executive takeaway: These duties apply now. They are the first thing a customer, auditor or regulator will ask about.

 What good looks like in 90 days

• Days 1 to 30, See it: Name one owner for the AI inventory. Run discovery across procurement records, SaaS, and network monitoring, and a short staff survey on the tools people actually use. Stop any prohibited practice found.
• Days 31 to 60, Sort it: Classify every system found, and record whether you are provider or deployer. Close transparency gaps. Confirm machine-readable marking for any generative features before 2 December.
• Days 61 to 90, Sustain it: Put AI literacy measures in place for staff who use AI. Add AI checks to procurement and vendor-change reviews, with contract clauses on feature changes and logs. Report the inventory, classifications, and open gaps to the executive committee.

The outcome: by day 90, leadership can answer the four questions with evidence rather than assurances.

The Delay Trap

• The Omnibus is widely read as "the AI Act has been postponed." It postponed only the high-risk regime.
• Enforcement capacity is still being built: As of June 2026, less than half of 27 the member states had clearly designated both their market surveillance and their notifying authorities (eu tracker).
• A quiet regulator is not an absent obligation. Obligations bind from their application date whether or not an authority has been named, and customers, auditors, and procurement teams are already asking.
• The Commission published its final Code of Practice on marking and labelling AI-generated content on 10 June 2026, and its guidelines on the Article 50 transparency obligations on 20 July 2026. Both the practical standard and the official interpretation now exist, so "we were waiting for guidance" no longer holds.

In Closing

Four questions for your next executive meeting:

1. Can we see every AI system we build, buy, or use, including AI inside existing software?
2. Has each one been classified, with an owner and evidence?
3. Do we know where we are provider and where we are deployer?
4. Have we met the obligations already in force, and are we ready for 2 December?

Bridge to Article 3: Question 3 is where most organisations underestimate their exposure. We will explore this in the next article.

SANS recently published the 2026 SANS EU AI Act Preparedness Survey. We greatly appreciate you taking the time to share your experience and expertise for the benefit of the community. Your real-world feedback supports SANS research, which is widely used by CISOs and decision makers to benchmark programs, guide strategy, and justify investments in tools, staffing, and training.