The EU AI Act, Regulation (EU) 2024/1689, is the European Union's horizontal law for artificial intelligence. It classifies AI systems by the risk their use creates, assigns duties according to whether you build a system or use one, and phases those duties in over several years. It is a product safety and fundamental rights instrument rather than a security regulation, which is exactly why security teams keep getting handed pieces of it without a clear brief.
On 2 August 2026, the Article 50 transparency obligations became applicable, and the Act reached its general application date. The penalties provisions and the Act’s supervisory architecture had already applied since 2 August 2025, while the heavier high-risk regime was deferred. That split is the single most important thing for security teams to understand before deciding what needs action now and what can use the additional runway.
This guide covers what applies now, which responsibilities actually reach the security function, and what CISOs should be doing with the runway before the deferred high-risk requirements arrive.
A great deal of material published before July describes a legal position that no longer holds. The high-risk deadlines moved, leaving the compliance calendar running at two speeds.
Live as of 2 August 2026: the transparency obligations in Article 50, covering systems that interact directly with people, systems that generate synthetic content, emotion recognition and biometric categorization, and deepfakes or text published on matters of public interest. The Act also reached its general application date, while the prohibited-practice rules, general-purpose model obligations, supervisory provisions, penalties chapter, and AI literacy duty had already begun applying on earlier dates.
The high-risk regime is not yet in force. Conformity assessment, technical documentation, registration, and the deployer duties in Article 26 apply to stand-alone Annex III systems from 2 December 2027 and to high-risk AI embedded in Annex I regulated products from 2 August 2028.
The transparency rules include a narrow transition period that security teams need to distinguish from a broader delay. Generative systems already on the market before 2 August 2026 have until 2 December 2026 to meet the machine-readable marking requirement in Article 50(2), but this is a limited transition, not a postponement of the transparency rules as a whole. It does not extend to systems placed on the market on or after 2 August, nor does it cover the deployer-facing duties in Article 50(4), such as deepfake labeling. Content generated before 2 August 2026 does not have to be marked retroactively.
The financial exposure is already real. Article 99 sets three penalty ceilings: up to 35 million euros or 7 percent of total worldwide annual turnover for the prohibited practices in Article 5; up to 15 million euros or 3 percent for most provider and deployer obligations, including the Article 50 transparency duties; and up to 7.5 million euros or 1 percent for supplying incorrect or misleading information to an authority. For an undertaking, the higher of the two figures applies; for SMEs and startups, it is the lower, and the July amendment extended a reduced cap to small mid-caps.
The penalties provisions have applied since 2 August 2025, so this is not a future enforcement regime. The transparency duties that became applicable this month sit in the 3 percent tier, meaning an undisclosed customer-facing chatbot can already create material regulatory exposure.
Warning: A 16-month deferral of the high-risk regime is not a reason to defer the work. Several of the requirements now due in December 2027 have long implementation lead times, including documentation, fundamental rights impact assessments, and vendor requalification. Organizations that treat the new deadline as a starting date risk arriving there without the controls or evidence needed to comply.
Almost everything downstream depends on this, but security teams may not know which role applies to each AI system in their environment. A provider develops an AI system or has one developed and places it on the market under its own name. A deployer uses an AI system under its own authority in a professional context. Most enterprises buying AI tooling are deployers.
Deployer is not a safe harbor. It changes which articles reach you first. Under Article 26, deployers of high-risk systems must use the system according to the provider's instructions, assign human oversight to people with the competence, training, and authority to intervene, keep the relevant input data appropriate, monitor operation and report serious risks or incidents, retain automatically generated logs under their control for at least six months, and inform workers before a high-risk system is used in the workplace.
The risk is crossing the boundary between the two roles. Making a substantial modification to a high-risk system, putting your own name on it, or using it outside its intended purpose can make you a provider under Article 25, with the full provider obligation set attached. Security should flag that possibility with engineering before systems are modified or repurposed: fine-tuning a purchased model or wrapping a vendor system in your own product can change your organization's legal role, not just the system's architecture.
Note: Role is assessed per system, not per organization. A company can simultaneously be a deployer of a purchased screening tool and a provider of an internal assistant it built, with different duties attaching to each.
The Act sorts systems by the risk their use creates. Those legal risk tiers do not map directly to security risk: a system with limited or no specific obligations under the Act can still have broad access to sensitive data, identities, and business systems.
The base tier is where the disconnect shows most clearly. A note-taker that joins every meeting and retains transcripts carries no specific AI Act obligation in most deployments. It can still create significant security exposure because it holds a standing grant to your calendar and your conversations. The Act is not a security program, and treating its tiers as a security priority list can leave material security exposure outside your compliance-driven controls.
Every obligation above assumes you can name the AI systems operating in your environment, say who is responsible for each, and classify them. That makes inventory a prerequisite for compliance, but AI is particularly difficult to inventory because it can enter the environment through consent screens and vendor feature releases rather than formal procurement.
Two categories should come first. The first is user-facing AI, including chatbots, voice agents, and content generation in customer-facing workflows, because Article 50 applies now. The second is AI with standing access to systems of record, where persistent permissions increase the security impact and may intersect with future high-risk obligations.
Navigate to AI Agent Security
The inventory that matters is not the list of approved AI. It is the AI actually operating in your environment, including the tools employees connected without asking and the AI nobody approved, discovered from identity providers and connected applications rather than from a survey. Reco continuously inventories discovered AI applications and agents, connected identities, authorization status, and permission context, giving security teams a factual starting point for classification. The legal classification, provider or deployer determination, and resulting records still have to be decided and documented by your organization.
Action: Run the discovery before the classification workshop, not after. Classifying an assumed application list creates a compliance record that may not reflect the AI actually operating in your environment.
For high-risk systems, several requirements overlap with controls and processes security teams already operate. Article 15 covers accuracy, robustness, and cybersecurity. Article 12 covers record-keeping and automatically generated logs. Article 14 covers human oversight. Article 26 places corresponding operational duties on deployers, including monitoring, escalation, and a six-month minimum retention period for automatically generated logs under their control.
Much of the operational machinery already exists. Log retention, monitoring, and incident escalation are established security disciplines. What is new is that log retention has a legal minimum, that oversight has to be assigned to people with the required competence, training, and authority, and that the escalation path can extend to the provider and relevant market surveillance authority rather than stopping internally.
The practical implication for a program starting now is to extend existing security processes rather than build a parallel AI compliance function. Where existing controls can support the requirement, use them and add the AI-specific evidence, ownership, and retention requirements the Act introduces.
Prioritize the work based on when the obligations become enforceable, using the high-risk deferral to start the controls with the longest lead times.
One organizational point determines whether this work becomes operational: ownership. A practical model is for legal or compliance to lead the classification and role determination, since both determine which regulatory obligations apply. The business owns the use case and the decision to keep it. Security owns the technical evidence those decisions depend on: knowing what is actually running, what it can reach, who approved it, and whether the logs exist. Define those responsibilities explicitly so legal makes the regulatory determination, the business remains accountable for the use case, and security provides the visibility and evidence needed to support both.
One last point, and it is the one worth taking to the board. EU AI Act compliance starts with knowing what AI you are running, what it is used for, who is accountable for it, and whether you can produce the evidence to support those answers. Security is only one part of the Act, but inventory and ownership are foundational to putting its requirements into practice. The same foundation also supports the broader AI governance questions addressed by other AI frameworks. Build that foundation once, and each new obligation becomes easier to classify, assign, evidence, and monitor.
This article is general information current as of August 2026, not legal advice, and not a guarantee of any compliance outcome; obligations turn on facts specific to each organization, so verify them against the Official Journal text and with qualified counsel.
%201.svg)
Gal is the Cofounder & CPO of Reco. Gal is a former Lieutenant Colonel in the Israeli Prime Minister's Office. He is a tech enthusiast, with a background of Security Researcher and Hacker. Gal has led teams in multiple cybersecurity areas with an expertise in the human element.
%201.svg)
.svg)