Algorithmic Audit vs. GenAI Audit: Why They Are Not the Same Thing

Last updated: June 2026 · Reading time: 8 minutes

---

Two terms have become staples of AI governance conversations in Europe: "algorithmic audit" and "GenAI audit." They appear in the same presentations, the same procurement requirements, and sometimes the same compliance roadmaps — as if they described the same activity. They do not.

Conflating the two is more than a semantic slip. It creates genuine compliance gaps, misallocated budgets, and documentation that does not cover what regulators will actually scrutinise. This article draws a precise line between the two, maps each to the relevant EU AI Act provisions, and explains what happens when a single system falls under both frameworks at once.

What Is an Algorithmic Audit?

An algorithmic audit examines an AI system built on classical machine learning techniques: supervised models, scoring systems, automated decision engines, rule-based classifiers. These systems take structured inputs, apply a learned or programmed function, and produce an output — a credit score, a risk rating, a hiring recommendation, a benefit eligibility decision.

The audit evaluates four core dimensions:

Bias and fairness. Does the system produce systematically different outcomes across demographic groups? This requires testing across protected characteristics (gender, age, nationality, origin) using fairness metrics such as demographic parity, equal opportunity, and predictive parity.

Performance and robustness. Does the system perform as claimed? Does it degrade gracefully under distribution shift or adversarial inputs? Precision, recall, AUC-ROC, and stress-testing under edge cases are standard here.

Explainability. Can the system's outputs be explained in terms a human can understand and contest? This matters both technically (SHAP values, LIME, feature importance) and legally (the GDPR right to explanation under Article 22 and AI Act transparency requirements under Article 13).

Governance and documentation. Has the system been developed with adequate version control, data governance, human oversight mechanisms, and post-market monitoring?

The legal framework for algorithmic audits

Provision	What it requires
GDPR Article 22	Right not to be subject to solely automated decisions with significant effect; right to explanation
AI Act Annex III	Identifies high-risk use cases (credit, employment, education, law enforcement, migration, etc.) requiring conformity assessment
AI Act Articles 9–17	Risk management, data governance, technical documentation, transparency, human oversight obligations for high-risk systems
AI Act Article 27	Fundamental Rights Impact Assessment (FRIA) for deployers in certain high-risk use cases
CNIL guidelines (FR)	Algorithmic systems used in public administration and consumer decisions

Typical outputs of an algorithmic audit: bias report with per-group metrics, fairness assessment against defined thresholds, explainability documentation, technical documentation gap analysis, and a remediation roadmap.

Examples: A credit scoring model used by a French bank. A CV-screening tool used by a European retailer. An automated risk classification system used by an insurer. A recidivism prediction tool used in judicial proceedings.

What Is a GenAI Audit?

A GenAI audit — or generative AI audit — examines systems built around large language models (LLMs), image generators, code generation tools, or other generative AI architectures. These systems do not score or classify in a bounded output space; they generate novel content, and their failure modes are fundamentally different from classical ML.

The audit evaluates dimensions that do not exist in algorithmic audit:

Hallucinations and factual reliability. Does the system generate confidently stated falsehoods? Under what conditions? What guardrails exist to detect or suppress them?

Security and adversarial robustness. Can the system be manipulated through prompt injection, jailbreaking, or indirect instruction? These are not academic concerns — they are active attack vectors in production LLM deployments.

Training data transparency and intellectual property. What data was the model trained on? Does it reproduce copyrighted material? Can it be made to output personal data from its training set? These questions bear on both compliance and legal liability.

Systemic risk assessment. For the largest models (those trained on compute above 10^25 FLOPs), does the model pose risks to public safety, public discourse, critical infrastructure, or democratic processes at scale?

Content and output quality governance. How are outputs monitored? What human-in-the-loop mechanisms exist? How are incidents detected and reported?

The legal framework for GenAI audits

Provision	What it requires
AI Act Articles 51–55	GPAI model obligations: technical documentation, copyright compliance, transparency summary, systemic risk assessment (for highest-scale models)
AI Act Article 53	Core GPAI obligations: technical and copyright documentation, training data summary, cooperation with AI Office
AI Act Article 55	Additional systemic risk obligations: adversarial testing, incident reporting, cybersecurity measures
GPAI Code of Practice	Detailed operational requirements for GPAI signatories, covering evaluation, red teaming, and capability transparency
AI Act Article 50	Transparency obligations: chatbots and AI-generated content must be labelled; AI-generated synthetic media must be machine-readable marked

Typical outputs of a GenAI audit: adversarial evaluation report (red teaming), hallucination rate benchmarks, prompt injection vulnerability assessment, training data transparency summary, systemic risk mapping (for qualifying models), and an Article 53 documentation package.

Examples: An internal customer-service chatbot built on an LLM API. A legal document drafting tool powered by a foundation model. A code completion assistant deployed to developers. An LLM-based medical information system available to patients.

Side-by-Side: The Structural Differences

Dimension	Algorithmic Audit	GenAI Audit
Target system type	Classical ML, scoring, automated decisions	LLMs, generative models, foundation models
Primary failure mode	Bias, discrimination, incorrect classification	Hallucinations, jailbreaks, copyright leakage
Output space	Bounded (score, label, decision)	Unbounded (text, image, code)
Primary legal framework	GDPR Art. 22, AI Act Annex III / Arts. 9–17	AI Act Articles 51–55, GPAI Code of Practice
Explainability method	SHAP, LIME, feature attribution	Interpretability research, output monitoring
Adversarial testing	Robustness testing, distribution shift	Red teaming, prompt injection, jailbreaking
Systemic risk question	No (system-specific)	Yes (for highest-scale models)
Typical auditor profile	ML engineer + fairness researcher	AI safety researcher + red team specialist

