For about eighteen months, every article on this subject pointed to the same date. 2 August 2026 was when the EU AI Act’s obligations for high-risk AI systems were due to take effect, and it did a lot of work in a lot of sales decks.
On 7 May 2026, negotiators from the European Commission, the European Parliament, and the Council of the European Union reached a provisional agreement on the Digital Omnibus on AI. Under it, those high-risk obligations are postponed by more than a year—stand-alone Annex III systems move to 2 December 2027, and AI embedded in regulated products under Annex I to 2 August 2028.
So if you have been carrying a vague sense that something lands next week, it probably does not. And if you are about to conclude that the whole thing can wait until 2027, that is the wrong lesson, for a reason that has nothing to do with regulators.
The pressure that is actually reaching small and mid-sized businesses in 2026 is not coming from enforcement. It is coming from procurement.
Table of contents
- What changed in May 2026, precisely
- Does the EU AI Act even apply to you?
- The pressure that didn’t move: procurement
- ISO 42001 and NIST AI RMF: which one, and why
- The risk most businesses actually have
- What a minimum viable AI policy contains
- How to build an AI inventory in an afternoon
- What not to do
- FAQs
What changed in May 2026, precisely
Three things are worth separating, because most coverage blurs them.
What moved. The obligations for high-risk AI systems. Under the provisional Digital Omnibus agreement, Annex III stand-alone high-risk systems now face a compliance date of 2 December 2027, and Annex I systems — AI embedded in products already regulated under EU product-safety law — move to 2 August 2028.
What did not move. The AI Act’s earlier phases are already in force and are unaffected by this postponement. The prohibitions on certain AI practices and the AI literacy obligations came into application first, and the general-purpose AI model provisions followed. If you assumed the whole Act was pending, it is not.
What is not yet final. This is a provisional agreement. It requires formal adoption and publication in the Official Journal to take legal effect, and the delay is contingent on that enactment. Any date in this article should be re-checked against the AI Act implementation timeline — a widely used independent tracker, not an EU institution — before you rely on it for planning. This is exactly the kind of moving target where a six-month-old blog post becomes actively misleading.
TechyKnow’s read: treat the postponement as real for planning purposes and provisional for compliance purposes. Do not cancel work on the assumption it is confirmed.
Does the EU AI Act even apply to you?
This is the question the competing guides skip, and skipping it is what lets them tell every reader they have an urgent problem.
The AI Act regulates AI systems by risk category, not by company size. The obligations that carry serious cost attach to high-risk systems — the Annex III list covers areas such as biometrics, critical infrastructure, education, employment, law enforcement, migration and border control, and the administration of justice.
Read that list against what your business actually does. If you use AI to screen job applicants, you are in scope of an employment-related high-risk category. If you use it to draft marketing copy, summarise meetings, generate images or answer customer questions about opening hours, you are not deploying a high-risk system, and the heavy Annex III obligations were never aimed at you.
Two things are still true even then. Territorial reach is broad — the Act can apply to providers and deployers outside the EU where the output is used in the EU — so “we are not an EU company” is not by itself an answer. And the earlier-phase obligations, including AI literacy expectations for staff who use these systems, are not conditional on being high-risk.
The honest summary for most small and mid-sized businesses: you probably do not have an EU AI Act high-risk problem, and you very likely do have an AI governance problem. Those are different, and conflating them is how businesses end up buying compliance consultancy for a risk they do not have while leaving the risk they do have untouched.
The pressure that didn’t move: procurement
Here is what is actually reaching businesses in 2026, and it arrives by email rather than by regulator.
Customer security questionnaires have started asking about AI. Where the vendor due-diligence pack used to ask about data location and breach notification, it now asks which AI tools process customer data, whether that data trains anyone’s models, who is accountable for AI-assisted output, and whether you hold a certified AI management system.
That last question increasingly names ISO/IEC 42001 specifically. Reporting across the AI vendor market through 2026 describes the same pattern repeatedly: procurement teams have started asking for it by name, and it is shifting from a differentiator to something closer to table stakes for companies selling into larger organisations.
This is the mechanism by which regulation reaches small businesses even when it does not apply to them directly. Your enterprise customer is in scope. Their compliance obligation becomes a contractual requirement flowed down to you. Nobody at a regulator ever contacts you; you simply lose the deal.
Which is why the May postponement changes the deadline but not the work. The regulatory clock slipped by sixteen months. The sales-cycle clock did not slip at all.
ISO 42001 and NIST AI RMF: which one, and why
These two get mentioned together constantly and do genuinely different jobs. The distinction is simple enough to settle in a table.
| ISO/IEC 42001 | NIST AI Risk Management Framework | |
|---|---|---|
| What it is | A management system standard for AI, in the same family as ISO 27001 | A voluntary risk-management framework |
| Certifiable? | Yes — external audit by an accredited body, with surveillance audits and periodic recertification | No — there is no certification to hold |
| What you get | A certificate you can put in a procurement response | A structured way to think about and document AI risk |
| Cost profile | Audit fees, plus the documentation work to become auditable | Internal effort only |
| Best for | Selling to organisations that ask for evidence | Building the underlying discipline, at any size |
The sequencing most teams settle on is to use NIST AI RMF first to establish the vocabulary and the lifecycle discipline, then layer ISO 42001 certification on top once the documentation exists and there is a commercial reason to be audited.
For a business under roughly fifty people with no enterprise customers asking, certification is usually premature. Skipping the underlying discipline is not — because the discipline is what the questionnaire is really testing, and you will need it the first time a customer asks whether their data trains a model.
The risk most businesses actually have
Set the regulation aside for a moment. In our assessment, the exposure that most commonly bites is not compliance at all. It is that nobody knows what is running.
Staff adopt AI tools individually, usually with good intentions and often on free tiers, and the organisation finds out later. This is shadow AI, and it is the same shape as the shadow IT problem that preceded it — with one meaningful difference. Shadow IT usually meant an unsanctioned app. Shadow AI usually means an unsanctioned app that has been given your data.
The concrete failures follow from that:
- Confidential data leaves via a free tier. Free and consumer plans frequently carry different data-handling terms from the paid business tiers, including on whether inputs may be used to improve models. Most staff never read them.
- Nobody owns the output. AI-assisted work reaches a customer with a factual error, and there is no record of who checked it or whether anyone did.
- Credentials sit somewhere web-reachable. Provider API keys end up in environment variables on servers that were stood up quickly to prototype something. This is not hypothetical; it is precisely how the exposure that TechyKnow covered in 175,000 publicly exposed APIs happens, and AI orchestration tools have made it more common.
- A tool gets write access nobody scoped. As organizations move from assistants to systems that act, the permissions question stops being an IT detail. This is the practical governance issue behind the agentic AI shift.
None of these require a regulator to become expensive. They require one bad afternoon.
What a minimum viable AI policy contains
An AI governance policy for a business of twenty or two hundred people does not need to be long. It needs to be specific enough that someone can act on it without asking. Five sections do most of the work.
1. Scope and approved tools. A named list of AI tools staff may use, on which plan, for what kinds of work. Naming the plan matters as much as naming the tool, because the data-handling terms differ between tiers. Include the route for requesting a tool that is not on the list — if there is no route, people will simply not tell you.
2. Data rules. What must never be entered into an AI tool: customer personal data, credentials, unreleased financials, anything under NDA, source code if that is your position. Write these as concrete categories, not as “sensitive information,” which every employee interprets differently.
3. Human accountability. The rule that the person who submits AI-assisted work owns it. Name the categories that require a documented human review before anything leaves the organisation — customer communications, published content, code that reaches production, anything with legal or financial consequence.
4. Disclosure. When AI involvement must be disclosed, to whom, and how. Internally, externally, to customers, in published content. Ambiguity here is what produces the awkward conversations later.
5. Ownership and review. One named person accountable for the policy, and a fixed review date. Quarterly is realistic in a market moving this fast; annual is theatre.
That is a two-page document. It will not certify you against anything, and it addresses the majority of the practical risk. If a customer questionnaire later demands more, you extend it — but you extend something real rather than starting from nothing.
How to build an AI inventory in an afternoon
Every framework starts with an inventory, and most guides describe it as a major undertaking. At small scale, it is not.
- Export your card and expense records for the last twelve months and search for AI vendor names and app-store charges. This finds paid tools nobody registered.
- Ask, without consequences attached. A short anonymous form asking which AI tools people use and what for. This only works if it is explicitly amnesty — if answering can get someone in trouble, you will get a clean, useless result.
- Check what your existing software turned on. A significant amount of AI in most organisations arrived as a feature inside a tool already in use, and was enabled by default rather than chosen.
- List anything with an API key. Any server, script or automation holding a provider key belongs on the inventory, along with what else that host can reach.
- Record four fields per entry: tool, plan tier, what data it touches, who owns it. Not more. An inventory nobody maintains is worse than a short one that stays current.
That artefact is the foundation for everything above it, and you can produce a usable first version in a few hours.
What not to do
Do not buy a certification you have no commercial reason to hold. ISO 42001 has real value when a customer is asking for it. Bought speculatively, it is an audit bill attached to documentation nobody reads.
Do not ban AI outright. Bans move usage onto personal accounts and personal devices, where you have no visibility at all. This makes the shadow AI problem worse while producing a policy that looks decisive.
Do not copy a policy template unchanged. The approved-tools list is the part that matters and the part a template cannot supply. A generic policy that does not name your actual tools will be ignored within a month.
Do not treat the postponement as cancellation. The Digital Omnibus delay is provisional pending formal adoption, and the earlier phases of the AI Act are already in force. Re-check the position before making a planning decision on it.
The practical next step: build the inventory this week — steps one to five above, in an afternoon. Whatever any regulator or customer eventually asks you, the first question will be some version of “what AI are you using?” Not being able to answer is the only failure mode that is entirely within your control today.
