Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  /

  / The EU AI Act in 2026: What It Means for Businesses

The EU AI Act in 2026: What It Means for Businesses

The world’s first comprehensive AI law is not a single switch that flips on in August 2026. It is a layered regulation that has been activating in stages since February 2025. As of May 2026, it is already being rewritten to give companies more time on the hardest parts. Anyone trying to plan around a single deadline is working from a map that no longer matches the territory.

The law’s reach is also global. Just as GDPR exported European privacy norms worldwide, the EU AI Act is producing a Brussels Effect for artificial intelligence: a regulation drafted in Europe that becomes the de facto global standard. Companies in the US, the UK, Bahrain, and anywhere else with EU customers or EU-facing outputs are already in scope, whether or not they have a European office.

This guide cuts through the noise. It explains what the EU AI Act actually requires, who it applies to, which rules are already live, which were just pushed back by the EU’s recent simplification deal, and what the penalties really look like for companies of different sizes.

The EU AI Act in 2026 What It Means for Your Business

What Is the EU AI Act?

The EU AI Act (Regulation (EU) 2024/1689) is a horizontal law that sets harmonised rules for developing, placing on the market, and using artificial intelligence systems across the European Union. It is the first comprehensive AI law passed by any major regulator anywhere in the world, and it entered into force on 1 August 2024.

The Act takes a risk-based approach. Rather than regulating AI as a single category, it sorts AI systems into tiers based on the harm they could cause to health, safety, or fundamental rights. The higher the risk, the stricter the obligations. Prohibited uses are banned outright. High-risk uses are heavily regulated. Most everyday AI — like spam filters and product recommenders — is left alone.

The law also creates a separate, parallel regime for general-purpose AI (GPAI) models, the foundation models behind systems like ChatGPT, Claude, and Gemini. That regime is enforced at the EU level rather than at the national level.

Why Was the EU AI Act Created?

The official answer is to foster trustworthy AI in Europe. The real answer is broader: the EU watched generative AI go mainstream in late 2022 and concluded that existing law — particularly GDPR — was not enough to address the specific risks AI systems pose. Opacity in decision-making, bias in hiring tools, biometric surveillance, and the manipulation potential of generative models all sat uneasily in the regulatory gap between data protection law and product safety law.

The EU’s stated goals are to protect health, safety, and fundamental rights, while preserving innovation and the single market. The political subtext is the Brussels Effect: do for AI what GDPR did for privacy, and let European rules become the global default by virtue of market access. Brazil, Canada, the UK, several US states, and Gulf jurisdictions, including Bahrain, are already drafting AI rules that borrow heavily from the EU framework. For a broader view of how AI governance is likely to evolve through the end of the decade, the trajectory is already becoming clear.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Who Does the EU AI Act Apply To?

The Act does not apply to AI itself. It applies to people and organisations that build, sell, or use AI systems. Article 3 defines those roles without reference to company size, so a two-person startup is in scope on the same legal basis as a Fortune 500 enterprise.

Providers and Developers

A provider is anyone who develops an AI system — or has one developed — and places it on the EU market or puts it into service under their own name or trademark. Providers carry the heaviest load of obligations, particularly for high-risk systems: risk management, technical documentation, conformity assessment, post-market monitoring, and incident reporting.

A provider is distinct from a downstream developer who simply integrates a third-party AI component. But the line moves: if you take a general-purpose model and put your name on the resulting product, you can become a provider yourself.

Deployers and Operators

A deployer is anyone using an AI system in a professional capacity. If you are a bank running a credit-scoring model you bought from a vendor, you are a deployer. Deployers have lighter obligations than providers but still carry real ones: ensuring human oversight, monitoring system behaviour, informing affected individuals, and conducting fundamental rights impact assessments where required.

The term operator in the Act is an umbrella that covers providers, deployers, importers, distributors, and authorised representatives.

Application Outside the EU

This is where many non-EU companies get caught. The AI Act applies extraterritorially. A US LLC training a model in Texas, a UK firm running an AI hiring tool, or a Bahrain-based fintech using AI for credit scoring is in scope the moment the output affects someone in the EU. If a US company develops an AI hiring tool and a German employer uses it on German candidates, the US provider is in scope — even with no EU office. The trigger is whether the system’s output is used in the Union, not where the company sits.

Pro Tip: Selling AI tools to EU customers outside the EU.

If you sell AI tools to EU customers from outside the EU, you must appoint an authorised representative established in a Member State before placing high-risk systems on the market. This is not optional and is one of the most commonly missed obligations for non-EU providers.

The Risk-Based Approach: How the EU AI Act Classifies AI Systems

