EU AI Act — 20 honest answers

The EU AI Act does not require a specific title, but deployers of high-risk AI systems must have clearly documented responsibility for compliance. In practice, this is most often the IT manager, CTO, compliance lead, or a dedicated AI Officer. For a midmarket organisation, a part-time role with a clearly defined mandate will generally be sufficient. The important thing is that a named person owns the AI policy and is the escalation point for AI incidents.

An AI governance structure is the processes and responsibility levels that ensure AI systems are procured, deployed, and used responsibly. For midmarket, this includes at minimum: an approval process for new AI systems, clear system owners for each AI system in operation, an escalation path for incidents, and a review cadence for the AI policy. It does not need to be a formal committee — it can function as part of existing IT governance.

For deployers of high-risk AI, a written AI policy is practically mandatory — not because the law explicitly requires a document with that title, but because the oversight obligations (Article 26) require documented procedures for use, oversight, and incidents. An AI policy that consolidates these requirements in one document provides clear overview and is easier to present to supervisory authorities. For organisations deploying only minimal-risk AI, a written policy is still good practice.

Define what an AI incident means in your context: unexpected or harmful outputs, violations of acceptable-use policy, shadow AI use, or vendor notifications about known defects in high-risk systems. Create a simple incident log with fields for date, system, description, those affected, and remedial actions. For high-risk systems with potential impact on individuals' rights, there should be a documented escalation process to the system owner and potentially the DPO. Serious incidents may need to be reported to national supervisory authorities.

An AI inventory is a structured register of all AI systems used in your organisation. This includes purchased AI applications, AI features in existing platforms (e.g. Copilot in M365, AI ranking in your ATS), internal AI models, and generative AI services employees use daily (shadow AI). Per system, the inventory should at minimum document: name, vendor, purpose, user group, risk assessment (Annex III reference), system owner, and deployment date.

Use the EU AI Act's four levels: unacceptable (banned — e.g. social scoring), high-risk (Annex III categories — e.g. AI recruitment, credit scoring), limited risk (systems interacting with humans but not high-risk — e.g. chatbots, deepfake generation), and minimal risk (spam filters, recommendation algorithms). Check each system against Annex III: does it involve biometrics, critical infrastructure, education, employment, core financial services, law enforcement, migration, or justice? Yes answers likely indicate high-risk.

A usage description documents what the system is designed for, who uses it, and under what conditions. For high-risk systems, this is a requirement under Article 26. A good usage description contains: the system's purpose and intended use, the primary user groups (number and role), the specific business processes it supports, and potential effects on affected individuals. It does not need to be long — two to three paragraphs per system is normally enough.

Article 4 of the EU AI Act obliges deployers to ensure that employees working with AI systems have sufficient knowledge and understanding to use them responsibly and within their intended scope. It is not a requirement for specific certification or a particular number of hours — it is a requirement to ensure appropriate competence based on the system's risk profile and the individual's role. For employees using high-risk AI, requirements are higher than for those using a simple AI-based spell checker.

It depends on the system's risk level and the employee's role. Supervisory authorities expect proportionality: an HR employee using an AI recruitment system (high-risk) needs thorough training in the system's limitations, bias risks, and complaint procedures. An employee using an AI-powered search function (minimal risk) needs far less. A practical minimum standard: all employees who make decisions based on AI output about individuals should have documented training in the system's limitations and how human oversight works.

Keep a simple training log with: employee name (or anonymised ID), date of completion, system trained on, and format (e-learning, workshop, self-study). For high-risk systems, confirmation from the employee that they have reviewed and understood the material is recommended. A CSV file or spreadsheet in your internal document system is sufficient to start — more important is that the log actually exists and is kept up to date.

A Fundamental Rights Impact Assessment (FRIA) is mandatory for deployers of high-risk AI systems (Article 27) before deployment. 'High-risk' is defined in Annex III — the eight categories include recruitment and HR, credit assessment and core financial services, biometric identification, critical infrastructure, and education. FRIA must be revised at least every three years or when there are significant changes to the system. For systems processing personal data, FRIA should be coordinated with a DPIA.

DPIA (Data Protection Impact Assessment) is a GDPR requirement and focuses on risks to personal data and data subjects' rights. FRIA (Fundamental Rights Impact Assessment) is a new AI Act requirement with a broader focus: all fundamental rights — including the right to equal treatment, access to employment and education, and human dignity. FRIA is not limited to personal data. When a high-risk AI system processes personal data, both assessments are required.

Article 11 requires providers of high-risk AI systems to maintain and make technical documentation available. As a deployer, you are entitled to receive this documentation from your vendor. Technical documentation must describe: the system's general description and purpose, system architecture, development process (including training data description), performance metrics and test results, known limitations and risks, and cybersecurity measures. Explicitly request Article 11 documentation from your vendors.

Articles 12 and 26 require high-risk AI systems to log activity sufficiently to enable retrospective analysis of the system's behaviour. The specific logging requirement depends on the nature of the system. For systems that make or influence decisions about individuals, the log should at minimum document: when the system was used, what inputs were given, what the output was, and who made the final decision. Ask your vendor about the system's built-in logging and whether you can export these logs.

Review existing contracts for AI systems with three points in mind: (1) Is the vendor's Annex III classification of the system documented? (2) Does the vendor make technical documentation available as required under Article 11? (3) Does the vendor commit to informing you about significant changes to the system that may affect your compliance? At the next contract renewal, you can add specific AI Act clauses. Start by sending a simple query to your most important AI vendors.

AI due diligence is the process of assessing an AI system and its vendor before deployment. A minimum-based due diligence checklist should cover: Annex III classification, availability of technical documentation, vendor's compliance status, data processing agreement (DPA), geographical data placement, and a compliance contact person. For high-risk systems, due diligence should be documented and retained as part of the compliance archive.

Ongoing vendor monitoring is about staying up to date on changes to AI systems that may affect your compliance status. Practical measures: subscribe to vendors' AI compliance newsletters or release notes, set a semi-annual reminder to check for new versions of high-risk systems, and ensure you receive notification of incidents (many vendor contracts do not include this as standard — it needs to be explicitly agreed).

For certain types of AI-generated content, transparency is a requirement under AI Act Article 50. Specifically: deepfakes and AI-generated audio/image/video content intended to mislead must be labelled. Chatbots and systems that interact with humans in a way that could be mistaken for human interaction must inform users that they are interacting with AI. For organisations using AI to generate content for customers and stakeholders, a clear labelling policy is a good idea.

Article 26 requires deployers of high-risk AI systems to implement appropriate human oversight measures. In practice: define for each high-risk system which decisions AI output can inform versus which require human final approval, document the procedure for when and how an employee can override or stop the system, and ensure that employees actually have the capacity and competence to exercise this oversight. Human oversight is not real if the employee always approves AI output without review.

The AI Act and GDPR overlap on important points, particularly for AI systems processing personal data. Coordination points: (1) Update your Register of Processing Activities (RoPA) with AI systems processing personal data. (2) Coordinate FRIA and DPIA for high-risk AI systems with personal data. (3) Review privacy policies and notices to reflect AI processing. (4) Include AI vendors in your vendor register under GDPR. The DPO should be involved early in AI Act compliance work.