AI security and compliance for an EU firm comes down to three jobs. You meet the EU AI Act obligations that match your role and risk tier. You meet the GDPR obligations you already had for any personal data the AI touches. And you engineer the system so it cannot be manipulated into leaking data or taking actions nobody approved. For most businesses using AI for internal productivity, document processing or customer service, the AI Act asks for relatively little: transparency and staff AI literacy. GDPR and solid security engineering carry most of the weight.
The heavy obligations fall in two places: high-risk uses such as hiring, credit scoring and safety components, and organisations that build and sell AI systems under their own name. This guide covers each layer, where they overlap, and the order in which we would tackle them.
What AI security and compliance actually covers
People tend to treat this as one topic. In practice it is three disciplines sharing a system diagram. Regulatory classification works out which laws apply and in what capacity. Data protection applies lawful basis, minimisation, retention, processors and data subject rights to a technology that copies data into prompts, logs, embeddings and vendor infrastructure. Security engineering deals with threats, prompt injection being the best known, that conventional application security does not fully cover.
Each layer fails differently. Compliance failures start as documentation gaps: nobody can say which AI systems are in use or why they are lawful. Data protection failures start as data flowing somewhere it shouldn’t, such as a customer list pasted into a consumer chatbot or a vector index that ignores document permissions. Security failures start with too much trust, in model output or in an agent holding broad credentials. A credible programme has to handle all three.
The EU AI Act: what applies to you
The EU AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024. It regulates AI systems according to the risk their use creates, and the role you hold determines most of your obligations.
Provider or deployer?
A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name. A deployer uses an AI system under its own authority in a professional context. A firm that licenses a hiring tool is a deployer; the vendor is the provider. Providers of high-risk systems take on conformity assessment, technical documentation, quality management and post-market monitoring. Deployers carry a much smaller set of duties.
The trap is that you can become a provider without meaning to. Under Article 25, putting your name or trademark on a high-risk system, substantially modifying one, or changing a general-purpose system’s intended purpose so that it becomes high-risk all shift provider obligations onto you. Wire a general-purpose model into an internal tool that ranks job applicants and you are no longer simply a user of a chatbot.
The risk tiers
Prohibited practices have been banned since 2 February 2025: social scoring, manipulative techniques that cause significant harm, emotion recognition in workplaces and education (with medical and safety exceptions), untargeted scraping of facial images, and certain biometric categorisation. High-risk systems are those listed in Annex III, covering employment, education, access to essential private and public services (including credit scoring and life and health insurance pricing), critical infrastructure, biometrics and law enforcement, plus AI that serves as a safety component of products already covered by EU product law. Limited-risk systems carry Article 50 transparency duties: people must be told when they are talking to a chatbot, and synthetic or deepfake content must be marked or disclosed. Everything else is minimal risk. Providers of general-purpose AI models fall under a separate regime that has applied since 2 August 2025.
One obligation already applies to almost everyone. Article 4 requires providers and deployers to ensure a sufficient level of AI literacy among staff who operate or use AI systems. A short, role-specific training programme with a record of completion is the minimum defensible answer.
Timeline and penalties
The Article 50 transparency obligations have applied since 2 August 2026. The high-risk dates moved: the Digital Omnibus on AI (Regulation (EU) 2026/1744), published in July 2026, pushed Annex III high-risk obligations from 2 August 2026 to 2 December 2027, and high-risk AI embedded in regulated products (Annex I) from August 2027 to 2 August 2028. Check the Commission’s AI Act page for the current timetable rather than relying on any article, this one included. Fines reach €35 million or 7% of global annual turnover for prohibited practices and €15 million or 3% for most other breaches. In Ireland, enforcement is spread across existing sectoral regulators rather than one new body, so your usual regulator is likely to be your AI Act contact too.
GDPR and AI: the obligations you already have
The AI Act does not replace the GDPR, and for most firms GDPR is where the real exposure sits. Any prompt, document, transcript or log containing personal data is processing, and every normal requirement applies.
Start with lawful basis. Legitimate interests is often workable for internal AI use, but only after a documented balancing test; the EDPB’s Opinion 28/2024 on AI models sets out how supervisory authorities approach it. A DPIA is likely to be required under Article 35 wherever AI evaluates people systematically or processes sensitive data at scale. And Article 22 limits decisions based solely on automated processing that have legal or similarly significant effects. If a model effectively decides who gets a loan or an interview, the human review has to be meaningful, not a rubber stamp.
The practical problems are mostly about where data ends up. LLM API vendors are processors, so you need an Article 28 data processing agreement, clarity on retention and training use, and a lawful transfer mechanism if data leaves the EEA. Use EU data residency where vendors offer it. Retrieval systems are subtler: if personal data is chunked and embedded into a vector store, you must be able to find and delete it when someone exercises their rights. Prompt and response logs are personal data too, so give them a retention period. The Data Protection Commission publishes guidance that applies directly to Irish controllers.
Security threats specific to AI systems
The OWASP Top 10 for LLM Applications is the most useful single reference. Rather than repeat it, here are the threats that matter most in real deployments.
Prompt injection and untrusted content
Any text the model reads can carry instructions: an inbound email, a web page, a PDF, a support ticket, a code comment. No filter reliably separates data from instructions, so the defence has to be architectural. Assume the model will sometimes follow an injected instruction, and arrange things so that following it cannot do much damage. The model reading untrusted content should not also hold credentials to send emails, move money or delete records without a gate in between.
Excessive agency
Agents raise the stakes because they act: they call tools, browse and write to systems. OpenAI’s disclosure that its test models affected dozens of third-party websites shows that an agent pursuing a goal can cause harm outside your own perimeter. The controls are least privilege, scoped and short-lived credentials, and giving agents their own identities rather than borrowed human tokens, which is why the move toward agents with their own workspace identity matters to anyone writing an access policy. Consequential actions should require human approval. We use this pattern ourselves and have written up how we make agents easy to steer from a phone with human-in-the-loop action tags. Approval only works if it costs the approver a few seconds rather than a login session.
Leakage, output handling and supply chain
Assume system prompts will leak, so never put secrets in them. Enforce access control in retrieval at query time against the user’s actual permissions, rather than trusting the model to keep confidential documents confidential. Treat model output as untrusted input: no eval, sanitised HTML, parameterised queries. Model weights, inference libraries, plugins and tool servers all run code or shape behaviour, so pin versions and review them like any dependency. Set rate limits and hard spend caps, because a runaway agent loop can cost a great deal before anyone notices. Our LLM integration guide for production systems covers these patterns in more depth.
Sector rules that stack on top
Depending on your sector, more frameworks apply. NIS2 places cyber risk-management and incident-reporting duties on essential and important entities, including an early warning within 24 hours of a significant incident, and AI systems sit inside that scope like any other ICT. Ireland’s transposition has run behind the EU deadline, so confirm your status with the National Cyber Security Centre. Since 17 January 2025, financial entities under DORA have had to manage ICT third-party risk, so AI vendors belong in the register of information. Medical device rules and the Cyber Resilience Act add further layers. One control set mapped to several frameworks is far cheaper than parallel programmes, and this is where automating compliance reporting pays off.
AI risk management: choosing a framework
You need one structure for governance and one threat model for engineering, not every framework.
| Framework | What it is | Best used for |
|---|---|---|
| NIST AI RMF 1.0 | Voluntary framework built around Govern, Map, Measure, Manage | Structuring an AI risk programme quickly, free of charge |
| ISO/IEC 42001:2023 | Certifiable AI management system standard | Firms that need third-party assurance for customers or procurement |
| OWASP Top 10 for LLM Applications | Threat catalogue for LLM-based software | Engineering reviews, threat modelling, test plans |
| EU harmonised standards (in development) | CEN-CENELEC standards supporting the AI Act | Presumption of conformity for high-risk providers once published |
For a mid-sized firm, NIST AI RMF for governance plus OWASP for engineering is a sensible default. Move to ISO 42001 when customers start asking for certificates.
Secure AI deployment: the controls checklist
These are the controls we would expect before an AI system touches production data:
- An inventory of every AI system and tool in use, including staff use of consumer chatbots, with an owner, purpose, AI Act role and risk tier for each.
- A signed DPA with every model vendor, with confirmed retention, training opt-out, residency and transfer mechanism, plus a DPIA wherever personal data is evaluated or processed at scale.
- Least-privilege, scoped credentials issued to each agent’s own identity.
- Human approval gates on irreversible or external actions: payments, outbound messages, deletions, production changes.
- Retrieval that enforces the requesting user’s permissions at query time.
- Model output sanitised, validated against schemas and never executed directly.
- Logging of prompts, tool calls and decisions with a defined retention period. High-risk deployers must keep logs for at least six months.
- Rate limits, spend caps and an off switch that someone on call knows how to use.
- Pinned model and dependency versions, with an evaluation suite that runs before any upgrade.
- Recorded AI literacy training, an acceptable-use policy staff have actually read, and Article 50 disclosures on customer-facing chatbots and generated content.
If this were our business, where would we start?
We would start with the inventory, because nothing else is possible without it, and make it honest by asking teams what they actually use rather than what procurement approved. Then we would rank each item by regulatory tier and blast radius, and fix the cheap, high-risk items within a fortnight: personal data going into consumer tools without a DPA, agents running on a person’s full credentials, and anything touching hiring or credit decisions. AI literacy training and an acceptable-use policy come next, since that obligation already applies. Only then would we invest in a formal framework or certification. Firms that begin with a 60-page policy and no inventory end up with paperwork describing a system nobody runs. For a structured first pass, our AI readiness audit guide walks through assessing the architecture these controls have to sit in.
D3X Solutions LABS is an AI engineering studio in Ireland that builds AI agents and automation, so security and compliance are designed in rather than bolted on at the end. We map your AI use against the AI Act tiers and your GDPR position, then build the controls, including scoped agent identities, approval gates, permission-aware retrieval and logging, so the evidence a regulator or customer asks for comes from the system itself. If you want a second opinion on where you stand, book a free 30-minute call.
Frequently Asked Questions
Does the EU AI Act apply to my business if we only use ChatGPT or Copilot?
Yes, but lightly in most cases. As a deployer of general-purpose tools for internal work, your main duties are AI literacy for staff under Article 4 and transparency if you expose AI to customers. That changes if you use those tools for a high-risk purpose such as screening job applicants or assessing creditworthiness.
What is the difference between EU AI Act compliance and GDPR compliance for AI?
The AI Act regulates AI systems according to the risk their use creates, whether or not personal data is involved. GDPR regulates the processing of personal data, whatever technology does it. Most AI systems that touch customer or employee data fall under both, so you need a lawful basis, processor agreements and possibly a DPIA, as well as any AI Act obligations for your tier.
When do the EU AI Act high-risk obligations apply?
Prohibited practices and AI literacy have applied since 2 February 2025, and general-purpose model obligations since 2 August 2025. Article 50 transparency obligations have applied since 2 August 2026. The 2026 Digital Omnibus (Regulation (EU) 2026/1744) moved Annex III high-risk obligations to 2 December 2027 and product-embedded high-risk AI (Annex I) to 2 August 2028. Check the Commission’s official AI Act page for the current dates.
Do I need a DPIA before deploying an AI system?
Often, yes. Article 35 GDPR requires a DPIA where processing is likely to result in high risk, which includes systematic evaluation of people, large-scale processing of sensitive data and innovative technologies used in those contexts. Even where it is not strictly required, a short DPIA is the clearest way to document your lawful basis and safeguards.
What is the biggest security risk in AI agents?
Excessive agency combined with prompt injection. An agent that reads untrusted content such as emails or web pages and also holds broad credentials can be steered into taking harmful actions. The fix is architectural: least-privilege scoped credentials, a separate identity for each agent, and human approval for irreversible or external actions.
Is ISO 42001 certification required under the EU AI Act?
No. ISO/IEC 42001 is a voluntary, certifiable management system standard, and the AI Act does not mandate it. It is useful when customers or procurement teams want third-party assurance, and it overlaps with AI Act governance expectations. High-risk providers will rely mainly on the EU harmonised standards being developed by CEN-CENELEC.
Want this working in your business?
D3X Solutions LABS builds AI agents and automation that pay back fast. Not sure where to start? A free 30-minute call is enough to find the first thing worth building.
Get in touch