The framework sorts AI systems into four tiers. The obligations scale with the tier.

Unacceptable Risk: Prohibited AI Practices

Article 5 prohibits eight categories of AI practice outright. These prohibitions became enforceable on 2 February 2025, well before the rest of the Act. The banned practices are:

Subliminal or manipulative techniques are designed to distort behaviour and cause significant harm. Exploitation of vulnerabilities related to age or disability. Social scoring by public or private actors — the kind of system that assigns citizens a trustworthiness rating based on their behaviour.

Predictive policing based solely on profiling. Untargeted scraping of facial images to build recognition databases. Emotion inference in workplaces and schools. Biometric categorisation that infers sensitive attributes like race or sexual orientation. And real-time remote biometric identification in public spaces for law enforcement, with only narrow exceptions.

Maximum fines for breaches of Article 5 are EUR 35 million or 7% of worldwide annual turnover, whichever is higher.

High-Risk AI Systems

The Act’s main regulatory weight falls here. The clearest example — and the one most organisations will recognise — is hiring algorithms: AI used to screen CVs, rank candidates, or score applicants against a job profile. Under the Act, those systems are high-risk by default, with all the documentation, oversight, and conformity-assessment obligations that come with the classification.

High-risk systems are split into two groups. The first covers AI used as a safety component in products already regulated under existing EU sectoral law: medical devices, machinery, toys, lifts, and vehicles.

The second is the Annex III list — a defined set of standalone AI use cases in sensitive areas: biometric identification, critical infrastructure, education and vocational training, employment and worker management (where the hiring algorithm sits), access to essential private and public services like credit scoring and insurance, law enforcement, migration and border control, and administration of justice and democratic processes.

A 2023 study by appliedAI of 106 enterprise AI systems found that 18% were high-risk, 42% low-risk, and 40% were unclear, which gives a sense of how much classification work most organisations still have ahead of them.

Limited or Transparency Risk

This middle tier covers AI systems that are not high-risk but still warrant disclosure. Chatbots must tell users they are talking to a machine. Deepfakes and AI-generated content must be labelled. Emotion recognition and biometric categorisation systems must inform the people they observe. These are transparency obligations, not full compliance regimes.

Minimal or No Risk

Everything else. Spam filters, AI in video games, basic recommender systems, predictive text. The AI Act introduces no rules for AI deemed minimal or no risk. The vast majority of AI systems currently used in the EU fall into this category, though other laws — GDPR compliance, consumer protection, and sectoral rules — still apply.

 

Requirements for High-Risk AI Systems

Providers of high-risk AI systems carry the heaviest compliance burden under the Act. The requirements form an interlocking set of obligations covering the entire lifecycle of the system, from design through post-market monitoring.

Technical and Data Standards

Every high-risk system needs a risk management system that runs continuously throughout the system’s life — not a one-off pre-launch checklist. Training, validation, and testing data must meet quality criteria around relevance, representativeness, and accuracy. Bias must be identified and addressed, particularly where it could affect protected characteristics.

Technical documentation must be prepared before the system is placed on the market and kept up to date. Automatic logging must be built into the system to enable traceability of outputs.

Systems must reach an appropriate level of accuracy, robustness, and cybersecurity. After satisfying those requirements, the system goes through a conformity assessment, receives a CE mark, and is registered in an EU-wide database before it can be sold.

Obligations on Operators of High-Risk AI Systems

Deployers of high-risk systems must use the system in accordance with the provider’s instructions, ensure adequate human oversight by people with the necessary competence and authority, monitor the system for malfunctions or unexpected behaviour, keep automatic logs, and inform workers (and their representatives) before deploying a high-risk AI system in the workplace. Public-sector deployers and certain private operators in finance and insurance must also conduct a Fundamental Rights Impact Assessment before first use, assessing impact against the rights protected under the Charter of Fundamental Rights of the European Union.

Transparency Requirements

Across the high-risk regime, transparency runs as a thread. Deployers must be given enough information to understand how the system works, what its limitations are, and how to interpret its outputs. End users affected by automated decisions have the right to an explanation and to contest outcomes.

Insider Note: The Commission’s Digital Omnibus package, agreed politically on 7 May 2026, ties the application of high-risk obligations to the availability of harmonised technical standards. If those standards are not ready, the high-risk deadlines slip to late 2027 or August 2028, depending on the system type. Most organisations are still planning around August 2026; the practical date may now be later for many of them.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Rules for General-Purpose AI (GPAI) Models

GPAI models are regulated separately from AI systems. They sit upstream of most products that integrate them, so the Act treats them as a distinct layer with its own enforcement track inside the AI Office.

