The AI Act Is a Security Law in Disguise, Part 1

1. Who owns the AI Act in your organisation?

The HR function at a mid-sized European bank buys an AI tool that screens CVs. Procurement negotiates the contract, legal reviews the terms, and the DPO completes a data-protection impact assessment. Security is asked for a penetration test the week before go-live, and the test passes.

Nobody has asked whether the tool is high-risk under the AI Act, who will keep its logs, or who reports it if it starts rejecting candidates unfairly. The organisation believes it is compliant because every function did its part, but nobody owned the whole.

The governance vacuum. Leadership teams often assume that AI governance is a shared effort; "we all own it" is a recurrent claim in board meetings after all. However, evidence shows the work landing on the function least equipped for it, accountability thin at the top, and security brought in late.

• AI governance defaults to privacy and legal: 68% of privacy professionals say they have taken on AI governance responsibilities (IAPP Salary and Jobs Report 2025-26). Where a single function leads AI governance, it is most often privacy (22%) or legal and compliance (22%). Security leads in just 5% of organisations (IAPP AI Governance Profession Report 2025, 670+ respondents in 45 countries).
• Thin executive and board ownership: Only 28% of organisations using AI say the CEO is responsible for overseeing AI governance, and 17% say the board is. Ownership is often split, with two leaders in charge on average. (McKinsey, The State of AI).
• Security arrives late, and as a technician: 46% of security professionals say their team has not been involved in developing, onboarding or implementing AI solutions, and 40% have had no hand in AI policy. 71% of organisations have run no AI incident response exercise, and only 3% have mature procedures for AI incidents. (ISACA State of Cybersecurity 2026). Where security does review AI, it is often a single gate: One third of organisations have no process to validate AI security before deployment, and 24% assess only once (WEF Global Cybersecurity Outlook 2026).

The Act's operational duties (scoping, monitoring, logging, and incident response) are Security's daily work, yet security joins at the end, as a technical reviewer.

2. AI Classification is the first security control

And indeed, Security plays a fundamental role from the get-go, right when a decision must be made whether an AI system is high-risk according to the AI Act classification.

What is at stake: the four tiers. Article 6 of the Act defines the rules to classify AI systems. The gap between high-risk and everything below it is the gap between a full management system and almost nothing. That is why classification drives most of the compliance cost.

Provider or Deployer? The Act defines two key roles:

• Provider: whoever builds the AI and puts their name on it. Examples are a software vendor selling a CV-screening tool, a bank that builds its own credit-scoring model, or OpenAI or Mistral for their models.
• Deployer: whoever puts the AI to work in their business. Examples are the bank's HR team using the vendor's CV tool, or a retailer using a third-party chatbot for customer service.

It’s worth noticing that, while the provider carries most of the weight, one organisation can be both. For example, the bank above is a provider for the credit model it built and a deployer for the CV tool it bought.

What high-risk actually means. The roles defined carry different levels of duties and responsibilities:

• Provider duties: risk management system, data governance, technical documentation, automatic logging, instructions for deployers, human oversight by design, accuracy, robustness and cybersecurity, quality management system, conformity assessment, EU declaration and CE marking, registration, post-market monitoring, serious-incident reporting.
• Deployer duties (Art. 26): use the system as instructed, assign competent human oversight, check that input data is relevant, monitor operation and report risks and incidents, keep logs for at least six months, and inform workers and affected people. Public bodies, and deployers using AI for credit scoring or life and health insurance pricing, must also carry out a fundamental-rights impact assessment.

Many (if not most) of the high-risk duties are security and operational-risk functions. Below the high-risk line, almost none of them apply. Deciding on which side of that line a system sits is therefore the single most consequential security decision in the Act.

The Security governance reading:

• Classification works like scoping. Getting it wrong means applying every later control to the wrong systems, as with a badly scoped asset inventory.
• Exemption works like a risk-acceptance decision. It must be documented, evidenced, and kept true. Detecting condition drifts is a monitoring and change-control job, directly reflecting into a cybersecurity risk change.

Worked examples:

Executive takeaway: Ask who signs off classification decisions, on what evidence, and who owns the process to ensure they stay true after every vendor update. Make sure accountability is clearly allocated and accepted.

Annex III reaches into security's own territory

Annex III of the AI Act lists the eight areas where an AI system counts as high-risk because of what it is used for, even if it isn't part of a regulated product. The lines that matter most for security leaders, as usual, are fine lines; although it may be tempting to include all security tooling within the high-risk perimeter, that’s not always the case.

Executive takeaway: Security's own tools are mostly outside the high-risk regime, but Security is the function best placed to judge the systems around them. Ensure you are structured and resourced appropriately to do that.

