EU AI Act: what Irish SMEs must do now

Lab0 Engineering · Published 1 August 2026 · Updated 1 August 2026

For most of the last two years the EU AI Act was something businesses planned around rather than lived with. That period is over. The obligations are in force, and the practical question has shifted from "when does this start" to "which parts already apply to us".

The one-paragraph status

The AI Act is a risk-based framework: obligations scale with what an AI system is used for, from essentially nothing at the minimal-risk end to a substantial compliance regime at the high-risk end, with a small set of prohibited uses banned outright. It came into force in stages. The prohibitions on unacceptable-risk uses and the AI-literacy duty applied from February 2025. Obligations on general-purpose AI models followed in August 2025. The high-risk obligations took effect in August 2026. All three sets of duties are live now.

Does the Act apply to you?

Almost certainly, in the sense that some part of it touches any business using AI. But the weight of it depends entirely on what you use AI for, and for most small and medium-sized businesses the honest answer is that the burden is light.

The great majority of everyday business AI sits in the minimal or limited-risk tiers: drafting and summarising text, internal document search, meeting notes, demand forecasting, code assistance, marketing copy. These carry no substantive compliance regime. They do not become high-risk because they are useful, or because they involve a large model.

Limited risk mainly means transparency. Where an AI system interacts directly with people, those people must be able to tell that they are dealing with a machine rather than a person, unless the context makes that obvious anyway. If you run a customer-facing chatbot, say so plainly in the interface. AI-generated or manipulated content carries its own marking and disclosure duties.

High risk is a defined list, not a judgement call, and in plain English the categories that most often catch an ordinary business are these:

• Employment decisions. Screening or ranking job applicants, and AI used in decisions about promotion, task allocation or termination.
• Access to essential services. Creditworthiness assessment and credit scoring, and eligibility decisions for public benefits.
• Education and training. Determining admission, evaluating learning outcomes, or scoring examinations.
• Safety components of regulated products. Where AI forms part of a product already governed by EU product-safety law.
• Biometrics, critical infrastructure, law enforcement, migration and justice. Specialised areas that most SMEs never touch, but which are firmly in scope when they do.

The pattern is consistent: a use becomes high-risk when the system's output materially affects a person's rights, livelihood or safety. If your AI recommends stock levels, that is not it. If your AI ranks candidates, it is.

One more point that catches people out. Your role matters as well as your use. A business that builds or substantially modifies an AI system carries provider obligations; a business that simply uses someone else's system in its own operations carries the lighter deployer obligations. Rebranding a bought-in system as your own, or repurposing it for something the vendor did not intend, can move you from one category to the other.

What human oversight actually means in practice

Human oversight is the requirement most often claimed and least often implemented. A dashboard showing what the AI did last week is monitoring, not oversight. Oversight means a person can actually change the outcome.

Concretely, four things have to be true. First, decisions have to be logged in enough detail to reconstruct them afterwards: what the system saw, what it produced, and on what basis. Second, actions with consequences need an approval gate, so a person confirms before the effect lands rather than being informed after it. Third, there has to be a real stop: the ability to override an individual decision and to halt the system entirely, available to someone who is present when it matters and not only to an administrator on another continent. Fourth, the reviewer needs enough explanation to disagree on informed grounds — a recommendation with no visible reasoning cannot be meaningfully approved, and approval that is always granted is not oversight either.

The competence point follows from that. The person overseeing the system must understand it well enough to spot when it is wrong, which is a training and staffing question rather than a software one.

A pragmatic five-step compliance posture for an SMB

You do not need a compliance department. You need to be able to answer questions about your own systems.

1. Inventory your AI uses. Write down every place AI touches the business, including tools individual teams adopted without a procurement process and AI features switched on inside software you already licence. This step usually turns up more than expected, and you cannot classify what you have not listed.
2. Classify each one by risk tier. Prohibited, high, limited or minimal, and note whether you are acting as a provider or a deployer. Most entries will resolve to minimal in a sentence. The few that do not are where your attention belongs.
3. Document what each system does. Purpose, data it uses, who is accountable for it, what happens when it is wrong. A page per system is usually enough, and it is the artefact that makes every later question answerable.
4. Build logging and human oversight into the workflow. Not as a review meeting bolted on afterwards, but in the system itself: an audit trail of decisions, and an approval gate on anything consequential. Retrofitting this is considerably more expensive than designing it in.
5. Review annually, and whenever something changes. New tools, new uses of existing tools, and changes to what a vendor's product does all reopen the classification. An annual pass keeps the inventory from going stale.

Two of those steps are documentation you could complete this month. That is the realistic starting point for most businesses.

How Lab0 builds for this by default

We designed our approach around these controls before they were obligations, because systems that cannot explain themselves are difficult to operate regardless of regulation. Every system we build logs its decisions with the context behind them, so an audit trail exists as a by-product of normal operation rather than as a reporting exercise. Actions that carry consequences pass through explicit approval gates, with a human in the loop by default and automation granted only where the risk genuinely warrants it. Where a system produces a recommendation, it surfaces the material it relied on, which is what makes a reviewer's approval meaningful. Our AI with guardrails service covers this in detail.

The commercial point is simple: the same properties that satisfy an auditor are the ones that let you trust a system enough to widen its remit. If you are scoping a project now, building these controls in from the start costs far less than adding them to something already in production — and if you are an Irish business, our guide to AI grants in Ireland covers schemes that can offset part of that work.

Last updated: August 2026

← Back to Insights