What Qualifies as a General-Purpose AI Model?

A GPAI model is one that shows significant generality, can competently perform a wide range of distinct tasks, and can be integrated into many downstream systems. Providers of GPAI models — defined as those trained above 10²³ floating-point operations — must meet transparency obligations and comply with EU copyright law.

A subset of these, GPAI models with systemic risk, face additional obligations. The current threshold is models trained with more than 10²⁵ FLOPs, which covers a small set of frontier models from a handful of providers.

Core Obligations for GPAI Providers

All GPAI providers face three core obligations. They must maintain detailed technical documentation of the model and share information with downstream developers integrating it. They must comply with EU copyright law, including respecting a clear opt-out for rightsholders who do not want their work used for training. And they must publish a detailed summary of the content used for training, using a template issued by the AI Office — the most novel of the three, since it forces transparency over training data in a way no other major jurisdiction currently requires.

Providers of systemic-risk GPAI models do all of the above and must additionally evaluate their models for systemic risks, conduct adversarial testing, assess and mitigate identified risks, report serious incidents to the AI Office without undue delay, and maintain an adequate level of cybersecurity. The GPAI rules became applicable on 2 August 2025, with full enforcement powers entering application on 2 August 2026.

Code of Practice for General-Purpose AI

To bridge the gap between the law coming into force and harmonised technical standards being published, the Commission worked with independent experts and over 1,000 stakeholders to develop the General-Purpose AI Code of Practice, finalised in July 2025. The Code has three chapters: Transparency, Copyright, and Safety and Security. The first two apply to all GPAI providers; the third only to systemic-risk providers.

Signing the Code is voluntary, but providers that do not sign must demonstrate alternative adequate means of compliance for the Commission to approve. The Safety and Security chapter has been drafted on the assumption that only about 5 to 15 providers worldwide will currently meet the systemic-risk threshold — a deliberately narrow group covering the makers of the most advanced frontier models.

EU AI Act Compliance Timeline and Application Dates

The Act applies in stages, and those stages have been moving. The May 2026 political agreement on the Digital Omnibus has reset several of the later deadlines. Here is the current picture:

1 August 2024 — The Act entered into force, twenty days after publication in the Official Journal. This is not a compliance deadline; it is the moment the law became part of the EU legal system.

2 February 2025 — Prohibitions under Article 5 became enforceable. AI literacy requirements under Article 4 also became live. These two chapters are already in full effect.

2 August 2025 — GPAI obligations became applicable. Governance structures, including the AI Office and its advisory bodies, became operational.

2 August 2026 — The headline general application date. High-risk AI obligations under Annex III, transparency requirements, and most operational provisions apply from this date — subject to the Omnibus caveat that where harmonised standards are not available, certain deadlines shift further.

Late 2027 / August 2028 — The revised outer limits for Omnibus-affected high-risk obligations where harmonised standards have not yet been published. For Annex I embedded systems (safety components in regulated products), the deadline now falls in August 2027.

2 December 2026 — The revised deadline for AI-generated content watermarking, pushed back from August 2026 under the Omnibus deal.

 

Governance and Enforcement

The AI Act is enforced through a hybrid model. The Commission, through the AI Office, holds direct enforcement powers over GPAI models. Member States enforce most of the rest through national market surveillance authorities.

The EU AI Office

The European AI Office sits inside the Commission’s Directorate-General for Communications Networks, Content and Technology (DG CNECT). It enforces the rules for general-purpose AI models EU-wide and supports national governance bodies. Its powers include conducting evaluations of GPAI models, requesting information and measures from model providers, and applying sanctions.

The Office works alongside three advisory bodies: the European Artificial Intelligence Board (Member State representatives), the Scientific Panel of Independent Experts, and the Advisory Forum (stakeholders from industry, civil society, and academia).

 

EU AI Act Fines and Penalties

The penalty structure has three tiers, set out in Article 99.

Prohibited practices (Article 5): Up to EUR 35 million or 7% of worldwide annual turnover, whichever is higher.

Most other breaches (high-risk obligations, GPAI rules, transparency requirements): Up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher.

Providing incorrect or misleading information to authorities: Up to EUR 7.5 million or 1% of worldwide annual turnover, whichever is higher.

The “whichever is higher” formula means the percentage almost always wins for companies of any meaningful size. These penalties exceed GDPR’s maximum of EUR 20 million or 4% of turnover, making the AI Act the second-highest percentage-based penalty regime in EU digital regulation.

