By now most leadership teams know what the AI Act is. The harder questions are the specific ones. Which of our tools actually count as AI systems? Are we the provider or the deployer? Is anything we run high-risk, and what would we show a regulator or an enterprise customer if they asked tomorrow?
That's where we start. We help organisations operating in Ireland map their AI, pin down their role under the Act, work out which obligations genuinely apply, and build the governance and evidence to back it up.
The AI Act is an EU Regulation, so it has applied directly in Ireland since it entered into force on 1 August 2024. What changed this summer is the machinery around it.
The Regulation of Artificial Intelligence Act 2026 was signed into law on 21 July 2026, and the AI Office of Ireland (Oifig IS na hÉireann) was established on 30 July as the central coordinating authority and single point of contact for the AI Act. The Government has been clear that the Irish Act is a technical implementing measure. It doesn't add obligations on top of the EU Regulation. It gives Irish regulators the powers to supervise and enforce it, from compliance notices through to administrative sanctions.
Ireland chose a distributed model. Fifteen competent authorities were designated in September 2025, and in practice many organisations will deal with a regulator they already know, such as the Central Bank of Ireland for regulated financial services, the Competition and Consumer Protection Commission, or Coimisiún na Meán. The AI Office of Ireland coordinates across them.
There's also an EU layer that matters more here than almost anywhere else. Ireland hosts the European headquarters of a lot of technology companies, including general-purpose AI model providers, and the European Commission's AI Office supervises general-purpose AI models directly. If your group sits in that picture, your supervisory map may involve both Brussels and Dublin.
None of this means every organisation carries the same obligations. What applies to you depends on your role, the AI systems involved and what they're used for. Working that out properly is the first job.
Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026 and moved the high-risk dates. Plenty of material online still shows 2 August 2026 as the high-risk deadline. It isn't any more.
Last reviewed 21 September 2026 against EUR-Lex and the Commission's AI Act Service Desk. We update this page when dates or guidance change.
Your obligations follow your role, and your role is decided system by system. The same company can be a provider for the AI feature it ships and a deployer for the HR tool it licenses. Here's how the Act draws the lines.
You develop an AI system or GPAI model, or have one developed, and place it on the market or put it into service under your own name or trademark, whether you charge for it or not.
Typical case: an Irish SaaS company that builds AI-driven candidate ranking into its platform and sells it across the EU.
This sounds like usYou use an AI system under your authority in a professional capacity. Most organisations are deployers of something, often many things.
Typical case: a lender using a third-party model to assess creditworthiness, or an HR team using an AI screening tool.
This sounds like usYou're located or established in the EU and place on the EU market an AI system carrying the name or trademark of a provider established outside the EU.
Typical case: an Irish entity bringing a US vendor's AI product to EU customers under the vendor's brand.
This sounds like usYou're in the supply chain, but not the provider or importer, and you make an AI system available on the EU market.
Typical case: a reseller or systems integrator supplying a third-party AI product to Irish and EU clients.
This sounds like usYou're established in the EU and hold a written mandate from a non-EU provider to carry out specified obligations on its behalf.
Worth checking: if you're the EU entity of a non-EU group, confirm whether you are acting as representative, importer, distributor, or in fact the provider.
Under Article 25, a deployer, importer or distributor can become the provider of a high-risk system by putting its own name on it, making a substantial modification, or changing its intended purpose so it becomes high-risk.
Not sure which applies? Start hereYou can't classify what you haven't found. And in most organisations the AI that matters isn't the model the data science team built. It's the scoring feature switched on in a SaaS platform two years ago.
We build the inventory with your system owners, procurement and IT rather than from a questionnaire nobody fills in. The aim is one register that legal, risk, security and product can all work from, and that stays current after we leave.
| Field | Why it matters |
|---|---|
| System, owner, vendor | Accountability, and who you'll need information from |
| Built, bought, embedded or GPAI-based | Drives your likely role and what the vendor owes you |
| Intended purpose and business use | Classification turns on purpose, not on the technology |
| Who it affects | Employees, customers, applicants or the public change the risk picture |
| Data used | Personal and special category data links you to GDPR and DPIAs |
| Deployment context | Internal or customer-facing, which EU markets, decision or support |
| Role and initial classification | The starting point for the obligation map |
| Evidence already held | So you don't rebuild what already exists |
People often picture the AI Act as a pyramid with four neat boxes. In practice we treat classification as a set of questions asked in order, because one system can trigger more than one set of rules. A high-risk system can also carry transparency duties.
A caution on examples. "Recruitment AI is high-risk" is a useful rule of thumb, not a classification. The answer depends on the intended purpose, what the system actually does, and how it's used. Annex III even carves out AI used to detect financial fraud from the creditworthiness category. That's why we classify from your inventory data and record the reasoning, rather than tagging systems from a generic list.
Our readiness assessment tells you where you stand today against the obligations that actually apply to you, and what to do about the gaps in what order.
It's a structured review, not a desk exercise. We interview system owners, look at the documentation and controls you already run (ISO 27001, GDPR records, vendor due diligence, model documentation), test a sample of systems end to end, and map it all back to specific articles of the Act and, where relevant, to Irish supervisory expectations.
The timeline depends on how many systems you have and how mature your records are. We agree scope and duration in writing before we start.
Request an EU AI Act AssessmentClassification tells you which rules apply. A risk assessment tells you what could actually go wrong with a given system and whether your controls are enough. They're different exercises and you need both.
Article 9 requires a risk management system that runs across the whole lifecycle: identifying known and foreseeable risks to health, safety and fundamental rights, estimating them, adopting measures and testing. We help you design it so it produces evidence as a by-product, not as an afterthought.
Public bodies, private entities providing public services, and deployers using AI for creditworthiness or life and health insurance pricing must complete a fundamental rights impact assessment (Article 27) before first use. Since the Omnibus it can cross-reference your GDPR DPIA rather than duplicate it.
Even where the Act doesn't mandate one, a proportionate AI risk assessment is how you decide what's acceptable. It's also the backbone of ISO/IEC 42001's AI risk and impact assessment, if you're heading that way.
AI risk isn't only regulatory. Prompt injection, data leakage through retrieval, and over-permissioned agents are security problems first. Where it makes sense, we pair the governance work with AI and LLM penetration testing so the risk register reflects how your systems behave under attack, not just on paper.
Obligations stick when there's a working structure behind them: named owners, a real approval step, and records produced as part of normal work. Here's what we help you put in place, and where the Act itself speaks to it.
| Area | What good looks like | Link to the AI Act |
|---|---|---|
| Ownership and accountability | A named owner per system, a governance forum with decision rights, and escalation paths | Not prescribed as such; underpins every obligation. Central to ISO/IEC 42001 |
| Policies and approval | An AI policy, acceptable-use rules, and a gate before new AI goes live or gets repurposed | Good practice; a change of intended purpose can alter your role under Article 25 |
| AI literacy | Role-based training, tracked, matched to what people actually do with AI | Article 4, for all providers and deployers |
| Human oversight | Named, trained people with the authority to intervene or override | Articles 14 and 26(2), for high-risk systems |
| Vendor governance | AI questions in due diligence, contractual access to documentation and logs | Article 25(4) written agreements for high-risk suppliers; Article 26 relies on provider instructions |
| Record keeping | Logs retained, documentation versioned, decisions traceable | Articles 12, 18, 19 and 26(6), for high-risk systems |
| Monitoring and incidents | Performance and drift monitoring, a route for staff to report issues, defined incident handling | Articles 72 and 73 for providers; Article 26(5) for deployers of high-risk systems |
| Transparency | Disclosure wording, content labelling, and notices to people affected | Article 50; Article 26(11) for Annex III decisions about people |
Eight stages, run in sequence the first time and on a cycle after that. New systems, vendor changes and new guidance all loop back to the start.
Build the inventory across products, business units and vendors.
Provider, deployer, importer, distributor or representative, per system.
Prohibited, high-risk, transparency or minimal, with the reasoning recorded.
The articles that apply, with application dates attached.
Against what you already run, so nothing is rebuilt needlessly.
Policies, oversight, vendor terms, logging, training.
A file you can hand to a regulator, auditor or customer.
Re-assess on change and track new guidance and standards.
A working summary. The first two rows can apply to any AI system; the rest apply where a system is high-risk. Read it alongside the articles cited, because the detail matters.
| Requirement | Provider | Deployer | Importer | Distributor |
|---|---|---|---|---|
| AI literacy (Art. 4) | Take measures to support staff AI literacy | Same duty | Not as importer* | Not as distributor* |
| Transparency (Art. 50) | Design for AI-interaction disclosure; machine-readable marking of synthetic content | Disclose deepfakes and certain AI-generated text; inform people exposed to emotion recognition or biometric categorisation | — | — |
| High-risk AI systems only | ||||
| Risk management and data governance (Arts. 9, 10) | Establish and maintain across lifecycle | Ensure input data under its control is relevant and representative | — | — |
| Technical documentation (Arts. 11, 18) | Draw up before market; keep 10 years | — | Verify it exists; keep declaration, certificate and instructions 10 years | — |
| Logging and record keeping (Arts. 12, 19, 26) | Build in automatic logging; keep logs under its control at least 6 months | Keep logs under its control at least 6 months | — | — |
| Instructions and human oversight (Arts. 13, 14, 26) | Provide instructions; design for effective oversight | Use per instructions; assign competent people with authority to oversee | Verify instructions accompany the system | Verify instructions accompany the system |
| Accuracy, robustness, cybersecurity (Art. 15) | Design and declare appropriate levels | — | — | — |
| Quality management system (Art. 17) | Required, proportionate to size | — | — | — |
| Conformity assessment, declaration, CE marking (Arts. 43, 47, 48) | Complete before placing on the market | — | Verify assessment done and CE marking present | Verify CE marking and EU declaration |
| EU database registration (Art. 49) | Register (also for Annex III systems self-assessed as not high-risk) | Public authorities register their use | — | — |
| Fundamental rights impact assessment (Art. 27) | — | Public bodies, public-service providers, credit and life/health insurance use cases | — | — |
| Monitoring and serious incidents (Arts. 26, 72, 73) | Post-market monitoring; report serious incidents to authorities | Monitor use; inform provider and authorities of serious incidents | Inform provider and authorities where a system presents a risk | Inform provider or importer and authorities where a system presents a risk |
| Informing people (Art. 26) | — | Tell workers' representatives before workplace use; tell people subject to Annex III decisions | — | — |
* Importers and distributors are frequently deployers or providers of other systems too, in which case those duties apply. Authorised representatives (Art. 22) verify documentation, keep it available for 10 years and cooperate with authorities under their mandate. SMEs and small mid-caps can use simplified technical documentation under the Omnibus changes.
"High-risk" is a legal category, not a judgement about how advanced or sensitive your AI feels. A system gets there by one of two routes.
The AI is a safety component of a product, or is itself a product, covered by listed EU harmonisation legislation such as medical devices, and that product needs third-party conformity assessment. Applies from 2 August 2028.
Biometrics; critical infrastructure; education and vocational training; employment and worker management; access to essential private and public services, including credit scoring and life and health insurance pricing; law enforcement; migration and border control; and the administration of justice and democratic processes. Applies from 2 December 2027.
Classification matters because it's the difference between a transparency notice and a full compliance programme. Getting it wrong in either direction costs money: overclassify and you build controls you didn't need, underclassify and you're exposed when the dates arrive.
Systems already on the market before the relevant date are treated differently under Article 111 unless their design changes significantly. Worth checking before you plan remediation.
This is where we see the most confusion. Using a general-purpose AI tool doesn't make you a GPAI model provider. Those obligations sit with whoever develops the model and places it on the market.
You're a deployer of an AI system. AI literacy applies, and Article 50 deployer duties apply if you publish deepfakes or certain AI-generated text. GPAI model obligations don't.
You're typically the provider of your AI system, and its classification depends on its purpose. The model provider must give downstream providers information to help them comply (Art. 53), so get that into your contracts.
You may be a GPAI model provider: technical documentation, downstream information, a copyright policy and a public training-content summary, plus more for models with systemic risk (Art. 55). The Commission's guidelines explain when modifying a model makes you its provider.
GPAI obligations have applied since 2 August 2025, the Commission has been able to enforce them since 2 August 2026, and the General-Purpose AI Code of Practice, published in July 2025, is the main voluntary route to demonstrating compliance. For groups with EU headquarters in Ireland, note that the Omnibus widened the Commission AI Office's supervision to AI systems built on a GPAI model by the same undertaking.
One is law. The other is a management system standard you can certify against. They reinforce each other, but one doesn't stand in for the other.
| EU AI Act | ISO/IEC 42001 | |
|---|---|---|
| What it is | EU Regulation (EU) 2024/1689, amended by (EU) 2026/1744 | International AI management system (AIMS) standard |
| Status | Legally binding where in scope | Voluntary; certifiable by accredited bodies |
| Focus | Obligations tied to roles and to specific AI systems and models | How the organisation governs AI: policy, risk, roles, controls, improvement |
| What "done" looks like | Obligations met, and for some high-risk systems a conformity assessment, CE marking and registration | A certificate for your management system scope |
It gives you the organisational spine the Act assumes but doesn't spell out: leadership accountability, an AI policy, a repeatable AI risk and impact assessment, supplier controls, internal audit and management review. Many of the governance rows above map neatly onto it.
It doesn't produce system-level technical documentation, conformity assessments, CE marking, EU database registration, Article 50 disclosures or specific log retention periods. A presumption of conformity only attaches to harmonised standards cited in the Official Journal, and ISO/IEC 42001 isn't one of them.
If certification is on your roadmap, we can design the AIMS so it produces AI Act evidence as it runs. See our ISO 42001 certification services in Ireland, or our longer comparison of the EU AI Act vs ISO 42001.
We support organisations across Ireland, whether your AI sits with a product team in Dublin, a medtech or pharma operation around Cork or Galway, or engineering and shared-services teams in Limerick and Waterford. The work is delivered remotely by default, with workshops scheduled around your teams; if on-site sessions matter to you, raise it when we scope.
EU engagements are contracted through our EU entity, Zulon Audits OÜ in Tallinn, and EU-region data processing is available if your evidence needs to stay within the EU. We're not a law firm. Where you need a formal legal opinion, we work alongside your solicitors or in-house counsel.
The sector doesn't decide your obligations; your role and use cases do. But some patterns come up again and again.
Building an AI product? Our page on ISO 42001 for SaaS and AI companies covers the certification side.
Not every item applies to every organisation. The tags show who each one typically matters for. Part of the assessment is telling you which you can safely skip.
We've been an audit and compliance firm since 2004. That shapes how we approach the AI Act: we think in terms of what an assessor will ask to see.
So the work is evidence-first. Every classification has written reasoning. Every obligation has an owner and a date. And we're straightforward about limits. No one can hand you a general "EU AI Act certificate". Where the Act requires third-party conformity assessment, notified bodies do it for specific high-risk systems. What we give you is a defensible, documented position.
Because we also test AI systems for security weaknesses, the governance work doesn't stay theoretical.
There's no honest fixed price, because two organisations with the same headcount can have very different AI footprints. We scope first, then give you a written proposal with a clear fee.
Request an EU AI Act AssessmentNumber of AI systems in scope
Your role, and how many roles you hold
Whether any systems are likely high-risk
Technical complexity of the systems
Number of business units involved
Existing governance (ISO 27001, ISO 42001, GDPR)
Documentation maturity
Jurisdictions and EU markets served
Reliance on third-party and GPAI-based AI
How much remediation support you want from us
The EU AI Act, Regulation (EU) 2024/1689, is the EU's law on artificial intelligence. It takes a risk-based approach: it bans certain practices, sets detailed requirements for high-risk AI systems, imposes transparency duties on some systems, and regulates general-purpose AI models. It entered into force on 1 August 2024 and applies in phases, and it was amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744, in July 2026.
Yes. As an EU Regulation it applies directly in Ireland. The Regulation of Artificial Intelligence Act 2026, signed into law on 21 July 2026, sets up the Irish enforcement structure, including the AI Office of Ireland and the powers of the designated competent authorities. It doesn't add obligations beyond the EU Regulation.
It can touch most organisations that use AI professionally, but obligations vary a lot. A company using general AI tools may mainly need AI literacy measures and awareness of the prohibited practices, while a provider of a high-risk system faces a full set of requirements. Some uses fall outside scope altogether, such as purely personal non-professional use and AI developed solely for scientific research.
Ask who develops the system and puts it on the market or into service under their own name. That's the provider. If you use a system under your authority in a professional capacity, you're a deployer. Roles are assessed per system, and a deployer can become a provider under Article 25, for example by rebranding a high-risk system or changing its intended purpose so that it becomes high-risk.
Check two routes. Is it a safety component of, or itself, a product under the EU legislation in Annex I that requires third-party conformity assessment? Or is it used for a purpose listed in Annex III, such as recruitment, credit scoring or access to education? An Annex III system can fall outside high-risk under Article 6(3) if it doesn't pose a significant risk of harm, but that assessment must be documented, and systems that profile people remain high-risk.
It's a structured review of where you stand against the obligations that apply to you. Ours covers your AI inventory, your role for each system, risk classification, a mapping of applicable articles, documentation and governance gaps, and a prioritised remediation roadmap tied to the actual application dates.
Start with an AI system inventory, your role mapping and classification records, plus evidence of AI literacy measures. What else you need depends on your position: high-risk providers need technical documentation, risk management records, logs and a quality management system, while some deployers need a fundamental rights impact assessment and human oversight records. Not every item applies to every organisation.
No. ISO/IEC 42001 certifies your AI management system, which is valuable groundwork for governance, risk and accountability. It doesn't by itself meet system-level obligations such as technical documentation, conformity assessment, registration or Article 50 transparency, and it isn't a harmonised standard that gives a presumption of conformity under the Act.
Prohibited practices and AI literacy have applied since 2 February 2025; GPAI model obligations since 2 August 2025; Article 50 transparency and the general date of application since 2 August 2026. New prohibitions apply from 2 December 2026. High-risk requirements apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I products, following the Digital Omnibus on AI. Dates were last checked on 21 September 2026.
Yes. We support organisations across Ireland, with delivery remote by default and workshops scheduled around your teams. EU engagements are contracted through our EU entity, Zulon Audits OÜ, and EU-region data processing is available.
Expert Auditors. Faster Certification.
European Operations
European engagements are delivered through Zulon Audits OÜ, the European practice of VISTA InfoSec.
Visit Zulon Audits →
VISTA InfoSec LLC,347 Fifth Ave,
Suite 1402-526, New York, NY 10016
© Copyright 2026. VISTA InfoSec. All Rights Reserved. | Disclosure Policy | Privacy Policy | Sitemap
Enquire Now