Prepare Your Organization for the AI Act: Ensure Safe Growth

September 28, 2026 · Bartłomiej Spasowski, Founder, modulla · EN

What is an AI Act audit and why organizations cannot delay it

An AI Act audit is a structured technical, legal, and operational assessment of artificial intelligence systems used in an organization, conducted to verify compliance with Regulation (EU) 2024/1689 — the EU Artificial Intelligence Act. It encompasses inventorying all AI tools, assigning legal roles (provider or deployer), classifying risk, and documenting oversight and governance mechanisms. This is not a one-time documentation review, but a continuous compliance process.

Experience shows that companies that have not conducted such a review have no idea how many AI systems are actually running in their environment. Marketing launches a chatbot. HR purchases a CV screening module. Finance integrates a risk scoring tool. Each department does this separately, without a shared registry. And suddenly it turns out that the organization is far more deeply involved in AI than management realizes.

AI Act implementation timeline: what is already in force

The Regulation entered into force on 1 August 2024, but its application is phased over time. The timeline is as follows:


Date	Scope of obligations
2 February 2025	Prohibition of banned AI practices (Art. 5) and obligation to provide AI literacy training
2 August 2025	Rules for general-purpose AI (GPAI) models, governance structures, penalty framework
2 August 2026	Transparency obligations (Art. 50): chatbots, synthetic content, and deepfakes must disclose their nature [19]
2 December 2027	Full application to high-risk systems (Annex III), registration in the EU database, Fundamental Rights Impact Assessments (FRIA Art. 27) [19]
2 August 2028	AI systems as safety components in regulated products (Annex I): medical devices, automotive [19]

Some provisions are already in force today. Companies that have continued to use AI systems prohibited under Art. 5 since 2 February 2025 are operating in breach of the law. The rest of the timeline allows time for preparation — but not for postponing the audit.

Four risk levels: where your organization's AI falls

The AI Act is built on a risk architecture. Every AI system must be classified into one of four levels, because this determines the scope of obligations [25].

Unacceptable risk (prohibited)

Systems that manipulate subliminally, exploit vulnerable groups, conduct social scoring, or use real-time biometric identification in public spaces for law enforcement purposes are unconditionally prohibited [25]. There is no room for interpretation here.

High risk (certification obligations)

Two groups. The first covers safety components in regulated products: medical devices, machinery, aviation, vehicles (Annex I). The second, relevant to most service organizations, covers autonomous systems operating in sensitive domains: recruitment and HR, credit scoring, education, critical infrastructure, migration administration, and the administration of justice (Annex III) [25].

A 2023 study by appliedAI conducted on 106 real-world AI systems found that 18% of systems could be classified as high-risk, 42% as low-risk, and as many as 40% fell into an ambiguous zone — primarily in the areas of HR, critical infrastructure, credit scoring, and customer assessment [4]. This is significantly higher than the European Commission's initial estimates, which assumed 5–15% of high-risk cases [4].

Limited risk (transparency obligations)

Systems that interact directly with humans — chatbots, emotion recognition tools, and AI-generated content (deepfakes, synthetic audio) — must clearly disclose their nature to users [14]. This obligation took effect on 2 August 2026.

Minimal risk

Spam filters, video games, standard analytics tools. No mandatory legal requirements, though voluntary codes of conduct are encouraged [25].

Provider or deployer: the trap few people know about

And here we get to the core issue: assigning the correct legal role is one of the most difficult and most frequently overlooked elements of the audit.

A Provider is an entity that develops an AI system — or commissions its development — and places it on the market under its own name or brand [31, 32]. The provider bears the heaviest obligations: a continuous risk management system (Art. 9), data governance (Art. 10), technical documentation (Art. 11 and Annex IV), a quality management system (Art. 17), conformity assessment (Art. 43), EU Declaration of Conformity (Art. 47), CE marking (Art. 48), and registration in the EU database (Art. 49) [31].

A Deployer is an entity that uses an AI system for professional purposes, under its own responsibility [31, 32]. Its obligations are lighter: following the provider's instructions, ensuring appropriate input data, maintaining logs (minimum 6 months), implementing human oversight (Art. 14/26), and — in certain cases — conducting a Fundamental Rights Impact Assessment (FRIA, Art. 27) [31].