For SMEs and startups, the formula is inverted: the fine is the lower of the fixed amount or the percentage. A startup with EUR 2 million in revenue that breaches Article 5 faces a maximum fine of EUR 140,000 — not EUR 35 million. The reduction is real but not trivial; EUR 140,000 can still be existential for an early-stage company.

Important: The turnover used to calculate the percentage is group-level, not entity-level. A subsidiary deploying a prohibited AI system can expose the parent company’s full global revenue to the percentage calculation. This is the same trap that caught several companies under GDPR.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Supporting Compliance and Innovation

AI Regulatory Sandboxes

By 2 August 2026, every Member State must have at least one national AI regulatory sandbox operational. These are controlled environments where providers can develop, train, validate, and test AI systems under regulatory supervision before placing them on the market. Providers participating in sandboxes remain liable under applicable liability laws but are protected from administrative fines if they follow sandbox guidelines in good faith.

SMEs and startups get priority, free access to sandboxes. Documentation generated through sandbox participation can be used to demonstrate compliance with the Act, which materially reduces the cost of getting a high-risk product to market. The Omnibus deal also introduces an EU-level sandbox for cross-border or particularly complex cases.

AI Literacy Requirements Under Article 4

Article 4 has been live since 2 February 2025. It requires providers and deployers to ensure a sufficient level of AI literacy among their staff and others operating AI systems on their behalf. There is no mandated curriculum, no minimum number of hours, no certificate.

What organisations need is a documented program covering: general understanding of AI, the organisation’s role as provider or deployer, the specific risks of the AI systems in use, and role-appropriate depth (a compliance officer needs different training from a software engineer).

Insider Note: Standalone enforcement of Article 4 is unlikely to be a regulator’s first priority. The real risk is that absence of a documented AI literacy program becomes an aggravating factor in enforcement action for some other breach. Treat it as foundational, not optional.

How the Commission Is Simplifying EU AI Act Implementation

The Digital Omnibus, presented by the Commission on 19 November 2025 and politically agreed on 7 May 2026, is the most significant softening of the AI Act since it was adopted. As reported by the Financial Times, the package reflects sustained pressure from European industry — particularly German manufacturing — and broader anxiety in Brussels (sharpened by the Draghi report on European competitiveness) that the EU has been over-regulating itself out of the AI race.

Key changes include: conditioning the application of high-risk obligations on the availability of harmonised technical standards, with deadlines pushed to late 2027 or August 2028 where standards lag; narrowing the definition of “safety component” so that AI which merely assists users will not automatically be high-risk; extending simplified requirements to small mid-cap companies (SMCs), a new category sitting between SMEs and large enterprises; reinforcing the AI Office’s enforcement powers; expanding sandbox access including an EU-level sandbox; and pushing the AI-generated content watermarking deadline from August to 2 December 2026.

Small Business Guide to the EU AI Act

There is no general size exemption. A microenterprise developing a high-risk AI system has the same core obligations as a multinational. But the Act builds in specific support measures that meaningfully change the compliance calculus for smaller players.

These include the inverted fine calculations described above, free priority access to regulatory sandboxes, simplified technical documentation requirements, and the principle of proportionality applied to fees for third-party conformity assessment.

The Commission must regularly assess the cost of compliance for SMEs and consult them directly when developing standards and implementing acts. The Omnibus deal extends several of these concessions to the new SMC category as well.

For SMEs grappling with AI governance alongside broader data management obligations, frameworks like ISO/IEC 42001 — the international standard for AI management systems — can provide a useful structural backbone that satisfies both regulatory and certification goals simultaneously.

How Axipro Helps Clients Navigate the EU AI Act

EU AI Act compliance is not a single workstream. It sits at the intersection of technical auditing, data governance, legal interpretation, and product design — and it has to be maintained as the regulation itself keeps moving. Axipro’s AI Governance team supports clients across four areas.

AI Risk Categorisation.

We inventory the AI systems already in use across an organisation, map each one against the Act’s risk tiers, and flag the systems most likely to fall under the high-risk regime. For most clients, this is the single highest-value first step, since the appliedAI research found 40% of enterprise AI systems sit in a grey zone where the classification is unclear without expert review.

Governance Framework Design.

We help clients build the internal policies that the Act requires in practice: risk management procedures, data quality standards, transparency disclosures, AI literacy programs, and the documentation that ties them together. The goal is a framework that satisfies Article 4 today and scales to the high-risk requirements as they come into effect.

Conformity Assessments.

For clients with high-risk systems, we prepare the technical documentation, run pre-assessment audits, and coordinate with notified bodies on the mandatory certification process so that systems clear the CE-marking and EU database registration steps before they go to market.

Continuous Monitoring.

