The EU AI Act, Explained: What Businesses Actually Need to Know

The EU AI Act is no longer a future regulation to prepare for. As of August 2026, most of it is already in force. It also applies far beyond companies headquartered in Europe. If your AI system’s output reaches someone in the EU, the regulation likely reaches you too.

That surprises a lot of teams. Many still treat the EU AI Act as a distant compliance project, something to revisit “closer to the deadline.” In practice, though, the deadlines have already started passing. More are coming through 2027.

This post breaks down what the regulation actually says. It covers how the EU AI Act classifies risk, what it bans outright, what it demands from high-risk systems, and what your team should be doing right now.

What Is the EU AI Act, Exactly?

Formally, it’s Regulation (EU) 2024/1689. It defines an AI system broadly. A machine-based system that operates with some autonomy, may adapt after deployment, and infers from its inputs how to generate outputs such as predictions, content, recommendations, or decisions all counts.

That definition matters because it’s intentionally wide. It covers everything from a resume-screening tool to a large generative model. It isn’t limited to headline-grabbing systems like facial recognition or autonomous vehicles.

Just as importantly, the EU AI Act reaches outside the EU’s borders. Say you place an AI system on the EU market, or its output gets used within the EU. Either way, you fall under scope. Location alone doesn’t exempt anyone, and neither does routing your AI infrastructure through a non-EU subsidiary.

The EU AI Act’s Risk-Based Approach

Rather than regulating every AI system the same way, the EU AI Act sorts systems into risk tiers. Each tier carries a different level of obligation.

At the top sits unacceptable risk: practices banned outright, with no compliance path available. Below that comes high-risk, meaning systems that stay on the market but only under strict obligations around risk management, documentation, and oversight. Below that sits limited risk, which mainly triggers transparency duties, such as disclosing that content was AI-generated. Everything else falls into minimal risk, where the regulation imposes no binding requirements at all.

This structure explains why compliance work looks so different from one AI use case to the next. A chatbot on a retail website faces a light touch. A tool used to screen job applicants faces a heavy one, even though both are technically “just AI.”

What’s Banned Outright Under the EU AI Act

Article 5 lists AI practices the EU AI Act prohibits entirely, regardless of sector or safeguards. These prohibitions have applied since February 2025, well ahead of the rest of the regulation.

Banned practices include AI systems that use subliminal or manipulative techniques to distort someone’s behavior in ways that cause harm. They also include systems that exploit vulnerabilities tied to a person’s age, disability, or economic situation. Social scoring by public or private actors is banned too. So is untargeted scraping of facial images from the internet or CCTV footage to build recognition databases.

A few other practices sit in this banned category with narrow carve-outs. Emotion recognition in workplaces and schools is prohibited, except for medical or safety purposes. Real-time remote biometric identification in public spaces for law enforcement is banned by default as well. A narrow exception exists for cases like searching for abduction victims or preventing an imminent terrorist threat. Even then, courts and strict safeguards apply before any deployment.

High-Risk AI Systems Carry the Heaviest Obligations

Annex III of the EU AI Act lists the areas where AI systems are automatically classified as high-risk. They include biometric identification and critical infrastructure. They also cover education and vocational training, employment and worker management, and access to essential public and private services. Law enforcement and migration and border control round out the list.

Falling into one of these categories doesn’t ban the system outright. Instead, it triggers a substantial compliance package. Providers must run a risk management process across the system’s lifecycle. They must maintain detailed technical documentation, ensure meaningful human oversight, and build in logging and traceability. Registration in an EU database is required too, before the system ever reaches deployment.

There’s a narrow exception worth knowing. A system that performs only a narrow procedural task, or one that merely improves on already-completed human work without replacing human judgment, may fall outside the high-risk category. But that exception has limits. Any system that profiles natural persons is automatically treated as high-risk, no matter how narrow its stated task looks.

General-Purpose AI Models Get Their Own Rules