The problem lies in the so-called reclassification trap (Art. 25). A deployer automatically becomes a provider if it places its own trademark on a high-risk system, changes its intended purpose, or makes a substantial modification [31]. In practice, fine-tuning language models on proprietary data, modifying algorithmic weights, or integrating RAG with company knowledge bases may trigger this mechanism [31]. The result: provider obligations and certification costs, with no prior plan to cover them.

Shadow AI: the invisible registry of AI systems in your company

According to Gartner forecasts, by 2027 75% of employees will be building or modifying technology outside the visibility of the IT department, compared to 41% in 2022 [1]. Employees use ChatGPT, Copilot, Claude, add plugins to SaaS tools, call APIs from spreadsheets. Every such touchpoint is a potentially unregistered AI system.

Art. 16 and 26 require full visibility over the organization's AI ecosystem [16]. An audit that relies on manual departmental surveys fails, because non-technical teams often do not realize that their SaaS tools use AI [16]. The market best practice is automated scanning of network and cloud infrastructure, which can deliver a preliminary AI asset registry within a short timeframe — even within a few days.

A central AI asset registry is not a bureaucratic requirement. It is the only tool that gives management a real picture of what is already running in the organization and what legal exposure it carries.

The registry should cover: model names and versions, business owners, assigned legal roles (provider/deployer), input data sources, risk level, and dependencies between systems.

Impact assessments: FRIA and its relationship to DPIA

Deployers of high-risk systems in the public sector, entities providing public services, or those using credit scoring and insurance scoring have an obligation to conduct a Fundamental Rights Impact Assessment (FRIA, Art. 27) [7, 8]. The FRIA examines the impact of an AI system on human dignity, non-discrimination, workers' rights, and access to justice [23, 24].

The difference from a DPIA (Data Protection Impact Assessment, GDPR Art. 35) is significant: a DPIA focuses exclusively on the privacy of personal data, while a FRIA covers a broader range of human rights [13]. Art. 27(4) explicitly allows deployers to build a FRIA on the basis of an existing DPIA rather than duplicating the work [7].

The market standard is an integrated DPIA + FRIA framework: a single joint document with shared system descriptions, data flow maps, and human oversight checkpoints, satisfying both the data protection authority and the market surveillance authority simultaneously.

ISO/IEC 42001 and the AI Act: what a certificate does not cover

Many organizations confuse ISO/IEC 42001 certification with legal compliance under the AI Act. This is a significant misunderstanding. ISO 42001 is an AI management system standard at the organizational level [26, 27, 28]. An ISO 42001 certificate does not replace AI Act requirements and does not grant CE marking [30]. It does not cover statutory mechanisms: EU database registration, CE marking, or FRIA [30].

The value of ISO 42001 lies elsewhere: it builds the organizational structure needed to meet the quality management system requirements of Art. 17 [29]. It generates the policies, risk management processes, and operational controls necessary to produce the technical documentation (Annex IV) required by the AI Act [29]. In other words: ISO 42001 is a good foundation, but not a finished building.

Research confirms that approximately 30–33% of organizations holding an ISO 42001 certificate or considered "compliant" have failed actual AI Act audits [11]. The main causes: static documentation, absence of runtime logs, and a discrepancy between written policies and production systems [11].

Financial penalties: the scale of risk from non-compliance

Art. 99 of the AI Act provides for a three-tier structure of administrative penalties based on global turnover [6, 19]:


Violation	Penalty
Prohibited AI practices (Art. 5)	Up to €35 million or 7% of global annual turnover (whichever is higher) [6]
Non-compliance with obligations for high-risk systems and GPAI	Up to €15 million or 3% of global turnover [6]
Providing misleading information to supervisory authorities	Up to €7.5 million or 1.5% of global turnover [6]

Reactive action under regulatory pressure costs 3 to 5 times more than proactive architecture adjustment at the design stage [20]. Regulatory intervention can also lead to product withdrawal from the market and operational freeze.

Practical applications of the AI Act audit across industries

HR and recruitment

AI systems for CV screening, candidate ranking, and employee assessment fall within the scope of Annex III. Deployers of such tools are required to conduct a FRIA assessing non-discrimination, workers' rights, and equal opportunities [7, 23]. If an HR department takes an external tool and fine-tunes it on its own historical employee data, it automatically becomes a provider with full certification obligations [31].