Compliance is not a launch event. Models retrain, use cases shift, and the regulation itself changes — the Omnibus deal being the clearest recent example. We provide continuous monitoring so that as AI systems and rules evolve, the compliance posture stays intact.

For organisations building, deploying, or selling AI in markets that touch the EU, the next twelve months are when planning becomes execution. Contact the Axipro Global Consulting Team to scope an AI governance review for your business.

What Is the EU AI Act in Simple Terms?

It is a single EU regulation that classifies AI systems by risk and applies different rules to each tier — from outright bans on the most harmful uses, to mandatory transparency and risk management for high-risk uses, with most everyday AI left alone.

Any software system meeting the Act’s definition of an AI system: one that operates with varying levels of autonomy, may exhibit adaptiveness after deployment, and infers from its inputs how to generate outputs such as predictions, content, recommendations, or decisions. Both narrow AI systems and general-purpose AI models are covered, with separate regimes for each.

Two groups: AI used as a safety component in products already regulated under EU sectoral law (medical devices, machinery, vehicles), and standalone AI in the Annex III use cases — biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, and administration of justice.

The headline date is 2 August 2026, but several obligations are already live (prohibitions and AI literacy since February 2025; GPAI rules since August 2025), and several others now apply later (Annex I high-risk in August 2027; some Omnibus-affected obligations as late as August 2028).

Up to EUR 35 million or 7% of worldwide annual turnover for prohibited practices; EUR 15 million or 3% for most other breaches; EUR 7.5 million or 1% for misleading authorities. For SMEs, the lower of the fixed amount or the percentage applies rather than the higher.

Yes. If the output of an AI system is used in the EU, the provider is in scope regardless of where they are based. Non-EU providers of high-risk AI systems must appoint an authorised representative established in a Member State.

 

The same core obligations apply as for large companies, but with inverted fine calculations, free priority sandbox access, simplified documentation requirements, and proportional fees for third-party conformity assessment. The Omnibus extends several of these concessions to the new small mid-cap category.

A unit inside the European Commission that enforces GPAI obligations EU-wide, coordinates national authorities, runs the AI Pact and Service Desk, and develops most of the secondary legislation and guidance underpinning the Act.

The EU’s position is not that AI is inherently dangerous, but that certain uses of AI can cause serious harm to health, safety, and fundamental rights — and that existing law does not adequately cover those uses.

The risk-based approach is the EU’s attempt to regulate the harmful uses without smothering everything else. Whether the balance is right is now the central political question, and the May 2026 Omnibus deal is evidence that even the EU is not fully convinced it landed in the right place the first time.

Axipro Author

Picture of Pedro Dias

Pedro Dias

Pedro has been writing online for over 10 years. With experience in all things programming, cyber security, and compliance, he is our editor-in-chief at Axipro.

Blog Highlights

Explore More Articles