Large generative models don’t fit neatly into the high-risk framework built around specific use cases. So the EU AI Act creates a separate track for general-purpose AI (GPAI) models instead.

All GPAI providers must maintain technical documentation. They also need to give downstream developers the information required to use the model responsibly. On top of that, providers must put a policy in place to comply with EU copyright law, including a summary of the content used to train the model.

Models presumed to carry systemic risk face additional duties. These include model evaluation, adversarial testing, incident reporting, and cybersecurity protections for the model itself. Open-source models get some relief from the transparency rules above. That relief disappears, however, the moment a model is considered to present systemic risk.

Transparency Obligations: Chatbots and Deepfakes

Article 50 covers systems that don’t reach high-risk status but still need to be honest with users about what they’re looking at.

Providers must ensure people know when they’re interacting with an AI system rather than a human. The exception is when that fact is already obvious from context. Separately, deployers of systems that generate deepfakes must disclose it too. A deepfake here means AI-manipulated image, audio, or video content that resembles a real person, place, or event.

These aren’t heavy obligations compared to the high-risk tier. Still, they’re easy to miss. That’s especially true for marketing or content teams experimenting with generative tools without security or legal in the loop.

The EU AI Act Timeline: What Applies When

The EU AI Act didn’t arrive all at once. It phases in across several dates, and by August 2026, most of those dates have already passed.

Prohibited practices under Article 5 became enforceable on 2 February 2025. That date also brought the general provisions and AI literacy obligations in Chapters I and II. Governance structures, GPAI obligations, and the penalty framework followed on 2 August 2025. Then, on 2 August 2026, the bulk of the regulation became applicable, including most high-risk system obligations under Annex III.

One piece still remains on the horizon. High-risk AI systems that serve as safety components of products already regulated under other EU harmonization law, think machinery or medical devices, get extra time. Article 6(1) and its corresponding obligations won’t apply to them until 2 August 2027.

Penalties: How Much Non-Compliance Actually Costs

The EU AI Act backs its obligations with real financial exposure. The amounts scale with the type of violation, not a flat penalty across the board.

Violating the Article 5 prohibitions carries the steepest penalty: fines up to €35 million, or 7% of global annual turnover, whichever is higher. Non-compliance with high-risk system obligations, transparency duties, or requirements for importers and distributors caps lower, at €15 million or 3% of turnover. Supplying incorrect or misleading information to regulators tops out at €7.5 million or 1% of turnover.

For SMEs and startups, each of those caps applies at whichever figure is lower, not higher. That softens the blow somewhat. Even so, regulators weigh factors like intent, cooperation, and harm caused when setting the actual fine. In other words, the ceiling isn’t the only number that matters.

How to Start Preparing

Given how much of the EU AI Act is already active, the practical question isn’t whether to prepare. It’s where to start.

Begin with an inventory. Map every AI system your organization builds, buys, or deploys. Don’t forget tools embedded in third-party software that teams may not even think of as “AI.” From there, classify each system against the risk tiers above, since that classification determines everything else about your obligations, from documentation depth to whether you can deploy the system at all.

If you already run an ISO 27001 or NIS2 compliance program, resist the urge to treat AI governance as a separate track. The EU AI Act’s risk management, documentation, and audit requirements overlap heavily with controls you likely already have in place. Extending an existing information security management system to cover AI systems and their data pipelines is far more efficient than building a parallel compliance silo from scratch. It also keeps a lean compliance team from drowning under yet another standalone framework.

For related reading, see your Secure by Design and Default guide, your Cyber Resilience Act compliance guide, and your ISO 27001 documentation checklist.

The Takeaway

The EU AI Act is no longer a regulation on the horizon; it’s current, active law for most AI systems on the EU market. Its prohibitions have been enforceable since early 2025. Its core obligations took effect in August 2026. Only one narrow category, embedded high-risk systems inside already-regulated products, still has runway left, until August 2027.