Financial sector

Automated credit scoring and insurance risk pricing are statutorily mandatory FRIA cases. Audits examine proxy variables in training data (e.g. postal codes as correlates of protected characteristics) that lead to indirect discrimination. Financial institutions are increasingly combining DPIA and FRIA into an integrated documentation framework.

Generative AI and synthetic content

Customer service chatbots, cloned voices, deepfakes, and AI-generated content are subject to Art. 50. From 2 August 2026, every system interacting with a user must disclose its AI nature at first contact. Providers of synthetic content must embed metadata and watermarks at the point of generation [14].

5 steps of an AI Act audit: what it looks like in practice

Inventory (Discovery): Automated scanning of cloud and on-premise environments to identify all AI systems, including Shadow AI. Building a Central AI Asset Registry.
Role and risk classification: Identifying prohibited practices (Art. 5) for immediate elimination. Classifying remaining systems by risk level and assigning legal roles (provider/deployer) to each.
Governance and quality management system: Implementing a quality management system (QMS, Art. 17), designating compliance owners, implementing human oversight protocols (Art. 14).
Impact assessments: Conducting integrated FRIA (Art. 27) and DPIA (GDPR Art. 35) for high-risk cases.
Conformity assessment and continuous monitoring: Technical documentation (Annex IV), conformity assessment under Annex VI or by a Notified Body (Annex VII), CE marking, and launching post-market monitoring systems.

Art. 9 requires a continuous, iterative risk management system — not a static pre-deployment checklist [20]. Auditors look for operational evidence: live event trails (Art. 12), post-market monitoring logs (Art. 72), and evidence that human oversight is actually exercised, not merely declared [20].

To put it plainly: paper compliance is an illusion of security. The regulator does not ask about a written policy — it asks for the logs from the past six months.

AI Act audit as a competitive advantage

Beyond avoiding penalties, an AI Act audit opens genuine market advantages. Corporate clients in procurement processes increasingly require documented AI governance. CE marking for high-risk products and ISO 42001 compliance create a differentiator against competitors who are only beginning to think about the topic. A study of 113 European AI startups found that 33% expect their products to be classified as high-risk under Annex III [4], meaning the certification and audit market will grow rapidly.

Organizations that treat the audit as a starting point for building a lasting AI governance architecture — rather than a one-time compliance project — also gain something else: a map of their own AI systems they previously lacked, and the ability to scale quickly without legal risk.

If you want to assess where your organization stands today in the context of the AI Act, we can work through it together. Contact us.

FAQ: AI Act audit in practice

When does my company need to be compliant with the AI Act?

It depends on which AI systems you use. The prohibition on banned practices (Art. 5) has applied since 2 February 2025. Transparency obligations (Art. 50) apply from 2 August 2026. Full application to high-risk systems from Annex III begins on 2 December 2027 [19]. However, preparation for each phase takes time, and it is worth starting the inventory audit now.

Is an ISO/IEC 42001 certificate sufficient for AI Act compliance?

No. ISO 42001 is an AI management standard at the organizational level that helps build the quality management system required by Art. 17. However, it does not replace legal compliance with the AI Act: it does not grant CE marking, does not cover EU database registration, or the Fundamental Rights Impact Assessment (FRIA) [30]. ISO 42001 is a good foundation, but the AI Act additionally requires evidence at the system and product level.

What is the reclassification trap in Art. 25 and how do you avoid it?

Art. 25 states that a deployer automatically becomes a provider if it places its own brand on a high-risk system, changes its intended purpose, or makes a substantial modification — such as fine-tuning a model on proprietary data [31]. To avoid the trap, every integration or modification of an external AI model should undergo a legal assessment for "substantial modification" before being deployed in a production environment.

What is the difference between FRIA and DPIA, and do I need to do both?

A DPIA (GDPR Art. 35) concerns the protection of personal data exclusively. A FRIA (AI Act Art. 27) assesses the broader impact on fundamental rights: dignity, non-discrimination, workers' rights, and access to justice [7, 13]. Art. 27(4) explicitly allows building a FRIA on the basis of an existing DPIA rather than creating a separate document [7]. The market standard is an integrated framework that satisfies both requirements simultaneously.