The EU AI Act names recruitment AI as high-risk. Annex III explicitly lists AI systems used for recruitment, candidate selection, and employment decisions, which pulls CV screeners, video interview platforms, and assessment tools into the most demanding compliance regime the Act contains. The original compliance date for these systems was August 2, 2026. In June 2026, the EU’s Digital Omnibus moved the deadline to December 2, 2027, a 16-month extension that has led many HR and talent teams to shelve the topic entirely. That’s a mistake, for two reasons. First, one rule that directly affects recruitment technology is already in force: the ban on emotion recognition in the workplace has applied since February 2, 2025, and it catches features still shipping in some video interview products today. Second, the deferred obligations didn’t shrink. Conformity assessments, human oversight design, bias monitoring, and documentation all still arrive in full, and the practical work of auditing a recruitment stack, renegotiating vendor contracts, and training hiring teams routinely takes a year or more. Here’s what the EU AI Act actually requires of employers and vendors using recruitment tools, on the timeline that now applies. Why Recruitment Tools Are Classified as High-Risk Under the EU AI Act​ Definition of High-Risk AI Systems in Hiring​ The Act takes a list-based approach. Annex III, point 4, designates as high-risk any AI system intended for the recruitment or selection of natural persons, including placing targeted job advertisements, analyzing and filtering applications, and evaluating candidates. The same point covers AI used for decisions on promotion, termination, task allocation, and monitoring of workers, so the classification follows the tool through the entire employment lifecycle, not just the hiring funnel. The reasoning is straightforward: hiring decisions shape access to livelihoods, and algorithmic discrimination in hiring is well documented. The European Commission’s regulatory framework for AI treats employment as one of the areas where an AI error or bias causes serious harm to fundamental rights. That’s the test for the high-risk tier. Types of Recruitment Tools Affected In practice, the high-risk classification captures most of the modern recruitment stack: CV and resume screeners that rank or filter applicants, video interview platforms that score responses or delivery, psychometric and skills assessment tools that produce scores feeding a hiring decision, sourcing and matching algorithms that decide which candidates a recruiter sees, and programmatic job ad targeting systems that determine who sees a vacancy at all. If the system’s output materially influences who advances and who does not, assume high-risk until proven otherwise. Important: Emotion recognition is not high-risk in the workplace. It is prohibited. Article 5 bans AI systems that infer emotions of people in the workplace (outside narrow medical and safety cases), and that ban has applied since February 2025 with the Act’s top penalty tier attached. If your video interview vendor markets “engagement scoring” or “sentiment analysis” of candidates, that feature needs to be switched off for EU hiring now, not in 2027. Recruitment Tools That May Fall Outside High-Risk Classification Not everything in the HR stack qualifies. The Act carves out systems performing narrow procedural tasks that do not materially influence decision outcomes. An applicant tracking system that stores applications, schedules interviews, and sends templated emails is a database with a workflow, not a high-risk AI system. The same goes for tools that transcribe interviews without scoring them, deduplicate candidate records, or generate first drafts of job descriptions for a human to edit. The line is decision influence: the moment a tool ranks, scores, filters, or recommends candidates, it crosses into Annex III territory. Deployers who rely on an exemption must be able to document that assessment, so “we decided it doesn’t count” needs to exist on paper. Extraterritorial Scope: Which Employers Are Covered The Act applies to providers placing AI systems on the EU market and to deployers established in the EU, but it also reaches further: it covers providers and deployers located outside the EU where the output of the system is used in the EU. For recruitment, the consequence is blunt. A US or UK company with no EU entity that uses an AI screener to filter applicants for roles based in Berlin or Dublin, or that screens candidates located in the EU, is using the system’s output in the Union. Brexit doesn’t move UK employers out of scope when they hire into or from the EU. Providers vs. Deployers of Recruitment AI Tools The Act splits obligations between the provider (the vendor that develops the tool and places it on the market) and the deployer (the employer using it). Most employers are deployers, and deployer obligations are lighter but real. One common trap: an employer that substantially modifies a high-risk system, or puts its own name on it, can be reclassified as a provider and inherit the full provider stack. Heavy customization of a screening model, or fine-tuning it on your own hiring data, can be enough to trigger this. Key Obligations for Employers Using AI Recruitment Tools Human Oversight in Automated Hiring Decisions Deployers must assign oversight of the system to people with the competence, training, and authority to intervene. That last word matters. A recruiter who rubber-stamps whatever the ranking algorithm produces, because nobody has time to review 800 rejected CVs, doesn’t count as oversight. Regulators and courts will look at whether the human could genuinely override the system and whether they ever did. Designing review checkpoints where a person can meaningfully change the outcome, and logging when they do, is the core of compliant deployment. Transparency Requirements Toward Candidates Employers must inform workers and their representatives before putting a high-risk AI system into use at work, and candidates subjected to such a system must be told it is being used. In countries with works councils, such as Germany, this obligation lands on top of existing co-determination rights, so employee representatives may need to be consulted before the tool goes live rather than just told afterward. Burying an AI disclosure in a privacy policy paragraph is unlikely to survive scrutiny.