The fastest path forward is classification. Once you know which risk tier each of your AI systems falls into, the rest of the compliance work follows a clear, documented path from there.

Sources: Regulation (EU) 2024/1689 (Artificial Intelligence Act) — EUR-Lex

Secure by Design: What ENISA’s New Playbook Means for Small Teams

Most small software and hardware teams agree that security matters. But agreeing isn’t the hard part. The hard part is knowing exactly what to build. Do it with almost no spare budget or dedicated security staff, and the gap between intention and execution grows fast.

That’s the gap ENISA just tried to close. In July 2026, the EU Agency for Cybersecurity published the Secure by Design and Default Playbook. It’s a practical guide built specifically for small and medium-sized enterprises. The document doesn’t just repeat the usual “shift security left” advice. Instead, it breaks secure by design into 22 concrete playbooks. Each one comes with a checklist, a minimum-evidence list, and a release gate your team can copy straight into a pull request template.

This post walks through what the playbook actually says. It covers why the guidance exists now, and how a lean team can start using it without hiring a security department first.

The guidance targets a specific audience: software developers, technical product managers, SME security leads, and system architects working with limited resources. If that sounds like your team, the playbook was written with you in mind, not with a Fortune 500 security org.

Why Secure by Design Needed Its Own Playbook

Secure by design sounds simple: build protection in from the start instead of bolting it on later. However, simple ideas don’t always translate into simple action.

ENISA points to a familiar pattern. SME manufacturers face budget constraints, limited security expertise, and constant time pressure from the business. As a result, principles that sound obvious in a conference talk often stay unimplemented in the actual codebase.

The Cyber Resilience Act (CRA) raises the stakes further. Products with digital elements sold in the EU must now demonstrate an appropriate level of cybersecurity. They must also ship with secure default configurations and support timely security updates. So secure by design isn’t just good practice anymore. For many manufacturers, it’s becoming a market-access requirement.

The playbook doesn’t offer legal advice. Instead, it gives engineering teams something more useful day to day: a repeatable way to translate CRA-relevant principles into ordinary sprint work.

Two Ideas, Four Categories

ENISA organizes its guidance around two related but distinct concepts.

Secure by design covers how a system is built. It means embedding threat modeling, secure architecture patterns, and vulnerability management into development from day one. That’s very different from retrofitting them after launch.

Secure by default covers what happens when a user first turns the product on. A secure-by-default product ships with the most protective configuration reasonably possible. Users shouldn’t need expert knowledge just to stay safe out of the box.

Within secure by design, ENISA groups principles into architectural foundations and operational integrity. Architectural foundations cover how the system is structured. Operational integrity, meanwhile, covers how it’s managed and maintained after launch. Within secure by default, principles split into default hardening and guided protection. Default hardening describes the factory-shipped state. Guided protection, in turn, describes how the system helps users stay secure over time.

Together, these four categories organize all 22 playbooks. They range from trust boundaries and least privilege through to secure recovery and ownership transfer.

Inside a Playbook: How the Checklists Actually Work

Each of the 22 playbooks follows the same five-part structure. That consistency is part of what makes the guide so usable for small teams.

First comes the principle itself, stated in one sentence. Next comes the objective: what failure mode this principle is meant to prevent. Then a checklist lists the highest-impact actions. These are written to be achievable by lean teams, not large dedicated security functions.

After that, a minimum evidence section names the smallest set of artifacts that prove the checklist was actually implemented. Finally, a release gate offers pass/fail criteria you can paste directly into a CI pipeline or release review.

For example, take attack surface minimization. The checklist asks teams to list every exposed interface and enforce default-deny network rules. It also asks them to strip development and diagnostic tooling from production builds, and to minimize the data they collect in the first place. The release gate then confirms, before each release, that no new port or admin endpoint slipped through unreviewed.

This format matters because it turns “be more secure” into something a developer can actually check off during a pull request review.

The Principles Cover the Whole Product Life Cycle

