5 Questions a Regulator Will Ask First in an EU AI Act Inspection

An EU AI Act regulator inspection does not start with a 500-page questionnaire. It starts with five targeted questions designed to expose whether your organisation has done the minimum required work. If you cannot answer them clearly, you will be on the back foot for everything that follows.

The EU AI Act entered into force on 1 August 2024. The first hard obligations for deployers of high-risk AI systems apply from 2 August 2026. National market surveillance authorities — including the Dutch Autoriteit Persoonsgegevens (AP) and the Belgian APD/GBA — are already building their supervisory frameworks. The time to prepare your answers is now, not when you receive a letter.

---

# Q1: What AI systems do you currently deploy?

This is the inventory question. Every inspection starts here because regulators need a baseline. They want a documented list: which tools you use, what they do, who supplies them, and in which business processes they operate.

Without a system inventory, you cannot classify risk, assign responsibilities, or demonstrate compliance with any other obligation. The AI Act does not define a specific format for the inventory, but Article 26 places clear obligations on deployers to understand the AI systems they put into use. That understanding must exist in writing.

For an SME with 20 to 200 employees, a practical inventory is a simple register: system name, supplier, version or API endpoint, business function, data inputs, outputs, and the staff roles that interact with it. Include everything — the CV-screening plugin in your ATS, the credit-scoring module your finance team uses, the chatbot on your customer portal. Regulators look for completeness. A partial list signals that your governance is partial too.

Action: Build or update your AI system inventory this quarter. Assign one person as owner.

---

# Q2: What is the highest risk classification in your portfolio?

Once the regulator has your inventory, they immediately look for high-risk systems as defined in Annex III of the AI Act. Annex III lists eight areas where AI systems are presumed high-risk: biometric identification, critical infrastructure, education, employment, essential private and public services, law enforcement, migration, and administration of justice.

For most SMEs, the employment category is the one that bites. AI tools used in recruitment, CV filtering, performance monitoring, or deciding who gets promoted or terminated fall directly under Annex III, point 4. If you use an AI-powered ATS or a workforce analytics platform, you are almost certainly deploying a high-risk system.

High-risk classification triggers a cascade of obligations under Articles 26 and 27. You must verify that your supplier has provided a CE-marked system with an EU Declaration of Conformity. You must implement a human oversight mechanism. You must log system outputs. You must conduct a Fundamental Rights Impact Assessment (FRIA) before deployment. You must register the system in the EU database where applicable.

Regulators know the Annex III categories by heart. If you misclassify a high-risk system as limited-risk or minimal-risk, that error is both a compliance failure and a credibility problem. Get your classification documented, with the reasoning written down.

Action: Map each system in your inventory to an Annex III category or record explicitly why it does not fall within one.

---

# Q3: What AI literacy training have your staff received?

This question has a legal basis in Article 4 of the AI Act, which requires providers and deployers to take measures to ensure a sufficient level of AI literacy in their staff. The obligation applies now. Article 4 came into force on 2 February 2025, the earliest compliance date in the entire regulation.

Regulators will ask for evidence. Not your training plan, not your good intentions. Evidence: records showing which staff completed what training, when, and what the training covered. For high-risk systems, the bar is higher. Staff who operate, oversee, or interpret outputs from a high-risk AI system need role-specific training on how that system works, its known limitations, and the human oversight procedures.

A one-hour generic "AI awareness" module will not satisfy the regulator if your HR team is using an AI system to screen candidates. That team needs training tied specifically to the tool and the obligations attached to it.

Action: Create a training log with employee names, training content, completion dates, and the AI systems covered. Store it somewhere you can retrieve it in 30 minutes.

---

# Q4: What does your AI policy say?

A written AI policy is the governance anchor the regulator looks for to confirm that AI use in your organisation is managed, not accidental. The policy does not need to be long. It needs to be specific.

At minimum, your AI policy should state: which AI systems are approved for use, who has authority to approve new systems, how risk classification decisions are made and recorded, what the human oversight requirements are, and how staff report concerns or anomalies. For deployers of high-risk systems, the policy should also describe your FRIA process and how you satisfy Article 26 obligations.

AVG/GDPR interaction matters here too. If your AI systems process personal data — and most HR and customer-facing tools do — your AI policy should cross-reference your DPIA process and your data protection obligations under the AVG. The AP has signalled publicly that it will treat AI Act inspections as an opportunity to check GDPR compliance simultaneously. A unified policy saves you from being caught twice.

If you currently have no AI policy, draft one. A two-page document that directly addresses the points above is infinitely better than nothing. The regulator is not expecting a Nobel Prize in governance. They are checking whether you have thought about this at all.

Action: Draft or review your AI policy before the end of this quarter. Make it version-controlled and date-stamped.

---

# Q5: How do you handle AI-related incidents?

Something will go wrong. An AI-powered tool will produce a biased output. A system will flag a candidate for the wrong reason. A decision will be made on the basis of an AI recommendation that later proves incorrect. The regulator's question is not whether incidents happen — it is whether you have a process for catching and responding to them.

Article 26(5) requires deployers of high-risk AI systems to report serious incidents to the relevant market surveillance authority without undue delay. "Without undue delay" means you need a process ready before the incident, not invented during it.

Your incident handling process should cover four steps: detection (how does a staff member flag a suspected AI-related incident?), assessment (who determines severity and whether it meets the reporting threshold?), notification (what do you send to the AP or APD/GBA, and within what timeframe?), and remediation (what do you do to prevent recurrence?). Document this process. Test it at least once a year with a tabletop exercise.

For lower-risk systems, incident handling is still good practice even where it is not legally mandated. Regulators view a working incident process as evidence of a mature compliance posture.

Action: Write a one-page AI incident response procedure and assign a named owner for each of the four steps.

---

# Being Ready for All Five

The pattern across all five questions is the same: document everything, assign owners, and store records where you can find them quickly. Regulators are not trying to catch you on technicalities. They are testing whether AI governance in your organisation is real or cosmetic.

For SMEs, the practical roadmap runs in this order. First, build the inventory. Second, classify risk against Annex III. Third, check your training records against Article 4. Fourth, produce or update your AI policy. Fifth, confirm your incident process is documented and tested. None of these steps requires a large team or an external consultant to get started — but each one requires dedicated time.

The deadline of 2 August 2026 for high-risk deployer obligations is firm. The AP and APD/GBA will not wait for everyone to catch up. Starting with these five questions means you are already ahead of most SMEs in your sector.

Run a free 2-minute compliance check at comply.khairos.ai to see exactly where your organisation stands on each of these five areas before a regulator asks first.