A green dashboard is not an audit opinion. Compliance automation platforms like Vanta, Drata, Secureframe, and Hyperproof have made SOC 2 readiness faster and cheaper, but every audit cycle produces the same pattern: controls that sat at “passing” for months come back from the auditor with exceptions or requests for re-testing. The four controls below account for a disproportionate share of those rejections, and they all fail for the same underlying reason. The tool confirmed that evidence exists. The auditor tested whether the control actually operated. This article walks through each of the four: what auditors reject, why, and how to fix the evidence before fieldwork starts. Why Compliance Tools Show “Passing” But Auditors Still Reject Controls​ The Gap Between Automated Checks and Auditor Judgment Compliance platforms run continuous control monitoring: API calls that check whether a configuration exists, a document is uploaded, or a task is marked done. That’s real value. It catches drift, keeps evidence in one place, and saves weeks of screenshot collection. An audit is a different exercise. A SOC 2 examination is an attestation performed by a CPA firm under AICPA standards, and the auditor’s job is to form an independent opinion on whether your controls met the Trust Services Criteria. That opinion rests on professional judgment, not on whether an API integration returned a 200 response. What “Passing” Actually Means in Your Compliance Dashboard​ When a control shows “passing,” the platform is telling you one narrow thing: at the moment of the last scan, an automated test found the artifact or setting it was programmed to look for: MFA enforced in the identity provider, a policy document uploaded, a training campaign sitting at 100%. The test says nothing about whether the underlying process ran the way your control narrative claims it did, or whether it ran that way across the whole audit period. How Auditors Evaluate Controls Beyond the Checkbox Auditors test two dimensions. Design effectiveness asks whether the control, as described, would meet the criterion if it worked as intended. Operating effectiveness, the core of a SOC 2 Type 2 report, asks whether it actually did throughout the audit period. To answer that, the auditor pulls a population (every access review, every change, every new hire in the period), selects a sample, and inspects the evidence item by item. A dashboard status feeds into that process. It doesn’t replace it. Insider Note: Auditors increasingly ask for evidence outside the compliance platform precisely because they know what the platform auto-collects. If every artifact you produce comes from the same tool export, expect the auditor to independently pull the population from the source system and compare. Discrepancies between the two are one of the fastest routes to an exception. Control #1: Access Reviews That Automation Marks Complete but Auditors Reject Why Auditors Reject Automated Access Review Evidence​ User access reviews sit under the logical access criteria (CC6.1 through CC6.3), and they are the single most common source of audit exceptions we see. The typical failure: the platform generated a user list, someone clicked “complete,” and the dashboard turned green. The auditor then asks a simple question the evidence can’t answer: what did the reviewer actually decide? The Missing Element: Documented Reviewer Judgment​ An access review is a judgment control. Someone with knowledge of the system must look at each account and confirm the access is still appropriate for the person’s role. A timestamped task closure proves the task was closed. It doesn’t prove anyone assessed anything, and an “approve all” review completed in ninety seconds gets exactly the skepticism it deserves. What Auditors Actually Want to See in Access Review Evidence Auditors look for four things: The full population of accounts at the time of review (including service accounts and admin roles), Evidence of who reviewed it and when, explicit dispositions per account or group (retain, modify, revoke), and Proof that flagged access was actually removed. That last item, the deprovisioning ticket showing revocation within a defined window, is the piece most companies can’t produce. How to Fix Your Access Review Control Before the Audit​ Assign a named control owner per in-scope system, run reviews quarterly, and require reviewers to record a disposition for every line, not a blanket approval. When access is revoked, link the removal ticket to the review record. If a quarter was missed, don’t backfill it. Document it honestly and show the remediation, because auditors treat fabricated retroactive evidence far more severely than a disclosed gap. Control #2: Change Management Approvals That Pass Automated Scans​ Why Ticket Closure Isn’t Proof of Approval​ Change management (CC8.1) automation typically verifies that production changes link to a ticket and the ticket is closed. Auditors test something stricter: that each sampled change was approved by an authorized person before deployment. An approval added after the merge, or a ticket closed by the same engineer who wrote the code, fails that test even though every automated check came back green. The Segregation of Duties Problem Automation Misses Segregation of duties is the requirement that no single person can develop, approve, and deploy the same change. NIST’s SP 800-53 control catalog treats it as a foundational access control principle, and SOC 2 auditors apply the same logic. Small engineering teams trip on this constantly. Self-approved pull requests, admins who can bypass branch protection, direct pushes to main: a scanner sees “changes with tickets” while an auditor sees SoD violations. Emergency Changes and Retroactive Approvals: Common Rejection Triggers​ Every audit period contains hotfixes. Auditors don’t reject emergency changes. They reject emergency changes with no documented post-hoc review. If your policy says urgent changes get retroactive approval within two business days, the auditor will sample your emergency changes and check exactly that. No policy, or a policy nobody followed, produces an exception. Rebuilding Change Management Evidence Auditors Will Accept​ Enforce the control technically: branch protection requiring at least one independent reviewer, no admin bypass, and deploy pipelines that only run from protected branches. Then write the emergency change procedure down and generate the review artifact every time it fires.

AI Tool Usage Tracking