3. Once in scope: the security core

Once a system is high-risk, four obligations read like a security programme. In plain language:

• It must withstand attack (Art. 15). The Act names AI-specific threats: poisoned training data, manipulated inputs designed to fool the model, and attempts to extract confidential data or the model itself.

• Example: An insurer's claims-triage model learns from past claims. Fraudsters discover which wording gets fast approval and flood the system with crafted claims. The model is both deceived and gradually retrained on bad data.

• Example: A recruitment chatbot is tricked by a cleverly worded message into revealing other applicants' details. That is an AI Act robustness failure and a GDPR breach at once.

• It must leave an evidence trail (Arts. 12, 26). Providers build in automatic logging; deployers keep the logs for a period appropriate to the intended purpose (at least 6 months if different provisions don’t apply).

• Example: A rejected loan applicant complains five months later, and the regulator asks what the system did. Without logs, the bank cannot answer.

• It must be watched in operation (Arts. 26, 72). Deployers monitor how the system behaves and report risks; providers run post-market monitoring.

• Failures must be reported (Art. 73). Serious incidents go to the authorities within 15 days, within 10 days if a death is involved, and within 2 days for widespread harm or serious disruption of critical infrastructure.

• Example: The utility's grid-balancing AI contributes to a regional outage. The 2-day clock starts when the organisation becomes aware, which presumes it can detect and diagnose an AI-related failure in the first place.

Executive takeaway: Each of these is an operational capability, not a policy. If it does not exist on the day a system goes live, no document will create it after an incident.

4. Where Security programmes need to focus on

On face value, it seems somewhat overwhelming. However, some considerations here help to frame the whole process more favorably:

• The governance process doesn’t change: AI adds a set of challenges mostly in terms of speed and scale, but doesn’t introduce new attack vectors per se. Consequently, robust governance models of the cybersecurity programme can easily adapt to the requirements of the AI Act and focus on the deltas in the tactical policy requirements.

• Example: The bank's penetration test checked the CV tool's login page, web interface, and data storage. It passed. Nobody tested whether a CV with hidden instructions could push a candidate to the top of the list, because that was not in scope; however, this is just a variant of a missing input sanitization control. The principle of checking inputs of applications is conceptually already integrated in the enterprise security architecture of the bank; it’s a matter of ensuring alignment between this variant and the assurance provided by functional and non-functional security testing.

• Point-in-time reviews do not fit AI: Models change with vendor updates, retraining, and new data. A one-off gate before go-live, which is how a quarter of organisations still assess AI security (WEF), misses most of the risk. Again, sound governance processes ensure that a proper risk management cycle takes care of this as needed.
• One process, not two: For products with digital elements, meeting the Cyber Resilience Act's essential requirements can help demonstrate the AI Act's cybersecurity requirements; the other way around holds true as well. Leaders should ask for one security-by-design process covering both and appropriate mappings as needed.

Executive takeaway: Ask whether your security testing covers how your AI systems behave, not merely how they are built, and whether it repeats after every significant change.

5. The governance consequence

"We all own it" becomes workable only when each decision has a named lead. Below is a suggested model, with security accountable from the first decision:

Our opening example replayed: Security joins when HR first scopes the CV tool. The joint classification flags it as high-risk because it ranks candidates. The contract requires the vendor to give notice of feature changes and to supply logs. The test scope includes manipulation of the model (including input validation). The incident playbook covers unfair outcomes, not only data breaches. Same tool, same vendor, same deadline, but this time someone owns the whole.

Executive takeaway: The change is organisational before it is technical: a seat at the table from the start, and joint sign-off on classification.

6. Conclusions

• Five questions for your next board or executive meeting:

a. Do we have a list of every AI system we build, buy or use, including AI features inside existing software?

b. Who signs off whether each one is high-risk, and is security part of that decision?

c. If we rely on an exemption, what evidence supports it, and who checks it still holds after vendor updates?

d. Could we show a regulator what one of our high-risk systems did six months ago?

e. If one of our AI systems failed or was manipulated tomorrow, who would notice, and could we report within the deadline?

• 2 December 2027: This is when the high-risk rules start to apply to standalone high-risk systems, and it is a deadline for capabilities (testing, logging, monitoring, and incident response) that take longer to build than policies take to write.

• Security at the table from the onset: Organisations that start with security at the table will find most of the AI Act already familiar; a structured and robust governance model will be able to accommodate it without major changes and while minimizing overhead and operational impacts. It all starts with accurate AI inventories and usage observability, which is where we will focus on in the next episode of this series.