The 22 playbooks map onto every stage of a product’s life, not just the coding phase.

Trust boundaries and threat modeling come first. Teams need to know what they’re protecting before they can protect it. Least privilege, strong identity architecture, and defence in depth follow next. Together, these form the architectural backbone of the system.

Operational integrity principles then take over. This includes secure coding practices, logging and monitoring, incident response, and vulnerability and patch management. Supply-chain controls round out the design side. They cover everything from signed build artifacts to software bills of materials (SBOMs).

On the default side, the playbook addresses what ships in the box. That means minimized default services, no shared admin credentials, encrypted communication from the first connection, and unique per-device secrets. Guided protection principles then help users stay secure after setup. They do this through mandatory onboarding steps, automatic updates, and clear warnings whenever someone disables a protection.

Notably, ENISA treats these life-cycle stages as iterative rather than sequential. A vulnerability found in production should trigger a return to earlier threat-modeling and risk-assessment steps, not just a quick patch and a shrug.

Threat Modeling Without the Overhead

Many small teams avoid threat modeling because it sounds like a multi-week exercise reserved for enterprise security departments. In practice, ENISA pushes back on that assumption directly.

The playbook recommends Adam Shostack’s four-question framework as a lightweight starting point. What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? Teams can answer these with a single diagram and a short list of top threats. A simple table mapping each threat to its mitigation rounds out the exercise.

The goal isn’t exhaustive documentation. It’s a minimum viable model that’s fast to produce and easy to refresh. Crucially, it should stay tightly coupled to real design decisions. A threat model nobody updates after the first release isn’t worth building in the first place.

Proving It, Not Just Claiming It

One of the more forward-looking sections of the playbook covers machine-processable attestation. Instead of relying on a static PDF report that nobody reads after the audit, ENISA describes how security claims can be expressed as structured, machine-readable data.

For instance, a signed attestation might state that a product enforces TLS 1.3 with AES-256 encryption. That claim then links to actual evidence, such as a configuration scan, a test result, or a build log. Automated systems can verify the claim without waiting on a human reviewer.

For an SME, this matters because it replaces expensive manual audits with automated checks that run on every release. Still, the playbook is careful to note the limits. An attestation alone doesn’t prove a product is secure. Verification and independent assessment remain separate, necessary steps. Structured evidence simply makes both of those steps faster and cheaper to carry out.

How to Start Without Boiling the Ocean

Twenty-two playbooks can feel overwhelming for a five-person engineering team. Fortunately, ENISA anticipated this reaction and suggests a progressive adoption path instead.

Start by establishing context. Define your product’s scope, users, and top risks using the lightweight threat-modeling approach described above. From there, build a foundational baseline covering secure coding practices, logging and monitoring, vulnerability management, and supply-chain controls. If your product handles user access, add restrictive initial access and secure-by-default communication to that baseline too.

Only after that foundation is in place should teams work through the remaining playbooks. Prioritize them by your specific risks and deployment context, not by the order they appear in the document. Progressive adoption isn’t an excuse to delay CRA obligations, though. It’s simply a realistic sequence for teams working with limited time and limited hands.

The Takeaway

Secure by design has always been easy to endorse and hard to operationalize. ENISA’s playbook doesn’t remove that difficulty entirely. But it does turn a vague principle into 22 checklists a small team can actually run through before shipping. Given the CRA’s incoming requirements, that shift from aspiration to action is exactly what most manufacturers need right now.

If your team hasn’t run a lightweight threat model yet, that’s the natural place to start. Everything else in the playbook builds outward from there, one release gate at a time.

For teams already navigating CRA compliance, the playbook is also worth reading alongside Annex C of the original document. It maps each of the 22 principles directly to specific CRA essential requirements, which can save real time when you’re building an internal compliance case. In other words, the checklist work you do for engineering reasons doubles as evidence for regulatory reasons too.

Source: ENISA, Secure by design and default playbook