One in five breached organizations last year traced the incident to shadow AI, and those breaches cost an average of $670,000 more than standard incidents, according to IBM’s 2025 Cost of a Data Breach Report. The worst part is that most of those organizations already ran a CASB, a DLP program, or both. The tools were on, but the traffic still got through. That’s the visibility gap this article is about. AI tool usage tracking isn’t the same problem as SaaS discovery, and the security stack built for the SaaS era misses most of what matters about AI. Below, we break down what tracking actually requires, where CASB and DLP fail, which categories of AI usage slip through, and what a stack that works looks like in 2026. What AI Tool Usage Tracking Actually Means Most teams that say they “track AI usage” mean they can see that someone visited chat.openai.com. That is app discovery, and it answers almost none of the questions a security or governance team actually needs answered. Beyond App Discovery: Tracking Prompts, Data Flows, and Model Interactions Real tracking covers three layers. First, which tools are in use: chatbots, copilots, coding assistants, embedded SaaS features, agents. Second, what data moves: the content of prompts, uploaded files, and pasted context, mapped against data classifications. Third, how models behave in your environment: which endpoints get called, which OAuth grants exist, which agents hold standing permissions. Seeing that an employee opened ChatGPT gets you nowhere. What you actually need to know is whether they pasted a customer contract into a personal account while they were there. The Difference Between Detection, Monitoring, and Continuous Tracking Detection is a point-in-time answer to “what AI is here?” Monitoring watches known tools on an ongoing basis. Continuous tracking is broader: it assumes the inventory changes weekly, correlates identity, data, and endpoint signals over time, and feeds a governance program rather than a one-off report. Frameworks such as the NIST AI Risk Management Framework and ISO 42001 assume the third mode. A discovery scan from last quarter won’t satisfy an auditor, and it certainly won’t slow down an attacker. Why Traditional SaaS Monitoring Falls Short for AI SaaS monitoring was built around a stable premise: an app is a destination with a domain, a login, and an admin console. AI breaks that premise in several ways at once. The risky activity is the content of an interaction, not the visit. The tool often isn’t a destination at all but a feature inside an app you already sanctioned. And increasingly the “user” isn’t a person but an agent acting on delegated credentials. Why CASB Misses Shadow AI Usage The Cloud Access Security Broker sits between users and cloud services to enforce policy, and for classic SaaS governance it still earns its keep. AI has structural blind spots that no amount of tuning can fix. CASBs Were Built for SaaS Apps, Not Model Endpoints A CASB catalog maps domains to applications with risk scores. AI usage doesn’t resolve neatly to a domain. The same api.openai.com endpoint serves a sanctioned enterprise deployment, a developer’s weekend experiment, and a data-leaking browser extension, and the catalog sees one “app”. Meanwhile, new model endpoints, wrappers, and niche AI tools appear faster than any vendor catalog can keep up with. Gartner research from late 2025 found 69% of organizations already suspect or have evidence that employees use prohibited public generative AI tools, catalog or no catalog. Blind Spots in Encrypted API Traffic to LLM Providers Prompt content travels over TLS. Without full TLS inspection, a CASB sees connection metadata: destination, volume, timing. It can’t see that the payload contained source code or patient records. And full TLS inspection is harder than the datasheet implies. Certificate pinning breaks it for many native apps and CLI tools, legal and works-council constraints limit it in the EU, and most organizations carve out broad exemption lists that AI traffic happily rides through. The OAuth and Embedded AI Problem CASBs Can’t See When an employee grants an AI meeting-notes tool access to their calendar and mailbox via OAuth, no proxy is involved at all. The vendor’s servers communicate directly with Microsoft’s or Google’s APIs using a persistent token. The same applies to AI features embedded inside sanctioned SaaS, think Notion AI, Slack AI, or Salesforce Einstein. The CASB sees approved traffic to an approved app, while the AI processing happening inside it, and whichever sub-processor it forwards data to, stays invisible. Personal Accounts and BYO-AI Bypass CASB Proxies Netskope’s 2026 Cloud and Threat Report found that nearly half of employees who use generative AI at work do so through personal accounts. Personal accounts on managed devices are hard enough; personal accounts on personal devices, home networks, and mobile connections never touch the corporate proxy path at all. Tenant restrictions help for a handful of major providers and do nothing for the long tail. Browser-Based and Extension-Delivered AI Escape Network Inspection AI browser extensions read page content and form inputs locally, then exfiltrate via their own backend, often to generic cloud infrastructure that categorizes as “technology” rather than “AI”. From the network’s view, it is routine HTTPS to a CDN. The riskiest interaction, an extension scraping everything an employee views, produces the most boring traffic signature. Insider Note: In AI governance readiness assessments, the OAuth grant review is where clients get the biggest surprise. We routinely find dozens of AI tools holding live mail, calendar, or drive scopes that nobody in IT ever approved, granted by employees who abandoned the tool (and sometimes the company) months earlier. The tokens keep working anyway. Why DLP Fails to Catch Shadow AI Data Exposure DLP has the opposite problem. It can sometimes see content, but it doesn’t understand it, and AI interactions defeat the pattern matching it depends on. Prompt-Based Data Loss Doesn’t Match DLP Signature Patterns DLP fires on signatures: credit card regexes, SSN formats, keyword dictionaries, file fingerprints. Sensitive prompts rarely look like that. “Summarize why we’re losing