How to Prepare an Internal AI Act Audit: The 10 Questions to Ask
An internal AI Act audit is the fastest way to identify compliance gaps before regulators do. These 10 diagnostic questions cover every major obligation area and reveal where your organisation stands.
The August 2026 compliance deadline for high-risk AI systems is approaching. For most organisations that develop, deploy, or integrate AI systems, the honest answer to "are we compliant?" is: we don't fully know yet. An internal AI Act audit is how you find out — systematically, before a national market surveillance authority does it for you.
This guide provides ten diagnostic questions that cover the full scope of AI Act obligations. Work through them honestly. The gaps you discover are exactly what your compliance programme needs to address.
Before You Start: Map Your AI Systems
Before answering any question, you need an accurate inventory of AI systems in your organisation. This sounds obvious but is frequently skipped.
Your AI inventory should include every system that:
- Uses machine learning, statistical modelling, or rule-based reasoning to generate outputs that influence real-world decisions
- Processes data about individuals — customers, employees, citizens, patients
- Automates or substantially supports decisions that affect individuals' rights, interests, or access to services
For each system, record: the vendor or development origin, the version deployed, the use case and user groups, the data categories processed, and whether you are operating as provider or deployer under the AI Act's definitions.
Without this inventory, the audit questions below cannot be answered accurately.
The 10 Audit Questions
Question 1: Is any of our AI covered by the prohibited practices list?
Why this matters: Article 5 of the AI Act prohibits certain AI practices outright, with no compliance pathway. They are banned as of February 2025. If your organisation uses any of the following, stop immediately:
- Social scoring systems that evaluate individuals across multiple life domains and lead to detrimental treatment
- AI that exploits psychological vulnerabilities of specific groups
- AI that manipulates persons through subliminal techniques
- Most real-time remote biometric identification systems in public spaces
- Biometric categorisation inferring sensitive characteristics (race, political opinion, sexual orientation)
- Emotion recognition in workplaces and educational institutions (with narrow exceptions)
Diagnostic test: Review your AI inventory against Article 5. If any system matches a prohibited category, escalate to legal immediately.
Question 2: Which of our AI systems are high-risk?
Why this matters: High-risk classification triggers the full suite of Articles 9–15 obligations. Operating a high-risk AI system without meeting these obligations is a serious regulatory violation. Many organisations underestimate how many of their systems fall into Annex III.
Diagnostic test: Apply Article 6 to each system in your inventory.
Does the system:
- Form part of a product covered by EU harmonisation legislation listed in Annex I (medical devices, machinery, toys, vehicles, etc.)?
- Fall within one of the eight categories in Annex III (biometric ID, critical infrastructure, education, employment, essential services, law enforcement, migration, administration of justice)?
If yes to either: high-risk.
Also check whether the Article 6(3) exception applies: an Annex III system may escape high-risk classification if it poses no significant risk of harm to health, safety, or fundamental rights — but this exception requires documented justification and notice to the European AI Office.
Question 3: For each high-risk system, who is the provider and who is the deployer?
Why this matters: The AI Act assigns different obligations to providers (who develop/place on market) and deployers (who put into service in a specific context). Getting this wrong means either assuming obligations you don't have, or — more commonly — assuming you have none when you do.
Diagnostic test: For each high-risk AI system:
- If you built it or placed it on the EU market under your own name: you are the provider. Articles 9–17 apply.
- If you are using a third-party AI system in your operations: you are the deployer. Article 26 applies.
- If you have made substantial modifications to a third-party system: you may have become the provider under Article 25.
Question 4: Do we have the four mandatory documents for each high-risk AI system we provide?
Why this matters: Providers of high-risk AI systems must maintain four documents: Technical Documentation (Annex IV), EU Declaration of Conformity (Annex V), Instructions for Use (Article 13), and have conducted the conformity assessment procedure (Article 43).
Diagnostic test:
| Document | Required by | Do we have it? | Is it current? |
|---|---|---|---|
| Technical Documentation (Annex IV) | Article 11 | ||
| EU Declaration of Conformity | Article 47, Annex V | ||
| Instructions for Use | Article 13 | ||
| Conformity Assessment completed | Article 43 |
If any cell is empty, that is a compliance gap requiring immediate action.
Question 5: Is our risk management process documented and operational?
Why this matters: Article 9 requires providers to implement a documented risk management system — not just a risk register, but a systematic process that runs throughout the AI system's lifecycle.
Diagnostic test:
- Is there a documented process for identifying foreseeable risks to health, safety, and fundamental rights throughout the system lifecycle?
- Are risk evaluation criteria defined and consistently applied?
- Are risk control measures implemented and their effectiveness tracked?
- Is the risk management file updated when the system changes?
A risk assessment done once at launch and never reviewed is not compliant with Article 9.
Question 6: Does our training data governance satisfy Article 10?
Why this matters: Article 10 imposes specific requirements on the data used to train, validate, and test high-risk AI systems. Data governance failures here are among the most common causes of AI Act non-compliance findings.
Diagnostic test:
- Do we have documentation of the datasets used for training, including their source and provenance?
- Have we assessed the datasets for potential biases that could lead to discriminatory outputs?
- Are the datasets representative of the contexts where the system will be deployed?
- If the training data included personal data, was there a valid legal basis under GDPR?
- Are special category data (health, biometric, ethnic origin) processed for training purposes — and if so, on what legal basis?
Question 7: Is there a meaningful human oversight function operating?
Why this matters: Article 14 requires human oversight to be built into the system design and exercised in practice. As discussed in Question 3, oversight must be technically possible and operationally implemented.
Diagnostic test:
- Is there a designated oversight person for each high-risk AI deployment?
- Does that person have the authority to override, pause, or escalate AI outputs?
- Is that person adequately trained on the specific AI system, its limitations, and override procedures?
- Are oversight interventions (including overrides) logged and retained?
- When was the last review of whether the oversight function is actually being exercised versus rubber-stamped?
Question 8: Is there a post-market monitoring process in place?
Why this matters: Article 17 requires providers to have a post-market monitoring plan. Article 26(5) requires deployers to monitor high-risk AI systems in deployment. Performance degradation, data drift, and unexpected outcomes in real-world use must be detected and addressed.
Diagnostic test:
- Is there a defined set of performance metrics tracked for each high-risk AI system in production?
- Is there a process for reviewing these metrics regularly?
- Is there a defined threshold below which performance triggers corrective action?
- Is there a process for reporting serious incidents to national authorities under Article 73?
- When was the last post-market monitoring review conducted?
Question 9: Are deployers receiving adequate information from providers?
Why this matters: If you are a deployer, Article 26 requires you to use high-risk AI systems only in accordance with the provider's instructions for use. If those instructions are inadequate, you cannot comply. If you are a provider, Article 13 requires you to provide deployers with all the information they need.
Diagnostic test for providers:
- Do the instructions for use cover all elements required by Article 13(3) — intended purpose, performance metrics, limitations, oversight requirements, expected lifetime?
- Are the instructions reviewed and updated when the system changes?
Diagnostic test for deployers:
- Have you verified that the provider has issued an EU Declaration of Conformity?
- Do you have current instructions for use for each high-risk system you deploy?
- Is there a documented process for flagging to the provider if the AI system behaves unexpectedly?
Question 10: If we are a deployer of a public or public-interest service, have we completed FRIAs?
Why this matters: Article 27 requires FRIAs for public bodies and public interest service providers before deploying high-risk AI. Many organisations in this category are unaware of this obligation.
Diagnostic test:
- Is your organisation a public body or a provider of services of general public interest?
- If yes: have you completed a FRIA for each high-risk AI system deployed?
- If no FRIA exists: is deployment already live?
If you are in scope and have deployed without a FRIA, this is an ongoing violation requiring immediate remediation.
What to Do With Your Answers
After working through all ten questions, you will have a clear compliance gap map. Prioritise gaps in this order:
- Critical: Any affirmative finding on Question 1 (prohibited AI) or any high-risk system with zero compliance documentation (Questions 4, 5)
- High priority: Missing or inadequate human oversight (Question 7), missing FRIAs for in-scope deployers (Question 10)
- Medium priority: Gaps in post-market monitoring (Question 8), inadequate instructions for use (Question 9)
- Ongoing maintenance: Training data governance (Question 6), risk management currency (Question 5)
How DilAIg Helps
DilAIg's 50-question audit covers every obligation area mapped in this internal audit guide. Completing the audit produces all four mandatory documents for high-risk AI providers — Technical Documentation, Declaration of Conformity, FRIA, and Transparency Notice — in a single automated workflow.
Start your free AI Act audit at dilaig.com and close your compliance gaps before August 2026.
FAQ: Internal AI Act Audits
Q: How often should we run an internal AI Act audit? At minimum annually, and additionally whenever: a new AI system is deployed, an existing system is substantially modified, a new use case is added to an existing system, or your organisation's role changes (e.g., you begin distributing a system to other organisations, making you a provider).
Q: Should we engage external legal counsel for an AI Act audit? For the initial audit — especially if you have complex high-risk systems or are uncertain about classification — external legal input is valuable. For ongoing monitoring and documentation, automated tools like DilAIg are more cost-efficient for most organisations, with legal review of edge cases.
Q: What is the difference between an AI Act audit and a GDPR audit? A GDPR audit focuses on personal data processing, legal bases, data subject rights, and security. An AI Act audit focuses on AI system classification, risk management, technical documentation, conformity assessment, and human oversight. The two overlap — many high-risk AI systems process personal data — but they address distinct regulatory frameworks.
Key Takeaways
- An internal AI Act audit starts with an accurate inventory of all AI systems — without this, the audit cannot be meaningful.
- The ten questions cover the full obligation spectrum: prohibited AI, high-risk classification, provider/deployer role, documentation, risk management, training data, human oversight, post-market monitoring, deployer information, and FRIAs.
- Prioritise prohibited AI findings and absent documentation as critical; address systematically from there.
- An annual audit cycle is the minimum; audit additionally on any material change.