Select your country

Not finding what you are looking for, select your country from our regional selector:

Search

| Blog

AI Act: it all comes down to the SOC, not the compliance documentation

Explore the rules and articles of the AI Act.

TLTR

  • August 2, 2026: the AI Act is no longer a theoretical topic; it is now becoming a practical one; 

  • The Digital Omnibus has shifted responsibility for the AI Act from the compliance department to the security team; 

  • A closer look at this new paradigm with David Racowski, Principal Consultant at Orange Cyberdefense.

Digital Omnibus: looking back

Digital Omnibus is a European Commission initiative presented on November 19, 2025, which aims to simplify and consolidate the complex regulatory framework of digital law: a single cybersecurity entry point, adjustments to the GDPR, and the AI Act.

For the latter, there is one deadline for all organisations: August 2, 2026. The “high-risk” obligations under Annex III (recruitment, scoring, biometrics, essential services) will apply from December 2, 2027, while those under Annex I will apply from August 2, 2028.

In practical terms:

  • Since August 2, 2026 : Article 50 transparency requirements (chatbots, generated content), as well as the AI Office’s supervisory and enforcement powers over providers of general-purpose AI models;

  • From December 2, 2026: end of the grace period for the technical marking of synthetic content for systems already placed on the market;

  • From December 2, 2027: the full set of high-risk requirements, including Article 15 (robustness, cybersecurity) and Article 14 (human oversight);

  • From December 11, 2027: full application of the Cyber Resilience Act, with reporting obligations for exploited vulnerabilities already in force since September 11, 2026.

A sixteen-month period is roughly the time required to implement an oversight programme across an AI environment. However, this postponement has already created a negative effect: projects are being put back into production without proper governance or tooling, on the grounds that “the deadline has moved”. And for a CISO, the deadline that matters is not the regulator’s, but that of the first incident. A compromised model within a critical process triggers an immediate NIS2 or DORA notification, regardless of the AI Act timetable.

Before considering the CISO’s “action plan”, let us take a closer look at Articles 15 and 14 of the AI Act.

The rules of the AI game

Article 15 of the AI Act is the regulation’s key cybersecurity provision: robustness must be demonstrated in production.

It therefore requires high-risk systems to achieve an appropriate level of accuracy, robustness and cybersecurity throughout their lifecycle. It also identifies attack vectors specific to AI: manipulation of the training dataset (data poisoning), alteration of pre-trained components (model poisoning), inputs designed to mislead the model (adversarial examples, model evasion), confidentiality attacks, and intrinsic model flaws.

“Prevent, detect, respond, resolve and control”: these words truly belong to the SOC, not to governance. This is where the market’s most costly point of friction lies. Robustness is not an attribute that can simply be described in documentation at a given point in time; it is a characteristic that evolves over time: a system declared robust in January may no longer be robust in March without a single line of code having been changed, because the input data and third-party components in the AI supply chain have changed.

Article 15 therefore requires the model to be treated as an information system asset:

  • AI systems fall within the SOC’s detection scope, with dedicated rules;

  • The model and its dependencies are included in the asset mapping and SBOM (Software Bills of Materials);

  • Prompts, outputs and performance drift become sources of logs to be collected and correlated;

  • RED TEAMING extends to the model: prompt injection, training data extraction, and bypassing safeguards.

"You shall not pass!"

Article 14 of the AI Act requires high-risk systems to be designed so that they can be effectively overseen by natural persons.

Article 26 shifts the responsibility to the deployer: assigning oversight to competent, trained individuals who are granted the necessary authority, retaining logs, and suspending use in the event of an anomaly. The person responsible is no longer a governance stakeholder, but the one who holds the logs.

The obligation set out in Article 4 reinforces the supervisor’s responsibility and requires “a sufficient level of AI literacy among their staff…”.

Human oversight has therefore shifted responsibility from the governance stakeholder to the SOC (or, failing that, the internal CSIRT/CERT).

The CISO’s governance mapping

The AI Act comes into force at a time when regulatory compliance programmes are already being implemented across organisations; it may be tempting to launch a dedicated AI Act programme independently of NIS2, DORA or CRA compliance efforts. However, the requirements overlap, and the evidence can be shared across these frameworks.

  • Article 15 / NIS2: risk management, supply chain security and incident handling already cover most of the core requirements; the gap lies in threats specific to the AI model implemented by the organisation; 

  • AI Act / DORA: in the financial sector, registers of critical ICT third-party providers and resilience testing provide a natural framework for integrating AI providers;

  • AI Act / CRA: AI embedded in a connected product falls under both regulatory regimes, with two deadlines just nine days apart in December 2027; 

  • Common foundation: asset mapping, logging, vulnerability management, incident notification and crisis exercises.

The CISO checklist: 10 actions before December 2027

  1. Inventory all AI systems in production and under development, including shadow AI and features enabled by default in SaaS tools;
  2. Classify each system: role (provider or deployer), risk level, applicable annex;
  3. Appoint an operational owner for each system, separate from the business sponsor;
  4. Integrate AI models, datasets and dependencies into the CMDB (Configuration Management Data Base) and the SBOM;
  5. Enable logging of prompts, outputs and decisions, with a compliant retention period;
  6. Create dedicated detection use cases: model drift, prompt-based exfiltration, abnormal agent behaviour;
  7. Extend the penetration testing and red teaming programme to models and agents;
  8. Contractually define security, notification and auditability commitments with AI providers;
  9. Train and raise awareness among oversight operators about AI failure modes, and document this training;
  10. Run a crisis exercise based on an AI scenario: data poisoning, compromised agent, manipulated output.

FAQ

My company is not an AI provider. Am I affected? Yes, as a deployer. Article 26 of the AI Act requires oversight by competent and authorised individuals, the retention of logs, and the suspension of the system in the event of an anomaly: these are operational security obligations.

Robustness or cybersecurity: what is the difference under Article 15? Robustness refers to resilience against errors, failures and inconsistencies. Cybersecurity refers to resistance against attempts by unauthorised third parties to alter the system’s use, outputs or behaviour, as well as against internal threats.


Does an incident involving an AI system need to be reported today? If the system supports an essential service or a critical function, NIS2 or DORA obligations already apply, without waiting until December 2027. The reporting of serious incidents required under the AI Act will be added to these obligations.

Is a dedicated tool required for AI Act compliance? Rarely. Most of the cybersecurity requirements under Article 15 can be met by extending existing measures: asset mapping, logging, detection, vulnerability management and incident response.

Where should we start if nothing has been done yet? With the inventory. No requirement can be demonstrated across an AI environment that has not been identified, and this inventory does not depend on any future harmonised standard.

What about proprietary data?

Proprietary data is the new asset of credibility. Generative answer engines, such as Google AI Overview, are redistributing visibility in favour of sources that provide first-hand, verifiable and attributable data. Generic analyses are fading into the background, while proprietary data is being cited.

The logic is the same as that of the AI Act: a claim without evidence is worth nothing, whether before a regulator or a search engine. This is why the Security Navigator 2026 by Orange Cyberdefense, with more than 139,000 incidents analysed between October 2024 and September 2025 across 160 countries, including 19,053 confirmed incidents, can provide a factual basis on which to calibrate an AI risk model.

And to assess your organisation’s maturity against the AI Act’s cybersecurity requirements, book a sit and talk with one of our Orange Cyberdefense experts.

More expert reading:

24/7 incident hotline