AI Act and Information Security - How New Regulations Intersect

When artificial intelligence meets information security

On 31 March 2026 the Council of Ministers adopted the bill on artificial intelligence systems — Poland's implementation of the EU regulation known as the AI Act. Four months remain until August. Meanwhile, most of the organisations we talk to treat the AI Act as somebody else's problem — a matter for innovation departments, technology companies and start-ups building language models.

That is a mistake of perspective. The AI Act does not concern only those who create artificial intelligence. It also concerns — and in many cases above all — those who deploy, buy and use it in their day-to-day operations. And if an organisation processes personal data with the help of algorithms (whether for credit scoring, insurance risk assessment, recruitment or automatic document classification), then the AI Act, GDPR and the amended Polish NIS-2 implementing act (the KSC Act) form three overlapping layers of obligations that cannot be satisfied in isolation from one another.

What the AI Act regulates — in a nutshell

Regulation (EU) 2024/1689 of the European Parliament and of the Council, commonly known as the AI Act, classifies artificial intelligence systems according to the level of risk they pose to health, safety and fundamental rights. It distinguishes four categories: unacceptable risk (prohibited systems), high risk, limited risk and minimal risk.

Prohibited systems — such as Chinese-style social scoring, subliminal manipulation and real-time biometric identification in public spaces (with narrow exceptions) — were withdrawn from the market as early as 2 February 2025.

The core of the regulation is high-risk systems, because it is these that impose the greatest number of obligations on providers and deployers alike. And the list of such systems is broader than one might think — it covers, among other things, systems used in recruitment and workforce management, creditworthiness assessment, access to public services, critical infrastructure management, law enforcement and the administration of justice.

From 2 August 2026 the provisions on high-risk systems under Annex III to the regulation start to apply. That is the date from which organisations deploying such systems must meet the full catalogue of requirements.

Three regulations, one management system

An organisation that processes personal data using machine learning algorithms and is at the same time subject to the amended KSC Act (because it operates in one of the eighteen sectors covered by the NIS-2 directive) faces a challenge that only appears to consist of three separate problems.

GDPR requires a legal basis for processing, data minimisation, transparency towards data subjects and — in the case of automated decision-making — the right to human intervention (Article 22). It also requires a data protection impact assessment (DPIA) where the processing is likely to result in a high risk to the rights and freedoms of natural persons.

The AI Act requires deployers of high-risk systems, among other things, to implement human oversight, ensure the transparency of the system's operation, maintain technical documentation, monitor the system in the production environment, report serious incidents and — crucially — carry out a fundamental rights impact assessment (FRIA) before putting the system into use.

The amended KSC Act requires risk analysis, the implementation of cybersecurity risk management measures, incident handling, business continuity and supply chain security.

These three sets of obligations do not sit side by side — they intersect. The DPIA under GDPR and the FRIA under the AI Act examine partly the same risks, only from different perspectives. The risk analysis under the KSC Act covers information systems, including those using AI. The security measures required by the KSC Act protect personal data (GDPR) and the integrity of AI systems (the AI Act) at the same time.

The conclusion is simple, even if acting on it is not: an organisation needs a single, coherent information security management system (ISMS) that takes account of the requirements of all three regulations. Building three separate silos — "the GDPR team", "the NIS-2 team", "the AI team" — is a recipe for gaps, duplication and confusion over who is responsible for what.

DPIA and FRIA — two assessments, one approach

The data protection impact assessment (DPIA), required by Article 35 GDPR, and the fundamental rights impact assessment (FRIA), required by Article 27 of the AI Act, are two instruments with a similar philosophy but a different scope.

The DPIA focuses on risks to privacy and the protection of personal data. The FRIA covers a broader spread of fundamental rights — including the right to non-discrimination, freedom of expression, human dignity and the right to an effective remedy. Where AI systems process personal data, the two assessments will complement each other.

Good practice — and, at the same time, a saving of time — is to carry them out together, as part of a single risk assessment process. The starting point is the same system, the same data, the same organisational context. What differ are the questions that have to be asked and the perspectives from which the risk has to be assessed — but the methodology can be shared.

Fib.Code recommends developing an integrated assessment template that combines the requirements of the DPIA and the FRIA with the risk analysis required by the KSC Act. One process, three outputs — instead of three processes run by three different teams with no idea what their neighbour has established.

Recruitment is a good example: the AI Act classifies systems assessing candidates as high risk, while Poland's data protection authority (UODO) looks at them through the lens of GDPR. We take that case apart in our article on AI in recruitment.

Human oversight — a legal requirement, not good practice

Article 14 of the AI Act sets out a requirement that many organisations will find harder to meet than any technical question: human oversight of high-risk systems. This is not about a declaratory "a human takes the final decision", but about genuinely ensuring that the person overseeing the system understands its limitations, is able to interpret its outputs and has a real ability to reject or correct the algorithm's decision.