When Both Frameworks Apply: The Compound Case

Here is where compliance planning can go wrong. A system may be subject to both audit types simultaneously — not as a matter of regulatory overlap, but because it genuinely combines both architectures.

Consider a human resources tool that uses an LLM to parse and summarise CVs, then passes structured outputs to a scoring model that ranks candidates. This system is:

• High-risk under Annex III (Article 6, use case: employment and workers management) — meaning full Articles 9–17 obligations and algorithmic audit requirements apply
• A downstream system integrating a GPAI model — meaning the system provider must understand the GPAI obligations of the foundation model provider and cannot rely on that provider's compliance to discharge their own obligations as a high-risk system provider

An algorithmic audit of the scoring layer without examining the LLM's hallucination risks and prompt injection vulnerabilities misses half the system. A GenAI audit that ignores the fairness properties of the downstream scoring model misses the other half.

Other compound examples: a medical imaging tool that uses a generative model for image enhancement before a classification model makes a diagnostic suggestion; an LLM-powered chatbot deployed in a consumer credit context; a legal AI system that generates contract drafts and then classifies their risk level.

The AI Act's allocation of responsibility in these compound cases is clear: if you are the provider of the overall system and it meets an Annex III use case, you carry the high-risk provider obligations regardless of which foundation model powers part of the pipeline.

Where DILAIG Fits

DILAIG's 50-question audit is built around the EU AI Act's high-risk system obligations — the algorithmic audit dimension of the compliance picture. It generates the four mandatory documents that high-risk AI system providers must produce before placing a system on the EU market: Technical Documentation (Annex IV), EU Declaration of Conformity, FRIA, and Transparency Notice.

DILAIG is not a red-teaming tool or an adversarial evaluation platform — it does not replace a dedicated GenAI audit for LLM-based systems. What it does is give you a structured, documented compliance baseline for the AI Act's core provider obligations, fast. That baseline is the prerequisite for any deeper external audit, whether algorithmic or generative.

→ Start your AI Act compliance audit — 50 questions, 4 documents ready in hours, no legal team required.

Learn what DILAIG generates · View pricing

---

FAQ: Algorithmic Audit vs. GenAI Audit

Q: Does the EU AI Act require an algorithmic audit? The AI Act does not use the term "algorithmic audit" directly. What it requires for high-risk systems is a conformity assessment process under Article 43 — which is substantially equivalent to what practitioners call an algorithmic audit. It covers risk management (Article 9), data governance (Article 10), technical documentation (Article 11), transparency (Article 13), human oversight (Article 14), and accuracy and robustness (Article 15).

Q: Does the AI Act require a GenAI audit? For GPAI model providers, Articles 53 and 55 require technical documentation, training data summaries, copyright compliance measures, and — for systemic risk models — adversarial testing. The GPAI Code of Practice translates these into detailed operational requirements that closely resemble what practitioners call a GenAI audit. The obligations have applied since August 2025.

Q: Who is responsible for a GenAI audit when using a third-party LLM API? The GPAI model provider (OpenAI, Anthropic, Mistral, Google) is responsible for their Articles 53–55 obligations. But if you build a high-risk AI system on top of their API, you are the provider of that high-risk system and must complete the conformity assessment for it. The two sets of obligations are independent and cumulative.

Q: Can one tool cover both types of audit? Some platforms address parts of both. No single tool replaces the judgment-intensive elements — red teaming, fairness metric selection, adversarial scenario design. What DILAIG provides is the structured documentation layer that anchors both audit types to the AI Act's mandatory output requirements.

Q: What about the Omnibus Regulation delay? The Omnibus Regulation proposal would push most high-risk provider obligations to December 2027. The GPAI obligations (Articles 51–55) remain unaffected — they applied from August 2025. Algorithmic audit obligations for Annex I systems (products covered by existing EU harmonisation legislation) shift to August 2027 regardless.

---

Key Takeaways

• Algorithmic audits examine classical ML and automated decision systems for bias, performance, explainability, and governance — grounded in GDPR Article 22 and AI Act Annex III.
• GenAI audits examine LLMs and generative systems for hallucinations, adversarial vulnerabilities, training data transparency, and systemic risk — grounded in AI Act Articles 51–55 and the GPAI Code of Practice.
• The two audit types address different failure modes, require different methodologies, and invoke different legal frameworks.
• A system embedding an LLM within an Annex III use case is subject to both frameworks; auditing only one layer creates genuine compliance exposure.
• DILAIG covers the structured documentation obligations for high-risk system providers — the mandatory starting point before any deeper audit engagement.

---

Sources

• Regulation (EU) 2024/1689 — EU AI Act, Official Journal of the EU, 12 July 2024
• AI Act Articles 6, 9–17, 22, 27, 43, 50, 51–55
• AI Act Annex III (high-risk use case list), Annex IV (technical documentation requirements)
• GPAI Code of Practice — EU AI Office, 2025
• Regulation (EU) 2016/679 — GDPR, Article 22
• CNIL — Algorithmic systems guidelines (2022, updated 2024)
• European Parliament, Council and Commission joint statement on the Omnibus Regulation amendment proposal (2025)