An organisation can define EU AI Act CISO responsibilities by delegation long before it maps them to the law. The board wants a name against the risk, procurement wants a signature, and an AI system is approaching production. Those pressures can turn “security owns AI risk” into an operating assumption even though the Regulation says nothing of the kind.
The Act doesn’t name the Chief Information Security Officer (CISO) anywhere. It assigns obligations according to an organisation’s role as an operator, including provider, deployer, importer, or distributor, and it requires providers of high-risk systems to set out an internal accountability framework. Nothing in it makes security the owner of AI compliance. For high-risk systems, documented risk management, testing, quality management, monitoring, and staff responsibilities make weak ownership harder to hide.
This article is for CISOs and security leaders being asked to approve an AI deployment, report AI risk to a board, answer a customer or procurement questionnaire, or accept residual risk for a system their team didn’t build. It draws a boundary you can defend: which AI Act workstreams security should lead, which should stay cross-functional, and what evidence you should require before you put your name against a system. For security leaders, the Act increases the importance of assurance without deciding who owns AI governance inside the organisation.
The EU AI Act Assigns Duties by Role, Not by Job Title
Read the Act looking for the CISO and you won’t find the role. The obligations attach to operators, defined by what an organisation does with AI systems. An internal org chart doesn’t determine which operator obligations apply.
Three articles set the shape of it for high-risk systems:
- Providers carry the Section 2 obligations under Article 16: ensuring the system meets requirements, maintaining a quality management system, keeping documentation, and ensuring the system undergoes the relevant conformity assessment procedure before it is placed on the market or put into service.
- Deployers carry a separate set under Article 26: using the system according to instructions, assigning competent human oversight, managing input data under their control, monitoring operation, and retaining logs where those logs are under their control.
- Article 17 requires providers of high-risk systems to operate a quality management system that includes an accountability framework setting out the responsibilities of management and other staff.
Article 17 is the closest the Act comes to your question, and it still doesn’t answer it for you. It requires the provider’s accountability framework to set out responsibilities across management and other staff. It doesn’t require one named accountable person or assign a specific corporate title. The CISO’s mandate remains an organisational design decision.
That distinction is why “the Act gives the CISO new legal responsibilities” is a category error. It confuses internal delegation with obligations the Regulation places on providers and deployers. Whether any of these obligations apply at all depends on the system’s classification and your organisation’s role. Not every AI system is high-risk, and not every organisation is a provider. Before the ownership question is even worth asking, the classification and role questions have to be settled, which is the work covered in our guide to what the EU AI Act requires from high-risk AI systems.
Influence AI Governance, Don’t Try to Own It
A security leader creates an avoidable accountability gap by accepting ownership of the whole AI governance programme without the authority and expertise to assess it.
Gartner’s December 2025 CISO guidance is direct on this point: CISOs should influence overall AI governance but resist leading or solely owning it, while leading the cybersecurity governance activities where security has real authority. Gartner also reports that 86% of organisations are piloting, scaling, or extensively deploying generative AI, which makes AI governance an operating question for many organisations (Gartner CISO FAQs).
Hold that line because overall AI governance spans legal interpretation, product intended purpose, data quality and provenance, human oversight design, fundamental-rights impact, and business accountability. Several of those decisions sit outside a security function’s authority and expertise. A CISO who signs for all of them accepts accountability without a reliable basis for the decision.
Organisational practice is running the other way, which is why the boundary is worth stating clearly. Splunk’s 2026 CISO research surveyed 650 global CISOs and found that 96% are responsible for AI governance and risk management (Splunk). It’s a vendor survey, and it measures how organisations are behaving, not what the law requires. The gap between “96% report responsibility” and “the Act names no such role” is the tension a CISO has to manage on purpose, rather than resolve by absorbing everything.
The workable position is: influence the governance programme, and own or co-own the security assurance workstream where the organisation assigns that mandate.
What Security Should Own: The AI Cybersecurity Assurance Workstream
The Act doesn’t assign any workstream to security by job title. For high-risk AI systems, Articles 9 and 15 provide the strongest legal basis for a cybersecurity assurance workstream that security can lead or co-lead under the organisation’s governance model.
Article 9 requires a documented, continuous risk management system for high-risk AI systems, including testing to identify appropriate risk management measures and verify consistent performance. Article 15 requires high-risk systems to be designed and developed to achieve an appropriate level of accuracy, robustness, and cybersecurity throughout their lifecycle, including resilience against attempts to alter their use, outputs, or performance by exploiting vulnerabilities. Article 15 names examples of AI-specific attacks and vulnerabilities where appropriate: data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks, and model flaws.
Under an organisation’s governance model, that translates into a concrete workstream a CISO can lead or co-lead:
- Threat modelling for the named system, covering its architecture, prompts, data flows, tools, permissions, and retrieval sources.
- A security test plan mapped to the attack classes that apply to the system.
- Adversarial testing and control verification, so a claimed control is shown to work rather than assumed to.
- Incident integration, connecting relevant AI monitoring to security operations. Article 72 assigns post-market monitoring duties to providers, while Article 73 and Article 26 set serious-incident reporting and notification duties for providers and, in defined cases, deployers. Security should integrate incidents within its remit while the relevant operator retains the regulatory duty.
- Security input into residual-risk decisions, backed by evidence, with the decision recorded under the organisation’s accountability framework.
This assurance scope extends beyond infrastructure security to the behaviour and resilience of a named AI system across its lifecycle. The voluntary National Institute of Standards and Technology (NIST) AI Risk Management Framework and its generative AI profile help organisations translate governance goals into risk management and evaluation practices.
The Evidence Unit Is One Named AI System, Not a Policy
A policy can state controls, but it can’t show how a production system behaves under data poisoning, prompt injection, model manipulation, tool misuse, or foreseeable misuse. A system approval decision needs evidence beyond policy-level documentation.
What the CISO needs is reviewable system evidence: a system boundary, a threat model, adversarial test records, control evidence, findings with named owners, retest results, logs, and monitoring triggers. For a system approval decision, the useful unit of evidence is one named AI system. An enterprise policy or inventory can’t demonstrate how that system behaves.
A useful discipline here is separating a control claim from a tested control. “We have guardrails” is a claim. Test cases, failure records, remediation, and retest results are evidence. A production review that accepts confident answers instead of artefacts isn’t a review, and our framework for whether an AI system is ready for production review walks through the evidence areas that separate the two.
The attack classes worth testing extend past conventional application security. Article 15 names model and data layer examples. At the application layer, the Open Worldwide Application Security Project (OWASP) 2025 Top 10 for Large Language Models and Generative AI Applications covers risks including prompt injection, sensitive information disclosure, improper output handling, excessive agency, and vector and embedding weaknesses. Those categories include failure modes such as retrieval manipulation and unsafe tool behaviour where they apply. For a primer on how this testing works, see AI red teaming and adversarial testing.
Evidence also has a shelf life. As an assurance rule, reassess a system when changes alter model behaviour, prompts, retrieval sources, tools, permissions, data, intended purpose, or the user population. A test result from before a model swap or a new tool connection describes an earlier system configuration.
A Responsibility Boundary a CISO Can Defend
The cleanest way to hold the line in a real organisation is to write the boundary down before anyone asks you to sign. The framework below is an editorial starting point, not a statement of legal allocation. Internal ownership depends on your organisation’s role, sector, product structure, and governance model, so treat it as a template to adapt rather than a fixed answer.
| Workstream | CISO Role | Likely Accountable Function | Evidence the CISO Should Require |
|---|---|---|---|
| Operator role and high-risk classification | Consulted | Legal, compliance, product, or enterprise risk | Written role and classification decision with assumptions |
| Intended purpose and prohibited-use boundaries | Consulted | Product and business owner with legal review | Intended-purpose statement and prohibited-use controls |
| AI cybersecurity risk management | Lead or co-lead | Security with the system owner | Threat model, risk register, control owners, residual-risk record |
| Robustness and adversarial testing | Lead assurance requirements | Engineering or AI owner for remediation, security for assurance | Test plan, reproducible findings, severity, remediation, retest evidence |
| Data governance and dataset suitability | Consulted on security | Data owner, AI or machine learning (ML) team, privacy, and compliance | Provenance, access controls, quality criteria, change records |
| Human oversight design | Consulted on abuse and control failure | Product, operations, and compliance | Oversight procedure, authority to intervene, test evidence |
| Technical documentation and quality management | Contributor | Provider’s designated compliance or quality owner | Security sections, test records, versioned control evidence |
| Monitoring and incident response | Lead cybersecurity integration | Provider or deployer owner with security and operations | Logs, alerting, escalation paths, incident playbook, post-incident evidence |
| Overall AI Act compliance sign-off | Not sole owner | Executive governance body or designated accountable owner | Consolidated evidence and formal decision record |
The table earns its place through the argument it encodes, which has two parts that have to hold at the same time: security can’t credibly own all of AI governance, and a security approval shouldn’t proceed without system-level evidence. Ignore the first and the CISO inherits workstreams they can’t assess. Ignore the second and the CISO signs on trust. The right-hand column is the part to defend hardest, because it’s the evidence you should require from other owners before you accept any security risk on their behalf.
Where Independent Assessment Fits
Overall AI governance remains cross-functional. The cybersecurity and robustness workstream still needs credible technical evidence. Security and engineering produce and assess that evidence, while legal and compliance determine how it supports the organisation’s regulatory position.
That’s where independent assessment earns its place, with clear limits. An external assessment gives the CISO a separate technical view and a structured evidence pack. It doesn’t own the organisation’s legal interpretation, certify compliance, or replace internal risk acceptance. Accountability and final risk acceptance remain with the organisation’s designated owner.
Independent testing is useful at a specific decision point: when an internal team built the system and governance needs a separate technical view, or when a board, a customer, or a governance body needs evidence beyond self-attestation. The assessment should support a defined decision rather than add documentation without a clear use.
This is the work Provion does. We run independent adversarial testing scoped to one named AI system, then produce structured findings with severity, evidence, and remediation guidance, mapped to the relevant AI Act articles where that mapping applies. We support the cybersecurity and robustness evidence workstream a CISO can own or co-own under the organisation’s governance model. We don’t certify compliance, act as a notified body, or replace legal counsel, and the report is built for security, engineering, and governance teams. For a fuller picture of scope and deliverables, see what an external AI red teaming assessment includes.
What the CISO Should Take Into the Next Decision
The EU AI Act doesn’t make the CISO the owner of AI compliance. For high-risk systems, it creates cybersecurity, robustness, risk management, monitoring, and documentation requirements for the relevant operators. The defensible internal position is narrow and strong: lead AI cybersecurity assurance where the organisation assigns that mandate, require evidence from the other owners, and refuse to sign for risk you can’t assess.
If you’re preparing to approve an AI deployment, answer a customer or procurement review, or brief a board on a specific system, the practical next step is to see what security assurance evidence looks like on the page. Review a Provion sample report for the findings format, severity logic, and evidence structure, or book a scoping call for one named AI system when you have a production decision, a customer review, or a board assurance request in front of you.