In an information security context this means that a system using AI to detect threats (a SIEM with a machine learning component, a behavioural analytics tool, an automatic incident classification system) must be operated by staff trained not only in using the tool, but also in understanding how the model reaches its decisions and where errors may occur.

For organisations covered by the KSC Act this is an additional layer of training requirements — alongside cyber hygiene training and management approval of policies comes the need to ensure competence in overseeing AI systems.

Incidents — the AI Act extends the reporting obligation

The amended KSC Act requires serious incidents to be reported on a 24/72/30 schedule (twenty-four hours for the initial notification, seventy-two hours for the interim report, a month for the final report). The AI Act introduces a separate obligation to report "serious incidents" involving high-risk systems — defined as events that may pose a threat to health, safety or fundamental rights.

In practice this means that the same incident — for example a failure of an AI system classifying emergency calls, or an error in an algorithm controlling critical infrastructure — may require reporting along two separate tracks: to the CSIRT (under the KSC Act) and to the market surveillance authority (under the AI Act). And if the incident involves a personal data breach, a third track is added: notification to the President of UODO under Article 33 GDPR.

Building three independent incident reporting procedures is a road to nowhere. An organisation needs one procedure that accommodates three reporting paths — with a clear decision tree setting out who is notified, within what deadline and in what form.

The AI supply chain — new questions for old suppliers

The AI Act introduces the concept of the "AI value chain" — the sequence of entities involved in creating, making available and deploying artificial intelligence systems. A deployer of a high-risk system is responsible for using it lawfully, even where the system itself was created by an external supplier.

Combined with the supply chain security requirement under the KSC Act, this means that organisations have to ask their suppliers new questions. It is no longer enough to ask about ISO certificates and confidentiality clauses. You need to establish: is the supplier aware that its product qualifies as a high-risk system? Does it maintain the required technical documentation? Does it provide post-deployment monitoring of the system? What training data was used, and is its use compliant with GDPR?

Contracts with AI technology suppliers should contain clauses obliging them to cooperate on incident reporting, to make technical documentation available and to notify any changes to the system that may affect its risk classification.

KRiBSI — a new authority, new powers

Poland has opted for a centralised model of AI supervision. The Commission for the Development and Security of Artificial Intelligence (KRiBSI) will act as the market surveillance authority within the meaning of the AI Act — with powers to conduct proceedings, issue decisions and impose administrative fines.

This approach sets Poland apart from most Member States, which spread these competences across several authorities. For organisations it brings a degree of convenience (a single point of contact), but also a risk — a centralised authority has a complete picture of the market and can be more effective at identifying entities that have failed to meet their obligations.

Fines for infringing the AI Act may reach thirty-five million euros or seven per cent of worldwide annual turnover — where prohibited AI practices are used. For infringements concerning high-risk systems, fines of up to fifteen million euros or three per cent of turnover are provided for. The scale is comparable to GDPR and, for the most serious infringements, significantly exceeds it.

What to do before August — an action plan

For organisations that use or intend to use artificial intelligence systems — even apparently simple ones such as customer service chatbots, automatic CV analysis tools or recommendation systems — we propose four preparatory steps.

First: an inventory of AI systems. A surprising number of organisations do not know how many systems using elements of artificial intelligence are running in their infrastructure. AI is often embedded in tools that are not perceived as such — in ERP systems, HR platforms, marketing tools, log analysis solutions. The starting point is a complete map: what, where, for what purpose and on whose data.

Second: risk classification. Every identified system needs to be assessed against the AI Act risk categories. High-risk systems are those that require the full package of obligations. But even limited-risk systems (such as chatbots) are subject to transparency requirements: the user must know they are talking to a machine.

Third: an integrated risk assessment. Combining the DPIA (GDPR), the FRIA (the AI Act) and the risk analysis (the KSC Act) into a single process — for systems subject to all three regulations.

Fourth: updating the ISMS documentation. If an organisation has an information security management system — compliant with ISO 27001 or with the requirements of the National Interoperability Framework (KRI) — it should extend it with AI-specific elements: a policy on the use of artificial intelligence systems, human oversight procedures, rules for testing and monitoring models, and procedures for reporting AI-related incidents.

How Fib.Code can help with the AI Act

Fib.Code operates at the intersection of information security, personal data protection and cybersecurity — precisely where the AI Act meets GDPR and the KSC Act. We do not build artificial intelligence models; we help organisations use the ones they already have, or plan to deploy, safely and lawfully.

Our end-to-end AI Act compliance service covers the inventory of AI systems for risk classification purposes, integrated DPIA/FRIA assessments, extending existing ISMS documentation to cover AI Act requirements, training for management and technical staff, and ongoing regulatory compliance advice.

Three regulations. One management system. One partner who sees the whole picture.

Book a free consultation: l.grabowski@fibcode.com | www.fibcode.com