CISO × EU AI Act Compliance Consulting

CISO and the EU AI Act: what do AI security, logs and human oversight require?

Updated 2026-11-03

Short answer

Under the EU AI Act a CISO owns three things: the security of AI systems (Article 15 requires high-risk AI to resist data poisoning, model poisoning, adversarial examples and confidentiality attacks), traceable records (Article 12 automatic logging; deployers keep logs for at least six months) and human oversight that can actually stop the system (Article 14). Start by mapping the role and risk tier of every AI system, then fold serious AI incident reporting into your existing security incident response. The EU AI Act has no standalone certificate, and ISO 42001 certification does not create a presumption of conformity.

What should a CISO inventory first to know which AI systems fall under the EU AI Act?

  • Scope: placing an AI system on the EU market, or using its output in the EU, brings you into scope even without an EU establishment (Article 2(1)).
  • Two decisions per system: your role (provider, deployer, importer or distributor) and the risk tier (Article 5 prohibitions, Annex I or Annex III high-risk, Article 50 transparency).
  • Roles can change: putting your name or trademark on a third-party AI system, substantially modifying a high-risk system, or changing the intended purpose so that it becomes high-risk makes you a provider under Article 25(1).
  • Application dates (as amended by the Digital Omnibus, Regulation (EU) 2026/1744): Annex III high-risk systems from 2 December 2027, Annex I products from 2 August 2028; Article 50 transparency obligations have applied since 2 August 2026.

Record the reasoning in the AI system inventory. What to do when your role changes

How do the high-risk AI security requirements (Article 15) differ from our existing security controls?

Article 15 requires high-risk AI to maintain an appropriate level of accuracy, robustness and cybersecurity throughout its lifecycle, and to resist attempts by unauthorised third parties to alter its use, outputs or performance by exploiting vulnerabilities. Unlike general security controls, it names AI-specific vulnerabilities; technical measures should, where appropriate, prevent, detect, respond to, resolve and control attacks on:

TargetTerm in the Article
Training data setData poisoning
Pre-trained components used in trainingModel poisoning
Inputs designed to cause mistakesAdversarial examples or model evasion
ConfidentialityConfidentiality attacks or model flaws

ISO 27001 controls can serve as the base, but AI-specific testing has to be added. For AI systems that are also CRA products with digital elements, meeting CRA Article 12 counts as meeting the cybersecurity requirements of AI Act Article 15.

How far must human oversight go? Which "stop" mechanisms should a CISO verify?

Article 14 requires high-risk AI to be designed so that natural persons can oversee it effectively. Under Article 14(4), the people assigned to oversight must be able to:

  • understand the system's capacities and limitations, monitor its operation and detect anomalies;
  • remain aware of the tendency to over-rely on its output (automation bias);
  • correctly interpret the output;
  • decide in any situation not to use the system, or to disregard, override or reverse its output;
  • intervene or interrupt the system through a "stop" button or similar procedure that brings it to a halt in a safe state.

On the deployer side, Article 26(2) requires oversight to be assigned to natural persons with the necessary competence, training and authority. The CISO should confirm three things: who holds the authority to stop, how the system is restored afterwards, and whether drills are recorded. Where AI can issue refunds or change orders, place the human checkpoint before high-impact operations. Further reading: Monthly model updates and AI that changes orders: who approves, stops and restores?

What should AI system logs record, and how long must they be kept?

  • Provider side: Article 12 requires high-risk AI to technically allow automatic recording of events (logs) over its lifetime, to identify situations that may present a risk or a substantial modification, to support post-market monitoring, and to support deployers' monitoring of operation.
  • Deployer side: Article 26(6) requires deployers to keep the logs under their control for a period appropriate to the intended purpose, of at least six months, unless Union or national law, in particular on personal data protection, provides otherwise.

The CISO's job is to bring AI logs into existing log management and access control and to set a retention period; where logs contain personal data, decide retention and data minimisation together with legal.

When an AI system causes a serious incident, how do we fold it into our existing incident reporting?

Article 73 requires providers of high-risk AI placed on the EU market to report serious incidents to the market surveillance authority of the Member State where the incident occurred:

SituationDeadline
Serious incident in generalImmediately after a causal link or its reasonable likelihood is established, at the latest 15 days after awareness
Widespread infringement, or a case under Article 3, point (49)(b)Immediately, at the latest 2 days after awareness
Death of a personImmediately, at the latest 10 days after awareness

An incomplete initial report may be submitted first, followed by a complete one. Deployers monitor operation under Article 26(5) and inform providers where relevant.

In practice, list the serious AI incident alongside the GDPR, NIS2, DORA and EU CRA deadlines in a single incident classification step. The European Commission has issued draft guidance on Article 73 for consultation; the final text is whatever the Commission publishes.

How should the board report present EU AI Act exposure and readiness?

  • Penalties (Article 99, whichever is higher; for SMEs whichever is lower): breaching the Article 5 prohibitions, up to EUR 35 million or 7% of worldwide annual turnover; breaching other obligations and Article 50 transparency, up to EUR 15 million or 3%; supplying incorrect information, up to EUR 7.5 million or 1%.
  • Where certificates stop: the EU AI Act has no standalone certificate; ISO/IEC 42001 is not a harmonised standard and certification gives no presumption of conformity.
  • Report contents: AI system inventory and risk tiers, the application date for each system, Article 15 test results and Article 14 oversight drills, AI incident records.

Listed companies can fold this into the regular cybersecurity report to the board or management under Article 37 of the TWSE and TPEx Cybersecurity Control Guidelines for Listed Companies; companies that are not public companies are not covered by these guidelines and can use them voluntarily.

How does Winners Consulting help a CISO with the EU AI Act?

  • Classify first: an AI system risk classification diagnosis, then a compliance path by risk tier
  • Three core documents: AI system inventory, AI risk and impact assessment, EU AI Act obligation matrix
  • One set of evidence: an ISO 42001 management system mapped article by article to Articles 9 to 17 to close the gaps, sharing a backbone with ISO 27001 and 27701
  • Statutory steps: technical documentation, conformity assessment and EU database registration; serious incident reporting folded into the existing security incident process
  • Timeline (as listed on the service page): high-risk AI compliance usually 6–9 months, 9–12 months when integrated with ISO 42001 certification
  • Who leads: VP- and director-level consultants lead the work end to end, never outsourced; the first assessment is free

More: EU AI Act consulting, Choosing an EU AI Act consultant, Sharing AI evidence with 27001, CISO role page

How other roles see this service

Other services for this role

Back to the role overview: Which standards and laws does a CISO own? 12 requirements explained one by one

Official sources