The EU AI Act is not a GDPR sequel. It targets systems by risk level, not data type, which means CISOs need to think about it differently from how their legal teams are approaching it. Some of the tools in your security stack are in scope. Some of your vendors don't know they are yet.
What does the EU AI Act actually regulate?
The EU AI Act regulates AI systems by the risk they pose in their application context. Prohibited systems sit at the top, then high-risk, then lower-risk with transparency obligations, then minimal-risk. For cybersecurity specifically, the relevant question is which of your AI-powered tools might be classified as high-risk in the categories the regulation calls out.
Critical infrastructure management falls under Annex III. If your AI-driven SIEM is making automated decisions that affect how infrastructure operates, that is a conversation your legal team needs to have with your vendor. Automated threat-response tools that take network isolation actions without human approval may face additional scrutiny as national guidance develops.
Which AI security tools are likely in scope?
Classification is still being worked out by national competent authorities and the European AI Office. What is clear: systems used for biometric categorisation, emotion recognition, and certain types of automated decision-making in employment or critical services contexts are high-risk under the Act.
For most security tooling, the direct AI Act obligations fall on the provider, not the buyer. Your AI-powered EDR vendor, not your organisation, is the "provider" under the Act. But as the "deployer," your organisation still has obligations: adequate logging, human oversight capability, and ensuring the system is used within its intended purpose.
The gap that LimitedView's governance analysis keeps identifying is the intended purpose clause. Vendors build AI tools for general threat detection. Organisations deploy them in specific contexts, with specific data types, making specific operational decisions. When those contexts differ meaningfully from the intended use case, the deployer's obligations increase significantly.
What do CISOs need to do with their AI vendor contracts?
Start with your existing AI vendor inventory. If you don't have one, the AI Act is good motivation to build it now rather than during an enforcement investigation. For each AI tool, identify who the provider is under the Act, what risk category the system likely falls in, and whether your contract gives you access to the logs and oversight mechanisms you need to meet deployer obligations.
High-risk AI system providers must give deployers access to technical documentation and usage logs. If your contracts predate the Act and don't include those provisions, renewals are your opportunity to add them. Don't assume vendors will proactively offer this during a commercial negotiation.
The practical risk isn't the fine. Regulators are unlikely to prioritise security tool vendors in their first enforcement wave. The practical risk is that a vendor builds a product that doesn't meet high-risk system requirements, and you've built operational dependencies around it before that becomes clear.
How does the AI Act interact with AI governance frameworks already in place?
If your organisation already has an internal AI governance framework, the AI Act maps reasonably onto it. Risk classification, human oversight requirements, logging and audit trails. The concepts are familiar even if the specific obligations differ.
Where organisations typically find gaps: their internal frameworks were built around internally developed or fine-tuned models. The AI Act also applies to commercial off-the-shelf AI systems used in high-risk contexts. Your SIEM vendor's machine learning engine may be in scope. Your organisation's existing risk classification process probably didn't include commercial security tools when it was designed.
LimitedView's analysis of enterprise AI governance postures found that organisations undercount their AI touchpoints consistently. Tools marketed as "analytics" or "automation" contain AI components that trigger Act obligations in certain deployment contexts. A practical gap analysis, starting with your security stack, is a more tractable exercise than it sounds.
What should CISOs prioritise to prepare for AI Act enforcement?
Three concrete priorities. First, complete a vendor inventory that identifies which AI-powered security tools are deployed, who the provider is under the Act, and whether the contract includes the documentation and oversight access a deployer needs.
Second, establish a process for assessing new AI security tool purchases against Act requirements before procurement finalises. The time to identify a compliance gap is before you've signed a three-year contract and integrated the tool into your SOC workflows.
Third, clarify internal ownership. AI Act compliance for security tools sits across legal, procurement, and security. That ambiguity is where gaps develop. Assign it explicitly.
What should CISOs put on their board agenda about the EU AI Act?
The board conversation about AI regulation rarely needs to be about specific rules. It needs to be about whether the organisation has a coherent process for making AI decisions that accounts for regulatory reality. The AI Act is useful framing for that conversation precisely because it is specific and enforceable, unlike many AI governance frameworks that exist as policy documents without operational teeth.
The question worth putting to the board: do we know which AI systems we are deploying in regulated contexts, and do our vendor contracts reflect what we are legally required to be able to demonstrate? If the answer is uncertain, that is the gap to close before an enforcement action makes it urgent.
